This changeset has been reverted fully or in part by changeset/72980546 where the changeset comment is: these are not paths, these are clearly roads and were correctly mapped earlier.

This changeset has been reverted fully or in part by changeset/72980515 where the changeset comment is: these are not paths, these are clearly roads and were correctly mapped earlier.

hello amazon,

please check the driveway loop here. the terminating way node is located on but not joined to the other part of the loop, where stepping along the nodes skips over this point.

this is flagged as a self-intersecting way.

this is interesting that the newly-added drive itself has no co-located nodes, but ridge park drive now has five overlapping nodes at the junction. my head hurts.

this is interesting in that along this loop, there have been placed five! nodes in the same location, ...519 down to ...514, with 515 the odd one out in that it is a nearby gate. i'm leaving this one alone for analysis, it's pretty unique.

this is not a meaningful description. in fact, looking at your edit history for the past days, there are very few edits where your descriptions appear to be sensible.

your changeset description should summarise what you are doing, in order to aid in troubleshooting whether error seen are a result of operator error, or in this case an editor bug.

`dgh' is not useful to anybody.

this amazon logistics edit was interesting that where i merged the overlapping nodes, three ways met, but only in a way that you could get from the first to the second, or from the second to the third, but not directly from the first to the third.

if that makes any sense. it's now fixed so one node is shared by the three ways.

adam, i did not even notice that this was your 11'999th edit until just now.

but to add a further observation, from an amazon edit from nothingness i just mended, user drew a-b-c-d, then went back to branch from c. duplicate node e, co-locaated with c, was uploaded. in the order of the first way, it was inserted a-b-e-c-d, e beiing the intersection, c unattached to branch e-f-...

note that it seems iD, presumably like potlatch that uses internal negative numbering in order of work, uploads the nodes in sequence so the osm-assigned numbers they receive correspond to the order they were created. it seems not to be true for JOSM uploads with dupe nodes, where stepping node-by-node along a way (can you do that in iD? seems not available in Potlatch1) shows numbers all over the place.

whether this ordering info helps to track down the bug is anyone's guess, but i felt it important to document this, meaningful or not.

hi ganesh,

this seems to be some obscure logic bug in iD, infrequent, and not a mapper issue. i do not know if iD highlights overlapping nodes in an obvious way as Potlatch2, or the throbbing pulsating angry red pustule of potlatch1.

in any case, as i repair more, including some non-amazon edits intermixed in texas, trying to find a pattern, i will update my comments in my conversation with user adamant about this minor issue.

i trust you are familiar with the OSM inspector, by which i am made aware of this and other issues, which can point to a particular pattern?

please use sensible changeset comments to explain your intentions, not this gibberish.

i have fixed the duplicate nodes added here, but you may wish to review way/707197542 which is drawn as a loop implying no connectivity to the service drive to its west, which mapbox imagery does not support.

thanks

the way added by this changeset was unusual in that over its short length it had no less than three co-located pairs of nodes.

has been fixed. i did not touch the nearby bogus TIGER imports.

blast. my previous firefox session wherein i had links to the erroneous fence is gone, so i can't link directly to demonstrate my observations.

i've seen it enough to suspect a pattern.

amazon is not using what i consider a fork the way dragonflyBSD is a fork from freeLSD, but what i am guessing is a snapshot, earlier of .12, now of the iD .3 with the torism bug, as of last week. this is a guess based on outside observations of what i suspect in the us would be considered trade secrects or proprietary info.

as far as what is added, changed or removed, my guess it is minimal and likely not kept too up-to-date, but that is only a gut theory with nothing to back it up. i don't follow iD development to know if amazon developers exist there to send things upstream. my outside view of amazon differs slightly from my understanding of the intel/linux-kernel in terms of resources at the least.

but that isn't important as the errors i find do not seem to be limited to one fork, but apparently a general iD issue.

interesting you say you don't get the warnings mentioned above, when others take them as gospel and blindly mis-correct non-errors. in any case, based on iD-only edits and guessing at its internal workings, it seems to emerge after correcting several instances overnight what occasionally happens is

user draws a-b-c-d-e
although the osm node numbers assigned to your tee are out-of-order so maybe you started from one end, then continued from the other end to meet in the middle. the sequential series is what i observe from amazon in almost all cases i analyse.

if a way is branched between two nodes, no problem. here you choose point, say b, to branch from. same also seen when branching from pre-existing non-iD nodes.

you drew from b to f and maybe beyond. or you thought you did.

on upload, instead of a b to f link, iD creates a new node co-located with b, now f in sequence, adds that to abcde as afbcde or abfcde, i have not noted.

then from f branches to g and beyond, not touching the pre-existing b.

as b and f are co-located, i consider this bug to originated within iD, and nothing to do with your mapping habits.

it is also not consistent or the map would be flooded with these daily. it only hits you as an extensive iD user a few times per month.

that amazon is probably contributing (without immediately identifying info as i continue to mention repeatedly) with this type of addition on a scale several times that of other iD users means this presumably obscure bug has surfaced more often.

same with duped nodes in a way, when positions 12345 are mapped by nodes abcdefgh in order 1233345 (i think imissed one) or abcdcef.

since it is infrequent, i guess i can't ask anything more of you or anyone,, but should i point out future errors to you, or quietly fix them as EWONTFIX return codes from iD?

yes, i am cynical.

howdy,
can i ask you to have a look at node/6168474777 and its immediate environs?

looks like as you rounded this 'about, this node was pulled from its intended position and re-joined to loop on itself.

i tested reverting just this node but it does not fit with the rest of your changes.

thanks

i believe what georg is asking, is that some hours after you added your address, he added some missing streets and buildings, and can you check if the address matches and should be moved to the building.

also, if the streets are named, can you help to add their names, particularly the name from your address, it would be great, thanks

hi again,

this is a very strange edit, so i am leaving it as-is for analysis.

i did not expect to find six nodes co-located on the highway. usually now i expect to see iD is reluctant to re-use an existing node when branching, on occasion.

these are the first five listed below until the gate. how they ended up at the start of drawing at the highway, together with the lowest number comprising the way, is not something i can guess at, and it is hard to imagine it could be operator error to be so precise and persistent.

hi amazon team (i am guessing)

there are two issues with the edit here yesterday to add this drive. one is the known apparent iD problem where two nodes are added at three slots in one place. that has happened here and is probably not worth worrying about as a possible show-stopper.

the other appears to be operator error, where at the end of the drawn loop, there was added a cluster of nodes very close to the start of the loop. but as far as i can see,none of these actually terminate the loop in other than a dead end.

i see now you are using a later version of iD so you can still create torism campites if you branch out, but this one gives you warnings i can see above about possible errors.

the close_nodes i assume refer to the co-located nodes in the way, and the almost-junction to the cluster very near node ...9697 leading in from the highway.

if you are now checking for errors with this later release, then i am glad as this is the first amazon edit made since the weekend that has been detected by OSMI i have found, and i have mended most but not all older edits overnight.

re-visiting, i note now the pair of nodes at one intermediate location is included over three slots describing the way. (out of the ascending order one expects to see as assigned by the osm servers)

this is, as i now expect, flagged for this reason as a self-intersecting part of the way.

i should note that of the commonest self-intersections i repair, none have been added by your team. but now i am beginning to suspect an issue within iD, but i need to see more examples to confirm a possible pattern.

if anyone is keeping track, there were three co-located nodes, resulting in OSMI not only warning of the nodes, but also flagging the way as self-intersecting. which otherwise it was not.

one node was tagged turning circle which i managed to preserve; the other two not.

this has been fixed in my cleanup.