With Taginfo I found a few source=* tags that simply refer to OSM or osm.org. I put them into Overpass Turbo here.
Are these tags redundant enough that we can just delete them?
3 Likes
Yes, for sure these can be removed, I do think there is no separate effort needed to clean them up.
If I use your overpass was working strange for me it did count many, many objects.
Filtering the source values in taginfo show, for example, 4729 ways tagged with “source=OSM;Maxar_Premium_Imagery” (link), I guess all mapped by one user.
I think it would be great to ping such a user via the changeset(s).
What possible benefit would there beof creating an extra object revision without a source tag? Just let the next person edit it - if it’s no longer appropriate, they can improve it then.
2 Likes
Nice suggestion. Currently I’m multitasking, so that’s going to end up somewhere in the to-do list.
Getting rid of redundant, meaningless data. Preserving those tags to ration version numbers sounds silly to me.
Deleting these tags one by one is a waste of people’s valuable time.
2 Likes
A scan through here filtered by “OSM” shows that most are not meaningless.
Of the ones that are just “OSM”, they’re oddly geographically distributed, and as suggested above it’d be interesting to know why they were tagged as they were.
However, that would require you to actually talk to people rather than just make a meaningless change to OSM data (again). 
2 Likes
That sounds similar to when they tag Bing as source. In other words, it’s the imagery they use while mapping on osm.org, thus the source is OSM. This would make sense as to why they chose this as source value.
But yes, unless you talk to them, you can’t be really sure.
It still feels redundant, unless they mention other actual source, like Bing or Maxar.
Such data, by its very definition, is unlikely to be consumed. Increasing version numbers, beside increasing the size of the main database, has a number of other unintended side-effects: it makes data look newer, it forces tile refreshes, it increases volume of differential updates. Each of these impacts directly on mappers and other resources immediately for a fairly nugatory potential future benefit.
A quick check on the example you provide suggest this is created by JOSM’s ability to add source of all imagery used to a changeset (see this example I created today to test), and this has for some reason also been placed on individual objects. The editor is a very experienced contributor. Unlike iD, Josm does not use imagery_used as a changeset tag by default.
The source tag is very rarely propagated by data consumers as it falls into a class of tags which are not about the element, but about aspects of how the data were captured. (It’s a post for another time, but I do see some benefit in holding such tags in a separate hstore column (metatags ?) in the API database.)
1 Like
That’s why I’m not planning to touch those.
Oh yeah, that’s very typical. The Germans usually don’t do a lot of OSM data cleanups. Every time I look at questionable mapping or tagging practices, Germany has a high density of them.
So we shouldn’t update OSM data because doing so updates the map. If you like, we can revisit this issue when you and SomeoneElse have drafted a guideline for which data updates are important enough to justify a map update.
Feel free to comment on this thread that I created about this exact topic: "Meta" tags · osmlab/osm-data-model · Discussion #27 · GitHub
This is not really safe to assume to be meaningless. I prefer to use source on changeset comments, but its specifies that edit was made based on existing OSM data, rather than on survey.
4 Likes
Okay, that’s an argument I can agree with.
1 Like
I generally prefer to put source tagging on changesets and not OSM objects – but – I have definitely indicated “existing OSM data” as a source in certain cases. I do this in cases where I’m modifying something and want to specifically indicate that I’m using geometry that someone else has already mapped but modifying it in some other way.
3 Likes
Thanks for the insight. That’s a case I hadn’t considered.
1 Like
Have done so as it seems very close to what I have envisaged.
1 Like
I did a (not so) quick check at the results in my extended home region, the border triangle France, Luxembourg, Germany. Most results are along the rivers Rhine, Mosel, Saar and were done by seamark mapping more than 10 years ago and it seems to me that source=OSM was just right at the time of the mapping.
obstacle=bridge, line, … were created where a bridge or a power line existed. I think that the source tag could have changed or deleted in case of finer mapping with OTG data such as height that could not derived from existing mapping.
Some other mapping could be moved to “fixme”, that’s river:waterway_distance like Node: 1770298585 | OpenStreetMap
I have cycled those parts of these rivers and I don’t believe there are really missing distance boards. There’s not a single one missing at the river Saar, not even at (Relation: Canal de la Marne au Rhin Est (3340793) | OpenStreetMap) or Relation: Canal des Houillères de la Sarre (1273572) | OpenStreetMap
I’m pretty sure there’s not a single one missing at the Rhine or Mosel too.
Additional question after another check:
Having the node Node: 1769584602 | OpenStreetMap from this initial mapping with later additions such as seamark:distance_mark_category=not_installed and the board Node: 393857287 | OpenStreetMap. Can I just delete the first one. That one is obviously wrong and superfluous because of the second one with OTG research. And do that for similar object combinations of this type too? OK, I have to extend the tagging of the board with the right seamark tagging from the first one in the middle of the waterway before deleting.
That would reducing the number of objects with source=OSM too.
1 Like
It seems to me that all seamark:distance_mark:category=not_installed are invalid. And if Node: 393857287 | OpenStreetMap is accurate this is also wrong in this case
but maybe it should be retagged, not deleted?
Tag:seamark:distance_mark:units=kilometres - OpenStreetMap Wiki makes a distinction between “virtual distance marks”, that got to be tagged in the middle of the waterway and boards on the shore, that get tagged at the OTG position.
If there are boards mapped like in the referred case there is not only no need for virtual distance marks. They are simply wrong. But the board got to get the right tagging from the virtual distance mark because most time there is only the distance marked.
After that is done at the board node the virtual distance mark can be deleted. No information is lost, and the mapping is better than before. This can and should be done manually.