This changeset has been reverted fully or in part by changeset/71509910 where the changeset comment is: #Vandalismus

This changeset has been reverted fully or in part by changeset/71508825 where the changeset comment is: please only map real things.

This changeset has been reverted fully or in part by changeset/71508804 where the changeset comment is: please only map real things.

just checking - you created a single-point forest (didn't know potlatch could do that, i must play) out of node node/1671288541 which was already a part of the existing way/154608197 which, as far as i can read from the history, did not get wiped out a few days ago.

the way in question, way/698846659 at v1 24 hours ago.

thanks

nice try, but it fails to jive with the evidence :-)

this is actually nothing to do with this changeset - v1 of the way was created 8 days ago, and the node in question, -389, was created then. nodes are numbered sequentially at time of their creation, and it sits perfectly between -388 and -390, both attached to the meadow. well, it did until i trimmed it in v4 of way way/697072632/history .

had it been created and added later, the number would no longer fit in that changeset's range. my potlatch assigns negative working numbers to new creations until their upload, dunno about the others.

not a big deal, i repeat, as it happens often enough. i am hoping once i get california, the last refuge of swarms of way errors, cleaned up, it will be easier to detect this and bad pokemon mapping nearer the time of creation and identify any patterns (the no-intersection parking aisles also happened far too often yet i haven't been arsed to see if those can be pinned to a particular user, a team, their editor, or what).

as an aside. i've had netwerk problems often enough, and i can probably still point to overlapping entire ways or standalone nodes that resulted, most of which i cleaned up by hand, or probably begged for a revert before summoning up the courage to ask, please sir, may i have a reverter?

you may also want to have a look at changeset/68160671#map=18/31.59190/-97.17947 to see if this is the sort of (lack of) quality you intended to add to the map.

i only looked at a few of your changesets to see if the extra nodes are a longer-running problem, and i did not go much further back than this.

thanks

should i revert this one? maybe then try the others if there are not too many conflicts?

this appears to be deletion of detail mapping and replacing with schematic ways.

viewed in https://nrenner.github.io/achavi/?changeset=71399994 ; best to set layers to plain OSM to best see the current state of the mapped footways

not worth mentioning, but since i caught ya red-handed...

at the lower right here, there was a duplicate overlapping fence node at the corner, while the other was attached to an unduplicated meadow node.

i have deleted the unattached one, so no action needed. i'm curious as to how country-wide there seem to be maybe half a- to a dozen such new cases per day. dirty mouse causing double-clicks? hyperactive operator wildly clicking?

wonder if the above
warnings:close_nodes 1
refers to that.

anyway, while the rest of the country has been kept clean by b-jazz, there's a pile-up in california along with self-intersecting ways that i'm slowly trying to clear to make it more inviting for others to tackle the issues where i throw up in disgust over my hands.

ignore me. thanks

again, something seems horribly wrong here.

you have used some 700 nodes here, yet the lines are very uneven and do not always match the aerial imageries, and there is an absurd amount of detail in the circle, where nodes are not consecutive, but several rounds are made around the circle, and the apparent footpath `v' that appears very uneven.

i am tempted to suggest you use a real editor like JOSM or iD which will give you the tools to smooth out or straighten the lines and simplify the excessive noding and inaccurate detail that osm does not need.

details of these edits, node-by-node, can be seen at https://nrenner.github.io/achavi/?changeset=71386825

hi,
there seems to be something that has gone horribly wrong here.

it looks like you have been drawing outlines of the building roof with an insane number of closely-spaced nodes for what should be a straight line, as footpaths.

you can see how your changes appear by zooming in at https://nrenner.github.io/achavi/?changeset=71385918 .

i am not sure if this is what you intended, or if go map!!1 is causing problems.

sorry for my last changeset comment - written while half asleep.

after a few minutes sleep, i think i know what is going on here as well. the relation was changed five years ago; it was broken before here as well as in your earlier commented-by-me changeset, but not in a way to be flagged by osmi, so the broken rendering beforehand was not seen by me.

i was probably confused by the one-tag to two-tag difference, not to mention the water(way)=river similarity for two different concepts, as i've been struggling to understand the wiki page when encountering wet map brokenness.

here too i've deleted the redundant outer tagging apart from the differing source tag, and the island/object now renders.

i've found lots of places within the imported canvec data where this has been an issue, to say nothing of old/new-style multipolygons.

anyway, apologies for misunderstanding the change iD has been making - it is actually helping here by highlighting the error to qa tools, without itself detecting the redundant/wrong tagging it has changed.

now to think about sleep

your change here has added a natural=water tag to the outer way way/25460578 previously only partly tagged as a riverbank.

this has resulted in the entire area bounded by this way to rendered as water, instead of the inner islands defined by the multipolygon relation being excluded.

this had been a fairly common error, outers tagging duplicating the inner, but i made several passes to clear most from the us, and this appeared today in an area i had cleared.

the wiki page on riverbank tagging warns not to retag as river without knowing what you are doing for several reasons i do not understand. i suspect this is not one of them, but a case of the iD editor incorrectly interpreting the tagging that is syntax-broken but working, and turning it into a syntax-correct but logically-broken tag.

https://osmlab.github.io/osm-deep-history/#/way/25460578 shows the tortured history it has had, but i shall be deleting the automatically-added tags and removing any other redundant ones to rescue the islands from the flooding.

does the iD validator warn in cases like this after your change before uploading, that the outer member tagging duplicates that of the relation?

this looks like it needs manual correction after a string of maps.me edits.

it appears on the international map still as prospect (cyrillic) but both the name:en and :ru show panda, which i presume is correct.

it is clear from the aerial imageries available that there are zebra stripes.

but unlike in switzerland, the aerial imagery is too poor for me to say if this is truly uncontrolled - i almost suspect it may be controlled as there is a visible halting line on the southbound road into this busy intersection.

if it really is uncontrolled for pedestrians, and assuming in russia that like in other european countries an uncontrolled zebra crossing has a special legal meaning for drivers, then it should be tagged as crossing_ref=zebra to reflect that, which is implied as crossing=zebra that is too often used where incorrect or without special meaning, thanks to an earlier iD editor preset.

the highway traffic signals are mapped schematically at the junctions of the roads, rather than at their true locations just before the mapped crossings.

therefore i highly doubt crossing=uncontrolled is correct, and this should no more be automatically applied than =zebra without more knowledge.

hi andy,

as someone who has done this too often, what is sorely missing from the osm website report-a-whatever possibilities, is to report a single changeset like this with one click.

i'm not sure if report-a-user goes indirectly to moderators, as i understand diary reports (that is being addressed as i write, i think) take a detour.

but the modus operandi of click-user-link, click report-a-luser, realise the changeset url wasn't copied, so with luck a middle-click was used for both new tabs and it can be copied and pasted without too much pain. (or browse changeset comments in a separate browser as i do)

it may also be that pascal goes through a template, updated since this report, which does not even go through the osm site, in which case i don't even remember if the possibility to spam the api with reports is available.

as your comments to me have shown, the report-a-* looks to be a bolt-on that isn't integrated with markdown, so i'm not surprised (actually, yes i am) that individual changesets are not reportable, allowing the reviewer to only report the suspicious ones (GolfMapper) as opposed to the totally bogus (Torches and Pitchforks Whatever with its own marxist party), taking the burden off the dwg to separate the gems from the excreta.

or something.

must be me bedtime, cheers

sounds like a case for a revert, or preferably a redaction of this forbidden source.

This changeset has been reverted fully or in part by changeset/71344599 where the changeset comment is: https://lists.openstreetmap.org/pipermail/talk-gb/2012-May/013166.html

have you compared all the available imageries, as well as official data when available?

i have no idea without looking which will be best around here, but often the default startup imagery is far worse than, say, the archive past-sell-by-date clarity imagery known for at least being close to where things really are.

that, by the way, is my default reference when i do not know better, or when far more detailed (esri, mapbox in some areas) imagery is not available.

this is a common beginner error, so no worries.

moin georg,

the first entry below gives the answer i guessed as correct based on failed autocompletion:
way/684438454

and it even bears the same village name :-)

hiya clarke,

as part of this changeset, you seem to have added the demolished tag to highlander road elementary school, relation/6407161 , shown clearly in progress in the mapbox aerials, and inferred from the blur in later aerials.

if you view the above url, there remain two things in osm that i am guessing are long-gone roof walkways that did not make it into the multipolygon. is it safe to delete these, do you know? or might they be preserved for eternity as memorials to all the schoolchildren who suffered here?

also, i cannot guess how old what seems to be the newest and also blurriest imagery, but it seems to show one building still intact, independent of the others. do you know if everything was levelled to the earth since that overflight, or if that one building still exists for later use?

i was clued into this by the osm inspector calling a problem with a demolished gap, and i am thinking with the outline still visible, the inner details do not matter so i can probably safely mangle that to quiet the warning.
https://tools.geofabrik.de/osmi/?view=areas&lon=-118.64575&lat=34.19554&zoom=18&baselayer=GeofabrikStandard&opacity=0.66&overlays=role_should_be_inner

thanks