these conversations are public and presently open to the whole world, so don't be surprised when uninvited parties or suspected sockpuppets such as meself poke their noses where they do not belong like here.

the apartment is certainly due to the poor design of maps.me, which it pains me to see experienced mappers like doktor kluge actually using like this rather than an editor free of maps.me issues.

the difference may be between the usian use of apartments versus the tourism definition used in osm, and it's no less clear in other languages that recognise both the english and french yet have their own equivalent word.

instead of deleting this, better would be to return it to its pre-vandalism state. the deletion has since caused the empty space to be filled twice, as well as the original area and mappers' history to become lost.

This changeset has been reverted fully or in part by changeset/71269187 where the changeset comment is: delete bogus maps.me personal home castle spam

are these changed tags actually presented as deprecated? on the wiki i can find nothing to back this up, with shop=boutique presented as status de facto.

only landuse=farm is documented as actually being deprecated with that word, of what i looked up, being discussed long enough to bore into the brains of anyone half paying attention, yet still to be found on the map.

adam, woody is publicly documenting what is happening out-of-sight, which will help the dwg in case they need to again take action as in way/549033571/history and the relevant changeset discussions.

it is part of the Open of osm, and keeps mappers civil. sometimes.

note that contacting the officials could help the vandalism backfire even more spectacularly as an unregistered business.

the poi, pre-adolescent-vandalism, was redundant with the school grounds you mapped at the same time (amenity school) and its position is better represented by the building outline that also has mostly similar tagging. so yeah, while it did add another label when zoomed in, it seemed to only attract the attention of a vandal, this time as a sacrificial lamb.

in general, the poi is the least accurate representation of the school grounds and building, so being redundant as tagged, it added little, which is probably why georg chose to delete, rather than repair.

this also added a v1 of node/6542670346 which i can swear i had seen already poorly added in changeset/70940746 which this appears to undo in spot checks, as well as further older changes on page3 of the nodes below.

https://osmlab.github.io/osm-deep-history/#/node/6522268884 shows this to be a duplicate added atop a very poorly positioned node, or else i have cached tiles, but a further object history elsewhere explained in a changeset commentary that a different user had reverted identical-data nodes.

a third deleted node appeared at an empty spot on the map, but not quite as badly positioned in the road, so i do not know about that one.

I would hope that any such iD automated-edit-by-proxy changesets would be as quickly detected and reverted as those a few weeks ago in Zürich, carried out worldwide and since then earning critical commentary.

my analysis of the changesets was that the iD rules were based on the assumption the mapped data was perfect, rather than being a simplified schematic highway representation mixed with a realistic depiction of tram lines, so a lot of not-really-existing crossings were added, that could negatively affect cyclists and auto-drivers who come nowhere near the tram lines (unless voluntarily choosing to straddle that lane as i witnessed rather often).

viewing the iD-induced damage outside of areas like Züri or Wien, there usually was little to complain as the overall mapping was poor and lacking, but where things are mapped in detail, then yes, the assumptions iD makes do indeed damage the map data. thus such changesets need to be caught and quickly reverted.

thanks. this was actually the last node i edited/not for which you were responsible. another mapper appeared to the south with this issue, but as i have no history with that mapper, i figured the best way is to quietly fix things.

in your case, i think we know ourselves so it does not matter. these changesets are almost a year old as are those of the other user, so it could be a since-resolved iD issue, as i don't see a flood of new overlap nodes anywhere.

what interests me is, does iD highlight this in any way? i know, in theory i could start iD meself, but for some time it just delivers a blank page, that i don't feel like debugging.

again, as this does not seem to be a current issue and it is limited in scope, i think you can ignore me. please.

the top-listed deleted building below, way/235340263 , has been restored to life as seen in pretty much every aerial imagery, out of respect for the original mapper.

hi adam,

this is a long-standing issue, and i am trying to understand how i am finding several such problems where you have created overlapping nodes at junctions.

these are flagged by the osm inspector, and there is a swarm around california that have not yet been acted upon, but the last few i fixed were items you had added.

node/5616466187 is one that i am leaving alone for now, to try and understand what is happening.

when i view this in potlatch1, the node pulsates angrily. p2 also displays an indication of multiple nodes in the same location.

does your iD editor indicate that there is an issue here?

and can you think of anything about your workflow of the time that might result in this happening repeatedly at junctions?

there were also some closed ways with overlapping nodes i resolved earlier as a one-off that you had created, but that did not appear to be a recurring issue, but it did raise my eyebrow at the time.

i am hoping that after my cleanup around here, where i can make sense of things, it will not be a recurring problem, and this area can remain as error-free as the rest of the us of a.

