Simple Indoor Tagging

Hi,

ich wollte euch hiermit auf unser Indoor-Tagging Proposal hinweisen an dem wir seit der letzten SOTM-EU gearbeitet haben. Das Proposal findet ihr hier: Simple Indoor Tagging.

Der Hauptgedanke ist, auf den Erfolg von S3DB aufzusetzen, indem man ein wirklich einfaches Proposal bereitstellt, das aber auch kompliziertere Fälle ohne großen Aufwand abdecken kann. Ich denke, dieses Ziel wurde erreicht und meine, dass das Proposal einen echten Mehrwert bietet. Es wäre nett, wenn sich alle Interessierten das Proposal mal anschaun würden und bei Fragen und Kommentaren uns diese mitzuteilen. Der ursprüngliche Thread befindet sich hier. Wer kein Englisch kann darf aber gerne auch hier kommentieren oder auf der Diskussionsseite des Proposals deutsch schreiben.

Ich schreib mal hier was in deutsch. Das in Englisch übersetzen nervt.

Beim Simple Indoor Tagging (habt ihr da nicht auch eine schöne Abk.?) vermisse ich folgendes:

  • Wichtig: Wie wollt ihr Indoor navigieren? Es sind keine Indoor-ways definiert!
  • Es fehlen Indoor Zonen z.B. Relax, Spielzone… Vielleicht areas? Das sind aber Bereiche, die wieder Zonen beinhalten.
  • Die Definition von Treppen und Rampen fehlt, hier muss eine Fläche so ausgewiesen sein, die in einen anderen level führt, und die Treppe sollte man modellieren können.
  • Die Definition von Böden und Decke vermisse ich auch.
  • Das ganze muss auch noch kongruent zum Außen 3D Tagging bleiben, wichtig sind Fenster, die aber auch schon von außen getaggt werden könnten ( auch ohne Indoor )
  • Gut finde ich, das man die Definition level einfach hält, und nicht komplizierte z.B building:indoor_level Konstrukte verwendet.

Vielleicht kann jemand das noch in die Erlanger Diskussion einwerfen, wenn mir noch was einfällt, schreibe ich hier noch was.

Grüße an alle Erlanger Diskussionsteilnehmer
Rolf

Braucht man nicht (die Wege).

Nette Idee, aber zusätzliche Komplexität die insofern auch nicht als Indoor-Element gemappt werden sollte (eher ein klassisches Einsatzgebiet für eine Relation).

Die Treppe -kannst- du modellieren, musst aber nicht, das Treppenhaus, resp. Liftschact dient als verbindenes Element.

Out of scope. Wir haben und wirklich aufs notwendige beschränkt, genau wie door und window kann man so was in einem seperaten Proposal integerieren.

Wie oben. Die 3d-Level Stockwerkdefinition ist aus praktischen Gründen nicht übertragbar auf die Indoor-Stockwerke. Falls tatsächlich nötig kann man mit Höhen an den optionalen level-outlines arbeiten.

Unser Vorschlag soll nicht alles mögliche abdecken, sondern ein minmales, einfaches Indoor-Schema definieren, die auch von Joe-Mapper umgesetzt werden kann.

Simon

Ich denke es sollte durchaus machbar sein, sich einen Navi-Graphen aus dem Modell zu errechnen. Einfach alle Türen in einer indoor=room|area miteinander verbinden und dann den kürzesten Weg unter einbehalten gewisser Regeln wie “muss innerhalb der Fläche sein”, “sollten möglichst 90 oder 45 Grad Winkel sein” usw. berechnen.
Bei Bedarf kann ich ja mal nen Python-Skript oder so anfangen…

Korrekt, es steht dir frei in einem indoor=* weitere Areas anzulegen.

An Rampen hatte ich bis jetzt noch gar nicht gedacht, das stimmt. Aber eigentlich ist das auch einfach ne besondere Art von Corridor. Muss halt der entsprechende Auswerter der Daten beachten.
Treppen sind durchaus enthalten. Man muss halt noch ein Sammlung an Values für den stairs=* Tag erstellen. Von konkreter Einzelmodellierung (vgl. https://wiki.openstreetmap.org/wiki/File:Indoor_steps1.png ) haben wir absichtlich abgesehen. Es macht auch keinen Spaß in einem Gebäude in dem eh alle Treppenhäuser gleich sind, jede Treppe einzeln zu zeichnen.

Ähm, was willst du den da genau angeben? Ob das nun Teppich oder Linoleum ist? Außerdem war die Idee was zu machen das einigermaßen einfach zu verstehen ist.

Fenster sind absichtlich nicht Teil dieses Vorschlags. Wie weit Indoor- und Outdoor-Level miteinander kompatibel sind wird sich in der Praxis zeigen.

Grüße aus München,
Andi

Hallo,

mir gefällt das Proposal sehr gut:

  • es kommt komplett ohne Relationen aus (wichtig für die Akzeptanz von Mappern, Editoren und Auswertern)
  • es ist sehr einfach zu verstehen
  • es benutzt einfache und teilweise schon etablierte keys (level, door, indoor, name, ref)
  • es beschränkt sich auf das Wesentliche und deckt trotzdem fast alle Situationen ab.

Wer entscheidet wie diese Indoor-ways verlaufen? In den wenigsten Gebäuden sind Wege gekennzeichent, d.h. man müsste für jede mögliche Verbindung einen way für das Routing einzeichnen.
Es gibt genug Algorithmen mit denen man einen Weg zwischen den einzelnen Türen berechnen kann. Davon abgesehen hilft mir ein “Gehen Sie geradeaus, dann in 5m halb rechts abbiegen und dann sofort rechts abbiegen” in einem Gebäude eher wenig. Viel hilfreicher wäre hier ein “Ihr Ziel befindet sich hinter der ersten Tür auf der rechten Seite” oder “Gehen Sie nach links durch den Korridor und benutzen Sie den Aufzug auf der rechten Seite um ins Erdgeschoss zu fahren.”

Für die wenigen Fälle, wo ein konventioneller Router indoor-Wege benutzen sollte (z.B. in Bahnhöfen oder Flughäfen), kann ja weiterhin highway=footway oder highway=corridor benutzt werden.

Dort wo es kein Treppenhaus gibt (z.B. die Rolltreppen in großen Kaufhäusern) wäre es aber schon interessant zu wissen, auf welche Seite der Rolltreppe man gehen muss, um in das gewünschte Stockwerk zu gelangen. Es wäre also durchaus interessant eine Möglichkeit zu haben, die Richtung einer Treppe (oder Rampe) anzugeben.

Könnte ja für Rollstuhlfahrer durchaus interessant sein oder um zu wissen wie schnell man um die Kurve rennen kann ohne auf die Nase zu fliegen. Es gibt ja den surface=*-tag für sowas.

Fenster würde ich jetzt auch nicht als Simple bezeichnen. Ich denke, dass wäre dann ein Fall für F3DB, genauso wie Türöffnungswinkel und detailliertes Treppenmapping. Wäre schön wenn man es schaffen könnte, dass F3DB als Ergänzung auf diesem simplen Schema aufbaut. Der gelegentliche Indoor-Mapper kann dann mit dem Simple-Indoor-Tagging die Umrisse der Räume einzeichen (ohne das komplette F3DB-Schema verstanden zu haben) und der Hardcore-Indoor-3D-Mapper kann dann noch Fenster, Türen, Treppensteigungen, Boden-, Wand- und Deckenbeschaffenheiten ergänzen. Bis auf ein paar keys die evtl. geändert werden müssten, sollten die beiden Schemata doch eigentlich kompatibel sein?

Es sollte auf jeden Fall vermieden werden, dass es zwei nebeneinander existierende Schemata gibt, die beide das selbe mit verschiedenen Tags beschreiben.

Viele Grüße

mapper999

F3DB ist als ein aufeinanderaufbauendes Schema zu verstehen. Wir sind soeben nach der ersten Kodifizierungsrunde, die nächste folgt morgen.
Für F3DB gibt es eine App,Eine WebAnwendung, ein JOSM preset und in absehbarer Zeit von der Uni Heidelberg eine 3D Anwendung. In Arbeit isteinImportfiltervon Industry Foundation Class Format (AutoCAD,ArchiCAD,Allplan umfassend) mit dem man 3D Modelle inclusive Wände, Türen, Fenster,Treppen,DeckenundDächer alsOSM Elemente importieren kann.

Ein simples Schema kann aber trotzdem sinnvoll sein.
Grüße,
Marek

Schau dir mal meine Versuche zum Flächenrouting an. Mir ging es um Fussgängerzonen, aber was mir den Weg über 3 Kneipen am Rathausplatz zeigt, sollte auch für 3 Büros auf dem Behördenflur passen. Und falls jemand im Gegensatz zu mir auch richtig programmieren kann, bringt er das vermutlich auch performant hin :wink:

Grüße, Max

Hallo, nochmal

@mapper999 Deinen Beitrag möchte ich voll zustimmen. Auch Indoor Wege müssen nicht sein, es sei denn ( z.B. EKZ ) wenn der Level 0 Weg eine Besonderheit darstellt und z.B. in der Stadt eine Abkürzung ist oder ein Unterschlupfweg darstellt etc. Dann mit den schon etablierten z.B. highway=corridor … ( mit entsprechenden Zusatztags ).
Ich denke, alle sonstigen Wege in ( selbst Großgebäude ) sind wirklich nicht einzustufen.

Bisher bin ich davon ausgegangen, das es hier zwei “Lager” gibt. Die einen wollen Simply, die anderen Full. Kann man das ganze nicht irgendwie “verschmelzen”.
Beim Simply ( mein Vorschlag zu einer Abk.: S3DBI ) sind wir in bezug auf 3D nur einen geringen Schritt weiter. Es bedeutet eigentlich nur eine 2D Karte innerhalb eines Gebäudes für jedes Stockwerk einzeln.
Das F3DB lässt nach weiteren Modifikationen aber ein volles 3D Bild des Gebäudekomplexes entstehen. Das dies mit den herkömmlichen JOSM Preset’s schwer umzusetzen ist, ist klar. Daher freue ich mich auf eine neue JOSM Erweiterung.
@ Erlangen. Bitte seht bei eurer Kodifizierungsrunde zu, das ihr eine Abstimmung hinbekommt, ein einfaches Indoor-Mapping mit dem F3DB Schema kompatibel zu machen.
Ich glaube, das macht viele angehende Indoor-Mapper glücklich und man kann das F3DB Schema in Ruhe weiter aufbauen.

Grüße Rolf

Danke für den Hinweis. Gibts den Code dazu auch irgendwo, oder war ich vorhin beim Querlesen der Wikiseite einfach nur zu blöd?

Danke im voraus,
Andi

Nee.

Du kannst ihn schon haben, wenn du versprichst nicht zu lachen. Aber hilfreich ist er sicher nicht. Da werden die Flächen aus einer osm2pgsql-Datenbank gezogen und in den Routinggraph von pgrouting gestopft. Das Testrouting fürs Ausdünnen passiert dann auch mit pgrouting. Das ist das Setup, das man hat, wenn man eigentlich nur Rendern wollte und dann doch ein bisschen mit Routen spielen will, nicht das, wenn man echt was damit anfangen möchte. Will ja niemand ernsthaft mit SQL routen…

Also klau dir lieber das Konzept (Der Herr couchmapper hats hier entdeckt, da sind auch paar Links dabei) und fang sauber an :wink:

Grüße, Max

Als die wichtigste Anwendung von Indoor Mapping, wenn es nicht nur um die Schönheit geht, sehe ich Indoor Navigation an.
In Frage kommen vor allem große öffentlich zugängliche Gebäude, die werden idR mehrstöckig sein.

Unverzichtbar für die Navigation ist die Zugehörigkeit zum Stockwerk. Das nur in einen Tagging-Wert zu stecken, scheint mit etwas zu “flach”. Ebenfalls unverzichtbar ist eine vernünftige (routingfähige) Lösung für den Übergang zwischen den Stockwerken (Treppen, Aufzüge, Rolltreppen, Rampen).

Die Ansätze zur Navigation über Flächen in allen Ehren, aber ich würde pragmatisch eingetragene Wege bevorzugen. Bei Korridoren ist das kein Problem, bei Flächen bietet sich eine Backbone-Strategie an, bei der ein oder zwei Wege die Fläche parallel zur Wand durchqueren. An die kann man dann die Wege aus den Gängen und ggf. aus Zimmertüren anbinden.
Die so entstehenden Routen mit rechten Winkeln sind zwar ein wenig länger, das fällt aber für die Navigation insgesamt weniger ins Gewicht, da fast alles irgendwo doch über Hauptknoten wie Treppen oder Eingangstüre laufen muss.
Die Verbindungen Tür zu Tür gehen quadratisch mit der Anzahl, mit Backbone dazwischen nur linear.

Gerade einen Beitrag auf WDR2 zum Burj Khalifa gehört, dort verlaufen sich regelmäßig Reinigungskräfte, die dann per Suchtrupp gesucht werden müssen. :sunglasses:

Viel Spaß beim Indoormappen :sunglasses:

Gibt es denn schon erste Ergebnisse aus der Kodifizierungsrunde F3DB vom letzten Wochenende?
Alle ( wahrscheinlich nur ganz wenig “alle” ) sind ganz gespannt darauf.

Grüße Rolf

Ja, wir haben erste Ergebnisse:

  1. Bin diese Woche krankgeschrieben.
  2. Tordanik machte Protokoll und wird dies wohl in Kürze veröffentlichen.
  3. Generell begrüßen wir alle die Autfeilung in “simple” und “advanced”.
  4. Wir hoffen bis zu der FoSSGIS Konferenz folgende Implementierung von F3DB:
  • als Blender Exportfilter
  • als Importilter aus Blender in OSM (gilt vor Allem für die Modellierung der Dächer)
  • als Importfilter aus IFC (stufenweise, mit einfachsten Elementen beginnend)
  • als Viewer in JOSM (Ausbau von Kendzi 3D)
  • in OSM2World

Viele Grüße,
Marek

Na, dann erst mal gute Besserung!

Die Aufteilung in “simple” und “advanced” ist voll ok. Das widerspiegelt wahrscheinlich den Wünschen aller, die sich damit beschäftigen.

Spätestens jetzt muß man sich doch mal mit dem Blender auseinandersetzen. Aber ok. Macht ja Spaß…

Kendzi 3D & OSM2World! Daumen hoch.

Danke, Marek.

Hallo,
da dieser Thread auch in der Wochennotiz 16-22.09.14 steht, möchte ich hier nur querverweisen auf momentane 3D / Indoor threads:

http://forum.openstreetmap.org/viewtopic.php?id=25316
http://forum.openstreetmap.org/viewtopic.php?id=27104

Im allgemeinen habe ich den Eindruck, 3D + Indoor Tagging hat verstärktes Interesse und damit Einzug gewonnen in der OSM Welt.