Bus stops in Norway [guide for understanding current data and reporting problems]

Information and guidance regarding OSM bus stops in Norway

Because the situation in Norway is quite special I think an explanation is in order. Note that the following are the procedures that are in place and that efforts have been made to keep the standards of OSM while also allowing for an import of a complete set of official data which keeps OSM up to date with a very large dataset which would be difficult to maintain any other way.

This post refers only to the highway=bus_stop nodes in Norway.

:information_source: For disclosure, I work for the company Entur which will be mentioned later. I sometimes use this profile: ENTUR Johan Wiklund | OpenStreetMap

Data

1. Where does the data come from?
The data originates in the official National Stop Place Registry (NSR) where all public transport operators in Norway (or operating within Norway) are required to register and maintain their stops. The requirements are linked to the legal requirement of making timetable data publicly available.

The requirements are established by the PSI-directive (EU), ITS-directive (EU) (Norway is obligated to conform through the (EEA membership)) and in Norwegian law through “yrkestransportforskriften”.

1.1 The stop place registry
Each region is responsible for the stops in its own area. This means that the regional government (fylke) is responsible for maintaining the stops according to the established guidelines.
The registry can be viewed here: https://stoppested.entur.org/

1.2 The registry is controlled by ENTUR AS which does QA, administration, and some direct edits.

1.3 Status of quality
There are roughly 65.000 stop areas with over 100.000 individual stop points in Norway. Full quality assurance is not- and can not be done in one sweep but is instead continuously performed by all involved parties over time.
There is no comprehensive statistic for the overall quality, but it is thought that all major errors have been eliminated (however, because of constant changes in roads new major errors are sometimes introduced).
Minor errors are very common but it is usually a matter of up to tens of meters offset.

2. How does the data end up in OSM?
The bot nsr2osm downloads data from Entur and updates all stops by the ID provided by Entur which matches to the nsrq or nsrs ref. The exact procedure can be found in the source code on GitHub. The bot was created and maintained by @NKA . This automated import was created in cooperation with Entur and is documented here: Import/Catalogue/Bus stop import Norway - OpenStreetMap Wiki

2.1 The bot/script is run about every week and it checks for changes in the stop registry. If there are changes the bot updates the bus stop in OSM. This is limited to bus stops in NSR and their corresponding floating nodes with the tag highway=bus_stop (and some bus stations).

2.2 Does it overwrite user changes?

  • Yes, but only name and position. Other tags are left in place.
  • And only if the stop has been updated in NSR more recently than the change in OSM was made.

Admittedly this may in some cases cause losses if the upstream data in NSR has not accounted for the change in OSM. More on this later in point 4.

3. What not to do with bus stops in OSM and why
These are not rules, just suggestions because there is a better way (see point 4)

  • Don’t move data to another element (for example into a way/relation). It should remain on a node
  • Don’t merge the node onto a way. It should be free floating.

Why? Because updating is easier if the nodes are left in place and it is better if data everywhere works the same way within the country.

  • Dont move or rename the stops
  • Dont delete stops or add new ones

Why? Because it is better to make these changes upstream in the National Stop Registry. It is worth noting, however, that position and naming of stops follow certain rules which may differ from some people’s opinion on where a stop should be placed in OSM.

A stop in the National Stop Registry (individual boarding position) must be placed on the intersection between tactile paving and sidewalk kerb if such exist. Otherwise equivalent position. Otherwise, best effort where bus’s front door is expected to be when the bus stops.

:grey_exclamation: Some people in OSM like to place the node on the shelter or the transport symbol sign. Unfortunately, the official dataset cannot accommodate this and it is better for continuous updates if the script always overrides these changes with data from the official source because it allows automated updates for the whole country.

So how can changes best be made to bus stops in :norway: OSM??!

4. How to best report issues with stops
First of all, what is not an issue that needs to be updated upstream? :stop_sign:

  • Moving the bus stop somewhere else than described in point 3.
  • Tags and relations (upstream has no use for this so go ahead and edit)
    • This includes shelters, bins, routes etc.

Important issues that are useful to the upstream data (crowdsourcing) :1st_place_medal:

  • The road has been rebuilt but the stops are in the old location.
  • The stops are not in the correct location to begin with (several meters off)
  • The name of the stop is wrong and SSR agrees with me
    • Usually related to placenames (farms etc)
  • A stop is missing (note that the script removes stops that have no current traffic)
  • A stop does not exist in reality and should be removed

4.1 Reporting issues with stops:
It is actually best to report them right here in this thread. Its easy, informal, and transparent to everyone else. The information needed to process issues is:

  • Where is it (OSM-URL), or what is the name and county/municipality, or what is the id (nsrq- or nsrs ref)?
  • What is wrong? What should be changed, and if relevant: why?
    • If the position is wrong you often only need to describe the new location if orthophotos are outdated. The issue is usually obvious at a glance when orthophotos are up to date. Use your own judgment for how much detailed info you need to include.

