Ups. Sorry. Fixed.

You are breaking >10 years worth of software, style sheets, maps, etc. Everybody who has dependet on this definition. This is not something you can change.

The way the natural=coastline tags have been understood for the last >10 years clearly say that the coastlines tags should go around the bay. Some of the details of the discussion on the tagging mailing list do not matter for the situation here. Are you going to revert this now?

I personally don't have an opinion on any tagging here except that natural=coastline should be where it used to be. If you want other tagging for naming the Bay that's fine with me.

Sorry, Sparks, but it doesn't matter for OSM what something "is". All that matters is that we agree on tagging, so that everybody can use the data consistently. And the agreed definition on where natural=coastline is tagged is in the wiki and has been used for a long time. You can not change this without breaking a whole lot of usage of the data. You are free to invent new tags that mean a different thing, but you can not change existing definitions. (Well, you could, but in something like this it would take quite a lot of community discussion and a worldwide consensus which would be very hard to reach.)

Lake Michigan is an actual lake, not part of the sea, so it doesn't apply here.

You can not just change what a tag is supposed to mean that has been around for years. Such changes break OSM. You just have to look at a map like the cycle map: osm.org/#map=4/43.13/-94.83&layers=C It doesn't show the great lakes in small zoom levels and it will not show Chesapeake Bay in the future any more of this change stands.

I am not sure what you mean with "follows the bathymetry of the Bay". The wiki defines the coastline as "The natural=coastline tag is used to mark the mean high water springs line along the coastline at the edge of the sea." By that definition your coastline is way off.

This change breaks the whole world map! The Chesapeake Bay is a bay but it is still part of the sea, not an inland water area. The bay is clearly tidal, clearly part of the sea, so the natural=coastline tags have to go around it. On many maps this huge area will now not be visible as water any more, because many maps don't render inland water until larger zoom levels. This change is also blocking updates to *all* coastlines around the world, because the automatical coastline tool has noticed this huge change in the world map. See
https://osmdata.openstreetmap.de/internal/coastline/

The coastline in this area is broken. See https://tools.geofabrik.de/osmi/?view=coastline&lon=-76.51587&lat=36.88312&zoom=12

Not sure whether it was this changeset or another. Can you have a look?

These overcomplex multipolygons are currently not fixable, because the software used to interpret them can't handle these complex cases. And every time you change them, there is a chance the processes handling them break. So please, at least for the time being, stop editing them. We have to figure out how to make the software work correctly.

The wiki says "The natural=coastline tag is used to mark the Mean high water spring which is the point of the highest tide." This implies that there is a tide...

If you think about where you want the coastline to be drawn on small zoom levels, where the sea is drawn but inland waterbodies aren't it becomes clearer where it makes sense to draw the coastline.

This change turns huge ocean areas into an "inland water" by putting the coastline far out. Is this correct? Generally water areas that are tidal should probably be mapped as part of the sea.

The changeset comment suggests that this changeset is about the "Closed_ways_with_spikes" I created. But there are a lot of edits here that might be due to a misunderstanding. This challenge is not about turning circles or turning loops! I don't want to say anything about whether it is right or not to turn turning loops that are mapped in detail into single points, but it definitely hasn't anything to do with the challenge. Is there some misunderstanding about the purpose of the challenge here? Or is this some other mapping that was done without changing the changeset comment?

You can also see the problem here:
http://tools.geofabrik.de/osmi/?view=areas&lon=1.34089&lat=43.57942&zoom=17

There are over 700 duplicated nodes here! JOSM finds thousands of errors with the validator.

This changeset broke the coastline. See http://tools.geofabrik.de/osmi/?view=coastline&lon=57.26229&lat=25.95029&zoom=18&overlays=coastline,coastline_error_lines,line_not_a_ring,line_overlap,line_invalid,line_direction,questionable,coastline_error_points,unconnected,intersections,not_a_ring,double_node,tagged_node . Problem is overlapping coastlines. Is the new border/coastline really correct? Sat images show a different coastline. Are boundary and coastline really the same here and at the new location? Also there are obviously far too many changes in this changeset for a manual inspection. Changes should be put into smaller changesets. And changing the old coastline to tagging natural=xxxcoastline is not a good idea. You have to conflate the old and new data in one go and not just put your new data over the old and then later maybe fix it.

Interessant. Ich hab keine Ahnung mehr, wie das zustande kam. Mein GPS schreibt keine Höhenangaben in die GPX-Datei und ich kann mich auch nicht erinnern, jemals ele-Tags benutzt zu haben. Verbuchen wir es mal unter Anfängerfehler. :-)

Please, please do NOT add natural=coastline tags to inland lakes. Natural=coastline is for the sea coastline only. This has been a long-standing tagging convention and is clearly documented on the wiki. (There are only a few lakes that still have coastline tags for historical reasons.) The coastline update process is brittle and will lead to problems if there such large scale changes to the coastline. Please revert these changes.

Hi!

Why are you tagging a lake natural=coastline? This tag is for the coastline of the sea only. For years we have been moving away from tagging coastline on inland lakes. There are some leftovers that are too big to change, but lake Ontario worked well without the natural=coastline. Major changes to the coastline like this should not be done without discussion, because it can have worldwide ramification due to the rather brittle coastline update/rendering mechanism. Was this maybe discussed somewhere in the Canadian community?

