BEZIEHT SICH AUF TECHNICHAL GUIDELINE VERSION 3.0.1

1. Ziel des Steckbriefs

Der Steckbrief soll geodatenhaltenden Stellen eine schnelle Entscheidungsgrundlage bezüglich der INSPIRE-Betroffenheit ermöglichen. Im Steckbrief wird das jeweilige INSPIRE-Thema grob erläutert, zu anderen INSPIRE-Themen abgegrenzt, die Objektarten beschrieben und eine Fragen- und Antwortensammlung zusammengestellt.

Der Steckbrief soll zunächst nicht dazu dienen, die Prozesse der Umsetzung zu beschreiben. Dafür sollte die Datenspezifikation, bzw. die fachlichen Leitfäden zur technischen Umsetzung, herangezogen werden.

2. Definition des Themas

Für die verschiedenen Transportarten gibt es verschiedene Zuständigkeiten. Entsprechend ist das Thema in die folgenden Unterthemen untergliedert:

  • Gemeinsame Transportelemente
  • Straßenverkehrsnetz
  • Schienenverkehrsnetz
  • Wasserverkehrsnetz
  • Luftverkehrsnetz
  • Seilbahnen

Daten und Dienste zu diesen Unterthemen sind von den entsprechenden geodatenhaltenden Stellen INSPIRE-konform bereitzustellen. Die geforderten Objektarten und Datentypen werden in den Anwendungsschemata und in Tabellen im Dokument „D 2.8.1.7 INSPIRE Data Specification on Transport Networks – Guidelines“ 1 genau beschrieben.

Anwendungsbeispiele für Transportnetze sind: Bestandsverwaltung, Kapazitätsplanung, Entwurf, Planung und Bauausführung, Notfallplanung und Notfalleinsätze, Umweltverträglichkeitsprüfungen, Flächenmanagement, Durchsatzmodellierung, Informationssysteme in Fahrzeugen, Störungsmanagement, Routenplanung, Wartung und Instandsetzung, Navigation, Betriebssteuerung, Umleitungen, Trassierung, Verkehrslenkung und Verkehrsbeeinflussung, etc.

Alleine aus den Anwendungsbeispielen – insbesondere in Verbindung mit Fragen des Umweltschutzes – wird deutlich, dass das Thema Transportnetze eines der wichtigsten Themen des Anhangs I ist.

Alle Transportnetze werden als verbundene punktförmige Elemente (Knoten; engl.: Transport Nodes) und linienförmige Elemente (Kanten, engl.: Transport Links) dargestellt, wobei die Knoten Endpunkte und Verbindungspunkte darstellen. Als Ergänzung zu punktund linienförmigen Objekten können auch flächige Objekte eingebunden werden. Die allen gemeinsamen Elemente sind im Generischen Netzmodell definiert (Die Objektarten des Generischen Netzmodells sind u.a. in Kapitel 5 des Anhang I des Entwurfs der Durchführungsbestimmung näher definiert.). 

Für die fünf Unterthemen werden zusätzlich spezielle Objektarten und Eigenschaften definiert. In Übereinstimmung mit Artikel 10(2) der INSPIRE-Richtlinie, sollen die nationalen Verkehrsnetze auch auf europäischer Ebene übergangslos definiert, d.h. sie sollen an den Staatengrenzen verknüpft sein.

Verkehrsnetzdaten umfassen topographische Objekte mit Bezug zu Straßen-, Schienen-, Wasser- und Luftverkehr. Es ist wichtig, dass die Objekte, wo angebracht, Netze bilden und dass Übergänge zwischen diesen Netzen definiert werden, wie beispielsweise multi-modale Verknüpfungspunkte. Dies ist insbesondere auf lokaler Ebene wichtig, um die Anforderungen für Intelligente Verkehrssysteme wie Location Based Services (LBS), Navigationsdiensten und Telematikanwendungen zu erfüllen. Dieser Ansatz erlaubt den Nutzern, eigene Informationen (z.B. Straßenzustandsberichte) mit den INSPIRE-konform veröffentlichten Transportnetzwerken zu verknüpfen.

Eine in Abbildung 1 dargestellte Verbindung zwischen verschiedenen Netzen nennt man „intermodal“. Üblicherweise sind für ein Straßennetz und für ein Schienennetz unterschiedliche Datenhalter zuständig und bezüglich der Verbindung sind Abstimmungen erforderlich. Intermodale Verbindungen unterstützen die Routenplanung, Navigation und verwandte Anwendungen. Intermodale Verbindungen sind optional.

Da keine allgemein anerkannten Standards für intermodale Verbindungen existieren, gibt INSPIRE ein einfaches Verfahren mit Querverweisen (cross references) vor. Die einzige Anforderung von INSPIRE ist, dass eine intermodale Verbindung sich nicht auf zwei Objekte im selben Netzwerk beziehen darf oder dass ein fremdes Element aus einem Netzwerk zweimal angesprochen wird.

