This changeset has been reverted fully or in part by changeset/73254561 where the changeset comment is: revert gibberish changeset

node/6438563532/history
weirdest atlanta i've ever seen, except for all the other spams.
i'm nuking it so you'll have to use other tools to see where it was.

hi ian,
noticed you changed this poi and in the process, removed the phone number.

i was wondering if you intended to update the number but forgot, or if you meant to delete it entirely but it did not go quite right.

as i've never heard of poism, i won't glare in that direction as possibly to blame. yet.

thankx

hi,

don't know exactly what the iD warnings above refer to, but there are some eight intersections with co-located nodes problems i can see when editing zoomed out from node/6684422585 .

this i analysed to find has no connection with the other way meeting at this point.
i have not analysed the nearby ones but they look suspiciously similar and too regular. and there are too many of them for me poor brane here. maps is hard, let's go shopping.

you look to be a new editor here so ignore what i say as this bug documentation is meant for the bug detectives, not you, sorry

no, no, and yes, as proven by woodwosewulf's question referring to the actual location, and your reply referring to google and their unique style.

osm may not copy from google, this means their data, their toolchain, and their presentation.

that they deliberately distort their data for the driver is well-known when one sees the multitude of SEO spams geocoded to the street improperly added to osm before 5359 identifies and purges them.

osm does not do this as it is to be an accurate and unbiased representation of the world, so instead of placing a ``pin'' at some location which i would consider copying google's style (osm cannot copy from google maps in any way, including geocoding), the osm mapper will draw an area at the correct location, which is obviously not a car park, based on personal knowledge or with the aid of the aerial imagery woodwosewulf has consulted.

the car park is already tagged, although not mapped yet as an area. it has no reason to be tagged as a park. nor does osm cater for end-customers who prefer that style, which i consider the intellectual property of google if not a trademark commercial selling point.

if the data you add comes from personal knowledge, then great, but it should be added according to osm standards, and not to match a so-called competitor (as osm is not a commercial entity), as even by mentioning the use of google maps, you open osm to unwanted accusations, and raise the suspicion this is another case of plagiarism that recur regularly and require repeated administrative action to purge any mention from the database.

