+100 for opening hours. it's been an eternity since i've seen a bancomat that is only available when the bank is open, as the banks cut back on their hours to save money.

further, with, say, a wall of bancomats within a bank building, there may be separate functions that have been proposed for tagging. one may accept payments in, another may give the full range of Euro notes from 5 to 500 (minus the 200) at the time I saw it, another may give swiss francs and a limited selection of Euroen, all of which tags are irrelevant to the bank proper but can be very important to the bancomat customer seeking a particular function or international network.

yeah, now that i look at this, the v1 is a clone of the edited v6 (names need tweaking in indiana, some of the roads with this naming pattern have been expanded to South but not this S), it is not within the bbox of this edit which should be limited to the single car park service drive in pennsylvania. there's probably some explanation why colorado is involved.

the two edits linked in
<< 81158988 · ssange · 81159095 >>
before and after the v6 edit give no clue how the road got cloned about 1000 changesets total later. here we have
<< 81159884 · ssange · 81160031 >>
in michigan and minnesota, so no clue why colorado should be involved at all.

all these edits were made via the osm website, while i still see other amazon edits without the given host (internal amazon iD instance). there is a common bug where amazon editors save multiple distinct edits to a single save creating large changeset bboxen; today i have suggested opening a new broswer tab for each edit rather than re-using an older edit tab when the editing session appears to freeze.

however, i recall reading somewhere that iD checkpoints unsaved data, so this might not be such a good idea to be running multiple editor instances, which i routinely due with potlatch which does not checkpoint unsaved data anywhere i know of, meaning unsaved work gets lost when the oom-killer reaps the flash instances. so it may well be that my suggestion of multiple tabs may make things worse, with each iD instance claiming the unsaved data for itself.

obviously my earlier suggestion was not well thought out, and won't help with the known problems, so i should go back to my day job hauling stones and leave anything requiring thought and intelligence to the experts.

as for identifying edits that cover too large an area, once an edit has been uploaded and saved, you cannot change its area.

as far as i know, there is nothing to change after the fact; the two edits that form the bounding box visualised in the changeset overview were probably correct and the only thing to change is to split them into separate edits by saving and waiting for the save to complete before going on to edit elsewhere, or invoking a new instance of iD in a new tab or window, with the overhead and the time which on my machine seems to border on an eternity, whilst Potlatch 1 is up nearly as fast as I can click through the startup (while being not suited for general editing these days).

i don't know what sort of correction your team is considering after the fact - a revert is possible but also covers the same large area with the problems reflected in the original, making a second changeset covering multiple us states to appear in the history tools, and bringing no benefit as both sets of edits would need to be repeated, losing time.

i can't see how identifying and correcting the problem changesets could help, but perhaps i'm not thinking outside the bbox enough, so i (and probably others) would like to hear details about this proposed course of action.

off-topic, but i thought i'd mention this is an amazon edit, but unlike earlier where i could identify them based on the absence of a particular header, this one does in fact include
host osm.org/edit
although i've not paid attention for some weeks to know if this is a new development and commonplace.

that loses the information of the precise location of the bancomat. in a recent note i noted a bank poi was improperly located, while the bancomat was precisely mapped where it could be found, on the proper side and well down of a streetcorner, and not on the main street of the bank entrance.

this is an outdoor bancomat on the building; where the bancomat is within the bank proper i would agree, unless the indoor mapping is more detailed to individually map each of several bancomats, self-service terminals, separately positioned from the bank counters proper.

the `on-the-ground' rule doesn't refer to definitions and terms used by other sites, but to how a disinterested mapper, when confronted by the object in question, would choose to map it in osm terms going by osm definitions.

there are plenty of so-called parks referred to by other authorities that do not qualify as osm urban parks, to pick an obvious example. the definitions used by these outside authorities are irrelevant to osm, and have nothing to do with the on-the-ground rule that excludes third-party influences.

i have no opinion here as i use everyday words like town or city to refer to things that clearly are not, in casual speech, as for me these are destinations, and not as distinguishing categories. also different languages distinguish the terms differently, so i say `city' to mean a compact village that is clearly not the surrounding not-village.

you are confusing various different meanings of `historic' as used in english (and probably other languages) with the osm definition of `historic'

This changeset has been reverted fully or in part by changeset/81229598 where the changeset comment is: maps.me fake rest areas

that would be an easy one to point out if one of the below that i looked at had that change, but i didn't look far enough.

the manual way to inspect the history of object tags is at the bottom of the link for the object, like
Download XML · View History

that gives a URL like
way/18855621/history
with details for each revision over time.

