FYI, i have attached a patch which fixes this issue to this jira: http://jira.codehaus.org/browse/GEOT-2550
Please speak up if you have issue with it. -Justin Gabriel Roldan wrote: > Justin Deoliveira wrote: >> Some changes to the implementation of >> SimpleFeature.getDefaultGeometry() are causing some problems with >> geoserver cite tests. The changes in question are described here: >> >> http://jira.codehaus.org/browse/GEOT-2403 >> >> As stated in the issue, the method before the changes was inconsistent >> with the contract of getDefaultGeometry(), and henceforth the >> following fallback was removed: >> >> +// // not found? Ok, let's do a lookup then... >> +// if ( defaultGeometry == null ) { >> +// for ( Object o : values ) { >> +// if ( o instanceof Geometry ) { >> +// defaultGeometry = o; >> +// break; >> +// } >> +// } >> +// } >> >> In which an exhaustive lookup for any geometry is done. Perhaps not >> the best place for the code, and perhaps bad practice to depend on >> such a fallback/hack/assumption, but nonetheless, it was relied on, >> and hence needs to be replicated with an alternative to rectify the >> regression. >> >> The case in which this is coming up is in a wfs bounding box query >> which does not specify a specific geometric attribute. So what is done >> is that the empty string "" is placed into a PropertyName. This runs >> through the PropertyAccessor extension point and gets mapped to >> SimpleFaturePropertyAccessorFactory.DEFAULT_GEOMETRY_ACCESS, which >> just calls through to feature.getDefaultGeometry(). >> >> So.. I am proposing that the definition of "" as a property name be >> explicitly mapped to *any* geometry, since that is how it is being >> used in this context, rather than the default goemetry, now that its >> definition and implementation have been synced up. >> >> Discussing the change with Gabriel he has suggested we change the name >> DEFAULT_GEOMETRY_ACCESS to ANY_GEOMETRY_ACCESS, which makes sense to me. >> >> Thoughts and/or opinions? The only other place place I can see this >> causing an issue might with SLD. > My gut feeling is it shouldn't be a problem for SLD. But also am not > sure whether SFPropertyAccessor plays any role in SLD handling. > Still, getDefaultGeometry() was first introduced purely for the sake of > playing nice with SLD, the only spec where such a concept exists, up to > my knowledge. And SLD expects it to be always the same attribute. If it > werent, and you have a FT with a point and a polygon attribute, the > point one being the default geom, a feature instance where the point > attribute is null may end up being rendered with a point symbolizer over > the polygon attribute, and viceversa. Still, the fact that we didn't get > a complain is not an indication that there's no problem, it is just a > hard one to identify: multiple geometry attributes aren't that common, > and by looking at a map it's quite hard to know if a given symbol comes > from the point attribute or from the polygon one being applied a point > symbolizer... So when evaluating an SLD it either happens that > SFPropertyAccessor is not being used, and getDefaultGeometry() is being > called, meaning we're ok in returning the declared default geometry, or > it is used and hence there's no regression; worse case the "bug" keeps > as hidden as it was. > > my 2c.- > > Gabriel >> >> -Justin >> > > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
