Offline usage of graphhopper web UI with vector tile maps

Triggered by a blogpost from Tobin Bradley about vector tile usage on http://fuzzytolerance.info/blog/2016/02/09/Vector-Tiles-Part-1/ I have added support for vector tile maps to the graphhopper web-ui, See https://github.com/ratrun/graphhopper/tree/master.

The fork includes everything needed to locally run a vector tile server and use such tiles in the graphhopper web UI. Free vector tiles input data are available on OSM2VectorTiles. If I made everything right, following instruction point 5. on https://github.com/ratrun/graphhopper/blob/master/docs/web/quickstart.md should get it running.

Please note that a fork of Tobin Bradley tile-server is included as a git sub-module. Therefore recursive sub-module update might be needed after a git switch.

In case that there is interest to include this to the official master, I will squash the commits and create a pull request.

I haven’t started searching yet. If anybody can recommend a vector style for a bicycle map I would be grateful.

I have added support for vector tile maps to the graphhopper web-ui

What needs to be added - just the URL to localhost? And we can add documentation for this but I would create a different entry ‘tiles’ or ‘deployment’ in index.md just stating the options for tiles or pointing this out in the deployment docs: Documentation: How to Deploy Graphhopper · Issue #593 · graphhopper/graphhopper · GitHub

In case that there is interest to include this to the official master

There might be interests from the community for a “fully offline routing project” similar to e.g. Atlas ( @devemux86 ) but we won’t include tiles or geocoding stuff in GraphHopper as it does not belong to routing IMO.

Note that vector and offline are not synonymous concepts.

Using vector maps (or tiles) does not mean necessarily they are offline. More that the rendering is not fixed (like with rasters) and can be changed with various styles on server provider or live on clients.

Offline is an added benefit for some vector implementations, depending on their advanced compact client storage.

Emux

@devemux86:

Note that vector and offline are not synonymous concepts.

Thank you. I was thinking a while about what tile to use, and this aspect got lost.

@karussell: I put the documentation into the wrong file. I was not aware about the subtile difference between the production quickstart https://github.com/graphhopper/graphhopper/tree/master/docs/web/quickstart.md and the developer quickstart graphhopper/docs/core/quickstart-from-source.md at master ¡ graphhopper/graphhopper ¡ GitHub, although I did stumble accross the second one in the past. I also see the benefits of adding a new tile section into index.md. I would consider this in a pull request accordingly.

What needs to be added - just the URL to localhost?

I do not understand this question, could you please elaborate? During thinking about what you could have meant, it came to my mind that in the production documentation it needs be mentioned that the part where a local tileserver is always queried about the areas which it serves should be de-activated in case that no vector tile-server shall get deployed. I have now put in a comment into the relevant code part at biketourplanner/web/src/main/webapp/js/config/tileLayers.js at master ¡ ratrun/biketourplanner ¡ GitHub

There might be interests from the community for a “fully offline routing project” similar to e.g. Atlas ( @devemux86 ) but we won’t include tiles or geocoding stuff in GraphHopper as it does not belong to routing IMO.

Yes I know. The commits contain elements, which are needed for such a project. Actually I was thinking about enhancing it into a webkit standalone application in the future. But as you say this becomes more and more a separted project then.

I think that the enhancements for both, the offline usage and the usage of a vector tile server, which by the way might of course also be located on the Internet, are separated clearly enough by using of the git sub-module method. The main benefit for graphhopper users is that the substential enhancements for the usage of vector tile servers would get included in the same way, as it is currently the case for raster tile servers.

The possibility of running a local vector tile server is interesting for developing users such as me, as it makes the usage, testing, and develpoing convenient in offline situations.

I do not understand this question, could you please elaborate?

I meant here: is it similarly integrated like a remote tile server?

Surely also interesting for us e.g. on fair trades or while traveling with deutsche bahn :wink: !

I meant here: is it similarly integrated like a remote tile server?

The usage of the checked in git sub-module vector tile server is more simple as it does not require any configuration.It should work out of the box as the code in the modified tileLayers requests the locally served areas with following fixed URL: http://localhost:3000/mbtilesareas.json . It is expected to return the list of available areas. For each area, a new layer gets created in the list of available map layers. In case that no reponse is received from this URL in time, no additiona vector layers get added to the list. So you’ll only get the currently included maps.

The integration of other remote tile servers works according to the same mechanism as for raster tile servers. I have not tested any, but it it should work at least in case that the remore tile server does not require any key. You need to manually apply modifications to the confiig/tileLayer.js file. In case that such a tile server requires a key, some minimal code modifications will be needed because for sake of simlicity I modified 4 code lines at lines 6-10 in biketourplanner/web/src/main/webapp/js/leaflet-mapbox-gl.js at master ¡ ratrun/biketourplanner ¡ GitHub .

Please give the instructions of 5. on biketourplanner/docs/web/quickstart.md at master · ratrun/biketourplanner · GitHub a try.:wink: I don’t want to copy these here such that I can improve them just in case something is missleading or does not work as described.

1 Like