Gibt es bereits Tools, mit welchen man m-genau Daten in Josm erzeugen kann? Ich meine wenn wir jetzt schon mit 3D anfangen und dann höhe breite Länge des Gebäudes bestimmen können/müssen, dann wäre es doch unsinnig diese freihändig in Josm vom Luftbild abzumalen.
So heute habe ich mich mal daran gemacht und einen ersten Versuch unternommen Schrägdächer auf das Haus zu setzen. Allerdings habe ich dabei einige Überaschungen erlebt.
http://wiki.openstreetmap.org/wiki/File:OSM3Dworkshop_1.1.png
während die 3 Gebäude in der Mitte eigentlich erwartungsgemäß aussehen, sind die beiden querstehenden links genau falsch rum. Warum? Das Eckhaus ist noch spannender. Hier sollte eigentlich auch das Dach um die Ecke gehen.
Alles ist so, wie Kendzi es programmiert hat. Die BEschreibung beinhaltet noch nicht die Darstellung aller Fälle. Am besten direkt bei ihm nachfragen was Sache ist: Die Bugs und Überraschungen sind wertvoll denn sie zeigen, wie jemand, der gerade dmait beginnt, arbeitet, und was ihn stört.
Was in dem PlugIn fehlt ist eine gut strukturierte Help Funktion.
Beispielsweise für das Gebäude Typ 2.0 auf dem L-Grundriß wird das Dach auf einem Bounding Box Gesamtbreite x Gesamttiefe angelegt und daraus erst Teile entfertn. Dann sieht ein Eegebnis so aus, wie es aufd dem von Dir angehängtem Beispielsbild aussieht.
Eine Funktion für Dächer Types: 1.0 und 2.0 für Gebäude in Form mehrmals gebrochener Linie ( z.B. für eine Z, N, M, U Form) mit der Funktion “entlang des Verläufes generieren” ist noch nicht implementiert. Es wird aber kommen.
Das ist doch normal! Der Programmierer dokumentiert frühstens wenn er fertig ist. Außerdem ist ja auch noch nicht alles spezifiziert. Wie soll es da schon in der Hilfe sein.
Naja der Typ 9 sah mir schon nach sowas aus. wenn ich den aber versuche wird nichts mehr angezeigt. Vielleicht weil es noch nicht implementiert ist.
Kompliment dafür, dass die Keytabelle angepasst wurde. Jetzt kann man endlich was mit den Höhen und Längen anfangen. Die Bildchen sind auch gut beschriftet. Man findet also auch schnell die betreffenden Dinge und es scheint bis auf wenige Ausnahmen auch zu funktionieren. Bei Dachtyp zwei hat mich die Einteilung etwas irritiert. Ich hatte nach 2.0 als 2.1 eigentlich den Typ 2.4 erwartet. Ich denke der wird wesentlich häufiger zu finden sein als die anderen beiden Vertreter. Es sei denn, man baut Häuser dann aus Einzelelementen zusammen. Sonst dürfte der Typ2.1 nur als Anbau vorkommen nicht aber als Hausdach an sich.
Eventuell ist noch von Bedeutung bei den Tags für die Höhen und Breiten, dass man erkennen kann, wann die für das Haus sind und wann die für Gauben oder Anbauten gelten. Vielleicht wäre es sinnvoller, an jeder Tabelle nochmal den Grundschlüssel anzugeben.
Ich gebe zu dass ich mit der Reihenfolge einiger Gebäudetypen nicht zufrieden bin. Besser gesagt: Vieles ist zwar nach reichlicher Überlegung aber die Reihenfolge nach Schnauze. Wir müßten prüfen, ob schon jemand mit diesem Typ gearbeitet hat. DEnn wenn wir jetzt Typologie umschreiben, kann es zu Fehler füren, wenn irgendwo vertreten.
… Vielleicht wäre es sinnvoller, an jeder Tabelle nochmal den Grundschlüssel anzugeben… Warum nicht. Machst Du einen Vorschlag?
Ein sinnvoller Tagging ist hier enorm wichtig und wir sind un mmit Kendzi sehr unsicher was das angeht…
Ich denke vielleicht sollte man die Nummerierung wirklich nicht mehr ändern. Aber wenigstens die Reihenfolge in der Tabelle dann vielleicht.
Wie würden denn bei dir zwei Balkons über einander aussehen? Als Tags meine ich.
Wenn zwei oder mehrere Elemente die identisch sind, übereinander liegen, müsste der Punkt einen Tag erhalten der sinngemäß “number of…=value” heißen müßte. Danach von unten aus: balcony1:height=value, balcony2:height=value usw… Spezifiziert haben ich das aber noch nicht.
Elegant wäre ( auf den ersten Blick) nur die Anzahl der Elemente und den wiederholbaren Abstand dazwischen anzugeben, damit alle anderen den gleichen Abstand bekommen. Leider sind oft die Geschoßhöhen leicht unterschiedlich ud auch für diesen Fall muß man sich was ausdenken.
Irgendwelche Vorschläge?
Meines Erachtens häufen sich hier die Zeichen dafür, dass ein Problem mit diesem Aspekt des Datenmodells existiert: Man hat keine feste Anzahl Schlüssel, sondern muss jedes Attribut (Form, Farbe, …) über eine Nummerierung der passenden Instanz zuordnen. Es werden Tags für mehrere Objekte an einen einzelnen Node gehängt, normale Vorlagen können nicht mehr “natürlich” auf einzelne Balkone angewendet werden.
Dieses Problem habe ich vor ein paar Tagen schon in einem anderen Kontext diskutiert - da ging es um Indoor-Mapping. Jemand hat vorgeschlagen, zwei Toiletten, die z.B. im dritten und vierten Stock, aber direkt übereinander liegen, als einen einzigen Knoten zu taggen und dann mit einem komplizierten Relationenkonstrukt die Attribute zuzuordnen (z.B. “Toilets=B;3[female=yes;male=no];4[female=no;male=yes]”, wenn die Toilette im 3. Stock eine Damen-, die im 4. Stock eine Herrentoilette ist). Da sträuben sich mir die Haare, und ähnlich geht es mir leider auch mit den übereinander liegenden Balkonen.
Wenn es sich um Objekte im Gebäudeinneren handelt, dann ist meine Position klar: Zwei Nodes an identischer (oder wenigstens ähnlicher) lat/lon platzieren und zusätzlich ein level-Tag setzen.
Bei den Balkonen fände ich das auch am besten. Leider kommt da die Schwierigkeit hinzu, dass sie in den Gebäudeumriss eingefügt werden sollen. Denkbar fände ich …
- … die Balkone nicht in den Umriss einzufügen, sondern nur in dessen Nähe zu setzen. Es wird dann ein Lot auf den Gebäudeumriss von der Nodeposition gefällt.
- … die Balkone als Ways zu zeichnen.
- … mehrere Umrisse für die Stockwerke zu zeichnen. Bei vielen Gebäuden ist der Umriss ohnehin nicht konstant über alle Stockwerke. Wenn man das Gebäude so detailliert erfasst, dass man Nodes für einzelne Balkone setzt, ist das Zeichnen von Stockwerksumrissen vielleicht auch zumutbar.
Richtig gut gefällt mir nichts davon, aber ich würde die Alternativen dem Versuch vorziehen, mehrere Objekte mit im 3D-Raum eindeutig unterschiedlichen Koordinaten und mit eigenständigen Attributen zu einem einzigen Node zu verschmelzen.
Also für jeden Balkon einen Punkt zu setzen ist mit Sicherheit nicht besser. Warum? Wenn wir Häuser mit 17 Stockwerken haben und uns dann auch noch vorstellen, dass es nicht nur Balkone gibt sondern auch noch Fenster und mehr, dann haben wir Punktwolken die nicht mehr händelbar sind. Und auch noch wesentlich weniger natürlich, als Balkon 1 balkon 2 balkon 3 für jeden Stock.
Das gleiche passiert bei deinem Vorschlag der Gebäudeumrisse. Hier würden 17 und mehr Wege übereinander liegen. Sorry, aber da halte ich es für sinnvoller für jedes Stockwerk eine Relation anzulegen. Member ist jeweils der Grundriß und die jeweiligen Schlüssel. Ziel ist es doch erstmal die einfachen Strukturen abzubilden. Jedenfalls hier in Dresden und anderen Großstädten mit Plattenbauten gibt es da jede Menge zu tun.
DEr vorläufige Vorschlag basiert lediglich auf der Idee die Außenhülle halbwegs schnell zu basteln.
Wenn wir über einzelne Toiletten reden, dann müssen wir mit dem Konzept der Geschoße arbeiten.
Habe ich bisher nur angedeutet. Demnächst mehr dazu.
Grüße.
Marek
Naja, wenn der Editor in der Lage wäre, in der dritten Dimension zu arbeiten, dann wäre die Punktwolke schon handhabbar. Das fänd ich sinnvoller, als krampfhaft aus dem 2D-Editor 3D-Modelle rauszuholen.
Man kann das sogar mit heutigen Werkzeugen einigermaßen bearbeiten. Zuerst mit dem JOSM-Filterfeature (das natürlich, wie so viele nützliche JOSM-Funktionen, wieder kaum einer kennt) einen Filter pro Stockwerk anlegen. Dann:
- erstes Stockwerk detailliert zeichnen, mit Balkonen & co.
- alles markieren, ein level=1 für alles setzen, kopieren per Strg + C.
- auf zweites Stockwerk umschalten
- einfügen per Strg + V, ein level=2 für alles setzen, ggf. stockwerksspezifische Änderungen einzeichnen
- auf drittes Stockwerk umschalten
- …
Der eigentliche Aufwand ist das erstmalige Abbilden eines üblichen Stockwerks für das Gebäude, und das kann einem kein Datenmodell abnehmen. Trotzdem sehe ich natürlich ein, dass man sich für “monotone” Gebäude eine etwas weniger detailintensive Variante wünschen würde - s.u.
Balkone mit Tags für jedes der übereinander liegenden Einzelstücke, wie Marek es für height beiläufig erwähnt hat, sind in meinen Augen nicht mehr “einfache” Strukturen.
Man kann allerdings als Zwischenlösung erst einmal so etwas wie eine “Balkonreihe” einführen, wo man dann mehrere gleichartige übereinanderliegende Balkone mit einem einzigen Objekt abdeckt. So ähnlich wie wir ja natural=tree_row haben, obwohl man mit entsprechender Ausdauer auch einzelne Bäume eintragen könnte. Aber dann sollte klar sein:
- Der Tag für eine “Balkonreihe” sollte nicht “Balkon” heißen.
- Nein, man kann den einzelnen Balkonen in einer Reihe keine individuellen Tags geben, ohne auf die detailliertere Erfassung der Balkone als Einzelobjekte zu wechseln.
- Die Möglichkeit, Balkone bei Bedarf einzeln zu erfassen, sollte von Anfang an Teil des Konzepts sein, weil sonst garantiert jemand #2 versuchen wird.
(“Balkone” stehen hier natürlich überall stellvertretend auch für andere Elemente der Gebäudehülle.)
Man braucht ja für viele Zwecke nicht einmal vollständiges 3D-Editieren. Da würde oft schon ein einfacher Stockwerksschalter im Editor reichen:
Ich klicke die Nummer des aktuell zu bearbeitenden Stockwerks an. Dann werden mir nur Objekte auf dem jeweiligen Stockwerk angezeigt, ich kann ganz normal zweidimensional editieren, und alle Objekte, die ich in diesem Modus hinzufüge, werden gleich auf dem aktuellen Stockwerk einsortiert.
Marek hat aber Recht, dass man damit direkt zu den Themen Geschoss- und Indoor-Mapping abdriftet.
Edit: Rechtschreibkorrekturen
Wie wäre es denn mit einer Relationenen? Ich könnte mir den Grundris vorstellen und darauf bassierend verschiedene Relationen je Stockwerk, wenn dort unterschiedliche Dinge existieren. Sollten die Stockwerke 2-12 gleich sein, dann behält die Ralation die Gültigkeit dafür.
Die Toiletten lassen sich auch prima in je einer Relation also im Beispiel in zwei Relationen anlegen. Einziger Member wäre der Punkt und einmal wäre es die Relation für Stockwerk 3 mit männlich und ein weitere Relation mit Stockwerk 4 für die weibliche Toilette. Genau so ließen sich auch Balkone etc. gestalten.
Also der Grundriss wie bisher und die anderen Dinge in eine Relation in der nur dieser Grundriss oder der Punkt Mitglied ist. Dazukommt ein Schlüssel von welcher Höhe bis welche Höhe das Gültig ist. So kann auch im Erdgeschoss die Fassade große Schaufenster bekommen und im zweiten dann normale Wohnzimmer Fenster.
Wäre eine intutive Tagging Idee nicht auch, wenn ich die Dachlinien einzeichne und dann anschließend nur den Dachfirst(Dachoberkante) mit einem Tag markiere und sage das sind jetzt 5 m. Dann kann sich die Softwar daraus die Dachtypen 2.0-2.4 und gegebnfalls sogar 9 selbst berechnen. Und ich würde nicht mit Ausrichtung und solchem Kram belästigt.
Das könnte auch bei Dachgauben funktionieren.
Relationen sind unbeliebt. Diese Lösung wurde funtioneren, abei ich denke, wir sollten mit API 7 das Konzept der Gechosse unterstützen.
Wie sollte es funtionieren?
In der höchsten Zoomstufe kann man die Ansicht der Karte pro Geschoß wählen bzw geschoßweise editieren. Die Elemente die in einem GEschoß liegen, bekommen dann automatisch die Zuweisung zum richtigen Geschoß. Eine ähnliche Definition kennt die IFC die ich für diese Diskussion herzlich empfehle:
http://de.wikipedia.org/wiki/Industry_Foundation_Classes
Das Format ist offen.
Warum verteufelt ihr die Relationen? Mal ganz ehrlich sind mir 10 Relationen auf einem Weg viel lieber als 10 Wege übereinander, welche dann alle noch ähnliche Tags haben.
Ihr verweist natürlich nicht zu unrecht auf die Filterfunktion von Josm, aber ich weise daraufhin dass dies meiner Meinung nach gerade bei Dachgeschoßwohnungen versagen wird. Denn die Frage ist als erstes wieviele Stockwerke hat so ein Haus? Zählt man Keller dazu? Wenn er zur Hälfte raus schaut? oder grundsätzlich nicht? Ist das Dachgeschoss ein vollwertiges Geschoss? Hier wird es später mal ganz schwer werden einen exakten Grundriss zu zeichnen, jedenfalls wenn wir aus Josm kein CAD machen wollen. Manchmal würde ich mir solche Funktionen wünschen, aber auf keinen Fall für alles und immer. Da bin ich mit Abzeichnen viel schneller.
Relationen werden immer dann schwierig, wenn man sich nicht vorstellen kann was man dort macht. Das gilt im übrigen auch für 3D. Daher ist das Plugin und auch osm2World so wichtig. Das man erstens sofort den Erfolg hat und zweitens auch Fehler erkennen kann.
Also denkt ernsthaft darüber nach ob nicht Relationen doch geeignet sind. Im Prinzip sind Wege auch bloß Relationen von Punkten. Nicht mehr und nicht weniger!
Es gibt ein Null Geschoß: Erdgeschoß, dann der Nummerierung nach weitere Geschosse (+1, +2, … +n). Das Dachgeschoß ist ein Vollgeschoß. Keller ist ein Geschoß. Mehrere Stockwerke nach unten bekommen entsprechend die Nummerierung (-1, -2, -3 … -n)
Ja, JOSM braucht mehr CAD. Insbesondere die Funktion die viele CAD Programmen kennen: Das darunter liegende GEschoß ist sichtbar, kann abgefragt, aber nicht geändert werden. Somit kann man ein Geschoß nach dem anderen nachzeichnen. Sind Geschoße wiederholbar, wäre eine copy paste funktion für Elemente super: Somit konnte man den gesamten Grundriß eines Einkaufszentrums kopieren, ein Geschoß höher einsetzen und dort modifizieren.
Ich habe nichts gegen Relationen außer dass sie von Anfänger schwer verstanden werden. Daher versuche ich sie umzugehen.
Doch es gibt einen sehr wichtigen Unterschied:
- Relationen sind per se nicht sortiert.
(Bei manchen gibt es nicht mal ein Kriterium dafür) - Bei Wegen sind die Knoten in der Reihenfolge sortiert,
in der sie im Weg auftreten.
(andere Reihenfolge → anderer Weg)
In einem Punkt allerdings ähnelt ein Weg den Relationen: Er stellt eine Beziehung zwischen den Knoten her.
Edbert (EvanE)
Da möchte ich dir wiedersprechen.
Ein Dachgeschoß ist kein Vollgeschoß, wenn es entweder ein Schrägdach ist oder wenn es von der Hauskante zurück gesetzt ist.
Übrigens gibt es Firmen, die ihre Etagen von der untersten (=1) bis zur obersten durchnummerieren. Das Erdgeschoß ist dann auf 2,3,4,… Das ist für den Besucher verblüffend, vereinfacht aber das Raum-Managment.
Für OSM-Zwecke funktioniert Erdgeschoß=0 (~Eingänge) genauso gut, wie es layer=-5/…/5 schon lange zeigt.
Edbert (EvanE)
Hallo Edbert,
die “Geschoße” wie ich sie beschreibe haben lediglich einen Nutzwert wegen der Vereinfachung der Modellierung für 3D Darstellung.
Es sind Arbeitsebenen auf denen einzelne Nutzflächen der Gebäude dargestellt werden.
Rechtlich gesehen ist die Definition des Geschosses anders, dafür sorgt schon die Bauordnung http://de.wikipedia.org/wiki/Bauordnung
Ein Geschoß darf eine Schräge beinhalten bzw von der Hauskante zurückgesetzt sein, solange die Nutzfläche wie die Bauordnung sie definiert, 2/3 der darunterliegenden Fläche überschreitet. Die Definition ist für uns aber irrelevant: Es geht nicht um die rechtliche Definition.
Genauso gut kann man z.B. eine Brücke die zwei befahrbare Ebenen hat mit zwei “Geschoßen” einfacher modellieren.
Es tut mir wirklich leid, dass der Modeller noch nicht ansatzweise funtionert. Man könnte die Sachen über die wir theoretisch schreiben sofort viel besser veranschaulichen.