Wiki aufräumen oder: "Was ist eigentlich ein Tunnel?"

So, dann diskutieren wir eben um jeden tag. :wink:

Gut im Wiki steht sehr viel widersprüchliches Zug, so wurde/wird auf http://wiki.openstreetmap.org/wiki/DE:Howto_Map_A ja gerade teilweise unter “Hausdurchfahrten” empfohlen, diese als covered=yes zu taggen, dabei ist das aus meiner Sicht doch ganz klar ein Tunnel, also eine geschlossene, röhrenförmige Durchführung durch ein Objekt. Aus meiner Sicht ist dabei auch völlig egal ob das nun ein Berg oder ein Haus ist.

Ursprünglich wurde covered=yes nach der Verwendung für Wasservorratsspeicher für Objekte wie z.B. die Tankstellenüberdachungen geschaffen, welche zumindest teilweise an der Seite offen sind. Das englische Wiki zu tunnel=* für covered=yes führt da noch Galerietunnel an, was ja auch klar “Überbauungen”.

full ack… sehe ich genau gleich.
aber da gibt es ein Problem: das Gebäude ist idR layer=0. In welchem layer ist dann der Tunnel, welcher eigentlich auf gleicher Stufe sein müsste, wie das Gebäude?

Mir geht es um die Unterscheidung zwischen Tunneln, die durch z.B. einen Berg führen (auf dem natürlich auch Häuser stehen können) und einer Hausdurchfahrt. Das sind eindeutig zwei verschiedene Sachverhalte, und für die 3D-Darstellung ist die Unterscheidung auch relevant.

Ich habe vor einiger Zeit mal auf der talk-de-Mailingliste nachgefragt, wie dort diese Unterscheidung gesehen wird. Das Fazit dort war, dass ein tunnel=yes durch den Boden führt, wohingegen ein Weg, der lediglich mit einem Gebäude oder anderem Konstrukt (Lawinen-Galerie o.ä.) überbaut ist, als covered=yes gilt. Das Resultat der dortigen Diskussion wurde im Wiki festgehalten.

Fabi hat den damals entstandenen Eintrag heute geändert, was diese Diskussion hier ausgelöst hat.

Noch eine Ergänzung aus dem covered-Proposal: Man solle covered=yes nicht an Tunnel taggen, denn “covered=yes is implied for tunnels”. Es gehört also definitiv nicht zur vorgesehenen Definition von covered=yes, dass die Seiten nicht geschlossen sein dürfen.

naja, der tunnel ist vom prinzip dann layer=0, der teil des gebäudes über dem tunnel layer=1, der rest des gebäudes auch layer=0…

aber sinnvoll ist das net ^^

auf OSB habe ich gelernt, dass ein Tunnel eine gewisse Mindestlänge haben muss, sonst isses kein Tunnel, deshalb hab ich auch so einige “Tunnel” entfernt und die jeweils andere Straße zur Brücke gemacht. Und wie das Tordanik so gesagt hat, im Prinzip isses kein Tunnel, sondern dass Gebäude hat eben ein min_height oder sowas.

Das Problem gibts aber mit vielen Objekten wenn sie sich kreuzen. Solange sie alleine sind, sind alle Objekte Layer 0. Kreuzen sie sich, selbst ohne die Höhe zu ändern, bekommen sie ein Layer Tag. Ich mag das auch nicht. Aber mir fällt nix besseres ein…ausser ner Relation (x ist über y). Aber da höre ich schon die Relations"freunde" schreien

Eine Ergänzung: auf der englischen Seite steht “In order to map galleries (tunnels which are open on one side, often found on mountain roads) or ways underneath a building, use covered=yes instead.”

Hatte ich erst falsch gelesen.

Ein Galerietunnel soll also als covered=yes getaggt werden, was nachvollziehbar ist, weil es ist ja an der Seite offen und somit überbaut.
Eine Hausdurchfahrt ist abstrakt gesehen aber ein Tunnel, nur das das statt des Berges bzw. der Erddurchführung ein Haus ist. Trotzdem soll er mit covered=yes gemappt werden.

