MapRoulette quality check challenges - kvalitetskontroll utfordringer


Etter å ha brukt offentlige forekomster av OSM kvalitetssikringsverktøy som Atlas og Osmose i tillegg til intern validering, har vi identifisert potensielle kartkvalitetsproblemer som nå er tilgjengelige i form av syv utfordringer gruppert i dette MapRoulette-prosjektet.

Gå gjerne gjennom utfordringene én oppgave om gangen, vurder dataene og korriger kvalitetsfeil der det er nødvendig. Teamet vårt vil jobbe med dem om et par uker.

Du kan finne mer informasjon om alle våre dataforbedringsaktiviteter i Norge på vår GitHub-side.

Jeg håper du liker de nye utfordringene. Gi meg beskjed hvis du har flere spørsmål.


“Norway | Not connected highway” is not properly set up. It ignores highway features which are connected to the pedestrian network - even features like highway=pedestrian and platform show up. It doesn’t take motor_vehicle=yes/destination into account either.

A few comments:

  • Please include in the instructions for each task to use “Norway Orthophoto” or “Kartverket N50 topo” as background imagery. The imagery you have listed on GitHub (Maxar, Esri, Bing) have large offsets in many parts of Norway, so please under no circumstance use them, and please edit this GitHub section.

  • Why is there a challenge for “mini_roundabout”? I cannot see any problems with them, and it is not clear from the task description what the problem might be. Are you looking for a large physical separation in the center? In general, it is very difficult to spot the difference between a “mini_roundabout” and a “turning_loop” from an orthophoto, unless there are painted arrows on the street.

  • I am not sure if it is worthwhile to have have a challenge for spiky buildings. I have not found any errors in the samples. Some buildings do (and should) have spiky polygons.

Thank you ENTUR | Johan Wiklund: our team will analyze and come back soon.

thank you User:NKA: i already adjusted the sources for editing as you advised, while will come back soon for the other 2 points regarding the mini_roundabout and the spiky buildings, while we do that, can you have a look at both challenges and see the remaining tasks if your comment applies to all

thank you

Looks like amenity=bench needs to be filtered out from the unclosed polygon task, e.g.

Hello ENTUR | Johan Wiklund,
thank you for your comment/observation, within a couple of weeks we will share more examples due to extensive work as we are conducting checks on the whole country.

Hello zidel
it is a “not an issues” situation so it can be skipped, we have done filtering and it can be an orphaned case, but thank you for the good catch.

for Spiky Buildings: thank you for the good catch and observation, if the building is spiky then you can kindly skip it, usually we generate such challenges as a standard error reporting and we always appreciate local knowledge and expertise from the community.

@NKA: thank you for your observations on the mini-roundabout.
I would ask you for now to apply your local knowledge and judgment on editing, removing or skipping the mini-roundabouts, however I would advise to consider connecting road geometries from a routing and application perspective.


Hi, we have noticed that your users are currently making changes in Norway which are not quite in line with acceptable edits.
Here is a clear example:

The user has made the following mistakes:

  • Using Maxar imagery instead of Norway Othophoto
  • Changed what is a perfect example of a track to a path

My intuition here tells me that the user is simply going by a list of routing islands and has been instructed to change all such TRACK into PATH, and imagery is not used to verify in great detail (which is not even possible with Maxar).

We would kindly ask that the user make visual verification before reclassifying these cases. This is obviously a tractor road between two fields and it should in fact be a routing island.

If this is related to Tomtoms car routing, I would advise you that track in Norway is normally used for mapping heavy equipment roads, and personal car routing should be “at your own risk”. If your project requires having motor vehicle connectivity for tracks, and therefor reclassify track-islands to path, I would say the project parameters are incorrect.

I have made some assumptions here - maybe I’m wrong, maybe I’m right - but the user in this case was definitively wrong, and many of your users have made similar edits.

@ENTUR Johan Wiklund

Thank you for your valuable observation, i will do the necessary actions with our editing team to be careful of such activities and indeed we have to take into consideration the road condition and imagery used. I have updated the sources used for editing on GitHub

@sbaido: Your multipolygon challenge is producing unwanted results such as in these changesets where tags are being duplicated:

Please terminate the multipolygon challenge now before you do more damage, and revert the changesets already committed.

All the undesired side effects of Tomtom’s project in Norway are concerning. Perhaps it would be better if you stop now.

@NKA: thank you for your input and observations, As for your concerns of the undesired side effects, we did and will continue to address all your observations and correct accordingly when needed. I will meanwhile work with the team to sort out the issues you pointed out and will come back.

Hello again @NKA,

we noticed that there are spiky building (+800 tasks: that needs to be fixed from our point of view, would you kindly like us to fix them, please give us your thoughts on these examples as below:

The problems are that

  • some of your challenges are not properly defined
  • your staff are not making appropriate choises

There is no problem fixing the “spiky” buildings as long as it is an appropriate edit. But if the result is worse than the initial problem, and the same faulty operation is deployed on a large scale - then what is the point. The result is either that you have to undo all your work - or worse, nobody spots it and the data in OSM is worse off than before. As such, just a big waste of everyones time.

We would love it so much if Tomtom conducted quality edits that improved Norwegian data, but now we are just sitting here on our toes, keeping an eye out for more, and I hesitate to say this, incompetent edits.

Please instruct your staff on how to make quality assured edits on a small scale per task before deploying them on a large scale. It will save us all a lot of problems.

If you wish, we could set up a Teams meeting (or similar) and you could tell us about all the types of edits you plan to do, and we could agree on how and what makes sense for Norway. THAT could save us some time, and make this project far more valuable for all of us.

I agree that the main goal is to assure the highest quality of edits in Norway. Yes i would like to have a teams meeting with you; let me send you a direct message to set up the call.

@NKA: the team has reverted the changes which you indicated. Additionally we have reverted similar few more which were corrected to avoid validation errors