hi amazon,

the driveway re-used the existing road node at the intersection.

the service drive added a new node at the same location, and ignored the existing node.

i will fix this one; just wanted to observe what actually happened before destroying the evidence in my cleanup.

servus geocodec,

actually, i must apologise for not fully understanding when presented below a list of deleted ways, which with a few Stichproben linked to other mappers' contributions.

with a better view of this presented by https://nrenner.github.io/achavi/?changeset=67825548
https://nrenner.github.io/achavi/?changeset=67825548
(argh i hate having a broken mouse and only a tablet touchscreen kezboard)
there was nothing actually deleted without being redrawn, very different from my first impressions and how you used these commentaries to launch an attack on Michael.

this generally goes against the agreed rules to preserve the fact of other mappers' contributions, much like to use a dedicated and identifiable account for imports, that would have kept you out of the predicament of being unable to separate bad imported data or processes from good manual labour.

the important thing is to realise the rules are there for a reason and to respect and follow them as they are not a personal attack, as it seems you feel DWG actions are, but are there for the benefit of other mappers as well in this community.

i cannot see why you would bring this up as this changeset has not been reverted, especially bringing up unprovoked the idea of sabotaging a revert action that anyone can perform.

throwing around these paranoid conspiracy theories has backfired by causing me to assume the worst for this changeset.

still, as others have said, not using a consistent linkable account identity and carrying out edits to thwart edit actions goes very much against the rules, that i have only experienced the worst malicious vandals seeking to break, and this is not the company i wish to see you associated with, having seen the results of other mappers truly turning not just bad, but destructive to the project and community.

i cannot say anything about the reverts performed, but i suspect they are justified placed into proper context, and i would need to be shown a changeset as i do not follow DWG or moderator activity.

however osm is a community and failing to abide by community standards places you at odds with the community in ways that are guaranteed to alienate some, just as i regularly receive criticism for failing to act a certain way, that i am sure some would like to see acted upon and find me blocked from contributing in the future.

but i know i must accept that as part of the condition of being able to participate as i do trying to clean up damage, and to live within the rules and respect others and their contributions.

my search results (and lack thereof) leads me to believe that these are the sorts of entries that have no place in osm, a serious database of verifiable facts and not a source for gamers and fiction.

yep, this changeset is the second of the earlier linked trio around red bluff. the vertical line only has node 970, while the horizontal pairs it with 968, while 969 is located somewhere else entirely.

in some edits i fix, i see four or more nodes piled up, so i wonder if they were meant to appear elsewhere, as i try to understand the amazon edits and place blame.

thanks

the osm inspector actually does, and if you look to https://tools.geofabrik.de/osmi/?view=geometry&lon=-122.33028&lat=40.25228&zoom=10&baselayer=PublicTransport&opacity=0.69&overlays=self_intersection_ways,self_intersection_points,single_node_in_way,duplicate_node_in_way for about the next three hours, you'll see one i just checked to see you acted on it, plus others linking to your edits in that area.

thanks for fixing the one.

i expect meadows to be green year round. although admittedly some were starting to resemble the mapnik scrub after four months without rain last summer. what the background imageries here reminded me of was something else not pleasant to plop down on during a hot summer day and sink into a bed of luscious wildflowers. but it may be a cultural difference.

there is another changeset i've not commented on where it seems iD is in fact detecting and warning of things but they get uploaded anyway.

i've become sensitised to this as amazon is now uploading things in a massive way including the errors i see you upload, and as i largely see corp-speak feedback, i thought i'd try for feedback from a long-term user who also solves problems.

i'm working on cleaning up cali as much as possible while me equipment rapidly collapses around me, in part so the new amazon errors will not remain hidden, while the day i reported issues to them i had just seen several dozen if not hundreds of new errors appear in the past day or two, before detecting a pattern.

anyway, i suspect those other parts of the country have janitors locally, or regionally but who throw in the towel when encountering the wall of errors and creative mapping behind them. georgia seems to have a user who prefers to damage imported bogosity rather than deleting or repairing. and of course imports often don't meet osm traditions so i ignore certain errors to get others fixed country- or continent-wide, venturing into neglected canada while awaiting the conspiratorial-firm geofabrik update to process.

anyway, i'll point out the other changesets as you have a cluster of errors in one cali area i've left to point out, and as i analyse what some amazon mappers are adding it seems liike iD haaaaas to be at fault unlike me here, something potlatch won't even let me do.

you are really digging yourself into a hole.

anyone can repair things and is encouraged to do so particularly when proper procedures are ignored.

and now you are justifying deleting the contributions made by others based on the misled assumption that by making a revert non-trivial, it is not possible?

i have a surprise for you, it happens regularly despite what happens in attempts to hinder it.

it seems you are quite happy to sabotage osm and damage the work of others in order to advance your own agenda which in the past weeks of activity has had me increasingly and now completely baffled.

the phrases meltdown and high-speed-car-crash-in-slow-motion are the best i can describe things as an outsider, undercover operative taking orders from F¡гма Ģеоfаbrıĸ.

if you follow the start/end nodes of the way that got split, eventually you will reach the original with 29 revisions and 686 pages in my lynx browser found at way/665480754/history . six months ago.

hallo nochmal,
just a generic US mapping TIGER road import suggestion, if your amazon mission is to improve the map by removing misleading information as well as adding missing service drives and private driveways,