Alternatively, issues can be reported by private message to one of my OSM users, to kollektivdata@entur.org, or directly to the local county administration.

If there is a problem with many stops, either provide a list (with info as above) or just point out a general area (for example, along a certain road between two places) and the general problem (for example, bad positioning).

4.2 What happens next?
Sometimes Entur can make improvements immediately (usually when they are obvious and simple). If not the issue is forwarded to the respective county administration department and it will be dealt with in due time.
When the change is made in the National Stop Registry the update will be imported in the next nsr2osm changeset.

4.3 It’s a hassle to write things here instead of editing OSM directly!!

  • Yes, but its an even bigger hassle for the public transport sector to try to discover and benefit from the improvements you’ve made if it only made in OSM without telling anyone :slight_smile:

Benefits

The great benefit of reporting problems upstream is that not just OSM gets updated. We have many consumers of our open data, as well as our open journey planning services. All these will be improved by these small contributions. In short: this is crowdsourcing.

Any information which can improve the national dataset is highly appreciated. Don’t hesitate to contribute. :parrot:

Further reading

3 Likes

Fantastic post, could you add this info to the wiki as well? Import/Catalogue/Bus stop import Norway - OpenStreetMap Wiki

And or link the comment saying “Where to report errors: Link to forum”

Excellent guide!

Could you add something about temporarily moved bus stops? E.g., how long-lasting does it need to be for someone to report it, or to add some temporary or lifecycle tag? Do you use such tags if they are present?

I know we are not supposed to map temporary features, but it depends if temporary means for a day, for a week, for a year or for ten years. So I propose to set some limits or advice…

Example: The western “Ugla” bus stop in Trondheim has been temporarily moved about 150m down the road, since the “Uglastien” path is in construction to become an official “Snarvei”.
https://www.atb.no/driftsavvik/buss-og-trikk/holdeplassen-ugla-flyttes-midlertidig-fra-16-januar-article19448-871.html

Nobody has done any changes in OSM, but I guess that also means Entur is currently using incorrect data there. Should anything be done, or is it too short lasting to be of importance?

This is possibly a too short lasting temporary change, but users cannot determine that easily without setting some sort of limit (e.g., Temporary changes to bus stops should be reported to kollektivdata@entur.org if they are expected to last longer than XX days).

Temporarily moved stops

Could you add something about temporarily moved bus stops? E.g., how long-lasting does it need to be for someone to report it, or to add some temporary or lifecycle tag? Do you use such tags if they are present?

The procedure is slightly diffuse because everything is a gray area. Like, “how far is too far, and is too far too far in every case”. Anyway, the practical rule of thumb is that:

  • Long term temporary stops that are far away (enough to warrant a new name): New stop is created at new location, old stop is usually disused.
  • Long term temporary stop nearby: The existing stop is moved to the new location and moved back when the situation is resolved.
  • Short term changes, long distances: Usually new stops are not created in the short term so either a different (already existing) stop is used, or the route just skips the stop.
  • Short term changes, short distance: Usually resolved by textual information in realtime deviation messages.

It should be noted here that NKA has recently modified the script so that only stops that have been out of use for 1 year are removed from OSM.

lifecycle tag

This would be difficult to implement in the source data. Stops come and go and its quite difficult for the counties to properly follow up on all stops - mostly because they dont always know if the stops will be used again later or not. The stops are versioned and the last version either has no end date, or it has an end date in the past or the future. Stops with an end date in the past are expired and should be considered “removed”.

Case: Ugla, Trondheim

Example: The western “Ugla” bus stop in Trondheim has been temporarily moved about 150m down the road, since the “Uglastien” path is in construction to become an official “Snarvei”.

I called AtB and they will investigate. This is a part of the problem that they don’t have the full- or up-to-date information from the municipality at all times. If warranted they will move the stop. I have also asked them to evaluate a new name so that it isn’t identical to the tram stop.

1 Like

Her er det en jeg ikke forstår: Endret for 19 dager siden med kommentar:
https://maproulette.org/browse/challenges/28363 (Samme link: MapRoulette)
Node: ‪Hjalmar Brantings vei‬ (‪6373681364‬) | OpenStreetMap ref:nsrq=55816

Veien er nok bygget om her, så nå ligger busstoppet i en midtrabatt, men - også - ser ut som om bruker chris_debian | OpenStreetMap legger til public_transport=platform på mange stoppesteder i Bergen. Tok en rask sjekk, og han har gjort dette flere steder.

Ja det kan se ut som det er lagt inn en MapRoulette for å gjøre unødvendige “oppdateringer” av stoppene.

Har meldt stoppet til Skyss for oppgradering.

1 Like

Har ikke sett noe i som legger til public_transport=platform i MapRoulette, men det er en i StreetComplete. Helt unødvendig, og fører til at oppdateringer fra NSR stopper opp.