
<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>Considering reviewing, it's fine to look at those, but one can also review pilot work being done which actually shows the end result after applied process.</p>

<p>Storuman, Vilhelmina, Dorotea and Lycksele municipalities is done, and Övertorneå is being worked on, which is taking quite some more time than expected due to many positional issues. In the actual changesets one can see how we use the highway tags in the end, as they are often changed from what the translation script has done.</p>

<p>I have so far never come across a road in the range trunk->tertial which has not been mapped previously, so one doesn't need to make any decisions there, just pick what's already used since before. If one changes these one *really* need to know what one is doing, and one should probably discuss it first. While I think that secondary is under-used in some municipalities in north of Sweden I would take that discussion separately, I don't think that is a useful scope for this import project. Changing these is a rather easy operation practically, deciding to change from what's already decided a long time back is a big thing.</p>

<p>Practical decision-making happens in the residential->track range, here there are more roads that are new, and there is more of bad tagging previously as these minor roads are often made by less experienced mappers and may have made some strange tagging decisions at times. Recently I've seen quite a lot highway=road, which is a tag used when the mapper haven't been able to decide. Anyway, there are the generic guides here: <a href="https://wiki.openstreetmap.org/wiki/Sv:Map_Features,">https://wiki.openstreetmap.org/wiki/Sv:Map_Features,</a> and I have fleshed them out a bit more in text here: <a href="https://wiki.openstreetmap.org/wiki/Import/Catalogue/Sweden_highway_import/Import_guidelines#Highway-typ">https://wiki.openstreetmap.org/wiki/Import/Catalogue/Sweden_highway_import/Import_guidelines#Highway-typ</a> for dealing with typical challenges that appear during import. I think that is about as much as we can do. I'm thinking of making a guide with more examples with screenshots too, but that would be later.</p>

<p>In this small road range it's simply not possible to make a translation from NVDB that one can just import without consideration. Regardless how you do the translation, with geometry analysis or only static tag conversion, there will be errors. Maybe 20% maybe 10%, but the mapper should strive for 100% correctness on the roads that goes into the changeset. Sure there will be mistakes and subjective decisions that differ mapper to mapper in some cases, but the intent must be there.</p>

<p>Regarding re-tagging, expert users can run the script on their own computer with custom settings. If you work with a municipality that is very service-road dense, you can change parameter. There's "--small_road_resolve prefer_service" option for example. I prefer the one which leads to more tracks, as the service roads are typically clustered in denser areas and thus easy to bulk-change (filter, select square, bulk-change, ready), while if "prefer_service" option is used I get quite some false service roads in the forestry and agriculture network which are more spread out. For me I prefer clustered errors than spread out errors I think it's a lower risk for me making errors that way, even if there are a higher number of roads in those clusters. But it's personal preference.</p>

<p>And if I do make an error I think it's better to have a track that should be service than a service that should be track, as if it's service it leaves the next mapper more confused why service was chosen there although he/she can't see a sign that it should be service.</p>

<p>Also where there is service roads there's also often unclassified and a track or two, and some roads need to be split, service road to house, continuing as a track to the agriculture behind. Regardless which setting the script has, there will be quite some re-tagging of highway type, otherwise one is doing it wrong.</p>

<p>When asking the community about preference on this issue, one must make clear that there will be errors regardless, and the importer is required to go through all roads and make a decision. So it's about which preference you have how these errors should be distributed, not that any of the alternatives out of the script could be used as-is.</p>

<p>/Anders</p>

<p id="reply-intro">On 2021-03-24 11:47, 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 style="color: #000000;">Thank you, Anders - this is a very helpful and most welcome initiative.</div>

<div style="color: #000000;"> </div>

<div style="color: #000000;">I did not find a link to the import files - they are here may be reviewed: <a href="http://nvdb-osm-map-data.s3-website.eu-north-1.amazonaws.com/" target="_blank" rel="noopener noreferrer">http://nvdb-osm-map-data.s3-website.eu-north-1.amazonaws.com</a></div>

<div style="color: #000000;"> </div>

<div style="color: #000000;">I only have two issues, which would be good to resolve:</div>

<div style="color: #000000;"> </div>

<div style="color: #000000;">1) I would prefer to be able to see which roads are state/national roads and which are county roads (primary/others), tagged as highway=trunk, primary and secondary, respectively. This way I can make decisions about up/downgrading them before uploading to OSM. Currently, the script is making educated guesses about which tag to use, so that a county road could be any of highway=trunk, primary, secondary and tertial. That makes it difficult and time consuming to "read" the import file without spending time on analysing highway numbers etc.</div>

