Ops, mandei pra lista errada, foi mal haha
2014-06-12 9:21 GMT-03:00 John Packer <john.pack...@gmail.com>: > 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
