Nothing is especially wrong with it; it is just that it is not a decision we have made for the library. Traditionally we have left user data alone to be used by client code. We would need to decide what to put into it? A String for srsName when encoding; or a CoordianteReferenceSystem for transformation?
I also don't like having duplication (since then one thing will always be wrong); and our feature model is supposed to have the CoordinateReferenceSystem thing under control. Jody On 27/07/2010, at 8:11 PM, <[email protected]> <[email protected]> wrote: > Hi Justin, > > I like your second idea, and it is actually similar to the patch Jody whipped > up (http://jira.codehaus.org/secure/attachment/50280/GML2EncodingUtils.patch). > Since AbstractFeatureTypeBinding.getProperties() eventually calls > GML2EncodingUtils.getProperties() anyway, we can make the changes there > again. > So, instead of checking for GeometryAttribute only, it also checks if value > is a Geometry, and get the SRS from the type. > What's wrong with using userData though? > > Cheers > Rini > > -----Original Message----- > From: Justin Deoliveira [mailto:[email protected]] > Sent: Tuesday, 27 July 2010 12:32 AM > To: Andrea Aime > Cc: Angreani, Rini (CESRE, Kensington); [email protected]; > [email protected] > Subject: Re: [Geotools-devel] handling of geometry crs > > On 10-07-26 2:41 AM, Andrea Aime wrote: >> [email protected] wrote: >>> Hi Jody, >>> >>> Ah, I see how the CRS gets updated in the geometry attribute now. >>> However, for complex features, it doesn't even go through >>> ReprojectingFeatureCollection, that's why the schema doesn't get >>> recreated with the new CRS. >>> >>> My stack trace starts from ContentFeatureCollection, then >>> ContentFeatureSource(line 499): >>> >>> if ( !canReproject() ) { >>> if (query.getCoordinateSystemReproject() != null) { >>> try { >>> reader = new ReprojectFeatureReader(reader, >>> query.getCoordinateSystemReproject()); >>> } catch (Exception e) { >>> if(e instanceof IOException) >>> throw (IOException) e; >>> else >>> throw (IOException) new IOException("Error occurred trying to >>> reproject data").initCause(e); >>> } >>> } } >>> It creates ReprojectFeatureReader, which creates the transformer >>> without touching the schema. >>> The code that assumes userData as CRS is in >>> GeometryCoordinateSequenceTransformer.transform(Geometry) line 138: >>> >>> if (crs != null) { >>> transformed.setUserData(crs); >>> } >>> >>> My original patch actually checked if it's a map or not, to be >>> consistent with GML2EncodingUtils. I removed it though, as from my >>> observation when stepping through the code, it's never a map? >>> >>> Original patch included GeometryCoordinateSequenceTransformer (that is >>> commented out below): >>> >>> if ((g.getUserData() == null) || g.getUserData() instanceof >>> CoordinateReferenceSystem) { >>> //set the new one to be the target crs >>> if (crs != null) { >>> transformed.setUserData(crs); >>> } >>> // } else if (g.getUserData() instanceof Map) { >>> // Map userData = (Map)g.getUserData(); >>> // userData.put(CoordinateReferenceSystem.class, crs); >>> } >>> >>> It's then called in GML2EncodingUtils which traces back to >>> AbstractGeometryTypeBinding.getProperty(), like you said. >>> >>> Hmm.. maybe the problem is that it should always use >>> ReprojectFeatureCollection? >>> >>> I'll write a separate email to Justin re: the binding, since I'm not >>> sure how to do it correctly. >>> Thanks for all your help so far. >> >> Rini, I think I stumbled in exactly the same problem today: >> http://jira.codehaus.org/browse/GEOS-4072 >> >> I _think_ the problem could be solved by passing down the attribute SRS >> via the pico context like we do for parsing. >> Even there it seems to be a GeoServer specific hack, see >> AbstractGeometryTypeBinding.setCRS/initializeChildContext in >> the GeoServer WFS module. >> Maybe something similar can be done when encoding the property >> so that the geometry can get the CRS from the context again. > > Well we miss the ability to pass down information between bindings > during the encoding chain like we do for the parsing chain. > > I can think of two relatively simple fixes for this. One would be to add > a hint for setting some "global" srs or something. I guess this would > make it similar to the way feature transformer does it. > > The second way would be to modify the binding for AbstractFeatureType > and when it returns a geometry value to somehow set the srs there from > the feature type attribute type. Unfortunately simply modifying the user > data in place is probably not a good idea. It would be nice to be able > to create some sort of temporary wrapper, a proxy would work if geometry > was an interface... so maybe this one is not so simple. > > I guess the two are not completely orthogonal. The first could be used > as a fallback when the second does not work. Sorry just thinking out > loud here. >> >> Anyways, just thinking out loud, Justin should know better. >> >> Cheers >> Andrea > > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
