<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>

<p>Hello,</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>"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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>/Anders</p>

<p id="reply-intro">On 2021-03-24 10:35, NKA mapper wrote:</p>

<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">

<div id="replybody1">

<div dir="ltr">

<div dir="ltr">

<div dir="ltr">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: <a href="https://nvdb-osm-map-data.s3.eu-north-1.amazonaws.com/index.html" target="_blank" rel="noopener noreferrer">https://nvdb-osm-map-data.s3.eu-north-1.amazonaws.com/index.html</a>.

<div> </div>

<div>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.</div>

<div> </div>

<div>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:</div>

<div>

<ul>

<li>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.</li>

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

</ul>

<div>The community could compare the alternative approaches for trunk/primary/secondary and trunk, for example using <a href="https://www.jottacloud.com/s/0592631d082283b49939bb929c3050af021" target="_blank" rel="noopener noreferrer">these examples</a> or others. (They are just for illustration, it is not a completed end product.) Further discussion on this topic <a href="https://github.com/atorger/nvdb2osm/issues" target="_blank" rel="noopener noreferrer">on Github</a>.</div>

</div>

<div> </div>

<div>Perhaps a high level tagging table for the most important features could be provided in the import plan, to document the choices..</div>

<div> </div>

<div>Finally, and just to be clear, I think Anders has done a great job at converting the very detailed NVDB dataset.</div>

<div> </div>

<div>/NKA</div>

</div>

</div>

</div>

</div>

<br />

<div class="pre" style="margin: 0; padding: 0; font-family: monospace">_______________________________________________<br />Imports mailing list<br /><a href="mailto:Imports@openstreetmap.org">Imports@openstreetmap.org</a><br /><a href="https://lists.openstreetmap.org/listinfo/imports" target="_blank" rel="noopener noreferrer">https://lists.openstreetmap.org/listinfo/imports</a></div>

</blockquote>

<p><br /></p>

</body></html>