[Imports] Road data imports from CC0 government database for Sweden

[Anders Torger]

Hello,

I think highway type is given may too much focus. It will never be 
perfect out of NVDB and will always require manual adjustment, which is 
clearly documented in the import guideline. There are already clear 
specifications on the wiki and traditions in practice how highways 
should be tagged, and testing has shown that regardless of translation 
pattern we use in the script, it won't match the current mapping 
tradition and what's currently in OSM.

I push very strongly for that automatic conversion should not be used in 
the blind. I don't even like the term "import" because it gives people 
the wrong impression of how this is going to work. It's basically manual 
mapping on steroids, rather than an import.

It's a manual merging process, NVDB is good for some fields, worse for 
others. It's great for maxspeed, it's not good at all for resolving OSM 
highway type, and we're not going to pretend that it is. This is clearly 
documented in the import guideline what the importer needs to do. It's 
not about blindly copying the layer without modification, never has 
been, never will be. The little feedback I've got from Swedish long-term 
experienced users is exactly this, that we should not make some static 
conversion and just copy, but that it should be up to traditional mapper 
judgement following the rules that have already been established since a 
long time, and I agree with them. If NVDB can't be made to match those, 
tough luck, manual work is required, and that's exactly where we are.

90% of the roads already exist in Sweden. It's just that the positioning 
is not that good and geometry can be low detail, and detailed tags like 
maxspeed etc can be missing or outdated. Highway tags are usually just 
fine though. This effort is not about improving highway tags, but 
improving the rest.

We are not supposed to change the mapping tradition so it conveniently 
matches what an NVDB translation can produce. Adjusting highways 
manually here and there is also compared to all other things you need to 
do when importing a smaller amount of work, and also forces you to do a 
healthy dose of inspection of both Lantmäteriet raster map and aerial 
photos to make the right decisions, so I don't think one should put so 
much focus on that.

The description of how conversion of trunk to tertiary is done in the 
script is not correct. It's a static conversion. Still there will be 
many mismatches, because NVDB is not OSM. If you look at all layers NVDB 
provides it has several different layers where roads are given different 
classes depending on traffic use. The script currently uses two of those 
layers, which from testing has shown to match OSM a bit better than only 
using one, but still there will be deviations. And as we write in the 
import guide, using what's already mapped in OSM is nearly always the 
best choice.

I don't think there's a value to specifically make a table in the docs 
of how these tags are translated. The script work through more than 40 
data layers and extract tags from them, and I'd say that while highway 
tag is the immediately most evident it's the least important as it 
cannot be correct regardless how we do it. It's more important that the 
good data is translated correctly, like traffic restrictions, one way 
roads and similar. How this is done is in the Python script.

There is subjectivity also in NVDB's classification. It's not that 
simple that a road with 3 numbers is secondary all the way. Many roads 
get less and less important the farther away from densely populated 
places they get, and they suddenly change classification without 
changing road number. This happens in NVDB, and this happens in OSM. The 
classification for a popular tourist location can be different looking 
at motorcar traffic than compared to hgvs, and so on. Inside bigger 
cities NVDB classifications are pretty chaotic with the 9 levels, and 
regardless how you make the cutoff, you will get some strange effects in 
them where roads change class where they shouldn't. Manual adjustment 
required.

"Guessing" in the script only takes place for the range unclassified, 
track and service. NVDB has no information if a road leads to a house or 
a beach or something else which makes it a service rather than say a 
track. Also for the minor roads the reporters are forestry companies and 
private individuals so the classification is pretty chaotic with many 
quality issues. These will always require a large amount of manual 
adjustment. While NVDB has an understanding for residential, it does not 
fully match how OSM defines residential so it gets underused. Also that 
needs manual correction. Every road should be considered manually. The 
"guessing" looks at road geometry and can identify likely driveways in 
rural areas and thus reduce the need for manual changes, speeding up the 
work a bit.

If you think there are too many track, just tune the script to make more 
service, the source code is there for advance users to tune, and now 
there even are command line options to tune the algorithm.

In the end it doesn't matter. You still need to consider each and every 
road individually to make sure you pick the right highway type. It's 
what I've done in my pilot work when testing out the script and process, 
and I strongly believe this is how you must work. Since 90% of the roads 
are already covered you most of the time already have a good suggestion 
of what the road should be, and if not, there are guidelines.

For this import to work at all, we must recruit people that are serious 
about doing good work, and not just want to make quick work not caring 
about the result. This is not a problem with the script, it's just the 
fact of NVDB is not the same as OSM.

/Anders

On 2021-03-24 10:35, NKA mapper wrote:

> This import plan was submitted to the import list a bit earlier than I 
> anticipated. I think it would be a good idea if the local community 
> could review the import plan first (it was posted to Facebook 
> yesterday, earlier just specific questions), and that the community 
> could review import files (so far no link to import files have been 
> provided). Here is the link to the files: 
> https://nvdb-osm-map-data.s3.eu-north-1.amazonaws.com/index.html.
> 
> The discussion would be open and documented if the local review could 
> be done on the Swedish OSM mailing list or on the Swedish OSM forum. I, 
> for one, do not post on Facebook.
> 
> I disagree with some of the main highway tagging choices, and there 
> have been different opinions about this on Facebook already. I think it 
> would be good if these choices, and their alternatives, are highlighted 
> in the local review. Examples:
> 
> * The script is making educated guesses about how trunk, primary and 
> secondary should be tagged. This has the implication that trunk, 
> primary and secondary are not corresponding to state roads, primary 
> county roads and secondary county roads, respectively. The Swedish 
> tagging guidelines for these highway classes are quite elaborate and to 
> some extent subjective. I think it would be better for the person who 
> is importing to clearly see what the highways represent, i.e. which 
> highways are state (trunk), primary county (primary) and secondary 
> county (secondary). The importer can then make his/her own choices for 
> tagging.
> * The script is also guessing which roads should be track. I think 
> there are way too many tracks in the current version, for example many 
> residential roads and rural roads are tagged with track, especially in 
> semi-urban municipalities such as for example Uppsala. There are ways 
> to limit the scope of track based on information in NVDB. (I do not 
> have an issue with the real forestry roads. The Swedish tradition in 
> OSM is to tag forestry roads as track, even if they can be used by 
> large logging trucks and normal cars.)
> 
> The community could compare the alternative approaches for 
> trunk/primary/secondary and trunk, for example using these examples [1] 
> or others. (They are just for illustration, it is not a completed end 
> product.) Further discussion on this topic on Github [2].
> 
> Perhaps a high level tagging table for the most important features 
> could be provided in the import plan, to document the choices..
> 
> Finally, and just to be clear, I think Anders has done a great job at 
> converting the very detailed NVDB dataset.
> 
> /NKA
> _______________________________________________
> Imports mailing list
> Imports at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports



Links:
------
[1] https://www.jottacloud.com/s/0592631d082283b49939bb929c3050af021
[2] https://github.com/atorger/nvdb2osm/issues
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20210324/ea6b4ac7/attachment-0001.htm>