Die Seiten DE:Key:checkpoint und DE:Key:course sind jetzt von meiner Seite her fertig. Wenn es noch etwas zu ergänzen oder zu ändern gibt, lass es mich wissen. Wenn nicht, passe ich die englischen Seiten noch an und verabschiede mich dann hier.
1 Like
Hallo Mikke,
ich hoffe du bist mir nicht böse, aber deine Wiki-Änderungen empfinde ich nicht wirklich als Verbesserung. Aus meiner Sicht besteht das größte Defizit der Key:checkpoint-Seite darin, dass die Perspektive der Wander-Stempelstellen überrepräsentiert ist, und andere Verwendungen übersehen werden. Das verstärkst du mit deiner Version sogar. Ich hatte in diesem Thread in Beitrag #126 bereits auf den checkpoint:type=register und die mögliche Analogie zum checkpoint:type=notebook hingewiesen. Bitte schau dir noch mal die dort verlinkte Seite “What Is a Trail Register?” an.
Wenn ich mich recht erinnere, hast du mit Beitrag #201 begonnen das Thema der Diskussion auf die Wiki-Seite Key:checkpoint zu erweitern. Spätestens damit müssen wir aber doch unsere Diskussionsperspektive auch auf andere Funktionen (von checkpoint=hiking) jenseits der uns vertrauten Stempelstellen erweitern:
Diese Fokussierung auf das Ausgangsthema und das Ignorieren von alternativen Verwendungen des tags können/sollten wir uns dann meines Erachtens nicht mehr erlauben.
Abstrakt betrachtet sehe ich neben der hier dominanten Funktion von Leistungsnachweisen (1.) für eine Challenge im Wesentlichen noch zwei weitere Funktionen für den tag checkpoint=hiking.
- hiker gets acknowledgment for challenge.
- hiker puts entry into logbook.
- authority checks permission of hiker.
zu 1. haben wir genug gesagt. Das war unser Hauptthema.
zu 2. verweise ich auf checkpoint:type=register und checkpoint:type=notebook (siehe Oben).
zu 3. haben wir noch gar nichts gesagt?
In den USA (und Kanada) finden sich ein paar Beispiele für checkpoint=hiking bei denen als Operator Nationalpark-Verwaltungen angegeben sind, und Recreation Passes haben dort eine gänzlich andere Bedeutung als wir von den Wanderpässen für Wandernadeln gewohnt sind. Daher vermute ich, dass dort (zumindest teilweise) eine Bedeutung im Sinne von 3. vorliegt.
Abschließend noch ein paar Anmerkungen zu deinen Wiki-Text/Änderungen:
Key:course
course=*ist ausschließlich für die Verwendung zusammen mit dem Schlüsselcheckpoint=*vorgesehen.
Damit sprichst du dem tag golf=hole die Legitimität zur Verwendung von course=* ab. Das erscheint mir etwas gewagt. Im Bild der zugehörigen Wikiseite ist eine Infotafel dargestellt, auf der wörtlich EAST CURSE geschrieben steht. Abstrakt betrachtet, gibt es dort doch das gleiche Bedürfnis, die Zugehörigkeit einzelner Objekte zu einem gemeinsamen Kontext zu kennzeichnen. Insbesondere, wenn es OTG explizit angeschrieben ist.
Ich sehe ehrlich gesagt keinen guten Grund dem golf course das zu untersagen.
Key:checkpoint
Hier sprichst du (Achtung! Wortspiel:) in einer Tour von einer “Tour” 
. Diesen Begriff assoziiere ich allerdings eher mit einer Form von zeitlichem Zusammenhang, wie zum Beispiel wie in:
Frage: Kann man diese Challenge in einer Tour erfüllen?
Antwort: Nicht an einem Tag, aber in mehreren Etappen in einer Woche.
Deshalb empfinde ich die Formulierung Tour in deinem Text eher als verwirrend. Ganz abstrakt betrachtet geht es doch um die Zugehörigkeit verschiedener Checkpoints zu einem gemeinsamen Kontext.
für 1. kann das die gemeinsame Challenge sein (z.B. Wanderpass einer Wandernadel)
für 2. (logbook) und 3. (access control) kann es eine Route (z.B Appalachian Trail) oder eine Region (z.B. ein bestimmter Nationalpark) sein.
Die Perspektive der Wander-Stempelstellen war Thema der Diskussion hier und auch die existierenden Wikiseiten befassten sich ausschließlich mit diesem Thema. Mein Anliegen war es nicht, die Wikiseiten um andere Bereiche zu erweitern, sondern lediglich den Bezug der Stempelstellen zu dem schwammigen Begriff “course” (der auf der deutschen Wikiseite bislang völlig fehlte) zu beschreiben.
Erweiterungen sind davon abgesehen natürlich jederzeit möglich, falls ein Bedarf dafür erkennbar ist. Das könnte z.B. auf die Checkpoints zutreffen, an denen Wanderer sich offiziell registrieren.
Eventuelle Checkpoints von Nationalparkverwaltungen o.äh. gehören m.E. dagegen nicht unter checkpoint=*, sondern unter amenity=checkpoint, da dort aktiv von einer Autorität Besucher überprüft werden (im Gegensatz zu den passiven checkpoint=*).
Ich halte es generell für eine schlechte Idee, ein und denselben Key für völlig unterschiedliche Objekte zu verwenden. Wenn course=* für die Zusammanfassung von Tourencheckpoints dokumentiert ist, sollte es nicht gleichzeitig für die Spielbahnen eines Golfplatzes Verwendung finden. Dafür gibt es ja bereits das dokumentierte Tag golf=hole, wozu also noch course=*?
Zum Vergleich: Spielbahnen auf Golfplätzen getaggt mit golf=hole: rund 244.000 mal in der Datenbank, getaggt als course=* rund 100 mal. Das sieht mir mehr nach einem Taggingfehler als nach einem echten Bedarf aus.
Irgendeinen Namen muss das schwammige Konstrukt, das alle Checkpoints zusammenfasst, die entweder zu einer Route gehören oder eben auch nicht, bekommen. Ich habe dafür den Begriff “Tour” gewählt, diesen absichtlich in “” gefasst und das sich dahinter verbergende Konstrukt ausführlich erläutert. Ob Kontext als Ersatz dafür verständlicher ist, wage ich zu bezweifeln.
Ich sehe momentan keine Veranlassung, an dem bisherigen Text etwas zu ändern, könnte mir aber vorstellen, die Seite noch um die Beschreibung der Registration Checkpoints, die bisher hier nicht thematisiert wurden, zu erweitern.
Hallo Mikke,
sorry, aber ich habe etwas den Eindruck, dass du meine Argumente nicht wirklich aufmerksam liest. Stattdessen machst du etwas, was man im Englischen als “to double down” bezeichnet.
In DE:Key:course
[…] ist er in der Vergangenheit auch für andere Objekte benutzt worden, z.B. für die einzelnen Bahnen von Golfplätzen (golf course), […]
Das stimmt doch so nicht. Der Key:course wird nicht für sondern von solchen Objekten genutzt, und zwar um genau das gleiche Problem zu lösen, das wir mit checkpoints auch haben: Mehrere Objekte mit gleicher ref scheinbar im gleichen Zusammenhang.
Bei uns geht es um die Unterscheidung von verschiedenen Stempel-Pässen/Karten von einem Operator.
Bei den Golf-Kursen geht es um den (seltenen) Ausnahmefall, dass es auf einem Golfplatz (leisure=golf_course) zwei (oder mehr) Kurse mit unterschiedlichen Bahnen (golf=hole) zur gleichen Loch-Nummer (ref) geben kann:
golf=hole
ref=7
course=west
und
golf=hole
ref=7
course=east
Bei den allermeisten Plätzen gibt es nur einen Kurs und deswegen können die Begriffe als synonym missverstanden werden.
Beispiele für solche Ausnahmen sind:
Jackson Park Golf Course mit Bahnen (golf=hole):
ref=2 ohne course sowie
ref=2 mit course=executive
Blue Fox Run Golf Course mit drei unterschiedlichen Bahnen zur #2:
ref=Blue_2 mit course=Blue
ref=Red_2 mit course=Red und
ref=White_2 mit course=White
Beim nahegelegenen Golfplatz Golf Club of Avon verhält es sich genauso.
Wie du unschwer siehst, hat das in den ref-Werten zu genau den Präfix-Wirren geführt, über die wir in diesem Thread zu Beginn heftig gestritten hatten.
Das liest sich für mich jetzt so:
Wenn die Übernahme geglückt ist, haben die Golf-Kurs-Mäpper das Nachsehen.
Dein letzter Satz hier klingt genauso unlogisch, als würde ein Golf-Kurs-Mäpper sagen:
Es gibt doch schon checkpoint=hiking, wozu also noch course=*?
Wo du hier andere Verwendung ausschließen möchtest, sehe ich eine deutliche Parallele zum Key:network und würde eher eine Änderung von derzeit course=* zu checkpoint:network=* bevorzugen. Dabei verweise ich explizit auf den Absatz Key:network#Amenities. Das brächte auch den Vorteil, dass für Objekte, bei denen die Funktion-Stempelstelle eine Nebensache ist (z.B. Hotels, Restaurants, Tourismusbüros, etc.), die Bedeutung klarer zuzuordnen ist (z.B. keine Verwechslungsgefahr mir der cuisine=*).
Damit möchte ich mich dann aber auch aus dieser Diskussion ausklinken und präsentiere zum Abschied noch eine Overpass-Turbo-Query zum Thema:
Checkpoints via Relationen selektieren,
am Beispiel von DichterMusikerMaler-Weg und dem EB (Internationaler Bergwanderweg Eisenach–Budapest).
Bei ersterem (DMM) sieht man, dass nur am Anfang des Wegs course gesetzt ist (grün), und dieser tag zum Ende des Wegs bei den Objekten fehlt (blau).
Beim EB sind viele Checkpoints mit note gekennzeichnet (cyan), ein paar haben den Text als description und manche sind nur über die Relation zu finden (blau).
Da täuscht Dein Eindruck, wir sind nur unterschiedlicher Meinung.
Ich bin kein Golfer und will auch keiner werden, aber die Zahlen dazu sprechen eine relativ klare Sprache: golf=hole rund 244.000 mal in der Datenbank, getaggt als course=* rund 100 mal. Das Problem ist also doch etwas anders gelagert als bei den Checkpoints.
Korrekt, und die unterscheiden sich meistens durch einen Farbcode. Wäre das nicht durch eine site-relation mit den zusammengehörenden Bahnen besser darzustellen? Ganz in der Nähe des von Dir verlinkten Jackson Park Golf Course liegt übrigens der Jefferson Park Golf Course, der ebenfalls einen 9-Loch und einen 18-Loch Platz beherbergt. Die ref 1-9 sind auch hier doppelt, kommen aber ohne course=* aus.
Und in Denver haben die Bahnen keinen course, aber die Grüns:
course = par3
golf = green
leisure = pitch
name = P3 Hole 2 - Putting Green
ref = 3-2
sport = golf
Ich denke nach wie vor, dass es keine gute Idee ist, course für so unterschiedliche Zwecke zu verwenden, aber verbieten kann man es ohnehin nicht, man kann nur drauf hinweisen. Ich werde das noch entsprechend anpassen.
Ich mache keinen Hehl daraus, dass ich course für keine besonders gute Wahl als Sammelschlüssel für die Checkpoints halte, aber ich gehe davon aus, dass bei der Auswahl mit Absicht auf route und network verzichtet wurde, um Verwechslungen mit diesen bereits verwendeten Schlüsseln zu vermeiden. Aber wenn Du checkpoint:network=* für die bessere Lösung hältst, schlag es einfach vor. Du solltest dafür dann m.E. aber ein neues Topic aufmachen.