Exzessives Micromapping mit natural=cliff

Ich bin durch den Hinweis eines Kartennutzers, die Karte sei in der Sächsischen Schweiz völlig unbrauchbar auf den folgenden Fall von exzessivem Micromapping gestoßen.

Das Ganze wurde letzten Monat auch schon mal diskutiert, aber IMHO nur unzureichend.

Hier hat sich jemand sehr viele Mühe gemacht, jeden einzelnen Felsturm und Felsvorsprung in der Gegend einzeln vom Höhenmodell abzumalen. Leider ist alles mit demselben Tag natural=cliff getaggt. Ein kleiner Felsturm ist für mich aber ein völlig anderes Objekt als eine 200m Klippe. Generell halte ich es für falsch, Tags für große Dinge unbesehen für Micromapping zu verwenden, dabei geht meistens etwas kaputt.

Ich denke was hier fehlt ist ein zweites Tag für Micromapping, so ähnlich wie place=island für große Inseln und place=islet für kleine Steinhäufchen.

In der gegenwärtigen Form hat ein Datennutzer oder Kartenerzeuger keinerlei Unterscheidungsmerkmal um sinnvolle Zoomlevel dafür einzustellen und dieses hingebungsvolle Micromapping hat eher einen negativen und ärgerlichen Effekt.

ich verstehe nicht, wieso man für zerklüftetes Gelände andere tags verwenden sollte, sobald es irgendwo ein paar Meter senkrecht nach unten geht ist das bei mir entweder retaining wall oder cliff, je nach Herkunft und Struktur, aber unabhängig von der Ausdehnung

Ich glaube, das ist vor einiger Zeit in Hinblick auf Monster-MP’s beziehungsweise den (technischen) Grenzen in Hinblick auch Anzahl von Relationsmitgliedern angerissen worden. Ich finde den Faden aber auf die Schnelle nicht.

Ich habe zwar vor wenigen Tagen in der Ecke einen Geometriefehler beseitigt: https://www.openstreetmap.org/changeset/75168886#map=18/50.89843/14.02993&layers=N natural=cliff war da aber meines Erachtens nicht maßgebend…

Ich bin kein "Gebirge"Mapper… aber nach meinem Gefühl würde ich grundsätzlich erst mal natural=rock|bare_rock für passender halten. Der Tag natural=cliff passt meinem Gefühl nach nicht, denn es sind dort in der Regel keine längeren Felskanten (“Abbruchkanten”), sondern es sind einzelne herausragende kleinere und größere Felsen… Auch jeden als inner auszuschnippeln halte ich für disskussionswürdig, da nur das geringste luftbildsichtbar ist. Kurz: ich tendiere zu Mappen für den Renderer…

Allgemein aber ist der Zugriff und der OSM-lizenzkonforme Zugriff z.B. auf DGM1-Daten in dem Beispiel hier Fluch und Segen zugleich…
Segen: man kann z.B. Bahndämme oder Schutzdeiche exellent indentifizieren…
Fluch: es eröffnet einem ungeahnte Möglichkeiten des Micromappings…

:expressionless:

Sven

Der einfachste Weg OSM zu schaden wäre: Alle Daten freizugeben. Dann würde über kurz oder lang der abgezeichnete/importierte Datenbestand nur noch für Detailkarten im Maßstab 1:100 brauchbar sein…

siehe:

@Nop: Etwas mühsam, aber vielleicht könnte die Länge der cliff-ways ein Kriterium sein? (Daten-Nutzerfreundlich ist das aber nicht.)

Die Taggingschemen waren nicht für Micromapping gedacht. Und die Micromapper haben sich einfach der etablierten Tags bedient, weil es gerendert wurde.
Ein frühes Beispiel war die Umdeutung/Umnutzung des natural=tree (bedeutende Bäume für Topographische Karten) für jegliche Art von Baum.
Mittlerweile werden auch Fahrradabstellplätze vor Privathäusern mit amenity erfasst und damit zunehmend für den OSM-Normalnutzer irrelevant. Beispiel: https://www.openstreetmap.org/note/1937384#map=19/49.45855/11.08315
Ähnliches passiert mit dem “Missbrauch” von amenity=parking, für Längsparkstreifen an normalen Straßen.
Und in Wüsten wird jede Rinne, die einmal in zwei Jahren kurz Wasser führt als Bach/Fluss eingetragen, so dass man mancherorts ein dichteres Gewässersystem als im Regenwald zu haben scheint.
Dem Namen nach ist das ja nicht alles falsch. Man kann faktisch aber eben nur keine Übersichtskarten mehr herstellen. Oder der Normalnutzer braucht eine Großrechenanlage und viiiel Zeit für die Renderregeln, um sich eine eigene Karte zu machen.

Das Dilemma ist: Wenn man jetzt fordert, dass das Problem jeweils durch Zusatztags wieder gelöst wird und sich der Renderer z.B. entschließt, den Fahrradstellplatz mit access=private nicht mehr darzustellen, dann werden die Mapper das access einfach weglassen. Wenn der Renderer nur noch Fahrradstellplätze mit access=* darstellt, dann werden massenhaft Altdaten entwertet etc. :frowning:

Jetz könnte man an diesem Beispiel (cliff) fordern, der Mapper möge jeweils die maximale Höhe des Kliffs erfassen. Das kann/will aber keiner machen. Problem theoretisch gelöst. Daten weniger Wert.

Quo vadis OSM?

Da ich im April von genau diesem Micromapping im NP Sächsische Schweiz profitiert habe, muss ich einen Kommentar dazu abgeben: Ich kann die Ansicht nicht unterstützen, dass solche Daten zu unbrauchbaren Karten führen. Vielleicht liegt es an der Darstellung im großen Maßstab, die bei manchem Betrachter Konfusion hervorruft.

Schon bei der Planung meiner Touren war mir die Standardkarte eine große Hilfe. Gerade im Carto-Stil konnte ich nach einer kleinen Einlesezeit die Karte gut interpretieren. So ist ein cliff für mich eine ohne Hilfsmittel nicht überwindbare Barriere, egal ob 5m oder 50m, ein bare_rock mit einem cliff-Rand drumherum einer der typischen Säulenfelsen.

Als ich dann vor Ort und mit Osmand unterwegs war, konnte ich genau sehen, wo z.B. ein bewaldetes Plateau war, das man nur über einen Zugang erreichen konnte. Ich war begeistert von der Detail-Genauigkeit und selbst bei Abschattungen in Schluchten konnte ich mit dem Handy meinen Standort jederzeit genau lokalisieren und hatte ein Höhenmodell, ohne SRTM, das dort fast nutzlos ist. Sogar Einheimischen auf der verzeifelten Suche nach dem Weg zur “Lokomotive” konnte ich helfen und die zunächst skeptischen Männer mit OSM beeindrucken. War echt lustig. Für die vielen Kletterer und Boofer sind diese Daten vermutlich auch hilfreich.

Ich bedanke mich hiermit vielmals für die geleistete Arbeit aller Mapper im Elbsandsteingebirge und stelle mal die Frage, ob es Kritiker mit Ortskenntnis gibt, die auf diese Daten tatsächlich verzichten möchten? Oder ob es mehr eine Frage des Geschmacks ist, denn ich gebe zu, dass auch ich beim ersten Zoom auf die Region von der ungewohnen Optik überrascht war. Die Landschaft ist halt aber einzigartig und somit auch das Aussehen der Karte in diesem Landstrich.

Gruß, Cepesko

