Appendix F: 14 geotiff.maptools.org domain links redirecting

[sadielbartholomew]

Title

Appendix F: multiple geotiff.maptools.org domain links outdated (redirecting)

Moderator

n/a or TBC

Requirement Summary

In the canonical document and all under Appendix F, there are multiple (specifically from a git grep "geotiff.maptools" | wc -l, 14) links to URLs with the domain root http://geotiff.maptools.org, a domain which now redirects to https://github.com/OSGeo/libgeotiff, as you can see by following the root link in a browser. As spotted during the creation of PR #476 .

Whilst the redirection works and is not problematic per-se, we should update them to corresponding links under the new domain it redirects to, since, at the least:

• at some point in the future the outdated links might not redirect any more and therefore become broken so best anticipate this and change them;
• in practical terms, this redirection means that we can't use the HTTPS protocol on all of those links `(see Convert all referenced URLs with HTTP protocol to HTTPS #476 (comment) where this was discovered), which we are able to use for every other link across the Conventions document and supporting files such as the revision history.

Technical Proposal Summary

1. Investigate to find the appropriate new page URLs under the new domain.
2. Update the links accordingly.

Benefits

Should be obvious, but:

• direct links are more explicit;
• prevent the risk that the old links will not break in future.

Status Quo

n/a

Associated pull request

Yet to be opened.

Detailed Proposal

As per summary - not too much to say since this is mostly infrastructure admin type changes.

[ChrisBarker-NOAA]

Has someone clarified with the geotiff team what the canonical url is? At a glance, http://geotiff.maptools.org looks like a canonical URL, with the gitHub project being an implementation details that might change.

[Armin-RS]

What about https://www.ogc.org/standard/geotiff/ ?
This is reference on git gitHub project page and looks "official".

[sadielbartholomew]

Hi both, thanks for your quick comments.

As for the URL we need, keep in mind it needs to work for all specific paths, and therefore pages, under that root, e.g. http://geotiff.maptools.org/proj_list/albers_equal_area_conic.html i.e. <root>/proj_list/albers_equal_area_conic.html would need to work, and with https://www.ogc.org/standard/geotiff/ that gives https://www.ogc.org/standard/geotiff/proj_list/albers_equal_area_conic.html which leads to a 'Page not found' error page, despite it seeming like a good equivalent to the original root. Unless we find pages that can replace these sufficiently (i.e. are similar enough) for all cases under the new root.

Has someone clarified with the geotiff team what the canonical url is?

@ChrisBarker-NOAA, FYI I have not checked this myself and I am not aware of anyone that has. It didn't strike us as an urgent issue and as such we (Lars and I) I believe intended to get the issue up but not take any further action for now. If someone else wants to take this on soon that would be great. It shouldn't be too time consuming or difficult for someone to ask the GeoTiff team, so it seems like a good first step.

[larsbarring]

I have very quickly looked at the extensive OGC standards document for geotiff linked above by @Armin-RS (https://www.ogc.org/standard/geotiff/). While it looks comprehensive and detailed (as one would expect from a standards document) I could not find the different map projections detailed with parameters etc. as in the old website. Thus it does not serve as a drop in replacement as @sadielbartholomew notes. The closest replacement might be the PROJ documentation, which is already in place in Appendix F. Suggestions for alternatives would be most welcome.

[JonathanGregory]

Lars has noted that this issue and #537 should be dealt with together, because both are about links in App F that should be revised.

[JonathanGregory]

Unless someone has time to deal with this very quickly i.e. before Monday, we won't be able to include it in CF1.12. I have prepared a PR for #537.