I was thinking that the paging would be exposed to the user - but of course
as you point out it could just be used internally to lower the per-request
response size.  I'm not sure we'd want to flood the server that heavily,
but improving performance via concurrent queries is an interesting option,
for sure.  We'll give this some thought.  We're also exploring reducing the
precision of the data itself, which is the ultimate best solution.

Agreed that using WMS to visualize the data might be better, atlhough the
query filter is fairly large (essentially a giant IN expression), so I
wonder how that would perform in practice.  The real impediment is that the
mapping framework we are using doesn't support this explicitly (it uses
OpenLayers at its core, but heavily encapsulated for purposes of client
code longevity).  But we might explore this approach if we have to.

Thanks for all your helpful suggestions.

Martin

On Tue, Oct 17, 2017 at 5:29 PM, Ben Caradoc-Davies <b...@transient.nz>
wrote:

> Why an awkward user experience? Can you not assemble the features on the
> client side? You could even make the requests in parallel if you do not
> mind the risk of saturating the server.
>
> If you are visualising all the features on a map, WMS might be a better
> solution. Why do you need the geometries? Interaction? Could this be
> implemented with a WMS GetFeatureInfo and then a WFS GetFeature to get only
> the geometries you need?
>
> Kind regards,
> Ben.
>
>
> On 18/10/17 13:20, Martin Davis wrote:
>
>> There are many geometries in a reponse (for example, one response has 2240
>> geometries, and has an uncompressed size of 123 MB!).
>>
>> We're aware of WFS paging, but in this particular use case it would result
>> an awkward user experience.   The use case is that they want to visualize
>> *all* the features on a map, to help decide where to locate a particular
>> biological sampling station. (The query features are biogeoclimatic zones
>> in BC, which is why they are so huuuge).
>>
>> Yes, GZIP is happening on the wire, but we could still realize a 50%
>> savings if the decimals were dropped.
>>
>> On Tue, Oct 17, 2017 at 5:08 PM, Ben Caradoc-Davies <b...@transient.nz>
>> wrote:
>>
>> Martin,
>>>
>>> do you have one giant geometry or many features? If you have multiple
>>> features, you can use WFS 2.0.0 paging to select a subset so that
>>> individual requests do not time out. This example requests one at a time
>>> but you can try larger increments:
>>> http://localhost:8080/geoserver/wfs?service=WFS&version=2.0.
>>> 0&request=GetFeature&typenames=topp:states&outputformat=json&count=1&
>>> startindex=0
>>> http://localhost:8080/geoserver/wfs?service=WFS&version=2.0.
>>> 0&request=GetFeature&typenames=topp:states&outputformat=json&count=1&
>>> startindex=1
>>> http://localhost:8080/geoserver/wfs?service=WFS&version=2.0.
>>> 0&request=GetFeature&typenames=topp:states&outputformat=json&count=1&
>>> startindex=2
>>> [...]
>>>
>>> Note that paging enables sorting to make requests stable; this imposes a
>>> small server overhead.
>>>
>>> GeoServer also supports paging for WFS 1.1.0 if you need it (extension,
>>> not part of the spec); just use maxfeatures instead of count and you
>>> should
>>> be good to go.
>>>
>>> GZIP compression should already be used on the wire.
>>>
>>> Kind regards,
>>> Ben.
>>>
>>>
>>> On 18/10/17 12:41, Martin Davis wrote:
>>>
>>> Thanks, Ben.  Unfortunately that setting won't work for us, because (a)
>>>> we
>>>> don't have access to the server to set it, (b) we want to use GeoJSON,
>>>> and
>>>> (c) we wouldn't want this setting to impact other layers (and in fact we
>>>> would like it to apply only to specific requests).
>>>>
>>>> And yes, am aware we can request responses with no geometry, but in this
>>>> case we need to display the geometry.  That's actually the key problem -
>>>> we
>>>> are requesting a large amount of geometry for display, and the requests
>>>> are
>>>> very slow or failing completely because the response size is so large.
>>>>
>>>> On Tue, Oct 17, 2017 at 4:29 PM, Ben Caradoc-Davies <b...@transient.nz>
>>>> wrote:
>>>>
>>>> Martin,
>>>>
>>>>>
>>>>> try Settings / Global / Number of decimals. This works for GML 2 and
>>>>> GML
>>>>> 3.1 but does not seem to work for GML 3.2 output.
>>>>>
>>>>> Do you need the geometries? If not, you can use the propertyname
>>>>> parameter
>>>>> to request only the properties you need for even smaller responses:
>>>>> http://localhost:8080/geoserver/wfs?service=WFS&version=2.0.
>>>>> 0&request=GetFeature&typenames=topp:states&propertyname=topp:PERSONS,
>>>>> topp:WORKERS
>>>>>
>>>>> Kind regards,
>>>>> Ben.
>>>>>
>>>>>
>>>>> On 18/10/17 11:55, Martin Davis wrote:
>>>>>
>>>>> Is there any way in GeoServer to request that the precision of WFS
>>>>> output
>>>>>
>>>>>> be reduced?  (I.e. remove decimal places from the ordinates?).
>>>>>>
>>>>>> We have a large dataset which has far too much precision on the data.
>>>>>> Removing unecessary decimal digits seems like it could significantly
>>>>>> reduce
>>>>>> WFS response size.
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------
>>>>>> ------------------
>>>>>> Check out the vibrant tech community on one of the world's most
>>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Geoserver-users mailing list
>>>>>>
>>>>>> Please make sure you read the following two resources before posting
>>>>>> to
>>>>>> this list:
>>>>>> - Earning your support instead of buying it, but Ian Turton:
>>>>>> http://www.ianturton.com/talks/foss4g.html#/
>>>>>> - The GeoServer user list posting guidelines:
>>>>>> http://geoserver.org/comm/userlist-guidelines.html
>>>>>>
>>>>>> Geoserver-users@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>> Ben Caradoc-Davies <b...@transient.nz>
>>>>> Director
>>>>> Transient Software Limited <http://transient.nz/>
>>>>> New Zealand
>>>>>
>>>>>
>>>>>
>>>> --
>>> Ben Caradoc-Davies <b...@transient.nz>
>>> Director
>>> Transient Software Limited <http://transient.nz/>
>>> New Zealand
>>>
>>>
>>
> --
> Ben Caradoc-Davies <b...@transient.nz>
> Director
> Transient Software Limited <http://transient.nz/>
> New Zealand
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-users mailing list

Please make sure you read the following two resources before posting to this 
list:
- Earning your support instead of buying it, but Ian Turton: 
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines: 
http://geoserver.org/comm/userlist-guidelines.html

Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Reply via email to