[OpenLayers-Dev] comment wrt latest GML update

[Bart van den Eijnden (OSGIS)]

I've worked with quite a few WFS servers, and to me gml:boundedBy is 
reliable.

Best regards,
Bart

Tim Schaub wrote:
> Hey-
>
> Christopher Schmidt wrote:
>   
>> On Wed, Feb 04, 2009 at 09:55:52AM -0700, Tim Schaub wrote:
>>     
>>> Hey-
>>>
>>> Eric Lemoine wrote:
>>>       
>>>> Hi devs
>>>>
>>>> The recent GML update Tim committed in trunk makes the GML format
>>>> reads BoundedBy into feature.geometry.bounds.
>>>>
>>>> Chris and I discussed this over the IRC a while back, we came to the
>>>> conclusion that the geometry.bounds value should always be calculated
>>>> by OpenLayers, and should therefore not be set to an external,
>>>> unreliable value. This provides some guarantee to the programmer on
>>>> the value of this property.
>>>>
>>>>         
>>> Sorry I missed the discussion.  I don't get this at all.  Unreliable?
>>>
>>> The point is to make use of what the server has already calculated and 
>>> ease the burden for the client.
>>>       
>> Is there a guarentee that what the server calculated is the same thing
>> as what OpenLayers has calculated? That's really the key question. For
>>     
>
> Of course not.
>
>   
>> GeoJSON data, where the data can easily be crafted by hand, there is a
>> possibility that someone would put in a 'bbox' that represents -- for
>> example -- the lower 48 states, while the actual coordinates is for the
>> entire dataset. (A 'bbox' for the 'United States' will be from -180 to
>> 180, because of Alaska being on both sides of the date line.)
>>     
>
> This is funny.  So, we write code that accounts for people who hand 
> calculate the bounds of the US but forget to include Alaska?
>
>   
>> If the 'bbox' in the data is not reperesentative of the actual geometry
>> -- if it's a rendering suggestion, or something else like that, as is
>> (reportedly) sometimes the case in GPX, and could potentially be the
>> case in any format, then using the bbox from the server has the
>> potential of OpenLayers not correctly drawing Alaska, because we use the
>> bbox as a filter of sorts (I believe) when drawing.
>>     
>
> Reportedly, sometimes?
>
>   
>> Since the 'bbox' is used internally by our rendering engine, I
>> stipulated that it may be important that we ensure the bbox that is
>> attached to the geometry match what we would calculate internally --
>> otherwise, the same geometries can be rendered differently.
>>
>> Since we don't have complete control over the servers, I argued that it
>> might be dangerous to include this.
>>
>>     
>
> I would never argue that anything we do might be dangerous.
>
>   
>> If GML has a sufficiently defined 'gml:boundedBy' property that it is
>> clear in the spec that it should *only* be a rectangular version of a
>> convex hull of the data in question, then the concern goes from being
>> one of 'what might something be meaning by gml:boundedBy', and instead
>> goes to 'Are there servers out there violating the spec?'
>>
>>     
>
> GML defines gml:boundedBy as the envelope that encloses the feature. 
> For our purposes, this fits.
>
> Of course there are servers that violate the spec.
>
>   
>> In the case of GeoJSON, the spec is loose:
>>
>>  "To include information on the coordinate range for geometries,
>>  features, or feature collections, a GeoJSON object may have a member
>>  named "bbox"."
>>
>> "Information on coordinate range" is loose enough that I would consider
>> it potentially possible to creat econforming GeoJSON that delivered a
>> BBOX different than what we would calculate via getBounds().
>>     
>
> I won't argue with you if you don't want to make use of the GeoJSON bbox 
> member.  I think it is perfectly sensible to make use of it - and 
> certainly eases the burden on the client if you care to do any geometry 
> intersection.
>
> I will argue against making things "consistent" by *not* making use of 
> gml:boundedBy.
>
> Tim
>
>   
>> Regards,
>>     
>
>
>   


-- 
Bart van den Eijnden
OSGIS, Open Source GIS
bartvde at osgis.nl
http://www.osgis.nl