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.

it would be good to be able to map as a bench, something more than the roughly-two-metre linear feature implied by the point node, and which the higher-zoom osm-carto tiles reproduce as rough points, here not reflecting the actual orientation at all.

for example, i saw that a significant section of a wall near me had been given the bench treatment, not only as isolated individual benches, but a continuous 20-ish metre section of seating. that is worthy of mapping as a linear way, although how to render it accurately is another matter.

another use case i've seen is a continuous way encircling a tree, or around a fountain or whatever. this too could be represented accurately by a closed linear way; again at present osm-carto has no way to indicate seating is available along the entire mapped way, associating a line to an icon.

i don't know if anyone has reached the point of micro-mapping an individual bench as a closed polygon area some 40cm by 2m whose entire surface is the bench. i'd hope not, or at least with area=yes, to differentiate from a ring where one can sit and rest, but not inside the border, there being a tree trunk, or fountain, or statue, or whatever.

an area significantly larger than a metre in front-to-back depth i would hesitate to call a simple bench, as with these dimensions it seems more suited to stretching out horizontally, unless built up akin to bleachers for sports audiences.

but i'm just stating the obvious, as it seems a renderer issue of how to display such a linear feature. like polarbear said.

Welcome to osm, Virginal Mapper!!! we are always in need of fresh blood, and you will fit the bill nicely!!@ this is your first edit, so ... how can we stop asking you about your lack of meaningful changeset comments when you haven't even failed to make any yet?

do you possess any useful skills like seeing into the future to know what is going to happen? if so we have a great job opening as Clairvoyant Mapper to push out updates to the map before any of the competition (There Is No Competition, TINC) and keep osm the best in its class of free and open data maps with the words open, map, and street in the name.

this appears to me to be the third soxkpuppet (i'll leave that typo for now, thankyouverymuch) account of a particular user who has received several dwg blocks for identical reasons as this account, said account created about the same time (i can't see the actual date a block was issued now) as the most recent still-active block to be placed on these user accounts.

without actually analysing the content of the changesets, i want to repeat that osm is a collaborative project, and that repeatedly thumbing your nose at co-conspirators by using meaningless and pointless changeset comments does nothing to endear them to the quirks of your mapping habits, whether well-meant or not.

(i sez to meself, ``Self, look in mirror before You cast the first stone from within the safe confines of Your hermetically sealed ivory glass tower''. QED.)