Scheinbar nicht. Sonst hätte er nicht nach zwei Jahren wieder einen mechanischen Edit gemacht.

Da es Löschungen sind, spricht nichts dagegen, sie zu revertieren. Der Konsens der Community ist ja für die gelöschten Fußwege, auch wenn sie Routingkrücken sind. Von daher ist es Vandalismus und den revertieren wir.

Es würde mich freuen, wenn ihr die Reverts machen würdet. Ein paar deiner Kollegen wissen, glaube ich auch, wie das geht. Bei Fragen helfe ich dir gerne weiter oder du fragst im IRC (z.B. #osm-de auf irc.oftc.net, Webchat auf irc.openstreetmap.org) oder einem anderen Kommunikationskanal deiner Wahl.

Ich weiß nicht, wie viele Konflikte darin lauern. Es macht mir halt keinen Spaß, ein oder zwei Stunden mit Konfliktlösung zuzubringen in einer Gegend, die mich nicht so interessiert. (Bei deutschen Bahnhöfen oder Bahnhöfen, in denen meine eigene Arbeit steckt, wäre es etwas anderes) Du verstehst hoffentlich, was ich meine. :-)

Es sieht so aus, also sollte man den Änderungssatz revertieren. Ich habe mir die restlichen Änderungssätze von ihm an Schweizer Bahnhöfen nicht angesehen. Vermutlich hat er darin dasselbe gemacht, d.h. man müsste auch sie revertieren.

Hallo Weltstaat,

