CAMPERADA: HERSTELLUNGSWEG DER AUS OPENSTREETMAP ABGELEITETEN DATENBESTÄNDE How Camperada derives its datasets from OpenStreetMap Stand: 28.10.2026 (Abschnitt 7 ergänzt; die Abschnitte 0 bis 6 sind unverändert vom 29.09.2026) Deutsch Diese Datei beschreibt nach Ziffer 4.6(b) der Open Database License (ODbL) 1.0, wie Camperada seine Datenbestände aus OpenStreetMap herstellt: welche Daten abgefragt und wie sie ausgewählt, aufbereitet und zusammengeführt werden. Die Daten stammen aus OpenStreetMap, © OpenStreetMap-Mitwirkende, und sind unter der ODbL 1.0 lizenziert (https://www.openstreetmap.org/copyright). Die daraus abgeleiteten Bestände stehen unter derselben Lizenz. Kontakt: über die Angaben im Impressum (https://camperada.de/impressum). English In accordance with section 4.6(b) of the Open Database License (ODbL) 1.0, this file describes how Camperada derives its datasets from OpenStreetMap: which data is queried and how it is selected, processed and combined. The data comes from OpenStreetMap, © OpenStreetMap contributors, and is licensed under the ODbL 1.0 (https://www.openstreetmap.org/copyright). The derived datasets are available under the same licence. Contact: see the imprint (https://camperada.de/impressum). (The detailed description below is in German. Queries, tags and values are given verbatim.) INHALT 0 Gemeinsame Grundlagen 1 Plätze: Campingplätze, Wohnmobilstellplätze, Entsorgungsstationen 2 Fähren: Fährlinien und Häfen 3 Sehenswertes (OpenStreetMap und Wikidata) 4 Umweltzonen (Teil aus OpenStreetMap) 5 Mautstraßennetz 6 Routing-Graph 7 Durchfahrts-Check: Wege mit Höhen-, Breiten-, Gewichts- oder Längenbeschränkung 8 Bezug einer Kopie ========================================================================================== 0 GEMEINSAME GRUNDLAGEN ========================================================================================== Abfrageweg. Die Bestände 1 bis 4 werden über QLever abgefragt, einen SPARQL-Dienst der Universität Freiburg, der den OSM-Planeten als Index führt: https://qlever.dev/api/osm-planet Jede Abfrage geht als HTTP-POST mit dem Inhaltstyp application/sparql-query an diesen Endpunkt, die Antwort kommt als CSV (Accept: text/csv). QLever stellt OSM-Objekte als IRIs dar (https://www.openstreetmap.org/node/..., .../way/..., .../relation/...) und Tags als Prädikate der Form . Die Bestände geben den OSM-Stand wieder, den QLever zum Zeitpunkt des Abrufs geladen hat; er kann einige Wochen hinter der OSM-Datenbank liegen. Das Mautstraßennetz (5) wird über die Overpass API abgefragt. Zeilenumbrüche und Einrückungen in den unten wiedergegebenen Abfragen dienen nur der Lesbarkeit. Objekttypen. "Alle Typen" heißt: Nodes, Ways und Relationen, soweit QLever für sie eine Geometrie führt. Kennungen. Wo ein Bestand die OSM-Kennung führt, ist sie verkürzt: aus node/123 wird n123, aus way/123 wird w123, aus relation/123 wird r123. Zentroid. Wo ein Bestand je Objekt einen Punkt führt, berechnet QLever ihn in der Abfrage mit geof:centroid aus der Geometrie des Objekts. Liefert die Abfrage für ein Objekt keinen Punkt, nimmt das Skript in den Beständen 1 und 3 die Mitte des umschreibenden Rechtecks aller Koordinaten, in Bestand 2 das erste Koordinatenpaar. Koordinaten stehen in der Reihenfolge Länge, Breite und werden, wo nicht anders angegeben, auf 5 Nachkommastellen gerundet. Plausibilitätsschwellen. Jedes Skript prüft die Menge seines Ergebnisses gegen eine Mindestzahl. Liegt es darunter, schreibt es nichts, und der bisherige Bestand bleibt in Gebrauch. Reihenfolge. Plätze, Fähren und Sehenswertes werden vor dem Schreiben nach Rasterzellen von 1 Grad sortiert (erst abgerundete Breite, dann abgerundete Länge, dann Länge). Das dient nur der Kompression und ändert keinen Inhalt. Speicherung. Die Bestände 1 bis 4 werden als JSON gespeichert und mit gzip (Stufe 9) gepackt, das Mautstraßennetz als ungepacktes JSON. Aktualisierung. Ein Hilfsprozess (planer/scripts/refresh-data.mts) läuft bei jedem Start des Planer-Stacks einmal durch. Er prüft das Alter jedes Bestands und führt das zugehörige Skript erneut aus, sobald der Bestand älter ist als seine Haltbarkeit (je Bestand unten genannt; die Voreinstellung ist per Umgebungsvariable änderbar). Scheitert ein Lauf, bleibt der bisherige Stand in Gebrauch. Unabhängig davon wird der mit der Anwendung ausgelieferte Stand von Hand mit denselben Skripten erneuert. Hilfsdaten, die nicht aus OpenStreetMap stammen. Die Länderzuordnung in 4 und 5 nutzt vereinfachte Ländergrenzen aus Natural Earth (gemeinfrei), abgelegt in planer/lib/tollcheck/countries.json. ========================================================================================== 1 PLÄTZE: CAMPINGPLÄTZE, WOHNMOBILSTELLPLÄTZE, ENTSORGUNGSSTATIONEN ========================================================================================== Zweck. Der Planer zeigt Campingplätze, Wohnmobilstellplätze und Entsorgungsstationen auf der Karte und in der Suche rund um die Halte einer Route. Gesucht wird im eigenen Bestand statt bei einem fremden Dienst. Skript: planer/scripts/update-campsites.mts (npm run campsites:update) Ergebnis: planer/lib/campsites/places.json.gz Quelle: QLever, https://qlever.dev/api/osm-planet, weltweit ohne räumliche Grenze Auswahl. Drei Arten, jede über genau ein Tag, Objekte aller Typen: Code Art Tag 0 camp_site tourism=camp_site 1 caravan_site tourism=caravan_site 2 dump_station amenity=sanitary_dump_station Weitere Ausschlüsse gibt es nicht. Objekte ohne verwertbare Position fallen weg. Übernommene Merkmale. Nur diese 23 Schlüssel, alle übrigen Tags entfallen: name, website, contact:website, phone, contact:phone, stars, operator, opening_hours, capacity, caravans, tents, motorhome, sanitary_dump_station, power_supply, drinking_water, shower, internet_access, fee, reservation, addr:city, addr:street, addr:housenumber, addr:postcode Abfragen. Je Art zwei, zusammen sechs. Wiedergegeben für camp_site. Abfrage 1, Positionen: PREFIX osmkey: PREFIX geo: PREFIX geof: SELECT ?o ?c WHERE { ?o osmkey:tourism "camp_site" . ?o geo:hasGeometry/geo:asWKT ?wkt . BIND(geof:centroid(?wkt) AS ?c) } Abfrage 2, Merkmale: PREFIX osmkey: SELECT ?o ?p ?v WHERE { ?o osmkey:tourism "camp_site" . VALUES ?p { } ?o ?p ?v . } Für die beiden anderen Arten lautet die erste Zeile im WHERE-Block beider Abfragen ?o osmkey:tourism "caravan_site" . (caravan_site) ?o osmkey:amenity "sanitary_dump_station" . (dump_station) Aufbereitung. * Position: der Zentroid aus Abfrage 1, gerundet auf 5 Nachkommastellen. * Mehrfach-Tagging: Gehört ein Objekt zu mehreren Arten, gilt die Rangfolge caravan_site vor camp_site vor dump_station. Ein Platz mit eigener Entsorgungsstation bleibt also ein Platz. * Merkmale werden nur für Objekte mit Position übernommen. Zeilenumbrüche in einem Wert werden zu Leerzeichen, Leerraum am Anfang und Ende wird entfernt, leere Werte fallen weg, Werte über 200 Zeichen werden auf die ersten 200 Zeichen gekürzt. * Aus anderen Quellen wird nichts ergänzt. * Plausibilitätsschwelle: mindestens 150.000 Plätze. Ergebnisformat. JSON-Objekt mit den Feldern generated Datum des Laufs (JJJJ-MM-TT) source Quellenangabe format Kurzbeschreibung des Zeilenformats count Zahl der Plätze places je Platz eine Liste [id, kind, lon, lat, name, tags] id verkürzte OSM-Kennung kind 0 camp_site, 1 caravan_site, 2 dump_station name Wert von name, sonst leer tags Objekt mit den übrigen übernommenen Merkmalen; fehlt, wenn es keine gibt Aktualisierung. Haltbarkeit 30 Tage. ========================================================================================== 2 FÄHREN: FÄHRLINIEN UND HÄFEN ========================================================================================== Zweck. Der Routendienst meldet, dass und wo eine Route eine Fähre nutzt, aber nicht welche. Der Bestand ordnet einem Fährabschnitt geometrisch die nächsten benannten Häfen an beiden Enden und die passende Fährlinie mit Name, Betreiber und Website zu. Skript: planer/scripts/update-ferries.mts (npm run ferries:update) Ergebnis: planer/lib/ferrydata/inventory.json.gz Quelle: QLever, https://qlever.dev/api/osm-planet, weltweit ohne räumliche Grenze Auswahl. * Linien: Ways mit route=ferry. Nodes und Relationen mit route=ferry werden nicht als Linie aufgenommen (Filter auf Way-IRIs in den Abfragen 1 bis 3). * Ergänzende Merkmale: Relationen mit route=ferry, in denen der Way Mitglied ist. * Häfen: Objekte aller Typen mit amenity=ferry_terminal und einem Tag name. Ausschlüsse. * Ways mit weniger als zwei Koordinaten. * Ways, deren erster und letzter Punkt weniger als 0,03 km auseinanderliegen (Entfernung nach der Haversine-Formel, Erdradius 6371 km): Schleifen oder Datenfehler. * Ways mit motor_vehicle=no oder motor_vehicle=private. Geprüft wird nur das Tag am Way selbst. * Häfen, deren Name nach der Bereinigung leer ist. Abfragen. Vier, alle mit demselben Kopf: PREFIX osmkey: PREFIX osmrel: PREFIX geo: PREFIX geof: Abfrage 1, Geometrie der Linien: SELECT ?o ?wkt WHERE { ?o osmkey:route "ferry" . ?o geo:hasGeometry/geo:asWKT ?wkt . FILTER(STRSTARTS(STR(?o), "https://www.openstreetmap.org/way/")) } Abfrage 2, Merkmale der Ways: SELECT ?o ?p ?v WHERE { ?o osmkey:route "ferry" . VALUES ?p { } ?o ?p ?v . FILTER(STRSTARTS(STR(?o), "https://www.openstreetmap.org/way/")) } Abfrage 3, Merkmale der Fährrelationen: SELECT ?o ?rel ?p ?v WHERE { ?o osmkey:route "ferry" . ?rel osmrel:member ?m . ?m osmrel:member_id ?o . ?rel osmkey:route "ferry" . VALUES ?p { } ?rel ?p ?v . FILTER(STRSTARTS(STR(?o), "https://www.openstreetmap.org/way/")) } Abfrage 4, Häfen: SELECT ?o ?c ?name WHERE { ?o osmkey:amenity "ferry_terminal" . ?o osmkey:name ?name . ?o geo:hasGeometry/geo:asWKT ?wkt . BIND(geof:centroid(?wkt) AS ?c) } Aufbereitung. * Von jeder Linie werden nur der erste und der letzte Punkt ihrer Geometrie übernommen, gerundet auf 5 Nachkommastellen. * Texte (name, operator, website, motor_vehicle, Hafennamen): Leerraum wird zu einem Leerzeichen zusammengezogen und an den Rändern entfernt, Werte über 120 Zeichen werden auf 120 Zeichen gekürzt, leere Werte fallen weg. * name, operator und website: Maßgeblich ist der Wert am Way. Fehlt er, gilt der Wert der Fährrelation. Liegt ein Way in mehreren Fährrelationen, wird je Schlüssel der Wert genau einer Relation übernommen, ausgewählt über die Relationskennung (vorgesehen ist die kleinste), damit wiederholte Läufe dasselbe Ergebnis liefern. * website wird nur als http- oder https-Adresse übernommen. Ein Wert mit Leerzeichen wird verworfen. Ein Wert ohne http:// oder https:// wird nur übernommen, wenn er auf den regulären Ausdruck ^[\w.-]+\.[a-z]{2,}(?:[/:?#]|$) passt (Groß- und Kleinschreibung egal); ihm wird dann https:// vorangestellt. Was sich danach nicht als http- oder https-Adresse lesen lässt, wird verworfen. * Häfen: Position ist der Zentroid aus Abfrage 4, gerundet auf 5 Nachkommastellen. Je Objekt zählt die erste Ergebniszeile. * Plausibilitätsschwellen: mindestens 15.000 Linien (nach Abzug der Ways ohne Kraftfahrzeuge) und mindestens 15.000 Häfen. Ergebnisformat. JSON-Objekt mit den Feldern generated (Datum des Laufs, JJJJ-MM-TT), source, format, terminalCount, lineCount und terminals je Hafen [id, lon, lat, name] lines je Linie [id, lon1, lat1, lon2, lat2, name, operator, website]; lon1, lat1 ist der erste, lon2, lat2 der letzte Punkt des Ways; ein leeres Feld heißt unbekannt Aktualisierung. Haltbarkeit 30 Tage. ========================================================================================== 3 SEHENSWERTES (OPENSTREETMAP UND WIKIDATA) ========================================================================================== Zweck. Der Planer zeigt entlang der Route und rund um die Halte Burgen, Kirchen, Museen, Aussichtspunkte, Naturziele, Leuchttürme und ähnliche Orte. Der Bestand verbindet OpenStreetMap (was ein Ort ist und wo er liegt) mit Wikidata (wie bekannt er ist, Namen auf Deutsch und Englisch, Kurzbeschreibung, Wikipedia-Artikel, Foto). Die Brücke ist das Tag wikidata am OSM-Objekt. Skript: planer/scripts/update-erleben.mts (npm run erleben:update) Ergebnis: planer/lib/erleben/sehenswertes.json.gz Quellen: QLever, https://qlever.dev/api/osm-planet (OpenStreetMap, ODbL) QLever, https://qlever.dev/api/wikidata (Wikidata, CC0) Auswahl in OpenStreetMap. Aufgenommen werden nur Objekte aller Typen, die eines der folgenden Tags (in Zeile 11 beide) und zusätzlich ein Tag wikidata tragen. Die Reihenfolge der Tabelle ist die Rangfolge (siehe Aufbereitung). minRang ist die Mindestzahl an Wikidata-Sitelinks, ab der ein Ort dieser Zeile aufgenommen wird. Nr Kategorie Tag minRang 1 burg historic=castle 2 2 burg historic=fort 3 3 kirche building=cathedral 3 4 kirche historic=monastery 3 5 kirche amenity=monastery 3 6 kirche amenity=place_of_worship 12 7 museum tourism=museum 3 8 geschichte historic=ruins 3 9 geschichte historic=archaeological_site 4 10 aussicht tourism=viewpoint 1 11 aussicht man_made=tower und tower:type=observation 2 12 natur waterway=waterfall 1 13 natur natural=waterfall 1 14 natur natural=gorge 1 15 natur natural=arch 1 16 natur natural=geyser 1 17 natur natural=cave_entrance 2 18 natur natural=hot_spring 2 19 natur natural=glacier 3 20 natur natural=volcano 5 21 natur natural=peak 30 22 kueste man_made=lighthouse 1 23 kueste natural=beach 2 24 freizeit tourism=theme_park 2 25 freizeit tourism=zoo 2 26 freizeit tourism=aquarium 2 27 freizeit leisure=water_park 3 28 sehenswert tourism=attraction 2 29 sehenswert historic=city_gate 2 30 sehenswert historic=monument 3 Abfrage in OpenStreetMap. Je Tabellenzeile eine, zusammen 30. Wiedergegeben für Zeile 1: PREFIX geo: PREFIX geof: SELECT ?o ?wd ?c ?name WHERE { ?o "castle" . ?o ?wd . ?o geo:hasGeometry/geo:asWKT ?wkt . BIND(geof:centroid(?wkt) AS ?c) OPTIONAL { ?o ?name } } In den übrigen Abfragen steht an Stelle der ersten Zeile im WHERE-Block das Tag der jeweiligen Tabellenzeile in derselben Form. Für Zeile 11 sind es zwei Zeilen: ?o "tower" . ?o "observation" . Aufbereitung der OSM-Treffer. * Der Wert von wikidata muss genau eine Kennung aus Q und 1 bis 10 Ziffern sein (Leerraum am Rand erlaubt, Groß- und Kleinschreibung egal). Listen und andere Werte fallen weg. * Position: der Zentroid, gerundet auf 5 Nachkommastellen. * Schlüssel des Bestands ist die Wikidata-Kennung. Tragen mehrere OSM-Objekte dieselbe Kennung, zählt der erste Treffer in der Reihenfolge der Tabelle, innerhalb einer Abfrage der erste in der Reihenfolge der Antwort. Dieser Treffer bestimmt Kategorie, minRang, Position und OSM-Namen. * Der OSM-Name (Tag name) dient nur als Rückfall, wenn Wikidata keinen Namen liefert. Leerraum wird zusammengezogen, Namen über 120 Zeichen werden verworfen. * Die OSM-Kennung wird nicht in den Bestand übernommen. Abfrage in Wikidata. In Paketen zu höchstens 4.000 Kennungen aus dem vorigen Schritt; an Stelle von wd:Q... stehen die Kennungen des Pakets: PREFIX wd: PREFIX wdt: PREFIX wikibase: PREFIX rdfs: PREFIX schema: SELECT ?item ?sl ?img ?nameDe ?nameEn ?beschrDe ?beschrEn ?wikiDe ?wikiEn ?welterbe ?coord ?einwohner WHERE { VALUES ?item { wd:Q... wd:Q... } ?item wikibase:sitelinks ?sl . OPTIONAL { ?item wdt:P18 ?img } OPTIONAL { ?item wdt:P625 ?coord } OPTIONAL { ?item wdt:P1082 ?einwohner } OPTIONAL { ?item rdfs:label ?nameDe . FILTER(LANG(?nameDe) = "de") } OPTIONAL { ?item rdfs:label ?nameEn . FILTER(LANG(?nameEn) = "en") } OPTIONAL { ?item schema:description ?beschrDe . FILTER(LANG(?beschrDe) = "de") } OPTIONAL { ?item schema:description ?beschrEn . FILTER(LANG(?beschrEn) = "en") } OPTIONAL { ?wikiDe schema:about ?item ; schema:isPartOf } OPTIONAL { ?wikiEn schema:about ?item ; schema:isPartOf } OPTIONAL { ?item wdt:P1435 wd:Q9259 . BIND(1 AS ?welterbe) } } Übernommen aus Wikidata. * Zahl der Sitelinks (Maß der Bekanntheit). * Name auf Deutsch und auf Englisch: die Bezeichnung (rdfs:label) der Sprache; fehlt sie, der Titel des Wikipedia-Artikels dieser Sprache ohne abschließenden Klammerzusatz. * Kurzbeschreibung auf Deutsch und auf Englisch (schema:description); ein abschließender Klammerzusatz aus Ziffern wird entfernt. * Titel des deutschen und des englischen Wikipedia-Artikels, aus der Adresse dekodiert, Unterstriche als Leerzeichen. * Dateiname des Fotos (P18) auf Wikimedia Commons; Namen über 160 Zeichen werden verworfen. * Welterbe: ja, wenn P1435 den Wert Q9259 hat. * Alle Koordinaten (P625) und ob eine Einwohnerzahl (P1082) vorliegt. Beides dient nur der Prüfung unten und steht nicht im Ergebnis. Namen und Kurzbeschreibungen: Leerraum wird zusammengezogen, Texte über 120 Zeichen werden verworfen. Liefert Wikidata für ein Objekt mehrere Zeilen, stammen Namen, Texte und Foto aus der ersten; die weiteren tragen nur zusätzliche Koordinaten und die Einwohnerangabe bei. Auswahl nach dem Abgleich. Ein Ort wird aufgenommen, wenn alle Bedingungen gelten: * Wikidata liefert für die Kennung einen Eintrag. * Die Zahl der Sitelinks erreicht minRang seiner Tabellenzeile, oder der Ort ist Welterbe. * Es gibt einen deutschen oder einen englischen Wikipedia-Artikel. * Es gibt einen Namen (deutsch, englisch oder aus OSM). * Wikidata führt keine Einwohnerzahl (P1082). * Wikidata führt mindestens eine Koordinate (P625), und die nächstgelegene davon liegt höchstens 5 km von der OSM-Position entfernt, in den Kategorien natur und kueste höchstens 15 km (Haversine-Formel, Erdradius 6371 km). * Plausibilitätsschwelle: mindestens 40.000 Orte. Ergebnisformat. JSON-Objekt mit den Feldern generated (Datum des Laufs, JJJJ-MM-TT), source, format, kategorien, count und orte. kategorien ist die Liste burg, kirche, museum, geschichte, aussicht, natur, kueste, freizeit, sehenswert; die Kategorie eines Orts ist der Index darin. Je Ort eine Liste [qid, kategorie, lon, lat, sitelinks, welterbe, name_de, name_en, beschreibung_de, beschreibung_en, wikipedia_de, wikipedia_en, commons_bild] qid Wikidata-Kennung als Zahl ohne Q lon, lat Position aus OpenStreetMap welterbe 1 oder 0 name_de deutscher Name, sonst englischer, sonst OSM-Name name_en englischer Name, nur wenn er von name_de abweicht, sonst leer Leere Felder am Ende einer Zeile entfallen; die ersten sieben Felder stehen immer da. Aktualisierung. Haltbarkeit 30 Tage. ========================================================================================== 4 UMWELTZONEN (TEIL AUS OPENSTREETMAP) ========================================================================================== Zweck. Der Planer weist an jeder Umweltzone auf der Route darauf hin, was vor der Einfahrt zu tun ist (Plakette, Crit'Air, Registrierung). Dafür braucht er die Fläche der Zone. Skript: planer/scripts/update-umweltzonen.mts (npm run umweltzonen:update) Ergebnis: planer/lib/umweltzonen/zonen.json.gz Quelle: QLever, https://qlever.dev/api/osm-planet, weltweit ohne räumliche Grenze Abgrenzung. Der Bestand hat zwei Quellen. Zonen in Frankreich stammen überwiegend aus der Base Nationale consolidée des Zones à Faibles Émissions (BNZFE) auf transport.data.gouv.fr unter der Licence Ouverte 2.0; sie stammen nicht aus OpenStreetMap und sind im Bestand mit quelle "bnzfe" gekennzeichnet. Alle übrigen Zonen stammen aus OpenStreetMap (quelle "osm"). Beschrieben wird hier der Teil aus OpenStreetMap und die Zusammenführung, soweit sie OSM-Daten betrifft. Auswahl. Objekte aller Typen mit boundary=low_emission_zone. Abfrage: PREFIX osmkey: PREFIX geo: SELECT ?o ?name ?namede ?start ?end ?website ?wkt WHERE { ?o osmkey:boundary "low_emission_zone" . ?o geo:hasGeometry/geo:asWKT ?wkt . OPTIONAL { ?o osmkey:name ?name } OPTIONAL { ?o osmkey:name:de ?namede } OPTIONAL { ?o osmkey:start_date ?start } OPTIONAL { ?o osmkey:end_date ?end } OPTIONAL { ?o osmkey:website ?website } } Aufbereitung der OSM-Zonen. * Nur Flächen: Geometrien vom Typ POLYGON oder MULTIPOLYGON. Punkte und Linien fallen weg. * Ringe mit weniger als 4 Punkten fallen weg. Ringe mit mehr als 4 Punkten werden nach Douglas-Peucker vereinfacht, Toleranz 0,0003 Grad (rund 30 m), die Längen dabei mit dem Kosinus der Breite des ersten Ringpunkts gestaucht; die verbleibenden Punkte werden auf 5 Nachkommastellen gerundet. Ringe mit genau 4 Punkten bleiben unverändert. Eine Fläche ohne verbleibenden Ring oder mit einem Außenring unter 4 Punkten fällt weg. * Je Objekt zählt die erste Ergebniszeile mit verwertbarer Fläche. * Name: Wert von name, sonst von name:de, an den Rändern bereinigt, auf 120 Zeichen gekürzt. * Beginn und Ende: start_date und end_date in den Formen JJJJ, JJJJ-MM oder JJJJ-MM-TT, ergänzt zu JJJJ-MM-TT (fehlender Monat oder Tag wird 01). Andere Formen entfallen. * website nur, wenn der Wert eine http- oder https-Adresse ohne Leerzeichen ist. * Land: Ländercode aus den Natural-Earth-Grenzen (Abschnitt 0), bestimmt an der Mitte des umschreibenden Rechtecks der Außenringe, sonst am ersten Punkt des ersten Außenrings. Liegt beides in keinem Land, bleibt das Land leer (null). * Kennung osm:n..., osm:w... oder osm:r... . Gruppe: Land und Name in Kleinbuchstaben, getrennt durch |, bei Zonen ohne Namen die Kennung. * Plausibilitätsschwellen: mindestens 120 OSM-Flächen und mindestens 20 BNZFE-Einträge. Zusammenführung und Filter. "Mitte" ist jeweils die Mitte des umschreibenden Rechtecks der Außenringe einer Zone. 1. Französische OSM-Zonen (Land FR) bleiben nur, wenn an derselben Stelle keine BNZFE-Zone ähnlicher Größe liegt. Ähnlich heißt: Das Verhältnis der Flächeninhalte der Außenringe (in Quadratgrad, gaußsche Trapezformel) liegt zwischen 0,25 und 4, jeweils ausschließlich. An derselben Stelle heißt: Die Mitte der OSM-Zone liegt in einem Außenring der BNZFE-Zone, oder die Mitte der BNZFE-Zone liegt in einem Außenring der OSM-Zone. 2. BNZFE-Einträge ohne Namen übernehmen den Namen einer benannten BNZFE-Zone, in der ihre Mitte liegt, sonst den einer benannten französischen OSM-Zone, in der ihre Mitte liegt, sonst den Namen "ZFE". Nur auf diesem Weg gehen OSM-Daten in BNZFE-Einträge ein. 3. OSM-Zonen ohne Namen fallen weg, wenn ihre Mitte in einer anderen Zone liegt, die einen Namen trägt oder aus der BNZFE stammt. 4. Zonen, deren Ende mehr als 365 Tage vor dem Lauf liegt, fallen weg. 5. Zonen, deren Name auf den folgenden regulären Ausdruck passt (Groß- und Kleinschreibung egal), fallen weg; sie betreffen kein Wohnmobil (Zonen nur für Lkw, Mofas oder Linienbusse). Der Ausdruck ist eine Zeile, hier umbrochen: \blkw\b|lkw-|\bhgv\b|\btruck|brom- en snorfiets|snorfiets| \bbromfiets|franchised bus|\bbus low emission 6. Die Zonen werden nach Kennung sortiert. Ergebnisformat. JSON-Objekt mit den Feldern generated (Zeitpunkt des Laufs), quellen (osm: "OpenStreetMap-Mitwirkende, ODbL"; bnzfe: Name, Lizenz und Stand der BNZFE) und zonen. Je Zone: id Kennung (osm:... bzw. bnzfe:...) land Ländercode oder null name Name, kann leer sein gruppe siehe oben quelle "osm" oder "bnzfe" bbox umschreibendes Rechteck der Außenringe [West, Süd, Ost, Nord] flaechen Liste von Flächen, jede eine Liste von Ringen aus [lon, lat], der erste Ring ist der Außenring ab, bis Beginn und Ende (JJJJ-MM-TT), nur wenn bekannt website nur wenn vorhanden critair nur bei BNZFE-Zonen Aktualisierung. Haltbarkeit 30 Tage. ========================================================================================== 5 MAUTSTRASSENNETZ ========================================================================================== Zweck. Das Netz liefert die mautpflichtigen Kilometer einer Route in Ländern mit streckenbezogener Maut; sie sind die Grundlage der Schätzung der Streckenmaut. Skript: planer/scripts/update-tollways.mts (npm run tolls:update) Ergebnis: planer/lib/tollcheck/tollways.json Quelle: Overpass API, Endpunkte in dieser Reihenfolge: https://overpass-api.de/api/interpreter https://overpass.kumi.systems/api/interpreter https://overpass.private.coffee/api/interpreter Auswahl. Ways mit highway=motorway oder highway=trunk und zugleich toll=yes, in Frankreich (FR), Italien (IT), Spanien (ES), Portugal (PT), Kroatien (HR) und Griechenland (GR). Länder mit Vignette sind nicht enthalten. Abfrage (Overpass QL), je Abfragefeld eine: [out:json][timeout:180]; way["highway"~"^(motorway|trunk)$"]["toll"="yes"](SÜD,WEST,NORD,OST); out geom; Abfragefelder. SÜD, WEST, NORD und OST ergeben sich je Land aus dem umschreibenden Rechteck seiner Natural-Earth-Grenze (Abschnitt 0), beschnitten auf Länge -12 bis 32 und Breite 34 bis 60 und zerlegt in gleich hohe Breitenbänder von höchstens 3,5 Grad. Die Grenzen werden auf 3 Nachkommastellen gerundet. Die Anfrage geht als HTTP-POST (Formularfeld data) an den ersten Endpunkt, bei einem Fehler an den nächsten, mit 30 Sekunden Pause nach jedem Fehlversuch und zwischen zwei Feldern. Scheitert ein Feld an allen Endpunkten, wird es in vier gleiche Viertel geteilt, die einzeln abgefragt werden, höchstens drei Teilungen tief. Scheitert ein Feld auch dann, wird kein Bestand geschrieben. Antworten werden in einem lokalen Zwischenspeicher abgelegt und bei einem weiteren Lauf ohne die Option --force wiederverwendet. Aufbereitung. * Ways mit weniger als zwei Punkten fallen weg. Jeder Way zählt einmal (nach OSM-Kennung), auch wenn er in mehreren Abfragefeldern vorkommt. * Land: bestimmt am mittleren Punkt des Ways (Position: Punktzahl halbiert, abgerundet) gegen die Natural-Earth-Grenzen der sechs Länder. Ways außerhalb dieser Länder fallen weg. * Je Land werden die Ways zu durchgehenden Linien verkettet: An eine Kette wird ein noch nicht verwendeter Way angehängt, dessen erster Punkt dem letzten Punkt der Kette gleicht (verglichen auf 6 Nachkommastellen). Ways werden dabei nicht umgedreht. * Jede Linie wird nach Douglas-Peucker vereinfacht, Toleranz 0,002 Grad (rund 220 m, ohne Stauchung der Längen), und auf 4 Nachkommastellen gerundet. * Übernommen wird nur die Geometrie. Kennungen und Tags der Ways entfallen. Ergebnisformat. JSON-Liste mit einem Eintrag {code, lines} je Land, nach code sortiert. lines ist eine Liste von Linien, jede eine Liste von Punkten [lon, lat]. Die Datei hat keinen Kopf und kein Datum. Aktualisierung. Haltbarkeit 300 Tage. ========================================================================================== 6 ROUTING-GRAPH ========================================================================================== Zweck. Routenberechnung im Planer mit dem eigenen Routendienst (GraphHopper). Quelle. Ein OpenStreetMap-Auszug der Geofabrik (je nach Bau der ganze Planet oder ein Kontinent), importiert mit GraphHopper 11.0 (Container-Image israelhikingmap/graphhopper). Aufbereitung. Der Import übernimmt die Straßen mit diesen Merkmalen (Konfiguration planer/graphhopper/config.yml, graph.encoded_values): car_access, car_average_speed, country, road_class, road_class_link, roundabout, max_speed, road_environment, toll, hgv, max_height, max_width, max_weight, max_length, max_weight_except, surface, track_type, ferry_speed, osm_way_id Ein Profil "womo" auf Grundlage von GraphHoppers car.json. Die Daten selbst werden beim Import nicht verändert. Fahrzeugmaße, Gewicht, Lkw-Fahrverbote über 3,5 t und Meidungswünsche wirken erst zur Anfragezeit als Custom Model auf dem fertigen Graphen. Ergebnisformat. Der Graph im Format von GraphHopper 11.0; er wird nicht veröffentlicht, genutzt werden nur die berechneten Routen. Aktualisierung. Neubau von Hand in unregelmäßigen Abständen. ========================================================================================== 7 DURCHFAHRTS-CHECK: WEGE MIT HÖHEN-, BREITEN-, GEWICHTS- ODER LÄNGENBESCHRÄNKUNG ========================================================================================== Zweck. Der Durchfahrts-Check prüft eine berechnete Route gegen erfasste Beschränkungen (Höhe, Breite, Gewicht, Länge) und nennt jede Fundstelle einzeln. Seit dem 27.10.2026 fragt er dafür keinen fremden Dienst mehr, sondern diesen eigenen Bestand. Skript: planer/scripts/update-beschraenkungen.mts (npm run beschraenkungen:update) Ergebnis: planer/lib/routecheck/beschraenkungen.bin.gz Quelle: QLever, https://qlever.dev/api/osm-planet, weltweit ohne räumliche Grenze Auswahl. Alle Ways, die mindestens einen dieser sechs Tags tragen: maxheight, maxheight:physical, maxwidth, maxwidth:physical, maxweight, maxlength Nodes und Relationen sind nicht enthalten. Nach Werten wird nicht gefiltert: Was ein Tag für eine Route bedeutet (auch Werte wie "none", "default" oder unlesbare Angaben), entscheidet der Planer zur Laufzeit; der Bestand spiegelt OpenStreetMap. Übernommene Merkmale. Nur diese elf Schlüssel, alle übrigen Tags entfallen: maxheight, maxheight:physical, maxwidth, maxwidth:physical, maxweight, maxlength, highway, barrier, route, name, ref Abfragen. Zwei je Lauf, beide über dieselbe Teilmenge WEGE: WEGE := { SELECT DISTINCT ?o WHERE { VALUES ?r { osmkey:maxheight osmkey:maxheight:physical osmkey:maxwidth osmkey:maxwidth:physical osmkey:maxweight osmkey:maxlength } ?o ?r ?rv . FILTER(STRSTARTS(STR(?o), "https://www.openstreetmap.org/way/")) } } Abfrage 1, Merkmale: PREFIX osmkey: SELECT ?o ?k ?v WHERE { WEGE VALUES ?k { osmkey:maxheight osmkey:maxheight:physical osmkey:maxwidth osmkey:maxwidth:physical osmkey:maxweight osmkey:maxlength osmkey:highway osmkey:barrier osmkey:route osmkey:name osmkey:ref } ?o ?k ?v . } Abfrage 2, Verläufe: PREFIX osmkey: PREFIX geo: SELECT ?o ?wkt WHERE { WEGE ?o geo:hasGeometry/geo:asWKT ?wkt . } Vor jeder Abfrage zählt das Skript die erwarteten Datensätze (SELECT (COUNT(*) AS ?n) über dasselbe Muster) und bricht ab, wenn weniger ankommen oder die Antwort nicht mit einem Zeilenende schließt. Die Antworten kommen als CSV (Accept: text/csv). Aufbereitung. * Je Way werden übernommen: die OSM-Kennung, die abgefragten Tags unverändert, der Name (ersatzweise ref) und der Verlauf aus dem WKT als Punktfolge. * Ways ohne Verlauf oder ohne Tags entfallen. Liegt ihr Anteil über 0,5 Prozent oder sinkt der Bestand unter 700.000 Ways bzw. 6 Millionen Punkte, bricht der Lauf ab und die bisherige Datei bleibt stehen. * Die Geometrie wird nicht vereinfacht, nur auf Millionstel Grad gerundet (rund 0,1 m). Tags werden weder ausgewertet noch verändert. Ergebnisformat. Gzip über einen Binärblock (Format Version 1, beschrieben in planer/lib/beschraenkungsbestand.ts): ein Kopf als JSON (generated: Zeitpunkt des Laufs, osmStand: der OSM-Stand, den QLever zum Abruf geladen hatte, quelle, Zahl der Ways und Punkte, die Liste der vorkommenden Tag-Kombinationen, die Liste der Namen), danach je Way Kennung, Index der Tag-Kombination, Index des Namens, Punktzahl und die Koordinaten in Millionstel Grad. Am 27.10.2026 waren es 881.735 Ways. Aktualisierung. Haltbarkeit 7 Tage. Hat QLever seit dem letzten Lauf keinen neueren OSM-Stand geladen, endet der Lauf ohne Abruf; die Datei behält dann ihren Stand. ========================================================================================== 8 BEZUG EINER KOPIE ========================================================================================== Camperada bietet die abgeleiteten Bestände nicht separat zum Download an. Wer eine Kopie der abgeleiteten Datenbank haben möchte, bekommt sie gern: Eine Nachricht über die Kontaktangaben im Impressum genügt (https://camperada.de/impressum). Camperada does not offer the derived datasets as a separate download. If you would like a copy of the derived database, we are happy to provide one: just get in touch via the contact details in the imprint (https://camperada.de/impressum).