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


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:


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


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”.

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).

1 Like

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”.

1 Like

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.

Some SSR cleanups of archaic names in Hitra

Where: (ref:nsrq 73067) Node: ‪Strøm‬ (‪7099991015‬) | OpenStreetMap
What: Wrong name “Strøm” → “Straum” (per SSR)

Where: (ref:nsrq 71282) Node: ‪Hernes kryss‬ (‪7099991359‬) | OpenStreetMap
What: Wrong name “Hernes kryss” → “Herneskrysset” (Place not in SSR, but has local usage predating the buss stop)

Where: (ref:nsrq 73480) Node: ‪Murvold‬ (‪7099991225‬) | OpenStreetMap
What: Wrong name “Murvold” → “Morvollan” (per SSR)

Where: (ref:nsrq 72367) Node: ‪Volden‬ (‪7099989881‬) | OpenStreetMap
What: Wrong name “Volden” → “Vollen” (per SSR)

Where (ref:nsrq 71149) Node: ‪Helgbostad‬ (‪7099991357‬) | OpenStreetMap
What: Another SSR writing cleanup “Helgbostad” → “Helgbustad”. But the buss doesn’t actually go the ~5km side road to Helbustad, and places like Håvika is actually closer (which would be a terrible name choice, since all traffic here is to Helgbustad). The junction where the buss stops is known in the area as (unsurprisingly) “Helgbustadkrysset”.
So I would actually recommend “Helgbostad” → “Helgbustadkrysset”.

Where (ref:nsrq 73830) Node: ‪Smågesjø‬ (‪7099991064‬) | OpenStreetMap
What: Stop has name of a different location (and in either case is not spelled correctly per SSR). The farm marked is “Småge”, “Smågasjøen” would be the farm further out by Dolmsundet. The bus stops on request both places, but the incorrect name in the data makes this difficult if not both the driver and the passenger are aware of this exact error.

Excellent report. All are duly noted and reported to AtB for processing. These are quite straight forward and the changes are in line with the regulation, so it should just be a formality. Thank you for reporting.

1 Like

And some for Frøya

Where: (ref:nsrq 71761) Node: ‪Hullet‬ (‪7099989561‬) | OpenStreetMap
What: Wrong name “Hullet” → “Holet” (per SSR)

Where: (ref:nsrq 72337) Node: ‪Skjellvik‬ (‪7099989564‬) | OpenStreetMap
What: Wrong name “Skjellvik” → “Skjelvik”. SSR has “Skjelvika” here, which would also be correct, but for “-vik” the default definite language form isn’t as strict as in many other cases. All other stops (“Ervik”, “Dyrvik” etc.) avoid the definite form here, which is acceptable to locals. There are additional subtle factors at play, but I would recommend “Skjelvik” here to stay consistent. Just get rid of the extra “l”.

Where: (ref:nsrq 73084) Node: ‪Kværnø‬ (‪7099989686‬) | OpenStreetMap
What: Wrong name “Kværnø” → “Kvernøy”. Per SSR. Same thing above, where the definite form is the default but the indefinite form isn’t wrong either. “Kværnø” is archaic though.

Some iffy ones:

Node: ‪Stranden‬ (‪7099991070‬) | OpenStreetMap (should likely by “Stranda” like the place, down the side road, but I do not have local knowledge to back it up). Node: ‪Sætra‬ (‪7099989525‬) | OpenStreetMap (geographical weirdness caused by the road network being completely different from how the houses are distributed, but there is probably no better name to give it). Node: ‪Ohraheia‬ (‪7099990704‬) | OpenStreetMap (odd choice of spelling, I would check if this was a request from a local knowing the area better than me, otherwise the SSR spelling “Urdaheia” should be used). Node: ‪Frøya kulturhus‬ (‪7099990783‬) | OpenStreetMap (A bit unfortunate how far away it is from the location it is named after, but the street layouts make it necessary. I guess the current way of marking the data is the best that can be done)

This node should also be checked upstream (ref:nsrq 74507) Node: ‪Dalpro‬ (‪7099990350‬) | OpenStreetMap

I think it isn’t routed properly in the eastward direction towards Fillan, causing passengers to occasionally get stranded here when the bus doesn’t pic them up.

Not sure what you mean here.

It will not be displayed as a stop to bus drivers when going in that direction, which I assume is something that’s using the same data set.

SSR and reality dont always match :smiley: Google Maps

That’s a different “Volden”, please use OSM link I provided.

1 Like

User DoubleA is quite active in deleting the tag highway=bus_stop. It is messing up the regular bus stop updates, creating hundreds of duplicates. After I spent a few hours fixing it today, DoubleA deleted highway=bus_stop again. He is not responding to changeset comments so far. I think next step is to report the matter to DWG, if the user keeps deleting the tag.

Example: Changeset: 140328270 | OpenStreetMap

Var en note i området om ikke-eksisterende buss-stopp, og det er riktig. Ingen skilt eller noen form buss-stopp der nå. Er parkeringsplasser.

Ruter bruker den for noe som ser ut å være “buss for trikk på natta” Entur – nasjonal reiseplanlegger