Neues von maps.osm2world.org

Glaube nicht, denn der Teil, der unter der Erde liegt ist in aller Regel ein “Keller”, nur wir sehen ihn nicht, und genau das passiert in einer 3D-Darstellung auch, da muss man die Bodenbeschaffenheit (Höhenlinien) berücksichtigen, dadurch verschwindet in der hinteren Hälfte des Hauses das 1. OG im Boden.

schönes Beispiel von Google:

Doch, schon im Stil des Silverline Tower. Man kann ja für den Teil unter der Erde auch noch zusätzlich ein building:part=yes machen.

Edit: wenn man zuerst alles lesen würde…
Gut, mein Beispiel würde wohl für vieles gehen. Aber für das Gebäude, wie Du es hier gepostet hast, würde meine Variante natürlich nicht stimmen. Aber das ist ja das Problem: OSM kennt eigentlich nur 2D und berücksichtigt keine Höhenlinien.

Na ja. Es ist ein wichtiges Thema für API 0.7
Wer, wo und wann kann hierfür eine Entscheidung treffen? Und wenn die Entscheidung getroffen ist - umsetzen?

Ich hab das Haus in Frage etwas vereinfacht, effektiv hat es ein hangseitiges Kellergeschoss, das aber hõher liegt als das Eingangsgeschoss, sprich das Problem ist durchaus richtig in der Zeichnung beschrieben.

Simon

Eingangsgeschoss sollte in unseren Überlegungen keine Rolle spielen. Es sollte nur die maximale Anzahl sichtbarer Stockwerke Erfasst werden.
Nehmen wir an, ein Bauwerk hat ein Eingangsgeschoss über eine Brücke. Eigentlich ist es aber 1.OG. von dem beschriebenen Gebäude.

Bauwerke am Hang haben des Weiteren gern versetzte Stockwerke. Ein klassischer “Keller” ist dort oft nur ein Funktionsraum der nicht als Keller in der Baudokumentation geführt wird.

Hi Todanik, danke für Deine Mail, klappt super.

Meine Kirchen:

Einige Anmerkungen/Wünsche:

Farbe bei Flachdächern klappt nicht?
roof:shape=half-hipped wird noch nicht unterstützt?
-i bei GUI wird anscheinend nicht ausgewertet, könntest Du alternativ eine recent-File-List ins Menü bauen?
Bei Gebäuden mit fehlender Ecke ist das Dach verdreht.

Grüße
Chris

MOin

schaut ja nett aus, “meine” Kirche: http://maps.osm2world.org/?h=128&view=N&zoom=18&lat=47.07023&lon=15.45645&layers=B0TTFF
Flachdachfarben gehen zumindest im Web: http://maps.osm2world.org/?h=128&view=N&zoom=18&lat=47.06109&lon=15.47043&layers=B0TTFF
Auch half-hipped wird ausgewertet: http://maps.osm2world.org/?h=128&view=N&zoom=18&lat=52.13521&lon=10.06778&layers=B0TTFF (das haus in braun mit schwarzem dach und das dahinter)

Das mit dem verdrehtem Dach ist nen Thema…

Amiga

Hi,

sry, wenn ich das nochmal hochrolle. Aber mir ist immer noch nicht klar, welchen Grund es hat, dass man die komplette building-Fläche mit parts überdecken muss. In mir sträubt es sich, wenn ich für eine Fläche doppelte Datenhaltung und auch doppelte Arbeit machen muss. Warum reicht es nicht, nur die “speziellen” Teile zu taggen und was nicht mit einem Part überdeckt ist, ist es eben nicht. Dann sollte doch der Algorithmus, wenn er es denn aus welchen Gründen auch immer benötigt, einfach über die “leeren” Teile selbst intern einen Part drüber legen. Bzw, warum nicht einfach in den unüberdeckten Teilen problemlos die Eigenschaften vom Building nehmen. Nix anderes würde ich doch jetzt als Mapper auch machen… Nur, dass da jetzt noch ein leerer Way mit building:part liegt, ohne Eigenschaften, da die ja vom Building kommen können oder wie oder was… Tut mir leid, ich verstehe es wirklich nicht. Mir erscheint das Doppelgemoppel völlig irrsinnig und unintuitiv. Doppelte Datenhaltung und Zeit bei der Erstellung und für Anfänger mit Sicherheit schwer zu verstehen.

