+1 Wäre toll. Dann gäb es damit keine Mißverständisse mehr.
Muß erst mal Gassi gehen. Da bettelt einer. Später vielleicht mehr…
Ich baue den Vorschag ein.
Grüße,
Marek
Ob ich die Frage jetzt stelle oder erst in ein paar Wochen, wenn ich davor stehe und es nicht zu taggen weiß.
Indoorwasserflächen (mit Bachlauf), Indoorgärtchen, Daueraustellungsflächen… eigentlich oft anzutreffen in größeren Gallerien und innerhalb des areas des meißt zentral gelegenen corridors. Wäre schade, wenn die untergehen. Voraussetzung, die Flächen haben eine entsprechende Größe.
Eigentlich sollten dann auch die tags indoor:water=pond, indoor:waterway=stream, indoor:leisure=garden und ggf. weitere neu überlegt werden.
Oder fange ich jetzt an zu spinnen, sagt es ruhig … 
Finde ich super!
Hab gar nicht dran gedacht. Das brauchen wir aber. Und es ist nur eben konsequent.
Na, wenn man einmal was sagt, dann folgt direkt ein ganzer Rattenschwanz.
Vielleicht sollte man mal drüber schlafen, bevor man alles ins Wiki packt.
Aber leider noch ein punctus cnactus: Wie geht man mit bisher getaggten POI’s und Shops, die als Node gesetzt sind, um.
Das haben unsere polnischen Freunde auch noch nicht konsequent umgesetzt bei ihren Indoor-Modellen.
Werden die Shops denn gerendert und auch von allen Apps erkannt, wenn man jetzt das Node auflöst und den Shop in einen “room” packt ( Mit allen was dazugehört, aber nicht die adress, die ist ja dem Gesamtgebäude zugeteilt oder doch? )
Und noch etwas wichtiges. Ich denke, das sollte auch ins Wiki, Marek.
Fluchtwege, Fluchttüren ( emergency_exit / bzw. escape door ) sollten irgendwie besonders gekennzeichnet sein. Oder gibt’s da schon was? Das diese Wege unbedingt erfasst werden sollten, ist klar. Aber nicht so konsequent, das die Fluchtpläne ausgehebelt werden.
Kleines Problem. Manchmal kann man Fluchtwege nicht einfach so benutzen, um diese zu mappen, man löst dann mitunter locker mal einen Alarm aus.
Apropos Fluchtplan. Welcher tag?
Hier gab’s auch schon mal eine Thread dazu. http://forum.openstreetmap.org/viewtopic.php?id=18058
Muß ich mir noch mal durchlesen.
Anhang: Klapps auf den Hinterkopf ( mein eigener ): Notausgang (evtl. mit Alarm) > entrance=emergency
Und wenn der Notausgang nun auf einem Flur ist, mittels Fluchttüre, umso besser. Dann werden diese eben auch erfasst, nicht nur die außenliegenden.
Die Shps können ruhig als Punkte bleiben. Denken wir an kleinere Verkausstands mitten in einer Galerie. Die haben oft keine Wände. Wichtig wäre, dass man konsequent die Stockwerkangabe macht.
Ist aber ein Laden wie z.B. C&A identisch mit einer Fläche, dann kann man ihn ja auch an die Fläche anhängen. Genau das machen wir ja auch wenn wir in einem Gebäude ein POI haben.
Um die Apps muß man sich keine Sorgen machen.Es ist dieeinfachte Sache der Welt einen zusätzlichen String bei dem Datenimport einzubauen. Haben wir mehr Objekte nach diesem Schema, ziehen alle nach.
Fluchtplan taggen: Weiß nicht. Wäre Dir dankbar wenn Du´s rausfindest. Ich mach jetzt haufenweise Überstunden um die Story mit dem Proposal abzuschließen. 
Dafür müssen sie zum Glück auf demFluchtplan gut ablesbar sein. Man kann´s abfotografieren…
Was mir beim schnellen Überfliegen aufgefallen ist:
Was ist mit Schiebetüren und Drehtüren? Beides sind in Einkaufszentren ja häufig anzutreffen.
Bisher scheinen jedoch nur “normale” Türen vom Tagging-Vorschlag abgedeckt zu sein.
Als zusätzliche Eigenschaft wäre auch ein ergänzendes Tag für barrierefreie Zugänge hilfreich (häufig ist ja der barrierefreie Zugang != Haupteingang)…
@Marek , F3DB
Da hat User “masti” nicht ganz unrecht mit dem opening:direction der Türen, etwas verwirrend.
Meißtens gibt es Flügeltüren oder Automatiktüren, natürlich auch Drehtüren bei öffentlichen Gebäuden. Ist alles auch noch nicht 100% festgemacht.
http://wiki.openstreetmap.org/wiki/Key:automatic_door ???
Barrierefreiheit (wheelchair) ist ja eigentlich immer an den entrances bei öffentlichen Gebäuden angesagt zu taggen, natürlich auch im Gebäude, wo es wichtig erscheint.
Absolut richtig! Ich habe die Bilder dafür fertig gehabt, ich baue es heute noch ein.
Zwischendurch hat aber der User Species etwas Schönes zusammengestellt:
https://wiki.openstreetmap.org/wiki/Proposed_features/door ich finde denTaggingvorschlag gut.
Es gibt ja auch den Content für Windows: https://wiki.openstreetmap.org/wiki/Key:window
Da bitte ich auch um Hinweise und Tipps.
Stimmt auch. Ich habe seit Monaten nur 2 Alternativen. Ich baute die erste ein.
Die zweite ist: Ich nehme zusätzlich die geografische Richtung dazu. Macht die Sache umständlich, der Usermuß aber nicht wissen, in welche Richtung die Wand geht.
Ich trege dies als Alternativeein, dann können wir weiter überlegen.
Keine gute Idee 
Das ist doch der Zugang für Rettungskräfte!
Besser wäre exit=emergency.
“exit=*” wird sowieso benötigt. Ich denke an Drehkreuze usw.
??? Wieso Zugang für Rettungskräfte? Die dürfen auch vorne rein. Ich kenne höchstens highway=service ; access=emergency als Zufahrt ( mit Pollern )
Ansonsten ist das tagging bei uns etabliert: http://wiki.openstreetmap.org/wiki/DE:Key:entrance
Der Tag exit_to=" " verwenden England und USA oft für Abfahrten auf highways. ( Selten bei uns ) Da käme es dann u.U. zu Verwechslungen.
Es reicht die Unterscheidung zwischen dem vorhandenen entrance=emergency und dem neuen, sagen wir Mal:
entrance=emergency_exit
bei dem gleich der Name sagt, dass man nur raus darf und nicht mehr rein…
Was glaubt ihr? Wäre das ok?
Ich meine, entrance kann sich nur auf die Außentüren bzw. den Ein- und Ausgängen eines Gebäudes oder Geländes beziehen und hat mit F3DB nicht viel zu tun.
Da kann eigentlich alles so bleiben. Für den neuen tag door=“” kann ja man noch Attribute dazupacken, wie door=exit, door=emergency_exit, door=service …
Oder soll man door=yes dann auch an den Zugängen zusätzlich taggen? Dann wird es kompliziert mit den Attributen.
Das ist notwendig weil wir für Routing wissen müssen, wo “Draußen” ebdet und wo “Indoor” beginnt.
Dies hat auch die EU Spezifikation und auch Open Geospatial Consortium.
Damit sie OSM in deren Formate “übersetzen” können verwenden wir entrance=* als Bezeichung für einen solchen Knoten.
Eigentlich ist, sagen wir Mal entrance=main auch immer door=yes. Es ist ein wenig lästig, ich gebe zu.
Ich habe leider keine andere Idee, wie man es lösen könnte.
Zwischedurch habe ich den Part http://wiki.openstreetmap.org/wiki/F3DB#Levels._Building_section_and_definition_of_height ein Wenig ergänzt.
Auch das Thema Dächer.
Bitte weiterhin um Feedback:
Was wäre von der Syntax besser: building:level:1=1.25 oder indoor:level:1=1.25
Ich platzierte auch einen Alternativvorschlag für Türaufschlagrichtung:
Die Idee:
Stehe ich im Flur und ist die klinke auf der linken Seite und die Tür öffnet sich in meine Richtung, dann ist es opening:direction=left
Stehe ich im Flur und ist die klinke auf der linken Seite und die Tür öffnet sich in Richtung Zimmer, dann ist es opening:direction=left_mirror
Das Problem bei diesem Ansatz sind leider Türen, die zwischen zwei gleiche Zimmer sind.
Dafür habe ich keine Lösung 
Das halte ich nicht für problematisch. Schließlich dienen ja die Werte der beiden Tags unterschiedlichen Zwecken: Der Wert von entrance gibt die Rolle des Ein-/Ausgangs an (Haupteingang, Service-Eingang, Notausgang, …), der Wert von door die Bauart der Tür (zumindest laut Door-Proposal).
Außerdem gibt es auch Ein-/Ausgänge, die statt mit einer Tür z.B. mit einem Drehkreuz versehen sind, unser örtliches Schwimmbad hat beispielsweise so einen Ausgang. Also ist entrance=* nicht immer gleichbedeutend mit door=*.
Mir gefällt die Lösung, das über die Richtung des Wand-Ways zu machen, am besten.
Ich bin nicht begeistert von der Idee, jedes Tag in zwei Versionen (einmal für indoor, einmal für outdoor) zu haben. Da würde ich es eher den Renderern aufbürden, diese Objekte auszufiltern, wenn sie sie nicht haben wollen. Das könnte ja z.B. über den level-Schlüssel gehen.
Ich bevorzuge sie auch. Sie ist eindeutig.
Schön und gut, verstehe ich auch. Aber wer kümmert sich drum? 
Klar, es sind ja “nur” Wys die stören. Wenn Du eine Lösung beisteuern könntest, wären wohl alle zufrieden.
Hallo,
Türaufschlagrichtung: Die Skizze wäre noch anschaulicher und eindeutiger, wenn du noch beschriftest: Dein Standort (ein Punkt), deine Richtung (Pfeil) und die Räume (floor, room). Dann bedarf es auch keinerlei Text mehr.
Dein neuer Vorschlag mit indoor:zone= X ist interessant. Also alle Bereiche, die nicht mit Wänden eindeutig abgetrennt sind.
Kann man den neuen tag dahingehend erweitern, das man alles mögliche dort unterbringen kann, wie indoor:zone=
(deine Vorschläge) ; decoration ; show ; exhibition ; gastronomy ; waiting area ; artificial pond ; artificial stream …
Diese Bereiche lassen sich wahrscheinlich meißt nicht genau ausmessen, im Gegensatz zu den rooms ( das Thema hatten wir schon ), so das man schätzen muss. Macht aber kaum was aus, denke ich.
Dann hätten wir 2 oder 3 Fliegen mit einer Klappe …
Soll die Höhe über Grund angeben, nicht wahr?
Gefällt mir eigentlich beides nicht so richtig. Ist hier nicht eindeutig, was verlangt wird. Wie wär’s mit building_height:level:1=1.25
Noch eins: Wenn man von einen indoor way auf einen elevator (meist als Fläche) trifft, soll dann der Verbindungspunkt als door getaggt werden?
Erst mal genug Unsinn verzapft.
Rolf
Eingebaut.
Ich baue morgen eine Skizze aus der Bauordnung mit der Beschreibung auf Deutsch ein, die das eindeutig formuliert. Meine Schwäche ist leider mittelmäßges Englisch.
Es eigentlich um etwas Einfaches: Ist das Gelände flach, haben wir EINE Höhe über Grund. Haben wir schräges Gelände ist der niedrigste Punkt von dem Gelände für die Höhenangaben maßgebend.
So macht man´s in der Baubranche.(Es sei denn, dass man einen andern Bezugspunkt extra definiert.
building_height:level:1=1.25 - ist ok.
Was sagen die Anderen dazu?
M.E.: Erst einmal ein Beispiel soweit wie bisher diskutiert mappen und dann weitere Vorschläge/Änderungen/Ergänzungen an diesen Objekt diskutieren/probieren (geht über studieren).