Closed brncsk closed 3 weeks ago
@brncsk 👏
could you also completely revert the changes in index.html and files.geojson that contain unwanted changes (in particular file timestamps updates) ? I'll update them locally once this PR is merged
@rouault Sure, will do – to clarify: that means I should completely revert both 0a46b04a32e9e95e9c1482a81f5ca9ae178c51d4 and 79c1ef1d6d16ddc73f3c6d7e2f627cd50b136a19 right?
Ok, I removed both 0a46b04 and 79c1ef1, addressed the suggested changes and fixed a typo in copyright_and_licenses.csv
(duplicate filename).
@rouault after a couple of emails w/ @zsiki, we've bumped into problems (whether semantic or technical is yet to be tackled) wrt between which EPSG entities one of our grid is supposed to work.
I'm going to tag this PR as draft until we figure how to address these problems.
I'll get back to this, but in the meantime, please do not merge.
Dear @brncsk ! Any news about the status of the merge? It would be highly appreciated. :-)
Dear @brncsk ! Any news about the status of the merge? It would be highly appreciated. :-)
@vbnhu Nope, sorry. It's on our backlog but with a rather low priority.
If anyone wants to pick this up and run with it: the main concern seems to be that (as per the convo w/ @zsiki) etrs2eov_notowgs.gsb
does not represent a datum shift between ETRS89 and HD72, but rather a transformation that maps EPSG:23700
onto itself (so you'd apply the transformation onto EPSG:23700
coordinates to obtain more precise EPSG:23700
coordinates).
As per @rouault's comment[1] on this PR's predecessor (proj-datumgrid#97) this does not make sense from PROJ's point of view – thus unsupported. The trick is, though, that despite all this, etrs2eov_notowgs.gsb
seems to actually work when used via +nadgrids
(the following is a modified version of EPSG:23700
's PROJ.4 definition):
+proj=somerc
+lat_0=47.14439372222222
+lon_0=19.04857177777778
+k_0=0.99993
+x_0=650000
+y_0=200000
+ellps=GRS67
+nadgrids=etrs2eov_notogs.gsb
+geoidgrids=geoid_eht2014.gtx
+units=m
+no_defs
I admittedly lack the knowledge to reconcile @rouault's and @zsiki's thoughts on the topic, so I basically gave up.
[1] https://github.com/OSGeo/proj-datumgrid/pull/97#discussion_r360696347
but rather a transformation that maps
EPSG:23700
onto itself (so you'd apply the transformation ontoEPSG:23700
coordinates to obtain more preciseEPSG:23700
coordinates).
that doesn't make much sense to me. Why wouldn't it be a transformation between HD72 and ETRS89 ? As I noted in https://github.com/OSGeo/proj-datumgrid/pull/97#discussion_r359587753, the values given by the Helmert transformation EPSG:1449 and etrs2eov_notowgs.gsb were consistent
If anyone wants to pick this up and run with it: the main concern seems to be that (as per the convo w/ @zsiki)
etrs2eov_notowgs.gsb
does not represent a datum shift between ETRS89 and HD72, but rather a transformation that mapsEPSG:23700
onto itself (so you'd apply the transformation ontoEPSG:23700
coordinates to obtain more preciseEPSG:23700
coordinates).
@brncsk @zsiki Looking at that, I kind of understand the idea of a "transformation onto EPSG:23700
coordinates to obtain more precise EPSG:23700
coordinates", but this isn't very compatible of the ISO-19111 framework that is used by PROJ. You can't (at least that's my understanding) have a transformation where the source CRS and the target are the same (except a time-based transformation for dynamic CRS, but that's not the case here).They need to have different codes. Perhaps you should IOGP / EPSG through https://epsg.org/dataset-change-requests.html to coordinate with them with the best way on how to model things properly to fit into ISO-19111. You might have to create some intermediate datum, geographic CRS and projected CRS. @busstoptaktik did have to create some artificial datums for old Danish transformations.
@rouault As per @zsiki's e-mail, I'm going to close this PR – hopefully they're going to propose an alternate solution to the problems, which will manifest in a new pull request.
This is basically a revival of https://github.com/OSGeo/proj-datumgrid/pull/97 (after having been in contact with @zsiki and obtaining his permission to do so).
Things that have changed:
at_bev
) that fetches and converts the files from the https://github.com/OSGeoLabBp/eov2etrs repository.Things yet to be addressed:
@rouault We'd kindly like to request a preliminary review from you on whether these additions are acceptable – and also if we need to do anything else to get this into
master
.