du solltest dir mal changeset/41473401 sowie die Änderungssätze davor und danach mit Achavi (http://overpass-api.de/achavi/?changeset=41473401) ansehen und auch die anderen Schweizer Bahnhöfe prüfen, die du und deine Kollegen in der Vergangenheit aufgehübscht haben. Benutzer Nzara hat die von euch gemappten Fußwege gelöscht, meint mein grober Blick. Vermutlich sind seine anderen Änderungssätze "update bus station" genauso unlöblich.

In Deutschland (Frankfürt-Rödelheim) habe ich ihm vorher auf die Finger gehauen und seine Löschungen zurückgesetzt. Aufällig wurde er durch einen mechanischen undiskutierten Änderungssätz (in letztem Fall ist er sogar Wiederholungstäter – der Name lies mich aufhorchen).

Links zum Weiterlesen:
changeset/41770820
changeset/41856980

Viele Grüße

Michael

Please do not move station nodes on the station building. They are mapped where the centroid of all platforms together is.

partially reverted by changeset/41873774

reasons see changeset/41770820

Sorry, that's the wrong changeset. This comment should go to changeset/41770896.

Another question: Why did you remove name="Kronberger Bahn"?

That's not his first changeset by him which has been reverted. See his mechanical edit on operator=* of railway tracks in 2014. changeset/26971130 http://forum.openstreetmap.org/viewtopic.php?id=28216

I have sent him following message because it seems to me that he has not understood the message in 2014:

===============
Dear user Nzara,

about two years ago I told you that mechanical edits have to be discussed before they are done.

changeset/26971130
http://forum.openstreetmap.org/viewtopic.php?id=28216

Unfortunately another mapper has discovered that you changed tags on a large number of cycle routes in the metropolian area of Stuttgart/Heilbronn without any prior discussion.

Mechanical edits are governed by a [policy](osm.wiki/Automated_Edits_code_of_conduct and need to be discussed before they are executed. Anything where you do not look at the individual object you are editing is a mechanical edit. Tagging changes of a large number of objects are also considered as mechanical and have to be discussed beforehand. Please do not make any further edits of this type. Otherwise your account will get blocked.

In addition, I want to inform you that the OSM community expects you to use more detailed changeset comments. "update cycle routes" is not a sufficient comment for the edits you have done. osm.wiki/Good_changeset_comments

A few minutes ago I commented on one of your "update railways" changesets because you delete two elevators. Please read that message. changeset/41770820

Best regards

Michael
==================

Dear Nzara,

elevators are mapped as nodes because they are a necessary routing information. The area of an elevator is tagged differently. Please also do not delete footways on platforms. They are necessary for routing. I will do a partial revert of this changeset and others with the same editing pattern.

Best regards

Michael

Hallo voland87,

wie du der Versionsgeschichte des Objekts entnehmen kannst, bin ich nicht der "Schuldige". node/3059639301/history

Vermutlich dürfte mapper999 die Tags aber auch von einem anderen Objekt kopiert haben. Näheres erfährst du mit http://overpass-api.de/achavi?changeset=CHANGESET-ID

Viele Grüße

Michael

This changeset has uploaded data which does not fit to each other. There is an offset between the water areas and the forest areas. Example: way/406539219

Could you please fix this?

Minikreisverkehre haben eine überfahrbare Insel (sind also ein runder weißer Strich in der Mitte der Kreuzung, ggf. mit ein paar Schildern), normale Kreisverkehre leisten etwas mehr Widerstand.

I have sent an email to the Talk-ca mailing list via Gmane. I hope it arrives. Otherwise I'll resent it the normal way. (I have subscribed the list)

Hi PlaneMad,

you fixed the multipoygon which was broken. That's the good thing. Thank you.

Unfortunately, you did not have a look at the history of this relation. That's a problem you share with your workmates. If you had took a look at it, you would have found that it is part of an broken import which uploaded large number of unclosed ways with natural=water (not even being part of a multipolygon). (I found this import when I tried out To-Fix https://twitter.com/Nakaner/status/769144181646295041)

If you look at the history before fixing something, you can easily distinguish an iD changeset which brake a multipolygon from an import uploading garbage. The first one needs to be fixed manually, the second one should be "repaired" by a revert.

Best regards

Michael

LogicalViolinist, why didn't you check and improve/adapt the existing data BEFORE you uploaded your import?

I do not claim that every lake has to be checked on the ground but some secpscepticism about third-party datasets is always a good idea.

Has ever been an OSM mapper in Northern Communities around James Bay and Nunavut and can say if the lakes at CANVEC match the reality? If you do remote sensing (outside OSM), it is a good idea to pick out some samples to check if the classificiation works as expected (or to train the classification algorithm/rules).

Regarding the JOSM validator: This check might be disabled at your JOSM. Maybe you delete your JOSM profile and created a new one with default settings?

Full explanation of issues of this import (changesets 41761086 to 41786190):

1. The imported data has overlapping, duplicated ways. Way #439632327 (natural=water) has exactly the same nodes as way #439632406 (no tags, inner member of forest multipolygon). Both ways have been uploaded at the same changeset. This issue exists all over the whole import.

2. There are areas which is mapped as natural=wood (multipolygon) which seems to have no trees at all according to Bing. If zoom out, the high-res imagery is replaced by low-res Landsat imagery. High-res is covered by snow while low-res is not covered by snow. The summer imagery shows a dark green only at that areas which are covered by trees on the winter imagery. Example: osm.org/#map=19/49.76484/-74.57356

3. A high-voltage power line crosses the area you imported and has already been mapped before. After your import it is still there but it runs next to its cutting through the forest. osm.wiki/File:Import-Fails-Powerlines-Not-Inside-Cutting.png

4. You uploaded address interpolation line(s) (way #439631732) whose curves are smoother than the sharp corners of the road.

5. The roads you uploaded are not connected with other roads and were uploaded although there have been roads before. http://overpass-turbo.eu/s/i6r

6. I doubt that way #439632682 is really a footway and assume that it is more likely a path. (That's more a tagging issue which can feed a long discussion at a mailing list)

Reverts will cover changeset/41761086 to 41786190 and maybe more changesets if I find more changesets with similar issues.

I will revert this an similar changesets in the next hours or days (its just a question of time until the load of the API is low enough). I will revert them mainly due to low quality of the imported data. Just compare it to satellite imagery, logic and Good_Practice at OSM wiki.

I will also revert all changeset which tried to fix this import.

Hi Rps333,

if you used a dedicated account and check all your uploads before you upload them, you would take the wind out of the sails of people like me.

Please note that not every error can be detected using JOSM's validation engine. If you upload data which is simple wrong (compare the data with satellite imagery you are allowed to use as data source – you might have a look at other Landsat imagery than the one used by Bing), your edit still might be reverted. If you do not invest the time to check the quality of your uploads, you cannot expect other mappers to preserve your edits (i.e. not revert it).

If your import is as bad as the examples of Worst of OSM (worstofosm.tumblr.com), it is just a matter of time until it and all similar changesets will be reverted.

Please keep the history of existing OSM objects. If someone has already mapped something in the area you want to import, you have to preserve this history and must not delete the old data and replace it by yours.

Additionally, I ask you to upload your data in smaller chunks, i.e. no changesets with more than 2500 objects at once.

By the way, has there ever been on-the-ground quality of Canvec's hydrological data (water areas and waterways)? Or do all Canadian mappers just trust that the people who produced the data did everything right? (OSM isn't a copy of public datasets)

Best regards

Michael