Splitting out the list of providers in a standalone JSON file
SylvainCorlay opened this issue · 12 comments
Currently, the available providers are listed in a JavaScript object that is defined inline in the source code of leaflet-providers.
It would be really useful to make that information available directly in a JSON file that could be used from other projects. For example, xyzservices extracts that information from leaflet-provider.js to make the same information available to Python. Xyzservices has some adoption in the scientific Python ecosystem (Geopandas, ipyleaflet, contextily, leafmap, bokeh, and others) - meaning that this project has in fact a lot of indirect adoption...
This separate JSON file could even be published independently of the leaflet-providers JS source, which would probably make it valuable for other users.
Hi @SylvainCorlay nice idea, we just have to find a way to generate automagically this JSON file from the repo. Do you have any hint for that ? @jieter any thoughts on this ?
Hi @brunob, we already have that magic in xyzservices
. We scrape your JS to get that JSON but the result is slightly adapted to work within our use case. But the Python code for that is here https://github.com/geopandas/xyzservices/blob/main/provider_sources/_parse_leaflet_providers.py and a resulting JSON here https://github.com/geopandas/xyzservices/blob/main/provider_sources/leaflet-providers-parsed.json.
@martinfleis do you think we can use your script on our repo with a github ci or anything like that ?
@brunob Yeah, we do that within this GHA https://github.com/geopandas/xyzservices/blob/main/.github/workflows/update_providers.yaml using this makefile
Nice, let's hope that @jieter could look into it or propose an alternative method :)
We could generate this JSON as a one-off, include the JSON in your repository, and then read the JSON from your JavaScript instead of having the object hard coded in the code base.
This would make it a single source of truth.
Yes, it would be nice to maintain the list in a machine readable format, and generate leaflet-providers.js
from it + a template. I am not sure about JSON though. In the current definitions, we use some comments: (1 2 3 4), which I think is a valuable capability not possible in classic json.
Other options would be JSONC, but that would require consumers of the file to use non-standard parsers too.
Any suggestions?
What about using YAML instead if we need comments? That feels as a bit more standard solution than JSONC.
The big advantage of JSON is that you can parse it from either Python or JS without a third-party dependency.
+1 for JSON too
One option to keep comments in the JSON without using non-standard parsers would be to include an optional note
or comment
field with a string that is currently in the comment and ignore it while parsing the JSON to show it on your website or within xyzservices.