Das Verkehrsnetz sollte auch die Abbildung des Verkehrsflusses zur Schaffung von Navigationsdiensten ermöglichen.

3. Abgrenzung zu anderen INSPIRE-Themen

keine Angaben

4. Inhalt des Themas

Für die Unterthemen

  • Gemeinsame Transportelemente
  • Flugverkehrsnetz
  • Seilbahnverkehrsnetz
  • Wasserstraßenverkehrsnetz

liegt noch kein Steckbrief vor.

Die Unterthemen Verkehrsnetze und Schienenverkehrsnetz sind in den folgenden Abschnitten im Detail beschrieben:

4A.1 Verkehrsnetze

Unterthema Straßenverkehrsnetz:

4A.2 Zusammenfassung Datenmodell Verkehrsnetze

Das Anwendungsschema Straßenverkehrsnetz verwendet ein Knoten-Kanten-Modell um ein Straßenverkehrsnetz abzubilden. Dazu bindet das Anwendungsschema Objektklassen aus einem allgemeinen Verkehrsnetz-Modell (Common Transport Schema) ein und definiert darüber hinaus eigene Objektklassen um spezielle Objekte und Eigenschaften eines Straßennetzes wie beispielsweise die Baulast oder die Richtung des Verkehrsflusses, die mittels Linearer Referenzierung auf ganze Bereiche des Netzes oder einzelne Abschnitte oder Teile von Abschnitten bezogen werden können.

