EFA-based local transit APIs have two kinds of stop identifiers: numbers such as 20009289 and codes such as de:05113:9289. travelynx needs a single type of ID, and this post is meant mostly for myself to find out which ID is most useful. The numeric one would of course be ideal, as travelynx already uses numeric IDs in its stations table.

Numbers

DM_REQUEST: Available as stopID in each departureList entry.

STOPSEQCOORD_REQUEST: Available as parent.properties.stopId in each locationSequence entry.

STOPFINDER_REQUEST: Available as stateless and ref.id.

COORD_REQUEST: missing.

Codes

DM_REQUEST: missing.

STOPSEQCOORD_REQUEST: Available as parent.id in each locationSequence entry. Outside of Germany, the format changes, e.g. placeID:27006983:1 for a border marker (not an actual stop) and NL:S:vl for Venlo Bf.

STOPFINDER_REQUEST: Available as ref.gid.

COORD_REQUEST: Available as id and properties.STOP_GLOBAL_ID in each locations entry.

API Input

• DM_REQUEST: Accepts stop names, numbers, and codes
• STOPSEQCOORD_REQUEST: Accepts stop numbers and codes

Examples

• LinzAG Ebelsberg Bahnhof: 60500470 / at:44:41121
• LinzAG Linz/Donau Hillerstraße: 60500450 / at:44:41171
• NWL Essen Hbf: 20009289 / de:05113:9289
• NWL Münster Hbf: 24041000 / de:05515:41000
• NWL Osnabrück Hbf: 28218059 / de:03404:71612
• VRR Essen Hbf: 20009289 / de:05113:9289
• VRR Nettetal Kaldenkirchen Bf: 20023754 / de:05166:23754
• VRR Venlo Bf: 21009676 / NL:S:vl

Conclusion

Looks like numeric stop IDs are sufficient. They're missing from the COORD_REQUEST endpoint, but that's not a dealbreaker -- all database-related operations work with DM_REQUEST and STOPSEQCOORD_REQUEST data. Also, there seems to be no universal mapping between the two types of stop IDs.