<div style="color: #000000;"> </div>

<div style="color: #000000;">2) In my opinion there is too much highway=track at the moment. In many mixed urban/rural municipalities such as for example Uppsala, several residential and rural roads are tagged as track. I think it would be better if highway=track is only used for the forestry roads. When importing, I would spend too much time on retagging track to unclassified and service with the current proposal.</div>

<div style="color: #000000;"> </div>

<div style="color: #000000;">Here are a few examples on how trunk/primary/secondary would look with "standard" tagging: <a href="https://www.jottacloud.com/s/0592631d082283b49939bb929c3050af021" target="_blank" rel="noopener noreferrer">Examples</a> (these examples are just for illustration, they are not complete end products).</div>

<div style="color: #000000;"> </div>

<div style="color: #000000;">I already know Anders' opinion on these two questions, but it would be good to understand the opinion of other members of the community.</div>

<div style="color: #000000;"> </div>

<div style="color: #000000;">In other respects an excellent job by Anders :)</div>

<div style="color: #000000;"> </div>

<div style="color: #000000;">/NKA</div>

</div>

</div>

<br />

<div class="v1gmail_quote">

<div class="v1gmail_attr" dir="ltr">ons. 24. mar. 2021 kl. 11:05 skrev Anders Torger <<a href="mailto:anders@torger.se" rel="noreferrer">anders@torger.se</a>>:</div>

<blockquote class="v1gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: #cccccc; padding-left: 1ex;">FYI, I just went through the archives of talk-se a bit further back and <br />indeed there I see many names I recognize also from the OSM Sweden <br />Facebook group, so it's known also by those users. My email there still <br />seems stuck in a moderator queue though so it's not appeared yet and <br />there have been no posts in that list since February 12.<br /><br />I've also just posted to the OSM forum, <br /><a href="https://forum.openstreetmap.org/viewtopic.php?id=72307" target="_blank" rel="noopener noreferrer">https://forum.openstreetmap.org/viewtopic.php?id=72307</a> but again much <br />lower activity there than in the facebook group and fewer of the <br />experienced mappers so I don't have high hopes for a lively discussion <br />there, but we'll see. Just making sure that so many as possible is <br />reached before we go ahead.<br /><br />Most discussion so far have taken place in the facebook group as well as <br />the issue tracker when the translation script has been debugged and <br />refined <a href="https://github.com/atorger/nvdb2osm/issues/" target="_blank" rel="noopener noreferrer">https://github.com/atorger/nvdb2osm/issues/</a>, and there most <br />feedback has been from a Norwegian import expert, the brain behind the <br />Norwegian NVDB import so it's been very useful.<br /><br />In the broader facebook group there's overall only been a handful of <br />individuals involved actively in the discussions which has mostly been <br />by answering open questions I've put out to the community regarding best <br />practices, plus we've had endorsement by end users and casual mappers <br />that just want to see better quality in the Swedish OSM road data. The <br />Swedish OSM community is pretty small, and the group of users with <br />long-term experience that is also active today is even smaller so we do <br />not expect a big discussion to take place within the Swedish community.<br /><br />One concern that has been raised not by OSM people but from the general <br />GIS community which also is active in these forums is how we're supposed <br />to keep in synch with NVDB, pushing the idea that an import would be <br />meaningless if it can't keep up the changes. NVDB is indeed continously <br />updated when new roads are built or traffic rules change, there's even <br />an open live API to get live changes. Our response to that is that most <br />of the road network is static, and once the overall quality of the OSM <br />data is raised such that roads are actually positioned correctly and <br />have good coverage it's much easier to make quality assurance tools that <br />can automatically compare and make small diffs between NVDB and OSM say <br />on a yearly basis for manual review and inclusion. It's an open question <br />though, for the initial import work we don't have a plan to <br />automatically keep track of changes.<br /><br />/Anders<br /><br />On 2021-03-24 08:36, Anders Torger wrote:<br />> I've made an announcement to talk-se as the process requries, no reply<br />> yet. But it was recent and there is very low activity in that group.<br />> Still waiting. I actually do not know about the visibility, there's<br />> relatively low activity in also in the Facebook group, lots of passive<br />> listeners which I do not know the names of. That I ended up there is<br />> by going through all the various forums etc to find where "all the<br />> action were", and while relatively low activity it was more than in<br />> the other places. (Facebook groups for all sorts of things is very<br />> popular in Sweden).<br /><br />_______________________________________________<br />Imports mailing list<br /><a href="mailto:Imports@openstreetmap.org" rel="noreferrer">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></blockquote>

</div>

</div>

</blockquote>

<p><br /></p>


</body></html>