Es ist immer wieder das selbe leidige Thema bei OSM. Es gibt bewährte Tags und doch meint der eine oder andere, das Rad neu erfinden zu müssen. In diesem Fall haben wir tunnel=yes und covered=yes, beide im Wiki eindeutig definiert. Leider wird Letzteres nicht in der Karte (Mapnik) dargestellt, Ersteres schon. Da haben wir wieder das Dilemma. Wir sollten trachten, dass covered=yes dargestellt wird. Dann bräuchten wir diese Diskussion nicht zu führen.
BTW: Irgendwie käme ich mir schon blöd vor, bei Tankstellen die Wege zu den Zapfsäulen, die überdacht sind, als Tunnel zu deklarieren.
Ich bemühe mal die Encyclopedia Britannica
http://www.britannica.com/bps/dictionary?query=tunnel
hollow conduit heißt “hohle Röhre” und dass ist wohl eine Hausdurchfahrt, denn die Seiten sind auch geschlossen.
covered heißt “bedeckt, zugedeckt”, wodurch lediglich ausgesagt ist, das sich oben etwas darüber befindet.
Somit bleiben Tankstellendächer auch covered 
Ich verstehe auch nicht, warum man da auf einmal etwas ändern möchte, das ist doch eindeutig und sinnvoll definiert und mit Bildern illustriert:
http://wiki.openstreetmap.org/wiki/Key:covered
Gruß,
Mondschein
Hallo Chris66, Dein Vorschlag:
tunnel=passage
plus
passage_type=<passage_type>
finde ich super! Wir werden es so implementieren. Es ist nicht der erste gute Taggingvorschlag von Dir. vielleicht könntest Du helfen beim Entwerfen der Taggingschemata für OSM4D - da ist wirklich viel zu tun?
@Wolfgang B:
Das Projekt lebt davon, dass man gute Sachen besser machen kann. Mit diesem Vorschlag haben wir also nicht 2 sondern 3 verschiedene Situationen abgedeckt:
tunnel:yes - für eine unterirdische Anlage (Brenner Tunnel)
tunnel:passage plus passage_type=<passage_type> geeignet u.A. für bessere 3D Darstellung für Indoor Mapping
covered:yes für überdachte Wege
Dein Hinweis: “Den überdachten Weg zu der Zapfsäule als Tunnel zu definieren ist quatsch” finde ich richtig. Du hast recht. covered:yes wäre hier richtiger!
Wir können “covered” für 3D so verwenden, dass er die GESAMTFLÄCHE bis zu einer Höhe entfernt, und somit einen richtigen Dach erzeugt!
ich werde dies in Kürze mit einigen Beispielen in http://wiki.openstreetmap.org/wiki/DE:3D_building#Durchfahrt_.28Tunnel.29 platzieren.
Bliebe nur noch zu klären, wie Galerien definiert werden, um die seitliche Öffnung richtig auswerten zu können. Da bräuchte covered noch irgendetwas zusätzliches in Abhängigkeit zur Wegrichtung.
seitdem das thema das erste mal aufgekommen und es keine klare entscheidung gegeben hat (tunnel vs. kein tunnel) mappe ich das wasserfest immer mit drei tags: covered=yes + tunnel=building_passage + building_passage=yes
http://taginfo.openstreetmap.org/tags/tunnel=building_passage#wiki (209)
http://taginfo.openstreetmap.org/keys/building_passage#values (106)
Oder
tunnel=gallery (einseitig offen)
tunnel=covered
Da ja tunnel=yes und covered=yes nur spezial Formen sind. könnte man sie so vereinheitlichen und covered=* irgendwann aufs Altenteil schicken.
Ähnlich wie bridge=* auch alles abdeckt, was “drüber” führt.
mdk
Hallo Michael,
ich weiß nicht ob ich richtig verstehe, was mit der Galerie gemeint ist. Ich begreife es so, dass jedem Weg quasi ein “Öffnungprofil” zugiwiesen wird, wodurch die Richtung definiert ist.
Seitliche Eingänge mit entrace=yes müßten mit einem Weg mit der Linie verbunden werden, die die Hauptrichtung der Galerie darstellt. Dadurch würde sich das Seitliche ergeben.
@mdk - die Idee mit Covered ist schon nicht schlecht: Ein gebogener Fußweg zwischen zwei Gebäuden mit einem Doppelschrägdach passiert ziemlich oft. Man würde dem überdachten Weg sozusagen einen Querschnitt der Überdachung verpassen und um eine richtige Darstellung müsste sich z.B. Kendzi mit Tordanik bemühen 
Im übrigen hoffe ich dass die beiden Kollegen eine Möglichkeit finden zusammen zu arbeiten. Ich manchmal das Gefühl dass einige Dinge überflüssigerweise doppelt entwickelt werden.
Wenn du dich jetzt nicht auf die Fußwege beschränkst, dann gibt es sehrwohl die Unterschiede. Zum Beispiel soll es U-Bahnen geben. Oder auch Straßen, welche erst nach dem Bau des Gebäudes angelegt werden. Wie in Berlin am Potsdamer Platz. Allerdings gibt es auch Straßen die ebenerdig verlaufen und dann nur von einem Gebäude überbaut werden. Einkaufszentren zum Beispiel.
Ach ja check
TANKSTELLE: …und eine Fläche mit building=yes bzw. das Dach über den Zapfzäulen mit building=roof und einem Weg als highway=service (http://wiki.openstreetmap.org/wiki/Tankstelle)
Wir haben also
tunnel=yes/*
covered=yes
building=roof
und zur Krönung noch etwa 5 Millionen Mal building=yes + wall=no (z.B. Kataster Import Frankreich)
Kennt noch jemand Tags um einem Weg ein “Dach” zu verpassen? 
mdk
Aber klar doch! Bahnsteigdächer kannst du auch mit shelter=yes bezeichnen. Wobei dann unklar ist, ob es sich auf einzelne Unterstände oder den ganzen Bahnsteig bezieht. Ich bin jedenfalls daraus nicht schlau geworden.
Mit Galerie ist so ein (nur auf einer Sete offenes) Bauwerk gemeint:
http://de.wikipedia.org/wiki/Galerie_%28Verkehrsbauwerk%29
mdk
Hallo mdk- es ist ein sehr guter Hinweis. Ich denke darüber nach!
Ich verstehe nicht, wo das Problem sein soll. Es gab mal ein Proposal, für Tunnels den Layer -1 als Default anzunehmen, aber das wurde ja niedergestimmt, u.a. von dir. Damit gilt für Tunnels weiterhin Layer 0 als Default. D.h. wenn layer=-1 gesetzt ist, ist es ein Tunnel unterm Haus, sonst durchs Haus.
Das gefällt mir aus 2 Gründen nicht:
1.) covered=yes ist, wie schon angemerkt wurde, für Objekte gedacht, deren Überdachungen zur Seite hin offen sind. Wollte man alle überdeckten Objekte mit covered=yes versehen, dann müsste man den Tag auch auf alle unterirdischen Objekte setzen. Das wär offenkundig zuviel des Guten, und in deinem Fall wäre erst wieder keine Unterscheidung zwischen Hausdurchfahrten und unterirdischen Tunnels möglch.
2.) Ich bin kein Freund von Redundanzen. Wenn durch das Gebäude die Überdeckung schon impliziert ist, warum dann noch extra einen Tag setzen?
Das stimmt, denn weil eine Gebäudedurchfahrt genau dort beginnt/endet, wo auch das Gebäude beginnt/endet, muss es an diesen Stellen gemeinsame Nodes geben. Ich fürchte aber, dass das im Normalfall nicht so korrekt gemappt ist.
Den Aufwand kann man sich als Mapper sparen, wenn man überhaupt kein tunnel=yes setzt und die Straße so zeichnet, als gäbe es das Haus gar nicht. Aus der Lage der beiden Objekte (Haus, Straße) ergibt sich ohnehin, dass das eine Häuserdurchfahrt ist. Das ist meine bevorzugte Metode.
Wann soll das jemals nötig sein? Ändert sich mitten in einer Hausdurchfahrt die Geschwindigkeitsbeschränkung? Ich glaube, du brauchst dir die Sache nicht so kompliziert machen.
Wenn du solche Fälle dennoch berücksichtigen willst, ist es im Grunde das gleiche wie bei “richtigen” Tunnels. Auch (oder v.a.) die können geteilt sein und sich sogar verzweigen.
So einfach ist die Sache auch nicht. Denn eine gewöhnliche Straße besitzt keine “Höhe”. Also sollten wir in diesem Falle schon korrekt bleiben und die Höhe nur dort angeben wo sie existiert.
Wann ist es notwendig die Hausdurchfahrt zu trennen. Geschwindigkeitsänderungen sind vielleicht nicht zu erwarten. Vielleicht aber Belagswechsel? Ein weiterer Grund könnte sich ändernde Höhen sein. Die im inneren viel höher ausfallen oder im weiteren Verlauf auch niedriger werden.
Außerdem versuchen wir bei der Lösungsfindung auch noch an das Indoormaping zu denken, was mit osm4D auch möglich werden soll.
hallo fkv,
bei der Thematik, die wir jetzt gemeinsam erwägen, ist eine perfekte Lösung wahrscheinlich deswegen schwierig, weil sie allmählich neue Anforderungen an einen durchschnittlichen User stellt. Die Technik, 3D dadurch zu erreichen, dass man bestimmte Elemente nach bestimmten Restriktionen taggen soll ist sehr fehleranfällig und für einen Anfänger umständlich zu erlernen.
Mit dem Taggingvorschlag welcher in Vorbereitung ist (Danke an Freunde die babei Helfen!!), kann man rein theoretisch ein Bauwerk von der Komplexität des Stephansdoms in Wien bauen.
Obwohl ich lange mit 3D arbeite wäre ich aber kaum in der Lage irgen Etwar richtig zu modellieren ohne dass ein unterstützender 3D Modeller steht.
Die Idee: in 3D zu basteln - (Tagging geschieht automatisch nache einem abgesprochenem und akzeptierten Shema im Hintergrung) - per drag and drop Elemente in 3D zu platzieren und leicht modifizieren können kann, wenn man sie in software umgesetzt hat, viele Fehler verhindern. Natürlich auch neue entstehen lassen. Wir wissen es noch nicht, aber ich bin mir sicher dass sich einige Leute auf die Modellierung von einigen Sehenswürdigkeiten stürzen werden.
Wir suchen weiterhin Helfer für die Implementierung der Funtionen der neuen Software. Je mehr wir sind, umso schneller werden die Ergebnisse kommen. Ich freue mich enorm über die Arbeit von Tordanik und Kendzi weil sie zeigt, dass Vieles möglich ist. Es ist aber auch klar, dass man zu zweit oder dritt die nötige Komplexität wahrscheinlich nicht so schnell schaffen kann.
[quote=viw]So einfach ist die Sache auch nicht. Denn eine gewöhnliche Straße besitzt keine “Höhe”. Also sollten wir in diesem Falle schon korrekt bleiben und die Höhe nur dort angeben wo sie existiert. […] Ein weiterer Grund könnte sich ändernde Höhen sein. Die im inneren viel höher ausfallen oder im weiteren Verlauf auch niedriger werden.[/quote] Bei maxheight braucht man für die ganze Durchfahrt nur den [EDIT: [del]größten[/del]] kleinsten Wert annehmen. Wenn aber die Raumhöhe gemeint ist, um die Gebäude bis ins letzte Detail 3d modeln zu können, dann gehört das eher über Tags am Gebäude und verschiedene Gebäudelayers gelöst als über Tags am Weg. Außerdem s.u.
[quote]Außerdem versuchen wir bei der Lösungsfindung auch noch an das Indoormaping zu denken, was mit osm4D auch möglich werden soll.[/quote] Vielleicht mache ich mir jetzt keine Freunde, aber ich finde, dass Indoormapping in einer Geodatenbank überhaupt nichts verloren hat. Mir kommt vor, dass einige Studenten OSM für ihre Projekte und Diplomarbeiten missbrauchen, die zwar durchaus herzeigbar sind und ihnen selber das Gefühl geben, etwas Großartiges zu schaffen, aber abseits vom Studium in Wahrheit keinen Nutzen bringen. Für diese Anwendungen gibt es bereits sehr spezialisierte Software (CAD etc.). So etwas in OSM zu machen ist so, wie wenn man in MS Word eine Tabellenkalkulation macht.
Naja, man muss sicher nicht jedes Detail erfassen, aber wir machen hier ja eine Karte und ich sehe keinen Grund, warum die mich zum Bahnhofseingang, aber nicht bis zum Gleis lotsen können sollte. Dafür braucht es aber nunmal auch ein wenig Indoormapping. Oder warum sollte mein Navi zu Fuß nicht durch das Kaufhaus abkürzen, wie ich das persönlich auch tun würde?