All ways, way types and points of interest in this application come from OpenStreetMap. From them we compute our own values — how noisy, how green and how worth seeing it is along a way — and we cut the tiles of the map from them. Both are derivative databases in the sense of the Open Database License. Our values live in databases of their own and are linked to OpenStreetMap solely by the way number. The licence requires us to disclose the method (section 4.6b). It is described as follows.
Every OSM object with a highway tag — including the noisy roads themselves. Everything is computed in metres. We also average the same values on a coarse grid with a cell width of 0.0028 degrees, for questions that concern no single way.
From OpenStreetMap areas we form five categories. Forest: landuse=forest, natural=wood. Open land: farmland, meadow, orchard, vineyard, grass, allotments, grassland, heath, scrub, wetland, beach. Settlement: residential, industrial, commercial, retail, garages, construction. Urban green: park, golf_course, common, recreation_ground, dog_park, cemetery, village_green, grave_yard, plus garden only with explicit public access. Protected area: nature_reserve, national_park. The value per category is the share of the way's length that lies inside such areas.
Roads count as noise sources, with an assumed range: motorway 1000 m, trunk road 800 m, primary road 500 m, secondary road 300 m; in addition airfields 2000 m (only sites of 1 km² or more), motorsport venues 1500 m, shooting ranges 1500 m, quarries 500 m. Tunnels do not count. Railways do not count — trains pass rarely. The value falls quadratically with distance: 100 × (1 − distance / range)². Forest between source and way dampens it: every metre of forest on the line of sight counts as three metres of distance. This is computed for the four nearest sources per way; the harshest one applies. We determine the same value per section of a way as well — that yields the figure “longest noisy stretch in one piece”. The water value works the same way, but linearly: rivers and canals 100 m, lakes 100 m from 10 000 m² of area, streams 50 m.
OpenStreetMap nodes and areas are selected using the values of tourism, historic, natural, waterway and amenity listed below. Other values of these tags do not qualify an object for inclusion.
For areas, all component polygons of 1 km² or more are excluded first. If several component polygons with the same OSM identifier remain, the largest is retained; no further ordering is specified for equally large polygons. Its centroid is calculated in ETRS89/UTM32N (EPSG:25832) and then transformed to geographic coordinates (EPSG:4326). OSM nodes retain their location. The waterway tag is evaluated for nodes only.
Each object receives exactly one category: the first matching rule in the following order wins. Objects matching no rule are excluded. Categories selected through amenity form the refreshments group; all others form the sights group. Refreshment venues without a name tag are excluded; sights do not require a name. An OSM node and an OSM area object representing the same place remain separate entries.
Waterfall 100 — waterway=waterfall.
Castle 100, including palaces — historic=castle.
Peak 90 — natural=peak.
Viewpoint 80 — tourism=viewpoint.
Ruin 60 — historic=ruins.
Monument 60 — historic=monument.
Cave 60 — natural=cave_entrance.
Zoo 60 — tourism=zoo.
Attraction 60 — tourism=attraction.
Museum 50 — tourism=museum.
City gate 50 — historic=city_gate.
Fortification 50 — historic=fort.
Archaeological site 40 — historic=archaeological_site.
Spring 40 — natural=spring.
Artwork 30 — tourism=artwork.
Picnic site 30 — tourism=picnic_site.
Memorial stone 20 — historic=memorial.
Beer garden 70 — amenity=biergarten.
Restaurant 60 — amenity=restaurant.
Café 50 — amenity=cafe.
Pub 40 — amenity=pub.
Fast food 30 — amenity=fast_food.
Ice cream shop 40 — amenity=ice_cream.
The range for gastronomy is therefore 30 to 70.
The additional input is QRank (Wikidata page views, CC0): the file qrank.csv.gz from qrank.wmcloud.org, with the columns Entity and QRank. Each scoring run uses the data snapshot available to it. The OSM wikidata tag is matched exactly against Entity.
For each selected POI with a matching QRank entry, L = ln(1 + QRank) is calculated; ln is the natural logarithm. The 5th percentile P05 and the 99th percentile P99 are calculated from these L values, using linear interpolation as in PostgreSQL percentile_cont. Each matching POI counts once, even if several POIs share the same Wikidata identifier. POIs without a matching QRank entry are excluded from the percentiles.
The unrounded prominence score Q is:
Q = 100 × min(1, max(0, (L − P05) / (P99 − P05))).
Q therefore lies between 0 and 100. If the QRank file or a matching entry is missing, or the percentile bounds are identical, Q = 0. Q is also stored separately, rounded to an integer.
The three parts are weighted 40 / 40 / 20: category base score K, prominence score Q and photo density F from Wikimedia Commons. Photo density is prepared, but currently 0. The overall score uses the unrounded value of Q:
Total = round(0.4 × K + 0.4 × Q + 0.2 × F).
Only this result is rounded to an integer; round refers to the PostgreSQL function. Missing QRank or photo values do not cause the weights to be redistributed.
When planning a loop you can have car parks nearby listed. For this we take every object tagged amenity=parking from OpenStreetMap, as a node or as an area; for areas we use the centroid, as we do for points of interest. Parking strips along the kerb are left out, that is parking=street_side, lane, on_kerb and half_on_kerb — they are not a place you drive to. An object without a parking tag stays in.
For every car park we compute three attributes of our own:
Trailhead parking — the object carries hiking=yes, or its name contains Wanderparkplatz or Wanderer-Parkplatz (German for trailhead parking).
On a hiking route — at most 100 m from a way belonging to a relation tagged route=hiking.
In green space — at most 50 m from an area in the categories woodland or urban green described above.
The access class is formed from access as it is for the tiles (see “The map”); closed car parks are not offered. Customer parking and car parks tagged fee=yes are also left out until you allow them in the interface. A car park with no fee tag counts as unknown and always stays in the list.
From these attributes a score is computed for each search. Exactly one class counts, the highest that applies: trailhead parking 1000, on a hiking route 800, otherwise 500. Then two bonuses: 250 if the car park lies in green space, and one for proximity to the chosen point — 300 below 100 m, 150 from 100 up to 300 m, none beyond that. The result is divided by a value that grows with distance: full hundreds of metres, plus one, times 0.1, plus one. At the chosen point the divisor is therefore 1.1, at 800 m it is 1.9, at 2000 m 3.1, at 4000 m 5.1. The 1000 nearest car parks within 4000 m are scored; the six with the highest score are shown. This score is held in no database: it depends on the chosen point and is computed afresh for every request.
The vector tiles of the map are built from the same extract with tilemaker following the Shortbread tile schema, extended by three layers of our own: hiking trails (ways in relations with route=hiking or route=foot, plus individual ways carrying sac_scale or trail_visibility), summits (natural=peak, saddle, volcano) and car parks (amenity=parking, as a node or as an area). The first two layers select from OpenStreetMap and add no value of our own.
For car parks we add a classification of our own. From the access tag we form three access classes: open (no access tag, or yes, permissive, public, designated), customer parking (customers, permit, destination and the combined values customers;private and private;customers) and closed (any other value, such as private or no). The map shows the first two classes and omits the third; the class lives in the tile, not in OpenStreetMap.