Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement style.json resolution strategy a when handling the stable style url #2 #448

Closed
ximenabb opened this issue Jan 29, 2024 · 2 comments · Fixed by #459
Closed

Implement style.json resolution strategy a when handling the stable style url #2 #448

ximenabb opened this issue Jan 29, 2024 · 2 comments · Fixed by #459
Assignees

Comments

@ximenabb
Copy link

linked to Implement style.json resolution strategy a when handling the stable style url #439

Description
A frontend client is provided a single endpoint to use for retrieving a style.json definition (see #438). This endpoint should be handled by the backend, which performs the following resolution strategy to determine the style.json payload that's returned as the response:

1-Check if there's a offline static map with the style id of default (or whatever name we decide on). In practice, this means that there's a file that exists on the filesystem at ROOT/default/style.json, where ROOT is a provided directory where static custom maps are stored. If it exists, serve the style.json content as the response

2- if internet access is available, proxy a default online style of our choosing (e.g. using a mapbox style that requires our account's public access token)
3- if internet access is not available, serve an fallback map style that uses statically served local geojson files (e.g. https://github.com/digidem/mapeo-offline-map)

##Todo

  • if internet access is available, proxy a default online style of our choosing (e.g. using a mapbox style that requires our account's public access token)
@achou11
Copy link
Member

achou11 commented Jan 31, 2024

@ximenabb @EvanHahn I decided to spend time addressing this on my own since I was able to get most of the implementation done within a reasonable amount of time: #459

Feel free to either close this issue or let the PR close it when merged

@EvanHahn EvanHahn assigned achou11 and unassigned EvanHahn Jan 31, 2024
@achou11
Copy link
Member

achou11 commented Jan 31, 2024

Think it makes sense to close this in favor of #459 . Confusing to have this here

@achou11 achou11 closed this as not planned Won't fix, can't repro, duplicate, stale Jan 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants