Tagging von Hausdurchfahrten

Wie wäre es mit tunnel=passage, um klarzustellen, dass diese Durchfahrt auf dem Niveau der Gebäudeaufstandsfläche liegt ?

tunnel=passage
plus
passage=<passage_type> oder passage_type=<passage_type>
könnte mir gefallen. 😉

Wobei man das passage(_type)=xyz auch mit covered=yes kombinieren kann. Müsste man mal schauen,
was derzeit öfter getaggt ist bei Hausdurchfahrten (tunnel oder covered).

Zu Tunnel, covered und so haben wir hier schon einmal vortrefflich gestritten. Natürlich ohne konkretes Ergebnis 🙄
http://forum.openstreetmap.org/viewtopic.php?id=12474

Der überdachte Weg sollte IMHO auf jeden Fall durch ein Tag identifiziert werden. Es geht ja nicht nur nur um 5 m lange Hausdurchgänge, sondern beispielsweise auch um kilometerlange Galerien auf Gebirgsautobahnen, wo es recht wahrscheinlich ist, dass der Weg in mehrere Teile zerlegt wird.
Der Vorschlag mit tunnel=passage gefällt mir gut, dann könnten wir das umstrittene covered=yes ausmustern.

Zusammengefasst würden die Wege etwa so getaggt:

"Echter" Tunnel (in die Erde gebohrt, gegraben):

• highway=<xyz>
• tunnel=yes
• layer=-1 (oder ein anderer Wert, der tiefer ist als die nächsthöhere Ebene)

Ebenerdiger Durchgang durch Gebäude, Galerie:

• highway=<xyz>
• tunnel=passage
• passage_type=<xyz>
• layer=0 (als Standardwert üblicherweise weggelassen; das durchfahrene Gebäude hat ebenfalls layer=0)

MetiorErgoSum wrote:

... dann könnten wir das umstrittene covered=yes ausmustern.
...

Aber nicht ganz, denn da bleiben noch einige Verwendungszwecke. Die im Moment in Bearbeitung befindliche Wiki müsste dann aber komplett umgearbeitet werden
http://wiki.openstreetmap.org/wiki/DE:Key:covered (engl. auch)
und für eine ganze Weile werden wir zwei Erfassungsvarianten haben, den per Bot kommen wir wegen der covered-Bedeutungen, die nichts mit Hausdurchgängen usw. zu tun haben, nicht weiter.

hurdygurdyman wrote:

Wie wäre es mit tunnel=passage, um klarzustellen, dass diese Durchfahrt auf dem Niveau der Gebäudeaufstandsfläche liegt?

Obwohl ich ja die Meinung vertrete, ein Tunnel ist ein Weg, der durch ein anderes Objekt (ob Hügel/Berg oder Haus) geht, gefällt mir tunnel=passage sehr gut. Das harmoniert auch mit tunnel=culvert für Durchlässe von kleineren Wasserläufen/Entwässerungsgräben.

Ein wesentlicher Vorteil wäre, dass die leidige Diskussion über den angemessenen Layer-Wert damit entfallen kann.
covered=yes kann dann auf die Fälle beschränkt werden, in denen ein Weg schlicht zum Schutz vor den Elementen überdacht ist.

Edbert (EvanE)

Hi,
da war in Rostock durch den Gebäude-Import vermutlich einige der ersten waren, die mit dem "Problem" der Hausdurchfahrten (gibt es hier in Ostdeutschland quasi bei jedem Plattenbau Gebiet zu Hauf...), haben wir das damals natürlich ganz naiv mit tunnel=yes erfasst. Die Idee wie Marek hatten wir damals auch (jedoch nicht konsequent durchgezogen) und ich verstehe, dass da die Auswertung ziemlich teuer ist (ähnlich wie ein prüfen auf Schnitt oder Nutzung der Länge um sowas abzuschätzen).

So ganz leuchtet es mir nicht ein, wieso man einen Tunnel unter ein Haus graben sollte, aber solche Fälle mag es sicherlich geben. Wenn dadurch die Renderer nicht durcheinander kommen, hab ich auch nix gegen tunnel=passage.

