Add (Overpass based) POI layer

[stesie]

This adds a (yet pretty simple) Overpass API based POI layer. To achieve this it integrates the MIT-licensed overpass-layer module, which runs overpass queries for the full bounding box (i.e. no "search along the route"), and uses a map marker quite like the existing POI marker (but with fa-search icon instead of fa-star). The popups list the OSM-style key/value pairs without much interpretation.

Overpass layers can be added in two ways:

• as default layers, with .geojson files residing statically below layers/overpass/
• as custom layers, that can be added dynamically by the user

Regarding the default layers I was wondering how many of those layers should be added (or if any at all), and how specific they should be e.g. to cycling needs (e.g. water sources of different kinds) or general purpose (one special kind of amenity per layer). This PR is currently leaning towards the latter and just adds a whole lot of amenities, shops & tourism osm features --- likely too many.

With the custom layers dialog I was also wondering, how things can be achieved in a user friendly way ... so far it's pretty cryptic (mainly since I refrained from just putting documentation into it or adding actual labels to the inputs). So instead of an URL you can put a Overpass Query (like e.g. (node[shop]['diet:vegan']['diet:vegan'!=no]; way[shop]['diet:vegan']['diet:vegan'!=no];);) in the URL input field, provide a layer name and click "add overpass query".

Both kinds of layers then can be checked on and off in the layer control like normal.

For the moment I'd consider this a minimal baseline, on which sub-sequent features could be built -- like choosing a color for the layer (which could be of interest to the gpx import layers as well)

refs #106

[stesie]

Just willing to give it a try? I've deployed this to my personal BRouter-Web instance at https://brouter.brokenpipe.de/
(however it has segment data for around Germany only)

[nrenner]

Thanks for the PR!

Some additional thoughts for potential (later) improvements (not critical for merging):

• The queries only include nodes and ways, which will miss some objects mapped as relations, e.g. this camp_site mapped both as site and multipolygon relation. Don't know about performance implications of always using the nwr shorthand. Otherwise taginfo shows relation usage per tag.
• I personally find the default styling of nodes as both CircleMarker and icon Marker superfluous and a bit too much
• My impression is, that the default Overpass instance is slow and overloaded these days, perhaps we should use an alternative instance?
• Some kind of loading indicator would be nice

[nrenner]

Regarding the default layers I was wondering how many of those layers should be added

Choosing relevant layers is hard. From a maintenance perspective I guess more is better (like your current selection), so I don't get frequent requests to add yet another layer.

With the custom layers dialog I was also wondering, how things can be achieved in a user friendly way

Not sure. Maybe by putting the current input placeholder as help text below like in the profile options tab and adding an example for Overpass, that can be copied this way (unlike the placeholder). Don't know if something like overpass-wizard would help.

edit: clarify "more" doesn't mean more than currently implemented

[stesie]

I completely agree with the minZoom requirement. overpass-layer's default actually is 16, which felt a bit too strict. Yet no limit at all might well be too lax :)

Regarding camp_site (and others) being mapped as relations, when creating all the geojson files I had a close look to OSM wiki, e.g. https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dcamp_site, which states that tourism=camp_site should not be used on ways and relations. And so on for the other files. But as you pointed out, there are e.g. camp sites that are mapped as relations, and they probably should be found as well. There's even a bunch of amenity=bench which are mapped as relations. Hence I've just changed all the search defintions to always use nwr[] no matter what. (unaware of the performance impact, but it doesn't feel worse with a couple of tries)

Regarding the marker symbol I also agree, so plain nodes are now depitected by a simple circle marker, and both areas as well as multi polygon relations by their outline.

I like the idea to split the custom layers dialog's placeholder into label and helptext parts, especially to keep the helptext visible. So I've just quickly changed that as well.

Regarding the loading indicator I need to have a closer look someday. To be honest I've been missing it myself from time to time already. Yet from a brief look into the documentation it doesn't (yet) emit the signals necessary to achieve this.

[nrenner]

Regarding the marker symbol I also agree, so plain nodes are now depitected by a simple circle marker, and both areas as well as multi polygon relations by their outline.

Not sure, but I would have tended to do it the other way round and just not show the CircleMarker for nodes, but keep both marker and outline for ways/areas:

• especially buildings get reduced to a few pixels and are harder to see when zooming out, so a marker helps, but the outline is useful additional information as well (Overpass Turbo has an option to turn small features into CircleMarkers on lower zooms)
• a future improvement might be to distinguish multiple Overpass layers by specific icons in the markers

Don't know how to do that with overpass-layer though, there seems to be a nodeFeature style option, see parks demo and overpass-frontend OverpassNode.js.

Regarding the loading indicator [...] Yet from a brief look into the documentation it doesn't (yet) emit the signals necessary to achieve this.

In the parks demo I just saw onLoadStart and onLoadEnd handlers.

Let me know if you want to leave it as is for now or add some more changes to this PR. I'm fine with merging as is.

[stesie]

I've just added a simple loading indicator, based on the existing messaging approach. Yet I didn't want to accidentally wipe out possibly visible error messages, hence I've wrapped the #message container to allow for a secondary alert to be shown right below it.

And thanks for pointing out those two event handlers exist, I wonder where I was looking at yesterday without noticing them. Whatever ...

Regarding multiple Overpass layers, so far I have been thinking of using separate colours instead of icons, so users could control the colour of either markers, circles or polygons. Having a colour picker feels more intuitive then adding some kind of icon selector, and also would be reusable for e.g. imported gpx route layers.

[nrenner]

Thanks for your contribution!

[nrenner]

I made some minor additions in #389.

Regarding multiple Overpass layers [...]. Having a colour picker feels more intuitive then adding some kind of icon selector,

My idea was not to let the user select, but to extend the overpass layer definitions with icons that would show both in the optional layers tree and in the markers for a selected layer. Ideally some existing icon associations and also translations could be used, e.g. from editor presets, see also #306.

Example from id-tagging-schema presets.json:

    "tourism/camp_site": {
        "icon": "maki-campsite",

which would be maki campsite-15.svg: