Osmose jetzt mit Deutschlandabdeckung

http://wiki.openstreetmap.org/wiki/Proposed_features/Water_details#Voting

Eben. Es gibt ein Proposal im Wiki, das zwar nur 16:3 pro ausging, aber das ist gültig. Ist ja nicht so, das ich mir das aus den Fingern sauge, oder neue Dinge erfinde.

Dass der Mapper, der das Proposal 2011(!) angekurbelt hat, sich nicht um grundlegende Änderungen im Wiki bemühte¹, sagt einiges aus über die Bedeutung des Proposals bzw die Verwendung des Tags. Genauso wie die 16 Abstimmer, denen zufolge jetzt die 25.000 monatlich aktiven bis 2.000.000 registrierten Mapper die neuen Tags verwenden sollen – die nur einen Bruchteil der in der DB vorhandenen Flüsse ausmachen:
water=river:10.700
waterway=riverbank:283.231

Ich sehe hier nur ein neues, konkurrierendes Schema, um neue Mapper zu verunsichern

Außerdem hätte ich gern eine verbindliche Festlegung, wann man water=pond und wann water=lake verwendet. Bisher konnte da jeder Auswerter für sich festlegen, indem er einfach die Länge von natural=water maß.

Der nächste mich irritierende Punkt ist das empfohlene tagging von Stauseen mit natural=water, water=reservoir. Ein Reservoir ist per Definition nicht natural – und ist nun landuse=reservoir auch obsolet?

Im Wiki steht, dass riverbank für die Fläche des Flusses² verwendet werden soll, nicht für den wasserführenden Teil, was man im Gegensatz dazu aus natural=water schließen kann. Die Ufer solcher Flüsse als natural=water zu mappen finde ich eher unlogisch:

Fluss Devoll an dieser Stelle, großklickbar

Hier noch der Link zur Diskussion in der ML.

¹
Mai 2011 nennt der Verfasser des Proposals water=* im englischen Wiki als eine Möglichkeit, Flüsse oder Kanäle zu mappen.

Anfang Mai 2015 wird von Xxzme waterway=river als deprecated deklariert – eine völlig konträre Aussage zu den Zahle des aktuell verwendeten Taggings.

Ende Mai 2015 wird im deutschen Wiki als “veraltet” markiert.

Immerhin dürfen Russen, Ukrainer und Portugiesen weiterhin einzig waterway=riverbank verwenden.

²

– Erster Satz der englischen Riverbank-Seite, dessen deutsche Übersetzung recht frei vorgenommen wurde.

Desweiteren steht im Proposal folgender “Ratschlag”:

Wenn man sowas tut gibt es leicht ein riesiges Chaos uns soweit ich sehe war das zum keinen Zeitpunkt notwendig.

Und hat sich schon jemand Gedanken gemacht was passiert wenn ein Fluss durch natural=wood oder natural=bare_rock fürht? Richtig, die meisten von uns nehmen wohl an, daß der Fluss über den Felsen oder durch den Wald führt und die teilweise absurd komplizierten “natural” areas nicht noch zusätzlich an jedem Flussufer aufgeteilt werden müssen. Solange der Fluss inklusive Ufer als waterway gemappt ist hat man dabei nicht die unschöne Situation, daß sich zwei natural areas überlappen - mit natural=water schon.

Ich halte das für eine Fehlinterpretation.
Das Flussufer ist die Linie, bis zu der der Fluss sich im Regelfall erstreckt, nicht die Maximalausdehnung, die er ein paar Wochen, ein paar Tage oder gar nur alle paar Jahre erreicht. Im Beispiel hier gehört da mMn natural=shingle oder sand hin, aber weder riverbank noch water. Es gibt Gegenden, da gehen Pisten durch die Überschwemmungsgebiete oder es werden sogar Felder angelegt. Soll man die per intermittent=yes in den Fluss legen?

Mir persönlich ist es egal, ob jemand mit water oder riverbank taggt, solange er das “Ufer” nicht über Hängebrücken laufen lässt oder die Fläche unter Brücken ausspart. Die Gefahr ist bei riverbank halt höher, da darunter eben oft nicht die Fläche verstanden wird.

Hier bin ich der Meinung, dass da, wo ein Fluss breit genug ist, um als Fläche erfasst zu werden, kein Wald und kein Fels ist, egal ob durch waterway=riverbank oder natural=water erfasst.
Da bin ich im Gegenteil dafür, die natural-Fläche aufzuteilen. Ich bin kein Freund von natural- oder landuse-Flächen, die sich über zig Kilometer erstrecken und die dann zu unwartbaren MPs mutieren, wenn Löcher mit anderen Nutzungen hineingestanzt werden. Die kann man gerade durch Flüsse, breite Straßen u.ä. in kleinere, handliche Stücke zerteilen.

Die unwartbaren MPs haben wir schon mal…

Und wenn der Fluss über den Felsen fließt finde ich es sogar völlig richtig das auch so zu mappen.

Also sollte man deiner Meinung nach einen Fluss so mappen?:

  • waterway=river für wenigstens den Hauptstrom der Minimalausdehnung
  • natural=water + water=river für die Fläche der Minimalausdehnung
  • natural=shingle;rock;gravel;mud;ground oder was auch immer für die nicht immer von Wasser bedeckten Flächen

Nun hätte ich gern noch die passende Definition für “nicht die Maximalausdehnung” oder die Minimalausdehnung…

Landwirtschaft, Tagebaue und Verkehr in Flussbetten habe ich bereits live gesehen. Spuren von beiden Letzteren findest du auch in bzw. in der Nähe des oben verlinkten Flusses.

Im Prinzip ja, nur statt Minimal- die Normalausdehnung während der größten Zeit des Jahres.
Ich gebe zu, dass es genug Flüsse gibt, die ihren Lauf zum Unwillen des Mappers öfters verlegen. Aber die Erdoberfläche (und ihre Abbildung) ist nun mal nicht statisch.

Da könnte ich zurückfragen: Was ist die Definition für Flussbett? Die Fläche, die ein Fluss irgendwann einmal bedeckt hat oder bedecken wird? Im Hochgebirge gibt es kilometerbreite Schotterebenen mit einem Rinnsal in der Mitte. Bei Schneeschmelze schwillt das stark an und schwenkt mal nach links und mal nach rechts. Ist das ein Flussbett? Ein weiteres Extrembeispiel wären Wadis. Ich würde die schon gerne von einem konstant breiten Strom unterscheiden können. waterway=riverbank bietet diese Möglichkeit alleine jedenfalls nicht.

Das optimale Tagging bzw. die unanfechtbare Definition gibt es mMn nicht, auch wenn uns Deutschen das etwas widerstrebt.

Ganz schön pingelig, das Teil.

Etablierte Key-Kombinationen wie highway und railway werden bemängelt, und auch Sammelrelationen (wie 1595756) mag
Osmose anscheinend nicht gern. :slight_smile:

Nichtsdestotrotz ist meine Gemeinde bei unter 5 Fehlern.

Ja, und bei einigen Fehlern/Warnungen würde mir eine bessere Beschreibung dessen wünschen, was denn überhaupt die Ursache ist und wie man es besser macht. Leider weiss ich nur nicht, wohin ich das adressieren soll.

Das einzige was wirklich blöd, aber leider nicht ungerechtfertigt ist, ist das mit Multiple Housenumbers, wenn z.B. das Gebäude mit addr:* und dann auch ein POI darin mit add:* getaggt ist, werde ich wohl alles als falsepositive markieren müssen

Nachdem ich Osmose schon in Nepal genutzt habe, hatte ich jetzt Zeit das Tool mal in Deutschland zu testen.
Es sind schöne Prüfungen dabei, so dass einem nie langweilig wird :slight_smile:
Leider fehlt mir, wie bei Keepright, die Möglichkeit Hinweise für mich dauerhaft auszublenden. Denn unterirdische Kabel werde ich auch in fünf Jahren nicht weiterzeichnen und TMC-Relationen interessieren mich nicht.

