Hi, Okay, so according to the geotools documentation CRSes with full URI specification don't suffer from axis order confusions. But I have the following SRS used in a test: urn:x-ogc:def:crs:EPSG:6.11.2:26713 And here's the thing: when running the test in maven, this is North->East, when running the same test in eclipse this is East->North. How on earth could that be possible?? What I've been able to figure out is that when running in maven the CRS is built by DirectEpsgFactory which takes it from a database in epsg-hsql, but in eclipse it is built by EPSGCRSAuthorityFactory in epsg-wkt which takes it from a text file (which says east-north). So my guess is that this has something to do with the different way that maven and eclipse handle module dependencies. But still, shouldn't it always be North->East when specified with such a URI?
It almost seems like a pure gamble which axis order you are going to end up with in geotools. You can force geotools to always use east->north, but you can't do it the other way around! And you can only set that setting once in the beginning of running your java instance, changing it again doesn't guarantee success because of caching crses. Also, I think there is a lot of unnecessary throwing away of axis order going on by using srs strings when there are already methods in place to use CRS instead. For example in BoundingBoxImpl, the getSrs/setSrs methods are deprecated, but they are still used everywhere, even in new code, it seems like the deprecations in BoundingBoxImpl are still ignored. In the FilterDuplicatorVisitor, from which most filter visitors are derived, the boundingbox is rebuilt using setSrs() so all CRS information axis order is lost each time a filter is rebuilt with a visitor. I think that could be easily changed. Regards Niels ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
