Okay I understand; so is this something we can work out on a uDig JIRA issue then.
Have you looked into the "interceptors" that apply the Filter / Query information? Or is this something handled by the feature renderer. -- Jody Garnett On Wednesday, 21 September 2011 at 6:32 AM, Emily Gouge wrote: > Jody, > > Having dug a bit further into this I don't believe it is a geotools bug > but a uDig one. Because of the way filters and queries are processed > (the filter is processed before the query is applied), I think the > original uDig code is correct and the "new" code is incorrect. > > In the rendering case the geotools renderer creates a bounding box > filter it applies on the raw data. This filter is applied to the > original feature source using the original CRS. We need this filter to > use a feature source that has the CRS that was specifically defined in > uDig. Thus, I think we have to use the > ForceCoordinateSystemFeatureResults class (or something similar). > > Emily > > > > On 17/09/2011 12:16 AM, Jody Garnett wrote: > > Hi Emily: > > > > That may be a result of poor QA after refactoring the code to use > > FeatureLayer; rather than the earlier MapLayer. No change in functionality > > was intended and this would be considered a regression. > > > > Can I ask you to open up a GeoTools bug report on this one; you have > > provided more than sufficient detail :-) > > > > > > > > > > > > _______________________________________________ > > User-friendly Desktop Internet GIS (uDig) > > http://udig.refractions.net > > http://lists.refractions.net/mailman/listinfo/udig-devel > _______________________________________________ > User-friendly Desktop Internet GIS (uDig) > http://udig.refractions.net > http://lists.refractions.net/mailman/listinfo/udig-devel
_______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