Das covered=yes aber bitte lassen, das haben wir hier öfters mal für so seperate überdachte Gänge zum "lustwandeln" mit Geranien genutzt. Quasi langgezogene Pavilions 😉

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 😉

Wolfgang B wrote:

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.

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:3 … 8Tunnel.29 platzieren.

marek kleciak wrote:

...
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!
...

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/t … ssage#wiki (209)
http://taginfo.openstreetmap.org/keys/b … age#values (106)

hurdygurdyman wrote:

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.

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

hurdygurdyman wrote:

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.

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.

!i! wrote:

So ganz leuchtet es mir nicht ein, wieso man einen Tunnel unter ein Haus graben sollte, aber solche Fälle mag es sicherlich geben. Wenn dadurch die Renderer nicht durcheinander kommen, hab ich auch nix gegen tunnel=passage.

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*

marek kleciak wrote:

...

@Wolfgang B:
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!
...

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

mdk wrote:

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.

marek kleciak wrote:

ich weiß nicht ob ich richtig verstehe, was mit der Galerie gemeint ist.

Mit Galerie ist so ein (nur auf einer Sete offenes) Bauwerk gemeint:
http://de.wikipedia.org/wiki/Galerie_%2 … bauwerk%29

mdk

Hallo mdk- es ist ein sehr guter Hinweis. Ich denke darüber nach!

Tordanik wrote:

Mein Eindruck ist, dass derzeit solche Durchfahrten oft als tunnel=yes eingetragen werden - also mit demselben Tag, mit dem man auch einen Tunnel unter einem Haus eintragen würde. Bei Renderern wie Mapnik bringt das die gewünschte Darstellung. Für 3D ist die Unterscheidung zwischen den beiden Fällen allerdings absolut relevant.

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.

• Vor einigen Monaten hatte ich dieses Thema auf talk-de angesprochen. Dort gab es den Vorschlag, covered=yes für diesen Fall einzusetzen. Das ist daher auch das Tagging, das OSM2World derzeit verwendet.
  

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?

• Marek hat noch einen anderen Vorschlag:
  

marek kleciak wrote:

Wir haben uns in Garching beim letzten Meeting auf ein Schema: http://wiki.openstreetmap.org/wiki/DE:3 … 8Tunnel.29 geeinigt.

Praktisch bedeutet es: Damit ein Weg mit Tunnel:yes als eine erdgeschossige Durchfahrt von einem Gebäude erkannt wird, müssen seine Anfang- und Endpunkt auf dem Gebäudeumriß liegen.

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.

Hier sehe ich allerdings mindestens das Problem von aufgetrennten Ways. Generell muss es ja möglich sein, eine Hausdurchfahrt auch aufzutrennen, weil nur so Attribute oder Relationen auf einzelne Teile angewendet werden können. Dadurch könnte es im Extremfall zu Wegstücken kommen, die zwar als tunnel=yes getaggt sind, aber eben doch keinen gemeinsamen Knoten mit dem Gebäudeumriss haben.

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.

fkv wrote:

• Marek hat noch einen anderen Vorschlag:
  

marek kleciak wrote:

Wir haben uns in Garching beim letzten Meeting auf ein Schema: http://wiki.openstreetmap.org/wiki/DE:3 … 8Tunnel.29 geeinigt.

Praktisch bedeutet es: Damit ein Weg mit Tunnel:yes als eine erdgeschossige Durchfahrt von einem Gebäude erkannt wird, müssen seine Anfang- und Endpunkt auf dem Gebäudeumriß liegen.

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.

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.

fkv wrote:

Hier sehe ich allerdings mindestens das Problem von aufgetrennten Ways. Generell muss es ja möglich sein, eine Hausdurchfahrt auch aufzutrennen, weil nur so Attribute oder Relationen auf einzelne Teile angewendet werden können. Dadurch könnte es im Extremfall zu Wegstücken kommen, die zwar als tunnel=yes getaggt sind, aber eben doch keinen gemeinsamen Knoten mit dem Gebäudeumriss haben.

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.

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.

