opener-next / osm2vdv462

OSM to VDV462 export pipeline

The goal of this app is to collect accessibility data for public transport stops in OpenStreetMap so that everyone can benefit from it. Due to the huge amount of public transport stops out there we want to encourage all citizen (experienced OSM users and newcomers) to help gathering this data. That's why we are developing this app that allows collecting the data in an easy, accessible and safe manner by asking simple questions. For deeper insight read the working principle of the app.

The data shall be the foundation for better routing especially for impaired people and lead to a renovation of non accessible stops, as well as many other things we ourselves can't even imagine right now.

Thanks and happy mapping!

Download

Screenshots

Contributing

We are always happy, if you not only want to help us mapping, but also want to directly participate in the project.

You can either open issues for enhancement suggestions and bug reports or help us developing the app further. A good starting point for the latter is to read the build instructions for the app.

You can also help translating the app at Weblate.

License

This app is released under the terms of the GNU General Public License v3.0 or later (GPL-3.0-or-later).

Funding

OpenStop is developed in the project OPENER next, which is funded by the German Federal Ministry for Digital and Transport as part of the mFUND innovation initiative.

Acknowledgement

Special thanks to Andy Allan (@gravitystorm) for granting us free access to the beautiful Thunderforest map tiles.

osm2vdv462's Issues

Export path links of neabry stop places/stop areas

For nearby stop areas it makes sense to find and export ways that connect them like we already do between platforms or entrances.

The hard question here is: what are the starting and end points? If we have entrances then we probably should pick them, but for lets say nearby tram stops we should probably pick the closest platforms or ideally generate a suitable AccessSpace.

Export levels

We are already exporting paths across different levels (with stairs, elevators etc.) but we do not assign levels to them in the export.

Levels are defined once for every StopPlace and then referenced when needed.

Level definition:

<StopPlace id="de:11000:900055101" version="1635772518">
  <Name>U Viktoria-Luise-Platz (Berlin)</Name>
  <levels>
    <Level id="DE::Level:675_-1::" version="1635772518">
      <ShortName>-1</ShortName>
    </Level>
    <Level id="DE::Level:675_0::" version="1635772518">
      <ShortName>0</ShortName>
    </Level>
  </levels>
  <StopPlaceType>other</StopPlaceType>
  ...
</StopPlace>

Some relevant fields are: Name, ShortName, Description.

Usage (Quays, AccessSpaces, Entrances and Parkings).:

    <Quay id="de:11000:900055101_300060041" version="1635772518">
      <Name>U Bahnsteig Gleis 1</Name>
      <LevelRef ref="DE::Level:675_-1::" version="1635772518"/>
    </Quay>

Idea:

• Modify the osm2pgsql export so it includes a level column (round to integer | use arrays for multiple levels, or only take one, since multiple levels are more important for paths?)
• GROUP BY levels per stop area the into a separate view by taking all stop elements (not paths)
• Use this view in the final export query vs respective xml transformation functions

Run osm2pgsql in docker

Currently osm2pgsql is the only thing that doesn't run in a docker. I would be nice to have docker as the only requirement to setup and run the pipeline.

Create a github workflow for export

We could create a workflow that runs the entire export pipeline based on a given osm.pbf file url which could be provided via a workflow input parameter.
The export files could be attached to releases or simply be published as artifacts.

A fully automated script could run once a week and download every single state, convert it and attach it as a release.

Add NeTEx validation workflow

Use the example data to run an export and validate the output.

Export DELFI attributes

StopPlace

• 1010 - Zuständiger Ansprechpartner für Belange des barrierefreien Reisens
• 1011 - Telefonnummer des zuständigen Ansprechpartners für Belange des barrierefreien Reisens
• 1020 - Fahrtkartenverkaufsstelle
• 1021 - Verkaufsstellenart
• 1022 - Stufenfrei erreichbar (Stufe/Schwelle maximal 3 cm)
• 1030 - Informationsstelle
• 1031 - Informationsstellenart
• 1032 - Stufenfrei erreichbar (Stufe/Schwelle maximal 3 cm)
• 1040 - Fahrkartenautomat
• 1050 - Öffentlicher Parkplatz
• 1051 - Parkplatzart
• 1052 - Öffnungszeiten/ Nutzungsbedingungen
• 1060 - Taxi-Stand
• 1070 - Toiletten
• 1071 - für Rollstuhlfahrer zugängliche Toilette vorhanden und stufenfrei (< 3 cm) erreichbar
• 1072 - für Rollstuhlfahrer zugängliche Toilette ist für alle Reisenden frei zugänglich
• 1072 und 1073 könnten mit einem Tag definiert werden. - für Rollstuhlfahrer zugängliche Toilette ist mit Euroschlüssel nutzbar
• 1074 - für Rollstuhlfahrer zugängliche Toilette ist mit einem speziellen Schlüssel nutzbar, der beim örtlichen Einzelhandel zu den Öfnungszeiten ausgeliehen werden kann
• 1075 - Aufnahme der  Öffnungszeiten/ Nutzungsbedingungen
• 1080 - Haltestelle niveaugleich
• 1081 - Ebene des Bereiches
• 1082 - Ebene des Zwischengeschosses
• 1090 - Schließfächer oder Aufbewahrungsmöglichkeiten
• 1100 - Gepäcktransport
• 1110 - Notrufsäule
• 1111 - Informationssäule
• 1112 - Kombinierte Informations- und Notrufsäule
• 1130 - Fahrtplananzeigetafeln
• 1131 - Akustischer Ausgabe
• 1160 - Induktive Höranlage
• 1161 - Standort
• 2010 - Stations-/Haltestellenplan vorhanden
• 2070 - Bodenindikatoren vorhanden

Quay:

