Fakt ist, dass verbogene Begrifflichkeiten in OSM Neulinge nur verwirren und abschrecken.
Deine Interpretation, die ich der OSM-Wiki nicht nachvollziehen konnte.
Die Länge ist für die Definition eines Tunnels nur nach DIN maßgeblich.
Mal sehen, obwohl ich nicht der Urheber dieser Diskussion bin, sondern nur zur Lösung beitragen wollte. Vielleicht überwiegt auf internationaler Ebene die Logik bei der Beurteilung.
Da aber die Wiki seit wann auch immer schon den hier diskutierten Zustand unter covered= definiert und mit einem Beispielbild aufwartet, verzichte ich auf weitere Diskussionen, und frage mich, was dieser thread eigentlich sollte…
Ich kann dir sagen was die Diskussion sollte. Fabi2 hats einfach mal mit der Holzhammmermethode geändert, dann kam Tordanik mit einem revert, aber das lässt sich Fabi2 natürlich nicht gefallen und der re-revert. So sind die covered=yes Befürworter auf einmal in der Rechtfertigungsposition (wohlgemerkt nur in Deutschland)
Wenn das die Methode sein soll, mit der die Wiki aufgeräumt wird…
So wie ich das sehe, gibt es für covered ein Proposal mit Zustimmung seit Ende 2009 und auch einen Wiki-Eintrag, der Hausdurchgänge als covered=yes definiert. Eigenmächtige tunnel-Änderungen sollten somit revertet werden.
Auch wenn ich covered=yes für die zweitbeste Lösung halte, kann ich damit gut leben. Den tunnel-Mist mache ich nicht mit und werde sowas ändern, wenn ich darauf stoße.
sollte ich heute Abend nach Hause gehen, werde ich “meine” Hauspassagen auch auf covered=yes ändern. Unterdessen musste ich meine Meinung revidieren und sehe das effektiv als bessere Lösung an, als tunnel…
(ausserdem dient es als Protest: es kann und darf nicht sein, dass jemand einfach so einen Tag von sich aus abändert bzw etwas nach seinem Willen durchboxen will… schon damals bei “meinen” Bäumen habe ich die blöden Zusatztags entfernt… sowas geht einfach nicht)
Die Tagging-Praxis wurde leider schon geändert, gerade gesehen, das diese uneindeutige Grütze wirklich schon im Proposal steht, gab leider nur eine direkte und eine indirekte Gegenstimme bezüglich dieses Problems. covered=yes sollte aus meiner Sicht für überbaute Objekte, die neben den Ein- und Ausfahrtsöffnungen (wenn vorhanden), mindestens noch zu einer Seite geöffnet sind benutzt werden. Also z.B.: http://upload.wikimedia.org/wikipedia/commons/3/3a/Galeriestra%C3%9Fe_cropped.jpg oder http://wiki.openstreetmap.org/w/images/d/dc/Covered.jpg.
Eine Hausdurchfahrt fällt unter den abstrakten Tunnelbegriff, so daß man dann auch hätte besser fragen sollen: “Sieht diese Hausdurchfahrt einem Tunnel ähnlich?” Weil natürlich ist eine Hausdurchfahrt so sehr ein Tunnel, wie ein Fußwg eine “highway” ist.
Auf Grund der Erweiterbarkeit um =_passage, wenn es eine Durchfahrt durch ein anderes Objekt ist, ist es mangels besserem Alternativkey, noch besser tunnel=* als abstrakten Tunnel durch eine Objekt anzusehen, als dafür das noch schlechter passende covered=yes zu benutzen.
@hurdygurdyman: Warum bist du nicht gleich dafür, daß man ab sofort die Keys nach dem Zufallsverfahren durch Aufschlagen des Wörterbuchs auswählt und dann im Wiki mit der gerade benötigten Bedeutung definiert? Die sind dann besonders einfach in der Benutzung.
Uns wenn man das Problem in Bezug auf die site-Relation (ein großer Container für alles was man gerade denkt, was zusammen gehört, der sich nicht automatisiert auswerten läßt und somit keinen Gewinn in Bezug auf die Daten bringt) trotz Erklärung nicht versteht, dann hat das genau 0 mit der Definition eines Tunnels als Objekt zu tun.
Es geht mir dabei auch nicht um die Deutungshoheit über irgendwelche Tags, sondern um eine logische Abgrenzung/Definition und gute Auswertbarbeit.
Von mir aus, taggt Hausdurchfahrten ruhig weiter mit covered=yes, dann haben wir dann bald ein zweites highway=path-Problem. Ihr wurdet hiermit gewarnt!
Ich hatte das Orginalproposal bis vor dem letzten Posting nicht gelesen, das ändert aber nichts an den sachlichen Fakten, bis auf dass der ganze Blödsinn von der Mehrheit der paar Leute die da abgestimmt haben, beschlossen wurde und ich das auch ggf. akzeptieren und meine Durchfahrten mit tunnel=* taggen werde. Stellungnahme dazu siehe oben.
Die Tags können vom Prinzip von jedem frei gewählt werden. Damit liegt es auch nahe, die Definitionen zu präzisieren bzw. zu verbessern, das hat absolut nichts mit dem Löschen von Informationen die einem subjektiv nicht gefallen zu tun!
Da aber meine Änderung im Wiki nicht akzeptiert wurde, habe ich das Thema hier zur Diskussion gestellt, das passiert ja auch oft genug auch mit Themen von der talk-de-Liste, die man dann parallel auch noch mal hier anspricht, ohne das da extra ein Verweis auf die Liste gemacht wird. Soll heißen, es ging mir eben darum hier gemeinsam eine Lösung für das von mir ausgemachte Problem zu finden.
Aber statt einen sachlichen Diskussion kommt von Leuten wie hurdygurdyman erst nur Getrolle, dann wurde einer auf “jetzt bin ich aber mal bockig und habe es einfach nicht nötig auf die sachlich vorgebrachten Argumente einzugehen”-gemacht und zum Schluß noch ein Spaltungsversuch, mit einem völlig aus dem Kontext gerissenen Thread.
Die Leute die hier ihre Meinung zur vermeintlich “besseren” Lösung revidieren, sollten sich lieber mal fragen, warum sie es vorher sachlich anders gesehen haben.
Ach ja, ich verstehe: Weil ich X nicht leiden kann, benutze ich die Tags x jetzt nicht mehr und tagge alles um, auch wenn er ja sachlich recht haben mag, aber schließlich ist die Verbesserung ja gegen die Proposal-Abstimmer-Mehrheitsmeinung! Deshalb benutze ich jetzt aus Protest nur noch den als untauglich erkannten Tag.
So, habe gerade schon mal vorsorglich einen Hunderterpack Merkbefreiungen geordert.
Klar stellt sich oft im nachhinein heraus, dass ein Tag nicht ganz optimal ist, aber eine Umbenennung sollte nur
im absoluten Ausnahmefall gemacht werden. Sonst hat mein ein Mischmasch den man nicht mehr wegbekommt.
So wie bei amenity=fire_hydrant, der zu emergency=fire_hydrant umgetauft wurde.
Ergebnis: Nun hat man beide Werte in der DB (11.000 mal bzw 15.000 mal) und alle Anwendungen müssen
beide Werte berücksichtigen.
Der mehr eingeschränkte Begriff ‘tunnel’ passt abstrahiert verbogen besser als der ganz allgemeine Begriff ‘covered’ (da ist was oben drüber)?
Du verbesserst den Begriff ‘covered’ in Richtung ‘an mindestens einer Längsseite offen’ - aber verwässerst gleichzeitig den Begriff ‘tunnel’ zu ‘an allen Längsseiten geschlossen’, unabhängig von dem durchaus allgemein akzeptierten sachlichen Fakt, was ein Tunnel ist.
Erst kamen sachliche Argumente.
Anscheinend wird - ganz sachlich - ersteres weder als Verbesserung noch zweiteres als untauglicher Tag erkannt.
Wenn ich bei mir einen Bedarf für einen Hunderterpack sehen würde, während mehrere Andere durchaus nur Bedarf an einer haben, fange ich an, meine Sicht nochmal zu überdenken - wie auf der Autobahn …
An und für sich sollte hierfür und auch bei Tunnels und Brücken kein Layer mehr erforderlich sein.
Ausnahme: mehrere Brücken übereinander.
BTW, das Gebäude müßte man dann ja aufteilen. JOSM meckert dann und das Gebäude wird nicht mehr als Ganzes dargestellt. Dann wäre also ein MP fällig. Kanns ja wohl auch nicht sein.
An den Vorwurf des Getrolles von bestimmter Seite habe ich mich mittlerweile gewöhnt. Die Einschätzung dazu überlasse ich neutralen Dritten.
Inwieweit meine Vorschläge nach Zufallsverfahren entstanden sein sollen, ist für mich weder allgemein noch konkret nachvollziehbar. Auch hier mögen andere urteilen.
Zum Schluss stelle ich an die Allgemeinheit die Frage, ob es besser ist, einen Begriff wie Tunnel zu abstrahieren (verbiegen), wenn es eindeutige dem allgemeinen Sprachgebrauch entnommene Alternativen gibt. Wie oben verschiedentlich erwähnt wurde, haben wir ja schon genug verwaschene Begrifflichkeiten. Meine Meinung dazu habe ich schon einmal dargelegt: http://forum.openstreetmap.org/viewtopic.php?pid=141389#p141389
