[OpenLayers-Dev] feature.bounds versus feature.geometry.bounds

Tim Schaub tschaub at opengeo.org
Thu Nov 12 21:13:06 EST 2009


Bart van den Eijnden (OSGIS) wrote:
> Hi list,
> 
> this discussion came up again in ticket 2255 
> (http://trac.openlayers.org/ticket/2255). I know it has come up before 
> (but I cannot find the respective thread right now).
> 
> What is our policy with respect to setting feature.bounds or 
> feature.geometry.bounds with values from server-side retrieved formats?
> 
> The current state of affairs in OpenLayers is:
> -GeoJSON: sets the bounds to feature.bounds
> -GML.Base sets the boundedBy info to feature.geometry.bounds
> 
> In my opinion it would be good to get one rule adopted for all formats, 
> and for me the most logical thing is setting feature.bounds. I see two 
> reasons for this:

I don't think we need the same rule for all formats.  But...

> 1) in GML the boundedBy property conceptually maps to the feature and 
> not the geometry

yes, in GML this is the feature bounds.  So you are correct, it should 
map to feature.bounds in OL.

In GeoJSON, any object can have a bounds member.  When present on the 
geometry, it should be set on the geometry by the parser.  When present 
on a feature, it should be set on the feature by the parser.

We don't parse the bounds member on GeoJSON geometries.  I don't think 
this is a problem, but it could be patched.

I also don't think we should say feature bounds is from the server and 
geometry bounds is calculated on the client.  (And I'm correcting myself 
if I've said otherwise before.)  A feature could have multiple 
geometries.  We use geometry.bounds frequently.  If people are really 
relying on feature.bounds, it should be updated when any geometry bounds 
change (and we should have a getter instead).

Tim

> 2) as you can see in the patch for ticket 2255, GML can have a boundedBy 
> property but have no geometry included in the feature
> 
> Tim, can you recall why you wanted it to map to feature.geometry.bounds 
> in GML.Base?

It was a mistake.  See the updated patch.

http://trac.openlayers.org/ticket/2255#comment:5

Tim

> 
> Best regards,
> Bart
> 


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



More information about the Dev mailing list