Der Netzknoten Navigator übersetzt geografische Positionen in fachliche Straßenreferenzen und wieder zurück. Hinter der einfachen Suche stecken lineare Referenzierung, Netzknoten, Nullpunkte, Abschnitte, Stationierung, Koordinatentransformation und regionale Straßendaten. Für professionelle Prozesse kommen Datenprovenienz, Batch-Verarbeitung, GeoJSON, OKSTRA, API und MCP hinzu.
Was macht der Netzknoten Navigator technisch betrachtet?
Auf den ersten Blick ist der Vextario Netzknoten Navigator eine Kartenanwendung. Man setzt einen Punkt, gibt Koordinaten ein oder sucht eine Straße und erhält Informationen zum Straßennetz.
Technisch passiert mehr.
Eine geografische Position muss mit einem fachlichen Netzmodell verbunden werden. Der Punkt besitzt zunächst beispielsweise nur Längen- und Breitengrad. Für die Verkehrssicherung ist aber häufig zusätzlich interessant, zu welchem Straßenabschnitt er gehört, welche Netzknoten den Abschnitt bestimmen und an welcher Station innerhalb dieses Abschnitts er liegt.
Der Navigator löst deshalb zwischen zwei unterschiedlichen Arten der Georeferenzierung auf.
Die erste ist die absolute geografische Position, etwa als WGS84-Koordinate.
Die zweite ist die lineare Referenz innerhalb des Straßennetzes. Statt den Standort ausschließlich durch zwei Koordinaten zu beschreiben, wird seine Position entlang eines definierten Straßenabschnitts angegeben.
Beide Modelle beschreiben denselben realen Ort, erfüllen aber unterschiedliche Aufgaben.
Eine Koordinate lässt sich unmittelbar auf einer Karte darstellen. Abschnitt und Station lassen sich dagegen direkt mit Straßenbestandsdaten, Bauwerken, Arbeitsstellen und weiteren straßenbezogenen Fachinformationen verbinden.
Produktseite: Vextario Netzknoten Navigator
https://netzknoten-navigator.vextario.com/
Was bedeuten Netzknoten, Nullpunkt, Abschnitt und Station genau?
Diese Begriffe werden im Alltag gelegentlich miteinander vermischt, technisch beschreiben sie unterschiedliche Elemente des Straßennetzes.
Ein Netzknoten repräsentiert einen Knotenbereich im Straßennetz, beispielsweise dort, wo klassifizierte Straßen miteinander verknüpft sind.
Innerhalb eines komplexen Knotens können Nullpunkte die eigentlichen Anfangs- und Endpunkte von Abschnitten bestimmen. Ein Netzknoten ist deshalb nicht zwangsläufig identisch mit genau einem geometrischen Straßenpunkt.
Ein Abschnitt verbindet zwei solche Begrenzungspunkte im Netz. Er besitzt eine definierte Richtung.
Die Station beschreibt schließlich die Position innerhalb dieses Abschnitts. Vereinfacht ausgedrückt gibt sie an, wie weit ein Punkt entlang des Abschnitts vom Abschnittsanfang entfernt liegt.
Der Landesbetrieb Straßenwesen Brandenburg beschreibt dieses ASB-basierte Ordnungssystem entsprechend: Straßen werden in Abschnitte gegliedert, jeder Abschnitt besitzt eine Stationierungsrichtung und wird durch VON- und NACH-Netzknoten begrenzt. Die Stationierung beginnt am VON-Netzknoten und läuft in Richtung NACH-Netzknoten.
Genau deshalb benötigt eine professionelle Straßenposition mehr Kontext als beispielsweise „Station 1,250“. Ohne den zugehörigen Abschnitt ist der Wert nicht vollständig beschrieben.
Was bedeuten VNK und NNK im Ergebnis?
VNK und NNK stehen für VON-Netzknoten und NACH-Netzknoten.
Sie beschreiben die Orientierung des betreffenden Abschnitts im Netzmodell. Die Stationierung steigt vom VON-Bezug in Richtung des NACH-Bezugs an.
Das ist für den Navigator wichtig, weil dieselbe reale Straße in beide Fahrtrichtungen befahren werden kann, während die fachliche Stationierungsrichtung davon unabhängig bleibt.
Ein Monteur kann sich also entgegen der Stationierungsrichtung bewegen. Der Stationswert wird dadurch nicht umgedreht.
Gerade bei getrennten Richtungsfahrbahnen, Anschlussstellen und Rampen darf deshalb Fahrtrichtung nicht automatisch mit Stationierungsrichtung gleichgesetzt werden.
Eine typische Fehlerquelle in selbstgebauten Tabellen oder einfachen GIS-Abfragen besteht genau darin: Ein Straßenverlauf wird als Linie betrachtet und aus der Fahrzeugrichtung wird eine fachliche Richtung abgeleitet. Das kann funktionieren, muss aber nicht.
Der Navigator behandelt beide Informationen getrennt.
Was ist lineare Referenzierung und warum ist sie für Straßen sinnvoll?
Bei einer normalen Geokoordinate wird ein Punkt über seine Lage auf der Erdoberfläche beschrieben.
Bei einer linearen Referenzierung wird der Punkt zusätzlich oder alternativ relativ zu einem Linienobjekt beschrieben. Im Straßenwesen ist dieses Linienobjekt ein definierter Abschnitt oder Ast des Netzes.
Das Prinzip ist besonders nützlich, weil viele Fachinformationen ohnehin an einer Straße liegen.
Eine Arbeitsstelle beginnt an Station X und endet an Station Y. Ein Bauwerk liegt an einer bestimmten Station. Eine Beschilderung, ein Schaden oder ein Kontrollpunkt lässt sich ebenfalls auf einen Straßenabschnitt beziehen.
OKSTRA verwendet genau dieses Prinzip für straßenbezogene Objekte: Objekte erhalten ihren Netzbezug über eine Stationierung auf einem Abschnitt oder Ast.
Der Netzknoten Navigator macht aus dieser Fachlogik einen praktisch nutzbaren Arbeitsablauf. Der Benutzer muss keine lineare Referenzierung berechnen. Er arbeitet mit Karte, Koordinate oder Straßenreferenz, während die Auflösung im Hintergrund erfolgt.
Wie funktioniert die Auflösung von GPS oder Koordinaten zum Straßennetz?
Bei der Vorwärtsauflösung beginnt der Navigator mit einer geografischen Position.
Das kann der aktuelle GPS-Standort sein, eine eingegebene Koordinate oder ein manuell gewählter Kartenpunkt.
Anschließend muss bestimmt werden, welche Netzobjekte fachlich zu dieser Position passen.
Eine naive Implementierung würde lediglich die geometrisch nächstgelegene Straßenlinie auswählen. Für eine einfache Karte kann das ausreichen. Für ein Straßennetz mit Parallelfahrbahnen, Rampen und Ästen ist es zu wenig.
Der fachliche Resolver muss zusätzlichen Netzkontext berücksichtigen.
Dazu gehören beispielsweise Straßenklasse und Straßennummer, Abschnittsgeometrie, Netzknotenbezug, Richtung, regionale Datenstruktur sowie mögliche alternative Treffer.
Das Ergebnis kann deshalb mehr als einen plausiblen Kandidaten enthalten.
Genau das ist gewollt. Eine Software sollte an einer komplexen Anschlussstelle nicht einen Treffer als sicher darstellen, nur weil dessen Geometrie 1,5 Meter näher am GPS-Punkt liegt als eine andere Fahrbahn.
Wie funktioniert die Reverse-Auflösung von Stationierung zu Koordinate?
Der umgekehrte Prozess beginnt mit einem Netzbezug.
Bekannt sind beispielsweise Straße, VNK, NNK, Abschnitt und Station. Gesucht wird der geografische Punkt.
Der Navigator identifiziert zunächst den betreffenden Abschnitt beziehungsweise Ast und dessen Geometrie. Anschließend wird die Station entlang des Abschnitts in die entsprechende geografische Lage übersetzt.
Damit wird aus einer linearen Referenz wieder ein Punkt.
Für die Verkehrssicherung ist diese Richtung besonders interessant, weil viele Unterlagen bereits mit straßenbezogenen Angaben arbeiten.
Eine Ausschreibung kann beispielsweise einen Arbeitsbereich über Abschnitt und Station beschreiben. Mit der Reverse-Auflösung lässt sich daraus unmittelbar ein Kartenpunkt erzeugen.
Der Benutzer muss dafür nicht wissen, wie die zugrunde liegende Abschnittsgeometrie gespeichert ist oder wie eine Position entlang einer LineString-Geometrie interpoliert wird.
Warum unterscheidet der Navigator zwischen Abschnitt und Ast?
Nicht jedes Netz lässt sich ausschließlich als einfache Folge von Straßenabschnitten modellieren.
Komplexe Netzknoten können zusätzliche Verbindungen besitzen. Dazu gehören beispielsweise Rampen oder Verknüpfungen innerhalb eines Knotens.
Solche Verbindungen werden in entsprechenden Straßenmodellen als Äste behandelt.
Für die Positionsauflösung ist das relevant, weil eine Koordinate an einer Autobahnanschlussstelle geometrisch möglicherweise näher an einem Ast als an der Hauptfahrbahn liegt.
Eine professionelle Anwendung muss deshalb erkennen können, dass verschiedene Netzobjekttypen existieren.
Wer diese Unterscheidung ignoriert, erhält oft Ergebnisse, die auf der Karte plausibel aussehen, aber fachlich nicht zum gemeinten Straßenbezug passen.
Der Navigator behandelt Abschnitte und komplexere Netzsituationen deshalb nicht nur als visuelle Linien auf der Karte, sondern als Elemente des zugrunde liegenden Ordnungssystems.
Wie unterscheiden sich WGS84 und ETRS89/UTM32?
WGS84 und ETRS89/UTM32 beschreiben geografische Positionen auf unterschiedliche Weise.
WGS84, typischerweise EPSG:4326, verwendet geografische Koordinaten in Längen- und Breitengrad. GPS-Geräte, Smartphones und viele Webdienste arbeiten in dieser Welt.
ETRS89/UTM Zone 32N, EPSG:25832, ist dagegen ein projiziertes Koordinatenreferenzsystem. Eine Position wird mit Ostwert und Nordwert in Metern beschrieben.
Das ist für viele Planungs-, Vermessungs- und GIS-Prozesse praktisch, weil Entfernungen und Geometrien in einem metrischen Koordinatenraum verarbeitet werden.
Der Netzknoten Navigator stellt deshalb WGS84 in Dezimaldarstellung und DMS sowie ETRS89/UTM32 bereit.
Ein technisches Detail ist wichtig: Deutschland berührt nach den bundesweiten technischen Vorgaben die UTM-Zonen 31, 32 und 33. EPSG:25832 bezeichnet ausdrücklich Zone 32 mit Ost-Nord-Achsenreihenfolge.
Für eine Datenübergabe sollte deshalb immer bekannt sein, welches Koordinatenreferenzsystem das Zielsystem erwartet. „UTM“ allein ist keine vollständige Spezifikation.
Was läuft bei Koordinatentransformationen üblicherweise falsch?
Ein Klassiker ist die fehlende EPSG-Angabe.
In einer CSV-Datei stehen zwei Zahlen, aber niemand weiß mehr, ob es sich um Länge und Breite, Ost- und Nordwert oder sogar um ein historisches Gauß-Krüger-System handelt.
Ebenso häufig werden Achsen vertauscht.
WGS84 wird in vielen technischen Formaten als Longitude, Latitude gespeichert, während Benutzer im Gespräch häufig Latitude zuerst nennen. Bei projizierten Systemen wiederum geht es um Easting und Northing.
Ein weiterer Fehler entsteht, wenn Koordinaten einfach mathematisch umformatiert werden, obwohl eigentlich eine Transformation zwischen unterschiedlichen Bezugssystemen erforderlich wäre.
Der Navigator hält deshalb Koordinatenformat und Referenzsystem als Teil derselben Position zusammen.
Der praktische Vorteil ist weniger das Anzeigen zusätzlicher Zahlen. Entscheidend ist, dass der Benutzer weiß, welche Zahlen er gerade kopiert.
Welche technischen Funktionen gehören zu welchem Arbeitsschritt?
| Ausgangssituation | Technische Funktion | Fachliches Ergebnis | Typische Weiterverwendung |
|---|---|---|---|
| GPS oder WGS84 | Location Resolver | Straße, Abschnitt, Netzknoten, Station | Arbeitsvorbereitung, Dokumentation |
| Kartenpunkt | Spatial Matching | mögliche Netzbezüge | Prüfung unbekannter Einsatzstelle |
| Abschnitt plus Station | Reverse Resolver | geografische Koordinate | Karte, Navigation, Außendienst |
| Netzreferenz | Abschnittsgeometrie | Verlauf des Netzabschnitts | Baustellenbereich, GIS |
| Koordinate | CRS-Transformation | WGS84, DMS, ETRS89/UTM32 | Planung, Vermessung, Datenaustausch |
| einzelne Position | Sharing | permanenter Link oder QR-Code | Bauleitung, Kolonne |
| CSV-Datei | Batch Resolver | viele Netzreferenzen oder Koordinaten | Rahmenvertrag, Bestandsdaten |
| Fachergebnis | GeoJSON-Export | Geometrie plus Attribute | GIS und Kartenanwendungen |
| Fachergebnis | OKSTRA-Export | standardisierte Straßenobjekte | Fachverfahren |
| Fremdsystem | API | strukturierter Straßenkontext | Portal, ERP, GIS, mobile App |
| Assistenzsystem | MCP | aufrufbare Road-Network-Tools | assistierte Fachprozesse |
Warum sind Quelle, Datenstand und Confidence technische Funktionen und keine Dekoration?
Straßendaten kommen nicht aus einer einzigen statischen Datenbank.
Daten werden durch unterschiedliche Landesverwaltungen gepflegt und zu unterschiedlichen Zeitpunkten fortgeschrieben. Attribute können regional variieren.
Deshalb reicht es bei einem professionellen Ergebnis nicht, ausschließlich den ermittelten Stationswert anzuzeigen.
Der Navigator kann zusätzlich festhalten, aus welcher Quelle das Ergebnis stammt, welchen Datenstand die verwendete Datenbasis besitzt und wie eindeutig die Zuordnung war.
Die Confidence ist dabei keine Garantie auf fachliche Richtigkeit. Sie beschreibt vielmehr die Qualität beziehungsweise Sicherheit der automatischen Zuordnung.
Ebenso wichtig sind Ambiguitäten. Gibt es mehrere plausible Ergebnisse, sollte dies als eigener Zustand behandelt werden.
Und schließlich gibt es Data Gaps. Wenn eine regionale Quelle eine benötigte Information nicht enthält, sollte die Software keinen Wert erfinden.
Gerade diese Zustände unterscheiden einen fachlichen Resolver von einer einfachen „Nearest Line“-Abfrage.
Was bedeutet regionale Capability im Netzknoten Navigator?
Nicht jedes Bundesland stellt dieselben Fachinformationen in identischer Form bereit.
Deshalb besitzt eine bundesweite Anwendung idealerweise kein starres Versprechen wie „jede Funktion funktioniert überall gleich“.
Stattdessen kann sie für einen Datenraum beschreiben, welche Fähigkeiten tatsächlich vorhanden sind.
Eine solche Capability kann beispielsweise aussagen, ob Stationierung aufgelöst werden kann, ob Betriebskilometer verfügbar sind, welche Bauwerksinformationen existieren oder welche Exporte fachlich unterstützt werden.
Für den Benutzer wirkt das zunächst wie ein technisches Detail.
Im Betrieb ist es wichtig, weil dadurch zwischen „Funktion existiert nicht“ und „die benötigten Quelldaten sind für diese Region nicht vorhanden“ unterschieden werden kann.
Das erleichtert auch Integrationen. Eine API kann vor einer Verarbeitung prüfen, welche Funktionen im betreffenden Datenraum verfügbar sind.
Warum speichert der Navigator den Datenstand einer geteilten Position?
Straßennetze verändern sich.
Ein neuer Kreisverkehr kann einen neuen Netzknoten erzeugen. Ein Abschnitt wird geteilt. Eine Straße wird umgestuft. Geometrien werden korrigiert.
Würde ein alter Projektlink Jahre später automatisch mit dem dann aktuellen Netz neu berechnet, könnte derselbe Link plötzlich eine andere Referenz anzeigen.
Für professionelle Dokumentation ist das problematisch.
Deshalb ist es sinnvoll, geteilte oder gespeicherte Ergebnisse mit dem ursprünglichen Datenstand zu verbinden.
Der Nutzer kann später nachvollziehen, auf welcher Netzversion eine damalige Zuordnung beruhte.
Aktualisierte Daten werden dadurch nicht verhindert. Sie überschreiben lediglich nicht stillschweigend den historischen Kontext eines bereits verwendeten Ergebnisses.
Wie funktioniert CSV-Batch-Verarbeitung technisch?
Die Einzelsuche arbeitet synchron mit einem Standort.
Batch-Verarbeitung hat andere Anforderungen.
Eine CSV-Datei kann hunderte oder tausende Zeilen enthalten. Spaltennamen unterscheiden sich zwischen Auftraggebern. Einzelne Koordinaten können fehlen oder fehlerhaft formatiert sein. Manche Positionen lassen sich eindeutig zuordnen, andere nicht.
Der Navigator benötigt deshalb zunächst ein Spalten-Mapping. Der Anwender beziehungsweise der Importprozess legt fest, welche Spalte Latitude, Longitude, Station, Straße oder andere Eingabewerte enthält.
Anschließend wird jede Zeile als eigenständiger Verarbeitungsvorgang behandelt.
Das ist wichtig für die Fehlerisolierung.
Eine ungültige Zeile sollte nicht dazu führen, dass 999 korrekte Zeilen verworfen werden. Erfolgreiche Ergebnisse, Ambiguitäten und Fehler lassen sich getrennt behandeln.
Für professionelle Datenverarbeitung ist dieses Row-Level-Fehlermodell wesentlich robuster als ein Alles-oder-nichts-Import.
Warum gibt es CSV und GeoJSON als unterschiedliche Exporte?
CSV und GeoJSON lösen unterschiedliche Aufgaben.
CSV ist tabellarisch. Es lässt sich einfach in Excel, BI-Anwendungen, Datenbanken oder vielen Fachverfahren weiterverarbeiten.
GeoJSON ist dagegen ein Geodatenformat.
Nach RFC 7946 kann GeoJSON Geometrien, Features und FeatureCollections beschreiben. Der Standard definiert sieben konkrete Geometrietypen, darunter Point, LineString, Polygon sowie deren Multi-Varianten und GeometryCollection.
Für den Netzknoten Navigator bedeutet das beispielsweise, dass ein Standort als Feature mit Punktgeometrie und zusätzlichen Eigenschaften exportiert werden kann. Ein Abschnitt kann als Liniengeometrie in einem GIS weiterverarbeitet werden.
RFC 7946 verwendet WGS84-Geokoordinaten in Dezimalgrad. Das ist bei der technischen Weiterverarbeitung relevant und sollte nicht mit einem beliebigen UTM-GeoJSON verwechselt werden.
Wofür wird OKSTRA benötigt?
GeoJSON ist hervorragend für allgemeine Geodaten. Es kennt aber keine deutsche Fachsemantik für Netzknoten, Straßenpunkte oder andere Objekte des Straßen- und Verkehrswesens.
Hier kommt OKSTRA, der Objektkatalog für das Straßen- und Verkehrswesen, ins Spiel.
OKSTRA definiert ein fachliches Datenmodell für den standardisierten Austausch straßenbezogener Informationen. Dazu gehören neben Geometrien auch die fachlichen Beziehungen zwischen Objekten.
Die aktuelle veröffentlichte OKSTRA-Version ist 2.023 und wurde am 27. Mai 2026 verabschiedet.
Der Netzknoten Navigator sieht für geeignete Datenräume einen fachlich validierten OKSTRA-Export vor. Eine XSD-Prüfung kann dabei kontrollieren, ob die erzeugte XML-Struktur dem vorgesehenen Schema entspricht.
Das ist technisch anspruchsvoller als ein CSV-Download, eröffnet aber die Weitergabe an echte Straßenfachverfahren.
Was bedeutet Provenienz im Export?
Provenienz beantwortet die Frage: Woher stammt dieser Wert?
Bei einer Netzreferenz kann das beispielsweise bedeuten, welcher Quelldatensatz verwendet wurde, welchen Stand dieser besaß, welche Auflösungsmethode zum Einsatz kam und ob das Ergebnis eindeutig war.
Diese Informationen sollten beim Export nicht zwangsläufig verloren gehen.
Eine CSV kann neben Straße und Station zusätzliche Statusspalten enthalten. Ein GeoJSON-Feature kann entsprechende Eigenschaften tragen. Auch eine API-Antwort kann Provenienzinformationen strukturiert liefern.
Das wird spätestens dann wichtig, wenn Datensätze später zusammengeführt oder automatisiert weiterverarbeitet werden.
Eine Position ohne Herkunft sieht zwar technisch vollständig aus, lässt sich bei einer späteren Abweichung aber wesentlich schlechter prüfen.
Wie ist die Road Network Intelligence API gedacht?
Die Web-App ist nur eine Benutzeroberfläche auf der fachlichen Straßenlogik.
Für Unternehmen mit eigenen Systemen ist deshalb eine API sinnvoll.
Eine Road Network Intelligence API kann beispielsweise Operationen anbieten, um eine Koordinate aufzulösen, eine Stationierung geografisch zu bestimmen oder den Netzkontext einer Position abzurufen.
Wichtig ist dabei die Versionierung.
Wenn sich intern Datenmodelle oder Algorithmen weiterentwickeln, darf eine bestehende Integration nicht unkontrolliert ihr Verhalten ändern.
Eine versionierte Schnittstelle schafft dafür einen technischen Vertrag.
Ebenso relevant sind Capability-Abfragen. Ein aufrufendes System kann dadurch zunächst feststellen, ob eine bestimmte Fachfunktion für den gewünschten Datenraum unterstützt wird.
Für ein mittelständisches Verkehrssicherungsunternehmen wird aus dem Navigator damit kein abgeschlossenes Inselwerkzeug, sondern ein Fachdienst, der auch in Disposition, Kundenportal, Kontrollfahrt oder GIS eingebunden werden kann.
Was ist MCP und warum gehört es zu einer Straßenreferenzierungs-App?
MCP steht für Model Context Protocol.
Vereinfacht gesagt ermöglicht es kompatiblen Assistenzsystemen, definierte Werkzeuge mit strukturierten Ein- und Ausgaben aufzurufen.
Für den Netzknoten Navigator bedeutet das: Ein Assistenzsystem muss nicht selbst erraten, welcher Netzknoten zu einer Koordinate gehört.
Es kann eine dafür vorgesehene Fachfunktion verwenden, beispielsweise find_net_node, find_road_segment, resolve_location, resolve_stationing oder get_network_context.
Das aktuelle MCP-Protokoll wurde 2026 technisch weiterentwickelt und besitzt seit der Spezifikation vom 28. Juli 2026 einen zustandslosen Protokollkern für HTTP-basierte Aufrufe.
Für Vextario ist aber weniger die Protokollarchitektur entscheidend als das Grundprinzip: Die Fachberechnung verbleibt in der Road-Network-Engine. Das Sprachmodell bedient sie lediglich.
Warum sollte ein KI-System Netzknoten nicht selbst „ermitteln“?
Weil eine fachliche Straßenreferenz kein Sprachproblem ist.
Ein Sprachmodell kann erklären, was ein Netzknoten ist. Es sollte aber nicht aus allgemeinen Kartendaten oder statistischer Wahrscheinlichkeit eine Stationierung erfinden.
Die eigentliche Position muss aus dafür vorgesehenen Geodaten und einer deterministischen beziehungsweise nachvollziehbaren Auflösungslogik stammen.
MCP trennt diese Rollen sauber.
Das Assistenzsystem versteht beispielsweise die Anfrage „Welche Netzreferenz gehört zu diesem Baustellenpunkt?“.
Der Navigator beziehungsweise dessen Fachfunktion beantwortet anschließend die geodatenbezogene Frage.
Das ist besonders für sicherheitsnahe Prozesse sinnvoll. Automatisierung kann den Arbeitsablauf beschleunigen, ersetzt aber nicht die fachliche Datenbasis.
Welche technischen Fehler sollte ein professioneller Straßenresolver vermeiden?
In der Praxis wiederholen sich einige Probleme.
Der geometrisch nächste Straßenabschnitt wird automatisch als richtiger Abschnitt angenommen. Fahrtrichtung und Stationierungsrichtung werden gleichgesetzt. Koordinaten werden ohne CRS-Kennung exportiert. Longitude und Latitude werden vertauscht. Fehlende Fachdaten werden mit vermeintlich plausiblen Werten ergänzt. Ein einzelner Fehler beendet einen kompletten Batch. Aktualisierte Daten überschreiben historische Projektreferenzen.
Der Netzknoten Navigator ist konzeptionell genau auf solche Fälle ausgerichtet.
Mehrdeutigkeiten bleiben sichtbar. Fehlende Daten bleiben fehlend. Provenienz wird mitgeführt. Batch-Fehler werden zeilenbezogen behandelt. Regionale Funktionen sind als Capabilities modelliert. Datenstände können nachvollzogen werden.
Das klingt technischer als eine gewöhnliche Kartenanwendung.
Für eine Fachanwendung ist es aber gerade der Unterschied zwischen einem hübschen Kartenpunkt und einem belastbaren Datenprozess.
Wie passt die Technik in den Alltag eines Verkehrssicherungsunternehmens?
Die meisten Anwender werden weder EPSG-Codes noch lineare Referenzierungsmodelle im Kopf haben wollen.
Das müssen sie auch nicht.
Der Bauleiter wählt eine Position und bekommt den Straßenbezug. Die Arbeitsvorbereitung gibt Abschnitt und Station ein und erhält den Kartenpunkt. Der Mitarbeiter draußen scannt einen QR-Code und startet die Navigation. Ein Datenverantwortlicher verarbeitet später 500 Positionen per CSV. Die IT bindet dieselbe Fachlogik über eine API ein.
Die technische Tiefe befindet sich unter diesen Abläufen.
Gerade das ist für mittelständische Unternehmen sinnvoll. Ein spezialisiertes Fachmodell muss nicht bedeuten, dass jeder Anwender ein GIS-Spezialist sein muss.
Weitere Anwendungen für Verkehrssicherung und operative Straßenprozesse bündelt die Vextario Produktfamilie Verkehrssicherung:
Warum ist der Netzknoten Navigator technisch mehr als eine Netzknotensuche?
Weil der Netzknoten nur ein Element des gesamten Modells ist.
Die eigentliche Aufgabe besteht darin, zwischen realem Ort, Koordinate und fachlichem Straßennetz zuverlässig zu übersetzen.
Dafür müssen Geometrie, Stationierung, Richtung, regionale Daten, Koordinatenreferenzsysteme und Datenstände zusammengeführt werden. Für professionelle Nutzung kommen Batch-Verarbeitung, standardisierte Exporte und Schnittstellen hinzu.
Aus einer einzelnen Web-Suche wird dadurch eine Road-Location-Engine.
Der Nutzen liegt letztlich darin, dass dieselbe fachliche Logik an verschiedenen Stellen eingesetzt werden kann: auf der Karte, im Smartphone, in einer CSV-Verarbeitung, im GIS, über die API oder in einem assistierten MCP-Workflow.
Produktseite: Vextario Netzknoten Navigator
https://netzknoten-navigator.vextario.com/
Hersteller: KrambergAI GmbH
https://krambergai.com/
Quellen der verwendeten Kennzahlen
Bundesamt für Kartographie und Geodäsie: Technische Regelungen zur Georeferenzierung
Verwendete Kennzahl: Für Deutschland werden UTM-Konventionen für die Zonen 31, 32 und 33 beschrieben.
https://www.bkg.bund.de/SharedDocs/Downloads/BKG/DE/Downloads-Allgemein/TR-BGeoRG.pdf
RFC Editor / IETF: RFC 7946, The GeoJSON Format
Verwendete Kennzahl: GeoJSON definiert sieben konkrete Geometrietypen.
https://www.rfc-editor.org/info/rfc7946/
OKSTRA: Aktuelle Version des Objektkatalogs für das Straßen- und Verkehrswesen
Verwendete Kennzahl: aktuelle Version 2.023, verabschiedet am 27. Mai 2026.
https://www.okstra.de/schema.html
Interessante Links
Landesbetrieb Straßenwesen Brandenburg: Straßeninformationsbank Brandenburg
Ausführliche Erläuterung von Netzknoten, Abschnitt, Stationierungsrichtung und ASB-basiertem Ordnungssystem.
https://www.ls.brandenburg.de/ls/de/service/strasseninformationsbank-brandenburg/
GovData: Klassifiziertes Straßennetz Sachsen
Amtliche Beschreibung von Netzknoten, Nullpunkten, Abschnitten, Stationierung und den verfügbaren Austauschformaten.
https://www.govdata.de/suche/daten/gdi-sbv-klassifiziertes-strassennetz-sachsen-dsf3611
Model Context Protocol: aktuelle Spezifikation 2026-07-28
Technischer Hintergrund zum Protokoll, über das spezialisierte Fachfunktionen für kompatible Assistenzsysteme bereitgestellt werden können.
https://blog.modelcontextprotocol.io/posts/2026-07-28/
Was ist der Unterschied zwischen Netzknoten und Nullpunkt?
Ein Netzknoten beschreibt einen Knotenbereich im Straßennetz, beispielsweise an einer Verknüpfung klassifizierter Straßen. Ein komplexer Netzknoten kann mehrere Nullpunkte enthalten. Nullpunkte bilden die konkreten Anfangs- und Endbezüge von Abschnitten oder Ästen. Für eine technisch exakte Referenzierung reicht deshalb die Netzknotennummer allein nicht in jeder Netzsituation aus.
Was bedeutet Stationierung innerhalb eines Straßenabschnitts?
Die Station beschreibt die Lage eines Punktes entlang eines definierten Abschnitts. Sie wird in Stationierungsrichtung vom Abschnittsanfang aus bestimmt. Ein Wert wie 1,250 bedeutet deshalb nicht einfach „Kilometer 1,250 der gesamten Straße“, sondern benötigt den zugehörigen Abschnitt beziehungsweise Netzbezug, damit die Position im Straßennetz eindeutig interpretiert werden kann.
Was ist der Unterschied zwischen Stationierungsrichtung und Fahrtrichtung?
Die Stationierungsrichtung gehört zum fachlichen Ordnungssystem des Straßenabschnitts und verläuft vom VON- zum NACH-Bezug. Die Fahrtrichtung beschreibt dagegen die tatsächliche Bewegungsrichtung eines Fahrzeugs. Ein Fahrzeug kann einen Abschnitt entgegen der Stationierungsrichtung befahren. Gerade bei Richtungsfahrbahnen und Anschlussstellen dürfen beide Begriffe deshalb nicht automatisch gleichgesetzt werden.
Warum verwendet der Navigator EPSG-Codes?
Ein EPSG-Code identifiziert ein Koordinatenreferenzsystem eindeutig. Dadurch ist beispielsweise erkennbar, ob zwei Zahlen WGS84-Koordinaten oder metrische ETRS89/UTM-Werte darstellen. Der Netzknoten Navigator unterstützt unter anderem EPSG:4326 für geografische WGS84-Koordinaten und EPSG:25832 für ETRS89/UTM Zone 32N, wodurch Datenübergaben technisch besser spezifiziert werden können.
Was bedeutet Confidence bei einer Straßenreferenz?
Confidence beschreibt, wie belastbar beziehungsweise eindeutig eine automatische Zuordnung aus Sicht der Auflösungslogik ist. Der Wert ersetzt keine fachliche Prüfung und ist keine Garantie. Besonders an Rampen, komplexen Knoten oder parallelen Fahrbahnen können mehrere Netzobjekte plausibel sein. Der Navigator kann solche Situationen deshalb zusätzlich als Mehrdeutigkeit ausweisen, statt nur einen Treffer anzuzeigen.
Was ist eine regionale Capability?
Eine Capability beschreibt, welche Fachfunktion für einen bestimmten regionalen Datenraum tatsächlich verfügbar ist. So kann beispielsweise Stationierung vorhanden sein, während Betriebskilometer oder bestimmte Bauwerksinformationen fehlen. Diese Trennung verhindert, dass eine bundesweite Oberfläche Funktionen vortäuscht, die die zugrunde liegenden Landesdaten fachlich nicht unterstützen, und erleichtert gleichzeitig die maschinenlesbare Prüfung über Schnittstellen.
Worin unterscheiden sich CSV und GeoJSON beim Export?
CSV ist ein tabellarisches Format und eignet sich besonders für Excel, Datenbanken, BI und klassische Fachverfahren. GeoJSON speichert zusätzlich Geometrien und Eigenschaften in einer standardisierten JSON-Struktur und eignet sich daher für GIS- und Kartenanwendungen. Der Netzknoten Navigator kann dadurch je nach Zielsystem entweder tabellarische Fachdaten oder direkt geografisch nutzbare Objekte bereitstellen.
Warum gibt es zusätzlich einen OKSTRA-Export?
OKSTRA ist ein deutsches Fachmodell für Daten des Straßen- und Verkehrswesens. Anders als ein allgemeines Geodatenformat kann es straßenspezifische Objektarten und Beziehungen standardisiert abbilden. Für geeignete Datenräume ermöglicht ein OKSTRA-Export deshalb die Weitergabe an spezialisierte Fachverfahren. Eine Schema-Validierung kann zusätzlich prüfen, ob die erzeugte XML-Struktur dem vorgesehenen Standard entspricht.
Wie verhindert die Batch-Verarbeitung, dass eine fehlerhafte Zeile alles stoppt?
Jede Zeile eines Imports wird als eigenständiger Verarbeitungsvorgang behandelt. Erfolgreiche Auflösungen, fachliche Mehrdeutigkeiten und technische Fehler können getrennt ausgewiesen werden. Dadurch muss eine Datei mit beispielsweise mehreren hundert Standorten nicht vollständig verworfen werden, wenn einzelne Koordinaten fehlen, falsch formatiert sind oder keinem eindeutigen Straßenabschnitt zugeordnet werden können.
Warum gibt es neben der API noch MCP?
Die API richtet sich primär an klassische Softwareintegrationen. MCP ermöglicht kompatiblen Assistenzsystemen, dieselben Fachfunktionen als definierte Tools aufzurufen. Ein Sprachmodell muss eine Netzreferenz dadurch nicht selbst bestimmen. Es kann beispielsweise resolve_location oder resolve_stationing aufrufen, während die eigentliche geodatenbezogene Berechnung weiterhin von der spezialisierten Road-Network-Engine durchgeführt wird.
