[OpenLayers-Dev] comment wrt latest GML update

[Tim Schaub]

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,


-- 
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.