• 1170 - Bordstein-/Bussteig-/Bahnsteighöhe
• 1180 - Breite des Bahn-/Bussteigs
• 1190 - Abstand Bahnsteigkante zur Gleismitte
• 1200 - Hochbord mit Spurführung
• 1201 - Hochbord mit Spurführung und doppelter Hohlkehle
• 1202 - Hochbord ohne Spurführung
• 1203 - Kombibord mit Spurführung
• 2071 - Taktile/visuelle Bodenindikatoren im Einstiegsbereich mit Auffindestreifen
• 2140 - Einstieg in Straßenmitte

Others export these values on StopPlaces:

• 1120 - Wartegelegenheiten mit Sitzplatz
• 1140 - Zugziel-/Fahrtzielanzeiger
• 1141 - Akustische Ausgabe
• 1150 - Ansagen

AccessSpace:

• 2080 - Durchgangsbreite der Umlaufsperre/des Sperrelements/der Engstelle
• 2081 - Bewegungsfläche in, durch und aus der Engstelle

Entrance:

• 2030 - Tür vorhanden
• 2031 - Öffnungszeiten der Tür/des Zugangs
• 2032 - Art der Tür/des Zugangs
• 2033 - Art der Türöffnung
• 2034 - Lichte Breite der Türöffnung/des Zugangs

PathLink:

• 2020 - Länge der niveaugleichen Wege
• 2021 - Breite der niveaugleichen Wege
• 2040 - Gleisüberquerung erforderlich (Höhengleicher Bahnsteigzugang)
• 2050 - Unbefestigter Bodenbelag
• 2072 - Taktile/visuelle Bodenindikatoren als Leitstreifen
• 2090 - Aufzug vorhanden
• 2091 - Türbreite Aufzug
• 2092 - Grundfläche des Aufzugs
• 2093 - Grundflächenlänge
• 2094 - Grundflächenbreite
• 2100 - Stufe vorhanden
• 2101 - Stufenhöhe
• 2110 - Treppe vorhanden
• 2112 - Stufenhöhe (Tritthöhe)
• 2113 - Anzahl der Treppenstufen
• 2120 - Rampe und Wege mit Neigungen vorhan-den/Zugang über Rampe
• 2122 - Rampenlänge
• 2123 - Rampenbreite
• 2124 - Rampenneigung
• 2130 - Rolltreppe vorhanden
• 2132 - Richtung der Rolltreppe
• 2133 - Wechselnde Richtung der Rolltreppe
• 2134 - Länge der Rolltreppe

Quay, Entrance, AccessSpace:

• 2060 - Benennung von Knotenpunkten und Wegen in komplexen Haltestellen, Umsteigehaltestellen und Stationen

Undefined, probably Quay?

• 1210 - Rampe vorhanden
• 1211 - Rampenlänge
• 1212 - Tragfähigkeit Rampe
• 1220 - Hublift vorhanden
• 1221 - Länge der Stellfläche
• 1222 - Tragfähigkeit Hublift

Use PPR routing by osm element type and id or level

The target and destination fields can additionally include the properties osm_type ("way" or "relation") and osm_id (int). We should try to use them or otherwise specify the level to assure that we calculate a path from and to the correct level. This is relevant to correctly export multi level train stations.

Export single platform stops as stop areas

Stop areas don't have to be composed of two or more platforms/stops. This is especially the case for railway stops where trains stop at the same platform for both directions (Example). In such cases usually no dedicated stop area relation is mapped in OSM (this is also explicitly allowed by the PTv2 schema). However currently the exporter only exports stop areas and their member platforms.

The problem is that we cannot detect whether a stop is supposed to be a stop area or if the corresponding stop area relation is simply missing. We could only detect this by reverse-engineering the IFOPT which should be avoided.

Allow passing parameters to export script

Allow passing required inputs (that are currently asked by user prompts) as parameters like: ./export.sh arg1 arg2 arg3 write them to the respective variables and only prompt when the variable was not set from the outside.

See: https://unix.stackexchange.com/questions/31414/how-can-i-pass-a-command-line-argument-into-a-shell-script

This is required to completely automate testing and exporting.

Export AccessFeatureType for paths

AccessFeatureType

lift
escalator
ramp
stairs

On first glance this should be rather trivial. Just an aggregate function across all elements (their tags) that looks for the respective highway tags like stepts, elevator etc.

Problem: A path might contain multiple AccessFeatureType. This is because we create StopPlaces mostly without AccessSpaces which are used for:

Eingangshalle, Zwischengeschoss oder Korridor innerhalb eines Umsteigebauwerks

So there are two options:

• Expect that AccessSpaces for every mezzanine exist in OSM
• Generate AccessSpaces for mezzanines (when a path goes across multiple levels, we need in between AccessSpaces ) Problem however is, that these require unique DHIDs at least by the specification.

Merge splitted platforms

In some rare cases a platform can be split into multiple way elements but have the same DHID. (for example because part of the platform lies on a bridge)

• https://www.openstreetmap.org/way/172420071
• https://www.openstreetmap.org/way/138389521

They should be merged to one element in the database view.

Split platforms with multiple DHIDs

Some platforms provide boarding places on both sides. Mappers sometimes then split these platforms in the middle into 2 platform elements to separate tags like ref. Others keep them as one element and instead add multiple values for the same tag. Example: https://www.openstreetmap.org/relation/3264414#map=18/52.12995/11.62747

For the DHID this looks like this:
ref:IFOPT=de:XXX;de:YYY

We should simply create two OSM elements out of this. They will have the same geometry and same tags, except when multiple values exist. Biggest challenge is how to handle their OSM ids, since keeping the id is important to reference them for relations and the like. It might be possible to stop using the ids as primary keys.