Consider contry in tagging

[balp]

To separate the nvdb tagging from the tags used in Norway, add a country identifier such as se:nvdb or something look at the comments to https://www.openstreetmap.org/changeset/98318559

[NKAmapper]

I do not think these id's should be stored in OSM at all. If the highway is altered, concatenated etc then the id will not be correct anymore (the highway in OSM and in NVDB will not be the same). Also, if the id in NVDB is updated, the id will be unusable. This has happened twice in NVDB in Norway during the last two years for all highways. So it is better to exclude RLID from the output of nvdb2osm, which I think already has been done in #5.

[atorger]

I think you talk about different ID:s, RLID I have indeed already removed, but I tag with "source=NVDB" on the generic source tag, often using tags like "source=Bing" etc.

Maybe "NVDB" is a a bit too unspecific, but I did some searches in overpass and it doesn't seem to be used in Norway, while NVDB as tag has already been used as source tag in Sweden long before this script (NVDB data has been available for quite a few years already), so I reused the NVDB tag.

The source tag doesn't tend to survive for that long and I don't think it's that important. In actuality now when I do updates using this script, which I do fully manually looking at every road, I also look at photos and previous data etc and change where needed/suitable so even if NVDB is stated as source it's not purely NVDB, but I find it just too cumbersome to individually set the source to multiple sources. On the patch set I set multiple sources though (which generally is "NVDB; Lantmäteriet Topographic Map; Esri World Imagery" which are the main layers I use)

[NKAmapper]

And as we all know, source tags go on the changeset, not on the ways. https://wiki.openstreetmap.org/wiki/Key:source

[atorger]

Hmm... maybe one should remove the source tag completely then, I've tagged the ways as that's how it usually looks, but I guess that's because where I update there's usually lots of old data...

How do you search for changeset tags so you can see where in the map certain data sources have been used? The advantage of having a source tag is that it's searchable in overpass, but maybe changeset tags can be searched as well?

[NKAmapper]

Here is one tool: http://resultmaps.neis-one.org/osm-changesets?comment=nvdb (last 30 days)

[atorger]

Thanks! I've surfed a bit and it does seem like there's no tool for checking stuff older than 30 days. I find the source=NVDB tag to be quite useful in this context to be able to track things for the near to mid-term (ie a few years into the future which is what one can expect reaching a good baseline would take), but if it's against what people do these days when merging I'll remove it, and run without source.

There are other ways one can figure out if NVDB merge has been made, by looking at richness of various tags and quality of road alignment, so it's not 100% necessary to have NVDB source tag for the purpose of identification, but it is more convenient.

What do you recommend?

(In my workflow practice it will mean that I will use source=NVDB while working on the merge, as much of the previous geometry is "historical" and has source tag set, (gpx, landsat etc), it's easier to track conflicts than remember to remove an old tag that becomes misleading after update with fresh geometry, and then when I'm ready to upload a changeset I remove any source=NVDB tags.)

[NKAmapper]

I think the source tag is not particularly well suited for highways, because these ways will often be modified in OSM by somebody else at a later stage, and then the source tag is not really correct anymore. Also, I think the guiding in the wiki is quite clear.

My experience is that when large import files include extra/optional tags, then many users who import will also upload them. Therefore I think it is better to exclude the source tag from the generated import files. If anyone would like to have the tag because of their workflow, they can easily add it to the import file as a first step in the import process.

The Changeset Manger window in JOSM can download a list of changesets in the current view, including the comment text to those changesets.

[atorger]

Thanks, I'll remove the source tag.

[atorger]

I've pushed a patch and I tested it locally, so I think we can close this issue now.

The conclusion is that the layer should be free from any source tagging as that is how OSM is doing it these days.