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 [email protected] http://www.osgis.nl _______________________________________________ Dev mailing list [email protected] http://openlayers.org/mailman/listinfo/dev