Ich habe mir alle Hinweise anzeigen lassen, aber inzwischen die folgenden Prüfroutinen ausgeschaltet:

  • fehlende Tags: Hausnummer doppelt in der Straße
    Es wurde ja schon in anderen Threads erwähnt, dass in Deutschland auch POIs Hausnummern erhalten, was momentan von uns wohl nicht als Fehler angesehen wird.

  • **ungeeignete Tags: ähnliche Werte **
    Ähnlich Werte tauchten bei mir bei Gleisen häufig auf: z.B. railway:signal:combined:states=DE-ESO:hp0;DE-ESO:ks1;DE-ESO:ks2
    Ich denke, dass ist so in Ordnung, deshalb schau ich mir die Hinweise nicht mehr an.

  • ungeeignete Tags: mehrfache Werte
    Durch die Firma Mentz werden viele Treppen und Rolltreppen mit Angaben wie level=0;-1 versehen.
    Mich stört das nicht, so dass ich hier nichts korrigiere.

  • ungeeignete Tags: Fehler bei “lanes”
    Osmose hat wohl Probleme beim Zählen von Lanes. Jedenfalls bringen die Hinweise nichts wenn Fahrradspuren bei turnlanes berücksichtigt werden und bei lanes nicht. Bei Spuren mit backward und forward kommen auch nicht nachvollziehbare Fehlermeldungen.

  • zu entfernende Tags: auf junction=roundabout
    Osmose meckert, wenn Kreisverkehre ein oneway=yes haben.
    Es darf aber laut Wiki gesetzt werden und mich stört es nicht.

  • zur Karte hinzuzufügen: Knoten auf Wegen
    Hier gibt es viele gates etc, die nicht mit Wegen verbunden sind. Man könnte es als Fehler ansehen, aber ich werde mich nicht drum kümmern.

Viele Grüße
Daniel

Es gibt aber leider jede Menge doppelter Hausnummern in derselben Straße, die nicht durch POI Eintrag verursacht werden, einfach weil sich der Mapper vertan hat…
Diese Fehler sollten wir finden und beheben.

Dann sollte aber diese Regel noch besser modifiziert werden, z.B.: nur Nodes/Ways mit addr:* wo nichts anderes dranhängt und/oder zusätzlich building=.
Alle anderen Elemente die addr:
und noch irgendetwas anderes drankleben haben können IMHO ausscheiden.

Tun sie auch nicht. Noch entscheidet nach dem Grundprinzip von OSM der einzelne Mapper, wie er was mappt. Wer sich von keepright, Osmose oder auch von den Fehlermeldungen in JOSM gängeln lässt, muss dass mit sich selbst abmachen. Das Nachdenken ersetzen diese Tools sowieso nicht. Und es war ja auch schon hier die Rede davon, dass die QA-Tools auch eine Menge false positives liefern.

Im Übrigen spricht es wohl für sich, wenn ein Proposal, bei dessen Abstimmung sich ganze 19 Personen beteiligt haben, für das gesamte Tagging weltweit Geltung beanspruchen will. Ich werde es jedenfalls, so wie bisher, ignorieren, weil ich keinen hinreichenden Sinn darin sehe. Außerdem finde ich es mehr als unglücklich, wenn aufgrund so eines Ergebnisses gleich das Wiki geändert wird. Das Wiki sollte allgemeine Überzeugungen/Handhabungen wiedergeben. Und das übliche Tagging drückt sich immer noch in der Häufigkeit der Verwendungen bestimmter key:value-Kombinationen bis bestimmte Objekte aus.

Keine Frage, das seh ich auch so.
Im Moment ist für mich Osmose für diesen Zweck das falsche Tool.

Osmose hat jetzt (mindestens) eine neue Prüfung: Missing access to highway (z.B. http://www.openstreetmap.org/way/303964944)). Es geht wohl darum, das ein Parkplatz mit highway verbunden sein sollte?!

Hab ich auch schon festgestellt, aber großteils ignoriert. Es macht einfach keinen Sinn jede kleine Parkbucht am Straßenrand mit einem extra Zufahrtsweg zu verbinden oder an die Straße zu “pappen”.

Könnte man aber wohl machen … so zumindest eine mögliche Antwort auf meine Frage indention behind 3161 parking lane ‘missing access to parking’

Die Parkbucht sollte auch eher mit http://wiki.openstreetmap.org/wiki/Key:parking:lane getaggt werden.