by the way, all, i think i was mistaken in my claim that potlatch2 would highlight this sort of overlap, haven given meself time to digest the random drivel i wrote.

i likely confused my investigative work on this error with that performed earlier, several months ago, on a different iD irregular infrequent occurrence also revealed by amazon edits, that one actually involving duplicate and overlapping nodes, sometimes up to a dozen in a single location.

if i remember, there was no obvious visual clue for the road overlaps like here, but then, it's been about a couple months since a lightning strike took out my machine capable of invoking p2, and i've been taking me good ol' time bringing a replacement, also a victim of lightning damage about a year earlier, into full service. so i can't fire up the editor to actually see what is visualised for these overlap errors.

i'm pretty sure the visual indication was useful to identify where new additions had been made to one but not both of the segments, with the presence or absence of a distinctive junction node.

apologies if i raised any false hopes.

i should caution that if one does use p2 as you describe, there is an extensive undo stack logic but you can't totally rely on it as it appears to lose track of an initial node that seems to get left behind when deleting a stray way, or at least that's the visual representation. just thought i'd mention that to confirm that no software is perfect. (cobol maybe, let's port iD to cobol)

by the way, in p2, as i've mentioned before, upon selecting a node, it's possible to toggle the different ways sharing the node, if memory serves, with the / key, which comes in handy when multiple polygons like landuses overlap or join linear ways, or a way like a boundary shares nodes with a road.

in the case where a boundary is defined by the road but mapped separately in osm, not sharing nodes, *then* these overlapping nodes get the no-vehicle-sign prominent indication i thought was the case here. but logic tells me that while the way gets cloned and trimmed to v1, there's no reason to clone and overlap the nodes; the error is somehow the original way randomly and infrequently fails to be truncated at the junction with the new way.

i'll take a look to see if there are other non-visual indications of this, but i think as osm delivers the present repaired state of the ways in question, i won't see how it was at that point in time where i suspect the list of component nodes would show extended sharing with the same (and identically-named) way.

anyway i'll let this issue simmer and fester in the back of me brane, as you mention keepright isn't suitable for an immediate review, and i'm pretty sure my tip with p2 was totally wrong and reveals me own idiocy and stupidity rather than shedding useful light, and i should crawl back under my rock and hibernate with the slugs and fungi that are my peers these days, how my foot fits me mouth oh so well.

back to ye ole drawing board

salut, gps-systematic-offset,

thanks for the tip. normally one is never too old to learn something new, but there's always an exception to every rule.

i agree, not detecting these promptly is an issue as errors that take more effort to correct get compunded. in the case of the two ways you listed, the newer one with larger number created at v1 should have been checked for an overlap. it seems to be an infrequent issue, and i can't guess if it averages to once per ten edits, or once per fifty, or what.

if one were using the online web-browser entry to stock iD, i'd suggest that one could, needed pre-conditions permitting, change quickly from iD after saving to, say, potlatch2 by the pulldown menu, which will present a different view of the updated data, and while the overlapping ways themselves will not be obvious (paths and walkways an exception), the presence of overlapping nodes at road bends or intersections, displayed by a distinctive red-bordered white circle akin to traffic sign osm.wiki/File:Zeichen_250_-_Verbot_f%C3%BCr_Fahrzeuge_aller_Art,_StVO_1992.svg

there would be, in case of an overlap, a row of these in place of normal red nodes on the selected way, on one side of the added turn restriction. these also appear in p2 without the need to highlight/select the way.

however, amazon uses a slightly modified iD and without logging the host used to invoke it, i can't be sure but i suspect there's not the same choice of editor offered by the OSM main website, which i've assumed by offering this quick visualisation of the changes.

a frequent turn-restriction iD mapper would soon figure out how frequently this issue occurs, with vigilance to check each edit, until such time as the bug is swatted, and the untouched original way can be manually split before it is further edited and the overlap discarded, or at least checked as i had done for inconsistencies needing further meddling, in case the new way has failed to inherit something from the original.

i need to learn to write better, simpler english

the value (?) of the auto-generated comment is that when looking at the history of the object, one does not need to pull up the changeset proper to know immediately it is a maps.me rubbish edit and very probably rubbish content, as any real castles will have been mapped by a Real Editor, and pretty much all maps.me castles will be bogus personal bookmarks of private residences that have no place in osm.

other bogus maps.me node abuse includes adding highway rest areas for benches, and in latin america i see a lot of waste bins used to mark some type of shop. public shelter nodes are used to mark private residences with comments indicating that the translated-to-english use of shelter is not what osm means. alpine huts are seen in coastal cities.