viw wrote:

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.

Bei maxheight braucht man für die ganze Durchfahrt nur den [EDIT: größten] 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.

Außerdem versuchen wir bei der Lösungsfindung auch noch an das Indoormaping zu denken, was mit osm4D auch möglich werden soll.

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?

errt wrote:

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?

Footways und Steps in Stationen und Unterführungen hab ich selber schon gemappt. Dafür braucht man keine speziellen Tags und schon gar keine Höhen. Soweit ich es verstehe, geht es hier doch um mehr.

Wir sind so ziemlich alle in Unklarem, was geht, und was nicht und wie es in Zukunft funtioniert und werden wohl viele Fehler machen bis wir eine Form gefunden haben, die akzeptiert und leben wird. Ich habe daher nichts gegen Kritik, Vorschläge, Gegenargumente. So Etwas hat noch niemand probiert, nicht mal Google hat sich getraut. Wenn es aber funktioniert dann sehen alle kommerziellen, inklusive Google ziemlich alt aus. Und ehlich: darauf habe ich Lust 🙂

geri-oc wrote:

...

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)

wobei m.E. das eine mit dem anderen nur wenig zu tun hat. building=roof wird ja auf dem überdeckenden Element angewandt (und nur dann, wenn es ein Dach ist), während covered=yes genauso wie tunnel=yes auf dem überdeckten Element getaggt wird.

Ich bin für covered=yes für Hausdurchfahrten, zumindest aber bei Brückenkontruktionen (oft Gebäude) über einem Weg (auf dem Weg). covered=yes behält also in jedem Fall seine Berechtigung.

viw wrote:

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.

Klar gibt es zu Straßen genauso wie zu anderen Wegen auch eine Höhe. Heisst Luftraumprofil, und ist bei der Straßenplanung und -instandhaltung wichtig. Erst recht hat eine überdeckte Straße eine lichte Höhe. Ich würde diese mit height taggen. Probleme gibt es (wie immer in ähnlichen Situationen) nur bei sich ändernden Höhen, weil wir kein tag haben, um zwischen stufenlosem und gestuftem Übergang zu unterscheiden (genauso wie wir kein Tag haben um eine als Polygonzug angenäherte Kurve von einem echten Polygonzug zu unterscheiden (naja, fast keins, es gibt ein Osmrender-subtag dazu)).

fkv wrote:

Bei maxheight braucht man für die ganze Durchfahrt nur den 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.

bei maxheight gibt es natürlich nur einen Wert: der der auf dem Schild steht (rechtliche Höhenbeschränkung), alles andere gehört in andere tags.

dieterdreist wrote:

...
wobei m.E. das eine mit dem anderen nur wenig zu tun hat. building=roof wird ja auf dem überdeckenden Element angewandt (und nur dann, wenn es ein Dach ist), während covered=yes genauso wie tunnel=yes auf dem überdeckten Element getaggt wird.

Ich bin für covered=yes für Hausdurchfahrten, zumindest aber bei Brückenkontruktionen (oft Gebäude) über einem Weg (auf dem Weg). covered=yes behält also in jedem Fall seine Berechtigung.

Und wir drehen uns im Kreise 🙄
http://forum.openstreetmap.org/viewtopi … 13#p201913
tunnel heißt nicht "bedeckt" sondern "röhrenförmig hindurch". Somit ist covered keine Durchfahrt.

Ergänzende Frage:

Benötigt covered=yes einen layer?

Ich habe einen Vorschlag auf der Seite
http://wiki.openstreetmap.org/wiki/DE:3 … Durchfahrt
platziert. Bitte im unteren Abschnitt lesen.

Grüße,
Marek

marek kleciak wrote:

Ich habe einen Vorschlag auf der Seite
http://wiki.openstreetmap.org/wiki/DE:3 … Durchfahrt
platziert. Bitte im unteren Abschnitt lesen.

Ist das noch OSM?

Radeln wrote:

marek kleciak wrote:

