Ekhm,
ich mir habe einige Bereiche angesehen, wo man versucht Indoor mapping zu machen.
Irgendiwe komme ich zu dem Schluß, dass ein Gehweg in einem Flur eine ander Kategorie sein sollte als das gute highway=footway da draußen.
Bei aller Liebe zu Mapnik und dem Team der an Mapnik arbeitet:
Wann gab es dort eine wirklich nennenswerte Änderung?
Die ereiche wo man versucht indoor wege innerhalbe eines Gebäudes zu zeichnen sehen besch… eiden aus.
Eine kategorie highway=indoor würde die Probleme mit dem Rendering erleichtern da der Mapnik sie einfach nicht anzeigen würde und für die Indoor Navigation wäre sie da.
Auch die Anfänger würden hier eine saubere Trennung sehen:
Was im Gebäude ist, ist Was anderes.
Nur so gesponnen nach gestriger Hitze in meinem indoor Zimmer…
+1
Du hast ja so recht. Ich warte auf den Tag , an dem eine Horde vom GPS geleiteter Fußgänger durch meinen Büroflur rauschen und die dort durch akribisches indoor-mapping erfassten Toilette aufsuchen, weil highway=footway und amenity=toilette verwendet wurden.
Solange amenity=toilette und nicht amenity=toilets verwendet wird sollte es sich in Grenzen halten
Ein room=indoor? Oder eher building=indoor?
Ernsthaft: Ich bin mir nicht ganz sicher ob ich das für alle Wege in einem Gebäude gut finden würde (Gebäude, die sich auf einem Fussweg hindurch passieren lassen?). Für die meisten wäre es vermutlich sinnvoll eine Unterscheidung zu haben, bei der es zum Ausblenden reicht, wenn man sie “vergisst”.
@Marek:
Dass “indoor” in einer gewissen Weise ein eigenes Tagging-Schema braucht unterstütze ich auch, aber:
Weil dieser Fall nicht eintreten wird und bei reiner GPS-Navigation zB alles was “indoor” ist rausfallen kann, da ein GPS in einem Gebäude noch immer nicht funktioniert…
Nun, wenn Du in dem Finanzamt arbeitest, oder einer anderen Behörde die offen für´s Publikum ist, wäre das in Ordnung.
Mit access=private, access=no bzw access=emergency only ( ) kannst Du sicherstellen, dass niemand reinkommt.
Zu Deiner Anmerkung, rayquaza: Natürlich, die Wege hindurch sollten als highway=footway bleiben (z.B. oben verglast; eher eine Passage die rund um die Uhr einen Weg darstellt). Oder highway=pedestrian, cycleway etc…
Für mich wäre ein highway=indoor ein Weg in einem Gebäude, welches gewisse Öffnungszeiten hat, bzw sich abschliessen läßt (Flughafen, Bahnhof, Museum, Theather, Kinokomplex, Krankenhaus, Universität, Behörde, Einkaufszentrum).
Nun, ich maße mir nicht an, ein Schema dafür allein zu entwickeln, ich sehe jedoch Handlungsbedarf. Es gibt hier in Forum einige Leute die wirklich geniale Vorschläge zum Tagging machen (meine ich wirklich ernsthaft).
In den meisten Gebäuden die ich kenne ist der Boden (mit Ausnahme der Wände :-)) durchgehend begehbar, sprich das erfassen von einzelnen Wegen ist nicht nötig, macht z.B. http://wiki.openstreetmap.org/wiki/IndoorOSM auch nicht.
Was IMHO im Augenblick fehlt (Leute die mein Keynote in Rapperswil gehört haben, wissen, dass die Vielzahl an halbfertigen Projekte in OSM mich sehr ägert):
ein Indoor Schema auf das sich alle Entwickler einigen (ala Simple 3D Model)
Kompatibiltät mit dem 3D Mapping (es macht wenig Sinn fast gleichlautende Tags für den gleichen Sachverhalt zu haben siehe buildingpart vs. building:part)
Unterstützung um die Daten mobil anzuzeigen, z.B. in Mapsforge
Dass momentan die IndoorOSM die Wege als solche nicht erfasst ist bekannt, jedoch ein Mangel, da die Kalkulation einer Strecke entlang eines Weges zu einem Punkt (z.B. Schalter am Flughafen) einfacher wäre. und zwar für alle, die Applikationen entwickeln wollen.
Du hast Recht:
die Entwickler müssen sich auf ein Indoor schema einigen, deswegen spreche ich´s an.
Kompatibilität mit dem 3D Mapping muß sein. Daher ein Vorschlag in OSM-4D. Ich baue es aus jedoch ohne konkrete Worte für die Tag / Value - es gibt hier viele Leute die dies besser machen als ich.
Machen wir Nägel mit Köpfen, wird auch die Unterstützung seitens der Anwender (Mobile) kommen.
Sicher ist es möglich, verursach aber für alle die sich damit befassen, deutlich höheren Aufwand bei der Programmierung.
Nutzen wir eine hybride Lösung (Fläche UND Weg), kann man sofort OSM indoor mit Navi Funktion haben. Und das auf allen Applikationen.
Außerdem ist die Kalkulation deutlich schneller.
GIbts den im Augenblick eine OSM Routinglösung die Routing entlang der Rändern einer Fläche nicht unterstützt? Natürlich genügt das alleine nicht, da man ja Wände auch berücksichtigen müsste (also ev. aus der Fläche ausstanzen beim Verarbeiten, oder die Fläche ignorieren und den Wänden nach routen) und für mehrere Stockwerke muss man irgend eine Treppen/Lift Lösung haben. Für viele Anwendungen, ausser den “ich hab einen grossen Platz und will quer darüber” Fall dürfte das gar nicht so schlecht sein.
Und für den “grossen Platz” Fall: nehm mal dein Beispiel mit den Schaltern im Abfertigungsgebäude am Flughafen vor, mit sagen wir 20 Schaltern und ein halbes Dutzend Eingängen, ausser du machst irgend eine Sterntopologie mit den Wegen (hässlich) ist doch das einzelne Wege erfassen hoffnungslos.
Simon
PS: so oder so auch wenn das automatiserte Indoor-Routing in der Zukunft wichtig sein wird, eigentlich brauchen wir -jetzt- vorallem eine Lösung um das ganze stockwerksweise anzuzeigen.
Zugegeben: Die Sterntopologie ist hässlich. Deswegen werde ich einige Fallbeispiele erarbeiten, wie man es umgehen kann.
Ein weiterer Vorteil des hybriden Ansatzes: es gibt Wege die auf einem “grossen Platz” nicht zu sehen sind, jedoch sollten benutz werden. Beispiel: Petersplatz Rom: http://osm.org/go/xcXjyomhO–
Möchte man in den Petersdom hinein, muss man Schlange stehen - rechts.
Vesrsucht man direkt hinein, so wie der Hapteingang gekennzeichnet ist, kriegt man mächtig Ärger.
Solche “informellen” Wege auf einem Platz kan man anzeigen mithilfe des hybriden Ansatzes.
Ok, das amenity=toilets statt =toilette sehe ich ein…
…aber ich war schon in mehreren Gebäuden, in denen ich GPS-Empfang hatte. Und es gibt ja auch noch andere Möglichkeiten der Positionsbestimmung.
Die Datenerfassung hat schon begonnen: Ich habe Parkhäuser in Spanien gesehen, in denen die Fahrwege der einzelnen Stockwerke mit level= erfasst waren. Insbesondere am Hang sind Ein- und Ausfahrten ja oft auf verschiedenen Ebenen.
In Gebäuden wird GPS wohl nie zufriedenstellend funktionieren. Wenn ich in ein Gebäude hineingehe, geht der Track gerne spiegelbildlich vom Eingang weg, da ich das Signal nicht direkt empfange.
Es gibt aber andere Methoden der Lokalisierung, z.B. über WLAN-Access-Points auf jedem Flur.
Für größere öffentliche Gebäude sehe ich da mittelfristig einen deutlichen Nutzen, der eine Erfassung rechtfertigt. Je früher da Empfehlungen/Regeln/Schemata aufgestellt werden, um so besser.
Genau das, Seichter!
Ein Freund von mir war bei einer Fachtagung und erzählte von solchen Techniken. Uns soll es letzt endlich wichtig sein, dass es demnächst geht. Wie - ist für uns weniger wichtig.
Es bring einen Nutzen mit sich, und es kommt sicherlich.
Vielleicht sollten wir ein Kodifizierungsmeeting organisieren?
Ich könnte da, wo ich wohne (Erlangen) Übernachtung und ein Meetingraum vorbereiten.
Ich bin nicht sicher, dass es das braucht. Ich hab mal die 2 “aktuellen” Vorschläge angeschaut.
der “Termite” Vorschlag ist nur skizziert und hat den grossen Nachteil, dass es Konventionen braucht die wohl nicht leicht verständlich sind und deshalb einen speziellen Editor praktisch vorausetzten (die way nodes (nicht die ways) eines Levels sind jeweils in einer “level”-Relation), Es gibt auch keinen PoC den ich kenne.
IndoorOSM: Vorschlag ist ziemlich vollständig. Änderungsbedarf gibt es bezüglich des “buildingpart” Tags und Rolle: Kollision mit 3D Tagging building:part und ein paar anderen ähnliche Problem, die man aber, denke ich, alle trivial rückwärtskompatibel lösen kann. Sprich entweder nimmt man was ganz anderes oder gleicht den Tag an die 3D Tags an. Was hässlich ist und nach Möglichkeit geändert werden sind die vertikalen Verbindungen wo man einen Kunstgriff braucht der mit Sicherheit zu Problemen führt. Denke wenn mas so machen will, kommt man nicht darum dies mit einer Relation zu modellieren, anstatt zu Fuss ein Relations ähnliches Konstrukt in einem Tag zu machen. Ein PoC zu IndoorOSM gibts, auch wenn es langsam in Heidelberg am verstauben ist.
Beide Vorschläge gehen nicht auf ein Indoor-Way mapping ein (aber geeignetes Tagging vorausgesetzt, könnte man solche Wege gegebenfalls auch einfach ignorieren).
Mit anderen Worten, ich glaube, dass man das problemlos auch im Indoor Forum festmachen kann. Was wirklich fehlt ist eine funktionierende Visualisierung die halbwegs aktuell gehalten wird (das sollte aber nicht wirklich ein Problem sein).
) kannst Du sicherstellen, dass niemand reinkommt.