Mammi71
(One feature, Six mappers and still More ways to map it)
41
Wenn der “Hafen” nur aus der Kaimauer an einer Seite des Kanals besteht gebe ich pyram recht. Hafendetails können dann ggf. auch an die Kaimauer getaggt werden, soweit möglich und nötig oder als eigenen Poi.
Sind ansonsten an der Wasserfläche keine anderen Tags als am Kanal selbst auch, ist ein Unterteilen der Wasserfläche nicht erforderlich, aber auch nicht schädlich. Je nach Umfang und Detailgrad sollte die Wasserfläche dann unterteilt werden, wenn die Zahl der Punkte des Umrisses sich langsam an die 2000 nähert. Die Aufteilung hat dann technische Gründe und kann dann wie bei Flüssen recht willkürlich erfolgen. Ich mach das meist im Bereich von Wehren und/oder Brücken, sofern sich nicht gerade Schleusen anbieten. Letzteres wäre vorzuziehen (und am LMDK gibt es genügend davon), da das Schleusenbecken als separate Wasserfläche getaggt werden kann.
Solange ein Kanalabschnitt noch wasserführend ist würde ich kein lifecycle-prefix verwenden. Das disused empfinde ich recht irreführend. Mühlkanäle setzen wir auch nicht auf disused, nur weil die Mühle nicht mehr in Betrieb ist.
Beachte auch den letzten Satz im Wiki:
Wenn ein stillgelegter („disused“) oder aufgelassener („abandoned“) Kanal kartiert wird, können so die trockenliegenden Bereiche kartiert werden. Die Abschnitte, die wasserführend sind, werden dann mit waterway=canal kartiert.
Mammi71
(One feature, Six mappers and still More ways to map it)
Split this topic
42
Bei 3. die Nachfrage: Kann über Abfragen der Datenbank (z.B. overpass-turbo) die gleiche Info gezogen werden, die jetzt in den Relationen steckt?
Wenn ja, gibt es von mir einen fetten dritten Daumen, weil die Relationen dann die Karte unnötig kompliziert machen.
Ich hatte sowieso schon den Gedanken, die Info, dass die Teile heute und ggf. früher direkten(!) Bezug zum LDMK hatten, mindestens in note oder gar in description reinkommen sollen.
Nicht nur aber auch wegen der Wiederfindbarkeit via DB-Abfrage.
Nur mal allgemein zur Info.
Ich habe vor, die Tags immer nur in (in sich konsistente) Tag-Gruppen zu ändern mit Fokus auf Einheitlichkeit, damit die Bearbeitungen/Changesets klein und übersichtlich bleiben.
In der ersten Gruppe sind/werden alle name und description Tags in einem Rutsch geändert (auch so bei Anlegestellen, Schleusen, Schleusenwärterhäuser usw.).
Dann folgen folgen die Gruppen (hier nur auszugsweise und nicht sortiert/priorisiert):
alle feature-Tags
alle wiki-Tags
alle zu historic gehörenden Tags
alle tourism-Tags, sofern relevant
Denkmalschutz-Tags
Beispiel: Beim Denkmalschutz ist es einfacher und birgt weniger Fehlerquellen, gleich alle zu einem Abschnitt bzw. einer Anlegestelle gehörenden Tags (Schleuse, Krane, Schleusenwärterhäuser) in einem Rutsch zu ändern.
Insofern starte ich deswegen mit der Vereinheitlichung der name und description Tags, damit ich und z.B. auch ein OsmAnd-Nutzer diese als primären Schlüssel für die Query verwenden können.
Z.B. mit der Query nwr[description~"Ludwig-Donau-Main-Kanal"][man_made=crane]; bekommt man alle Krane.
Oder mit der Query nwr[description~"Alter Kanalhafen Kelheim, Ludwig-Donau-Main-Kanal"]; bekommt man alle Objekte vom Kanalhafen Kelheim.
Momentan arbeite ich noch mit folgender Query, damit ich überhaupt alles erwischen kann aufgrund uneinheitlicher Tag-Verwendungen und Schreibweisen: nwr[name~"Ludwig-Donau-Main-Kanal|Ludwigskanal|Alter Kanal|LDMK"]; nwr[description~"Ludwig-Donau-Main-Kanal|Ludwigskanal|Alter Kanal|LDMK"]; nwr[note~"Ludwig-Donau-Main-Kanal|Ludwigskanal|Alter Kanal|LDMK"];
Persönlich sind mir objektbezogene Änderungen lieber. Da ist dann die Änderungshistorie übersichtlicher.
Das wird auf Dauer so nicht funktionieren, da andere Mapper sich nicht an “Deine” Regeln halten werden. Die kennen die schlicht nicht.
Sinnvoller sind räumliche Abfragen, wie zum Beispiel around .
Ich würde außerdem material=metal angeben. Dann ist auch der Information aus dem vorherigen name=Eisenkran Rechnung getragen.
sofern Eisenkran sich auf das Material des Krans bezieht (wobei das eher Stahl sein dürfte) und nicht darauf dass er für das Bewegen von Eisen benutzt wurde. Im zweiten Fall ist name auch gar nicht zwangsläufig falsch
Ja, mir eigentlich auch, aber ich habe auch schon die Erfahrung gemacht, dass mir bei der Vielzahl der Objekte (ca. 60 Schleusen) doch mal ein Tag durch die Lappen geht.
Und wenn ich z.B. alle Schleusen vollumfänglich mit allen Tags pflegen wollte, dannn brauche ich Tage (inkl. der Recherchen für z.B. Wiki- und Denkmal-Tags) und es gäbe Monster-Changesets, dessen Review auch entsprechend groß wären.
Also aufgeblähte history m.M.n. das kleinere Übel…
Ja, auch das ist mir klar, so naiv bin ich nicht…
Aber ich halte das für jetzt bei der Bearbeitung und nur für den LDMK im Ganzen für sinnvoll.
Einen größeren Fokus habe ich nicht und es hilft mir den LDMK-Molloch zu bearbeiten und Euch zu “query-en”.
Es ist damit auch klar, warum der Kollege, dessen Namen nicht genannt werden soll, die vielen Sammel-Relationen geschaffen hat.
Einfach damit er die Million Teile des Kanals organisiert wiederfinden und editieren kann.
Ich habe schon mehrfach in JOSM die 172 km Kanal hoch und runter gescrollt und kann berichten: ES MACHT KEIN SPASS
Schon oben diskutiert.
Habe ich geprüft, Eisenkran ist kein Eigenname oder historisch belegt als Name, sondern eher mundartlich bzw. beschreibend für das Material, aus dem das Teil besteht.
Ggf. wäre sowas wie Gusseisen besser, aber dessen Quellen-Prüfung sehe ich nicht so hoch-prior.
Deswegen wollte ich ursprünglich material ganz weglassen…
Ansonsten, wenn wir schon beim Thema sind…
Allgemein würde ich name eher zurückhaltend füllen wollen, außer es handelt es sich um dokumentierte Eigennamen (keine Phantasienamen @pyram) oder es handelt sich um einen Ort mit mehreren Objekten (z.B. Alter Kanalhafen in Kelheim).
Bei letzterem würde ich nur das sinnvolle bzw. größte Objekt mit name taggen, also am Beispiel nur die Wasserfläche in Kelheim.
description=Alter Kanalhafen Kelheim, Ludwig-Donau-Main-Kanal
Hier alle Infos kurz und knackig rein, aber auch “Kelheim, Ludwig-Donau-Main-Kanal” damit man wieder gut nach suchen kann.
Alle anderen örtlich zugehörigen Objekte, wie z.B. Krane, Kanalmeisterhäuser usw. bekommen kein name, außer es sind wieder Eigennamen, und sie bekommen description, wie z.B. description=Historischer Kran Alter Kanalhafen Kelheim, Ludwig-Donau-Main-Kanal
Als nächstes dachte ich die Schleusen zu pflegen.
Die Schleusennummer an sich ist schon wert, im name (sichtbar in der Karte) zu erscheinen.
Viele Quellen beziehen sich auf “Schleuse xy”.
Daher mein Vorschlag, die Schleuse selbst bekommt name=Schleuse xy (ggf. zusätzlich/alternativ lock_name=Schleuse xy, muss ich noch prüfen)
und description=Schleuse xy, Ludwig-Donau-Main-Kanal
Alle zur Schleuse zugehörigen Objekte (Schleusenwärterhäuser) bekommen kein name und description=Schleusenwärterhaus Schleuse xy, Ludwig-Donau-Main-Kanal
Gegenvorschläge/Anmerkungen?
Sorry, habe mich etwas mistverständlich ausgedrückt, deine Erläuterungen haben aber bereits meine Fragen beantwortet.
Und so langsam begreife ich die Zusammenhänge und Abläufe…
Vielen Dank!
Wenn Du genau überlegst, dann wirst Du feststellen, dass das schon lange vorher genau so war: Node History: 616493828 | OpenStreetMap
Der jetzt vorgeschlagene Name (der der Name ist), war seit mehr als einem Jahrzehnt schon so erfasst. Und der POI, den Du dazu gelöscht hast, wäre für die Umkreissuche absolut geeignet gewesen. (Zitat “Ja, auch das ist mir klar…”).
Du hast das jetzt geändert (und genau das war mein Kritikpunkt: Den Namen der Schleuse mit “Ludwig-Donau-Main-Kanal” zu verlängern war falsch) und zudem ein Stück des Kanals so benannt.
Stelle dir vor, wir würden jeden Hafen aus dem See/Meer herausschneiden und mit den Hafennamen versehen. Wäre das korrekt??
Besser wäre es - statt nur den Wasserweg so zu taggen - mindestens das ganze Becken samt den Schleusentoren(!) als eigenständige Fläche zu erfassen.
Ansonsten mappen wir nicht für bestimmte Filterkriterien (Zitat: “Alle zur Schleuse zugehörigen Objekte (Schleusenwärterhäuser) bekommen kein name” und “…damit ich und z.B. auch ein OsmAnd-Nutzer diese als primären Schlüssel für die Query verwenden können.”) oder nur, damit es “einheitlich ist”. Die echte Welt ist keine konsistente Datenbank.
Ja, Deinen Frust verstehe ich, Du hast Recht, das habe ich bereits erkannt, das habe ich anfänglich falsch gemacht und werde ich rückgängig machen bzw. reparieren.
Das Chaos an POIs, waterways und einfachen nodes für noch real und nicht mehr existierende Schleusen im und neben dem ursprünglichen waterway (also schon existent vor Beginn meiner Bearbeitungen) hat mich total in die falsche Richtung laufen lassen.
Dazu kam noch die Wiki-Seite https://wiki.openstreetmap.org/wiki/DE:Key:lock, woran ich mich orientiert habe und annahm, dass damit auch keine POIs und nodes nötig wären - auch falsch gedacht.
Das Chaos habe ich damit letztendlich verschlimmert, Asche über mein Haupt.
Und nicht zuletzt deswegen habe ich diesen Thread gestartet, um Rat und Hilfe einzuholen.
Aber ich möchte nach vorne schauen und frage, wo wollen wir am Ende hin?
Ich kann auch als ersten Schritt die Schleusen wieder so herstellen, wie sie mal waren, um danach neu aufzusetzen.
Klingt mir jetzt auch als sinnvoller erster Schritt, oder?
Mein Fokus ist nicht die Welt oder die ganze OSM-Datenbank, sondern nur der LDMK aber in Gänze, nicht mehr und nicht weniger.
Was wäre der konkrete Nachteil oder Schaden, den LDMK strukturiert und einheitlich zu “benamen”?
Was wäre bitte Dein konkreter Vorschlag?