Ich habe einen Vorschlag auf der Seite
http://wiki.openstreetmap.org/wiki/DE:3 … Durchfahrt
platziert. Bitte im unteren Abschnitt lesen.

Ist das noch OSM?

Was ist es denn sonst? Es geht darum die Gegebenheiten nicht nur wie auf einer Landkarte zu erfassen, sondern so wie sie wirklich da sind. Genauso kann man fragen ob Fahrradrouten oder ÖPNV Linien noch osm sind. Natürlich sind auch Wälder strenggenommen keine Straßen mehr.
Aber in einer freien Geodatenbank, denke ich hat das ebenso seine Bereichtigung wie Maxspeed und maxheigth.

marek kleciak wrote:

Ich habe einen Vorschlag auf der Seite
http://wiki.openstreetmap.org/wiki/DE:3 … Durchfahrt
platziert. Bitte im unteren Abschnitt lesen.

Grüße,
Marek

Zur Gallerie:
Was haltet ihr von:
covered=yes
closed_side=right/left (im Bezug auf die Richtung des ways)

closed_side=right/left (im Bezug auf die Richtung des ways) - Gute Idee Michael!
Bitte in die Wiki Seite gleich eintragen!

Grüße,
Marek

Den Tag "geschützt/bedeckt" und "geschlossene Seite" finde ich eher unpassend.

Ich währe eher dafür, dass alle "tunnelähnlichen" Gebilde den Key tunnel bekommen.

für Galerie würde mit folgendes besser gefallen:
tunnel=galerie
galerie_open=left/right
oder
galerie=left/right

einfallen würde mir noch:
galerie_type=säulen oder pfeiler / fenster(nicht solche aus Glas, sondern Aussparungen im Mauerwerk) / offen
galerie_access= [welcher Zugang durch die Öffnung erfolgen kann]

Was haltet ihr davon?

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.

Nochmal zur Erinnerung: http://wiki.openstreetmap.org/wiki/DE:3 … Durchfahrt

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:
1. 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.
2. Zusätzlich kann dieser Punkt z.B. als Tor, Zaun, Entrace=yes beschrieben werden
3. Für den Renderer wir es wahrscheinlich einfacher, einen gemeinsamen Punkt zu haben als ihn zu berechnen.

marek kleciak wrote:

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.

Denke die Fälle sind schon klar:

Weg durch das Gebäude:
tunnel=passage + layer=0 (layer=0 würd ich explizit auch hinschreiben damit es klar ist)

bei "Weg unterhalb eines Hauses" und "ganz unterhalb eines Hauses" weiß ich grad nicht welchen Unterschied du meinst:
tunney=yes + layer=-1 !?

ich nehme mal an, dass bei beiden Fotos der Weg auf der Gebäudekante gezeichnet wird?
[1] http://www.stahlbau-standke.de/pics/con … age-16.jpg
[2] http://upload.wikimedia.org/wikipedia/c … _Dom_4.jpg

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.

flaimo wrote:

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.

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.

flaimo wrote:

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.

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. 🙂

Tordanik wrote:

flaimo wrote:

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.

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.

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.

JM2C
Edbert (EvanE)

EvanE wrote:

Wegen bisher 266 Verwendungen sehe ich keinen Grund, dieses lange Wort zu bevorzugen. In meinen Augen reicht tunnel=passage völlig aus.

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. 😉

Zudem finde ich, dass building_passage eine zu spezifische Aussage ist, also die Verwendung unnötig weit einschränkt.

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.

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.

Absolut.

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.

flaimo wrote:

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.

Nahmd,

dieterdreist wrote:

(genauso wie wir kein Tag haben um eine als Polygonzug angenäherte Kurve von einem echten Polygonzug zu unterscheiden (naja, fast keins, es gibt ein Osmrender-subtag dazu)).

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.

Gruß Wolf

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.)

Gruß Masi

MasiMaster wrote:

Ich bin immernoch für "tunnel=gallery" als zu einer Seite hin offenem Tunnel.)
Gruß Masi

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 :-)

Die Stichworte Galerie + Tunnel liefern u. a. http://www.panoramio.com/photo/6316208

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.