if you view the added driveway here at way/706642127 , you may notice that not far from the added orange way, (to which my attention was drawn by a trivial OSMI-flagged error i apparently did not fix) there is another crude private drive just southwest.

in the editing when selecting and aligning the most suitable imagery, it may be worthwhile to throw an eye on nearby features.

i am willing to bet my last quatloo that the existing nearby drive, a TIGER import, was meant to be the drive you added, as if you pull up any imagery, particularly the oldest archival clarity about a decade old, there is no candidate for such a driveway other than what you added.

if you look at the driveway unmapped by you but imported nearby from TIGER to the east of this addition, you will again see it is close enough to be re-used, but not accurate for osm standards of today.

you are more than welcome to re-use and fix a nearby wrong drive; then again it may be easier to delete the imported driveway and draw it afresh.

in any case, if you see obvious errors nearby, like these misplaced driveways, do not hesitate to fix them in any way, if it does not detract from you map goals.

there are so many errors similar to seen here that the more eyes finding them and doing something, may reduce the estimated time to tackle them, by several decades calendar time.

all other TIGER-tackling mappers will be grateful, i assure you.

you team is of course under no obligation to care about nearby errors on the map, other than they detract from your additions.

thanks

got a duplicate node here at or on node/6634705965 and i didn't expect pothead to do *that* just now like that.

i also see the close nodes warning above, that this presumably is.

jus' sayin', that's all

moin adam,
i see this meadow (meadow? he asks from the alps) is flagged as self-intersecting by osmi, and i also see crossing ways warnings above.

as i step through suspicious nodes, i discover node/6598905370 at v3 is twice a member of way/702693989 , maybe 2/3 down the list.

it only appears once in the two fences shared even if one has a funny hook.

would you want to look at this? i've been fixing my share of this overnight and feel as someone who uses iD you can better figure how it comes up with this, or other issues that seem to plague cali.

thanx

the user-facing iD version was just bumped to ...4 sometime yesterday by a merge made later than this edit as ...3 can be seen above. toryism should no longer appear now, although one probably needs to test tag a political party office to verify. or something

hello amazon team, me again.

wanted to point out self-intersecting loop at way/707200584 which i hope i remember to fix and save before you see this.

this is three days old, at least half as old as when i mentioned this not-infrequent issue.

also, while i just said i would probably not report duplicate nodes in ways again, there seem to be maybe a dozen nearby in this part of texas, the first i viewed also an amazon edit. unsure if i will quietly fix them, or work 3lsewhere and hope someone else bags 'em, or quickly view them for analysis.

one more, amazon team, then i will probably leave any more of this common type this morning unreported.

single overlapping node in way/705940962 at an intersection, i have merged it. also an older edit.

hello amazon team,

this is an older and larger edit, but i have now repaired a zero-length segment where one way joined another, of which this extra node was not a member.

i also tidied up way/705961735 as it did not look right to me, even if not pointed out by the osm inspector, and it was overlapping the other way i repaired.

just for your info.

hello again amazon team,

this an older edit, but just wanted to report you added three co-located nodes atop an intersection the east end of way/705988003 .

i will merge these, but it is a strange thing to see, and now i am both reporting and repairing, to get an idea of how much of an issue it is.

thanks

hello again, amazon team.

here you have added a service drive way/707590092 in the form of a knot or necktie, two days ago, about a week after i reported this common error.

the other part of the drive is correctly disconnected.

i just thought i would mention this before repairing, so you will need maybe the osm deep history inspector to learn how it was originally uploaded.

thanks

wait, this is a newer iD version, but it does not show the self-intersection in the listing above...

i am horribly confused.

can you look at way/17194553 ?

it seems some nodes got dragged, and even where it looks reasonable, i cannot see the background imagery quite agreeing with what is on the map.

thanks

hello again amazon team - i am almost starting to recognise your mappers by how they work without any username additions...

i just wrote in another comment, changeset/72605960 , how that was the first flagged amazon edit i saw this morning - here is another similar case of co-located nodes in way/706892706 where the path loops over two co-located nodes, but here at the end there are somehow four(!) nodes atop each other.

it would interest me to know how this is happening, as i have seen other osm mappers adding duplicate nodes regularly, and if it is worthy to try to avoid this from the editor side, or what is the use case for these.

thanks

hi,
can i ask you and your team to check what in your workflow or toolchain might be causing regular errors on occasion like the two pointed out here by the osm inspector?

it seems this is a result of your iD editor being willing to create duplicate co-located nodes, maybe as a result of a dirty mouse double-click, as i see this often from both iD and josm edits.

way/706998968 shows the sequence, node node/6643918786 is included twice (the self-intersection) surrounding co-located node node/6643918785 .

i can trivially repair this in potlatch which makes it very visible, and analyse it by stepping node by node, but as i am seemingly unable to create overlapping nodes in potlatch and amazon (i have not verified) is using its custom fork, if it is felt worth it, code to prevent the most common errors with the simple edits i have seen so far, could be added, or cherry-picked from later releases.

if all your edits are limited to adding simple missing service drives then josm is almost certainly overkill. i will not advocate potlatch even though it has another advantage in not re-using changeset comments that i have also seen, and i have not tried to see how trivial creating self-intersecting ways might be, as in testing i never could easily reproduce the errors i wanted to understand how to repair.

with that, this is the first amazon edit i see out of a limited number, but i am examining more closely to understand how errors from anyone can make it on the map.

i am leaving this untouched to show what is wrong without having to go into the item history after i merge the co-located nodes.