Hmm yeah I figured it had something to do with that. Thanks for the detailed explanation, Ben. But my question remains: should gt-epsg-wkt be allowed to produce the wrong CRS in the first place? Should it perhaps not be completely removed from all dependencies and replaced by better alternatives
Regards Niels On 27-02-15 01:04, Ben Caradoc-Davies wrote: > Niels, > > I will answer your first question. You are right: this is a classpath > difference. The cause is that Maven and Eclipse have different > dependency models. Eclipse has no notion of a phase (compile versus > test) and no way to exclude transitive dependencies (so test > dependencies of other modules always get included on the classpath). > gt-epsg-wkt is the problem; how do you make it go away? > > This is the devious workaround I implemented in 2010 to disable > gt-epsg-wkt EPSGCRSAuthorityFactory so that gt-xsd-gml3 unit tests > pass in Eclipse: > https://github.com/geotools/geotools/blob/master/modules/extension/xsd/xsd-gml3/src/test/java/org/geotools/referencing/crs/EPSGCRSAuthorityFactory.java > > > https://jira.codehaus.org/browse/GEOT-3112 > > It may be enough to add gt-xsd-gml3 as a test-phase dependency before > all other dependencies. Maven will not include it as a dependency for > consumers of your module because it is test-phase only. Eclipse will > blindly include it at all times and disable gt-epsg-wkt. > > There is no META-INF/services SPI file as this is provided by the real > implementations. > > Kind regards, > Ben. > > On 27/02/15 10:52, Niels Charlier wrote: >> 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 >> >> > ------------------------------------------------------------------------------ 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
