Jody Garnett wrote: > Thanks for the summary Andrea. > > I agree on all counts. > > The query also allows for two specific modifications; forcing a CRS > (in cases where the CRS is incorrect) and transforming the data to a > different projection. > Which is implemented quite differently across datastores and can't really be trusted in most cases.
I agree on the first two points. And the third I would think the correct thing to do would be as Jody suggests to use the crs set on query and reproject into that. And as a fallback reprojecting into the crs of the first geometry returned. 2c. -Justin > Jody > > > On 13/09/2009, at 7:11 PM, Andrea Aime wrote: > >> Hi, >> I would like to discuss what seems to be a common bug in our codebase. >> >> By definition FeaturesSource.getBounds(query) returns the bounds of >> the collections that would be returned by the query. >> >> Now, the filter is honored, so only the bounds of the features that >> are actually catched by the filter is returned, but the properties are >> usually forgotten about. >> >> If the Query q extracts only non geometric attributes, what should be >> the result of fs.getBounds(q)? Imho they should be empty, as if >> the feature type was geometryless, because the feature collection >> returned by fs.getFeatures(q) _is_ geometryless. >> Yet the database code atm just ignores that and returns non empty >> bounds using the default geom or all the geoms. >> >> What if we have a feature type with multiple geometries and q extracts >> only one of them? Imho the fs.getBounds(q) should return the bounds >> of just the geometry column extracted. Yet, the current code either >> returns the bounds of the default geometry or uses them all. >> >> What if we have multiple columns that are in different srs? >> The resulting bounds are one, imho everything should be reprojected >> to the srs of the first geometric column requested. The alternative >> would be to use the crs of the default geometry, but that seems >> wrong, if you request the bounds of a single geometry column >> in a SRS other than the default one, wouldn't you expect the >> bounds to be returned in the SRS of the requested one? >> >> Opinions? >> >> Cheers >> Andrea >> >> -- >> Andrea Aime >> OpenGeo - http://opengeo.org >> Expert service straight from the developers. >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> 30-Day >> trial. Simplify your report design, integration and deployment - and >> focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Geotools-devel mailing list >> Geotools-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geotools-devel > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
