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

[Anders Torger]

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.

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.

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.

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: https://wiki.openstreetmap.org/wiki/Sv:Map_Features, and I 
have fleshed them out a bit more in text here: 
https://wiki.openstreetmap.org/wiki/Import/Catalogue/Sweden_highway_import/Import_guidelines#Highway-typ 
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.

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.

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.

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.

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.

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.

/Anders

On 2021-03-24 11:47, NKA mapper wrote:

> Thank you, Anders - this is a very helpful and most welcome initiative.
> 
> I did not find a link to the import files - they are here may be 
> reviewed: http://nvdb-osm-map-data.s3-website.eu-north-1.amazonaws.com 
> [1]
> 
> I only have two issues, which would be good to resolve:
> 
> 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.
> 
> 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.
> 
> Here are a few examples on how trunk/primary/secondary would look with 
> "standard" tagging: Examples [2] (these examples are just for 
> illustration, they are not complete end products).
> 
> I already know Anders' opinion on these two questions, but it would be 
> good to understand the opinion of other members of the community.
> 
> In other respects an excellent job by Anders :)
> 
> /NKA
> 
> ons. 24. mar. 2021 kl. 11:05 skrev Anders Torger <anders at torger.se>:
> 
>> FYI, I just went through the archives of talk-se a bit further back 
>> and
>> indeed there I see many names I recognize also from the OSM Sweden
>> Facebook group, so it's known also by those users. My email there 
>> still
>> seems stuck in a moderator queue though so it's not appeared yet and
>> there have been no posts in that list since February 12.
>> 
>> I've also just posted to the OSM forum,
>> https://forum.openstreetmap.org/viewtopic.php?id=72307 but again much
>> lower activity there than in the facebook group and fewer of the
>> experienced mappers so I don't have high hopes for a lively discussion
>> there, but we'll see. Just making sure that so many as possible is
>> reached before we go ahead.
>> 
>> Most discussion so far have taken place in the facebook group as well 
>> as
>> the issue tracker when the translation script has been debugged and
>> refined https://github.com/atorger/nvdb2osm/issues/, and there most
>> feedback has been from a Norwegian import expert, the brain behind the
>> Norwegian NVDB import so it's been very useful.
>> 
>> In the broader facebook group there's overall only been a handful of
>> individuals involved actively in the discussions which has mostly been
>> by answering open questions I've put out to the community regarding 
>> best
>> practices, plus we've had endorsement by end users and casual mappers
>> that just want to see better quality in the Swedish OSM road data. The
>> Swedish OSM community is pretty small, and the group of users with
>> long-term experience that is also active today is even smaller so we 
>> do
>> not expect a big discussion to take place within the Swedish 
>> community.
>> 
>> One concern that has been raised not by OSM people but from the 
>> general
>> GIS community which also is active in these forums is how we're 
>> supposed
>> to keep in synch with NVDB, pushing the idea that an import would be
>> meaningless if it can't keep up the changes. NVDB is indeed 
>> continously
>> updated when new roads are built or traffic rules change, there's even
>> an open live API to get live changes. Our response to that is that 
>> most
>> of the road network is static, and once the overall quality of the OSM
>> data is raised such that roads are actually positioned correctly and
>> have good coverage it's much easier to make quality assurance tools 
>> that
>> can automatically compare and make small diffs between NVDB and OSM 
>> say
>> on a yearly basis for manual review and inclusion. It's an open 
>> question
>> though, for the initial import work we don't have a plan to
>> automatically keep track of changes.
>> 
>> /Anders
>> 
>> On 2021-03-24 08:36, Anders Torger wrote:
>>> I've made an announcement to talk-se as the process requries, no 
>>> reply
>>> yet. But it was recent and there is very low activity in that group.
>>> Still waiting. I actually do not know about the visibility, there's
>>> relatively low activity in also in the Facebook group, lots of 
>>> passive
>>> listeners which I do not know the names of. That I ended up there is
>>> by going through all the various forums etc to find where "all the
>>> action were", and while relatively low activity it was more than in
>>> the other places. (Facebook groups for all sorts of things is very
>>> popular in Sweden).
>> 
>> _______________________________________________
>> Imports mailing list
>> Imports at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/imports



Links:
------
[1] http://nvdb-osm-map-data.s3-website.eu-north-1.amazonaws.com/
[2] https://www.jottacloud.com/s/0592631d082283b49939bb929c3050af021
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20210324/857f7192/attachment-0001.htm>