thanks

great -- that's why i'm commenting in detail rather than quietly correcting things like elsewhere, in the hope you will experience the same aha! moment i did some hours ago, and unlike me, become a better mapper.

yo,
your reversion re-added the name from v2 to the outer, which is wrong as the remaining relation has the proper name.

this feature should not have a name, as it is merely the outer with no additional tags, and the fact that it was given a name is what is throwing the osmi warning independent of the multipolygon.

the name was added a month ago in an attempt to remedy a different problem i don't see now.

erm, as this is a different changeset, i don't know if gpserror will be aware of this comment...

i'm confused - does your use of outer, inner match the osm multipolygon terms or what?

as i see it, there are two identical relations here: relation/9670998 in question and relation/6661096 which looks properly tagged.

way/685295750 , used by both, has a pointless area=yes tag (there should be none on this innard)

seeing it's early this holiday (don't those birds know to KEEP QUIET on holidays like us so-called humans) there could be something i'm overlooking here, so forgive my stupidity just this once.

okay. clarity to z19 looks like i expect, so i can keep me brain for now.

mapbox shows clearly heavy machinery and skips, as well as the destruction in progress of the paths north to chicago street. this must be rather old mapbox imagery, because...

bing goes to z20 and thus is probably closer to 5 years old here, and it is possible to make out the post-removal positions of things.

all other TMS imageries i can view are obviously as new or more likely newer.

a quick g00gle text search turned up nothing about what used to be here as obviously i searched wrong, or the aliens who abducted the building also infiltrated g00gle. again.

the bog-standard esri imagery also shows an early post-removal ghost-outlines-state, but nothing can be pinpointed to former building parts.

i know, across the globe it's difficult to keep track of all the different imageries, which is why i am happy to stick my nose here where it is not wanted.

Pascal,
it used to be that the clarity layer was the decade-ish old original bing imagery, sometimes mirrored by mapbox.

however, i have seen elsewhere this appears not to always be the case. here the mapbox imagery is different where in non-up-to-date areas it was a poor pixellated copy of archival bing.

that no other imagery for this area shows anything disturbs me, and i shall attempt to analyse what is here, and whether i need a serious brane-adjustment for the different imageries nowadays.

more later. i hope.

no worries, i don't have the stomach to reverse-engineer things in detail, as the deep history viewer i used caused memory use to balloon to the point where i sacrificed the potlatch child processes to stop the swap and avoid the droid (oooh, better check that cultural reference. ewww. yup, i'm old, but we knew that).

what i found interesting is your way cut was not at the lake itself, but at the point just before. i'm wondering if the lake was continuous with the nodes doing double duty along part of the shoreline. i've seen that often enough in my fixit role, and in fact there were four overlapping double-duty nodes where the original outline ended and the new one - well, overlapped.

i bet you have no clue what i'm talking about. nor do i.

cheers

i don't see in the linked wiki page mentioned, any indication that this is a deprecated tagging (status de facto), nor any mention of the additional tags that iD is so eager to add.

if iD is presenting these as actually deprecated, that does not appear to be justified by the documentation i see without research; the same is true for other suggested changes that have caused me grief.

in fact, grabbing one of the first changes below, this is *not* something that should be changed without review and familiarity with the local laws (bet it's the zebra crossings that near me have meaning lost on the iD developers)

arrgh, more alpine huts in this town to swat. that and castle nodes would be a useful thing for iD to flag.

howdy,

could i pick your brain to understand your intention behind the residential boundary relation/397331 , presently broken?

your changeset comment points to the brokenness at the west end of way/49085161 where the other end of the boundary arrives from the north, but at this point intersects not this road but the slightly offset boundary parallel to this highway, to which this boundary does not belong.

would it be better to have the neighbourhood follow boundary lines where possible (until the end of the mentioned highway segment) or were your intentions to connect the boundary line to the physical highway with a short (centimetre?) link where what defines the outline changes, keeping boundaries separate?

i hope you understand i can see too many ways to fix this, but i'd prefer to know your intentions for mixed cases like this.

thansk

mojn,

your josm didn't perchance warn your changeset was breaking relations like relation/2416295 - which i've just repaired so far as i can see, in a way likely very different from how it was originally mapped along the lake outline, so no need to take action.

i'm just trying to gather as much background info to help me understand what may have gone titsup with the multitude of damaged unclosed rings thrown up by osmi all across your country, when the element histories allow me to re-create the missing segments. or better, to try to understand the thinking behind the editor operators, as there seem to be as many ways to map as there are mappers.

thnks