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 > -- Gabriel Roldan OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ 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
