i count eight objects below.

which is weird in that in another changeset with numerous deletions, nothing appears at the start of the list.

in achavi, though, i see seven in the two areas deletions are obvious.

got it, that last bit is an outer part to one of the other two.

yep, that's a centre turn lane for most of its length. and some of those turns it allows are not mapped from both directions.

and yes, the route relation is buggy.

by the way, i couldn't remember if the 5-year-old your village maps overlap of way/282842300/history was mentioned - it was, so now you have two pairs of items here to use the josm `replace geometry' feature on.

i'm guessing the other changesets i recall seeing mention of a few deletions would be candidates for a p1 act of vandalism as well (it's all i know).

that sounds like overkill for just one deletion, way/501526036/history .

if it's not too messy i'd poke around with potlatch1; if it looks too much work it's about time i write a wrapper around the undelete and related scripts.

oh, that was too easy with the size of this changeset. coming your way, an almost co-located paragon apartments

(blast. try again...)

hoi jess,

if you didn't know you can also create a simple polygon in p2 from a node, keeping its history and transferring the tags. i forget which meta-key it is - shift? - and drag the node near the desired outline. my tablet soft-kezboard keeps that modifier to itself.

i've used it often for graveyards imported as nodes and no doubt other things. the corners or outline needs tweaking, of course, and for a polygon like this it would be ugly, although i think with shift one can redraw a rough polygon (certainly a lake) at nearly the speed of drawing afresh.

this could be mis-remembering through rose-coloured spectacles, bloodshot eyeballs, or high-diopter beer-googles.

just in case this might be useful for future node->polygon conversions. che*HIC*ers