flaimo wrote:

ist das wirklich der richtige begriff für sowas? wen ich nach gallery suche finde ich nur einen haufen bilderaustellungen :-)

Auf Wikipedia findet man leider nur die in den Bergen: http://de.wikipedia.org/wiki/Galerie_(Verkehrsbauwerk)

flaimo wrote:

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.

Meinte auch eher sowas:
http://de.wikipedia.org/w/index.php?tit … 0918061636
http://de.wikipedia.org/w/index.php?tit … Inside.jpg
http://de.wikipedia.org/w/index.php?tit … 0216004925
http://home.fotocommunity.de/chor/index … d=20115380 (nicht frei)

MasiMaster wrote:

Meinte auch eher sowas: [...]

Das sind Arkaden.

RFC: https://wiki.openstreetmap.org/wiki/Pro … ng_passage

fkv wrote:

MasiMaster wrote:

Meinte auch eher sowas: [...]

Das sind Arkaden.

Ohh ok, Bild 2 & 4 sind Arkaden (bzw. Arkadengang), also kein Tunnel.
1 & 3 sind meiner Ansicht nach eher Tunnel (weil man seitlich nicht raus kann).

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.

Da fehlt soweit ich gerade auf die Schnelle sehe, noch die Unterscheidung zwischen tunnel=* und covered=*.

@Flaimo: Warum hast du es immer so eilig? Wenn ein Proposal gebraucht wird, werden es Leute über die Suchfunktion finden und weitere Kommentare abgeben. Das geht so über Monate. Das kann man nicht beschleunigen.

Fabi2 wrote:

Da fehlt soweit ich gerade auf die Schnelle sehe, noch die Unterscheidung zwischen tunnel=* und covered=*.

Ja, ich hab das schon in Beitrag #49 geschrieben und auf der Talk-Seite auch. Flaimo hat es als resolved markiert, aber richtig geklärt sieht es mir noch nicht aus. Ich würde weiterhin die Definition bevorzugen, dass covered=* genau dann zu verwenden ist, wenn etwas zur Seite offen ist. Also covered=avalanche_protector statt tunnel=avalanche_protector.

fkv wrote:

Fabi2 wrote:

Da fehlt soweit ich gerade auf die Schnelle sehe, noch die Unterscheidung zwischen tunnel=* und covered=*.

Ja, ich hab das schon in Beitrag #49 geschrieben und auf der Talk-Seite auch. Flaimo hat es als resolved markiert, aber richtig geklärt sieht es mir noch nicht aus. Ich würde weiterhin die Definition bevorzugen, dass covered=* genau dann zu verwenden ist, wenn etwas zur Seite offen ist. Also covered=avalanche_protector statt tunnel=avalanche_protector.

Da schließe ich mich an, siehe Talk-Seite. Weil das ist, nach dem bisherigen Diskussionsstand, das eizige was gut und klar überall abzugrenzen und zu unterscheiden ist, und das deckt vor allem dann auch mit der ursprünglichen coverd=*-Definition, z.B. für Sachen wie Tankstellendächer. Hausdurchfahrten sind eben kurze, ebenerdige Tunnel, da war die tunnel=yes-Verwendung wie z.B. in Rostock also völlig OK, nur hier geht es ja um die Präzisierung der Tunnelart.

fkv wrote:

@Flaimo: Warum hast du es immer so eilig? Wenn ein Proposal gebraucht wird, werden es Leute über die Suchfunktion finden und weitere Kommentare abgeben. Das geht so über Monate. Das kann man nicht beschleunigen.

Fabi2 wrote:

Da fehlt soweit ich gerade auf die Schnelle sehe, noch die Unterscheidung zwischen tunnel=* und covered=*.

Ja, ich hab das schon in Beitrag #49 geschrieben und auf der Talk-Seite auch. Flaimo hat es als resolved markiert, aber richtig geklärt sieht es mir noch nicht aus. Ich würde weiterhin die Definition bevorzugen, dass covered=* genau dann zu verwenden ist, wenn etwas zur Seite offen ist. Also covered=avalanche_protector statt tunnel=avalanche_protector.

