Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

Compatibility of map tiles between Territory view (iD Editor) and Observation view (Mapbox GL JS) #314

Closed
gmaclennan opened this issue Mar 20, 2020 · 0 comments

Comments

@gmaclennan
Copy link
Member

Describe the idea
This is a feature request for both the Territory View and Observation View to use the same offline map tiles to render the background map in each view, to avoid the need to create two sets of offline map tiles in two different formats, one for each view.

Currently we have two tile formats: raster tiles, which are used in the iD Editor view, and Mapbox Map styles, which are rendered by mapbox-gl-js as the background map for the Obseration View.

The Mapbox map styles work with either vector tiles or raster tiles (or both) and they need a style.json which defines how the tiles should be rendered, as well as rendered font sdf files if there are any labels, and png icons if there are any icons on the map.

Currently, rendering the same map background in both views requires two copies of the map tiles in different formats.

What's your role? Where and how do you currently use the application?
Dd Technical Director

What is your ideal step by step workflow?
A user adds a "Map Style" package to Mapeo Desktop, and they see it as the map background (option) in both the territory and observation views. (nb. currently the Observation view does not have an option to change the map background, but the territory view does).

Have you thought about what it might look like?
I think this task should be split into two, because one is easier than the other:

  1. Using plain raster tilesets in territory view

iD Editor uses plain raster tilesets to render the map background in the territory view. These are basically 256x256px raster tiles named like the original Google Maps tiles

These raster tilesets can be used by mapbox-gl-js but they require a simple wrapper style.json to work, e.g. a raster tileset for iD Editor hosted at "http://localhost:5005/landsat20150908/{z}/{x}/{y}.jpg" would need the following style.json:

{
  "version": 8,
  "name": "Satellite",
  "sources": {
    "my-tiles": {
      "tiles": ["http://localhost:5005/landsat20150908/{z}/{x}/{y}.jpg"],
      "type": "raster",
      "tileSize": 256
    }
  },
  "layers": [
    {
      "id": "background",
      "type": "background",
      "paint": { "background-color": "rgb(4,7,14)" }
    },
    {
      "id": "satellite",
      "type": "raster",
      "source": "my-tiles"
    }
  ]
}

If we generate automatically this json then we can serve the same raster tiles from iD to the observation view and render them in mapbox-gl-js

  1. Using Mapbox styled tiles from the observation view in the territory view

This is a little harder and there are two approaches:

a) Render the tiles in the server process of electron using mapbox-gl-native to render the vector tiles into raster tiles to serve to iD. It would probably make sense to use a pre-existing tile server like tileserver-gl to wrap mapbox-gl-native with a tile server that follows spec.

b) Add a mapbox-gl-js layer to iD editor and move it in sync with the iD map data. This might result in a slight lag between layers, and be more CPU intensive on the render thread, but it will result in map rendering that is more consistent (sometimes the mapbox-gl-native libs lag behind the mapbox-gl-js lib in terms of features and but fixes).

@digidem digidem locked and limited conversation to collaborators Oct 1, 2021
@ErikSin ErikSin closed this as completed Oct 1, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants