Uferbereich mit Wasserbausteinen mappen

versucht. wird nicht gerendert. Macht also meiner Meinung nach keinen Sinn auf ein “falsches” neues natural Tag als Notlösung auszuweichen, statt dann gleich das “richtigere” angedachte man_made=waterside_lining (ö.ä) zu taggen, wenn beides ohnehin nicht angezeigt würde…

Und genau da liegt mein Problem. So komisch das vielleicht für Einige hier klingen mag. Ich mappe in diesem Fall tatsächlich auch, um am Ende meinen Angelkollegen mal was Konkretes auf der Karte anzeigen zu können. :wink:
Hintergrund ist auch, dass ich die Karten dann auch für künftige Gewässerprofile dieser Machart heranziehen möchte:
http://www.angelwahn.de/oyter-see/
Um letztlich auf diese Weise auch meine selbst erstellten Tiefenkarten über dieses Gewässerprofil teilen zu können.

Werde daher wohl dem Rat von maxbe und geri-oc folgen und vorerst „scree“ als einzige, renderfähige Notvariante nehmen und das dann per „fixme“ auch als Notlösung kennzeichnen. Devise: Richtig erfasste Umrisse der Steinschüttung mit „falschen“ Steinen gefüllt sind hier immer noch besser als nichts oder einfach die angrenzende Kuhweide zum Ufer ziehen, wie es auch oft praktiziert wird.
Schnell umtaggen kann man dann ja immer noch, wenn ein eventuelles Proposal mal durchkommt.

Hätte jemand Erfahrenes evtl . Lust mal so etwas anstoßen? … Hab wie gesagt nicht so den tiefen Einblick in das Procedere und kann ehrlich gesagt auch besser Tiefenkarten machen als englisch schreiben. :wink:

Tut mir leid, aber ich muss die Party stören: das, was du da vorschlägst, ist reines “tagging for the renderer”. Du findest das natural=scree auf dem standard-mapnik schön aussieht, und daher willst du es nutzen, egal was das tag besagt.

Ich bin voll dafür diese Böschungsflächen zu erfassen, aber mit einem korrekten, noch zu diskutierendem Tag (ich fand die man_made=… Ideen die hier im thread kamen bisher ganz gut)

Mach dir doch deine eigene Angelkarte! Da kannst du beliebige Tags rendern, ganz so wie du das willst, und müllst die Datenbank nicht mit irgendwelchen “sieht auf einer speziellen Karte schön aus”-Konstrukten zu.

Mit tilemill soll das auch sehr einfach gehen, eigene Kartenstile zu kreieren.

Ich verstehe ja deinen Wunsch diesse Böschungen auf “der” Karte sichtbar zu haben (ich finde das auch gut und würde das unterstützen!), aber bitte nicht so!

dann sollte aber auch natural=scree entsprechend spezifiziert werden, daß das nicht bei künstlichen Steinschüttungen an Gewässerufer anzuwenden ist. Das geht aus der Definition von natural=scree nicht hervor.

Sven

Ob nun natural oder man_made - m.E geht es immer um scree (kantige Bruchsteine - eine Masse von kleinen losen Steinen).
Was ist der Unterschied von natürlicher oder künstlicher Ablagerung?
natural=beach ist ein Strand - oft künstlich aufgeschüttet/aufgespült oder darf nur natürlicher Sandstrand Beach sein?

Eventuell könntest du einmal beim Forum OpenSeaMap fragen, da diese auch die Flüsse integrieren (Seezeichen, Wassertiefen, …).
http://forum.openseamap.org/index.php

Ob ein Sandstrand aufgeschüttet oder natürlich ist, sehe ich ihm nachher nicht an,
den Unterschied zwischen einem Geröllfeld und einer Uferbepflasterung sehr wohl.
Das kommt mir so vor, als ob man eine Mole mit natural=cliff mappt.

“die durch Felsstürze, Steinschlag und Verwitterung entstehen” bzw. “formed by rockfall” sollte doch eigentlich reichen.

@Angelwahn: Das verpönte “mapping for the renderer” meint, dass man willentlich falsch mappt, um ein bestimmtes Aussehen (meist in der Standardkarte) zu erzeugen. “natural=scree” halte ich in diesem Fall für sehr grenzwertig.
Es müsste doch elegantere Lösungen geben als eine Krücke mit scree und FIXME/note. Da hoffe ich auf hilfreiche Kollegen mit Erfahrung bei der Erzeugung von Spezialkarten.

Wo es geht, halte ich mich auch lieber an die Vorgaben und versuche da sehr konform zu bleiben. Daher bin ich bestimmt kein Freiwilliger, der hier nur mitmappt,weil es einfach nur “schön” aussieht. Wozu ich aber stehe, das ich hier AUCH versuche eine praktikable Zwischenlösung aus einer sonst ziemlich unerschlossenen Sitution zu finden. Finds auch keineswegs verwerflich im Zweifel die Anwender im Blick zu halten. :wink:

Und da sehe ich es im konkreten Fall auch so wie geri-oc. Es geht hier nur darum, wie die gleichen Steine zum Ufer gelangt sind. Meiner Meinung nach die bessere Wahl als jetzt einfach hier z.b. mit frei erfundenen, vom Status noch unakzeptierten, man_made=values den Code noch weiter zu divergieren, bis eine einheitliche Lösung gefunden ist. Da halte ich hier das scree im ständigen Spannungsfeld zwischen praxisnahen Ergebnissen für die Anwender und schönen Code für…(ja für wen eigentlich?) für verantwortbar. Zur weiteren Beruhigung der Situation: Habs auch im Blick und zur regelmäßigen Prüfung auf meiner ToDo-List, werde meine Einträge dann natürlich sofort umtaggen, wenn sich da was Treffenderes ergibt. EDIT: Posting eben überschnitten mit Seichters: Klar wenn sich noch was ergibt wäre das Klasse! :slight_smile:

Und danke für den Openseamap-Tipp, geri-oc. Hab da schon vor einiger Zeit meine Echolottracks gespendet…Leider gibts bei dem Projekt noch den ungelösten Punkt, der der einheitlichen Pegelnahme in Nebengewässern um die verschiedenen Tiefendatenspenden bei unterschiedlichen Wasserständen auf “Normalnull” zu normieren. Hatte das auch schon mit dem Initiator Markus Bärlocher in nettem Emailkontakt beschnackt… M.M.n. muss dieser Punkt erst gelöst werden, bevor man hier richtig “Gas geben” kann. Muss aber auch da mal wieder vorbeischauen, was sich mittlerweile getan hat :slight_smile:

Um die Diskussion von der Zwischenlösung zum ursächlichen Problem zu lenken – was (hoffentlich) am Ende in ein Proposal mündet:

Man könnte sonst auch versuchen den value “armourstones” für Wasserbausteine aufnehmen zu lassen.

Ob nun direkt als “kleine” Lösung man_made=amourstones
oder als Zusatztag für den aufgeworfenen (noch auszuarbeitenden) Vorschlag der Möglichkeit die Gefällerichtung einzugeben bei gleichzeitigem Flächeneinsatz:
x=y
material / surface=amourstones

Ich würde den Ansatz nicht so eng machen. Schließlich dienen Wasserbausteine der Uferbefestigung: “bank stabilisation”

So könnte man man_made=bank_stabilisation + material=amourstones ; dann hätten auch meine Faschienen Platz: material=fascine

material=fascine wäre nur als Linie möglich
material=amourstones als Fläche und (für kleinere Dinge, wie bei und im Spreewald) als Linie.

Vielleicht mag das einer auch eher im waterway-Bereich… Ich denke aber man_made ist in Ordnung.

Sven

klingt doch nach einem Plan… :slight_smile:

EDIT: Spundwände (sheet_piling?) wären auch diese Weise auch gleich abgedeckt.
Bisher wenn überhaupt hier nur retaining_wal und material=metal als “gehhilfe” möglich…

EDIT2: —und dieses Ding hier könnte man auch endlich vernünftig taggen:
http://binged.it/1YimUjb

man_made=bank_stabilisation
material=concrete

Ich tendiere auch dazu, die top-level values möglichst allgemein zu machen und Verfeinerungen in material, surface etc. zu stecken.
Stabilisierung ist mir dabei schon etwas zu eingeengt, ich würde so was wie man_made=bank_structure vorziehen, um möglichst viel abzudecken.

Da die Angler ja wohl nur die letzten Meter am Wasser interessieren, würde ich mir überlegen, ob nicht doch etliche Gewässerkilometer als Linie mit man_made=embankment + div. subtags gemappt werden können.

Du meinst als pure Linie? Dürfte echt schwierig werden.
Schaul mal hier, nicht selten, dass es am Ufer so aussieht:

http://binged.it/1MWvsIP

Die eigentliche Böschung mündet in Buhnen, diese wiederum sind teils mit Buschen bewachsen manche davon beweidet und einige Buhen werden wiederum noch von Wasserbausteinen umsäumt (sieht man wenn man reinzoomt) und manchmal ist eben auch nur Flußsand (insbesondere in den Buhnenfeldern) vorhanden. Das checke ich aber meistens vorort und tagge nach Geofotos.
Alles zusammen stellt dann die Böschung dar. Ich bekomme jetzt schon Zahnschmerzen wenn das alles igendwie in eine Linie “eingebaut” werden soll. Ich tendiere daher mehr zur vorgeschlagenen Flächenlösung welcher Oberkategorisierungsweite auch immer.

Das funktioniert nicht. Diverse (ausgebaute) Gewässer haben einerseits paralle begleitende embankments und andererseits trotzdem befestigte Uferkanten. Dazwischen oft mehrere Meiter (10/15/20 Meter) Ufervorland…

Mit einen noch gröberen Beginn (man_made=bank_structure) kann ich mich gut anfreunden. Als wichtig und unerläßlich halte ich es trotzdem je nach subtag Linie, als auch Fläche zuzulassen.

Aber eine eventuelle Gefällerichtung lässt sich nicht ohne weiteres erfassen. OSM kennt ja nicht mal den realen Flächendatentyp. Eine auch auf der z-Ebene gerichtete Fläche lässt sich erst recht nicht umsetzen, dazu fehlt OSM grundsätzlich eine regelmäßige Höheninformation.

Sven

Solange das nur für Uferbefestigungen verwendet wird, fände ich das jetzt nicht tragisch. In so einem Fall lässt sich das aus einem Kartenbild (“blau ist unten”) entnehmen und andere Auswertungen kämen auch klar: Der Satz “Du musst da rüber schwimmen und dann über die Uferbefestigung” wäre für mich auch ohne “hoch” oder “runter” interpretierbar und ich wüsste, in welcher Richtung ich über die Steine krabbeln muss :wink:

Am Nordufer geht es nicht, aber am Südufer ginge es mMn schon.
Das hängt aber nicht unerheblich davon ab, wie genau man mappen will. Wenn man auf Meter-Genauigkeit heruntergeht, wird man praktisch immer bei Flächen landen (siehe Straßen). Die Erfassung auch nur eines Flussufers artet dann halt in ziemliche Arbeit aus.

Ok, ab sofort werden dann nur noch Südufer erfasst. :wink:

Ernsthaft: Detailmapping an Ufern wäre schon wichtig für den Boots- und anderen Wassersport. Es wird mit deiner Lösung nur der Gefällefunktion wegen leider sehr schwer sein (wenn nicht sogar praktisch unmöglich sein) die Realität abzubilden und sollte vielleicht noch mal gegen die anderen Lösungen abgewogen werden.

Die Gefällefunktion wäre nur ein optionales Feature zum Flächenmapping dazu. Das kam überhaupt nur auf wegen der rechts-runter-Regel bei embankment-Linien, hat aber mit der key=value-Diskussion nichts zu tun.