It’s simple, but not easy …
Bei den Schleusen wollen wir auch diesem Grundsatz folgen:
KISS (keep it simple, stupid). Datentechnisch elegante, aber für Laien schwer verständliche Lösungen werden vermieden, so lange wir mit einfacheren Mitteln die gleiche Differenzierung und Klarheit herstellen können.
Einfach und unkompliziert ist eine Schleuse, die lediglich die Aufgabe hat Schiffe zu heben/senken, nicht historisch interessant oder gar denkmalgeschützt ist und kein Gelände um sich herum hat, das auch als Schleuse bezeichnet und wahrgenommen wird.
Schwierig ist eine Schleuse als gesamtes (touristisch/historisch interessantes) Schleusen-Gelände abzubilden. Dazu gehört (nicht immer) ein Schleusenwärterhaus, manchmal eine Brücke, die über das Unterhaupt der Schleuse führt, die Grasflächen an der Schleusenkammer (die an manchen Stellen als Liegewiese für Badegäste dienen), evtl. ein Picknickplatz, erklärende Info-Schilder, oder auch mal Gastronomie. Mit “wir treffen uns in Schleuse 35” ist bei uns eine Verabredung im Biergarten gemeint und nicht ein Bad in der Schleusenkammer.
Die Standard-Lösung nach Wiki ist, alle tags auf das waterway-Segment waterway=lock zu setzen. Das funktioniert für Schleusen wie Schleuse Bachhausen MDK perfekt, dafür ist das Schema entwickelt worden.
Beim MDK gibt es zwar sicher auch ein “Schleusenwärterhaus”, wahrscheinlich einen Kontrollraum, der im Beispiel in einem der zwei großen Gebäude (schlicht mit building=yes getaggt) liegen wird. Hier greift die Methode nach Wiki, genauer differenzieren muss man nicht, weil das allgemeine und touristische Interesse relativ gering ist.
Beim LDMK ist schon das Schleusenwärterhaus ein intensiv gemapptes Objekt mit vielen Attributen, die Ensemble haben einen historischen und touristischen Wert und es gibt viele Zwischenstufen im Erhaltungszustand. Mit der Standardlösung fallen diese Feinheiten unter den Tisch.
Zu lösen ist, wohin die Attribute gesetzt werden, die das gesamte Schleusengelände meinen. Also tags wie: name=*, historic=*, tourism=*, wikipedia=*, website=*, description=* ...
(Aussparen will ich auch hier wieder die heritage-tags, die auf klar definierte Ensemble nach den Denkmallisten angewendet werden können.)
Ist eurer Meinung nach sinnvoll
- mit Standardlösung die tags an den waterway (dem kleinen Stück innerhalb der Schleusenkammer) zu heften
- eine site-Relation pro Schleuse zu erstellen und die Attribute an die Relation zu taggen
- pro Schleuse einen POI zu erstellen
- oder etwas ganz anderes
???
Wir sind eher bei der Lösung mit POI gelandet,
weil wir die Standardlösung für den LDMK zu wenig differenziert finden und
weil wir die komplizierte Relation vermeiden wollen (wenn wir für jede Schleuse eine korrekte site-relation bauen, wird diese vielleicht in Zukunft nicht verstanden und von neuen mappern mit guten Motiven verschlimmbessert, das heißt man müsste ständig das tagging bewachen …) .
Ein POI pro Schleuse (nur otg vorhandene Schleusen, keine “virtuellen” aufgelassene Schleusen, von denen nichts mehr zu sehen ist)
- ist intuitiv verständlich
- gibt die Gelegenheit übergreifende Attribute an einem Element (statt an jedes zur Schleuse gehörendes Element) zu taggen, was widersprüchliches tagging vermeiden hilft
- kann auch an ungewöhnlichen (weil nur noch fragemtarisch erhaltenen) Schleusen fein differenziert die Situation wiedergeben
- kann Attribute der Schleuse tragen, auch wenn sie kein Wasser mehr führt
- Ermöglicht ein einheitliches Bild auf die gesamte Länge des Kanals
- Stellt keine Doppelung dar, wenn zusätzlich auch die (funktionierende) Schleuse als Schiffshebeanlage nach Wiki getaggt ist (mit
lock_name=*, lock_ref=*, ...) - ist als Point Of Interest gerechtfertigt, weil die Schleusen für Radler, Läufer, Wanderer Orientierungs- oder Zielpunkte sind.
- kann bei “schönen Schleusen” den tourism-tag als feature tragen, bei eher belanglosen Schleusen den historic_tag.
Wie gefällt euch das?