hallo amazon (i'm sure without checking) iD editor user,

something has gone very wrong with this changeset.

if you look below, you have updated the original version of oregon pike with a lower way number to revision 12.

just below that is v1 of a new oregon pike, which apparently is the result of an intended split of the original. or maybe you did not intend to split the road at all.

but weirdly from the upper end of the v1 version, there was no split of the original, and the new one has been joined to the old at every original node.

you have then been adding service drives which some get attached to only one of the ways.

this is a bug i've never known iD to create yet, but i'd seriously suggest some team leader take a look at josm as from changeset comments, i see your editors are being called out for errors at a much higher rate than i would expect, and you have been moving into relations that georg (5359) has pointed out as problematic, where iD is widely known to have weaknesses.

i am going to try to use potlatch2 to repair as much of this as i can, because another mapper failed to get anywhere with iD. that mapper has pointed out other relation issues that i am likely to break further as i eliminate the duplicate bit by bit.

i'll try to analyse each new junction as well.

it's an automated edit that is prefixing colour codes with an octothorpe.

however like many such simplistic automated edits, it's not well thought out and the one example i grabbed, way/604112653 , shows a 50% success rate and 50% failure in detecting each instance of colour.

i've probably botched the link here but the thread starting with https://lists.openstreetmap.org/pipermail/talk/2019-September/083236.html . 13 entries.

i can see from viewing this changeset at https://nrenner.github.io/achavi/?changeset=74171182 these are clearly not continuous topo lines. i can also see from the changeset details they are a mixture of 10'000 node deletion, and here many lines without the nodes, as divided up by josm, so i am unsure if revert ordering will matter with my commandline tools, that took all day and night yesterday to revert a country-wide mechanical edit retagging FIXMEs.

(this isn't wanting to post. try again)

the so-called california snark was an honest comment that while i see you are active all over, i would expect that if you have opted into notifications somehow, i would expect it to be geographically limited to your area of greatest interest, as the feeds i am aware of provided by osm cover a fairly limited area. so that to get full coverage of the us of a you would need to divide into multiple squares. which if you did so, you would be seeing a lot more revert activity over the years that i encounter.

but then i have never ever received notification from osm (just the occasional heads-up via the message system) that anyone has edited an item i have worked on, despite knowing many thousands have been touched.

the edit wars do not refer to your activity, but to outsiders, the worst case i know being a particularly persistent vandal in rochester michigan who may have finally given up after a live three-pronged defence with immediate reversions. some pokemon vandals fall into this category before they give up. further edit wars appear to take place in disputed areas. in any case the version numbers often rapidly increment into the dozens to hundreds with no action on your behalf.

i am not going to speculate why you take offence other than to state it is irrelevant to this revert, except where the user already made a second pass over an area despite being asked by the DWG to stop the retagging several days before.

i understand fully well what my tools do. they connect to the api server, download info about the changeset, then for each item, perform a GET to get the necessary data to either determine whether the item has since been modified, or to increment the version with a PUT with an earlier data status. it then sends a comment to document what has been done (also helping with recordkeeping for widespread cases like the driveway deletion carried out in small steps where i missed one) and closes the changeset.

it sends no mails. it makes no other api calls related to messaging, if that is possible. it is just like any other edit whether carried out by josm, or iD proxy automated validator retagging edits.

i get it, there is something notifying you of every change made to any object you touch, and apparently the retagging to kick this all off didn't bother you despite happening just as many or more times, and i take it you would have the same objection if the DWG had stepped in in my stead and used the very same tools to perform the same reverts, again touching items you have modified.

you can if you like choose to tag things with the lowercase fixme it seems some want to force on all mappers but as a non-data tag meant for human mappers, i have chosen to respect the choice of the original mapper to use a tag that sticks out prominently in multiple ways.

i take responsibility for what my changesets do to the map data. but i cannot take responsibility for unintended consequences if someone has wired themselves up to be notified for every item i upload, for that would be absurd, yet still possible to do with minutely updates.

ohhh-kay...

this changeset reverted a changeset that touched nearly a hundred items. i would not be reviewing every item. one changeset covered around 5'000 items, maybe part of california heavily mapped where users aren't afraid to voice uncertainties.

i take it you somehow get a notification if you are in the edit history for everything someone edits? wow. i did not know that was possible, and i certainly would not want that for all the items i've seen you edit, what with prolonged edit wars and the number of items that aren't at v1.

your FIXMEs were not bot-changed, but by a user who has failed to reply to any changeset comments (a DWG block could be needed) and seems to be running mostly mechanical edits, some aplying iD presets or controversial retagging, which is frowned on by the osm community i know.

a bot would be something like wall-e or xybot, well documented and mostly accepted by the community. i do not run such a bot. i use scripts that act on manually selected edits, whether vandalism, changes-gone-bad, or in this case an unapproved and undiscussed mechanical edit.

like i say, i've no idea how or why you get a notification, but i'd think there should be the possibility to not get a trigger when osmtools makes an edit. the bot label you see is a bit iffy to go by as i've seen bad edits use it where you *should* want to see what is up, while trusting those who run osmtools to be doing undeletions or reverts to a previous edit state, or other DWG-type edits that look to be all it can do when in capable hands.

but without knowing how the notifications originate, i can't suggest a way to implement that exclusion (or if it's desirable. i've only randomly seen my work appear like too often in this retagging, where in the changeset discussions seen at https://resultmaps.neis-one.org/osm-discussion-comments?uid=905716 - 52 of them so far, 62 comments, not a single reply or change of behaviour - , i hope it won't have to continue to go up by much). that was the only way i was aware of to learn of my reverts without searching them out.

This changeset has been reverted fully or in part by changeset/74554216 where the changeset comment is: revert undiscussed automated retagging of objects where i have presented reasons to keep existing tagging

i'm not sure where the place=suburb comes in, because all i am doing is reverting an ongoing country-wide undiscussed mechanical edit that multiple users have taken issue with and the DWG has weighed in on. mechanical edits such as this that are affecting multiple tens of thousands of mapper contributions.

i'm not sure either how this would be triggering any sort of alarms, but the edits in the first place should have triggered just as many alarms unless you've done something out of the ordinary.

if the original mechanical retagging had been acted upon sooner then there would have been fewer changesets, but i have seen no discussion of this on the tagging mailing list, talk-us as it appears to be country-wide aiming at 100% coverage, or even in the general talk mailing list where a similar revert of a mechanical edit in saxon switzerland has been discussed but not acted upon yet.

are you getting notifications for the edits carried out like
relation/9266256 last edited as v2; restoring previous version 1 by 'stevea'
? that shouldn't be the case as v3 bears my username and v2 bears the other user's,

and how is a changeset in hawaii setting off alarms for you? california i maybe could see.

anyway, the earlier mechanical edits mixed together several uncontroversial edits with other controversial ones. which still should be documented and discussed, but without a clean separation they are not so easy.

This changeset has been reverted fully or in part by changeset/74554048 where the changeset comment is: revert undiscussed automated retagging of objects where i have presented reasons to keep existing tagging

This changeset has been reverted fully or in part by changeset/74553750 where the changeset comment is: revert undiscussed automated retagging of objects where i have presented reasons to keep existing tagging

This changeset has been reverted fully or in part by changeset/74553672 where the changeset comment is: revert undiscussed automated retagging of objects where i have presented reasons to keep existing tagging

and more to the point, with the fairly extensive discussion on the talk mailing list that i felt concluded the unique cliff features were accurate, is the plan to restore the deleted data by reverting this changeset and the others? still working on a country-wide retagging with many dozens of thousands of items that is taking quite a while to revert...

This changeset has been reverted fully or in part by changeset/74553421 where the changeset comment is: revert undiscussed automated retagging of objects where i have presented reasons to keep existing tagging

This changeset has been reverted fully or in part by changeset/74553367 where the changeset comment is: revert undiscussed automated retagging of objects where i have presented reasons to keep existing tagging

This changeset has been reverted fully or in part by changeset/74553171 where the changeset comment is: revert undiscussed automated retagging of objects where i have presented reasons to keep existing tagging

this is another large and pointless change from FIXME to fixme from what i have seen so far, while other equally generic descriptions include FIXME changes with other automated iD retagging carried out over a large area.

feels like a candidate for a revert.