How do we deal with organisations changing names?

[kbevers]

As luck would have it, the Danish geodetic authority (my employer) has changed its name from SDFE to SDFI. The question now is how to handle that? We've got a bunch of transformation resources in the dk_sdfe-folder which now all have the wrong prefix. Ideally I'd like to change all the prefixes from dk_sdfe to dk_sdfi but I am not sure how feasible that is. Can the names be aliased in the database so that references to e.g. dk_sdfe_dvr90.tif er linked to dk_sdfi_dvr90.tif and vice versa? Or is it generally best to just leave it as is and use the new name when releasing new products?

[rouault]

The grid_alternatives table of proj.db has 3 columns:

• original_grid_name: contains the value used in the EPSG dataset, e.g. ggeoid16.gri
• proj_grid_name: contains the value of the geotiff PROJ filename, e.g dk_sdfe_gvr2016.tif
• old_proj_grid_name: contains the value of the old PROJ filename (NTv2 or GTX), if there was such a file, e.g gvr2016.gtx

The FileManager::open_resource_file() method has logic to query the database to be able to use indifferently proj_grid_name and old_proj_grid_name.
Here we'd need a 4th value. Which shows that we would need to use a real aliasing mechanism that would support adding as many grid names as wished (possibly using the alias_name table or adding a alias_grid_names table) if we'd want to support dk_sdfe_dvr90.tif and dk_sdfi_dvr90.tif indifferently (perhaps a day SDFI will be renamed SDFxx ...). Nothing that can't be done, but code would have to be written.

Probably that a compromise would be to rename in PROJ-data the dk_sdfe directory to df_sdfi (and updating other references such as agency.json, README.data, CMakeLists.txt), while keeping the existing grid filenames unchanged.

[kbevers]

There's a bit of a back story to this issue. I am in the process of improving our documentation of all Danish and Greenlandic reference systems and transformations. This includes EPSG-updates. Part of this is also to give users a proper way to download our transformation models via our website (this isn't really possible today). With all of this up in the air I was thinking about giving the official filenames of the various models a revamp so they align with PROJ. That would of course also include updates to EPSG. So that the GVR2016 grid officially available from us would be dk_sdfi_gvr2016.tif instead of ggeoid16.gri as stated in EPSG today.

With that in mind, would updating the grid names in EPSG make it possible us to rename the grids in PROJ-data? The reasoning being that a change in original_grid_name would trigger new rows in the database which can then be reference to dk_sdfi_-prefixed files. The old dk_sdfe_-prefixed files can be kept in the archive I guess.

[rouault]

With that in mind, would updating the grid names in EPSG make it possible us to rename the grids in PROJ-data?

My reading of the code is that a new row with
original_grid_name=dk_sdfi_gvr2016.tif
proj_grid_name=dk_sdfi_gvr2016.tif
old_proj_grid_name=dk_sdfe_gvr2016.tif
might work in compatibility mode (that is if using grids=dk_sdfe_gvr2016.tif and not finding it, dk_sdfi_gvr2016.tif will be attempted. But the reverse won't be true. cf comment https://github.com/OSGeo/PROJ/blob/a390c57ab5998154535d7ffbc7de04aad2a73910/src/filemanager.cpp#L1649), but you should definitely confirm this by simulating changes in data/sql/grid_transformation.sql and grid_alternative.sql

The old dk_sdfe_-prefixed files can be kept in the archive I guess.

In the proj-data-XXXX tarball, you mean ? That would be confusing to have both the old and new names (and it wouldn't help keeping it as small as possible). If you meant on the CDN, yes, there's no issue. The resynchronization from PROJ-data to the CDN is a append/update only operation: existing files on the CDN no longer in PROJ-data are kept. So older PROJ releases using the CDN will still work.

[kbevers]

In the proj-data-XXXX tarball, you mean ? That would be confusing to have both the old and new names

Yeah, that's what I meant. Just thinking out loud what might work. It's definitely a downside to have duplicates. I'll have to test what happens if I add new rows to grid_alternatives and how it affects backwards compatibility.