epsg.io is misleading people in believing it is a reference #171
Comments
neteler
added a commit
to neteler/grass
that referenced
this issue
Oct 16, 2024
As epsg.io is partially outdated (see [source](maptiler/epsg.io#171) and related) and PROJ is our engine anyway, this PR switches the references in the GUI to https://spatialreference.org.
neteler
added a commit
to OSGeo/grass
that referenced
this issue
Oct 17, 2024
As epsg.io is partially outdated (see [source](maptiler/epsg.io#171) and related) and PROJ is our engine anyway, this PR switches the references in the GUI to https://spatialreference.org. * "See also" section: added URLs to CRS Explorer and EPSG Geodetic Parameter Dataset Co-authored-by: Vaclav Petras <[email protected]>
neteler
added a commit
to OSGeo/grass
that referenced
this issue
Oct 17, 2024
As epsg.io is partially outdated (see [source](maptiler/epsg.io#171) and related) and PROJ is our engine anyway, this PR switches the references in the GUI to https://spatialreference.org. * "See also" section: added URLs to CRS Explorer and EPSG Geodetic Parameter Dataset Co-authored-by: Vaclav Petras <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
the use of the epsg namespace in epsg.io is misleading people in believing it is the ultimate source of truth. When presenting objects like CRS, it is probably OK, but for coordinate transformations, when datum shifts are involved, there are always more or less arbitrary choice to make if the user doesn't choose the datum transformation itself. It would be honest in the UI to add a prominent warning that it is one possible transformation, not necessarily the only one (that could be restricted to situations where datum transformations are involved)
Trigger for this is this GDAL / PROJ ticket ( OSGeo/gdal#3377 (comment) ) where users take for granted epsg.io output. And I've seen such pattern in other tickets too.
The text was updated successfully, but these errors were encountered: