Gallerien, Passagen, Museum... Science-Fiction: Indoor+3D? No, F3DB!

Absolut ja! Mach es bitte!

Ich bin aber gegen die Verwendung der Bezeichnung level. Level ist eine logische Bezeichnung dafür, welche Elemente über welchen liegen.
Ich bevorzuge building:level=<-n... -1, 0,1,2... n> wobei ich building:level=0 als haupteingangebene bezeichne. Diese kann hausinter ander heißen, zum Beispiel das Gebäude in dem ich arbeite schimpft sich im Erdgeschoß lustegerweise 2BM. Dafür würde ich etwa building:level:name=2BM benutzen.

marek kleciak wrote:

Absolut ja! Mach es bitte!

@marek: Gab es nicht einmal ein polnisches Einkaufcenter (3D) mit mehreren Etagen aus Kartendaten - ich finde es im Moment nicht - war ein sehr schönes Beispiel.

Ja, das gibt es. Unser Freund Dotevo ( die osm24 Seite) hat´s gebaut. Er hat auch ein Tool in dem man die Dinge gut beobachten kann.
http://osmtools.org/indoor/#lat=51.2356 … 71526&z=18 Einmal links auf "Klick to load the building" kurz abwarten, dann auf das Gebäude klicken mit linker Maustaste und dann auf "Betreten".

Das ist ja der Anfang. Wir sind ja zusammen mit Roland Olbricht, Dotevo, Balrogg, Kendzi, Thomas Greichen von der TU-Chemnitz, vvovv und und noch einigen Freunden an der Sache dran. 🙂

Und immer brav die POIs aktuell halten. Gerade in Einkaufszentren wechseln die Läden oft schneller als die Jahreszeiten.

marek wrote:

Absolut ja! Mach es bitte!

Bitte, nicht gleich weinen. ( Wir sind ja hier nicht beim Fußball spielen ). Ich hab ja schon eine Vorstellung, wie ich das angehe. Mein GPS nützt mir hier herzlich wenig.
Ich denke, verschiedene Mappingverfahren aufwendig kombinieren und das ganze vorsichtig in die OSM einfliessen lassen.
Wobei ich wahrscheinlich das Gesamtgebäude in 3D noch nicht hinbekommen werde. ( Sind einfach zu groß ). Rolltreppen und Obergeschosse werden zuerst ( nicht ) getaggt aber gemappt. (Überlege ich mir dann!)

Ich bevorzuge building:level

In Wiki finde ich nur building:levels ( Anzahl Stockwerke für 3D ). Für's herkömmliche 2D Mapping reichte da die Angabe level=x. http://wiki.openstreetmap.org/wiki/Key:level
Kenn ich mal wieder zu wenig Wiki?

chris66 wrote:

Und immer brav die POIs aktuell halten.

Man muss es ja nicht übertreiben und hier ist natürlich auch die ganze OSM-Gemeinschaft gefragt, das upzudaten. Okay, Witz komm raus.... ( du bist umzingelt ).

Anhang: Mit obiger Karte ist auch mein Indoor Weg erfasst. Sieht so aus, als wär´s das einzige hier weit und breit.

http://osmtools.org/indoor/#lat=50.8142 … 15649&z=18

In Wiki finde ich nur building:levels ( Anzahl Stockwerke für 3D ). Für's herkömmliche 2D Mapping reichte da die Angabe level=x. http://wiki.openstreetmap.org/wiki/Key:level
Kenn ich mal wieder zu wenig Wiki?

Ich habe in der Tat aus einem Vorschlag zitiert, den ich in den kommenden Wochen publik machen möchte. Es soll S3DB und Indoor verbinden. Die Vorprüfung haben bereits Mapper die ich in #4 erwähnt habe, gemacht.

marek wrote:

Ich bevorzuge building:level=<-n... -1, 0,1,2... n> wobei ich building:level=0 als haupteingangebene bezeichne. Diese kann hausinter ander heißen, zum Beispiel das Gebäude in dem ich arbeite schimpft sich im Erdgeschoß lustegerweise 2BM. Dafür würde ich etwa building:level:name=2BM benutzen.

Ich habe in der Tat aus einem Vorschlag zitiert, den ich in den kommenden Wochen publik machen möchte.

Soll heißen, du bist sicher, das dieses tagging etabliert wird. und ich von vornerein so taggen soll ?
Also, ab in den Aufzug (wenn vorhanden) und die Bezeichnungen der Etagenknöpfe verwenden ? Ist mir jetzt etwas zu voreilig, ehrlich eingestanden.

du bist sicher, das dieses tagging etabliert wird. und ich von vornerein so taggen soll ?

In OSM sind nur Diskussionen todsicher 🙂
Was ich glaube ist, dass man zur Diskussion ein schlüssiges Konzept vorstellt in dem nötige Elemente vorgestellt werden und anschließend an dem Wording arbeitet. Und ja, ich bin mir sicher, das das Konzept schlüssig ist.

Dann hätt' ich noch was zur Diskussion beizutragen. Der neue tag building:level=(-1,0,1,2... ) gilt in Zukunft. Und als Zusatztag den tag building:level:designation=(U2, S3DB, O1, EG..... ). ( oder .... name?) IMHO denke ich,, spezielle hausinterne Geschoßnamen sollten getrennt getaggt werden. Sonst blickt international keiner mehr durch. Der tag kann ja dann auf den way der jeweiligen Ebene gelegt werden. Die Shops sollten aber nur den einfachen tag building:level behalten.

Edit: Kleine Ergänzung

pezielle hausinterne Geschoßnamen sollten getrennt getaggt werden. Sonst blickt international keiner mehr durch

+1

Die Shops sollten aber nur den einfachen tag building:level behalten

+1
So baue ich es ein.
Ich kann im Vorab die Handskizzen in die Wiki einbauen.
Treppen, Rampen, Rolltreppen:
der unterste und oberste Punkt soll jeweils als "unten" bzw"oben"getaggt werden. Roland Olbricht hatte eine Idee zum Wording.

Auch Zwischenpodeste bekämen die präzisen Höhenangaben.
Zur Höhendefinition gibt es auch eine Idee die aus der Bauordnung kommt und auch in anderen Länder verwendet wird.
Dadurch sind wir kompatibel zur Industry Foundation Classes und könnten in Zukunft mit einem Importer 1:1 die 3D Gebäudemodelle mit den Innenstrukturen die von Architekten bzw Bauingenieuren gemacht worden sind in OSM importieren.

Grüße,
Marek

chris66 schrieb:
Und immer brav die POIs aktuell halten.

Irgendwann sollte das der Inhaber des POI selbst können, er muss nur wissen wie (notes oder eigenes Bearbeiten - hier sollte er auf Fehler hingewiesen werden und nicht einfach beheben, dann ist der Fehler nächstes Mal wieder da).

marek wrote:

Ja, das gibt es. Unser Freund Dotevo ( die osm24 Seite) hat´s gebaut. Er hat auch ein Tool in dem man die Dinge gut beobachten kann.
http://osmtools.org/indoor/#lat=51.2356 … 71526&z=18 Einmal links auf "Klick to load the building" kurz abwarten, dann auf das Gebäude klicken mit linker Maustaste und dann auf "Betreten".

Hab mir erst mal die Aktivitäten im polnischen und deutschen Raum angesehen. Das ganze hält sich bei uns ja noch in sehr kleinen Grenzen. Interresant ist das riesige EKZ bei Lódz. Da trifft sich ja alles. http://osmtools.org/indoor/#lat=51.7030 … 41432&z=17 Aber noch nicht ganz fertig dort.
Bleiben wir erst einmal bescheidener, ich finde das kleine EKZ in Prag ganz nett mit EG und 1 Stockwerk. http://osmtools.org/indoor/#lat=50.0973 … 35991&z=19
Sowas wäre doch für den Anfang vielleicht machbar.

Auch Zwischenpodeste bekämen die präzisen Höhenangaben.

Wenn man sich nun wirklich damit beschäftigen sollte, wäre vielleicht die Anschaffung eines Laser Entfernungsmesser's recht sinnvoll, oder ?
Na, dann muss ich mir mein Hobbybudget mal anschauen, das Ding kostet ja nur 50-100€.
Fehlt noch der amtliche Ausweis am Revert mit großer Schrift "OSM - Geovermessungsdienst" mit Lichtbild und Unterschrift vom Chef (M.K.), man will ja nicht von diversen Personal angepöbelt bekommen: "Was machen sie eigentlich da?". Das erinnert mich stark an Indoor-Geocaching, was eine sehr heikle Angelegenheit ist ( hab ich damals kaum gemacht ).
Als nächtes beschäftige ich mich erst mal mit euren Wiki-Einträgen.

Danke erstmal. Bitte keine ganz schnellen Ergebnisse erwarten. Muß das ganze erst mal zu einem neuen Projekt für mich im Kopf ausreifen lassen.

Gruß Rolf

chris66 wrote:

Und immer brav die POIs aktuell halten. Gerade in Einkaufszentren wechseln die Läden oft schneller als die Jahreszeiten.

Daher ist es auch wichtig zumindest ungefähr das Zentrum innen räumlich richtig zu mappen, es erleichtert das Update, weil man schon an der Reihenfolge der Läden sieht, ob einer gewechselt hat.

wegavision wrote:

Daher ist es auch wichtig zumindest ungefähr das Zentrum innen räumlich richtig zu mappen, es erleichtert das Update, weil man schon an der Reihenfolge der Läden sieht, ob einer gewechselt hat.

Verstehe nicht ganz, warum nur das Zentrum? Du meinst, den Weg, Korridor etc. und zwar im richtigen Umfang als area bzw Gebäudeteil? Natürlich. Darauf bauen dann auch die restlichen Gebäudereste meinetwegen rechts und links für die Shops auf. Was ich nicht für ganz oberwichtig halte, ist die genaue Position der Eingangstüre eines Shops. Sollte man natürlich taggen, alleine wegen access / opening_hours .... . Aber ich wäre auch mit einer Schätzung ggf. über ein Foto zufrieden.

Hat denn jemand von euch, sagen wir mal den 10-20 Indoor-Mappern in Germany, sich so einen Laser-Messer mal angeschafft? Oder hat jemand eine andere Idee, wie man Höhen und Weiten erfassen kann? ( Ich und Sohne rennen bestimmt nicht mit einem 20m Maßband im EKZ rum, und vermesse alles, obwohl das bestimmt für die Kundschaft beeindruckend wirkt ). Ich spreche auch die polnischen Kollegen an, die hier ein paar Monate voraus sind. In diesem Thread mache ich aber nicht auf englisch , weil ich euch "Landsmänner" ansprechen möchte, hier eine gewisse gemeinsame Innovation zu entwickeln.

NGaaM Rolf

P.S. ( Die abk. NGaaM ist mir gerade so eingefallen, s.h. Nette Grüße an alle Mapper ..., dachtet ihr euch schon? )

P.S.S http://forum.openstreetmap.org/viewtopic.php?id=25638 ... ist hier aussen vor

Rogehm wrote:

Oder hat jemand eine andere Idee, wie man Höhen und Weiten erfassen kann?

Wenn's nicht super-genau sein soll: Ich würde häufiger vorkommende Objekte (z.B. Fliesen, Geländer) Vermessen, ggf mit Objekten, von denen man die Abmessungen kennt, die aber nicht als Messgerät erkennbar sind (Hände, Telefone, …). Mit diesen Daten und Fotos kann man dann auch die Abmessungen von anderen Objekten gut abschätzen. Bei Höhen wird's schwieriger, kann aber auch so funktionieren.

Nun, einige Infos:
1.ich habe ein Mockup für eine App für OSM Indoor Mapping entwickelt.
(Ich bin Architekt, mit CAD arbeite ich seit 1990, habe diverse Spezifikationen für CAD Software entwickelt. Die ersten CAD Kurse machte ich 1994, darüber hinaus 15 Jahre Unterricht CAD und darstellende Geometrie an einigen Hochschulen. Ich behaupte, ein Wenig kenne ich mein Fach).
Ich hebe einige Kandidaten, die diese App schreiben könnten. Z.B. dieser OSM Mapper: http://www.youtube.com/watch?v=j4mB5KMcAAk
Um dies zu vervollständigen fehlt einfach Geld,nicht viel aber. Ich frage mich man dafür nicht ein Spendenaufruf starten könnte.
Was glaubt ihr?
Es sei denn, jemand möchte das machen. Dann einfach bei mir melden.

Auch ein Anschluss von einem einfachen Entferungsmesser an ein Android Gerät ist kein Thema. Solche Vermessungstools gibt es zuhauf.

2. Der Leiter des Landesvermessungsamtes Lodz ist schon pfiffig. Als ich ihm sagte, das die Mapper gern mehr Indoor Modelle in der OSM Karte haben wollen, beschloss er nach CAD Plänen zu suchen, die wir in die Karte einbauen könnten. Damit würde man Vieles einfacher haben.
Vielleicht kann man eben das Gleiche hierzulande probieren?

Ok, Geld fehlt mir leider auch z.Z. ; Von den einfachen Android Tools wie Smart Tools mit Entfernungsmesser halte ich leider gar nichts.
Spendenaufruf hier im Thread? Ausnahmsweise mal ein 3D Thread, den fast keinen interessiert. Oder wie machbar?
Neuer Vorschlag: Time-Sharing eines guten Laser Messers. Das Ding kann ich anschaffen und da ich es nur ztw. gebrauche, für eine zu vereinbarte Zeit gegen einen Obolus verleihen. Das Porto bezahlt immer der Absender. Wie wär's damit?

Ich glaube, die polnische Obrigkeit ist insgesamt etwas lockerer drauf.CAD Plane für ein EKZ bekommt man hierzulande 100% nicht umsonst, eigentlich überhaupt nicht.

Ich habe nicht die geringste Erfahrung mit Spendenaufruf. Wohl ist die Überschrift von dem Post auch nicht gerade hilfreich.

Was dei Datenweitergabe angeht, habe ich vor bei mir in Erlagen mit einigen der Datenbesitzer zu sprechen. Wen nicht versucht, bekommt nichts. Meckern ist stets einfacher als machen 😉

Ich bin übrigens der Meinung, dass man mit dem Laserentferungsmesser gar nicht arbeiten muss. Es gibt andere Wege Entfernung zu messen bzw. schätzen.

Sorry, Marek. War ich zu harsch? Nö 🙂

Natürlich gibt es hier keinen Spendenaufruf.

Ich denke, auch mit verschiedenen Interpolations und Zählverfahren, wie es rayquaza vorgeschlagen hat, kann man einiges erreichen. Befürchte nur die Hohe einer Ebene wird immens schwierig abzuschätzen sein.
Eigentlich ist unsere Map ja auch nicht die 100% Karte, sondern dient der groben bis mittleren Orientierung. Daher wundert es mich, das du darauf fast schon bestehst:

Auch Zwischenpodeste bekämen die präzisen Höhenangaben.

Ich frage dich jetzt mal konkret, wie man das genau schätzen soll. An der Wand sind alle möglichen Dinge angebracht, bestimmt keine gleichmäßigen Fliesen.

Anhang: Es gibt natürlich Bauvorschriften. Aber die zu kennen, für einen Standard Mapper, kann man nicht voraussetzen.

Ich frage dich jetzt mal konkret, wie man das genau schätzen soll

Smartphone mit dem barometrischen Höhensensor gibt Dir die Höhe mit 0.5 cm Genauigkeit. Geht wirklich einfach.

Nö, nix harsch. Ich Dickhaut. 😉

Ich auch Dickhaut. Und die grübeln meist viel. Ich hab' s jetzt. Treppe suchen. Treppenstufen: Anzahl feststellen. Wegen mir auch eine Höhe messen. ( Ist Norm ). Ein bisschen rechnen....
Also keinen Laser kaufen. Und auch kein teures Handy. ( Ich hab nur ein günstiges ). Problem gelöst.

Anhang: Muss meine Meinung über Smartphone Apps revidieren. Mit genauer Bedienung ( hier der Entfernungsmesser von "Smart Tools" ) bekommt man ein Ergebnis mit einem Fehler < 2% hin, d.h. z,B. 10cm bei 4 m Abstand. Ich denke, damit kann man leben. Hätte ich nicht gedacht.

Werde die Tage mal eine ToDo Liste erstellen, welche Vermessungsdaten indoor wichtig sind. mich dann mal bewaffnen und eine Lokalität aufsuchen ( wahrscheinlich Galerie Troisdorf - 2 Ebenen + TG ) Dann alle Ergebnisse auf mm-Papier....

Ich bin nach wie vor der Meinung: Einfach -> detailiert -> speziell -> expert

Ein einfaches Gebäude -> detailliert (Adresse, Zweck) -> speziell mit Geschoßangaben, Dach, ... außen 3D -> dort weiter speziell Farb- und Materialangaben)
Oder speziell innen -> da auch wieder von einfach (POI eintragen) -> detailiert (Ebenen) -> speziell Verbindungen (Aufzüge Roll- , Treppen)

Ich frage dich jetzt mal konkret, wie man das genau schätzen soll

Ein Foto und daraus lassen sich viele Daten schätzen

Es bringt allen etwas, wenn man nur ein building einträgt, ein andere verfeinert es, ein anderer wird 3 D ergänzen , ein anderer erste Indoordaten einträgt ... und um expert wird sich jemand kümmern, wenn er es benötigt.

Verstehe nicht ganz, warum nur das Zentrum? Du meinst, den Weg, Korridor etc. und zwar im richtigen Umfang als area bzw Gebäudeteil? Natürlich. Darauf bauen dann auch die restlichen Gebäudereste meinetwegen rechts und links für die Shops auf. Was ich nicht für ganz oberwichtig halte, ist die genaue Position der Eingangstüre eines Shops. Sollte man natürlich taggen, alleine wegen access / opening_hours .... . Aber ich wäre auch mit einer Schätzung ggf. über ein Foto zufrieden.

Der einfache way ist wichtig - wenn du ihn als Fläche erstellst fein, kann aber auch später ergänzt werden. Wichtiger sind die Wege, Eingänge damit man hinfinden kann (zu dem "Sportschuhgeschäft")

Zu Beginn dieses Threads wollte ich ja nur mal checken, was man noch machen kann um die tlw. nachlässig gemappten Einkaufzentren und deren Lokalitäten besser darzustellen und zu erweitern. Nicht umsonst schreien alle Smartphone User nach POI's in den diversen Map-Apps.
Das dies nur hinzubekommen ist über sauberes Indoor mappen und dies auch schon fleißig in Angriff genommen wird, habe ich erst hier erfahren.
Ein erfassen der Innenräume und deren Umsetzung bewirkt natürlich automatisch die außerliche 3D Ansicht, jedoch noch nicht Fassade, Dach und Farbgebung.
Das (EKZ)- Indoor und 3D keine Science Fiction mehr ist, zeige ich mal hier an diesem schönen Beispiel in Breslau:

http://osmtools.org/indoor/#lat=51.0946 … 01942&z=18
http://demo.f4map.com/#lat=51.0943435&l … 05&zoom=17

Wie man sieht, der Gebäudekomplex steht, außen sieht der aber noch etwas trostlos aus.

Es bringt allen etwas, wenn man nur ein building einträgt, ein andere verfeinert es, ein anderer wird 3 D ergänzen , ein anderer erste Indoordaten einträgt ... und um expert wird sich jemand kümmern, wenn er es benötigt.

Da ist also die zwangsläufige Reihenfolge IMHO nicht immer so gegeben. Aber ich meine, wer den doch recht großen Rechercheaufwand für Indoor fertig macht. wird sich nicht damit zufrieden geben das nur tlw. einzutragen und 3D links liegen zu lassen.
Daher meine ich, indoor und 3D Mappen sind eigentlich 2 Schuhe, die aber eigentlich nur zusammen ein Paar bilden können womit dann der User oder auch Experte auch etwas anfangen kann.
Versteht diesen Beitrag bitte nur mal als kleine Ermunterung ( der vielen deutschen ) Mapper, sich auch damit mal zu beschäftigen.
Ich werde ein erstes (kleineres) Projekt nun doch in Angriff nehmen.

Rogehm wrote:

Verstehe nicht ganz, warum nur das Zentrum?

Ich meinte damit das Einkaufs-"Zentrum" und nicht dessen Zentrum.

Da ist also die zwangsläufige Reihenfolge IMHO nicht immer so gegeben. Aber ich meine, wer den doch recht großen Rechercheaufwand für Indoor fertig macht. wird sich nicht damit zufrieden geben das nur tlw. einzutragen und 3D links liegen zu lassen.

So in etwa meinte ich es - Das Haus muss erst einmal da sein. Und wenn du nur innen (so perfekt du es machen kannst/willst) ist es schon ein Schritt. Dann kommt der "Architekt" und bemaßt auf mm. Der nächste hat Freude an der Eintragung der 3 D (simple buildings tags) und einer macht es dann noch genauer.

