[OSM-talk] Worldwide non-surveyed tag edits

John Packer john.packer7 at gmail.com
Thu Jun 12 12:36:55 UTC 2014


Friends,

Some examples of bad and good gardening, and how unpredictable this
business can be:

1. Once I searched for wikidata values without "Q" as a prefix. I found
some values (not many), and to guarantee the quality of my work, I opened
each object's wikidata page to verify the new value would be the correct
one. Turns out that one of the objects had a tag "wikidata=1960", and it
didn't correspond to "wikidata=Q1960". It was in another language, so I
couldn't find the correct one, so I messaged the user that added this data,
and he verified my assumption: it was supposed to be start_*dat*e instead
of wikidata;

2. Once, some guy removed around 80 websites or so in South America. They
were all websites that Keepright reported as not found or something
equivalent. I was annoyed by this change, and asked him to revert his
changeset, which he quickly complied. At first the logic seems solid on
this kind of change, but we never know if the website will remain offline
or it was just temporary, if Keepright (or the gardener himself) simply
can't access the website from his location, if there is a typo in the url
(e.g.  ".com" instead of ".org"), etc. To aggravate the problem, as some of
you may know, recently I found out there were some URLs that were
"corrupted" by invisible characters (see [1]). They probably would be
removed by these kind of changes, even though they only need a simple fix.

3. In the beginning of this year, there was some commotion in the brazilian
community because some guy started manually using a spell-checker in
street's names in Brazil. It did fix some hard to find mistakes (like Kubit
*s*check instead of Kubitcheck), but also could introduce errors (like it
did on a street which had an indigenous name). The user was an considerably
experienced mapper, and was tech-savvy, but there was no way to guarantee
this kind of work would be free of errors, so he stopped doing that.
This kind of correction can be useful in some select cases: Here in Brazil,
there are some official maps that are devoid of diacritics, so it would be
completely valid to manually run an ortographic corrector on streets that
were added from these maps (and not by survey).

4. A friend of mine, which is a really experienced mapper, sometimes go
around gardening the map. Once I was reviewing one of his changesets, and
he added a tag amenity=community_center to a place with "Community Center"
in the name, even though it was actually "amenity=social_outreach". Usually
he does good gardening, but it's just to show that even an experienced
mapper makes mistakes (just imagine what an enthusiastic OSM newbie that
wants to go on a gardening spree worldwide can do)

Besides the numerous cases of users that try to "tidy up" some objects, and
unintentionally make the object lose accuracy.

What I mean to conclude:
Gardening (without local knowledge) *IS* a tricky business, and it should
be treated like so.
It is far too easy to change another user's work, and it is orders of
magnitude more expensive to actually go and collect the data.

The policy of "if no one complains, then it's ok" is in place so people can
actually do gardening without needing to discuss everything before.
But unless you want to risk having your work reverted (and therefore lose
the time spent on it), you should probably discuss changes that might
affect a considerable number of users, are *mechanic* changes, may be
polemic, etc.

Oh, and personally I think it's every gardener's DUTY to make
meaningful *changeset
comments.*

[1]: http://overpass-turbo.eu/s/3eJ

Roland,

> > Please go to taginfo
> https://taginfo.openstreetmap.org/
> choose "highway" there, browse through the values and tell me which of
> the values you would like to change.
>

Post processing that you spoke is about process the bad data into a
readable form after the fact.
It is used when you do not know what state the data is in and fixing the
bad data.
Potentially this could be anything.

Also the data has already been fixed by the mech edits/gardening that has
been done before and is done on a regular basis. I know I have done
residential typos in the past. So many for this example might not occur
still however for post processing you need to consider that they might and
do happen.
In theory if the data is perfect to begin with there is no need for any
post processing.

But searching on taginfo highlight the potential in-correctness of the
data. There are currently 1049 values for highway.
I could reverse your point and say are all of these 1049 values correct?

For example is this correct?

highway = "Bandar Road"

https://taginfo.openstreetmap.org/tags/highway=Bandar%20Road#overview

which is here:
http://www.openstreetmap.org/#map=16/16.5072/80.6299

Now how do we fix that with any form of mechanical editing?

Do I follow all the rules? wait a few weeks for a consensus on the import
mailing list?

Now I could seeing that just fix it to
name = "Bandar Road"
highway = unclassified (I could at aerial imagery and guess the correct
type)

The point of this type of gardening is to fix errors like this and make a
better map. Some people are happy to leave that there until a local mapper
fixes it as it will ruin the local community if I fix. They will be threats
or actual blocks/bans etc if any fixes this that has no local knowledge and
does this in a mechanical way. Even using in conjunction with aerial
imagery may not be ok.

> Couldn't this be even worse than applying those changes directly in
> the database?

>The postprocessing refers to the final data consumer, not the map on
>osm.org. The map on osm.org is specifically designed for giving mappers
>feedback. Therefore, it has no such postprocessing and will never have.

The map at osm.org does have post processing to varying degrees most of it
simple stuff (it is a bridge if it is true, yes or 1) and is a data
consumer just as much as anyone else. Creating maps is probably the
greatest data consumer use of openstreetmap data. The map is designed for
various reasons (and that changes over time) one of them is mappers
feedback.

Post processing is a balance of doing everything and there is an overhead.
Not much ignoring the case of something like that some might remove
whitespace around a tag but beyond that there is very little most of time
the solution is fixing the data.

Thank you for your ongoing discussion.
-------------- Pr�xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20140612/8a1f414b/attachment.html>


More information about the talk mailing list