[OpenLayers-Dev] gml:boundedBy

[Eric Lemoine]

Hi Tim

Do the GML specs say something about the correctness/accuracy of the
boundedBy value?

Say I build a feature grid and I want to center the map when a grid
row is clicked. I want this grid to work with both  HTTP/GeoJSON and
WFS/GML. For performance reason, I also want this grid to rely on the
server-calculated bounds. Then, it'd make my life easier if the GML
and GeoJSON formats stored the read bounds at the same location with
the feature object. That's why i'd rather keep some consistency there.

Chris, you disagreed with having the GeoJSON format read the box
property as geometry.bounds. What do you think now?

Eric

2009/2/5, Tim Schaub <tschaub at opengeo.org>:
> Hey-
>
> Eric Lemoine wrote:
>> Tim
>>
>> If we go that path, and I'm not against it, then we need to update the
>> GeoJSON format to be consistent with GML think.
>>
>
> Fine by me.  I could also understand the argument that we aren't going
> to make the GeoJSON spec consistent with the GML spec, so there's no
> reason that our parsers should have the same behavior.
>
> Tim
>
>> Cheers,
>>
>> Eric
>>
>> 2009/2/5, Tim Schaub <tschaub at opengeo.org>:
>>> Hey-
>>>
>>> I trashed the last message, but this is a response to the latest from
>>> Eric.
>>>
>>> Yes, geometry bounds is used by the renderer.  The calculation is
>>> expensive (given many features/many points).  If the server has done it
>>> for us already, we gain efficiency.  Not only in rendering, but in any
>>> feature selection by location, intersection tests, snapping, etc.
>>>
>>> I can't tell if this is just a pedantic argument, or if you guys have
>>> any real reason to think making use of gml:boundedBy will bring users
>>> harm.
>>>
>>> How about if we wait until people who use GML complain that things
>>> aren't working because their servers are reporting bogus gml:boundedBy
>>> elements?
>>>
>>> At that point, someone could create a patch that makes it optional.
>>> Until then, we all enjoy efficiency gains.
>>>
>>> Tim
>>>
>>>
>>> --
>>> Tim Schaub
>>> OpenGeo - http://opengeo.org
>>> Expert service straight from the developers.
>>> _______________________________________________
>>> Dev mailing list
>>> Dev at openlayers.org
>>> http://openlayers.org/mailman/listinfo/dev
>>>
>
>
> --
> Tim Schaub
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
> _______________________________________________
> Dev mailing list
> Dev at openlayers.org
> http://openlayers.org/mailman/listinfo/dev
>