Yes, this was intended. The gt-epsg-wkt implementation was intended for use with Java Applets (which could not create an hsql database locally).
If you must respect axis order you will need to write a script to dump out the contents of hsql database to a properties file (and replace epsg.properties). -- Jody Garnett On 28 September 2015 at 03:44, Mart Sõmermaa <mrts.py...@gmail.com> wrote: > Hi, > > it seems that the gt-epsg-wkt plugin does not support the longitudeFirst > parameter to org.geotools.referencing.CRS.decode() and generally behaves > differently than gt-epsg-hsql. > > Is this intended? If yes, what's the recommended way to deal with > longitude-first CRSes in gt-epsg-wkt? > > Here's a sample project that demonstrates that converting coordinates from > WGS84 to KKJ succeeds when using the gt-epsg-hsql plugin, but fails when > usinggt-epsg-wkt: > > https://gitlab.com/mrts/broken-gt-epsg-wkt-crs-transform > > Thanks in advance for any info, > Mart Sõmermaa > > > ------------------------------------------------------------------------------ > > _______________________________________________ > GeoTools-GT2-Users mailing list > GeoTools-GT2-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users > >
------------------------------------------------------------------------------
_______________________________________________ GeoTools-GT2-Users mailing list GeoTools-GT2-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