it could be easier to pass the way (or node or relation) ID to
https://osmlab.github.io/osm-deep-history/
where the changed attributes are highlighted in the listing for each changeset.

hope that's what you wanted to know.

but what about the case where an originally concrete road has decayed to the point where patching is pointless yet it still forms a solid base for being overpaved with asphalt to save money, and the original mapper used paved to refer to the concrete? you're both right... i'll go away.

This changeset has been reverted fully or in part by changeset/81093539 where the changeset comment is: maps.me fake rest areas

i have to agree with salad99, if this Packstation is not a generic name, it certainly appears as a label on the objects illustrated in https://en.wikipedia.org/wiki/Packstation .

the operator, DHL, label is separated too far from the Packstation label for me to insist that `DHL Packstation' is the full label. If `Packstation' is a generic german term, shared with other operator services, it is not necessarily a generic description in other languages - see the danish label `Døgnposten' if that should be their generic term.

The OSM tags of post_box and vending are insufficient to determine its label; one should not need to parse the wikipædia tag in order to present to a user speaking another mother tongue, the label to be seen on the object, as it helps to identify the object when the generic term in their own language is very different.

this is quite the opposite from the recent retagging of Hundekotspender vending machines, none of which i have ever seen with a label anything like that, where the generic term was turned into a name tag. that was wrong; but so long as a label or sign can be seen on an item, even if generic, that is a good candidate for the name= field, like the generic Lavanderia or the american General Store.

The ref=115 number does not belong in the name= field.

hallo someoneelse,

it seems like andrew has learned norwegian so maybe a translation would be helpful? tak...

(not being serious, obviously, though i should be)

grüezi ascheberger,

your editing history can be seen at @Ascheberger/history and in the last two days, it seems you have given up on the beginner editor JOSM and joined the far superior iD crowd, as well as giving in to and embracing the cultural dominance of english, no wait, *american*, as the lingua franca of osm, so no need for me ins deutsch zu übersetzen. there are a lot of long-idle mappers like you who are now doing the same, proving the dominance of english, no wait, *american* in osm and showing the present diversity drive as barking up the wrong tree. awesome. megageil.

no wait, awesome!!! thanks for your contribution to osm!!!!!! please feel free to reach out!!!!!! great work!!!!! AWESOME!!1! oh i feel sick

see @Bluedabadee/blocks , and look around for discussion of similar edits, and mention on the two swedish communications channels. i could probably go into details here as i think the person who edited this is not the mapper who sees this e-mail conversation, but for now i'll leave the research to you, if i may be so allowed.

moin andy,

in your way history link, the two/one end nodes of the way were merged as seen in the history, node/7213739352 , now shared by both areas.

click on the two objects of which it is a member, way/772676282 and way/772676281 , and they are both adjoining at level -1.

i can identify other dupe nodes on the first page of the deleted nodes by their changeset description as amazon edits and the dupes (which i've cleaned by the tonne in the past) are a result of an iD bug that piles multiple nodes, occasionally half a dozen, at a single point in a way.

my repairs of this type have been simple potlatch 1 or 2 merges in one local area per changeset, but i have seen places where a node for a gate or other tagged node overlap a non-tagged node. i forget now which of the two gets deleted by the merge as it's been months since i've done this sort of cleanup based on the OSM Inspector daily update, that gives me a good idea of where the amazon team have been working on a day or over time. but that means a visual inspection of each place is needed, as well as stepping through the nodes in P2 (can't recall if P1 has that ability or if a different missing capability dealing with shared nodes is that of which i am thinking). or any other editor. there are a few 3d or similar complex polygons on the us west coast i learned to run away very fast when seeing the dupes.

i have no opinion if a revert is appropriate, or overkill here, but the handful of deleted nodes i reviewed had none with tags, but i only reviewed a small fraction.

i'll crawl back into me hole now.

This changeset has been reverted fully or in part by changeset/81025145 where the changeset comment is: alpine huts are not found in cuba and personal info should not be published to osm

This changeset has been reverted fully or in part by changeset/80970091 where the changeset comment is: resolve note/1987046, a maps.me versus maps.me conflict

hi, can you look at node/61483240/history which along with another nearby node looks to have been dragged from its correct position and joined with your boundary here? thanks

hoi ian,

can you tell if this is actually a house and not some random farm building, as aerials lead me to believe the eastern-most of the three buildings would be the house, this roof missing the characteristics of a residence, having been selectively added by a persistent fantasy mapper.

thanks

This changeset has been reverted fully or in part by changeset/80939164 where the changeset comment is: despite multiple user blocks, you continue to add this fictional rubbish to osm