Wenn wir eine allgemeine Lösung anstreben dann muß sie alle Fälle berücksichtigen:
Weg unterhalb eines Hauses, ein Weg durch das Gebäude oder eben ganz unterhalb eines Hauses.
Hängen wir dort an ein Weg ein Profil, bekommen wir Gestaltungsmöglichkeiten die für Indoormapping / osm4D wichtig sind. Ein weiterer Aspekt wieso gemeinsame Punkte von Gebäude und Weg wichtig sind:
Ganz oft stehen zwei Gebäudeteile nicht im rechten Winkel zueinander und der Durchgang ist konisch. In diesem Fall müssen die Breiten von dem Durchgang an jeder Seite genau bestimmt werden, und zwar dort wo der Eingang beginnt und endet also an der Hausfassade.
Zusätzlich kann dieser Punkt z.B. als Tor, Zaun, Entrace=yes beschrieben werden
Für den Renderer wir es wahrscheinlich einfacher, einen gemeinsamen Punkt zu haben als ihn zu berechnen.
dann müsste man bei [1] covered=yes den Weg + Bedachung nach außen rendern, und bei [2] tunnel=galerie den Weg unter das Gebäude rendern. (Abhängig von der Breite des Weges/der Überdachung)
in dieser diskussion hat man sich schon mal auf “building_passage” geeinigt: http://forum.openstreetmap.org/viewtopic.php?id=12474. ich sehe keinen sinn darin jetzt wieder das rad neu zu erfinden zu wollen, nochdazu wo es seit der ersten diskussion bereits verwendet wird (siehe taginfo weiter oben). unabhängig davon sollte das ganze aber eigentlich noch der internationalen gemeinschaft präsentiert werden. ich habe irgendwie ein ungutes gefühl und fürchte, dass “passage” zu schwammig und nichtsaussagend ist.
layer kann man sich im normalfall sparen denke ich, da haus und weg gemeinsame nodes an den schnittstellen haben. nur wenn das haus selber einen layer hat, sollte das beim way nachgezogen werden.
Guter Einwurf, auch der Hinweis auf Taginfo. Das würde dann in meinen Augen doch dafür sprechen, tunnel=building_passage gegenüber tunnel=passage den Vorzug zu geben. Zumal es eben eine weniger missverständliche Bezeichnung ist.
Ahhh, wusste gar nicht, dass es tunnel=building_passage schon gibt. Find ich gut! Nur leider findet man (ich) dazu nichts im wiki.
Kann man das nicht “offiziell” machen und eintragen, damit nicht jedes halbe Jahr die Diskussion aufkommt?
Aus der verlinkten Diskussion erkenne ich zwar nicht, dass sich auf irgendwas geeinigt wurde…aber gut, wenn dem so ist.
Wegen bisher 266 Verwendungen sehe ich keinen Grund, dieses lange Wort zu bevorzugen. In meinen Augen reicht tunnel=passage völlig aus. Zudem finde ich, dass building_passage eine zu spezifische Aussage ist, also die Verwendung unnötig weit einschränkt.
Dass man wie flaimo angeregt hat, diese Erweiterung in größerem Kreis (talk-de, talk, tagging) diskutieren sollte, steht außer Frage. Da kann die Eindeutigkeit des einfachen “passage” gleich mitdiskutiert werden.
Nein, die 266 Verwendungen wären für sich genommen kein ausreichendes Argument. Nur ändert das eben die Perspektive. Ich hatte bisher eher den Eindruck, dass tunnel=passage der status quo sei, und hätte die Vorteile von building_passage nicht für ausreichend für einen Umstieg gehalten.
Wenn nun aber tunnel=building_passage das ein bisschen “etabliertere” Tag ist, dann sehe ich überhaupt keinen Grund mehr zu einem Rückschritt zum aus meiner Sicht ein klein bisschen weniger überzeugenden tunnel=passage.
Und bitte, die Länge ist kein schwerwiegendes Problem. Wer Tags beim Mappen noch mehrfach komplett eintippt, muss schon einen sehr rückständigen Editor verwenden.
Da sehe ich die Situation ähnlich, aber ich beurteile sie anders. Ich befürchte nämlich, dass “passage” ein so nichtssagendes Wort ist, dass es bald für alles mögliche verwendet würde.
ok, wenn ich ein proposal auf die beine stelle, soll ich es mit tunnel=building_passage machen oder mit building_passage=yes machen? letzteres halte ich für flexibler in zusammenspiel mit anderen tags. auch wenn mir grad kein beispiel einfällt bin ich mir sicher, dass es irgendwelche verzwacketen mappingsituationen gibt wo man den tunnel-key dann für was anderes braucht.
Grad in verzwackten Situationen ist es praktischer, wenn man mit weniger Tags auskommt. Darum gefällt mir von den beiden Varianten die mit tunnel=building_passage besser. Aber du kannst ja noch überlegen, ob dir ein Beispiel einfällt, wo das partout nicht geht.
Wenn du ein Proposal anlegst, achte auch auf die Abgrenzung. tunnel=passage kann freier interpretiert werden, aber auch bei tunnel=building_passage ist beileibe nicht klar, ob nur Durchhäuser gemeint sind oder auch Einkaufspassagen, Unterführungen, Stiegenanlagen mit 2 Ausgängen usw. Auch der Unterschied zu covered=yes sollte definiert werden.
Bei der Erfassung von Flächen würde ich das gerne vergeben. Ist das Tag soweit stabil, besteht soviel Akzeptanz, dass sich die Erfassung lohnt? Ob es zur Zeit gerendert wird, ist mir dabei unwichtig.
Hi,
ich würd auf jeden Fall “tunnel=passage” oder “tunnel=building_passage” nehmen.
Es ist ja immernoch ein Tunnel, auch wenns ein “besonderer” ist.
Das passt dann auch in Anlehnung zu: “tunnel=culvert”, “bridge=viaduct;aqueduct;swing”.
Wie fkv schon sagte, finde ich auch, dass eine Abgrenzung sehr wichtig ist! (Möglicherweise findest du sogar weitere Vorschlage für die Abgegrenzten. Ich bin immernoch für “tunnel=gallery” als zu einer Seite hin offenem Tunnel.)
hast du für sowas ein foto um das zu veranschaulichen (möglichst mit CC lizenz)? ist das wirklich der richtige begriff für sowas? wen ich nach gallery suche finde ich nur einen haufen bilderaustellungen
ich dachte wir reden hier von häusern und nicht von tunnel-varianten die durch bzw entlang von bergen gehen? letzteres hat meiner meinung nach nichts im gleichen proposal wie building_passage zu suchen.
Ok, 1 ist keine Arkade, denn Arkade kommt von arc = Bogen. Ohne Bögen ist es eine Kolonnade. Hab ich bis heute nicht gewusst. Der Überbegriff ist im Englischen anscheinend “portico” ?!
In Bild 1 steht das Gebäude zudem weit über. Weiß nicht, ob man in so einem Fall noch von einer Kolonnade spricht. Aber einen Tunnel würde ich den nach links offenen Abschnitt auch nicht nennen.
wer noch nicht seinen senf zum proposal gegeben hat, möge das bitte jetzt (auf der talk page) tun, ansonsten gebe ich es zum voting frei, damit wir unter dieses kapitel mal einen schlusstrich ziehen können.