Wenn in einem Zentrum mehrere Geschäfte sind, ist es m.E. wichtig zu diesen zu finden. Und wenn du die POI's in 3D und indoor einbaust ist es toll.

wegavision wrote:

Ich meinte damit das Einkaufs-"Zentrum" und nicht dessen Zentrum.

Klar. Sorry. War ein Mißverständnis.

So in etwa meinte ich es - Das Haus muss erst einmal da sein. Und wenn du nur innen (so perfekt du es machen kannst/willst) ist es schon ein Schritt. Dann kommt der "Architekt" und bemaßt auf mm. Der nächste hat Freude an der Eintragung der 3 D (simple buildings tags) und einer macht es dann noch genauer.

+1

Genau. Mann kann die Schritte stufenweise gehen, wobei denn ein Gebäude, das schon in 3D getaggt ist, dann auch einlädt, es innen "auszubauen".
Ich glaube, eines der Hindernisse für die Attraktivität des Indoor-Mappens ist der recht hohe Aufwand "vor Ort" und das Aufwand/Nutzen Verhältnis.
Wer braucht dann schon ein Indoor Plan eines EKZ (der alte Name Einkaufszentrum ist ja eigentlich "ausgestorben", aber als Abk. mir allerliebst), wo doch an den Eingängen immer ein Plan hängt.
Außerdem kenne ich noch keine App, die derartige Pläne darstellen kann, d.h. man müsste Ausdrucke mitnehmen. Macht kein Mensch.
Marek hat da ja was in Vorbereitung (#17).
Was ich nicht ganz verstehe, ist, das unser Nachbarland Polen darin uns einen großen Schritt voraus ist. Die machen einen guten Job dort.
Habe heute mein erstes Kleinprojekt schon mal angefangen und alle POI's im Gebäude schon mal platziert. Jetzt kommt natürlich das "Maß" nehmen.
Mal sehen, was ich im Urlaub schaffe.
Danke erstmal für eure Beiträge.

Gruß Rolf

Was ich nicht ganz verstehe, ist, das unser Nachbarland Polen darin uns einen großen Schritt voraus ist.

Na ja. Es ist einfach so, dass eine Handvoll Mapper Spaß an konkret dieser Sache hat. Mehr ist es nicht. In Deutschland entstanden viele tolle Projekte weil die einfach jemand angefangen hat: Openfiremap, Openseamap, OSRM, OSM2World usw. usw.

Den Gedankeaustausch hier finde ich richtig gut, vor allem die Idee mit dem natürlichen Workflow, wie man zu einem solchen Ergebnis kommt. Und auch die Beschreibung der Technik wie man solche Ergebnisse praktisch bekommen kann mit einem durchexerzierten Testfall.
Ich würde gern Skizzen die ich habe zusammen mit diesem Content in einer neue Wiki Seite unterbringen. Wie könnte man so eine Seite taufen? Habt Ihr eine Idee?
Grüße,
Marek

marek kleciak wrote:

OSMR

OT: Kann mir jemand den Fuss vom Schlauch nehmen?

Ups, sorry.
Gemeint war http://project-osrm.org/ 😉

Hallo Marek,

marek kleciak wrote:

Ich habe nicht die geringste Erfahrung mit Spendenaufruf. Wohl ist die Überschrift von dem Post auch nicht gerade hilfreich.

Was dei Datenweitergabe angeht, habe ich vor bei mir in Erlagen mit einigen der Datenbesitzer zu sprechen. Wen nicht versucht, bekommt nichts. Meckern ist stets einfacher als machen 😉

Ich bin übrigens der Meinung, dass man mit dem Laserentferungsmesser gar nicht arbeiten muss. Es gibt andere Wege Entfernung zu messen bzw. schätzen.

Du könntest bei der Fossgis einen Projektantrag stellen. Frag mal bei Marc nach [1], der ist auch Fossgis-Mitglied und hat da Einblick.

viele Grüße

Dietmar

[1] https://www.openstreetmap.org/user/mgehling

Das mach´ích.
Vielen Dank Dietmar für den Tipp!

Rogehm wrote:

Oder hat jemand eine andere Idee, wie man Höhen und Weiten erfassen kann?

Ggf. könnt ich zum Entfernungmessen noch etwas beisteuern: ich hatte vor längerer Zeit mal einen Protoypen für einen Android-Schrittzähler entwickelt.
Schritte werden relativ zuverlässig erkannt, bei Annahme einer konstanten Schrittweite lässt sich damit die Entfernung ableiten. Die Richtung wird über den Kompass bestimmt.
Das ganze liess sich auf einer Mapsforge-Karte darstellen und als GPX exportieren..

Nachteil: die Methode setzt voraus, dass das Handy während des Trackings einigermaßen stabil gehalten wird, ansonsten driftet die Richtung zu stark.

Bei Interesse könnt ich versuchen, den Prototypen zu reaktivieren..

Toll!
Interesse klar vorhanden. 🙂

Um ganz ehrlich zu sein habe ich es als Idee in der App Beschreibung.
Vielleicht können wir es irgendwie zusammenbauen?

Android-Schrittzähler

Danke, free_as_a_bird. Den Gedanken hatte ich natürlich auch schon. Ich war erstaunt, wieviele Android Schrittzähler es gibt. Aber die Comments sagen alle aus: "Schön und gut, aber viel zu ungenau". Ich hatte ja auch schon die App "Smart Tools" erwähnt. Aber die bringt auch nur bei kurzer Entfernung einigermaßen genaue Ergebnisse.
Dann war ich es doch leid und hab mir bei Ebay den Entfernungsmesser Bosch PLR 50 ersteigert. (Genauigkeit: 2mm auf 50m ). Da ich nicht nur ein EKZ erfassen möchte, lohnt sich die Anschaffung vielleicht doch.

Anhang: Nun muß man doch länger wachbleiben in der Verlängerung.
Was ich noch sagen wollte: Es geht nicht nur um Gallerien, Passagen, EKZ... sondern auch um Flughäfen, Großbahnhöfe, Rathäuser, Indoor-Sportanlagen, Unterstadt (U) und, und, und ....

marek kleciak wrote:

Toll!
Interesse klar vorhanden. 🙂

Schick mir per PN Deine Mailadresse, da übers Forum keine Anhänge zugelassen sind. Gerne kann ich Dich durch den Prototypen führen..

Rogehm wrote:

Aber die Comments sagen alle aus: "Schön und gut, aber viel zu ungenau".

Akzeptiert, nur welcher EKZ-Betreiber lässt Dich im Haus mit furchterregendem Equipment wie Laserpointern hantieren?

Wenn Du fündig wirst, stelle ich leihweise dieses Gerät mit hochgenauen Drehencodern zur Entfernungsmessung zur Verfügung (damals vorgesehen als Plattform zur Indoor-Feldstärkemessung von Wifis/iBeacons etc.)
Vorteil: fährt im Zweifelsfall auch schneller als die Security rennt 😄

Viele Grüße
Tobi

Wenn Du fündig wirst, stelle ich leihweise dieses Gerät mit hochgenauen Drehencodern zur Entfernungsmessung zur Verfügung (damals vorgesehen als Plattform zur Indoor-Feldstärkemessung von Wifis/iBeacons etc.)
Vorteil: fährt im Zweifelsfall auch schneller als die Security rennt big_smile

Ich glaube, wenn ich im EKZ mit so einem Teil per Fernbedienung rumgurke, ist das jawohl ein bisschen auffälliger als meine Mini Laser Pistole.
Danke für das Angebot. 🤔

Allerdings geht's natürlich auch mit Android Schrittzähler Apps. Da heisst es nur, früh übt sich, wer später mal berühmter Indoor-Mapper werden will.

Ich habe die ersten Beschreibungen zusammengekratzt:
https://wiki.openstreetmap.org/wiki/F3DB

Nun zu, bitte um Änderungen, Vorschläge etc.

Grüße,
Marek

Da ist mir wieder mal jemand 2 Minuten zuvor gekommen. 🙁

Na, da hät ich auch schon die 1. Frage:
Ways, eigentlich immer footways sollen unabhängig und gesondert vom corridor / floor getaggt werden, als:
highway=footway ( würde aber auf der Mapnik dargestellt, IMHO nicht so toll; oder als highway=tunnel ( wird öfter gemacht, aber ebenso unkorrekt. ), oder
highway=corridor ( wäre zwar auf Mapnik nicht zu sehen, passt aber auch nicht immer )
Kann der highway=corridor als area getaggt werden ( ist ja so in Passagen )?

Gruß Rolf

P.S. Warte noch auf meinen Laser, kann dann erst nach ausprobieren erste Erkenntnisse loswerden.

Der highway=corridor kann als area getaggt werden
sonst würde ich eine kategorie Einführen für die Mapnik blind ist:
indoor:highway=footway
indoor:highway=steps
Indoor:highway=ramp

Das schöne an der Sache wäre nicht nur, dass sie vom Mapnik ignoriert werden wodurch keine Anpassung notwendig ist, sondern auch dass spezielle indoor navis explizit nach solchen Wegen in dem Gebäude suchen könten.

indoor:highway=footway
indoor:highway=steps
Indoor:highway=ramp
Das schöne an der Sache wäre nicht nur, dass sie vom Mapnik ignoriert werden wodurch keine Anpassung notwendig ist, sondern auch dass spezielle indoor navis explizit nach solchen Wegen in dem Gebäude suchen könten.

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

indoor:water=pond, indoor:waterway=stream, indoor:leisure=garden und ggf. weitere neu überlegt werden

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.

Rogehm wrote:

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.

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

Rogehm wrote:

Problem: Manchmal kann man Fluchtwege nicht einfach so benutzen, um diese zu mappen, man löst dann mitunter locker mal einen Alarm aus.

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.

Was ist mit Schiebetüren und Drehtüren? Beides sind in Einkaufszentren ja häufig anzutreffen.

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.

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.

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/Pro … tures/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.

opening:direction der Türen, etwas verwirrend.

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.

Rogehm wrote:

...
Notausgang:
entrance=emetgency...

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.

Das ist doch der Zugang für Rettungskräfte! Besser wäre exit=emergency.
"exit=*" wird sowieso benötigt. Ich denke an Drehkreuze usw

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.

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 … _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 😐

marek kleciak wrote:

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.

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=*.

Ich platzierte auch einen Alternativvorschlag für Türaufschlagrichtung

Mir gefällt die Lösung, das über die Richtung des Wand-Ways zu machen, am besten.

indoor:water=pond, indoor:waterway=stream, indoor:leisure=garden und ggf. weitere neu überlegt werden

Finde ich super!
Hab gar nicht dran gedacht. Das brauchen wir aber. Und es ist nur eben konsequent.

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.

Tordanik wrote:

Mir gefällt die Lösung, das über die Richtung des Wand-Ways zu machen, am besten.

Ich bevorzuge sie auch. Sie ist eindeutig.

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.

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

building:level:1=1.25 oder indoor:level:1=1.25

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

Vorschlag mit: decoration ; show ; exhibition ; gastronomy ; waiting area ; artificial pond ; artificial stream

Eingebaut.

Soll die Höhe über Grund angeben, nicht wahr?

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?

marek kleciak wrote:

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

Was sagen die Anderen dazu?

Nix! Sorry, geri-oc, hat sich überschnitten.

Mir fallen noch die wichtigen und oft eingebauten zones: relax_area und playground ein. Thanks für dein promptes zustimmen. Soll man da nicht erst überlegen?

Erst einmal ein Beispiel soweit wie bisher diskutiert mappen und dann weitere Vorschläge/Änderungen/Ergänzungen an diesen Objekt diskutieren/probieren

Ich glaube, da hat Marek keine Zeit dafür. Die polnischen Kollegen wollen wissen, woran sie sind. Wir hätten ja noch etwas Zeit...

Hinzugefügt.
Wir finden sicherlich noch weitere 20 Beispiele für solche Areas.
In dem indoor consortium gibt es ein Doku wo sowas steht. Ich suche es morgen aus.

marek kleciak wrote:

Ich habe die ersten Beschreibungen zusammengekratzt:
https://wiki.openstreetmap.org/wiki/F3DB

Nun zu, bitte um Änderungen, Vorschläge etc.

Grüße,
Marek

Ich finde die Idee des Indoor-Mapping und 3D-Mapping sehr gut. Beim 3D-Mapping habe ich auch selbst erste Versuche unternommen.
Wenn ich mir aber ansehe, wie das Indoor-Mapping erfolgen könnte (laut Proposal), dann erinnert mich dies an 3D-Mapping und die damit verbundenen Probleme der Erfassung:
Man kommt sehr schnell in die Situation, dass eine Vielzahl an Linien direkt übereinander liegt (z.B. gleicher Grundriss auf allen Ebenen). Da habe ich (in JOSM) noch keinen vernünftigen Weg gefunden, wie man solche gestapelten Daten dann nach der Ersterfasung noch bearbeiten kann, ohne etwas kaputt zu machen. Das war für mich ein Grund, die Gehversuche im 3D-Mapping wieder einzustellen.

Hier besteht aus meiner Sicht zum einen Bedarf für Erfassungstools, die nicht nur in 2D arbeiten, sondern durch geeignete Methoden z.B. eine saubere Ebenentrennung oder gar ein vollständiges Modellieren in 3D gestatten.

Ich wage jedoch die Prognose, dass die Mehrheit der Mapper den (zusätzlichen) Aufwand zur Nutzung eines solchen Editors nicht machen werden. Diese werden weiterhin mit den vorhandenen (oder neuen) Editoren arbeiten. Damit ist die Wahrscheinlichkeit sehr groß, dass mit der Erfassung/Änderung in einem solchen Editor ein bestehendes 3D-Modell beschädigt wird.

Daher sollten die Daten so erfasst und im Editor dann zur Verfügung gestellt werden, dass solche versehentlichen Fälle möglichst vermieden werden können. Eine Möglichkeit, die mir dazu einfällt, wäre das Anhängen von 3D- und Indoor-Beschreibungen an das 2D-Modell (typischerweise das Gebäude) in einer ähnlichen Form wie Relationen. Damit habe ich zunächst nur die Basisdaten im 2D-Editor zur Verfügung. Erst mit weiteren Aktionen komme ich an die 3D- / Indoor-Daten.
Allerdings besteht dann die Möglichkeit, den Grundriss allein zu ändern. Das Innenleben des Gebäude wäre dann nicht mehr ganz "passend".

Aber vielleicht ist dies auch nur ein Henne-Ei-Problem: Ohne erste Ansätze des Mapping wird es keinen Editor geben. Und daher werde ich mich einfach etwas in Geduld üben und auf die Ergebnisse (für das Mapping) warten.

Lieber Aromatiker,
ein OSM Freund aus Berlin werkelt bereits an einem JOSM PlugIn dafür.
Mit Roland Olbricht haben wir die notwendigen API Änderungen besprochen.
Nun müsste man an Tom H ran und ein Paar Kollegen die die Hauptseite nach bereits vorhandener Mockup umbauen würden.

Dafür würde ich aber Euch alle herzlich bitten: Macht mit! Ich habe zwar Erfahrung in 3D und Bauwesen aber dies ist ein gemeinsames Werk und das Letzte wasich möchte ist jemandem Etwas aufzuzwingen.
Ich lade Euch alle gern Ende August zu mir nach Hause nach Erlangen ein (Yepp, Geburtstag und man kann auch übernachten 🙂 ) denn bis dahin werder die wichtigsten Elemente definiert.

Zu der Form von dem Erfassungstool: Ich bereite für Marc G ein Blogpost vor indem die Idee grob skizziert wird. Vielleicht finden wir ein Team mit dem sich sowas realisieren lässt.

Zur genaueren Angabe was ist der Bezugspunkt für die Höhenmessung von dem Gebäude eine kleine Skizze:
https://wiki.openstreetmap.org/wiki/Fil … gPoint.jpg

Auch die Alternativlösung zum Taggen der Türöffnung ist drin.

Hallo,

Nochmal zu Erinnerung dein Proposal: https://wiki.openstreetmap.org/wiki/F3DB

Die Alternativlösung Solution B für die Türöffnung mit eindeutigen farblichen und hilfreichen Hinweisen ist voll i.O.; jetzt braucht man nicht mehr querzudenken und den Bildschirm umdrehen. Solution A kann IMHO weg.

Den indoor:highway=escalator solltest du ändern in conveying, da hat sich der tag escalator doch assimiliert....

Den lowest terrain/building section point gegenüber der Höhe in level 0 festzustellen bzw. zu mappen, kann ich mir vielerorts als schwierig vorstellen.
Zum Glück bin ich ja ein fast "Flachländler" in Kölner Raum. Aber selbst in Köln gibt es diverse Bodenwellen, wo die Treppe zum Eingang links zum Bsp. 20 Stufen hat und rechts 17. Wie bekommt man sowas hin? Immer den Bezug zum niedrigsten Punkt außen, nehme ich an. Bloss weiß ich noch nicht, wie man das ohne größeren Aufwand ausmisst.
Na ja, morgen kommt der Laser... ( sollte aber nur zur erweiterten Mappingausstattung eines Indoormappers gehören )

Gruß Rolf

P.S. So ein Ding in klein hab ich auch, wen es interessiert, das möchte ich verkaufen.
Mir reicht jetzt mein Handlaser ( nur um die störenden Fußganger loszuwerden, damit ich endlich meine Messung machen kann... )

Den lowest terrain/building section point gegenüber der Höhe in level 0 festzustellen bzw. zu mappen, kann ich mir vielerorts als schwierig vorstellen.

Stimmt. Es kann aber auch geschätzt werden. Selbst bei einem Fehler maßgebend sind die Höhen einzelner Stockwerke. Den Messfehler kann man in Zukunft nachbessern ohe dass die Gesamtkonstruktion den Schaden nimmt. Das Gebäude sitzt dan leicht zu tief oder zu hoch in der Erde, sonst nichts. Alle anderen Höhen (z.B. der Fenster) sind relativ zu dem jeweiligen Fußboden vermessen.

DeinBeispielin Köln:Ich wüder die höhere Anzahl, also 20 Stufen nehmen. Bei einer Höhe der Stufe von ca.18 cm hättest Du also 360 cm.

Hallo, zusammen

Der Lasermesser ist angekommen. Sehr gutes Teil (*). Besonders die automatische Höhen-Pythagoras Messung - absolut Top.
Zu Hause: 6 m Abstand zur Wand. Genauigkeit / Höhenmessung mit Pythagoras 2-6 mm. Messzeit der Doppelmessung: 5 sek. ; Ich glaube, da kann man fast unbemerkt indoor mappen gehen. Man sollte nur schauen, das da kein Passant zufällig in Augenhöhe "dazwischen" gerät.

Ich habe mir auch mal das Proposal http://wiki.openstreetmap.org/wiki/Prop … res/indoor
angeschaut. Da fällt mir auf dem Bild und der Beschreibung auf: Der way auf building:level=0 ist "outdoor".
Außerdem ist das Relation-/Area Schema sehr schön dargestellt. Gefällt mir gut, muss dann aber wohl neu überlegt werden.

Ansonsten kämpfe ich mich mal durch die Arbeit der Heidelberger Uni, nur interessehalber:

http://koenigstuhl.geog.uni-heidelberg. … oorOSM.pdf

So ganz ohne Vorbereitung ( muß noch eine ToDo Liste und Ausdrucke ( evtl. mit fieldpapers ) machen ), gehe ich noch nicht an den Start.

NGaaIM Rolf

P.S. (*) Was mich nur stört, ist das man das Ding nicht auf Laser Klasse 4 (Betäubung) umschalten kann, nix da, die störenden Fußgänger loszuwerden.... 🙁

Wir sind nun nach einem zweitägigne Workshop mit Thomas Greichen von der TU-Chemnitz sowie Gedankenaustausch um die Gruppe von Yarl.
In die F3DB Seite werden nun die Ergebnisse einfliessen.
Ds Wichtigste ist, dass man an konkreten Beispielen zeigen möchte, wie der Mappingvorgang dann funktioniert und dass man nicht gleich mit 3D zwangsweise arbeiten muß.

Yarl möchte sein Tool an F3DB anpassen. Der momentane stand ist bekannt:

http://osmtools.org/indoor/#lat=51.2356 … 71526&z=18

Mit der neune Version der Seite von Yarl hätten wir sozusagen Mockup und die Möglichkeit die Indoor Darstellung in die Hauptseite einzubauen; ich denke vielleicht als einen weiteren Layer neben Cycle, Transport, Mapquest und Humanitarian.
Oder zumindest darüber zu diskutieren.

Noch kurz zum Thema "Türrichtung" und "Öffnungsrichtung":

Nach DIN (Deutscher Industie Norm) ist die Türrichtung vorgegeben.
Hier eine Skizze:
https://www.haefele.de/is-bin/intershop … htung.html

Grüße vom Schreinermeister

Vielen Dank, Schreinemeister!

Was muss dieser Skizze nach in der F3DB Spez. geändert werden?
Wahrscheinlich sind einige Skizzen falsch beschriftet, oder?

Viele Grüße,
Marek

Guten Abend,
Nach ein paar Tagen Urlaub und "Römer" mappen wende ich mich diesem Problem wieder zu.
Man liest natürlich auch: http://forum.openstreetmap.org/viewtopic.php?id=25961 , wenn man sich hierfür interessiert.
Es geht jetzt um den Start in das Projekt und zwar "klein" angefangen und mit hohen Aufwand "bewaffnet" und vorbereitet.
Dazu war ich heute mal in einer mittelgroßen Passage in Berg. Gladbach und hab mir überlegt, was machst du jetzt mit deinem Fotohandy und deinem Lasermesser?
Da ich mittags da war, war reges Treiben in der Passage. Alle Glastüren standen weit offen. Mit dem Laser bekommt man die Entfernungen zu den Glastüren auch nicht hin.
Fotos machen mit dem Handy ist ja draussen gut und schön, aber innen schon schwierig. Viele sind dann verwackelt oder unscharf. ( Hab natürlich auch eine gute Kamera... )
Dann ist man hier auch durch das viele Volk etwas zurückhaltend, "tausende Fotos" zu machen.
Der Flucht- und Rettungsplan befindet sich meißt recht unscheinbar irgendwo. Der sollte zumindest fotografiert werden. Ist aber als Hintergrund auch nicht verwendbar, denke ich. Dann natürlich der Stockwerksplan mit den Shops.
Ich denke, in einer Kombination mit den Dingen, die man sieht ( fotografiert ), verschiedene Messungen, wenn diese möglich sind, guter Vorbereitung, indem man schon mal provosorische Ausdrucke der Ebenen mitnimmt für Notizen usw, könnte man sowas wirklich hinbekommen. Aber wahrscheinlich nur in mehreren Durchgängen, da man 100% immer was vergisst. Technische Vorausetzung: Möglichst kompakte, gut auflösende, lichtempfindliche Kamera; Lasermesser, Zollstock, Bandmaß; Klemmbrett mit vorbereiteten Ausdrucken ( + Bleistift, Lineal, Radierer ), To-Do Liste mit den geforderten Details. Beste Uhrzeit: Morgens ; Und viel Zeit mitbringen...
Na, dann will ich das nächste Woche mal so versuchen...

Wow,
kling ja gut.
Ich habe mir schon gedacht, man sollte vielleicht mit einem Objekt anfangen, wo man problemlos von dem Besitzer ein Plan bekommt (eine Schule, Kindergarten?) damit man auf der Karte ein Beispiel hat, mit dem man dem Verwalter eines EKZ reden könnte?

Morgen,

Ich habe mir schon gedacht, man sollte vielleicht mit einem Objekt anfangen, wo man problemlos von dem Besitzer ein Plan bekommt (eine Schule, Kindergarten?) damit man auf der Karte ein Beispiel hat, mit dem man dem Verwalter eines EKZ reden könnte?

In NRW ist Ferien und mit KiGa's hab ich's auch nicht mehr so mit, da ist Sohnemann schön längst rausgewachsen.
Aber was spricht dagegen, wenn man sich sowas ausdruckt und mitnimmt zum mappen, nur mal so als Gedächtnisstütze?

Schließlich soll unser "Werk" ja dann auch mal so ähnlich aussehen in der 3D OSM...
http://www.rheinberggalerie.de/center-lageplan.aspx

Moin,

Ja_Meister! wrote:

Nach DIN (Deutscher Industie Norm) ist die Türrichtung vorgegeben.

marek kleciak wrote:

Was muss dieser Skizze nach in der F3DB Spez. geändert werden?
Wahrscheinlich sind einige Skizzen falsch beschriftet, oder?

Schreinermeister bezieht sich darauf, das die Angabe links/rechts sich auf die Aufhängung/Bänder bezieht, während Du in Deiner Solution B die Angabe auf den handle/Türdrücker beziehst.

Sowohl die DIN-Norm wie auch Deine Solution B haben aber für OSM den Nachteil, dass sie sich auf einen bestimmten Standpunkt/Sichtweise beziehen:
- Wo sind die Bänder und auf welcher Wandseite?
- Auf welcher Seite der Tür befindet sich der Flur/corridor denn überhaupt?

Dies lässt sich in den OSM-Daten aber nicht an einem einfachen node der Tür taggen sondern benötigt weitere Bezugsangaben.

Insofern halte ich Deine Solution A mit Bezug auf die Wegrichtung der Wand für den praktisch sinnvolleren Weg, auch wenn dort andere Tücken lauern.
Auch die Werte für die Öffnungsrichtung müssen nicht nach DIN benannt werden, da in OSM eben nicht das Bezugssystem der DIN (einfach) angewendet werden kann.

Gruß
Georg

Wie ich sehe, sind die meisten User aus praktischen Gründen für die Lösung A und um ehrlich zui sein bevorzuge ich sie auch, da sie mathematisch eindeutig ist.
Grüße,
Marek

Ich sehe für die exakte Definition von Türen und Türrichtungen 2 Möglichkeiten:

1. Die grafische Version
Ähnlich wie bei Architekturzeichnungen werden die Türen direkt eingezeichnet. In CAD-Programmen gibt es vorgefertigte Module, die einfach eingefügt werden. Der Zeichner kann auch gleich das Ergebnis kontrollieren. Beispiel http://www.fertighaus-keitel.de/uploads … aintal.jpg . Ob das mit einem Editor (JOSM o.ä.) umsetzbar ist, kann ich nicht beurteilen.

2. Die beschreibende Version
Wie schon bei https://wiki.openstreetmap.org/wiki/F3DB#Solution_B ansatzweise beschrieben, braucht man auf jeden Fall eine Linienrichtung der Mauer. Jetzt gibt es 4 Varianten der Türausführung. In Linienrichtung gesehen, ist die Türfläche links oder rechts? Auf die Türfläche blickend, sind die Bänder (Scharniere) links oder rechts?
Am Beispiel https://www.haefele.de/is-bin/intershop … htung.html (Bild "Öffnungsrichtung" ganz unten):
Die Linienrichtung der Wand geht von links nach rechts.
DIN Links links auswärts = openig_direction= left_left
DIN Rechts rechts auswärts = openig_direction= left_right
DIN Links rechts einwärts = openig_direction= right_left
DIN Rechts links einwärts = openig_direction= right_right

Ich sehe hier ERHEBLICHE Verwechslungsgefahr

Rogehm wrote:

Dann ist man hier auch durch das viele Volk etwas zurückhaltend, "tausende Fotos" zu machen.

Dann nehme doch ein "Model" zum positionieren - kannst ja auch "vorbei" aufnehmen.

geri-oc wrote:

Dann nehme doch ein "Model" zum positionieren - kannst ja auch "vorbei" aufnehmen.

Da wollte er mich doch wieder herausfordern und ein Beispiel irgendwo finden lassen...
War leider nicht erfolgreich, nur so was "für Erwachsene" gefunden... lassen wir lieber.

Diese Geschichte mit den Fotos machen in öffentliche Gebäude ließ mich dann doch grübeln, ob alles hier so rechtens wäre.
Ich glaube, keiner hat was dagegen, so 2-3 Fotos von einer Gallerie innen zu schießen. Aber bei der Aktion brauche ich weitaus mehr, auch innerhalb der Shops.
Und da scheint wohl der Spaß aufzuhören. Das geht natürlich nicht ohne Genehmigung. Mag der eine Verkäufer das ignorieren, der andere wird aufmerksam, dann kommen Ladenchef und "die höhere Gewalt " ins Spiel. Da findet man doch reichlich Antworten im Netz bei der Frage: Kann ich hier ohne weiteres fotografieren?
Schätze, wenn nirgendwo ein Verbotsschild hängt, sollte man zumindest die Haussordnung lesen. Hoffentlich hängt die aus. Ansonsten hilft nichts und man muss vorher um Genehmigung fragen.
http://de.wikipedia.org/wiki/Fotografiererlaubnis

Hat jemand eine Meinung?

Anh.: @Marek: Kannst du mal bei den polnischen Kollegen nachfragen, mit welchen "Mitteln" die Kollegen doch schon einige eindrucksvolle Indoor-3D Arbeit geschafft haben?
Also: Hardware, vor Ort Beschau, Fotos, Messungen, angeforderte oder im Internet gefundene Pläne usw. Möglicherweise ist auch dort die Rechtslage anders?

Und da scheint wohl der Spaß aufzuhören. Das geht natürlich nicht ohne Genehmigung.

Vielleicht ist der Ansatzpunkt falsch: wenn der Galleriebetreiber einen StreetView-Indoor-Fotografen engagiert, kostet ihn das erstmal, bzw. er muss die Karten selbst digitalisieren.
Wenn das ganze kostenlos gemappt wird, ist das doch eine WIN-WIN-Situation für den Betreiber und OSM.

Ich könnte mir daher vorstellen, dass viele Galleriebetreiber dem ganzen eher offenstehen und auf Nachfrage eine Genehmigung gerne erteilen...

free_as_a_bird wrote:

Wenn das ganze kostenlos gemappt wird, ist das doch eine WIN-WIN-Situation für den Betreiber und OSM.
Ich könnte mir daher vorstellen, dass viele Galleriebetreiber dem ganzen eher offenstehen und auf Nachfrage eine Genehmigung gerne erteilen

Ja, ich gehe auch davon aus, das eine positive Antwort seitens des Betreibers überwiegen wird.
Ich hatte jedoch anfänglich dieses rechtliche Problem gar nicht bedacht. Es gibt hier wieder zwei Möglichkeiten ( wie immer im Leben... )
Entweder muss man, natürlich schriftlich, in einem langwierigen Hin und Her-Verfahren, sich solch eine Genehmigung vom Betreiber/ Besitzer einholen;
oder man überlegt sich ein grundlegend anderes Mapping Konzept, wobei dann kaum Fotos gebraucht werden. ( Dies ist bei mir in Überlegung ).
Mit "Indoor-Fotos" in irgendwelchen Gebäuden bewegt man sich tatsächlich in einer rechtlichen "Grauzone", deren Bewältigung sehr viel Aufwand bedeutet, was wir OSMatiker ja eigentlich gar nicht wollen.
Im Prinzip sind die Fotos zum Indoor mappen ja auch nur zur Auswertung der "vor Ort" Verhältnisse gedacht und landen normalerweise nicht irgendwo im Netz.
Aber wer weiß das schon, und wenn's doch passiert?
Also müsste man sogar eine Unterlassungserklärung formulieren/unterschreiben, damit das nicht passiert. Hier wird's dann doch rechtlich gesehen ziemlich "anstrengend".
Ich glaube, das "Indoor Foto-Mapping" wird scheitern bei dieser Rechtslage. Bleibt noch Konzept B. ( Muss ich noch überlegen, bevor ich's hier veröffentliche ).

Was ist eigentlich mit diesem kleinen Einkaufscenter in Passau (DEZ Dreiflüsse EKZ)
http://www.openstreetmap.org/#map=18/48.56369/13.43008
Da wurden schon vor 4 Jahren Indoor Mapping Versuche gemacht, aber dann nicht weiter verfolgt.
Es sind eigentlich schon so viele Information getaggt, das man da gut ansetzen kann mit F3DB.
Gibt es vielleicht einen mitlesenden User, der dort lebt und evtl. Ergänzungen bereitstellen kann?
Dann hätten wir auf die Schnelle schon mal ein Beispiel parat.

Rogehm wrote:

Was ist eigentlich mit diesem kleinen Einkaufscenter in Passau (DEZ Dreiflüsse EKZ)
http://www.openstreetmap.org/#map=18/48.56369/13.43008
Da wurden schon vor 4 Jahren Indoor Mapping Versuche gemacht, aber dann nicht weiter verfolgt.
Es sind eigentlich schon so viele Information getaggt, das man da gut ansetzen kann mit F3DB.
Gibt es vielleicht einen mitlesenden User, der dort lebt und evtl. Ergänzungen bereitstellen kann?

Ich lebe dort und die damaligen Versuche mit Indoor Mapping gehen auch auf mein Konto. Das Einkaufscenter wurde leider bald nach den ersten Mappingansätzen umgebaut und war dann monatelang eine Baustelle, so dass ich das Projekt damals nicht weiter verfolgt habe.

Es ist wahr, man könnte dort modernere Indoor-Tagging-Ansätze ausprobieren bzw. sogar verschiedene Ansätze vergleichen. Ich komme auch demnächst wieder dort vorbei, also kann ich noch weitere Daten sammeln bzw. die Informationen aktualisieren.

Vielleicht sollte ich noch darauf hinweisen, dass ich dort nichts ausgemessen habe. Ich habe mir im Gebäude zwar zahlreiche Notizen und Skizzen gemacht, aber die Lagedetails sind im Wesentlichen über die Position der Gebäudeeingänge bzw. die Gebäudeform von Bing abgeschätzt. Meiner Meinung nach ist das für ein vergleichsweise einfach strukturiertes Gebäude wie dieses in erster Näherung aber ausreichend.

Tordanik wrote:

Ich lebe dort und die damaligen Versuche mit Indoor Mapping gehen auch auf mein Konto

Dachte ich mir schon. Eigentlich ist dieses 2 Ebenen Gebäude wie geschaffen für ein kleines Beispiel. Mit automatischen Türen, Rolltreppe, diversen Shops und kleinem Parkhaus.
Wenn du meinst, die Räumlichkeiten sind so wie gezeichnet, könnte man sofort loslegen, die neuen tags einzusetzen.
Eigentlich sollte dieses Gebäude mit Flachdach und einem Lichtfenster auch als 3D einfach zu händeln sein.
Wenn du nichts dagegen hast, setze ich hier schon mal die mittlerweilen etablierten 3D bzw auch schon die neuen tags ( F3DB ) ein, damit man diese an einem Beispiel zuende diskutieren kann. Es fehlen natürlich noch ein paar Maße, die werde ich erstmal schätzen.
Wäre toll, wenn das ginge. Bis ich mit meinem Projekt soweit bin ( was ich parallel mitmache ), wird es noch was dauern.

Rogehm wrote:

Eigentlich ist dieses 2 Ebenen Gebäude wie geschaffen für ein kleines Beispiel. Mit automatischen Türen, Rolltreppe, diversen Shops und kleinem Parkhaus.

Stimmt. Wobei das "Parkhaus" nur ein Parkplatz auf dem Dach eines Getränkemarkts ist. 😉

Wenn du meinst, die Räumlichkeiten sind so wie gezeichnet, könnte man sofort loslegen, die neuen tags einzusetzen.

Die Räume stimmen im Wesentlichen, aber nicht 100% (z.B. der als FIXME eingetragene Zugang zu den Toiletten verläuft hinter, nicht vor dem nordwestlichen Raum). Und bei den Läden müsste ich noch einmal nachsehen, dort sind m.W. teils neue eingezogen.

Wie gesagt, ich komme bald mal hin und werde noch mal einen Blick auf die aktuelle Situation werfen.

Wenn du nichts dagegen hast, setze ich hier schon mal die mittlerweilen etablierten 3D bzw auch schon die neuen tags ( F3DB ) ein, damit man diese an einem Beispiel zuende diskutieren kann. Es fehlen natürlich noch ein paar Maße, die werde ich erstmal schätzen.

Hm, ich wollte dort gern auch etwas experimentieren (u.a. auch mit dem Alternativansatz, der im Indoor-Forum diskutiert wird). Können wir beide erst mal offline arbeiten und nichts hochladen, damit wir uns nicht in die Quere kommen?

Hm, ich wollte dort gern auch etwas experimentieren (u.a. auch mit dem Alternativansatz, der im Indoor-Forum diskutiert wird). Können wir beide erst mal offline arbeiten und nichts hochladen, damit wir uns nicht in die Quere kommen?

Kein Problem. Ist ja prima, wenn man eine "einfache Spielwiese" hat und sich dort austauschen kann. War mir auch etwas zu weit weg...
Vielleicht suche ich mir hier etwas ähnliches. Eine große Passage ist ja dann schon etwas umfangreicher. Und da das F3DB Konzept noch nicht steht, fängt man lieber klein an.

@ Marek. Du hast im F3DB Proposal unter "Links" http://wiki.openstreetmap.org/wiki/F3DB … g_examples eingetragen.
Dort möchtest du 3 Beispiele zeigen. Hast du dafür schon was in Aussicht oder suchst du noch?

Ich möchte konkrete Architekturbeispiele zeigen aber in Form von Skizzen wo zu jedem Element alle tags aufgeschrieben sind.
Ich habe mich aber noch nicht entschieden,welche Objekte ich nehme.
Ist jedenfalls mein selbst auferlegtes "soll" bis Freitag.

Ich bin dabei, Örtlichkeiten für das F3DB Mapping zu lokalisieren. Ergebnisse kommen später.
Die heutige Frage an alle ist, wie geht man mit Fenster um. Im F3DB ist erstmal der Hinweis auf https://wiki.openstreetmap.org/wiki/Key:window
Aber es wird in der Regel in den meissten Fällen, bei dem Indoor Mapping sinnvoll wäre, schwierig sein, die Fenster von innen zu erreichen und dann noch auszumessen.
Viel einfacher, jedenfalls bei nicht allzu hohen Gebäuden, ist die Erfassung von aussen mittels Foto und ggf. Lasermessungen.
Natürlich kann man das Ergebnis des Außen-Mapping in irgendeinerweise (OSMatiker... "Gut schätzen und mappen...") ins Indoor-Mapping übertragen. Aber jetzt haben wir einen Konflikt.
Warum kann man nicht Fenster "nur" im Simple-3D-Buildungs Verfahren taggen, auch wenn kein Indoor-Tagging möglich ist? Quatsch, ist natürlich möglich.
Aber wie bekommt man überein, das "Fenster-Tagging" sowohl im Simple-3D (outdoor) sowohl auch im F3DB (indoor) zusammen zu bringen, ohne in Konflikte mit den Abmessungen / Position / Raumzuordnung... zu geraten?
Das einfache Mapping eines Gebäudes von aussen muss man irgendwie mit den vielleicht abweichenden Indoor-Mapping kongruent bekommen. Was hat Vorrang? Muß der Indoor-Mapper das vielleicht schon vorhandene Außen-Mapping beanstanden, oder umgekehrt? Beide Messungen sind sicher mit Fehlern behaftet. Der Fehler wird umso größer, je öfter daran herumgedoktert wird. Das 3D Rendering wird nicht leichter, wenn dort Unstimmigkeiten herrschen. Sind da schon Überlegungen im Gange?
Ich habe da erstmal ein Problem. ( Nicht, wenn ich alles alleine gleichzeitig mache... )

Gruß
Rolf

Rogehm wrote:

Warum kann man nicht Fenster "nur" im Simple-3D-Buildungs Verfahren taggen, auch wenn kein Indoor-Tagging möglich ist? Quatsch, ist natürlich möglich.
Aber wie bekommt man überein, das "Fenster-Tagging" sowohl im Simple-3D (outdoor) sowohl auch im F3DB (indoor) zusammen zu bringen, ohne in Konflikte mit den Abmessungen / Position / Raumzuordnung... zu geraten?

Ich arbeite gerade an einem Satz von Tags für detailliertes Fenstermapping, das sowohl indoor als auch outdoor funktionieren soll. Ich würde das demnächst hier veröffentlichen und hoffe, dass wir damit der Lösung des Problems einen Schritt näher kommen werden.

Dann möchte ich an den Editor von Vvovv verweisen, der Fenstermapping bereits berücksichtigt.

Nur um die Tendenz sich eine eigene Scheinwelt aufzubauen kurz mal ein bisschen zu bremsen. Es gibt in http://forum.openstreetmap.org/viewtopic.php?id=25961 noch eine weitere Diskussion zum Thema und z.B. hier https://wiki.openstreetmap.org/wiki/IndoorOSM_2.0 ein anderes Proposal für indoor mapping.

Simon,
Du wurdest eingeladen mitzumachen und an der gemeinsamen Entwicklung teilzunehmen.
Schade, dass Du nicht geatwortet hast.
Wir wollen uns alle die an dem Thema interessiert sind, treffen und Ideen austauschen, über Pros und Cons diskutieren.
Ich schätze die Arbeit von Tordanik sehr, ich schätze auch Vvovv und ebenfalls die Freunde von der Uni Heidelberg die an dem Treffen in Erlangen teilnehmen werden. (Prof. Zipf hat da ein Terminkonflikt, seine Mitarbeiter sind aber dabei).
Wir wollen offfen über das Thema reden und alle Vorschläge und Ideen im Hinblick auf das Gesatmprojekt besprechen.

Ich finde also Deine Formulierung "eigene Scheinwelt" einfach unverschämt; und zwar allen Teilnehmer gegenüber.

Tordanik wrote:

Ich arbeite gerade an einem Satz von Tags für detailliertes Fenstermapping, das sowohl indoor als auch outdoor funktionieren soll. Ich würde das demnächst hier veröffentlichen und hoffe, dass wir damit der Lösung des Problems einen Schritt näher kommen werden.

Ja, super. Aber eigentlich, IMHO ergibt sich das Problem meißt von alleine. Auch wenn man, wie es sicher am sinnvollsten ist, das Gebäude erst einmal als Simple 3D Gebäude taggt, werden doch meisst erst die Fenster vergessen. Dann kommt der Indoor Mapper und muss dann wohl auch Außenmapping machen, um Fensterformen und Größe den jeweiligen Etagen und Räumen zuzuordnen.

marek kleciak wrote:

Dann möchte ich an den Editor von Vvovv verweisen, der Fenstermapping bereits berücksichtigt.

Ich hatte etwas Probleme, den richtigen User rauszufinden. Es ist natürlich vvoovv. Der Kollege aus Rußland arbeitet wohl sehr professionell mit dem 3D Editor "Blender" und dem OpenSource Map Tool "Tilemill". Ich glaube, da sind die meißten User hierzulande etwas überfordert mit.
Aber sein Blog über diese Anwendungen ist sehr interessant.
Ich habe mir den 3D Editor "Blender" jetzt mal runtergeladen. Bedarf natürlich einiges an Einarbeitung. Sieht aber erstmal vielversprechend aus.

SimonPoole wrote:

Nur um die Tendenz sich eine eigene Scheinwelt aufzubauen kurz mal ein bisschen zu bremsen. Es gibt in http://forum.openstreetmap.org/viewtopic.php?id=25961 noch eine weitere Diskussion zum Thema und z.B. hier https://wiki.openstreetmap.org/wiki/IndoorOSM_2.0 ein anderes Proposal für indoor mapping.

Hier wird nichts gebremst. Die Diskussion mit dem Indoor-Mapping geht jetzt schon über 4 Jahre. Wird nun Zeit, das da was bei rauskommt. Es geht natürlich nur, wie es Marek immer wieder versucht, nur im Konsens und in der offenen Diskussion, wobei dann aber auch Ergebnisse folgen sollten. Die "Scheinwelt", ich nenne es lieber "Wunschwelt" existierte dann wohl bei jedem User, der sich in der Vergangenheit mit diesem Thema beschäftigt hat, also auch bei dir.
Das ich auch im deutschen Forum eine kleine parallele Diskussion mit diesem Thread führe, hat den alleinigen Grund, das nun nicht wirklich alle deutschen User in der englischen Sprache so bewandert ist, das sie ohne Probleme in engl.sprachigen Foren mitreden möchten ( inkl. ich !). Die "Übersetzer" sind mir leider noch nicht ausgereift genug.
Aber das allgemeine Interesse ist ja da bei den "Deutschen". Das sieht man an der doch recht hohen Anzahl an Aufrufen. ( Ja klar, ich rufe den Thread 100* tgl auf... 😛 )

Noch was eigenes. Ich hab durch Zufall nun endgültig ein Gebäude gefunden, das hierzulande das 1.? F3DB Tagging "abbekommen" soll. Es ist ein nicht so großes Museum.
Mit leichten Gefälle draussen, 2 Etagen, Zwischenetagen, Dachetage, Fahrstuhl, mehrere Treppen, Raumbezeichnung... und Fotografiererlaubnis! Also optimal.
Muß das Gebäude jedoch erst mal in 3D umbauen, bevor ich es vorstelle.

Hallo,

Ich brauche dringend im 3D Mapping einen tag für "Fensterladen" - engl- "Window_shutter". Das macht bei vielen Gebäudenansichten ein anderes und korrektes "Outfit" aus.
Außerdem ist die Position solcher Fensterläden, die ja eigentlich schon zum Türmapping gehört, noch zu klären.
Meißtens sind diese Läden in Deutschland "offen arretiert", d.h. es ist in der 3D Außenmauer zuzuordnen, und es gibt ein ganz anderes Bild des Hauses ab.

Außerdem brauche ich einen tag für "Falltüren" (engl- trap_door). Ganz wichtig für Indoor-tagging (z.B. Dachzugänge) und auch für aussen (bei einem meiner F3DB-Vorversuche auch ganz wichtig!)
Den User "Species" habe ich bezüglich dessen schon angeschrieben , aber noch keine Antwort.

Ich weiß, das ich penetrant "drängele". Aber das sind hier nur wichtige Zusatzvorschläge für F3DB.

Gruß Rolf

Rogehm wrote:

...

Hier wird nichts gebremst. Die Diskussion mit dem Indoor-Mapping geht jetzt schon über 4 Jahre. Wird nun Zeit, das da was bei rauskommt. Es geht natürlich nur, wie es Marek immer wieder versucht, nur im Konsens und in der offenen Diskussion, wobei dann aber auch Ergebnisse folgen sollten.

Ich sehe da nichts von Konsens, sondern nur ein Vorschlag für "yet another indoor tagging scheme" der a) zu kompliziert (resp. keine einfachen Grundvarianten hat) und b) mit überhaupt nichts rückwärts kompatibel ist. Sprich die Fehler der letzen 4 Jahre wiederholt, anstatt das Erfolgsrezept vom S3DB anzuwenden.

Scheinwelt: den Konsens muss man sich erarbeiten, sprich eben keine Privatdiskussion im Deutschen Forum führen sondern mindestens auf tagging und im indoor Forum, sonst muss man damit Leben, dass möglicherweise sein Lieblingsvorschlag gekippt und was ganz anderes gemacht wird.

Simon

marek kleciak wrote:

Simon,
Du wurdest eingeladen mitzumachen und an der gemeinsamen Entwicklung teilzunehmen.

In OSM braucht niemand eine Einladung um mitzureden und es ist auch so was von Wurst ob man ein Prof, ein Strassenarbeiter oder sonst was ist und genau so sind alle Taggingvorschläge gleich, egal welcher Provienz. Nach den vielen Jahren hast du immer noch nicht verstanden wie OSM funktioniert.

Simon

Nach den vielen Jahren hast du immer noch nicht verstanden wie OSM funktioniert.

Dito Simon.
Das Gleiche denke ich über das, was Du tust.

Jeder kann Vorschläge machen und Menschen einladen um darüber zu sprechen. Niemand gibt Befehle, niemand redet andere Manschen klein.
Wir argumentieren sachlich.
Wenn Du einen Vorschlag machst wird das Leben - sprich -die Mapper, entscheiden ob man es angenommen wird oder nicht.
Ich habe mir Deinen Vorschlag angesehen, auch nach der Überarbeitung. Ich sehe dort inhaltliche Schwächen und bin gern bereit darüber zu reden.

Und ich freue mich, dass Du den Erfolg von S3DB siehst, denn ich habe es damals genauso gemacht wie ich jetzt vor habe:
Einfach Leute eingeladen, damit wir gemeinsam über das Problem reden können und gemeinsam nach einer Lösung suchen.
Wenn Du also OSM so gut verstehst, komm vorbei.

marek kleciak wrote:

Und ich freue mich, dass Du den Erfolg von S3DB siehst, denn ich habe es damals genauso gemacht wie ich jetzt vor habe:
Einfach Leute eingeladen, damit wir gemeinsam über das Problem reden können und gemeinsam nach einer Lösung suchen.

Natürlich ist das ein erheblicher Unterschied. Es handelte sich um einen offenen 3D-Workshop mit einer gemeinschaftlich erarbeiteten Tagesordnung. Die Terminierung fand über Doodle statt. Es gab zu diesem Zeitpunkt bereits "etablierte" 3D-Taggingschemen, die sich aber in Details unterschieden. Der Workshop war daher vor allem ein Treffen der entsprechenden Entwickler, ihre Bemühungen in einem Taggingschema zu vereinheitlichen.

Dein jetziger Workshop hingegen basiert auf einem (für mich zu komplizierten) Vorschlag von dir, der gleich an mehreren Stellen das OSM-Tagging ändern/spezifizieren will. Ich fände z.B. einen Indoor-Workshop immer noch ansprechender als einen F3DB-Workshop! Aber auch dann finde ich es suboptimal, einen Workshop zu veranstalten der ein Tagging "absegnen" soll statt eines zu entwickeln.

Als wichtigsten Punkt sehe ich aber nach wie vor einen offenen Prozess so ein Tagging zu entwickeln, wie es Simon im Indoor-Forum gestartet hatte. Da kann sich dann auch wirklich jeder beteiligen und ist nicht auf persönliche Einladungen angewiesen. Dann kann man sich nämlich auch mal hinsetzen und das Tagging z.B. in JOSM testen und Problemstellen melden und evtl. verbessern. Es können dann auch Leute teilnehmen, für die es nicht so einfach ist mal eben ein Wochenende nach Deutschland zu fliegen ... das hatten wir aber schon mal 😉 Ein Tagging zu entwickeln ist zudem auch ein längerer Prozess und braucht sicherlich mehrere Iterationen. Da kann ein Workshop zwar ein sinnvoller Weg sein, sich über ein mögliches Tagging zu unterhalten, ich befürchte aber, dass erstens zu viele Personen ausgeschlossen werden (sicher ungewollt) und zweitens kein sinnvoller Vorschlag für eine weitere Diskussionsgrundlage entsteht, sondern eine weitere Wikiseite, die ebenfalls den Anspruch auf Gültigkeit (und Vollständigkeit) erhebt. Ich schließe mich daher Simons Kritik an.

Peda wrote:

"absegnen" soll statt ... zu entwickeln.

Da kann ich nur mit dem Zitat antworten:
Hier wird nichts gebremst. Die Diskussion mit dem Indoor-Mapping geht jetzt schon über 4 Jahre. Wird nun Zeit, das da was bei rauskommt.

Und klar, ich bevorzuge die Lösung an der ich mit den anderen Menschen die tief in der Materie stecken diskutiert habe.
Ich möchte in einem Workshop den Entwickler aufzeigen, warum ich diese Lösung bevorzuge und welche Vorteile sie für OSM hätte.
Ich kann durchaus verstehen, dass ein neues Schema, insbesondere von diesem Umfang, auf Vorbehalte stößt.

Was Tagging angeht, so ist die F3DB Seite ein Arbeitsdokument und unser Treffen soll ausgerechnet nicht "absegnen" sondern gemeinsam entwickeln. Und sicherlich: wir werden weitere Iterationen brauchen und es ist gut so, denn wir werden bei einem komplexen Thema wohl nicht an alles erdenkliche denken können. Trotzdem können wir hier ein für alle nützliches Gerüst schaffen, davon bin ich überzeugt.

Ab #96 sage ich heute erst mal nichts dazu, nur das dieser Thread ursprünglich nicht dafür gedacht war, eine Grundsatzdiskussion über das "Für und Wieder" von "einfachen" Indoor-Mapping und einem heranwachsenden und fast "ausgereiften" Indoor-Mapping Verfahren, das auch noch in 5 Jahren Bestand haben könnte, hier zu führen. Wem das F3DB zu komplex ist, braucht es ja nicht zu unterstützen. Ich finde jedoch den modularen Aufbau von building, areas, indoor:walls, indoor:zones, etc. schon sehr gut entwickelt. Hier kann sich der User Step by Step an einem "Faden" von Stufe zu Stufe hangeln, um im Endeffekt das gesamte F3DB Gebäude zu erfassen.
Allerdings bin ich der Meinung, das "Tagging of door direction" sollte als eines der letzten Punkte im Gesamtschema behandelt werden. Dazu muss das Gebäude extrem gut erfasst werden, und das könnte in vielen Fällen entweder nicht mehr möglich sein oder sich lange herauszögern, da man dazu das Gebäude in und auswendig kennen muss.
Viel wichtiger erscheint mir die Erfassung der Fenster im Gesamtkomplex des Gebäudes. Eigentlich sollte die Erfassung von Fenster schon im Schema S3DB integriert sein.
Weiter oben habe ich das Thema schon mal angeschnitten. Das gehört eigentlich nicht ins Indoor Schema. Obwohl F3DB Indoor und Outdoor miteinander verbinden will, ist das Thema Fenster "Outdoor-mapping" pur (Indoor-Mapper korrigieren dies vielleicht noch) . Die nicht vorhandenen Fenster in der F4 Karte oder die vielen kleinen Fensterchen in OSM2World nerven doch, oder nicht?
Also hier die Bitte: Forciert das "Fenster"-Thema.

Gruß Rolf

Rogehm wrote:

Ab #96 sage ich heute erst mal nichts dazu, nur das dieser Thread ursprünglich nicht dafür gedacht war, eine Grundsatzdiskussion über das "Für und Wieder" von "einfachen" Indoor-Mapping und einem heranwachsenden und fast "ausgereiften" Indoor-Mapping Verfahren, das auch noch in 5 Jahren Bestand haben könnte, hier zu führen. Wem das F3DB zu komplex ist, braucht es ja nicht zu unterstützen. Ich finde jedoch den modularen Aufbau von building, areas, indoor:walls, indoor:zones, etc. schon sehr gut entwickelt. Hier kann sich der User Step by Step an einem "Faden" von Stufe zu Stufe hangeln, um im Endeffekt das gesamte F3DB Gebäude zu erfassen.
...

IMHO sollte ein gutes Taggingschema einerseits erlauben was grob zu erfassen und dann schrittweise, falls gewünscht, zu verfeinern und anderseits sollte das System auch einfach erweiterbar sein (dazu gehört zum Beispiel Werte tatsächlich als Werte zu erfassen und nicht alles in den Eigenschaftsnamen zu verfrachten).

Im Augenblick verliert sich F3DB extrem im Detail (wie du erwähnst z.B. die Türenöffnungsrichtungen) ohne ganz grundsätzliche Sachen zu definieren, z.B. wie man angibt auf welchem Stockwerk die Objekte im Gebäude sind, wieviele Stockwerke das Gebäude hat etc. Sprich es ist eher weit von einem implementierbaren Vorschlag weg, ABER grundsätzlich sind soweit überhaupt feststellbar z.B. IndoorOSM IndoorOSM 2.0 und F3DB konzeptionell nicht sehr verschieden und alle könnten ein beliebig detailreiches Mapping unterstützen.

Grundsätzlich dürfte aber den meisten Leuten vorallem wichtig sein: wo is was im Gebäude und wie komm ich dahin? Und nicht eine möglischst detailgenaue Erfassung der Inneneinrichtung.

Simon

marek kleciak wrote:

...
Wenn Du einen Vorschlag machst wird das Leben - sprich -die Mapper, entscheiden ob man es angenommen wird oder nicht.
Ich habe mir Deinen Vorschlag angesehen, auch nach der Überarbeitung. Ich sehe dort inhaltliche Schwächen und bin gern bereit darüber zu reden.
...

Das ist aber der Punkt, anstatt ständig Metadiskussion zu führen (wir müssen jetzt zuerst einnal darüber reden, das wir über was reden müssen) und die eigentliche Sacharbeit irgendwo anders, nicht öffentlich, zu machen, könntest du einfach deine Anmerkungen hier auf den Tisch legen.

Wie du weist war IndoorOSM 2.0 schlicht eine Modifikation vom bereits funktionierenden (von den internen Verbindungen mal abgesehen) IndoorOSM mit einigen umbenannten Tags wegen den Konflikten mit S3DB. In der Diskussion im Indoor-Forum wurden noch diverse Änderungen gewünscht (vor allem die Relationen optional zu machen), die ich nachgetragen habe. Das einzige was wirklich auf meinem eigenen Mist gewachsen ist, ist der Vorschlag für ein einfaches kompatibles inddor POI Mapping.

Simon

SimonPoole wrote:

ABER grundsätzlich sind soweit überhaupt feststellbar z.B. IndoorOSM IndoorOSM 2.0 und F3DB konzeptionell nicht sehr verschieden und alle könnten ein beliebig detailreiches Mapping unterstützen.

Ja, klar. Beide Konzepte nähern sich an. Aber du musst zugeben, Marek's Vorschlag ist schon etwas ausgereifter. Eigentlich könntet ihr euch schon einigen auf Indoor Tags.
Das das Indoor Tagging getrennt behandelt werden muss, steht ausser Frage. Deshalb immer den Erstbegriff indoor:xxxx. ( Aber nur im Konflikt mit Outdoor/Normal-tagging)
Eigentlich bin ich nicht der Meinung, das es den Leuten hauptsächlich daran liegt, wie komme ich dahin..., die finden es schon so (hat ja bisher auch so gefunkt).
Vielmehr sind die Einzelheiten gefragt.
Was sind die Besonderheiten im Museum? Was für kleine Shops gibt es noch im EKZ? Auf welcher Etage ist der Shop? Komme ich dahin, auch mit Handicap?
Das wird mittels OSM dann im Vorfeld gecheckt und nicht im Gebäude selbst! Bis es derartige Apps gibt, wird es noch was dauern.
Die Inneneinrichtung finde ich wichtig ( speziell in EKZ ). Gibt es dort Relax-Zonen? Kann ich mein Kind abgeben? Wo kann ich 'nen Kaffee trinken? Ich hab Hunger!
Natürlich sollte auch ein Indoor Weg vorgegeben sein. Aber hier bleibt zu überlegen, ob als Einstieg nicht der "Level 0 Durchgang" reicht.

Wir sind auf dem richtigen Weg, denke ich.

Rolf

Simon wrote:

Im Augenblick verliert sich F3DB extrem im Detail (wie du erwähnst z.B. die Türenöffnungsrichtungen) ohne ganz grundsätzliche Sachen zu definieren, z.B. wie man angibt auf welchem Stockwerk die Objekte im Gebäude sind, wieviele Stockwerke das Gebäude hat etc.

Die Öffnungsrichtungen sind in der Tat nebensächlich. Du hast aber Recht indem Du sagst dass momentan auf F3DB wesentliche Dinge fehlen:
Wir haben aber diese Themen, wie z.B. die Stockwerksproblematik in einem 2 Tage Marathon mit Thomas Graichen diskutiert und einen Vorschlag ausgearbeitet.
Jetzt ist Thomas dran, diese Vorschläge in die F3DB Seite einzutragen.
Was von dieser Arbeitsrunde auch fehlt, ist das Konzept für , nennen wir´s, Level of Detail: Es soll möglich sein, ein Bauwerk in Detaillierungsstufen aufzubauen. Ich hoffe, dass Thomas in Kürze die Zeit findet dies einzutragen.

Angeregt von dieser Diskussion und weil ich sowieso gerade vor Ort war, habe ich nun auch mal ein Einkaufszentrum neu gestaltet, zumindest zu einem Drittel, der westliche Teil:
http://www.openstreetmap.de/karte.html# … ers=000BTF
Ich habe zuerst die einzelnen Geschäfte als building:part=yes und den Fußweg als Fußgängerzone bezeichnet. Ist aber so nicht schön. Vor allem wirden die Grenzen der einzelnen Läden nicht angezeigt.

Hiernach https://wiki.openstreetmap.org/wiki/F3D … door_Areas sollte man die einzelnen Räume als
indoor:area=*
name=*
bezeichnen, wobei mir nicht ganz klar ist was man da schreiben soll. indoor:area=room oder yes oder shop?
Den öffentlichen Bereich habe ich nun als indoor:highway=footway bezeichnet, das ist schlüssig, wobei man vielleicht noch die Bereiche, wo Tische etc. stehen abgrenzen könnte.

Das Ergebnis in der Karte ist aber nicht wirklich schön. Es erscheint ein roter Klotz, das building=yes und nicht einmal die Fußwege werden angezeigt, geschweige die Umrisse der einzelnen Läden. Also dann doch wieder footway=yes einzeichnen?

edit:
sehe gerade, dass auch Google das ähnlich gemacht, hat, wenn auch meine Unterteilung genauer ist. Aber so sollte das dann auch auf unserer Karte aussehen:
https://maps.google.de/maps?ll=49.52622 … sic&dg=opt

Moin,

wegavision wrote:

Das Ergebnis in der Karte ist aber nicht wirklich schön. Es erscheint ein roter Klotz, das building=yes und nicht einmal die Fußwege werden angezeigt, geschweige die Umrisse der einzelnen Läden. Also dann doch wieder footway=yes einzeichnen?

indoor sollte indoor:* bleiben.
footway oder pedestrian nur, wenn es sich um eine immer öffentlich zugängliche Passage handelt.
Ist jedenfalls meine Meinung.

wegavision wrote:

edit:
sehe gerade, dass auch Google das ähnlich gemacht, hat, wenn auch meine Unterteilung genauer ist. Aber so sollte das dann auch auf unserer Karte aussehen:
https://maps.google.de/maps?ll=49.52622 … sic&dg=opt

Auf welcher unserer Karten?
Kann es dann ja auch - wenn die indoor-Tags entsprechend gerendert werden.

Gruß
Georg