Wie sich herausgestellt hat, will Tordanik da eher was zur Unterscheidung von Hausdurchfahrten von Tunneln haben. Jedenfalls ist aus meiner Sicht dafür covered=* zu mißbrauchen so, als ob mal highway=path ab jetzt allgemein für Wege paßt, weil man als Autofahrer dieses Tag ja eh nicht braucht. :wink:

Stimmt, das ist echt ein Problem. Eigentlich ist ja nur das Stück über dem Tunnel layer=1, aber das ist wieder umständlich zu taggen.

Vorgaben für Mindestlängen sind ja ganz was neues! Wir hatten hier vor einer Weile hier mal die Diskussion zum Bach der durch ein Rohr fließt, das war dann das Rohr auch tunnel=yes, wenn man nicht den Weg darüber als bridge=yes taggen will.

Interessant wird das dann bei der Unterscheidung von bridge/tunnel in Bezug auf geschlossene Betonröhren z.B. mit Fußweg, wo oben erhöht auf einem Wall, durch den der Tunnel geht, die Eisenbahn entlangführt. Klar das ist üblicherweise ein Tunnel, zumal der Fall, der mir da einfällt und den ich deshalb gerade betrachte, noch etwas cutting=yes hat, was es noch eindeutiger macht, aber es ist nicht ausgeschlossen, das man Aus sicht der Eisenbahn sagen kann, das ist eine Brücke. Es hängt also noch von Niveau der Umgebung um das Objekt ab, aber da die Eisenbahn in den Fall die ganze Zeit auf dem Damm fährt, ist das eher ein Tunnel. layer=* bezieht sich ja nur auf das relative Objektaufschichtung, setzt sie also nicht in Bezug zur Umgebung.

Flaimo hat eine Zusatztag für Tunnel (tunnel=*), um zwischen Haus- und “üblichen” Tunneln zu unterscheiden, vorgeschlagen. Auf den ersten Blick sehe ich das als gute Idee.

jaja ignoriere mich ruhig, eine Relation hätte zumindest den Vorteil, dass man die Ways an der Stelle nicht mehr dreiteilen müsste. Also Straße durch Haus Relation type=layer, building role 1, residential role 0. Hätte den Vorteil, dass sich das Layer erstmal auf nicht anderes bezieht und mit andere Relationen kombinierbar wäre

Das würde ich wohl als die beste Lösung ansehen. Wäre wohl gar nicht schlecht, hierzu ein Proposal aufzusetzen…

Ich denke im Normalfall noch über die Sachen nach die ich schreibe, gerade bei Problemfällen. Korrekt, in Bezug auf die Realität wäre eigentlich, das Gebäude mit min_height=* bzw. building:min_level=* zu mappen. Da hilft aus meiner Sicht eine Relation auch nur wenn man das Gebäude aufteilt. Ohne Aufteilung kann man auch gleich layer=0.5 an das Gebäude taggen. :wink:

Ich verstehe Deine Antwort nicht. Was hat das mit min_height oder buidling_level zu tun. Mein Vorschlag sagt einzig und allein, was drüber und was drunter ist. Und das relativ, also eine Relation, in die das gesamte Gebäude und die gesamte Straße reinkommt…Das Gebäude als upper oder 1 oder sowas und die Straßen als lower oder 0 etc. . Also auch wenn das Gebäude über eine Straße geht, kann man unabhängig davon auch noch mappen, dass ein Fluss unter der Straße durchgeht…ohne sich darum kümmern zu müssen, dass da noch ein Gebäude drüber ist. Dann halt durch eine neue Relation

Das Haus steht aber auch auf layer=0 da macht es auch eine Relation nicht besser die es auf diesem Weg indirekt auf layer=1 verfrachtet, ohne den Weg am Haus aufzuteilen, bzw. das Haus dreizuteilen ist das kein Unterscheid zu layer=0 am Weg und layer=1 am Haus. Die damit abgebildete Beziehung von Haus zum Weg ist durch die Relation zwar richtig, dafür ist die des Hauses zum Rest bzw. der Erdoberfläche aber falsch.

