Add Hungarian grids

[brncsk]

This is basically a revival of OSGeo/proj-datumgrid#97 (after having been in contact with @zsiki and obtaining his permission to do so).

Things that have changed:

• Both grids have been converted into GeoTIFFs.
• All of @rouault's change requests were addressed and adapted to conform to the new repository's requirements.
• A basic build script has been added (based on what I saw in at_bev) that fetches and converts the files from the https://github.com/OSGeoLabBp/eov2etrs repository.

Things yet to be addressed:

• No attempt has been made so far to contact EPSG about this addition (but we are already in the process of completing the change request form and plan to submit it as soon as possible).

@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.

[aberenyi]

@brncsk 👏

[rouault]

This looks globally good to me. Besides the version change in copyright_and_licenses.csv, 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

[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 0a46b04 and 79c1ef1 right?

[rouault]

that means I should completely revert both 0a46b04 and 79c1ef1 right?

yes

[brncsk]

Ok, I removed both 0a46b04 and 79c1ef1, addressed the suggested changes and fixed a typo in copyright_and_licenses.csv (duplicate filename).

[brncsk]

@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.

[vbnhu]

Dear @brncsk ! Any news about the status of the merge? It would be highly appreciated. :-)

[brncsk]

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] OSGeo/proj-datumgrid#97 (comment)

[rouault]

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).

that doesn't make much sense to me. Why wouldn't it be a transformation between HD72 and ETRS89 ? As I noted in OSGeo/proj-datumgrid#97 (comment), the values given by the Helmert transformation EPSG:1449 and etrs2eov_notowgs.gsb were consistent

[rouault]

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).

@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.

[brncsk]

@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.