one of the above warnings i fixed was for two overlapping nodes, one part of a, one part of b, no additional dupes there, yet it should have been created as an intersection (usually at such a branch i find a co-located iD intersection with an isolated dupe. mentioning this variant, as i see this is a pre-release iD and i fixed two logic errors with overlapping nodes in a fairly small area. commented by changeset/73238991

hi,
what have you tried to do here? in the area of way/678039307 you have created an elongated bench, some untagged ways i cannot figure out, near a bench that esri imagery shows is near the road centreline.

i haven't looked further to see what else might be absurd, but i've seen quite a few very strange go map!! edits, and i don't know if you meant well, or if i should just clean up.

thanks

so you have copied this mislocated info and mislocation from google?

i would suggest it is mixed use, as the aerial imagery clearly shows it is a mix of hangars and private residences sharing the infrastructure to the airstrip.

also that before this edit it was tagged residential

and i'm glad to see the thailand history behind facebook's use has made its way into the tagging mailing list discussion, so that i do not need to mis-remember it, or vainly seek to find it for some context.

i'm done here :-)

...but what about us group of Disorganised Mappers LLC who can't even figure out which side of bed to get out of before taking orders from our overlords on how to systematically sabotage The Mapp. i demand equal representation. signed, The Cabal [TINC]

hallo joseph,

> I noticed that you added the tag "import=yes" to many roads. This tag should only be used as a changeset tag when you import data from an outside source, like another database.

you do realise whom you are addressing here? i hope...

blast, clicked the entirely wrong button bringing up editor Potlatch1, but i can see your repair of the multiple nodes here was, in contrast to an earlier comment i made today, totally effective.

as an aside, what you refer to as an older version of OSM is more correctly described as an earlier version of the iD editor, customised for amazon logistics. but i understand your intent, and it appears to be just as dupe-node buggy as the later version (... .3, OSM-facing is at least .4 now) with which amazon has replaced it.

the .4 version still has this bug as i see from non-amazon edits.

urgh, i should have verified this earlier, but when i invoke Potlatch2 deliberately here, at osm.org/edit?editor=potlatch2&way=707194420#map=17/38.77517/-121.19255 , i see from the red-white no-vehicle-traffic-sign-alike there are still overlapping nodes, so either your repair just merged a pair rather than all, or you need to step through the nodes and manually delete the others.

i have noted in Potlatch2 i have needed to repeat the `j'oin merge keystroke in probably similar cases, before i started stepping by node for a deeper analysis, as well in preserving the tagging from one particular node that otherwise might be lost, like a turning circle.

sorry for the bad news :-)

mojn ganesh,

i would suggest with the frequency of this bug, you open an issue at the github iD editor repository:
https://github.com/openstreetmap/iD/issues
thereby selling your soul or at least personal details to what is now microsoft.

i checked the first two pages but with 441 open issues, i did not feel like seeing if it has been reported already months ago.

i presume the iD developers are unofficially aware of this issue, as i'm sure were i again to suggest switching to JOSM (or even Potlatch2 for the sorts of edits i see your team appearing on OSMI) their kibo-detection algorithm would result in a repeat of an earlier changeset comment followup that gets nowhere.

my sympathies do go out to the iD developers as i cannot see this error being reproducible, nor consistent, and these edge cases with not two but five overlapping nodes, that i flag when i find them, do not seem logical.

in any case, official notice will be a start, and i will continue to comment in changesets on unusual cases or patterns i discover.

hi ganesh,

please go easy on your (presumably) human editors. within reason, of course.

this is an analysis of a tool iD editor bug that can happen, and does, to all users of iD. i quietly fix non-amazon edits, and now trivial amazon edits, sometimes with commentary like in canada where the last-added node in a rectangle was duplicated, as that statistical irregularity was notable.\

maybe this info can help iD followers to locate and fix this unfortunate bug.

here is similar; i'm sure your ever-suffering mapper meant the best, but was thwarted by this bug in the iD editor, which results i've found on my OSMI radar.

if it makes all of you iD users feel better, while attempting to repair damage in one area, my chosen potlatch editor introduced the errors i discovered of turning a repaired service drive into a motorway link (a buggy shortcut), and adding adopted TIGER road tags to non-tiger private driveways i re-tagged. the latter an operator not-paying-attention error in simplified display mode, where my mistake was later obvious in detail advanced mode.

oh how i wish i had a functioning kezboard and mouse when making those edits, not only to speed up my edits by estimated ten times.

if your errors are reported by iD on upload, good, but i've read from another user of no notice of errors i find later, so i don't know what to believe.

thanks, and given the volume of amazon logistics edits, good to see your responsiveness to feedback.

YES!!1!

i am so glad you replaced the hiking paths i deleted around the water tower, with the fence i deduced from the archive old-bing clarity imagery must be present, and seemed likely.

good work.

hi trav,

thanks for continuing the cleanup here, as well as your changeset comments re paths v. footways. and anything else you might have done i've not discovered yet.

jumping in here, do not forget the importance that a posted sign or entrance has for a non-native speaker seeking emergency services.

even if the sign for the police is as simple as Polizei or Gendarmerie, this may not be immediately obvious for a tourist whose maps.me presents the logo in a completely different script.

i have always tagged my quick surveys of chemists with name Lekarna as that is only what is on the sign, even if with the right language settings it's obvious - in countries where that was all that was obviously visible in a quick ride-by. i see the same with the cyrillic corresponding to Apteka, frequently mapped.

if nothing else, in an emergency where one is led to a closed entrance, how can one tell which of several possibilities is the correct one without something like a hint Lekarna Pivo (of which i've provided only the first half) is more likely than a dozen personal names that to an outsider are all gibberish?

so i am all in favour that any posted signage be a candidate for the name field, no matter how how apparently redundant natives find it - particularly for police and pharmacies/Apotheken (that usually have distinctive non-generic names in your country) or other vitally important services.

Probably omitting Kriegerdenkmal, but i've tagged plenty as such and it's a different discussion.

'tschuldigung...

nice changeset. i'm glad you were able to correct/augment the driveways i was unclear about, due to my chosen imagery at the time, as actual driveways and not business/gummint service drives in this area.

one thing i noticed where i had not corrected your mis-tagged additions, is that it appears esri/maxar aerials are most recent, where i saw a mis-mapped car park that matched bing, but not the newly laid tarmac of the others.

of course the decade-old esri clarity archive is also different, but best for drawing and aligning unchanged features in this area where mapbox fails to deliver the sharp images i expect to find.

good work.