die definition hast du eh selber in deinem ersten absatz geliefert (wodurch sich auch tunnel für avalanche_protector ergibt). abgesehen führt das proposal nur neue values ein, und keine definition von bestehenden keys. sowas gehört auf die talk pages der jeweiligen wiki-seiten. da die values des proposals eindeutig sind, können sie problemlos mittels bot umgemappt werden sollte die die definition der keys später doch ändern.

und ab jetzt bitte auf der talk page weiter machen und nicht hier; ihr schließt damit nämlich schon wieder die internationale osm gemeinschaft aus der diskussion aus.

RFC-Phase war lange genug. Voting hat jetzt begonnen: https://wiki.openstreetmap.org/wiki/Pro … ng_passage

flaimo wrote:

RFC-Phase war lange genug. Voting hat jetzt begonnen: https://wiki.openstreetmap.org/wiki/Pro … ng_passage

Da enthalte ich mich, siehe Diskussionsseite. Weil die teiloffenen Teile sind ist für mich covered=* und alle geschlossenen tunnel=*.

Fabi2 wrote:

Da enthalte ich mich, siehe Diskussionsseite. Weil die teiloffenen Teile sind ist für mich covered=* und alle geschlossenen tunnel=*.

Diese Unterscheidung finde ich im Proposal in der Tat auch nicht gut gelöst - ist mir allerdings nicht sofort aufgefallen. Das tunnel=building_part als Lösung des Problems, mit dem ich den Thread gestartet hatte, finde ich gut. Bei z.B. dem avalance_protector ist die Wahl des Schlüssels aber unbefriedigend und das Thema scheint auch auf der Diskussionsseite nicht zu Ende diskutiert worden zu sein.

Tordanik wrote:

Fabi2 wrote:

Da enthalte ich mich, siehe Diskussionsseite. Weil die teiloffenen Teile sind ist für mich covered=* und alle geschlossenen tunnel=*.

Diese Unterscheidung finde ich im Proposal in der Tat auch nicht gut gelöst - ist mir allerdings nicht sofort aufgefallen. Das tunnel=building_part als Lösung des Problems, mit dem ich den Thread gestartet hatte, finde ich gut. Bei z.B. dem avalance_protector ist die Wahl des Schlüssels aber unbefriedigend und das Thema scheint auch auf der Diskussionsseite nicht zu Ende diskutiert worden zu sein.

Stimmt, tunnel=building_part ist noch besser, weil ist ja nicht gesagt, das der Tunnel im Gebäude immer durchgängig ist! Ich denke da an das Mikromapping von z.B. Parkhaus-/Tiefgarageneinfahrten und anderen ähnlichen Einfahrten, die stückweise ein Tunnel sein können, aber nicht durch das Gebäude gehen.

Fabi2 wrote:

Stimmt, tunnel=building_part ist noch besser, weil ist ja nicht gesagt, das der Tunnel im Gebäude immer durchgängig ist! Ich denke da an das Mikromapping von z.B. Parkhaus-/Tiefgarageneinfahrten und anderen ähnlichen Einfahrten, die stückweise ein Tunnel sein können, aber nicht durch das Gebäude gehen.

Äh, ich meinte eigentlich tunnel=building_passage. 😄 Obwohl deine Argumentation auch was hat.

Tordanik wrote:

Fabi2 wrote:

Stimmt, tunnel=building_part ist noch besser, weil ist ja nicht gesagt, das der Tunnel im Gebäude immer durchgängig ist! Ich denke da an das Mikromapping von z.B. Parkhaus-/Tiefgarageneinfahrten und anderen ähnlichen Einfahrten, die stückweise ein Tunnel sein können, aber nicht durch das Gebäude gehen.

Äh, ich meinte eigentlich tunnel=building_passage. 😄 Obwohl deine Argumentation auch was hat.

Da wäre aber das Problem der Abgrenzung von Einfahrt bzw. von "Eingang" (entrance=*) im Allgemeinen! Ist der 5 cm breite Türrahmen auch schon ein Tunnel?