Die 2. Version fand ich überzeugender und habe in der Wiki einen Hinweis gegeben besser diese zu benutzen.
Statistisch ist die 1. Version im Vorteil 2246:147:2904 zu 159:3:35
aerialway=drag_lift ohne Hinweis auf den genauen Type gibt es 4575 mal.
JSOM verwendet auch die 1. Version.
Mir bekannte Karten werten beides aus.
Ist es nun sinnvoll bei der 1. Version zu bleiben oder umzustellen?
Ein künstlich herbeigeführte Umstellung macht keinen Sinn, insbesondere wenn es mit der ursprünglichen Version kein echtes Problem gibt. Sowas hat auch wenig Aussicht auf Erfolg.
Von daher ein klares: Version 1 bleibt, Wiki-Eintrag sollte häufigeres Tag beschreiben und selteneres evtl. danach noch erwähnen.
ein Problem kann es doch geben:
Wenn ich als Ski-Laie einen Schlepplift sehe, dann weiß ich nicht, ob das nun j-bar, t-bar oder platter oder sonst was ist. Immerhin: Schlepplift/drag_lift erkenne ich. Dafür bräuchte ich einen value, den dann ein Experte später mit einem Zusatz-Tag präzisieren könnte.
Überhaupt: Grundsätzlich geht die Tendenz in OSM IMHO dahin, Zusatz-Tags zu nehmen, nicht zig values im Haupt-Key für ganz ähnliche Dinge.
Du musst nicht mal Laie sein um dieses Problem zu haben, wenn Du den Lift nur im Sommer siehst. Dann sind die Bügel in der Regel ausgehängt, oft fehlt auch das Seil. Masten und Spur sind aber meistens deutlich, jedenfalls sieht man, dass da geschleppt wird und nichts schwebt.
Ich finde das Tagging mit aerialway=drag_lift|j-bar|t-bar|platter aber auch nicht so viel schlechter, als dass man es ändern müsste und verfeinern kann ich ja auch, indem ich den Wert von aerialway ändere…
So fände ich es am übersichtlichsten und am leichtesten auszuwerten. Wenn jemand nur wissen will, wo Schlepplifte sind, sich mit deren Form / Typen aber nicht auskennt, hilft ihm ein gemeinsames Haupttag am besten weiter. Wenn jemand Details will, hilft ihm das Zusatztag. So ein Tagging wird also beiden Nutzergruppen gerecht.
Bei diesem Tagging ist aber das Problem für den Kartenhersteller, dass er eine Liste an möglichen Werten haben und pflegen muss, wenn er alle Schlepplifte gleich darstellen will.
Er muss also irgendwas wie “if aerialway IN (‘drag_lift’,‘j-bar’,‘t-bar’,‘platter’,‘rope_tow’) then aerialway=drag_lift” schreiben, statt einfach auf drag_lift zu prüfen. Das erhöht die Komplexität der Auswertung, weil man selbst Klassen bilden muss, statt die Klassen einfach aus der DB geliefert zu bekommen. Außerdem ist es Wartungsanfällig, wenn mal jemand einen y-bar erfindet, oder so.
Aber ich sehe das wie du: das jetzt umzutaggen ist unsinnig.
Es soll ja auch gar nicht mehrere Schemata geben, sondern eines - das steht außer Frage. Die Frage ist doch, welches das beste ist. Und eines, bei dem jemand, der einfach nur einen Schlepplift sucht, ohne sich damit auseinandersetzen zu müssen, welche Typen es gibt, wie sie getaggt sind und ob es vielleicht noch Sonderformen gibt, die von seinen 4-5 OR-vernüpften Abfragen nicht erfasst werden, würde ich nicht das beste nennen.
gomo hat es richtig beschrieben. Es handelt sich hier um Schlepplift und t-bar, j-bar, patter sind nur genauere Spezifizierungen. Das wird mit der 2. Version besser abgebildet und lässt sich sicher besser auswerten.
Ist nur die berechtigte Frage ob eine Änderung gerechtfertigt ist?
Wenn wir den Tag neu einführen würden, müsste auch die Signifikanz überprüft werden. Und dann würden man sich für die Version 2 entscheiden.
Wobei in der Wiki ja nichts gelöscht werden muss, sonder nur ein Hinweis auf die bevorzugte Version 2 gegeben werden müsste.
Und wenn jemand die Schlepplifte unterscheiden möchte muss er mit Schema2 2 tags auswerten anstatt nur eins. Das kann man also so und so sehen.
Auf jeden Fall sollten beide Varianten für Datenauswerter trivial sein. Wer OSM-Daten verarbeiten möchte, muss sich mit viel komplizierteren Dingen befassen. Die Frage nach der Wartbarkeit stellt sich hier auch nicht wirklich, da nicht zu erwarten ist, das in den nächsten Jahren noch neue Typen hinzukommen.
Prinzipiell sind beide Schemas machbar, das ist klar. Schema1 hat jedoch viel höhere Nutzungszahlen. Ich halte eine Umstellung für nicht sinnvoll, weil sie meiner Meinung nach keinen nennenswerten Vorteil bringt, dafür aber den Nachteil, dass man über Jahre hinweg mit 2 verschiedenen Schemas zu kämpfen hat.
Wer eine solche Anwendung hat, kann bei Schema 2 genau so gut nach einem einzigen Tag (drag_lift=*) suchen und je nach Wert sortieren. Den Tag aerialway=drag_lift kann er ignorieren, oder als Konsistenztest ebenfalls auslesen.
Wenn man berücksichtigt, dass beim Schema 1 die spezielle Bauform des Schlepplifts getaggt wird, kann man durchaus davon ausgehen, dass es Spezialfälle / Sonderformen gibt, die von den bisherigen Werten nicht erfasst sind, und die dann natürlich einen neuen Wert erfordern würden. Das stellt durchaus ein Problem für die Wartbarkeit eines Auswerters das, das bei Schema 2 nicht der Fall ist.
Da liegst du mit den Zahlen etwas daneben, siehe erster Post in diesem Thread. Die 4575 aerialway=drag_lift kann man ja nicht klar Schema 1 oder 2 zuordnen, weil sie nach beiden gültig wären. Diese müsste man also gar nicht umtaggen. Sinnvoll wäre es hier nur, diese feiner zu taggen. Im Vergleich dazu stellen die etwas über 5000 aerialway= keine “viel höhere” Zahl da, sondern liegen in der gleichen Größenordnung - der Aufwand dafür wäre also vergleichbar.
Zum Vorteil für die Auswertung siehe oben. Dass eine Umstellung von 5000 Elementen, die man (nach geeigneter Absprache selbstverständlich) sogar mechanisch durchführen könnte, sowie Änderung in Wiki und Editoren, Jahre dauern sollte, halte ich aber doch für arg übertrieben und unrealistisch.
Die Zahlen sind: aerialway=t-bar|j-bar|platter|rope_tow 2262+147+2917+802=6128 zu aerialway:drag_lift 206
Das heißt auf einen Schema2 Schlepplift kommen 30 Schema1 Schlepplifte. Das würde jetzt schon mal als “viel höhere Nutzungszahl” bezeichnen wollen
Ich wüsste nicht, wann das letzte mal per mechanischem Edit von einem Taggingschema auf ein anderes umgestellt wurde. (Wenn man die unabgesprochenen edits, welche anschließend wieder revertiert wurden mal außen vorlässt.)
Noch ein kleiner Fakt: bei 23 Liften (was 11% aller Schema2 Lifte entspricht) wiedersprechen sich die Werte von aerialway und aerialway:drag_lift. (http://overpass-turbo.eu/s/eah). Das kann man zwar jetzt keinem der beiden Schemas anlasten, aber sicherlich der Tatsache, dass es 2 Schemas gibt.
