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.
_______________________________________________ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br