Add links to crs-explorer in documentation

[jjimenezshaw]

Add links in the documentation to the webpage https://jjimenezshaw.github.io/crs-explorer/ , an open source page that lists all the coordinate reference systems from proj.db.

• Fully documented, including updating docs/source/*.rst for new API

[kbevers]

It's a cool site Javier but I'm not sure we want to "advertise" it in the docs. There's a bunch of other sites we probably should include as well then.

[rouault]

for the record, Javier contacted me offline about that and I found it was a good idea, as it is strongly related to PROJ (using it) and answering an often asked question

[kbevers]

My main concern here is that we end up in a situation similar to that of spatialreference.org. That is, a widely used (and linked to) ressource that looks quite official but hasn't been updated in years. It's not unlikely that this website at some point will lag behind (or even get abandoned). That's not a problem per se but we need to realise if it isn't getting updates and then remove the links from the docs. The FAQ doesn't see that much activity so it could easily be missed for a long period of time.

Then there's another concern about including external ressources in our docs. This is a project from a well-established contributor and I think we are all more inclined to be friendly towards that. Let's say the epsg.io people wanted to include a link, would we also be welcoming towards that? Maybe more of a principal and philosophical question.

With that said, I'm +0 on this one. If other regular contributors feel this adds more value than the (small?) risk of linking to out-of-date information this one should of course be merged.

[rouault]

An alternative would be to have that incorporated in PROJ itself through a github action that would refresh the crs explorer github repo automatically.

[jjimenezshaw]

Hi @kbevers I understand your concern about the continuity of the project. I can say that I will maintain it forever, but you should not trust me ;)

To minimize the work on every update there are github actions that generate all the files on demand. So I only have to change a number in a PR and merge it. (Last time also change PROJ_LIB to PROJ_DATA). But there is something to be done, true.
About other pages, I think this one is directly related to PROJ, and it says it clearly in the description. That was my reason to include it in PROJ documentation.

One option would be to include it in PROJ. However it should be a different repository. It automatically generates two files (wkt1 and wkt2) for every CRS. Today more than 13000 CRSs in proj.db. That's a lot! (it is intentional to have static access to the wkt strings without needing any browser interaction). Would it be worth it? I am using github pages for convenience and transparency. In case you include it, it can be on any other server, of course (in github you can access previous versions of the wkts or the main json file, for instance to compare them).

If I understand @rouault suggestion correctly (I am a beginner with github actions) it would be that a github action started in PROJ triggers something in my repository, right?

[rouault]

If I understand @rouault suggestion correctly (I am a beginner with github actions) it would be that a github action started in PROJ triggers something in my repository, right?

yes, basically move your regeneration scripts here with some changes, or git clone your repository in a github action run here, and push the result in your github repo. Something along the lines of what GDAL uses to refresh & deploy its documentation to github static pages at each push in its repository (PROJ does something similar for its doc but it is still in Travis CI): https://github.com/OSGeo/gdal/blob/8362c14ffd0f9282fc6bab3549511630ecf36f7f/.github/workflows/doc_build.yml#L98. That would involve your create a deploy github key that is added as a secret in this repository.
I'm only speaking about the technical side. Not about if we want to do that.

[kbevers]

How about this:

1. We adopt the CRS-explorer as a product of the PROJ project
2. The repo is moved to github.com/OSGeo/PROJ-CRS
3. The website is published on GitHub pages but using a domain like crs.proj.org

The technical side of things are more or less already sorted out above it seems. Would that be a sensible way to go about this?

[jjimenezshaw]

That sounds Ok. Looking about the usage of GitHub pages with a subdomain, it is not clear to me if the same user/organization can use it for multiple repositories (I guess that OSGeo would like to do it in other repos). That should be tested before.

[kbevers]

Looking about the usage of GitHub pages with a subdomain, it is not clear to me if the same user/organization can use it for multiple repositories

Shouldn't be a problem. I think GitHub pages is limited to one URL per repo. So a new repo would probably need to be set up but that's not a big deal.