switch to epsg.org as data source?

[floledermann]

The collection of parameters harvested from epsg.io results in parameters that give incorrect results when used in conjunction with proj4JS. The CRS data published at spatialreference.org seems to be more reliable in this regard.

For now it is only anecdotal evidence, but I have identified two cases where this causes incorrect results when using epsg-index:

EPSG:2169

https://epsg.io/2169 gives as a proj4 definition:
+proj=tmerc +lat_0=49.8333333333333 +lon_0=6.16666666666667 +k=1 +x_0=80000 +y_0=100000 +ellps=intl +towgs84=-265.8867,76.9851,20.2667,0.33746,3.09264,-2.53861,0.4598 +units=m +no_defs +type=crs

https://spatialreference.org/ref/epsg/2169/ gives:
+proj=tmerc +lat_0=49.83333333333334 +lon_0=6.166666666666667 +k=1 +x_0=80000 +y_0=100000 +ellps=intl +towgs84=-193,13.7,-39.3,-0.41,-2.933,2.688,0.43 +units=m +no_defs

(note the diverging towgs84 parameter!)

The latter one seems to be correct, see this thread on Mastodon for the feedback of someone with local knowledge: https://mapstodon.space/@jaykayone/111325366362650226

Simplified test case here: https://observablehq.com/d/841eca8097085b5d , with the definition from spatialreference.org giving the correct result.

EPSG:4312

https://epsg.io/4312 :
+proj=longlat +ellps=bessel +no_defs +type=crs

https://spatialreference.org/ref/epsg/4312/ :
+proj=longlat +ellps=bessel +towgs84=577.326,90.129,463.919,5.137,1.474,5.297,2.4232 +no_defs

Again, the latter one is correct, as the first one is missing the crucial towgs84 parameter.

I have no idea what is going on here, or how to reach the maintainers of epsg.io, but these (admittedly anecdotal) data points strongly suggest that epsg.io cannot be trusted as a source for CRS info.

Switching to the data from spatialreference.org should be easy, as the URL pattern https://spatialreference.org/ref/epsg/{epsg_code}/proj4/ will get a text-only response with the proj4 definition.

[floledermann]

Upon further digging around I found out that epsg.io does in fact contain the correct transformation, it is just not the selected default transformation... If you go to https://epsg.io/2169 you will see the transformation variants listed on the top left, the second one seems to give the correct results with proj4js. I don't know how this data can be accessed in a machine-readable way, or on which basis the transformation should be chosen to ensure compatibility with Proj4JS ...

I will update the issue title and description accordingly.

[derhuerst]

related: maptiler/epsg.io#171

[derhuerst]

What do you think we shall do?

• For each EPSG entry, provide a list of common variants?
• Just pick whatever https://epsg.org says?
• Just pick whatever https://spatialreference.org says?

[floledermann]

I tried to get to the bottom of this issue, but I still don't fully understand what's going on here and what the solution would be. epsg.io does contain the transformation data needed for Proj4JS, but unfortunately listed among other transformations which don't work with Proj4JS. I have not found a way to get any kind of metadata that would allow to choose the suitable transformation in an automated way. I am also kind of sure that the towgs84 parameter is used incorrectly for the "incompatible" transformations, but unfortunately I lack the geodesy knowledge to really get to the bottom of this.
So my conclusion is that maybe the data in epsg-index right now could be argued to not be incorrect, technically – on the other hand, an argument could be made that epsg-index should contain proj4 strings that actually work with Proj4JS, which is probably the most common use case (?)

Long story short, regarding the three options you gave, here's what I can comment:

• Providing alternative transformation variants is IMO not really useful, if there is no metadata and criteria to decide (in code) which transformation to use.
• epsg.org was repeatedly mentioned as authoritative source, but I lack the knowledge (and/or patience) to get any data out from this site... I am not sure if proj4 strings that reliably work with Proj4JS, or metadata that allows one to choose the appropriate transformation, can be gathered from epsg.org.
• The definitions on spatialreference.org seem to generally work with Proj4JS (although I could not verify this and there may be other problems with other CRS), but is claimed to be more "outdated" by people in the know. I am not sure if this is of relevance for the (potentially more casual) use cases of JS implementations.

Unfortunately the whole issue left me kind of puzzled, and I ran out of time to investigate further for now. In my own application ( https://cartolab.at/coords/ ) I resorted to manually fixing incorrect transformations whenever a problem is pointed out by my users, but this is not a feasible approach for epsg-index, I guess. So unfortunately I don't have a concrete suggestion at this time for how to proceed ☹.

[matafokka]

Hello, everybody! Chiming in with a related issue: now epsg.io uses +nadgrids parameter which requires external files to be downloaded. This renders espg.io and, consequently, epsg-index unusable with proj4js.

So I had to switch to epsg.org database for my project. You can get the database by registering an account on epsg.org.

My code passes my limited tests, and there seems to be little to no difference between coordinates produced my Proj4 strings and Proj4 strings from epsg.io before it was updated. Since epsg.io is not an official data source, I've decided to keep whatever is in epsg.org database. Still, I'm not sure if I did everything right, can never be :)

If you're interested in my approach, take a look at this file. It builds Proj4 strings for CRS and depends on other scripts in the same directory.

As for +towgs84 parameter, I don't know how to get it from EPSG database. However, in like 50% CRS it can be safely replaced with an ellipsoid and prime meridian definitions. Other 50% will suffer a precision loss which will vary from CRS to CRS.

[derhuerst]

Somewhat related, #13 proposes just switching to the MapTiler coordinates API, but I assume the latter has the same problems described here.