Public Transport Stops Swiss Location Identification (sloid)

Communities Switzerland
, , ,
1

Swiss Location Identification (SLOID) documentation in Deutsch, Français, Italiano

Currently, most public transport stops have a uic_ref (explore it on overpass-turbo).
This reference is being retired, in favor of a new id. While the with the old uic there was only one id for all platforms (think directions for typical bus stops), with sloid there will be separate ids for each platfrom.

This matches well with OSM, as we mapped bus stops separately for each direction any way.

Example with Aarau:
Today, there is an uic_ref of 8502113 on Aarau. Sloid will be ch:1:sloid:2113. We could map this to osm tags in different ways. For example ref:sloid=ch:1:sloid:2113
Now the interesting part, platform 1 in Aarau will have ch:1:sloid:2113:1. This could for example be ref:sloid=ch:1:sloid:2113:1. Why do I propose ref:sloid tag? because there might be different refs from different countries in the end. Probably not in Aarau, but in areas close to the border, where a foreign transport company also services Swiss stops or vice versa. So a stop or platform could have multiple useful refs, from different national systems.

Why is this id useful:
Like with the uic number, the sloid will be understood by various APIs, and be referenced from open data like opentransportdata.swiss.
For example the uic is used to create a station board in this demo.

Driver behind this change in the Swiss public transport sphere is SKI with Atlas, which is a directory of all public transport stops with platforms and other relevant information. SBB is hosting and maintaining the platform, but the many public transport corporations have to maintain their data themselves.

To get more context, also see the OSM Wiki DiDok page which documents the previous import.

A new tool was developed by Guillem Massagué as Bachelor’s thesis at HESGE, comparing OSM to Atlas (see other community thread ATLAS-OSM app feedback and ideas). The idea is that this tool will be used to add sloid information to the stops. I also hope it will replace the old didok.osm.ch tool for maintenance, comparing OSM with Atlas and fixing problems.

While neighboring countries are pursuing similar approaches, Switzerland has opted for this namespace approach to meet specific local requirements.

Drawbacks of id refs in OSM: They may not be understood by some mappers. For example a common introduction of an error is copying an existing stop or platform for a new one without adapting the ref. Either not noticing the ref or not knowing what goes in there, as the number is not visible on the ground. The tool from Guillem should detect such errors and help maintaining the refs.

My personal opinion
I appreciate the initiative of SKI, it shows that the Swiss public transport sector is motivated to use and contribute to OSM. As with the uic_ref, the usefulness (of the foreign reference) outweighs the drawback.

6 Likes
2

Sounds good to me, so sad the uic doesn’t provide a sufficient solution and a national solution is needed….
Your drawback is already an existing problem within osm. So it shouldn’t block the introduction of sloid.

What is the/your idea with the uic_ref tag in osm, should it be removed, once the sloid is added?
So we only have to maintain one identifier.

3

From the Transitous point of view where we consume this kind of data I agree, both on the namespacing using ref:sloid (there’s just too many overlapping identification systems in that space) as well as maintaining this in OSM (it’s what we have to match all public transport data to eventually, for routing). It’s unfortunate that within Europe this is so fragmented by region/operator, but that’s the reality we have to deal with.

uic_ref still has value though, as the UIC station codes are still in use also for CH, e.g. in international ticket barcodes. The main problem with uic_ref is that it contains the wrong data in DE, but that’s a different issue.

1 Like