OSM Overpass
Der Node erzeugt aus einem auf der Karte gewählten Gebiet und einer Liste von OpenStreetMap-Tags eine Overpass-QL-Abfrage, sendet sie an die öffentliche Overpass API, wandelt das Ergebnis mit osmtogeojson in GeoJSON um und gibt die gefundenen Objekte als Objekte vom Typ OsmFeature aus. Er eignet sich für Points of Interest wie Spielplätze, Trinkbrunnen, Eisdielen oder Parkplätze in einer Kommune.
- Node-Typ
- osm-overpass
- Paket
- @htag/node-red-contrib-hypertegrity-pointofinterest
- Eingänge / Ausgänge
- 1 / 1
- Datenquelle
- OpenStreetMap über die öffentliche Overpass API
Wofür Sie den Node verwenden
OpenStreetMap (OSM) enthält für fast jede Kommune eine große Zahl an Points of Interest, die über sogenannte Tags beschrieben sind, zum Beispiel amenity=playground für Spielplätze oder amenity=drinking_water für Trinkbrunnen. Die Overpass API ist die Abfrageschnittstelle zu diesen Daten. Der OSM-Overpass-Node nimmt Ihnen das Schreiben der Abfragesprache Overpass QL ab: Sie wählen im Dialog ein Gebiet und die gewünschten Tags, der Node baut die Abfrage, führt sie aus und liefert ein auswertbares Ergebnis.
Typische Einsatzfälle sind:
- Points of Interest einer Stadt oder eines Landkreises (Spielplätze, Bänke, Toiletten, Ladesäulen) in einen NGSI-LD Context Broker übernehmen.
- Flächen und Gebäude wie Parks oder Schulen mit Punkt- und Polygon-Geometrie für Karten-Dashboards bereitstellen.
- Bestandsabgleiche zwischen kommunalen Fachdaten und dem OSM-Datenbestand in regelmäßigen Abständen durchführen.
So funktioniert der Node
Auslösen
Eine eingehende Nachricht startet die Abfrage. Der Node fragt die Overpass API nicht von selbst ab.
Abfrage bauen
Aus Gebiet (Verwaltungsgebiet, Bounding Box oder Radius) und Tags entsteht eine Overpass-QL-Abfrage für Nodes, Ways und Relations.
Abfragen
Die Abfrage geht nacheinander an bis zu vier öffentliche Overpass-Server (Ausweichserver), jeweils mit bis zu zehn Versuchen.
Wandeln
Das OSM-JSON wird mit osmtogeojson in GeoJSON überführt und in flache OsmFeature-Objekte mit Punktgeometrie gemappt.
Ausgeben
Je Tag (oder je Tag-Kombination) verlässt eine Nachricht den Node; msg.topic nennt das Tag, msg.payload enthält die Treffer.
Ergebnis: Ein Array von OsmFeature-Objekten je Tag, das direkt in den NGSI-LD Builder geführt werden kann.
Der Node ist triggerbasiert. Kombinieren Sie ihn mit einem Inject-Node, der zum Beispiel einmal täglich auslöst. OSM-Daten ändern sich selten so schnell, dass häufigere Abfragen nötig wären, und die Overpass-Server sind eine gemeinschaftlich betriebene Ressource.
Die erzeugte Abfrage beginnt mit [out:json][timeout:30], enthält bei einer Bounding Box den Zusatz [bbox:S,W,N,E], bei einem Radius den Filter (around:Meter,Lat,Lon) und bei Verwaltungsgebieten einen Block area(ID)->.searchArea. Für jedes Tag werden node, way und relation abgefragt, gefolgt von out body; >; out skel qt;, damit die Geometrien von Wegen und Relationen vollständig geladen werden.
Konfiguration
Der Bearbeitungsdialog hat zwei Registerkarten. Die Gebietsfelder werden nicht direkt eingetippt, sondern über die Karte oder die Gebietssuche gefüllt; sie sind im Dialog als verborgene Felder hinterlegt.
Registerkarte „Ort & Suche“
| Feld | Typ | Standard | Bedeutung |
|---|---|---|---|
| Name | Text | leer | Anzeigename des Nodes im Flow. |
| Gebietssuche | Suchfeld mit Button „Suchen“ | leer | Sucht über Nominatim nach Städten, Landkreisen oder Stadtteilen. Ein Treffer mit Grenzpolygon wird als Verwaltungsgebiet übernommen; mehrere Gebiete lassen sich nacheinander hinzufügen und als Chips wieder entfernen. |
| Abfragebereich (Karte) | Leaflet-Karte mit Zeichenwerkzeugen | Deutschland-Übersicht | Mit den Werkzeugen am linken Kartenrand zeichnen Sie einen Kreis (Radius) oder ein Rechteck (Bounding Box). Eine neue Zeichnung ersetzt vorhandene Gebiete. |
areaType | verborgen (area, bbox, radius) | leer | Wird durch Suche oder Zeichnung gesetzt und bestimmt die Art des Gebietsfilters. |
areas | verborgen (Liste) | leer | Gewählte Verwaltungsgebiete mit name, osmId, osmType und searchId (Overpass-Area-ID: Relation + 3600000000, Way + 2400000000). |
bboxS, bboxW, bboxN, bboxE | verborgen (Dezimalgrad) | leer | Süd-, West-, Nord- und Ostgrenze des gezeichneten Rechtecks. |
radiusLat, radiusLon, radiusMeters | verborgen (Dezimalgrad, Meter) | leer | Mittelpunkt und Radius des gezeichneten Kreises in Metern. |
Registerkarte „Tags & Filter“
| Feld | Typ | Standard | Bedeutung |
|---|---|---|---|
| Geometriemodus | Auswahl | „Nur Punkt (für Marker)“ | point: jedes Objekt erhält nur eine Punktgeometrie (bei Flächen und Linien der Mittelpunkt der Bounding Box). split: zusätzlich wird die Originalgeometrie im Feld location_polygon ausgegeben. |
| Abfragemodus | Auswahl | „Beliebiger Tag (ODER) - separate Abfragen“ | or: jedes Tag wird einzeln abgefragt und als eigene Nachricht ausgegeben. and: alle Tags müssen gleichzeitig zutreffen; es entsteht eine kombinierte Abfrage und eine Nachricht. |
| OSM Tags | Bearbeitbare Liste (Key, Value) | leer | Schlüssel und Wert eines OSM-Tags, zum Beispiel amenity und cafe. Beide Felder bieten Auto-Vervollständigung über die Taginfo API. Bleibt der Wert leer, werden alle Objekte mit diesem Schlüssel unabhängig vom Wert gefunden. |
Speichern Sie den Dialog ohne Gebiet, meldet der Editor eine Warnung. Zur Laufzeit lehnt der Node Nachrichten ab, solange kein Gebiet und mindestens ein Tag konfiguriert sind.
Eingang
Der Eingang dient ausschließlich als Auslöser. Der Node wertet keine Nachrichteneigenschaften aus; alle Parameter stammen aus der Konfiguration. Eigenschaften der eingehenden Nachricht werden in die Ausgangsnachrichten übernommen, lediglich payload und topic werden überschrieben.
| Eigenschaft | Typ | Bedeutung |
|---|---|---|
msg.payload | beliebig | Jeder Wert löst die Abfrage aus. Der Inhalt wird nicht ausgewertet. |
Ausgang
Der Node sendet pro Tag (Modus ODER) beziehungsweise pro Tag-Kombination (Modus UND) eine eigene Nachricht über den einzigen Ausgang. msg.topic enthält das Tag in der Form amenity=ice_cream oder bei leerem Wert nur den Schlüssel; im Modus UND lautet es zum Beispiel amenity=cafe AND outdoor_seating=yes. msg.payload ist ein Array von OsmFeature-Objekten.
[
{
"id": "node:1234567890",
"type": "OsmFeature",
"osmtype": "node",
"location": {
"type": "GeoProperty",
"value": {"type": "Point", "coordinates": [7.7689, 49.4447]}
},
"amenity": "ice_cream",
"name": "Eiscafé Beispiel",
"addr_street": "Marktstraße",
"addr_housenumber": "12",
"addr_postcode": "67655",
"opening_hours": "Mo-Su 11:00-21:00"
}
]
| Feld | Bedeutung |
|---|---|
id | OSM-Kennung aus Typ und Nummer; der Schrägstrich der GeoJSON-ID wird durch einen Doppelpunkt ersetzt (node:…, way:…, relation:…). |
type | Immer OsmFeature. |
osmtype | OSM-Objektart node, way oder relation. |
location | GeoProperty mit Punktgeometrie. Bei Polygonen, Multipolygonen und Linien ist das der Mittelpunkt der umschließenden Bounding Box. |
location_polygon | Nur im Geometriemodus split und nur für Nicht-Punkte: GeoProperty mit der Originalgeometrie aus GeoJSON. |
| weitere Felder | Alle OSM-Tags des Objekts. Zeichen außer Buchstaben, Ziffern, _ und - im Schlüssel werden durch _ ersetzt, aus addr:street wird also addr_street. |
Im Modus ODER kann ein Objekt, das mehrere der konfigurierten Tags trägt, in mehreren Nachrichten vorkommen. Objekte, die im Overpass-Ergebnis nur als Geometriestützpunkte enthalten sind und keines der Tags tragen, werden nicht ausgegeben.
Beispiel-Flow
Das Paket bringt einen Beispiel-Flow mit. Sie importieren ihn in Node-RED über Menü → Importieren → Beispiele → @htag/node-red-contrib-hypertegrity-pointofinterest → osm-overpass. Alternativ laden Sie die Datei osm-overpass.json herunter und importieren sie über Menü → Importieren.
Inject
Ein Inject-Node löst die Abfrage manuell oder in einem festen Intervall aus.
OSM Overpass
Der Node fragt im Verwaltungsgebiet Kaiserslautern die Tags amenity=ice_cream und cuisine=ice_cream ab.
Debug
Ein Debug-Node zeigt je Tag ein Array von OsmFeature-Objekten in der Seitenleiste an.
Beispiel-Flow als JSON anzeigen
[
{"id": "tab1", "type": "tab", "label": "osm overpass", "disabled": false, "info": ""},
{"id": "inject1", "type": "inject", "z": "tab1", "name": "", "props": [{"p": "payload"}], "repeat": "", "crontab": "", "once": false, "onceDelay": 0.1, "topic": "", "payload": "", "payloadType": "date", "x": 140, "y": 120, "wires": [["osm1"]]},
{"id": "osm1", "type": "osm-overpass", "z": "tab1", "name": "", "areaType": "area", "areas": "[{\"name\":\"Kaiserslautern\",\"osmId\":62652,\"osmType\":\"relation\",\"searchId\":3600062652}]", "bboxS": "", "bboxW": "", "bboxN": "", "bboxE": "", "radiusLat": "", "radiusLon": "", "radiusMeters": "", "geometryMode": "point", "tagMatchMode": "or", "tags": [{"key": "amenity", "value": "ice_cream"}, {"key": "cuisine", "value": "ice_cream"}], "x": 400, "y": 120, "wires": [["debug1"]]},
{"id": "debug1", "type": "debug", "z": "tab1", "name": "Overpass data", "active": true, "tosidebar": true, "console": false, "tostatus": false, "complete": "payload", "targetType": "msg", "x": 600, "y": 120, "wires": []}
]
Status und Fehler
| Anzeige | Bedeutung |
|---|---|
| Blauer Punkt „querying overpass-api.de (endpoint 1/4, try 1/10)...“ | Die Abfrage läuft gegen den genannten Server; Zähler für Server und Versuch. |
| Grüner Punkt „connected to …“ | Der Server hat ein gültiges Ergebnis geliefert. |
| Blauer Punkt „converting to geojson...“ | Das OSM-JSON wird mit osmtogeojson umgewandelt. |
| Blauer Punkt „mapping to ngsi-ld...“ | Die GeoJSON-Features werden in OsmFeature-Objekte überführt. Danach wird der Status gelöscht. |
| Roter Ring „Invalid config“ | Kein Gebiet, keine Tags oder unvollständige Koordinaten. Die Fehlermeldung nennt die Ursache, zum Beispiel „No tags specified for OSM query.“ oder „Bounding box incomplete“. |
| Roter Ring „failed“ | Alle Server sind gescheitert oder die Umwandlung ist fehlgeschlagen. Die Fehlermeldung lautet „All Overpass endpoints failed after 40 attempts. Last error: …“. |
| Warnung „Overpass endpoint … attempt n/10 failed: …“ | Ein Versuch ist fehlgeschlagen (HTTP-Status, Timeout nach 30 Sekunden oder eine remark-Meldung der Overpass API). Nach 1,5 Sekunden folgt der nächste Versuch. |
| Warnung „All 10 attempts failed for …, trying next endpoint...“ | Der Node wechselt zum nächsten Ausweichserver. |
Fehler werden über done(error) gemeldet und können mit einem Catch-Node abgefangen werden. Warnungen erscheinen in der Debug-Seitenleiste.
Hinweise
- Nutzungsbedingungen und Fair Use: Die verwendeten Overpass-Server (
overpass-api.de,overpass.osm.ch,overpass.openstreetmap.fr,overpass.kumi.systems) sind gemeinschaftlich betriebene, kostenlose Dienste mit Fair-Use-Regeln, unter anderem Grenzen für parallele Anfragen und tägliches Datenvolumen je IP-Adresse. Der Node sendet einen identifizierenden User-Agent und begrenzt jede Abfrage auf 30 Sekunden. Wählen Sie Abfrageintervalle im Bereich von Stunden oder Tagen und halten Sie Gebiete und Tag-Listen so klein wie nötig. Die Gebietssuche und die Tag-Vorschläge im Editor nutzen Nominatim und Taginfo, für die ebenfalls Nutzungsrichtlinien gelten. - Lizenz der Daten: OSM-Daten stehen unter der Open Database License (ODbL). Bei einer Veröffentlichung, etwa in einem Dashboard, ist die Quellenangabe „© OpenStreetMap-Mitwirkende“ erforderlich.
- Große Gebiete: Verwaltungsgebiete werden in der Abfrage über ihre Overpass-Area-ID referenziert. Sehr große Gebiete oder Tags mit vielen Treffern (zum Beispiel
building) können das Timeout von 30 Sekunden überschreiten; der Node versucht es dann erneut und wechselt den Server, was lange dauern kann. - Ausgabeformat: Die Objekte sind bewusst flach gehalten. Die eigentliche NGSI-LD-Entität entsteht erst im nachgelagerten NGSI-LD Builder. Das Feld
locationist bereits als GeoProperty vorbereitet. - Metrische Einheiten: Der Radius wird in Metern angegeben und auch so in die Abfrage übernommen.
- Personenbezogene Daten: OSM-Objekte enthalten in der Regel keine Daten von Privatpersonen. Tags wie
contact:phone,emailoderoperatorkönnen jedoch Ansprechpersonen kleiner Betriebe nennen. Prüfen Sie vor einer Veröffentlichung, welche Tags Sie weitergeben.