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
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.
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.
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.
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
@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.
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
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.
Gibt es denn schon erste Ergebnisse aus der Kodifizierungsrunde F3DB vom letzten Wochenende?
Alle ( wahrscheinlich nur ganz wenig âalleâ ) sind ganz gespannt darauf.
