search

DanielJDufour / get-epsg-code

Gets EPSG Code for Various Inputs (incl. OGC WKT, ESRI WKT, PROJ String, Proj4js String)
https://get-epsg-code.netlify.com/
Creative Commons Zero v1.0 Universal
9 stars 1 forks source link

some ESRI WKT format Coordinate Reference System , such as EPSG:4490 or EPSG:4507, do not parse the correct results, please fix it #16

Open quanvae opened 1 year ago

DanielJDufour commented 1 year ago

Hi, @quanvae . Thanks for alerting us to this issue!

DanielJDufour commented 1 year ago

Here's an example with esriwkt from https://epsg.io/4490.esriwkt

doesn't work

getEPSGCode(`GEOGCS["GCS_China_Geodetic_Coordinate_System_2000",DATUM["D_China_2000",SPHEROID["CGCS2000",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]]`)
undefined

works

getEPSGCode(`GEOGCS["China Geodetic Coordinate System 2000",DATUM["D_China_2000",SPHEROID["CGCS2000",6378137,298.257222101]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943]]`)

Issue seems to be name of GEOGCS changed

DanielJDufour commented 1 year ago

The issue has been fixed for EPSG:4490; however, fixing EPSG:4507 will take some more time because it's more complicated. get-epsg-code works by doing simple normalization on the inputs (lowercasing, replacing spaces with underscores, removing extra characters, etc.). The issue with EPSG:4507 is that the core parameters changed.

old

PROJCS["CGCS2000_Gauss_Kruger_CM_105E",GEOGCS["GCS_China Geodetic Coordinate System 2000",DATUM["D_China_2000",SPHEROID["CGCS2000",6378137,298.257222101]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",105],PARAMETER["scale_factor",1],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["Meter",1]]

new

PROJCS["CGCS2000_GK_CM_105E",GEOGCS["GCS_China_Geodetic_Coordinate_System_2000",DATUM["D_China_2000",SPHEROID["CGCS2000",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Gauss_Kruger"],PARAMETER["False_Easting",500000.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",105.0],PARAMETER["Scale_Factor",1.0],PARAMETER["Latitude_Of_Origin",0.0],UNIT["Meter",1.0]]

In theory, I could have a Github action that looks for updates and automatically republishes every week, but I'd prefer a solution that supports both the old and new versions of esriwkt.

I'm going to explore ways I can harvest the history of esriwkt for projections and then maybe have multiple entries where the projection parameters have changed substantially. This will take some time.

Open to suggestions!

liu-yy258 commented 12 months ago

EPSG:4549 is also not parsed correctly looking forward to supporting

PROJCS["CGCS2000_3_Degree_GK_CM_120E",GEOGCS["GCS_China_Geodetic_Coordinate_System_2000",DATUM["D_China_2000",SPHEROID["CGCS2000",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Gauss_Kruger"],PARAMETER["False_Easting",500000.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",120.0],PARAMETER["Scale_Factor",1.0],PARAMETER["Latitude_Of_Origin",0.0],UNIT["Meter",1.0]]

DanielJDufour commented 12 months ago

It looks like the issue with EPSG:4549 is unfortunately the same as EPSG:4507 in that the PROJECTION parameter changed it's value. I'm reticent to make hard-coded fixes, because I don't think I can maintain that.

My current thinking is that the only way to solve this is to do a big rewrite and collect the whole history of ESRI WKT for each EPSG Code (which I'm definitely open to doing, but it might be a long while till that happens).

Open to thoughts or if there are CSVs that have already compiled this data!