Zur Info falls sich jemand wundert, warum die Diskussion hier aufgehört hat. Die Diskussion wurde auf der Dresdner Mailingliste fortgesetzt:
http://lists.openstreetmap.de/mailman/listinfo/dresden

Lieber Wolfgang,
ich habe Deine persönliche Nachricht gesehn, will aber hier nicht darauf eingehen, weil ich sie hier nicht zitieren will.
Ich finde es völlig normal und richtig, dass die Diskussion hier öffentlich geführt wird. OpenStreetMap kann nur funktionieren, wenn die Community interagiert und hier gibt es die Möglichkeit für die interessierte Community sich zu beteiligen. Schließlich geht es hier nicht um einen kleinen Fehler, sondern um grundsätzliche Fragen, um benutzte Datenquellen und das vorgehen beim Mappen. Bitte antworte doch hier oder, wenn Dir das lieber ist, auf der Dresdner Mailingliste.

Lieber WolleDD,

Ich habe ein paar Anmerkungen zu Deinen Änderungen an den Bushaltestellen in Dresden. Ich habe gesehen, dass Du das auch an anderen Stellen daran arbeitest, aber weil dieser Changeset quasi direkt vor meiner Haustür liegt und ich die Gegend kenne, gehe ich jetzt mal konkret hier darauf ein.

Als erstes stört mich, dass die als highway=bus_stop getaggten Punkte nicht mehr dort sind, wo das Haltestellen-Schild ist, sondern auf der Straße. Das ist eine Änderung der schon lange eingeführten Bedeutung dieser Punkte. Aus dem Wiki: "Der highway=bus_stop tag ist als Knoten (Node) links und/oder rechts von einem highway-Weg am weitesten verbreitet und kennzeichnet die Position, an der die Passagiere neben der Fahrbahn auf den Bus 'warten'". Auf der Karte fehlt mir so jetzt auch die Information, welcher Punkt für welche Fahrtrichtung des Busses gilt. Das war vorher klar ablesbar. Die Einführung der verschiedenen public_transport-Tags ist total unabhängig davon, wie highway=bus_stop getaggt wurde, das sollte man dabei nicht ändern.

Als zweites stört mich, dass überall public_transport=platform gemappt sind, wo keine existieren. An den Stellen, wo ich mich auskenne hier in der Gegend, sind die jetzt überall eingetragen, obwohl in der Wirklichkeit da einfach ein (oft unbefestigter) Gehweg ist. Da ist nichtmal eine besondere Pflasterung oder eine Erhöhung der Bordsteinkante. Diese "platform" existiert also nicht als in der Wirklichkeit erkennbare Sache und darf daher auch nicht gemappt werden. Vielleicht unterstelle ich hier was, aber mir kommt es so vor, als ob hier nur der Ordnung halber und weil es dann so schön einheitlich ist, massenweise Details eingetragen wurden, die nicht existieren.

Das bringt mich zu meinem nächsten Punkt: Größere Edits, insbesondere, wenn sie bestehene Strukturen verändern, sollten mit der Community vorher diskutiert werden. Hat eine solche Diskussion stattgefunden? Ich bin noch nicht so lange in Dresden und habe das daher vielleicht verpasst. Kannst Du mir einen Hinweis geben, wo eine solche Diskussion vielleicht stattgefunden hat und welche Ergebnisse die hatte? Wenn es keine Diskussion gab, dann würde ich vorschlagen sie auf der Dresdner Mailingliste (http://lists.openstreetmap.de/mailman/listinfo/dresden) zu führen.

Das Ganze ist offensichtlich eine Armchair-Mapping-Aktion. Hast Du die Situation vor Ort überprüft? Dann wäre Dir wahrscheinlich aufgefallen, dass die Haltestelle Oehmestraße an der falschen Position gemappt war (und nun immernoch ist). In Wirklichkeit ist sie nicht in der Berggartenstraße, sondern in der Oehmestraße vor dem Haus Nummer 14. (Es kann gut sein, dass die Haltestelle mal verlegt war, angelegt wurde der Node im Changeset osm.org/changeset/11998810, der den Titel "Umbau Oehmestraße" trägt.) An der jetzigen Position ist sie seit mindestens einem halben Jahr. (Diese Haltestelle hat übrigens (in beiden Richtungen) eine höhere Bordsteinkante und so Riffel-Kacheln für Blinde, man könnte hier also begründen, warum eine "Platform" eingetragen ist auch wenn ich persönlich so eine "Platform" nur bei größeren Haltestellen mit Bahnsteigen oder Bussteigen mappen würde.)

Um eins klarzustellen: Ich bin nicht gegen das verfeinerte Mapping der ÖPNV-Infrastruktur. Das ist prima und ich halte das neue Schema auch nicht für völlig verkehrt. (Ich war bei der Diplomarbeit von Sebastian "Oxomoa" Schwarz, in der er das Schema entwickelt hat, der Zweitbetreuer), aber Details sollten auch nur da gemappt werden, wo sie existieren und es sinnvoll ist. Wenn wir Details erfinden, hat keiner was davon. Und lange bestehende Konventionen sollten eingehalten werden. Und wenn man größere Änderung plant, dann müssen die mit der Community besprochen werden.