[OpenLayers-Dev] comment wrt latest GML update

[Christopher Schmidt]

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
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.)

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.

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.

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?'

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().

Regards,
-- 
Christopher Schmidt
MetaCarta