Die Kritik ist nicht, dass es detaillierte Daten gibt, sondern dass es keine Unterscheidungsmöglichkeit für unterschiedliche Zoomlevels gibt. Wenn jemand jeden Hydranten erfassen will - meinetwegen. Wenn aber jeder Hügel als Gebirgsgipfel (siehe https://www.openstreetmap.org/node/1786592668 ) erfasst wird, dann wird es halt irgendwann schwierig.

natural=peak ist halt nicht nur ein „Gebirgsgipfel“ und dafür gibt es auch schon tags wie isolation, prominence und ele. Dass die cliffs in den meisten zoomstufen nicht gut aussehen wenn sie kurz sind und dicht stehen, das müsste man auf Seite der Renderer angehen, wenn es einem das wert ist, weil es nicht sehr viele ähnliche Stellen gibt, die auch noch eine ausreichende Mapperdichte aufweisen. Vom detaillierten in einen gröberen Maßstab generalisieren sollte jedenfalls zumindest theoretisch möglich sein (Menschen können das), anders rum geht es nicht.

+1. Es ist nicht „sträflich“, jede natürliche Abbruchkante als natural=cliff zu erfassen, mag sie nun 2 oder 20 m hoch sein. Ab einer gewissen Dichte müssen Renderer das entweder sortieren oder sich zur Nicht-mehr-Darstellung entscheiden.

Ob wir allerdings /das/ zum Kriterium machen sollten … :smiley: „hier ist hohe Mapperdichte, fahr mal die Details auf minus drei!“

–ks

Für cliff braucht es mMn keine längere Kante - Hauptsache es geht (fast) senkrecht etliche Meter nach unten, d.h. es ist eine Gefahrenstelle.
bare_rock ist ein Flächentag, das sollte im Luftbild gut sichtbar sein, es kann im Gegensatz zu rock völlig eben sein.

Das Detaillierungsproblem sehe ich nicht anders als z.B. in Städten, da kann man je nach Zoomlevel auch nicht jedes Haus rendern.
Da muss der Renderer auch abhängig vom Maßstab generalisieren.

Ob es sinnvoll ist, wie z.B. am Lilienstein alle paar Meter eine parallele Klifflinie zu ziehen, da kann man geteilter Meinung sein.
Auf jeden Fall sollten solche Linien nur bei extremem Zoom gerendert werden, auf “Wandermaßstab” sollte da nur eine Linie sein, genauso wie man in Städten Häuser zu Blocks zusammenfasst und kleinere Gässchen weg lässt.

Das Hauptproblem bei der momentanen Darstellung scheint mir zu sein, dass die Renderer (zumindest die vier aus #1) Klifflinien noch nicht als Generalisierungskandidaten vorsehen. Ob sie den Aufwand dafür für vertretbar halten, da die Sächsische Schweiz schon ein sehr spezielles Gebiet ist, ist wieder ein anderes Thema.

Welcher Detaillierungsgrad für OSM weltweit tragbar ist, ist nicht einfach zu entscheiden. Gemappt werden kann eben alles, was “da” ist. Begrenzender Faktor ist zur Zeit nur die Manpower der Mapper, die bekanntermaßen sehr ungleich verteilt sind und sehr unterschiedliche Interessen haben.

Aufgrund der Erfassungsdichte von Klippen in der Sächsischen Schweiz, wurde die entsprechende Darstellung in der FZK-Android vor Kurzem angepasst. Klippen werden jetzt weniger dominant dargestellt. Die Datenlage dort fand ich sehr informativ.

Mein Punkt ist genau der: Es gibt kein Kriterium, um einen passenden Zoomlevel zu setzen. Alle diese cliffs sind gleich getaggt.

Wir hatten ähnliche Probleme auch schon mit historic=castle, das an jedem Gebäude und jedem Turm nochmal extra gesetzt wurde, was zu einem Dutzend Burgen innerhalb derselben Anlage führte. Das wurde glaub ich mit building:part gelöst.

Ebenso sind winzige Erhebungen im Wasser als islet getaggt, nicht als island. Wenn das falsch gemacht wird werden sie sonst überall prominent mit Namen gerendert.

Selbes Problem mit Gipfeln, da wurde glaub ich über ein Zusatztag “prominence” diskutiert.

Kleine Simse innerhalb einer größeren Felswand sollten deshalb nicht als “cliff” getaggt werden. Sie sollten entweder ersatzweise oder zusätzlich mit speziellen Tags wie “ledge” oder “rock_tower” oder sowas beschrieben werden.

Dann wäre eine sinnvolle Auswertung und Anzeige wieder möglich.

Sowohl das deutsche als auch das englische Wiki https://wiki.openstreetmap.org/wiki/Tag:natural%3Dcliff beschreiben als eines der wenigen Zusatztags “height”, das auch schon bei über 3000 cliffs verwendet wird.
Dies erscheint mir ein sinnvoller, einfach zu verstehender Zusatz, der in Kombination mit der Cliff-Länge eine "Bedeutungs-"Filterung erlauben sollte.

Ja, die Gegend sieht in den Karten ziemlich gruselig aus, aber eigentlich kann man an der Verwendung von Cliff nicht viel aussetzen… Die parallelen Klippen, die seichter in #9 erwähnt, scheinen mir falsch, irgendwie siehts aus als wäre das sowas wie ein Ersatz für Höhenlinien. (Sowas haben wir auch in anderen Gegenden auch, nur nicht so gehäuft wie in der Sächsischen Schweiz).

Denk auch, das wäre der richtige Ansatz, falls man da was filtern wollte. Funktioniert aber erst gut, wenn height=* auch häufig genug verwendet wird, weil man weiss nicht, was man bis dahin mit Klippen ohne dieses Tag machen soll.

Die Opentopomap sortiert Gipfel nach berechneter Dominanz. Funktioniert in der Sächsischen Schweiz aber nicht, weil so kleine und dicht zusammenstehende Gipfelchen fallen durchs Raster der Höhendaten und eine hilfreiches ele=* haben die Gipfel dort nicht. Würde hier aber auch dann nicht funktionieren, ab irgendeinem Zoomlevel möchte man ja schon alle Gipfel anzeigen und wenn die Berge dort in 20 Meter Abstand stehen müsste man ein paar Zoomlevel mehr haben um so kleine Dominanzen sinnvoll auszuwerten…

Grüße
Max

die tags sind gleich, aber die Geometrie kann man trotzdem analysieren. Es gibt viele Features, die in bestimmten Situationen nicht optimal dargestellt werden, das wird im Laufe der Zeit vermutlich aber besser werden (durch automatische Verfahren zur Generalisierung und grundsätzlich durch wachsende Rechenleistung, die solche Verfahren anwendbar macht auch im globalen Maßstab). Wenn ein cliff nur wenige Meter lang ist, dann will man es vielleicht in z12 gar nicht sehen, während ein kilometerlanges schon früher gerendert werden sollte, oder wenn viele Kanten parallel oder fast parallel verlaufen dann will man sie in größeren Maßstäben (kleineren Zoomleveln) eigentlich zusammenfassen.

das ist m.E. kein “ähnliches” Problem, sondern ein anderes, vergleichbar etwa mit Schulen und Krankenhäusern, wo man nicht jedes Gebäude auf einem gemeinsamen Areal als eigene Schule oder Krankenhaus mappen sollte, es aber gelegentlich gemacht wird. Natural=cliff beschreibt eine felsige Geländekante, normalerweise kein Feature wie natural=tree oder peak oder z.B. eine Düne. Man kann einen natural=cliff-way splitten und es ändert sich nichts an der Karte, ähnlich wie bei einem highway=*
Das sind keine “zählbaren” Features wie Schulen, Gipfel und Krankenhäuser.

AFAIK geht es nicht um die Größe der Erhebung sondern nur um den Teil, der aus dem Wasser ragt. Eine genaue Abgrenzung gibt es dafür aber glaube ich nicht. Besonders konsequent ist

Das würde es einfacher machen, aber eine sinnvolle Auswertung wäre jetzt auch schon möglich, müsste man halt machen, und ist je nach Anspruch ans Ergebnis nicht trivial. Einen neuen tag könnte man natürlich auch versuchen einzuführen. Als erstes müsste man da mal überlegen, was die Kriterien sind, die könnte man in einem Proposal diskutieren und dann sehen, ob es angenommen wird.

Könnte man nicht height oder so an cliffs taggen? Renderer können dann ne nach height die cliffs früher oder später anzeigen.

Danke dafür. Das ist genau das, wo mir persönlich z.B. die Erfahrung fehlt, wie welches Landschaftselement im Bergland zu interpretieren ist… Darum bin ich da auch vorsichtig, auch mit der Bewertung. Eine durchschnittliche Angabe der height wie es westnordost vorschlägt, wäre eine äußerst gute Ergänzung. Sven

*height *halte ich für ein nur mäßig gutes Kriterium:
Eine 5 m hohe Abbruchkante über einem Fluss wäre für mich für wichtig.
Eine Klifflinie der Höhe 50, die direkt neben einer zweiten höchstens einen Standplatz für Kletterer markiert, kann eher wegfallen.

Eine Hilfe für das Rendern könnte sein, wenn der Fels konsequent als natural=rock gemappt würde, und zwar von unten bis an die Klifflinie, so wie man das senkrecht von oben sieht. Die meisten Felsen fallen ja nicht genau senkrecht ab, Überhänge lassen wir mal lieber aus dem Spiel.
Dann hätten Klifflinien zwischen rock-Flächen eine geringere Priorität.

Das natural=bare_rock würde ich lieber für die Felsköpfe nehmen, die ja oft von einer Seite aus eben erreichbar sind und in Wiese oder Wald übergehen.

Das halte ich für leicht dahingesagt, aber fachlich absolut falsch.

Schau Dir bitte mal beispielhaft diesen zufällig gewählten Ausschnitt an und sage mir, welche der meist 5 parallelen Linien Du früher anzeigen oder zu einer zusammenfassen würdest oder wo mehrere dargestellt werden müssen. Und erkläre nach welchen automatisch programmierbaren Kriterien Du das tust.

Ich behaupte: Nicht mal als Mensch kannst Du ohne weitere Informationen eine sinnvolle Einordnung vornehmen - geschweige denn automatisch.

Abgesehen davon sind alle solchen Auswertungen nur “geraten” und fehlerbehaftet. Nur der Mapper weiß, was er da gemappt hat, was seine Absicht dabei war und welche der vielen parallelen Linien wirklich einer Makro-Felswand entspricht und früher dargestellt werden sollte und was Micromapping für hohe Zoomlevel ist. Wenn das nicht durch Tags ausgedrückt wird, ist eine sinnvolle Weiterverarbeitung nicht möglich.

Wenn irgendwo das Micromapping eines neuen Themas beginnt, werden auch neue Tags benötigt. Einfach ein Makro-Tag für Micromapping zu verwenden, ist dasselbe wie Tagging für den Renderer mit Tags, die für andere Zwecke vorgesehen waren.

als erstes müsste man festlegen für welchen Maßstab man optimieren will, erst dann kann man überhaupt sinnvoll anfangen nachzudenken was Information ist, und was nur noch Rauschen.

Dein Linienstil („Kreuzstich“) für cliff ist jedenfalls dazu geeignet, die Unruhe zu verstärken und schon viel früher als bei einfachen Linien einen unübersichtlichen Brei zu generieren, weil er von der Hauptrichtung des cliff ablenkt

Der Kartenstil hat nichts mit dem Grundproblem der fehlenden Differenzierungsmöglichkeit zu tun, deshalb habe ich in meinem ersten Post auch bewußt Mapcompare verlinkt mit dem Salat auf allen Topokarten.

Bitte versuche nicht das Thema zu wechseln sondern begründe Deine Aussage daß es “jetzt auch schon möglich sei” und erkläre nach welchen Kriterien Du eine Unterscheidung durchführen könntest. Nehmen wir an für z13 und z15.