Ich habe auch ein Problem damit, ein Gebäude in mehrere Teile zu hacken, nur weil es ein komisches Dach hat, was man nur als Zusammensetzung unterschiedlicher Einzelformen richtig darstellen kann. Ich meine… Das wäre doch nur Tagging für Renderer. Nur damit die 3D-Ansicht nett ist, zerhacken wir jetzt Gebäude und keiner stört sich dran?

Ich meine, ich weiß, dass ich es nicht machen muss, wenn ich nicht will, aber ich sträube mich einfach dagegen, unglaublich viel Arbeit zu investieren, die vielleicht sogar grundlegend falsch ist - oder ich es nur als falsch ansehe. Deswegen frage ich ja nochmal nach.

Anderes Problem: Wie kriege ich denn Gebäude- und Dachhöhen raus? Ich meine, alles was ich machen kann, ist Stockwerke zählen. Dann aber die Frage, ab wann zählt eine Etage als Dachgeschoss und wann nicht: Es gibt genügend Häuser, bei denen Dächer weit runtergezogen sind… Dann gibt es Häuser, die hohe Dacher haben, so, dass über der letzten sichtbaren Etage gern noch mal ein halbes oder gar ganzes Stockwerk Platz hat. Ist das dann ein level +1 oder nicht…

Und wie erkenne ich die Farben? Mareks Vorschlag ist nicht nutzbar: Ich kann nicht voin jedem Haus der Siedlung ein Foto machen, das dann bearbeiten (2x!) um die Farbe rauszukriegen und die dann zu setzen:
a) Hat niemand so viel Zeit, um das flächendeckend zu machen
b) Die Lichtverhältnisse und Farbwerte bei Fotos das ganze verfälschen
c) Ich neulich von einer Kripo-Streife angehalten wurde, nur weil ich mich für Hausnummern interessiert hab. Meinten, ich würde Häuser auskundschaften, in die es sich einzubrechen lohnt. Wie soll ich denn da Fotos erklären?

Wie gesagt, es gibt mir noch zu viele Ungereimtheiten, als dass ich irgendwie ernsthaft motiviert wäre, da viel viel viel Zeit reinzustecken. Aber ich würde mich freuen, erleuchtet zu werden. :slight_smile:

@S-Man42

Der Beitrag von Tordanik in #83 hat mich etwas bekehrt, zumindest was die building-parts betrifft. Bleiben wir beim Kirchturm. Die Kirche ist als eine Fläche getagt, mit Höhe. Welche Höhe wird wohl eingetragen sein? Die Gesamthöhe. Niemand trägt bei einer als eine Fläche getaggten Kirche die Höhe ohne Kirchturm ein…
Jetzt komme ich, und trage den Kirchturm ein, setze die Höhe dran und lasse den Rest des Gebäudes ohne building-part aussen vor. Dann wären Kirche und Turm gleichhoch. Da bleibt wohl nichts anderes übrig, als alle Building-Flächen mit parts zu belegen.

Der andere Punkt ist, wieviel Gebäude sind das denn, die ‘zerhackt’ werden? In reinen Wohngebieten werden das nicht viele sein, ok, Häuser in L-Form wären so ne Sache. Aber da das Building aussenrum erhalten bleibt, braucht ja der, der sich um parts nicht schert, die nicht auswerten.

In Sachen Indoor-Mapping werden eh viele Gebäude geteilt werden. Bis jetzt sehe ich zum Beispiel den Bäcker vorne im Supermarkt in den meisten Fällen als Node eingetragen. Mal sehen, wann sich Flächen dafür durchsetzen… An Shopping-Malls gar nicht zu denken…

EDIT: Aber fremde Häuser zu Fotografieren (aus nächster Nähe, wegen dem Farbton) und mit Laser zu vermessen, würde ich mich auch nicht trauen… :wink:

Danke für deine Antwort, aber:

überzeugt mich nicht. Was hindert mich, nun ans Building die Nicht-Turm-Höhe ranzuschreiben?

Und auch in Einfamiliensiedlungen kann man gut hacken, wenn man denn möchte: Vordächer, Erker, Verandas, Seitenflügel, Garagen, etc…