Du verstehst den Unterschied zwischen relativ und absolut nicht.

Schon, auch wenn mir nicht gleich aufgegangen ist, was du mit der Relation erreichen willst, weil aus meiner Sicht kann man den Tunnel ja nicht weglassen. Offenbar ist die Layerangabe aber doch absolut in Bezug auf die Gesamtaufschichtung der Objekte, weil alle Objekte sind ja standardmäßig auf layer=0, also alles andere ist entsprechend darüber und darunter. Somit muß man dann das Haus oder den Weg aber trotzdem noch dreiteilen, da helfen auch keine Relationen für layer=*.

Den Weg durch das Haus muß man trotzdem dreitteilen um den Tunnel einzuzeichen, bzw. muß man andernfalls das Haus dreiteilen um die “Bücke” mit z.B. buildings:min_level einzuzeichen. Der Weg an für sich ist laut http://wiki.openstreetmap.org/wiki/Key:layer ja auf layer=0, der Tunnel ist dann auch auf layer=0. Das Haus ist an den Seiten auf layer=0 und da wo der Teil der “Brücke” ist auf layer=1. Im Bezug auf die Gesamtaufschichtung an dem Ort ist der layer=* aber absolut. Das ergibt sich z.B. daraus das am darauf achten soll, das das layer-Tagging des Gesamtways nich mit anschließenden Wegen an anderen Stellen kollidiert. Welchen layer=* hat denn dann z.B. das Haus in Bezug auf die vertikale Gesamtanordnung, wenn du es als Gesamtobjekt in die Relation aufnehmen willst?

Da die ganze Layer-Anordnung ja in Bezug auf den jeweiligen Ort absolut ist, braucht man auch keine Relationen mehr. Die sind durch Schleifen und mögliche Inkonsistenzen nur eine zusätzliche Fehlerquelle.

Grübel, Grübel ?!?!
Das Problem entsteht, weil das Datenmodell in OSM nur zweidimensional ist. Der räumliche Bezug von Objekten zueinander wird hilfsweise durch die layer (drunter und drüber) abgebildet. Gebäude werden durch die Aufstandsfläche abgebildet, Straßen und Wege durch deren linienförmigen Verlauf (mittlerweile auch schon teilweise durch deren Oberflächen. Der Weg “durchdringt” das Gebäude, genauso wie z.B. der Waldweg den Wald “durchdringt” (möglicherweise auch ein “Tunnel” aus Baumkronen :wink: ). Für die gemeinsame Punktmenge von Gebäude und Durchfahrt gelten somit analog zum Waldweg im Bezug auf die Abbildungsfläche beide Eigenschaften…

Muss da überhaupt ein Tunnel hin ?

naja, wald is ja kein objekt sondern eine flächennutzung, ein gebäude ist aber sehr wohl ein objekt. würden wir jeden baum einzeln taggen (nein, ich möchte das nicht!) und der weg durch den baum führen hättest du recht.

Ich unterscheide hier bewusst zwischen den Realobjekten und deren Abbildung in unserem zweidimensionalen Datenmodell. Und da ist alles auf eine Flächennutzung reduziert. Jedes Realobjekt wird in der Datenbank zu einem Punkt oder einer Punktmenge. Da ist es egal, ob wir Wald oder Gebäude als Flächeneigenschaft (=Punktmengen) angeben.
Stell dir vor, man definiert “Gebäude” zu “Menge aus Wänden, Decken, Treppen, Fenstern, Türen usw.” um. Dann wäre das Gebäude auch die Sammlung von Teilobjekten genau wie ein Wald.

Geoinformationssysteme und dazugehörige Datensammlungen sind immer eine Abstraktion der Wirklichkeit. Wir abstrahieren hier in OSM auf die 2D-Projektion und da sind alle Realobjekte nun einmal auf Punkte, Linien und Flächen reduziert.

den wald taggen wir aber als landuse, also die überwiegende nutzung von flächen und ein waldweg gehört zum wald dazu. eine straße die durch ein gebäude führt, ist aber deshalb noch lange nicht teil des gebäudes