language translation issues, or icons in maps.me that people like a lot?

adamant, this user has been repeatedly blocked by the DWG and if memory serves the most recent block was a two month duration from which the mapper has promptly emerged continuing to map exactly as told not to in the block message.

a user block is not something that can be ignored, be it a zero-hour one-off, or an extended period of time which this user has, in violation of OSM policy, created multiple sockpuppet accounts in order to work around the block, yet continuing to map without changing their (his) ways, obviously ignoring community feedback channeled via official means.

that's very different from failing to heed changeset notifications, or quietly mending ones ways without openly responding. it's clear from previous sockpuppet comments that this user is uninterested in community feedback and rejects it outright.

even if the mapper ignores these comments, they are open public feedback so the community (around a dozen participants i'm aware of so far) can see them, where private communication has failed for whatever reason.

stevea, i appreciate your beef with Frau Ada Mant, but please formulate it constructively, as i hope i have in case Fr.Mant was unaware of the userblocks, and even if so, that others can be aware of the background, that this is not an isolated case, but a long-running bone of contention.

apologies if your personal mail copies of this get single-character lines, this is an apparent android bug i first saw evidence of maybe 10 to 20 years ago, that appears to be handling user input under memory pressure (blind typeahead) in a way that transposes characters and/or inserts newlines, apparently in part by backspacing to correct errors when bl-lind typing. like i tried but failed to provoke there, damn kezboard, not knowing what i meant to type. there, got that backspace key right and sho' nuff. sorry for the digression)

hi,
can you review your change here which is pointed out by note/2045621 ?
clearly something was added or moved in a place it should not have been.
thanks

a description of what you have done as `many edits' is unhelpful, it's obvious from the list below.

in the list there are multiple items as areas which appear to have incorrect names, that should instead be descriptions.

with grouping so many unrelated objects over such an area into a single changeset, you make it difficult for other mappers to have the motivation i lost to check through the hundreds of listed nodes below for similar questionable items that need further attention.

way/285480554
what is the source of this name, both english and russian? is it posted on the building? why is this edit to a russian object included in a changeset where you have made local changes to a much smaller area in california in previous edits?

way/760393200

again, what is the source of this name which looks to be a description, not a proper name?

if someone has the patience to review the nodes below, more power to you, to find further questionable tagging. my own comments are based solely on the few things to leap out at me and i didn't review anything more in detail. too much to do, too little time

there is a way to restore the node you deleted without resorting to JOSM, and if you wish, i can attempt that as i slowly get my damaged computing hardware rebuilt from other damaged hardware, if all goes well.

or someone else can step up and undo the deletion, as it's trivial to do, also with JOSM

the southern bounday extends out of canada due to reverting bogosity seen in changeset/44569751 located near phoenix arizona that the pokemon mapper did not already purge.

presumably the commonality is being flagged as broken polygons despite the wide area range; i dunno, i could only fix these errors in close proximity

salve, gpserror...

is your detection of these overlaps able to spit out the id of the two (or more) ways of concern?

i know my editor will make them obvious, but due to multiple catastropic equipment failure i'm reduced to viewing osm data on a castrated device where tracking the history of all the created parts, themselves now several revisions later, causes me to lose the will to live as here and your other comment, so i can't spend my two pennies to point at the particular changeset, not that it matters, as these appear without checking to be multiple amazon logistics changes over a short period of time by multiple map editors.

i'll repeat my earlier suggestion to avoid using the editor iD to add or edit relations where there are known issues (turn restrictions here, transport routes elsewhere), or at least these edits should be checked as soon as possible for the random sporadic occurrence of this bug, and mended promptly before later edits amend only one of the two original and newly-created ways and make later repairs much more painful.

or even determining what went pear-shaped and when.

i have seen the osm website github descriptions of iD changes, but in my superficial review nothing has lept out as a fix for this particular issue since these or the original edits six months ago where amazon logistics became involved.

with that, i have no new insight to offer, and i should better spend my time replacing or repairing the lightning-strike-damaged machines. or deciding to take a different direction in life, probably the better option.

i'm seeing drink:beer=yes on other entries in this changeset, which kinda makes me boggle for a traditional pharmacy as i understand it, but a prescription i'll be happy to get refilled. repeatedly. looks similar as typo. doctor, is there nothing i can take, to relieve my bellyache

has been mended, but for protocol, qq-> shortcut for addr: ; hn-> shortcut for housenumber and st street, which shortcuts failed here, described elsewhere

ahoj, amazon mapper...

it would be helpful if in addition to explaining what you have done (which is obvious from below in this simple changeset), you give the reason behind your edit in your changeset description.

i trust this is based on your driver feedback, but in this case this deletion has come under scrutiny in note/2037766 , so an explanation, be it that the aerial imagery referenced above is outdated and no longer reflects ground truth (i haven't checked) - or whatever - would help to clarify matters in this case, or in future deletions where the resources available to you are markedly different from those at hand for a normal mapper or reviewer.

grazie

UNIT_ID as you use it, seems a property of the source data that, much like the TIGER wozzit numbers that get automagically deleted upon editing by most editor utilities, and are stored as subtags of top-level tiger tags. that sentence lost its way mid-stream, if you find it, please send it home.

i feel what you should do is to map these into subtags of the accepted OSM top-level `source' tag as this info is relevant to that and as you note, is useful within OSM for debugging or troubleshooting or version-tracking.

i'm no tagging whiz, having just taken one, but anyway, from what little i've paid attention to, i'd guess there could be something like source:cpad:version=whatever that includes the value presently stored in UNIT_ID and makes it immediately obvious what it is with no need to consult the wiki. tweak the grammar as needed to match OSM conventions, be they version:cpad:source or whatever, i tend to ignore such details while holding on to the general idea. replace `:version' with whatever OSM uses to represent same, `revision' or wossit. leave out the `cpad' if the second-level version-alike tag exists in general, though i've tended to note the source itself becomes a subtag, if i'm not imagining things.

ACRES should also be a subtag under source:cpan or whatever; again as i pay no attention to tagging details, i don't know if something on the order of `checksum' or `uuid' is accepted and in use, and for that matter if in the former case, there are established standards like `crc16', `md5' and so on, and if `uuid' also refers to a specific format. then it will be obvious that this is a property of the imported data, rather than an arbitrary tag, and it will be clear that these tags are useful for OSM data maintenance and coördination with the original source, as opposed to tags only meaningful outside of osm.

feel free to ignore my input as i readily admit to having only a superficial view of what's going on here. thanks.

it is pure SEO map vandalism, and should be reverted back to v8 out of node/62211504/history to restore the now-deleted information.

i would not do any favours for this SEO vandal by correcting their multiple errors, nor allowing their advert copy to remain and threaten OSM's non-commercial not-for-profit status, and i have a personal nuke-on-sight policy for all of the dozens of misplaced SEO markers each day appearing in my little corner of the OSM world.

other mappers may be more forgiving, but these are not beginner errors and these map vandals are unwilling to learn and change their ways, and only degrade the quality and reputation of osm.

um, yes, the DWG is the eartrumpet that needs to be consulted as they are the only osm members with the ability to block a user. (technically there are a handful of admins who can do the same but the DWG is the official path.)

if that is your goal. i know this is a rhetorical question in that your goal is to get these repeated unnecessary redundant additions to cease, with a user block only one means by which this may be achieved as a last resort, and there only the DWG has the ability and power to carry out that means to the end.

and yes, i have seen similar and worse repeatedly posted additions from maps.me, so nothing would surprise me these days.

heiligabendliche grüße

gileri, the three nodes below all have unneeded name:en tags (and in the case of mont blanc, it should be Mount to be actual english) so your removal you mention has not actually happened (or refers to the one single entry that got the unneeded tag after your fix)

your attempt was repaired by Georg, who sent you a form-letter mail describing what you did not quite get right.

further, comparing the map data now, it appears Georg also fixed the imported road to better match reality and put your added address in a probable likely location.

thanks Georg for your improvements, not only here, but also in the thousands of other places; and Bill, do not worry, and do not give up -- it is a simple beginner's mistake from not understanding the details of how everything works, no harm done.

fröhliche Weihnachten wünscht
birra gratis

just wondering why you removed the building=yes tag from way/323906654/history so that this library outline no longer renders, only as an icon. thanks

you have made a lot of errors with this, changing correctly-tagged highways into parks and non-rendering objects. i have not analysed every change and i am no longer able to edit or revert objects, but someone should review these items, as what i am seeing at way/273197845/history#map=18/6.34446/-75.55310&layers=N looks very wrong.

islands can also be a special case, for multiple reasons. there was an area i watched for days or weeks until i forgot about it, in hopes the invisible islands would appear.

some months later i was reminded to revisit that area to see that at last the islands were rendering, with no changes since before i forgot about them. coastlines do not follow the normal update schedule is presumably the reason for that, given i'd ruled out the obvious syntax error that could trap the unwary.