Hi Tim Do the GML specs say something about the correctness/accuracy of the boundedBy value?
Say I build a feature grid and I want to center the map when a grid row is clicked. I want this grid to work with both HTTP/GeoJSON and WFS/GML. For performance reason, I also want this grid to rely on the server-calculated bounds. Then, it'd make my life easier if the GML and GeoJSON formats stored the read bounds at the same location with the feature object. That's why i'd rather keep some consistency there. Chris, you disagreed with having the GeoJSON format read the box property as geometry.bounds. What do you think now? Eric 2009/2/5, Tim Schaub <[email protected]>: > Hey- > > Eric Lemoine wrote: >> Tim >> >> If we go that path, and I'm not against it, then we need to update the >> GeoJSON format to be consistent with GML think. >> > > Fine by me. I could also understand the argument that we aren't going > to make the GeoJSON spec consistent with the GML spec, so there's no > reason that our parsers should have the same behavior. > > Tim > >> Cheers, >> >> Eric >> >> 2009/2/5, Tim Schaub <[email protected]>: >>> Hey- >>> >>> I trashed the last message, but this is a response to the latest from >>> Eric. >>> >>> Yes, geometry bounds is used by the renderer. The calculation is >>> expensive (given many features/many points). If the server has done it >>> for us already, we gain efficiency. Not only in rendering, but in any >>> feature selection by location, intersection tests, snapping, etc. >>> >>> I can't tell if this is just a pedantic argument, or if you guys have >>> any real reason to think making use of gml:boundedBy will bring users >>> harm. >>> >>> How about if we wait until people who use GML complain that things >>> aren't working because their servers are reporting bogus gml:boundedBy >>> elements? >>> >>> At that point, someone could create a patch that makes it optional. >>> Until then, we all enjoy efficiency gains. >>> >>> Tim >>> >>> >>> -- >>> Tim Schaub >>> OpenGeo - http://opengeo.org >>> Expert service straight from the developers. >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> http://openlayers.org/mailman/listinfo/dev >>> > > > -- > Tim Schaub > OpenGeo - http://opengeo.org > Expert service straight from the developers. > _______________________________________________ > Dev mailing list > [email protected] > http://openlayers.org/mailman/listinfo/dev > _______________________________________________ Dev mailing list [email protected] http://openlayers.org/mailman/listinfo/dev
