Migrate from Mapbox to OpenLayers

[easbar]

Still not decided whether or not we should do this, but if yes we should probably do it soon.

Some pros and cons compared to Mapbox (just considering the issues we ran into so far)

Pro:

• faster raster tile rendering
• no blurry raster tiles (Blurry appearance of raster tiles #156) when constrainResolution is enabled
• very active development compared to Mapbox, which is only developed under a proprietary license now
• was able to fix the long press issue on iOS
• (minor) commented out layers seem to work out of the box (Enable commented out map layers #57)

Con:

• slower vector tile rendering (important for /spt, not so much for /mvt)
• if we consider vector tiles to be too slow with OL we cannot take advantage of some of the corresponding benefits, like custom map styling. Still we could use the Mapbox GL JS integration of OL.
• cannot pitch/tilt the map -> try PerspectiveMap extension

I started to explore this migration here: https://github.com/graphhopper/graphhopper-maps/tree/ol_exp
The live instance is running here: http://gh-maps-react.s3-website.eu-central-1.amazonaws.com/ol_exp/
See also the discussion here: #132

This is the current list of todos for the ol_exp branch:

• fix remaining svg marker issues, see commit message: f2213e2, but at least the cursor appearance is now fixed
• make markers draggable
• add context menu (including the long touch handler)
• put back path details layer
• add map attributions
• allow click selection of the paths
• restrict map zoom/pan so we cannot pan around the globe
• put back view store test
• use same mouse cursors for map as in master
• bug/issue: when refreshing map with a route the map flickers and sometimes even ends up being zoomed out all the way to world view -> this is caused by a bug in master (Map zooms to both the info bbox and the route bbox if url contains points #162)
• test (also on mobile)

[easbar]

I also tried a different way to handle the map state that could be also useful even if we kept using Mapbox (and replace the react wrapper): Basically I treat the map more like a 'store' rather than a UI component. The map object has the map state (like the camera position etc.) and is created once in MapStore. Then there is the MapComponent which is the actual UI component representing the map. It uses the map from MapStore and (more or less) only attaches it to a div container. The map layers are separate react components that also depend on the MapStore so they can attach the corresponding layers and (hopefully soon) also interaction handlers to the map. See BackgroundLayer for example. Actions that are supposed to change the camera position like SetSelectedPath are handled in the reduce function of MapStore where we have direct access to the map view. This way there is no need to manage the camera state outside of the map as we currently do in ViewportState in master. Not entirely sure about this yet, but so far it seems pretty useful and it certainly feels better to deal with the map directly instead of using a wrapper like react-map-gl that we do not really understand :) Will be interesting to see if this concept also allows easily adding click interactions for the different map layers.

[Janekdererste]

I think this is comparable to the Qwant people, where the map component lives outside of the react app. It listens for custom events which are issued by the react app and updates the map accordingly. This could be seen, in our case, as a store with a visual output.

[easbar]

I think this is comparable to the Qwant people, where the map component lives outside of the react app. It listens for custom events which are issued by the react app and updates the map accordingly. This could be seen, in our case, as a store with a visual output.

Ok, interesting. I did not really check the Erdapfel code, but does this pattern make sense to you?

[Janekdererste]

but does this pattern make sense to you?

Actually I don't really know yet. I think I would maybe not make it an actual store but we can pass other types than stores to the Dispatcher as well. So one could still listen for actions and update the internal map state accordingly. Let's talk it through via phone :-)

[boldtrn]

Thanks for providing both versions to compare.

In Firefox (also with V94) the vector tile rendering, both of Mapbox and OL weren't great. I personally think Mapbox performs better, but both are far from great :(

In Chrome, Mapbox performs a lot better. Mapbox works without any real issues and is fun to use. OL still feels clunky, freezes sometimes for a short period.

I tested a three different devices, all with the same result.

no blurry raster tiles (Blurry appearance of raster tiles #156) when constrainResolution is enabled

This might have been fixed with the latest version of Maplibre: maplibre/maplibre-gl-js#637

[easbar]

Thanks for testing!

In Chrome, Mapbox performs a lot better. Mapbox works without any real issues and is fun to use. OL still feels clunky, freezes sometimes for a short period.

Yes, same for iOS/Safari on my phone. With OL the vector tiles aren't really nice to use. Then again we noticed earlier that Maptiler seems to be much slower than Mapbox (at least for the styles we use). But anyway Mapbox is clearly faster for the vector tile providers we currently use (Mapbox+Mapilion). And by 'faster' I mean faster when zooming & panning the map (this is what I just tried). That does not say the initial page load (#132) is fast. This is currently hard to test, because of #162.

This might have been fixed with the latest version of Maplibre: maplibre/maplibre-gl-js#637

But isn't this only about high-resolution tiles? The blurry tiles I was referring to in that issue were just the normal tiles from openstreetmap on my Laptop.

So yes, one important factor to decide whether we should use Mapbox or Openlayers is whether or not we should/want to use vector tiles for the map background. If you ask me we don't need this and can just go with raster tiles and OpenLayers. Or at least I haven't heard any major arguments that convinced me that vector tiles are important (for GH maps) ;)

[boldtrn]

And by 'faster' I mean faster when zooming & panning the map (this is what I just tried). That does not say the initial page load (#132) is fast.

Yes, that's what I was referring to as well, good to clarify.

But isn't this only about high-resolution tiles? The blurry tiles I was referring to in that issue were just the normal tiles from openstreetmap on my Laptop.

I think raster tiles are just images that are shown on the screen. So to "fix" blurry images there are two options. Either you use high-res tiles or you load more tiles (like going one zoom level up and loading 4x the tiles). I think OSM isn't offering high-res tiles at the moment.

If you ask me we don't need this and can just go with raster tiles and OpenLayers.

Yes sure, if you don't need vector tiles, then I would go with OpenLayers or Leaflet straight away, no need to add hundreds of kb of dependencies and more complicated API if you don't need it :). Maplibre/Mapbox is vector tiles first.

[karussell]

Either you use high-res tiles or you load more tiles

I think maplibre/mapbox has the problem that fractional zooms are accepted for raster tiles and there seems to be no option to disable this, so they will be blurry even if high res.

[easbar]

Yes exactly. The tiles can be blurry because they are, well, blurry. Or they can become blurry when they are shown at the wrong resolution. This happens for example when they are over-zoomed. For OpenLayers the constrainResolution option prevents the over-zooming and only uses the (discrete) zoom levels for which there are tiles.

However, the bluriness issue seems to be different on mobile. I feel like the OSM tiles (no 2x) are a bit blurry on my iPhone. I thought this is because of the high resolution of my phone's screen. But for some reason the 'Kurviger Liberty' tiles also seem blurry on my phone (for the OL branch). On master/Mapbox this is not the case, and neither for GH maps/Leaflet. @boldtrn maybe you know why this is? Maybe we are missing some settings still?

[boldtrn]

I think maplibre/mapbox has the problem that fractional zooms are accepted for raster tiles and there seems to be no option to disable this, so they will be blurry even if high res.

Ah yes, fractional zooms might be indeed the source of this.

But for some reason the 'Kurviger Liberty' tiles also seem blurry on my phone (for the OL branch).

Have you enabled the x2 option? Kurviger Liberty is available as high-res tiles.

[easbar]

Have you enabled the x2 option? Kurviger Liberty is available as high-res tiles.

Yes, I thought so:

graphhopper-maps/src/stores/MapOptionsStore.ts

Lines 123 to 137 in 29f749b

	const kurviger: RasterStyle = {
	name: 'Kurviger Liberty',
	type: 'raster',
	url: [
	'https://a-tiles.mapilion.com/raster/styles/kurviger-liberty/{z}/{x}/{y}@2x.png?key=' + kurvigerApiKey,
	'https://b-tiles.mapilion.com/raster/styles/kurviger-liberty/{z}/{x}/{y}@2x.png?key=' + kurvigerApiKey,
	'https://c-tiles.mapilion.com/raster/styles/kurviger-liberty/{z}/{x}/{y}@2x.png?key=' + kurvigerApiKey,
	'https://d-tiles.mapilion.com/raster/styles/kurviger-liberty/{z}/{x}/{y}@2x.png?key=' + kurvigerApiKey,
	'https://e-tiles.mapilion.com/raster/styles/kurviger-liberty/{z}/{x}/{y}@2x.png?key=' + kurvigerApiKey,
	],
	attribution:
	osmAttribution +
	',&copy; <a href="https://kurviger.de/" target="_blank">Kurviger</a> &copy; <a href="https://mapilion.com/attribution" target="_blank">Mapilion</a> <a href="http://www.openmaptiles.org/" target="_blank">&copy; OpenMapTiles</a>',
	maxZoom: 22
	}

Or is there anything else we need to do? Do we need to use the tileSize option for the OL View?

[boldtrn]

The url seem correct :). I am not sure if you need to set anything else in OL.

[easbar]

Ok thanks we need to check this.

This is how Kurviger Liberty currently looks using OpenLayers on my iPhone:

And this is how it looks on Mapbox:

For Leaflet/GH maps 1: it is even slightly better (maybe):

The OSM tiles are looking perfect on my Laptop, but not as nice on my phone, not even for GH maps 1:

[easbar]

@boldtrn OL has this tilePixelRatio option:

The pixel ratio used by the tile service. For example, if the tile service advertizes 256px by 256px tiles but actually sends 512px by 512px images (for retina/hidpi devices) then tilePixelRatio should be set to 2.

When I set this to 2 the tiles look sharp on my phone, see here: http://gh-maps-react.s3-website.eu-central-1.amazonaws.com/ol_exp_tile_size/?profile=bike&layer=Kurviger+Liberty
Can you comment on the tile size and pixel ratio of the Kurviger Liberty tiles?