Re: [Geoserver-users] Best way to implement WFS response that only returns the bbox of the result

[Lundmark A. <Alb...@sw...>]

Justin, I'll try your suggestion with a empty feature collection that still returns a bounding box. 

You mensioned a bug with encoding the bounding box. Is it fixed in 1.7.x now that http://jira.codehaus.org/browse/GEOS-2583 is fixed??

And if I get it to work we can deside on the "correct" way to get into the structure. For now I'll try the "Hits"-way with format_options.

//Albin

-----Ursprungligt meddelande-----
Från: Justin Deoliveira [mailto:jde...@op...] 
Skickat: den 3 mars 2009 17:16
Till: Andrea Aime
Kopia: Lundmark Albin; geo...@li...
Ämne: Re: [Geoserver-users] Best way to implement WFS response that only returns the bbox of the result

Andrea Aime wrote:
> Justin Deoliveira wrote:
>>>
>>> Hmm... you are assuming all formats are actually able to return a
>>> bbox information. Not sure if json does, csv and excel most definitely
>>> won't. So you'd end up with a new resultType that works only with a
>>> specific output format (gml), and in order to get it working, you'd have
>>> to modify core code instead of adding a new peripheral change.
>>> Kinda feels like using a cannon to hit a small bird ;-)
>> Well I would just assume that geojson supports some notion of a 
>> bounding box but I could be wrong. For other formats in which there 
>> are no standard representing spatial information (csv, excel) a 
>> bounding representation could be mocked up. A single row with 5 
>> columns sort of thing.
> 
> For excel, I have my hands free, but for csv, that would break its 
> "single table" nature. It could be eventually
> included as part of a comment, hacky, but workable.
> 
> For GeoJSON, yep, there is an optional element that can be used,
> called bbox:
> http://geojson.org/geojson-spec.html#bounding-boxes
> 
> Mind that by default we don't generate the bounds (see recent patches
> to avoid killing the server in case you're working with multi-million
> feature collections), so this new result type would have to either
> override the server configuration, or just not work in case the
> admin disabled feature bounding.
Sure that sounds reasonable. Give the server administrator final 
authority to turn the feature off. Or just take the meaning of 
featureBounding = false to mean never ever calculate bounds. And if the 
client asks for it throw a service exception.
> In the case of a server providing millions of features per type
> as an admin I would certainly like to have some control on that kind of 
> setting and eventually disable it so that nobody can slam my server
> with non interruptible jdbc queries that can take minutes to be run.
> 
> Cheers
> Andrea


-- 
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.