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.
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.
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 
OSM??!
4. How to best report issues with stops
First of all, what is not an issue that needs to be updated upstream? 
- 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) 
- 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
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. 