Nix, aber dann pack zusätzlich an das Building=church auch building:part=yes
und an den Turm ein min_height, dann stellst du den Turm auf die Kirche. Simple :smiley:
vgl. http://www.openstreetmap.org/browse/way/183545979

Hab ich doch geschrieben. Wer ne Kirche als eine Fläche einträgt, wird die Gesamthöhe eintragen. Und nach eintragen des Turms am Gesamtgebäude die Höhe auf die Höhe ohne Turm zu ändern, halte ich für noch falscher. Die Höhe des Gesamtbuildings ist die Gesamthöhe. Und die sollte für den Fall, das jemand Höhen der Buildings verarbeitet, erhalten bleiben. Btw, in Informationsschriften zu Kirchen steht auch nicht drin: ‘Die Kirche ist 10m hoch. Und dann ist noch ein Turm drauf…’ :wink:

Zu den Siedlungen: Erker sind glaub ich im 3D-Schema abgedeckt, Garagen hab ich auch so schon getrennt; denn eine Garage ist eine Garage und kein Haus, Verandas sind kein Teil des Gebäudes…
Ich denke, so viel zum Hacken bleibt da wirklich nicht. Komplexe Gebäude wie Malls usw. sind da natürlich was anderes

EDIT: @reneman: Halte ich für falsch. Siehe erster Absatz dieses Postings

Was mich wundert. Hätte gedacht, man bestimmt das kleinste umhüllende Rechteck und nimmt das
als Basis für die Dachberechnung.

Anwendungen, die keine 3D-Renderer sind, werden Building Parts normalerweise ignorieren. Wenn also jemand nach den höchsten Kirchen sucht, verwendet er dazu die height-Tags am building.

Anders gesagt: Die Definition, was height an einem Building bedeutet, gab es schon vor den Building Parts, und wenn man sie ändern möchte, müsste man sich darüber auch außerhalb des 3D-Zirkels einig sein.

Zugegeben tritt dieses Problem aber dann nicht auf, wenn die gesondert eingetragenen Gebäudeteile niedriger sind als der Rest. In diesem Fall ist die Begründung einfach: Das wurde so definiert und manche Anwendungen verlassen sich womöglich darauf. Eventuell sollte ich das noch mal neu mit den anderen Entwicklern ausdiskutieren, wenn es für mehr Mapper ein Problem ist.

Genau das Thema hatten wir gestern schon, da wurde es nicht abgelehnt. Die Bsp. von http://www.openstreetmap.org/browse/way/183545979 werden auch korrekt in OSM2World wieder gegeben. Die Frage die noch offen war ist, ob die Relation unbeding erforderlich ist. Und bzgl. Höhe, dafür gibt es extra viele height-Werte: building:height; est_height; height; maxheight; maxheight:physical; min_height; roof:height; …

nochmals hierzu… hätte jemand einen Vorschlag, wie man ein abgerundetes Dach taggen soll? wie gesagt, roof:shape=round finde ich nicht optimal.

z.b. untere Eishalle hat ein abgerundetes Dach (und dies möchte ich wenn möglich in OSM auch gerne so wiedergeben):


Zusätzlich zu roof:shape=round kannst du mit roof:ridge die höchste Linie definieren. Zusätzlich mit roof:height die Dachhöhe, dann wird das runde Dach ensprechend Flach gedrückt :slight_smile:

Das ist ein Problem mit der Stildefinition. Eigentlich unlängst gelöst, hat es aber noch nicht in den herunterladbaren Beispiel-Texturstil geschafft.

Sollte unterstützt sein, hab auch schon einige eingetragen. Muss an was anderem liegen.

Ja, lässt sich wohl machen.

Leider ein bekanntes Problem.

wie meinst Du das genau?
building=yes
height=10 (also inkl. Dachhöhe?)
roof:shape=round

dann eine Linie für den “First”?
roof:ridge=Yes
roof:height=5

hmmm… wäre das so korrekt?

Habe grad festgestellt, dass

building:roof:ridge = yes
building:roof:edge = yes
building:roof:apex=yes

wie es hier zu lesen ist, in OSM2World nicht funktioniert.
Aber,

roof:ridge = yes
roof:edge = yes
roof:apex = yes

funktionieren, vgl. http://osm2world.org/docs/taglist.txt

@efred: roof:height=5 muss ans building