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
>
>

-- 
Ben Caradoc-Davies <b...@transient.nz>
Software Engineer
Transient Software <http://transient.nz>
New Zealand

------------------------------------------------------------------------------
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

Reply via email to