I propose to do an automated edit as described here:
https://wiki.openstreetmap.org/wiki/User:Kmpoppe/Automated_Edits/Fix_Name_Inconsistencies
For documentation purposes, please discuss or approve on the wiki page, thanks!
K
I propose to do an automated edit as described here:
https://wiki.openstreetmap.org/wiki/User:Kmpoppe/Automated_Edits/Fix_Name_Inconsistencies
For documentation purposes, please discuss or approve on the wiki page, thanks!
K
How would that help ensure that names in OSM are correct?
Essentially, you’ve seen some information suggesting that a name (or lack of name) might be incorrect, and your suggestion is just to remove that suggestion?
I’m sure that there are examples where, after checking the object history (or aurvey), you can remove a fixme because a problem has been fixed, but it shouldn’t be a mechanical process.
My apologies if I have got the wrong end of the stick here, but your suggestion does sound worrying.
After only 5 people answering (including those initially suggesting it), I got so many different opinions that I could directly bin the idea again.
Maybe going the completely neutral approach (deleting the fixme
only when someone answers a name-related quest in SC) is the only way
Is the list of objects that would be affected by the proposal available, or is there a query we could run to see see these objects in a particular area?
I’d like to look at a sample of cases to see if there is any pattern, e.g. maybe the names on noname=yes objects are not clear-cut (e.g. they might be more like descriptions). But querying the database based on tags changing at different dates is beyond my limited skills.
In certain situations the fixme
may be safe to delete, for example if someone leaves fixme=name
on an object with no name and then a subsequent mapper answers the StreetComplete quest “Determine place names”. A mapper using any normal editor would have noticed the fixme
and deleted it when entering the name, but SC doesn’t give that option, so it leaves the fixme
tag.
However, identifying these situations requires looking at the object history and the changeset tags. Not sure if the effort is worth it. If there’s a mapper nearby looking at fixme
s, they’ll probably quickly realise what’s happened and delete the tag.
Well, perhaps if by “Any normal editor” you meant “(only) JOSM”
Looking at top 10 editors (both desktop and android) that I can access, none except JOSM seem to make that fixme=name
visible on the first page (usually it was either in some “advanced” tab, or offscreen at the bottom of a long list, or not visible at all).
At the same time, name=*
was right there at the top.
So I find it highly likely that if there was fixme=name
without name=*
tag, and afterwards object was edited to include name=*
tag (but fixme=name
was not removed), that such failure to remove it was because they’ve just haven’t noticed that (well hidden) fixme=name
tag (and NOT due to mapper adding a name, but still not being sure that they’re adding a correct name)
Yes, I would’ve thought that looking at object history was prerequisite anyway (how would you know otherwise whether it was first name=*
and then fixme=name
, or vice-versa? Those two situations require totally opposite handling for same current tags…)
But it could be made more certain if changeset editor is accessed:
name=*
but didn’t remove fixme=name
was StreetComplete or SCEE or Organic Maps (or MAPS.ME I assume too?), than that fixme=name
is definitely an error and absolutely should be removed, as those don’t seem to ever show that tag.fixme=name
after adding name=*
is not extremely uncommon thing)iD does make fixmes very visible, it shows a yellow warning box right at the top. Not sure about the others!
Anyway, in general I agree with you. The tricky part is that Overpass only gives you very limited access to an object’s history. For example, I don’t think it lets you inspect the changeset tags that store the information which editor was used to make a change.
I did a global automated edit a while back, after much community discussion etc. When I wanted to limit it to those nodes where editor X had been used to add tag Y, I had to write code to query the API for the history and changeset metadata for each object that I was thinking about touching.
yes, in some case it would be useful
having fixme
as say amenity=fast_food fixme=name
is just utterly pointless.
Especially given that it was apparently machine-added in at least some cases (see jumps in 2012), see fixme=name | Tags | OpenStreetMap Taginfo
removed
There are a couple of problems with Maproulette:
Now obviously you could say that you will address (1) and (3), and you could try and deter people falling foul of (2) by making clear the level of investigation required, but ultimately most are still not remotely resolvable.
Looking at an example somewhat near me, the fixme there dates back 11 years. There’s not an obvious name source such as OS OpenData that could pin down which bit is what, and likely it’s going to need a survey, along the whole of that quite long section.
As noted above, it’s easy to see current issues with overpass, and a number of editors already make fixmes fairly clear. I’d suggest that your time would be better spent going out and surveying any within 20km of you .
The original scope of the proposal would’ve been broader than that of an effective MapRoulette challenge anyways. But if you could narrow it to certain classes of features, in places where there’s likely to be either common knowledge or resources at mappers’ fingertips, then it would get more uptake and probably yield more accurate results, even if you mark the task as needing local knowledge.
It looks like you’ve already narrowed down the set based on element history, which is a good start. It sounds like some of the commenters earlier missed this aspect of your proposal, as I did the first couple times I read it. I guess what could help is an analysis of when the contradictory tag was added. iD only gained a warning about contradictory tags last February, so the cases before that time might be more likely to be oversights than the cases afterwards.
There’s also JOSM to consider. Would it be possible to analyze changeset tags to determine the editor involved? When I analyzed element history for this one-way discussion, Osmium did provide access to changeset tags, which might’ve been useful that time too.
Thanks for your comments @Minh_Nguyen.
I think grouping the objects by aspects that aren’t known to me from the outside would prove difficult and could also probably ending up with a more confusing set of tasks for the MapRoulette users.
If you’re already examining element history, you might be able to identify a specific mapper who used both noname=yes
and later name=*
on the same element, which would be more clearly an oversight. Or a changeset that added the names en masse, which you could reach out to the mapper about. Just spitballing here, but I imagine there might be some low-hanging fruit if this is a tagging combination you’re still interested in.