Übersicht:
Favoritenliste:
Favoritenseiten
Ihre Favoritenliste enthält derzeit keine Seiten. Sie fügen dieser Liste Seiten hinzu, indem Sie im Menü Extras der angezeigten Seite Favorit selektieren. |
BEZIEHT SICH AUF TECHNICHAL GUIDELINE VERSION 3.0.1
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.
Für die verschiedenen Transportarten gibt es verschiedene Zuständigkeiten. Entsprechend ist das Thema in die folgenden Unterthemen untergliedert:
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.
keine Angaben
Für die Unterthemen
liegt noch kein Steckbrief vor.
Die Unterthemen Verkehrsnetze und Schienenverkehrsnetz sind in den folgenden Abschnitten im Detail beschrieben:
Unterthema Straßenverkehrsnetz:
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:
Hinweise für die Umsetzung
Potentiell geodatenhaltende Stellen sind unter anderem:
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: -
Auf kommunaler Ebene sind die entsprechenden Arbeitsgruppen der kommunalen Spitzenverbände im Straßen- und Verkehrswesens einzubinden.
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.
Objektname | Objektname (englisch) | Definition | Hinweise zu OKSTRA und OKSTRA kommunal |
---|---|---|---|
Objektarten Knoten-Kanten-Modell | |||
Straße | Road | Eine 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ßenabschnitt | RoadLink | Ein 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:
|
Straßenpunkt | RoadNode | Ein 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:
|
Europastraße | ERoad | Eine 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ßenabschnittsfolge | RoadLinkSequence | Ein 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ßenname | RoadName | Der 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ße | FormOfWay | Eine Klassifikation, die auf den physischen Eigenschaften des Straßenabschnitts beruht [TWG TN, basierend auf EuroRoadS]. Beispiele: Autobahn, Radweg, Fußweg, Kreisverkehr | Ableitbar 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ße | FunctionalRoadClass | Eine 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ßenbefestigung | RoadSurface Category | Kennzeichnung 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 Fahrstreifen | NumberOfLanes | Die 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ßenbreite | RoadWidth | Die 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. |
Geschwindigkeitsbegrenzung | SpeedLimit | Begrenzung 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äche | RoadArea | Das 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äche | VehicleTrafficArea | Gelä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ände | RoadServiceArea | Ein 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 Verkehrsservices | RoadServiceType | Beschreibung 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 | |||
AreaConditionValue | Gebietsbedingungen, die Geschwindigkeitsbegrenzungen beeinflussen | ||
MinMaxLaneValue | Indikator, ob die Fahrstreifenanzahl ein Minimum- oder Maximalwert ist. | ||
RoadPartValue | Indikator, für welchen Teil der Straße der Wert für die Straßenbreite gilt (Fahrbahn oder gesamte befestigte Fläche). | ||
RoadSurfaceCategoryValue | Art der Befestigung (befestigt oder unbefestigt) | ||
SpeedLimitMinMaxValue | zeigt die Art einer Geschwindigkeitsbegrenzu ng an (z.B. maximale Geschwindigkeit, Mindestgeschwindigkeit, Richtgeschwindigkeit) | ||
SpeedLimitSourceValue | Gibt die Quelle der Geschwindigkeitsbegrenzu ng an (z.B. festes Schild, variables Schild, implizite Geschwindigkeitsbegrenzu ng durch Verkehrsregeln wie 50 km/h Innerorts) | ||
VehicleTypeValue | Fahrzeugtyp, für den eine Geschwindigkeitsbegrenzu ng gilt. | ||
WeatherConditionValue | Wetterbedingung, bei denen Geschwindigkeitsbegrenzung gilt. | ||
FormOfRoadNodeValue | Art des Straßenpunktes | ||
FormOfWayValue | Nutzungsart der Straße | ||
FunctionalRoadClassValue | Straßenklasse | ||
RoadServiceTypeValue | Art der Serviceeinrichtung (Bushaltestelle, Mautstation, Rastplatz, Parkierungsanlage) | ||
ServiceFacility Value | Art der angebotenen Services an einer Serviceeinrichtung (z.B. Essen, Trinken, Tanken) |
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:
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.
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.
Objektname | Objektname (englisch) | Definition | Hinweise zu IDMVU und railML |
---|---|---|---|
Objektarten Knoten-KantenModell | |||
Punktförmige GEO-Objekte | |||
Gleisknoten | RailwayNode | Ein 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. |
Bahnhof | RailwayStationNode | Reprä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. |
Haltepunkt | RailwayYardNode | Beschreibt 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 | |||
Gleisabschnitt | RailwayLink | Ist 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. |
Gleisstrecke | RailwayLinkSequence | Ist 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. |
Verkehrslinie | RailwayLine | Ist 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 | |||
Bahnhofbereich | RailwayStationArea | Eine 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- /Rangierbereich | RailwayYardArea | Beschreibt 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äche | RailwayArea | Beschreibt 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 | |||
Spurweite | RailwayGauge | Ist 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. |
Gleisnutzung | RailwayUse | Ist 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. |
Entwurfsgeschwindigkeit | DesignSpeed | Gibt 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. |
Gleisanzahl | NumberOfTracks | Gibt 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. |
Elektrifizierung | RailwayElectrification | Gibt 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. |
Schienennutzung | RailwayType | Gibt 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. |
<Potentielle Daten und Einrichtungen auflisten>
< Daten und Einrichtungen auflisten, die potentiell nicht zu INSPIRE gehören>
6 Kommentare
Burkhard Schlegel sagt:
"Gemeinsame Trabsportelemente" erster Spiegelstrich unter 2. macht Sinn: Trab-Sport-Elemente
Es sollte wohl eher "Gemeinsame Transportelemente" heißen.
Gruß
Burkhard Schlegel
Iris Heine sagt:
Auch wenn die Reiter jetzt vielleicht ein bisschen traurig sind, dass ihr Trab-Sport nicht mehr gewürdigt wird...
Ich habe den Fehler korrigiert
Daniela Witter sagt:
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.
Jürgen Walther sagt:
Hallo Daniela, einen Kontakt zur DFS kann ich finden... melde mich nochmal deswegen bei Dir
Jürgen Walther sagt:
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).
Daniela Witter sagt:
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