Hi,

Sorry if I expressed myself wrong: my data is actually in epsg:4647 and, since 
I am using FORCE_LONGITUDE_FIRST_AXIS_ORDER=false, it would be wrong to load 
the data in epsg:5652.

Now, since this specific WKT does not contain any information about proper axis 
order, from perspective of geotools epsg:5652 is probably a correct answer. I 
prefer though Geotools would not deliver just a first matching candidate but a 
set of possible matches; for an application or ultimately an user to choose the 
correct one from the set. Further I'd prefer CRS.lookupIdentifier() would not 
enforce FORCE_LONGITUDE_FIRST_AXIS_ORDER=true for this search​ 😕. Or, I now 
begin to wonder, is there a reason to?

The second issue, even if I copy/paste CRS class to my module and change the 
FORCE_LONGITUDE_FIRST_AXIS_ORDER flag to false, I still do not get 4647 as an 
answer.  I debugged it and found out, 4647 is discarded in 
IdentifiedObjectFinder#createFromCodes() / 
IdentifiedObjectFinder#deriveEquivalent() because its "baseCRS" ("EPSG:ETRS89") 
defines northing-easting axis to be default and so does not match "exactly 
(ignoring metadata)" "baseCRS" of the CRS constructed from WKT. This might be a 
bug, the axis order of "baseCRS" should not matter, since it is overridden in 
actual CRS anyway (always? I dont know).

With best regards, Slava
________________________________
Von: Ian Turton <[email protected]>
Gesendet: Samstag, 24. Januar 2026 13:04
An: Viatcheslav Sysoltsev <[email protected]>
Cc: [email protected] 
<[email protected]>
Betreff: Re: [Geotools-gt2-users] WKT to EPSG-code: cannot make 
CRS.lookupEpsgCode() to detect epsg:4647

Your data is stored in epsg:5652 - while you could alter the metadata to make 
it appear to be stored in epsg:4647 it would end up in the wrong place (and 
flipped through 90 degrees) - what you need to do is reproject it to epsg:4647. 
The easiest way to do this is to use a ReprojectingFeatureCollection using 
something like this


public static void main(String[] args) throws IOException, 
NoSuchAuthorityCodeException, FactoryException {
     if(args.length==0) {
       System.err.println("usage: Reprojector shapefile.shp");
       System.exit(1);
     }
     FileDataStore ds = FileDataStoreFinder.getDataStore(new File(args[0]));
     SimpleFeatureCollection features = ds.getFeatureSource().getFeatures();
     try(SimpleFeatureIterator itr=features.features()){
       int count=0;
       while(itr.hasNext()&&count++<10) {
         System.out.println(((Geometry) 
itr.next().getDefaultGeometry()).getCentroid());
       }
     }
     System.out.println("");
     ReprojectingFeatureCollection rfc = new 
ReprojectingFeatureCollection(features, CRS.decode("epsg:3875"));
     try(SimpleFeatureIterator itr=rfc.features()){
       int count=0;
       while(itr.hasNext()&&count++<10) {
         System.out.println(((Geometry) 
itr.next().getDefaultGeometry()).getCentroid());
       }
     }
  }


Ian


On Fri, 23 Jan 2026 at 16:36, Viatcheslav Sysoltsev 
<[email protected]<mailto:[email protected]>> 
wrote:
Hi,

Hope someone can help me... I did get a shapefile, I believe produced by QGIS, 
with .prj file:

PROJCS["ETRS_1989_UTM_Zone_N32",
    GEOGCS["GCS_ETRS_1989",
       DATUM["D_ETRS_1989",
          SPHEROID["GRS_1980",6378137.0,298.257222101]
       ],
       PRIMEM["Greenwich",0.0],
       UNIT["Degree",0.0174532925199433]
    ],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["False_Easting",32500000.0],
    PARAMETER["False_Northing",0.0],
    PARAMETER["Central_Meridian",9.0],
    PARAMETER["Scale_Factor",0.9996],
    PARAMETER["Latitude_Of_Origin",0.0],
    UNIT["Meter",1.0]
]

If I feed this WKT to the code:

CoordinateReferenceSystem crs = CRS.parseWKT(wkt);
Integer lookupResult = CRS.lookupEpsgCode(crs, true);

.. I do get number 5652, which is correct, but has northing-easting axis order 
(https://epsg.io/5652). I'd rather prefer 4647, which is the same, but with 
easting-northing. Is there a way to get it? I'm using gt-epsg-hsql plugin, here 
is the gradle classpath:

implementation 'org.geotools:gt-api'
implementation 'org.geotools:gt-referencing'
implementation 'org.geotools:gt-main'
implementation 'org.geotools:gt-epsg-hsql'
implementation 'org.geotools:gt-coverage'

Geotools version is 34.1.

// Strange thing, if I copy-paste Implementation of CRS class and set 
FORCE_LONGITUDE_FIRST_AXIS_ORDER to false, I still don't get 4647, but null. 
Might it be a bug, maybe 4647 is not in the hsql database?

With best regards, Slava



_______________________________________________
GeoTools-GT2-Users mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users


--
Ian Turton
_______________________________________________
GeoTools-GT2-Users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users

Reply via email to