File based CoordinateOperation factory

Andrea Aime added a comment - 21/Apr/12 5:14 PM Hi Oscar, I'd really want to avoid having directly knowledge between one factory and the other so I setup a test that reproduces the same conditions as GeoServer, forcing the usage of longitude first mode, and tested it the same way geoserver uses the referencing subsystem, that is, via the CRS utility class. The code is meant to be added among the gt-epsg-hsql module, where the official EPSG factory is available. Of course I modified your patch so that the DirectEPSGFactory does not get to know about the property based one. Now, there are two tests in there and they both pass, the only thing I had to do was to invert the ordinates since we're working in longitude/latitude mode, and avoid forcing a axis order in the epsg.properties file. So.. I cannot reproduce the problem. I'm about to catch a long flight (10 hours back to Europe) and in the next days I'll be pretty jet lagged, but could you write a test in GeoServer showing the issue? Maybe I failed to fully reproduce the GS enviroment.

Oscar Fonts added a comment - 24/Apr/12 11:25 AM Hi Andrea. Caveat: If no operation is found in the properties file, the CoordinateOperationFactoryUsingWKT (well, in fact, the DefaultCoordinateOperationFactory) will generate a "standalone" transform, not searching for further trasforms in the EPSG database. Added a testDefaultBehavior showing the case (it uses a NTv2 transform, which needs BETA2007.gsb). So, in a previous approach, I tried to call the "next available factory" from inside CoordinateOperationFactoryUsingWKT, before returning the control to DefaultCoordinateOperationFactory: https://github.com/oscarfonts/geotools/blob/dc1bde1c5d2952f81a19bdf636ff6d3b222b012d/modules/library/referencing/src/main/java/org/geotools/referencing/factory/epsg/CoordinateOperationFactoryUsingWKT.java#L246 ...and that worked, except when forcing LongitudeFirst. Now, we need the DefaultCoordinateOperationFactory to try to split the operation into steps (from projected to geodetic, etc), but need also to prevent it to resolve a datum shift without previously visiting the EPSG database. I'm willing to code, but some architectural view will be of much value. Any suggestions on how to do this neatly? Thanks.

Andrea Aime added a comment - 25/Apr/12 9:08 AM Oscar, I'm not the one that created the maze of factories that we have today, so I don't have a full understanding of it either, just been through them a few times so I hope to be able to figure out something if I have a test that shows the problem. But I don't know the solution in advance.

Andrea Aime added a comment - 06/May/12 5:25 AM Patch applied on trunk. I actually have another patch that avoids the custom wkt factory to use its own fallback mechanism, and uses the standard one instead, but it requires changes to some classes that I'm not comfortable with given that trunk is scheduled to become stable shortly, I'll open another jira and commit on the new trunk once we have it