2) same logic - bus stops should have neither wikipedia nor wikidata tags, but use network:wiki* tags instead. Same thing - now that these objects are trackable, they can be converted to network as well. Performing just one task is much safer for the stability of the data. I can move all bus stops for a single network in one swoop, verifying data more meticulously.

1) correct - when doing semi-automated changes, it is not a good practice to change multiple things at once, because in case of a mistake, the partially-automated and partially-manual changes are hard to undo (wastes a lot of effort). So step one is to add matching wikidata item, just as described in the chat, and step 2 is to move wikipedia/wikidata tags, with discussion, to brand. Brand conversations have already been going on in various channels.

Harald, this was just a trailing space tag name correction of the existing tag (something JOSM was complaining about). I wouldn't want to touch the meaning of that tag without JA community involvement. It does look like a website, but this is beyond my competence. In retrospect, I probably shouldn't have changed that tag at all, because partial correction is not a "good thing" (tm).

Andy, are you saying that neither Q2407197 nor en:Tibshelf should be attached to rel 957593 ? It the WD item is correct for both - it is both the city and the parish.

I have reverted all of the relations and nodes that contained "#" in their "wikipedia" tag. I put together some thoughts on how wikipedia/wikidata should be validated and improved - osm.wiki/Wikipedia_Improvement_Tasks

https://lists.openstreetmap.org/pipermail/talk/2017-September/078720.html

Hi Spiegel0, yes, anchor-links should be handled separately. The problem is that wikipedia tag is used in multiple ways:
* this object has a wikipedia page (1:1)
* this object is mentioned on a wikipedia page
* this object's "type" (brand/concept) has a wikipedia page

As mentioned in the @talk conversation, and as proposed in osm.wiki/Proposed_features/Wikipedia_tag_types , we need to use different tags to separate those use cases, keeping the "wikipedia/wikidata" only for the first - 1:1 usecase. I am not sure what to call these tags yet (perhaps section and list are too specific). Note that iD automatically adds wikidata every time you add wikipedia, so we should approach this systematically, not just for a specific edit.

Rom1, I agree - wikidata should not be set for a place of business that is a chain - e.g. Mc Donalds. As discussed in the @talk, this is just the first step that allows rapid search for all such places. The next step is to move all wikipedia and wikidata tags to brand:* for the chains, as well as other things like subjects and species.

I think you have the wrong changeset. This changset did not move any objects. I see you already fixed Pechers'ka.

@Nakaner, this is a very valid point - there is clearly a mistake in this edit - basically propagating previous mistake. But this does not warrant undoing significant manual time I spent validating it. Now that the value is cleaned up, it would be significantly easier for queries to spot these cases - by simply querying for anything with ele < elevation of Bavaria. On top of my mistake, that query would catch all other broken cases where people did not include units, making it appear correct. But with your revert, I won't be able to do this as easily using automated QA - I would simply miss cases like this. I was, or at least tried to, follow the rules for automated edits. If I broke the rule, please explain which one, so I wouldn't do it again. Thanks!

@nakaner, that's because I had them all in the same JOSM session - I reviewed them, did several auto and manual checks, visually inspected them, and then uploaded them one area at a time. I was told by other OSM members that this way its easier for them to check my changes rather than when they see a very large changeset.

P.S. the only "mechanical" part was finding these cases using the Wikidata+OSM service. Fixing was not.

@nakaner, all of these "123 m" -> "123" were inspected by me. These are not automatic.

Michael, this was not a mechanical edit. I was cleaning up roads, and reviewing them individually by hand. Most of the time in OSM, various roads, boundaries, and waterways are incompletely tagged with wikipedia/wikidata in both the relation, and *some* of the ways, which makes it for a bad data. Cleaning them up makes it easier to maintain - relation has the common data, ways have data that differs. E.g. speedlimit is one per segment, relation has road names and wiki links.

Ah, that makes sense - you are using tools.wmflabs.org - that's the tool labs, a user-controlled server farm under WMF control, but different IPs, and different capabilities. Apparently, its not blocked. One way to work around the ban would be to use my new service - I just added it to the latest wikipedia plugin. But it doesn't use it for those queries yet, only for the download screen... I need to think about it...

Hi, this is very strange. Both Fetch Wikidata IDs, Fetch Wikidata coordinates, and Fetch Wikipedia coordinates use exactly the same server. Are you sure both work?

@SomeoneElse, I think it should be fixed differently - we should remove all tags except name, note, source, and type, and create a relation that has all the original tags with those two ways.

This is awesome!!! I think we should adapt your bot to other places, e.g. US and Russia (the two places I know a bit better than others). Could you make your bot also track any entries that have the same wikidata ID as ones listed in the template, and update those places accordingly?

Thanks and sorry to hear that :( I have filed a bug https://josm.openstreetmap.de/ticket/15314

Hi, if possible, please run JOSM's "wikidata" plugin - it can add the corresponding wikidata tags with just one command. Thanks!