Die wichtigsten Ausprägungen, die für die Elemente des Straßennetzes modelliert worden, sind:

  • Räumliche Ausprägung: Geometrische (Punkt, Linie und Fläche (topographisch) Darstellung der verschiedenen Netzelemente. Typischerweise wird das Straßennetz als Netzwerk von verknüpften linearen Objekten (Kanten oder Abschnitte) mit jeweils einem Knoten an Anfang und Ende (an Kreuzungspunkten oder Straßenenden) dargestellt. Weiterhin werden andere Objekte (neben den Knoten und Kanten) mit einer bestimmten Funktion im Straßennetz in einem Straßendatensatz abgebildet. Die Konnektivität der Netzelemente innerhalb Straßennetzes ist eine grundsätzliche Anforderung. Zusätzlich kann optional eine Verknüpfung mit Elementen anderer Netze (z.B. einem Schienenverkehrsnetz) hergestellt werden
  • Zeitliche Ausprägung: Alle Objekte im Straßennetz sollten einen Gültigkeitszeitraum besitzen (beispielsweise die Beschreibung seit wann ein Objekt in der Realität existiert). Und zusätzlich optional Informationen wann die Objektdaten in den Datensatz aufgenommen, dort verändert oder gelöscht worden sind.
  • Thematische Ausprägung: Das Datenmodell enthält verschiedene thematische Attribute des Netzes wie z.B. den Baulastträger oder Geschwindigkeitsbeschränkungen.

Hinweise für die Umsetzung

Potentiell geodatenhaltende Stellen sind unter anderem:

  • Bundesministerium für Verkehr, Bau und Stadtentwicklung (BMVBS)
  • Bundesanstalt für Straßenwesen (Bast)
  • Straßenbauverwaltungen der Länder und Kommunen

Es wird davon ausgegangen, dass die INSPIRE-relevanten Daten in den Straßendaten- /Straßeninformationsbanken der Länder und Kommunen in weiten Teilen vorhanden sind. Geodatenhaltende Stellen sind für das klassifizierte Straßennetz die Landesstraßenbauverwaltungen (für Autobahnen, Bundesstraßen, Landes-/Staatsstraßen sowie teilweise Kreisstraßen, wenn diese im Auftrag der Kreise betreiben werden), die Straßenbauverwaltungen der Kreise für die Kreisstraßen (wo diese nicht von einem Bundesland betrieben werden) sowie die Straßenbauverwaltungen der Kommunen (Städte und Gemeinden) für das restliche kommunale Straßennetz

Die INSPIRE-Daten können u.U. aus Objektarten einer Straßendatenhaltung nach OKSTRA bzw. OKSTRA kommunal abgeleitet werden. Als GML-Applikationsschemata sind sowohl OKSTRA als auch OKSTRA kommunal geeignet über INSPIRE-konforme Web Dienste veröffentlicht zu werden. Hinweise dazu sind in der unter Teil 3 dargestellten Tabelle aufgeführt.

Für eine bundeseinheitliche Umsetzung der Datenbereitstellung von Straßennetzdaten für INSPIRE auf Bund/Länder-Ebene sind folgende Projektgruppen unter dem Dach des BundLänder-Ausschusses IT-Koordinierung (IT-KO) (im Bereich des Straßenwesens) einzubinden: -

  • Projektgruppe Objektkatalog für das Straßen- und Verkehrswesen (PG OKSTRA)
  • Projektgruppe Anweisung Straßeninformationsbank (PG ASB)
  • Projektgruppe Datenaustausch

Auf kommunaler Ebene sind die entsprechenden Arbeitsgruppen der kommunalen Spitzenverbände im Straßen- und Verkehrswesens einzubinden.

4A.3 Objektarten Verkehrsnetze

Die folgende Tabelle zeigt die im Entwurf der Durchführungsbestimmung zur Interoperabilität von Geodaten und Geodatendiensten definierten Objektarten und Schlüsseltabellen für die Straßenverkehrsnetze. Für die Objektarten sind jeweils Hinweise zu ihrer möglichen Ableitung aus OKSTRA bzw. OKSTRA kommunal gegeben.

ObjektnameObjektname (englisch)DefinitionHinweise zu OKSTRA und OKSTRA kommunal
Objektarten Knoten-Kanten-Modell
StraßeRoadEine Gruppe von Straßenrouten und/ oder einzelnen Straßenabschnitten, die durch einen oder mehrere thematische(n) Bezeichner und/oder eine oder mehrere Eigenschaft(en) gekennzeichnet ist.BEISPIEL Straßen, die eine einheitliche offizielle Straßennummer haben (Bundesstraße B 57) oder touristische Routen, die durch einen spezifischen Namen gekennzeichnet sind (z.B. „Deutsche Märchenstraße“). Das Road-Objekt entspricht dem Strasse-Objekt des OKSTRA. Im OKSTRA kommunal ist die Objektart kommunale_Strasse definiert. Andere Straßen (wie z.B. touristische Routen) könnten im OKSTRA wie im OKSTRA kommunal aus der Objektart Route oder Netzbereich bzw. Teilnetz abgeleitet werden.
StraßenabschnittRoadLinkEin lineares Geo-Objekt, das die Geometrie und Konnektivität eines Straßenverkehrsnetzes zwischen zwei Punkten im Netzwerk beschreibt. Straßenabschnitte können Wege, Fahrradwege, Straßen mit einer Fahrbahn, Straßen mit mehreren Fahrbahnen und sogar Bewegungsbahnen über Verkehrsflächen sein.

Folgende Abbildungsmöglichkeiten aus dem OKSTRA sind möglich:

  • Ableitung der RoadLinks aus den Abschnitt_oder_Ast-Objekten. Problematisch ist hierbei, dass Abschnitte u.U. an den Nullpunkten der auftreffenden Äste zerschlagen werden müssen.
  • Ableitung der RoadLinks aus Abschnitten. Hierbei ist wiederum die oben genannte Anforderung einzuhalten. Problematisch wird dies, wenn die in einem Netzknoten zusammentreffenden Abschnitte an unterschiedlichen und relativ weit auseinanderliegenden Nullpunkten enden.
  • Ableitung der RoadLinks aus Straßenelementen. Diese Lösung liefert zwar eine geometrisch saubere Abbildung, aber es gelten hierbei die Vorbehalte hinsichtlich der Verfügbarkeit der Straßenelemente, der nur losen Kopplung von Straßenelementen zum NetzknotenStationierungssystem und der notwendigen Umreferenzierung von Fachdaten auf die Straßenelemente.
StraßenpunktRoadNodeEin punktförmiges GeoObjekt, das dazu verwendet wird, entweder die Konnektivität zwischen zwei Straßenabschnitten oder ein bedeutsames GeoObjekt wie eine Servicestation oder einen Kreisverkehr darzustellen.

RoadNode ist ein Punktobjekt mit einer Eigenschaft, die die Knotenform (als formOfRoadNodeAttribut) angibt (missing data ist zulässig). Die Knotenform entspricht nur sehr eingeschränkt der Knotenpunktsform und der Knotenart des OKSTRA. Die Knotenform aus INSPIRE deckt nämlich auch Situationen wie Plätze, Überführungen, Sackgassenenden und Bahnübergänge ab, während nur die Fälle fiktiver Knoten, Kreisverkehr und allgemein Junction (Einmündungen, Kreuzungen, planfreie Formen) aus OKSTRA-Daten ableitbar sind. Folgende Abbildungsmöglichkeiten aus dem OKSTRA sind möglich:

  • Ableitung der RoadNodes aus den Nullpunkten. Problematisch ist hierbei, dass die Nullpunkte in den OKSTRA-Datenbeständen keine eindeutige Geometrie haben müssen (mehrere Nullpunktsorte sind möglich).
  • Ableitung der RoadNodes aus den Netzknoten. Problematisch wird dies, wenn die in einem Netzknoten zusammentreffenden Abschnitte an unterschiedlichen und relativ weit auseinanderliegenden Nullpunkten enden. Bei dieser Abbildung geht offensichtlich auch die interne Struktur der Netzknoten verloren.
  • Ableitung der RoadNodes aus Verbindungspunkten. Diese Lösung liefert zwar eine geometrisch saubere Abbildung, aber es gelten hierbei die Vorbehalte hinsichtlich der Verfügbarkeit der Verbindungspunkte, der nur losen Kopplung von Verbindungspunkten zum Netzknoten.
EuropastraßeERoadEine Gruppe von Straßenrouten und/ oder einzelnen Straßenabschnitten, die eine Straße bilden, die Teil des internationalen Europastraßennetzes ist; diese Gruppe ist durch eine bestimmte Europastraßennummer gekennzeichnet.Im OKSTRA existiert für die Objektart Teilnetz_ASB eine Teilnetzklasse Europastraße. Über diese Klasse könnten die Straßen, die Europastraßen sind, herausgefiltert werden.
StraßenabschnittsfolgeRoadLinkSequenceEin lineares Geo-Objekt, das aus einer geordneten Gruppe von Straßenabschnitten besteht, die eine durchgehende Strecke ohne Abzweigungen in einem Straßenverkehrsnetz bildet. Das Element hat einen festgelegten Anfang und ein vorgegebenes Ende, und jede Position innerhalb der Straßenabschnittsfolge kann durch einen einzigen Parameter wie die Länge gekennzeichnet werden. Das lineare Geo-Objekt beschreibt ein Element des Straßenverkehrsnetzes, das durch einen oder mehrere thematische(n) Bezeichner und/ oder eine oder mehrere Eigenschaft(en) gekennzeichnet ist.Eine Straßenabschnittsfolge kann im OKSTRA wie im OKSTRA kommunal durch eine Route abgebildet werden.
StraßennameRoadNameDer Name der Straße, der ihm von der zuständigen Behörde zugewiesen wurde.Im OKSTRA sind keine Straßennamen vorgesehen. Im OKSTRA kommunal besitzt die Objektart kommunale_Strasse das Attribut Bezeichnung, welches den Straßennamen enthält.
Nutzungsart der StraßeFormOfWayEine Klassifikation, die auf den physischen Eigenschaften des Straßenabschnitts beruht [TWG TN, basierend auf EuroRoadS]. Beispiele: Autobahn, Radweg, Fußweg, KreisverkehrAbleitbar aus dem OKSTRA sind die Fälle SingleCarriageWay (einbahnig) und DualCarriageWay (zweibahnig) aus dem Objekt Bahnigkeit, Motorway (Autobahn) aus der Strassenklasse in Strassenbezeichnung, und SlipRoad (Objektart ist Ast). Im OKSTRA kommunal ist eine entsprechende Information nicht enthalten.
Funktionsklasse der StraßeFunctionalRoadClassEine Klassifikation, die auf der Bedeutung der Funktion beruht, die der Straße im Straßenverkehrsnetz zukommt.Nächste Näherung im OKSTRA wäre hier die Ableitung aus der Strassenklasse. Im OKSTRA kommunal existiert eine Objektart Strassenklasse_kommunal, die ausgewertet werden könnte
Kategorie der StraßenbefestigungRoadSurface CategoryKennzeichnung der Beschaffenheit des Belags eines zugehörigen Straßenelements. Zeigt an, ob eine Straße befestigt ist oder nicht.Unterscheidet nur zwischen unbefestigten und befestigten Straßen. Für das überörtliche Straßennetz gilt wohl immer „befestigt“. Im kommunalen Bereich gilt dies für die Fahrbahn von für den motorisierten Verkehr ebenfalls. Ansonsten müssten die Informationen zu den Aufbauschichten im Schema „bauliche Straßeneigenschaften“ ausgewertet werden.
Anzahl der FahrstreifenNumberOfLanesDie Anzahl der Fahrstreifen eines Straßenabschnitts.Die INSPIRE-Pflicht-Attribute direction und numberOfLanes können im OKSTRA aus Anzahl_Fahrstreifen gewonnen werden. Im OKSTRA kommunal könnten die relevanten Informationen nur durch Auswertung der Informationen zu den Querschnittsstreifen bzw. aus den Verkehrsflächen abgeleitet werden.
StraßenbreiteRoadWidthDie Breite der Straße, gemessen als Mittelwert.Könnte im OKSTRA entweder aus Fahrbahnbreite oder aus Trassenbreite gewonnen werden. Im OKSTRA kommunal könnte die Bereite entweder aus der Summe der Breiten der einzelnen Querschnittsstreifen (mittlere Breite) oder aus der Breite der Flächenobjekte abgeleitet werden.
GeschwindigkeitsbegrenzungSpeedLimitBegrenzung der Geschwindigkeit eines Fahrzeugs auf einer Straße.Die Attribute dieses Objektes können im OKSTRA aus Verkehrseinschränkung und den assoziierten Objekten Umfang_VES, Gueltigkeit_VES, Wochentag_VES abgeleitet werden. Generische Beschränkungen, z.B. in geschlossenen Ortschaften, können so nicht berücksichtigt werden. Im OKSTRA kommunal sind Daten zu Geschwindigkeitsbegrenzungen bisher nicht modelliert.
Objektarten Flächen
StraßenflächeRoadAreaDas Gelände innerhalb der Straßenränder einschließlich des Verkehrsbereichs und anderer Teile der Straße.Straßenränder einschließlich des Verkehrsbereichs und anderer Teile der Straße. INSPIRE kann neben achsenbezogenen Straßendaten auch geometrisch flächenhaft modellierte Straßen abbilden (wie auch der OKSTRA kommunal). Die entsprechenden Flächen-Objekte dienen zur Übertragung der Straßenfläche sowie zur Fläche, die für Fahrzeuge nutzbar ist. Im OKSTRA gibt es keine äquivalenten Strukturen.
StraßenverkehrsflächeVehicleTrafficAreaGelände, das den Teil der Straße darstellt, der für den normalen Fahrverkehr genutzt wird.INSPIRE kann neben achsenbezogenen Straßendaten auch geometrisch flächenhaft modellierte Straßen abbilden (wie auch der OKSTRA kommunal). Die entsprechenden Flächen-Objekte dienen zur Übertragung der Straßenfläche sowie zur Fläche, die für Fahrzeuge nutzbar ist. Im OKSTRA gibt es keine äquivalenten Strukturen.
ServicegeländeRoadServiceAreaEin Gelände, das an eine Straße angegliedert ist und dazu dient, bestimmte Funktionen im Bezug auf diese Straße zu erfüllen.Im OKSTRA wird zwar die Raststätte modelliert, jedoch nicht flächenhaft, sondern als Streckenobjekt. Im OKSTRA kommunal könnten Servicegelände theoretisch im Flächenmodell abgebildet werden, wobei dieses dafür aber nicht gedacht ist.
Art des VerkehrsservicesRoadServiceTypeBeschreibung der Art des Servicegeländes und der dazugehörigen Anlagen.Im OKSTRA wird die Art einer Rastanlage über die Schlüsseltabelle Art_der_Rastanlage angegeben. Die verfügbaren Arten im OKSTRA entsprechen aber nicht den Arten in INSPIRE. Im OKSTRA kommunal kann keine Art für ein Servicegelände angegeben werden.
Schlüsseltabellen

AreaConditionValueGebietsbedingungen, die Geschwindigkeitsbegrenzungen beeinflussen

MinMaxLaneValueIndikator, ob die Fahrstreifenanzahl ein Minimum- oder Maximalwert ist.

RoadPartValueIndikator, für welchen Teil der Straße der Wert für die Straßenbreite gilt (Fahrbahn oder gesamte befestigte Fläche).

RoadSurfaceCategoryValueArt der Befestigung (befestigt oder unbefestigt)

SpeedLimitMinMaxValuezeigt die Art einer Geschwindigkeitsbegrenzu ng an (z.B. maximale Geschwindigkeit, Mindestgeschwindigkeit, Richtgeschwindigkeit)

SpeedLimitSourceValueGibt die Quelle der Geschwindigkeitsbegrenzu ng an (z.B. festes Schild, variables Schild, implizite Geschwindigkeitsbegrenzu ng durch Verkehrsregeln wie 50 km/h Innerorts)

VehicleTypeValueFahrzeugtyp, für den eine Geschwindigkeitsbegrenzu ng gilt.

WeatherConditionValueWetterbedingung, bei denen Geschwindigkeitsbegrenzung gilt.

FormOfRoadNodeValueArt des Straßenpunktes

FormOfWayValueNutzungsart der Straße

FunctionalRoadClassValueStraßenklasse

RoadServiceTypeValueArt der Serviceeinrichtung (Bushaltestelle, Mautstation, Rastplatz, Parkierungsanlage)

ServiceFacility ValueArt der angebotenen Services an einer Serviceeinrichtung (z.B. Essen, Trinken, Tanken)

4B.1 Schienennetz

4B.2 Zusammenfassung Datenmodell Schienennetz

Abb. 3 stellt die wichtigsten Objektarten eines Schienennetzes dar. Für seine Modellierung wird ebenfalls ein Knoten-Kanten-Modell verwendet. Das Anwendungsschema leitet seine Objektklassen aus einem übergeordneten, allgemeinen Verkehrsnetz-Modell (Common Transport Schema) ab und ergänzt diese um spezielle Objekte und Attribute. Die Objektklassen des Schienennetzes sind zum einen Real World Objects (RWO), die ihren Raumbezug durch ihre Geo-Koordinaten erhalten. Weitere Objektklassen erhalten ihren Raumbezug durch Referenzierung auf geocodierte Objekte des Schienennetzes. Spezielle Eigenschaften definieren die Schienennetzelemente hinsichtlich Raum, Zeit und Themen:

  • Raum: Die Darstellung der verschiedenen Elemente erfolgt geometrisch über Punkt, (Poly-) Linie und Fläche. Flächen definieren dabei Bereiche an der Erdoberfläche, die punkt- und linienförmige RWOs des Schienennetzes räumlich beinhalten. Über die Verknüpfung von Kanten und/oder Abschnitten wird das Schienennetz dargestellt. Diese linearen Objekte werden an ihrem Anfang und Ende durch punktförmige Objekte (Knoten) begrenzt. Gleisstrecken können spurgenau oder als Zusammenfassung paralleler Gleise modelliert werden. Die Verbindung der Elemente innerhalb des Schienennetzes und die Verknüpfungsmöglichkeit zu anderen Netzen sind charakteristisch.
  • Zeit: Die Gültigkeit (von, bis) definiert die Existenz eines Elements in der Wirklichkeit. Zusätzliche Informationen geben Auskunft darüber wann ein Element in die Netzdaten aufgenommen, verändert oder gelöscht wurde. So können historische Fragestellungen beantwortet werden.
  • Themen: Die Datenvorhaltung von z.B. Eigentümer, Elektrifizierung, Entwurfsgeschwindigkeit und Anderen ermöglicht die thematische Filterung von Netzelementen.

Hinweise für die Umsetzung:

Die Inhaber der Schienennetze sind die potentiellen Lieferanten der benötigten Geodaten. Das Allgemeine Eisenbahngesetz unterscheidet zwischen Eisenbahnverkehrs- (EVU) und Eisenbahninfrastrukturunternehmen (EIU). EVU erbringen Eisenbahnverkehrsleistungen, EIU betreiben eine Eisenbahninfrastruktur. Organisiert sind beide entweder als öffentliche Einrichtungen oder privatrechtliche Unternehmen, auch nichtbundeseigene Bahnen (NEBahnen) genannt.

Damit fallen alle direkten und mittelbaren, bundeseigenen EIU in den Anwendungsbereich der INSPIRE-Richtlinie. NE-Bahnen, die sich im öffentlichen Eigentum von z.B. Kommunen oder Gebietskörperschaften befinden, fallen ebenfalls darunter. Auch die kommunalen Verkehrsunternehmen mit ihren Straßen-, U- und Stadtbahnen sind dem Anwendungsbereich zuzurechnen. Keine rechtliche Verpflichtung besteht z.Zt. für NEBahnen im privaten Eigentum.

Nach heutigem Kenntnisstand ist nicht davon auszugehen, dass die betroffenen Organisationen ihre Infrastrukturdaten schon flächendeckend digital aufgebaut haben und wenn, dann in proprietären Datenformaten. In Deutschland gibt es aber zwei Initiativen mit wachsender Bedeutung, welche jeweils ein neutrales Schnittstellenformat für den Datenaustausch im Schienenverkehr entwickelt haben. Dies sind IDMVU und railML. Beiden liegt ein Objektklassenmodell zugrunde. IDMVU verwendet dabei wie INSPIRE GMLApplikationsschemata, railML setzt auf natives XML.

4B.3 Zusammenfassung  Objektarten Schienennetz

Die Durchführungsbestimmung ISDSS definiert für die Schienennetze Objektklassen und deren Attribute. Sie dienen der Interoperabilität der Geodaten und der noch aufzubauenden Geodatendienste. Die nachfolgende Tabelle listet die Objektklassen des InspireSchienennetzmodells auf, erläutert die Bedeutung der einzelnen Klassen und gibt Hinweise zur Ableitung dieser Objektklassen aus den Austauschformaten IDMVU und railML.

ObjektnameObjektname (englisch)DefinitionHinweise zu IDMVU und railML
Objektarten Knoten-KantenModell
Punktförmige GEO-Objekte
GleisknotenRailwayNodeEin Gleisknoten bezeichnet einen signifikanten Punkt entlang des Schienennetzes oder die Kreuzung von Gleisen. Die genaue Funktion eines Gleisknotens (Gleisanfang, Gleisende, Weiche, Pseudoknoten und niveaugleicher Straßenübergang) erfolgt über ein Attribut. Der RailwayNode leitet sich vom übergeordneten TransportNode ab.

IDMVU: kennt Gleisknoten spezieller als Begrenzung von Gleisabschnitten. Die Funktion des Gleisknotens wird auch hier attributgesteuert. Zusätzlich gibt es die Objektklasse Begrenzungspunkt.

railML: kennt die speziellen Knoten trackBegin, trackEnd als Begrenzung von Gleisstrecken. Darüber hinaus gibt es weitere Knoten. Diese eigenständigen georeferenzierten Punkte können in Relation zu einer Gleisstrecke gesetzt werden, bestimmen aber keine Gleisabschnitte. Entsprechende Objektklassen sind: operationControlPoint s (OCP) und connections mit den Subklassen switches, crossing und connection.

BahnhofRailwayStationNodeRepräsentiert punktförmig den Ort eines Bahnhofs entlang eines Schienennetzes. Ein Bahnhof liegt innerhalb eines Bahnhofsbereichs. In ihm laufen alle (Haupt-) Gleisstrecken zusammen. Der RailwayStationNode leitet sich vom übergeordneten RailwayNode ab

IDMVU: kennt die punktförmige Objektart Haltestelle. Innerhalb IDMVU ist der Bahnhof eine komplex aufgebaute Haltestelle.

railML: kennt die Objektklasse propOperational mit der spezifischen Eigenschaft station.

HaltepunktRailwayYardNodeBeschreibt einen Gleisknoten innerhalb eines Bahnsteig- /Rangierbereichs. Ein RailwayYardNode leitet sich innerhalb des Datenmodells vom Gleisknoten ab.

IDMVU: hier bezeichnet der Haltepunkt einen Punkt auf einem Bahnsteig, an dem Bahnen anhalten, um Fahrgästen den Einund Ausstieg zu ermöglichen. Der Frachtumschlag wird nicht berücksichtigt

railML: kennt die Objektklasse propOperational mit der spezifischen Eigenschaft stoppingPoint.

Linienförmige GEO-Objekte
GleisabschnittRailwayLinkIst eine linienhafte Verbindung aller linearisierten Trassierungselemente eines Gleises zwischen 2 aufeinander folgenden Gleisknoten. Der RailwayLink leitet sich innerhalb des Datenmodells aus dem allgemeinen TransportLink ab.

IDMVU: kennt die Objektart GleisStrecke als die Verbindung zwischen zwei Gleisknoten.

railML: kennt keinen Gleisabschnitt.

GleisstreckeRailwayLinkSequenceIst die Aneinanderreihung von Gleisabschnitten unter einem Ordnungskriterium (=Streckenname). Ein Gleisabschnitt kann immer nur einer Gleisstrecke angehören. Die RailwayLinkSequence leitet sich innerhalb des Datenmodells aus dem allgemeinen AggregatedTransportLink ab.

IDMVU: kennt ebenfalls die Objektart GleisStrecke als logischen Verbund von Gleisabschnitten.

railML: kennt die Objektart track. Sie beschreibt die linienhafte Verbindung zwischen trackBegin und trackEnd.

VerkehrslinieRailwayLineIst eine planmäßig mit durchgehenden Zügen befahrene Verkehrsrelation, bestehend aus Gleisstrecken und einzelnen Gleisabschnitten. Hierbei können Gleisstrecken und Gleisabschnitte von mehreren Verkehrslinien genutzt werden. Die RailwayLine leitet sich innerhalb des Datenmodells vom allgemeinen TransportLinkSet ab.

IDMVU: kennt die Objektart FreieGruppierung. Über sie können Gleisstrecken und Gleisabschnitte thematisch kombiniert werden.

railML: kennt die Objektklasse line.

Flächenförmige GEO-Objekte
BahnhofbereichRailwayStationAreaEine RailwayStationArea ist eine TransportArea, welche die Fläche einer Bahnhofsanlage repräsentiert.

ÎDMVU: kennt die abstrakte Objektklasse Gebiet mit den derzeitigen Unterklassen Bahnsteig und Raum. Weitere Unterklassen könnten abgeleitet werden.

railML: kennt die Objektklasse area als Subklasse der OCP. Die Differenzierung innerhalb der Klasse wird durch Attribute gesteuert. Weiter gibt es die Objektklasse border. Über solche Grenzen könnten ebenfalls Bereiche definiert sein.

Bahnsteig- /RangierbereichRailwayYardAreaBeschreibt eine Fläche innerhalb eines Bahnhofbereichs. Hier werden Züge angehalten um Passagiere ein- oder aussteigen zulassen oder Fracht zu be- oder entladen ohne den Zugverkehr der Hauptgleise zu stören. Die Fläche wird durch mehr als 2 parallele (Neben-) Gleise mit Gleiswechseln durchzogen. Sie liegt immer in einem Bahnhofsbereich. Innerhalb des Datenmodells leitet sie sich von der allgemeinen TransportArea ab.

IDMVU: kennt die Objektklasse Bahnsteig, lässt auch die Assoziation von zwei Gebieten zu der Objektklasse FolgeVonGebieten zu.

railML: kennt die Objektklasse area als Subklasse der OCP. Die Differenzierung innerhalb der Klasse wird durch Attribute gesteuert. Weiter gibt es die Objektklasse border. Über solche Grenzen könnten ebenfalls Bereiche definiert sein.


OberbauflächeRailwayAreaBeschreibt die Fläche, die der Oberbau einer Gleisstrecke abdeckt, aber je nach Detaillierungsgrad auch den unabhängigen oder den besonderen Bahnkörper. Die RailwayArea leitet sich von der allgemeinen TransportArea ab.

IDMVU: Dieses Datenmodell kennt die Oberbaufläche nicht. Die benötigten Daten können aber aus der Objektklasse GleisKörperProfil entnommen werden.

railML: kennt die Objektklasse area als Subklasse der OCP. Die Differenzierung innerhalb der Klasse wird durch Attribute gesteuert. Weiter gibt es die Objektklasse border. Über solche Grenzen könnten ebenfalls Bereiche definiert sein.

Transporteigenschaften
SpurweiteRailwayGaugeIst eine Gleiseigenschaft und gibt den Abstand zwischen den Innenkanten der Schienen eines Gleises an.

IDMVU: kennt die Spurweite als Attribut der Objektart Gleisstrecke.

railML: kennt die punktförmige Objektklasse gaugeChange. Über das Attribut value wird die neue Spurweite angegeben.

GleisnutzungRailwayUseIst eine Eigenschaft welche die aktuelle Nutzung des Gleises benennt. So wird zwischen Fracht-, Autopendel-, Fahrgastund gemischtem Betrieb differenziert.

IDMVU: beschäftigt sich nur mit Personenverkehr. Eine Differenzierung der Gleisnutzung findet nicht statt.

railML: kennt keine Objektklasse oder ein Attribut für Gleisnutzung.

EntwurfsgeschwindigkeitDesignSpeedGibt an, für welche Spitzengeschwindigkeit die Gleisgeometrie ausgelegt ist.

IDMVU: ein Pendant ist der aktuellen Dokumentation nicht zu entnehmen.

railML: ein Pendant ist der aktuellen Dokumentation nicht zu entnehmen, da die Bedeutung der Objektart speed dort nicht erläutert ist.

GleisanzahlNumberOfTracksGibt die Anzahl parallel liegender Gleise an, die in einem RailwayLink oder einer RailwayLinKSequence zusammengefasst sind.

IDMVU: Das Netzmodell ist spurgenau. Die Zusammenfassung paralleler Gleise zu einem Strang ist nicht vorgesehen.

railML: ein Pendant ist der aktuellen Dokumentation nicht zu entnehmen.

ElektrifizierungRailwayElectrificationGibt an, ob der Gleisabschnitt, bzw. die Gleisstrecke elektrifiziert ist.

IDMVU: kennt die Objektarten Stromschiene und Oberleitung. Sie können auf das schienennetz referenziert werden.

railML: kennt die Objektart electrificationChange. Über sie werden Punkte im Netz definiert, wo sich die Elektrifizierung ändert.

SchienennutzungRailwayTypeGibt an, durch welche Bahnart das Gleis genutzt wird (Straßen-, Schwebebahn, U-Bahn, etc.)

IDMVU: ein Pendant ist der aktuellen Dokumentation nicht zu entnehmen.

railML: ein Pendant ist der aktuellen Dokumentation nicht zu entnehmen.

5. Potentielle Daten, die zum Thema gehören

<Potentielle Daten und Einrichtungen auflisten>

6. Daten, die nicht zum Thema gehören

< Daten und Einrichtungen auflisten, die potentiell nicht zu INSPIRE gehören>



6 Kommentare

  1. "Gemeinsame Trabsportelemente" erster Spiegelstrich unter 2. macht Sinn:  Trab-Sport-Elemente (Zwinkern)

    Es sollte wohl eher "Gemeinsame Transportelemente" heißen.

    Gruß

    Burkhard Schlegel

    1. Iris Heine sagt:

      Auch wenn die Reiter jetzt vielleicht ein bisschen traurig sind, dass ihr Trab-Sport nicht mehr gewürdigt wird... (Zwinkern) 

      Ich habe den Fehler korrigiert

  2. Auf GitHub wurde ein Change Proposal zur Änderung des Schemas AirTransportNetworks.xsd eingereicht. Nach Diskussion in der sub-group "Governance of INSPIRE Artefacts" wird um fachlichen Input durch Fachpersonen aus dem Bereich "Luftverkehrsnetz" gebeten. Eingereicht wurde der Change Proposal durch wetransform im Auftrag der Deutschen Flugsicherung. Daher gehe ich davon aus, dass wir aus Deutschland den Vorschlag unterstützen. Ggf. könnte dennoch ein zusätzlicher fachlicher Input an dieser Stelle helfen.

  3. Hallo Daniela, einen Kontakt zur DFS kann ich finden... melde mich nochmal deswegen bei Dir

  4. Bei dem Change Proposal der DFS geht es darum, dass der sog. Airport reference point keine direkte räumliche Verknüpfung mit der runway hat. Da INSPIRE aber diese Knoten fordert, hat die DFS für den Bereich Luftfahrt den Änderungsantrag gestellt, dass dies nicht obligatorisch sein sollte.

    → "The three feature types AerodromeNode, DesignatedPoint and RunwayCentrelinePoint should inherit from TransportPoint instead of TransportNode.
    The three types are currently inheriting from TransportNode. That means that they shall theoretically only be present where transport links connect or end. This is not the case in reality and the model should therefore be adapted.

    Expected behaviour
    AerodromeNode, DesignatedPoint and RunwayCentrelinePoint inherit from TransportPoint

    Current behaviour
    AerodromeNode, DesignatedPoint and RunwayCentrelinePoint inherit from TransportNode"


    Stand des Change Proposal: https://github.com/INSPIRE-MIF/application-schemas/issues/61 (öffentlich zugänglich). 


  5. Weitere Diskussion zum Datenmodell "Flugverkehrsnetz" im Rahmen der Bereitstellung von Daten zu Großflughäfen (Umgebungslärmrichtlinie): https://github.com/INSPIRE-MIF/helpdesk/discussions/146