Neues von maps.osm2world.org

Ist schön und macht ein schlechtes Gewissen, nix dafür getan zu haben... Die Schummerung tut der Karte gut.

Ein Permalink auf osm.org wäre ganz praktisch. Mir kam gerade diese Gegend sehr eigenartig vor, da hiflt ein Blick zum 2D-Renderer, das Industriegebiet im Wald zu erkennen.

Schalt doch den Layer auf mapnik um. Die Darstellung ist dann zwar verzerrt, aber erkennbar sollte alles sein.

In Hagen habe ich einen Stadtteil fast komplett mit SimpleBuildings erfasst und im restlichen Stadtgebiet finden auch einzelne Gebäude die nach dem Simplebuildingsschema erfasst sind.

Hab die 3D-Sache im letzten Jahr nicht mehr so verfolgt und habe noch Häuser mit 3dr-Tags für kendzi3d wie building:roof:shape=3dr, 3dr:length1=* usw., ist das jetzt überholt und ich muss es aufs Neue umstellen oder wie ist der aktuelle 3D-Stand?

Tordanik wrote:

Es gibt Neues von unserer 3D-Slippymap zu berichten. ... für ganz Deutschland verfügbar.

Auch auf den zweiten Blick sind aber noch einige andere Neuerungen zu entdecken, ... Multipolygone mit mehreren outer-Ways ... Küstenlinien ... Hochspannungsmasten ... verbesserten Gebäudetexturen ... Höhenschummerung ... Suchfeld sowie einen Link zum direkten Bearbeiten in JOSM ergänzt.

Werft doch einfach selber einen Blick darauf: http://maps.osm2world.org
...
Dann also: Frohes 3D-Mappen! ...

Den JOSM-Link habt ihr gut in der kaum findbaren Toolbox versteckt. Danach musste ich lange suchen.

Ich muss mir wohl angewöhnen mehr Details (Stockwerke, Dach, ...) zu Gebäuden zu erfassen. All die gleich aussehenden Kästen sollen doch nicht das Ende der Fahnenstange sein.
Schön: Es werden Eingänge dargestellt, falls sie erfasst sind. Mit building:levels werden Fenster angezeigt, praktisch um zu kontrollieren, wo das noch nicht gesetzt ist.

Eine seltsame Situation habe ich bei der Aennchenstraße, Ecke Truchseßstraße in Bonn gefunden. In osm2world wird das als dreieckiger Platz dargestellt. Auf der OSM-Standardkarte und in der Realität ist das jedoch eine versetzte Kreuzung in einer Kurve.

Nachtrag (2013-02-03):
In der deutschen Mailingliste wird von einem ähnlichen Problem berichtet und im folgenden Beitrag die Ursache dafür erläutert.
Für mich ist damit das Problem erklärt und ich habe die Ursache dafür verstanden.

Edbert (EvanE)

Schöne Karte, das gibt Ansporn, 3D-Tags zu verwenden...

Was wird denn bei Garagen ausgewertet? Wird dort eine einheitliche Größe und Flachdach angenommen, oder werden Tags zu Höhe und Dachform ausgewertet? Und die Anzahl der Garagentore wird einfach über die Breite vermutet?

sehr schön 🙂 , danke

ich brauche zeit oder einen lottogewinn.......

@things-change Ich meine, dass man es manuell taggen muss, ein triggern auf landuse=garages am Gebäude (oder wenn die Gebäude in dem Bereich stehen) gibt es noch nicht

@monotar es gibt mit Simple 3D buildings ein schema, dass von vielen (teilweise nicht allumfänglich) genutzt wird. Wie der Name vermuten lässt, lassen sich damit nicht alle Eventualitäten abdecken, aber es ist dafür klein und gut handhabar und man kann schon für einen recht hohen Wiedererkennungswert sorgen 🙂 Kendzi und OSM-4D müssen irgendwann noch mal diskutiert werden (oder es gibt ein völlig neues complex 3d buildings-Schema), genauso welche POIs wie dargestellt werden müssen, wie man die 3D Modelle austauschbar bekommt, wie man ein Höhenmodell nutzen und verfeinern kann ....
Es gib also noch ein bißchen was zu tun 🙂

@tordanik Wow das ist echt schick geworden! Großes Kompliment an dich und Peda und all die anderen. Nicht nur das O2W immer besser wird, die Plattform ist ein super Showcase für alle, die sich das nicht extra installieren wollen, "um mal zu gucken" 😄

Kriegt ihr die Hardware irgendwie gesponsort, oder sollten wir euch da mal finanziell unterstützen?

Tordanik wrote:

Die auffälligste Änderung zuerst: Ab jetzt ist die Karte offiziell für ganz Deutschland verfügbar.

Hallo Tordanik,
wäre super, wenn man in dieser Map auch noch die Schweiz und Österreich sehen könnte.

Tordanik wrote:

Wie bisher nehmen wir auch weiterhin Wünsche zu kleineren Gebieten außerhalb Deutschlands entgegen, dafür haben wir noch Kapazitäten frei

Wenn Schweiz und Österreich zu gross sein sollten, wäre ich schon mit dem Kanton Freiburg zu frieden http://www.openstreetmap.org/browse/relation/1698314

Tordanik wrote:

Die auffälligste Änderung zuerst: Ab jetzt ist die Karte offiziell für ganz Deutschland verfügbar.

BeiAbout müsste noch der neueste Stand (ganz Deutschland) ergänzt werden.

Ich habe "zu Hause" geschaut, es gefällt mir schon jetzt und ich schätze es steckt eine Menge Arbeit drin. Da muss ich wohl auch einmal etwas Zeit investieren.

Sehr schön, dann muss ich mein Wohngebiet mal auf den neuesten Stand bringen was das Tagging angeht.

Chris

Moin

Hey, nun sind alle meine letzten Changes drinnen. Und ich entdecke noch Optimierungsbedarf.
Ich hab zum einen den Bereich in Graz getaggt, zum anderen werkel ich gerade hier: http://maps.osm2world.org/?h=128&view=W … ers=B0FFFF
Danach gehts dann wieder nach Graz...
Viel Arbeit.

Amiga4000

monotar@

Proposal under 3dr roofs [1] is still valid. Only Osm2Word don't support it. If you have really simple buildings you can try to convert it into "Simple 3d Building" definition [2], which is fully supported by kendzi3d. You can even mix this two specifications. Nerveless in most cases 3dr specification is the only thing that left.

[1] - http://wiki.openstreetmap.org/wiki/Roof_table
[2] - http://wiki.openstreetmap.org/wiki/Simple_3D_Buildings

Sind die HTML Farbnamen case sensitiv?

[1] http://html-color-codes.info/color-names/

Edit: Laut OSM Wiki soll es in lowercase

Werden geneigte Flachdächer (roof:shape=flat, roof:angle=x) im Simple 3D Modell / OSM2World unterstützt?
Wenn ja, wie wird die Dachfirstlinie angegeben?

Verbesserung:
highway=living_street wird wie eine Hauptstraße dargestellt
Wie funktioniert das nun mit den Farben, ich habe building:material=concrete und building:color=#E9E8E7 angegeben, die Farbe hat aber offensichtlich keinen Einfluss?

edit: ich grad gemerkt, dass die runterladbare live-version anscheinend noch nicht auf dem neuesten stand ist?

!i! wrote:

@things-change Ich meine, dass man es manuell taggen muss, ein triggern auf landuse=garages am Gebäude (oder wenn die Gebäude in dem Bereich stehen) gibt es noch nicht

Ich meinte 'building=garage', das wird auf der Karte als Garage dargestellt. Aber es sieht so aus, als ob alle gleich hoch sind, Flachdächer haben und eine sich aus der Breite ergebende Anzahl an Garagentoren haben; daher die Frage ob überhaupt tags an Garagen zur Darstellung verwendet werden.

Ich hattehier einmal eine Tabelle (kendzi : Tordanik) mit Dachformen. Werden jetzt der Text oder die Zahl ausgewertet?

Gibt es ein Plugin für JOSM für OSM2World?
Das 3D-Plugin von kendzi (Farben, Firstlinie) passt doch nicht für OSM2World?

Danke schon mal für die vielen Rückmeldungen und auch an diejenigen, die ihre eigenen 3D-Gegenden posten - da sind auch wieder sehr schöne Beispiele dabei. 🙂

Ich fange direkt mit dem Beantworten der Fragen an, bei einigen muss ich aber erst noch nachschauen.

things-change wrote:

Was wird denn bei Garagen ausgewertet? Wird dort eine einheitliche Größe und Flachdach angenommen, oder werden Tags zu Höhe und Dachform ausgewertet? Und die Anzahl der Garagentore wird einfach über die Breite vermutet?

Dachform wird ausgewertet, falls vorhanden. Höhe theoretisch auch, ich merke aber gerade dass es da in der Praxis noch ein Darstellungsproblem gibt.

Garagentore werden anhand der Breite abgeschätzt. (Wird die Anzahl denn getaggt?) Außerdem haben die Garagen derzeit noch auf allen Seiten Tore... 🤔

geri-oc wrote:

Bei About müsste noch der neueste Stand (ganz Deutschland) ergänzt werden.

Stimmt, ist jetzt aktualisiert.

chris66 wrote:

Werden geneigte Flachdächer (roof:shape=flat, roof:angle=x) im Simple 3D Modell / OSM2World unterstützt?
Wenn ja, wie wird die Dachfirstlinie angegeben?

Wird von Simple 3D Buildings noch nicht unterstützt.

OSM2World verwendet experimentell roof:shape=skillion + roof:slope:direction=*. Kendzi3D hat eine andere Lösung, das haben wir kürzlich schon mal ergebnislos diskutiert.

monotar wrote:

Wie funktioniert das nun mit den Farben, ich habe building:material=concrete und building:color=#E9E8E7 angegeben, die Farbe hat aber offensichtlich keinen Einfluss?

Der Grund, warum du nichts siehst, ist dass Beton im Kartenstil noch nicht als einfärbbar definiert ist. Muss ich mal korrigieren.

Oh, und offiziell heißt das Tag building:colour. Passiert mir auch leicht, dass ich versehentlich "color" schreibe, aber es gibt ja bei OSM eine "British English"-Konvention.

monotar wrote:

Wie funktioniert das nun mit den Farben, ich habe building:material=concrete und building:color=#E9E8E7 angegeben, die Farbe hat aber offensichtlich keinen Einfluss?

Viele Surfaces werden noch nicht unterstützt und viele Surfaces können die Farbe nicht wechseln.
Das zweite Problem triftt auf concrete zu, was besonderst ärgerlich und auffällig ist, da concrete als nichtveränderbares Standartmaterial für Flachdächer verwendet wird.

geri-oc wrote:

Gibt es ein Plugin für JOSM für  OSM2World?

Es gibt das simplebuildings-preset von Kendzi, das die von osm2world unterstützten Formen unterstützt.

geri-oc wrote:

Ich hatte hier einmal eine Tabelle (kendzi : Tordanik) mit Dachformen. Werden jetzt der Text oder die Zahl ausgewertet?

Der Text nach http://wiki.openstreetmap.org/wiki/Simp … dings#Roof

things-change wrote:

Ich meinte 'building=garage', das wird auf der Karte als Garage dargestellt. Aber es sieht so aus, als ob alle gleich hoch sind, Flachdächer haben und eine sich aus der Breite ergebende Anzahl an Garagentoren haben; daher die Frage ob überhaupt tags an Garagen zur Darstellung verwendet werden.

Die verwendeten Werte sind Standartwerte, durch abweichende Werte für Höhe und Dachform werden diese überschrieben. Die Anzahl der Garagentore und die Seiten auf denen sie erscheinen lassen sich durch tags nicht beeinflussen.

!i! wrote:

Kriegt ihr die Hardware irgendwie gesponsort, oder sollten wir euch da mal finanziell unterstützen?

Die Hardware wurde bis auf die verbauten Festplatten komplett gesponsort (Danke an JJ 😉). Finanziell haben wir kein Problem, eher zu wenig Zeit fleissig weiter zu arbeiten da es trotz der ganzen schönen Neuigkeiten immer noch viel zu tun gäbe 🙂

efred wrote:

wäre super, wenn man in dieser Map auch noch die Schweiz und Österreich sehen könnte.

Für die komplette Schweiz oder Österreich reicht derzeit wohl der Festplattenspeicher nicht ganz, aber

efred wrote:

... wäre ich schon mit dem Kanton Freiburg zu frieden

den Kanton Freiburg sollten wir wohl hinbekommen. Ich schau mal, dass ich das in unsere Skripten einpflege, dass der komplett mit erfasst wird.

Um mal ein Stimmungsbild zu bekommen:

Wie macht ihr das mit dem Taggen von Gebäudehöhen und Farben?

Die kann ich ja nur schätzen, aber dann hätte man auf jeden Fall eine bessere 3D-Karte, als wenn dort nur diese gleichhohen, gleichfarbigen Gebäude mit roten Flachdächern wären.

Der große Kontrapunkt: Wenn ich am Gebäude eine (geschätzte) Höhe eingebe, kann man sich fast sicher sein, dass jeder von ausgeht, das hat wer eingegeben, der es weiss, und nie wieder angefasst wird. Tagge ich nichts, ist es offensichtlich, dass die Höhe fehlt.

🤔

Hab es so gemacht:

building:levels␣=␣5
height␣=␣17
source:height␣=␣errechnet␣6x2,80m

6 x weil das Dach ja mit berücksichtigt werden muss 😉

Tordanik wrote:

chris66 wrote:

Werden geneigte Flachdächer (roof:shape=flat, roof:angle=x) im Simple 3D Modell / OSM2World unterstützt?
Wenn ja, wie wird die Dachfirstlinie angegeben?

Wird von Simple 3D Buildings noch nicht unterstützt.

OSM2World verwendet experimentell roof:shape=skillion + roof:slope:direction=*. Kendzi3D hat eine andere Lösung, das haben wir kürzlich schon mal ergebnislos diskutiert.

Schade, ich hatte seinerzeit die beiden Knoten des Firstes mit building:roof:ridge = yes markiert.
Inklusive aller Varianten (roof:ridge / building:roof:ridge auf Node oder Kante) immerhin 1300 mal in Verwendung.

Zum Vergleich: roof:slope:direction gibt es 35 mal.

Nahmd,

things-change wrote:

Der große Kontrapunkt: Wenn ich am Gebäude eine (geschätzte) Höhe eingebe, kann man sich fast sicher sein, dass jeder von ausgeht, das hat wer eingegeben, der es weiss, und nie wieder angefasst wird. Tagge ich nichts, ist es offensichtlich, dass die Höhe fehlt.

Wenn sich die Weiterverarbeiter darüber einig würden, wäre ein “~” (=ungefähr)-Prefix schnell eingegeben. Auch nützlich für geschätzte Höhenangaben im Gelände. Sähe sogar gedruckt nicht schlecht aus.

Gruß Wolf

@geri-oc
All 3d programs for openstreetmap data should generate almost the same result. If it isn't true please make issue to programs which don't implements it correctly. If you see any differences please help with solving it. The best place for this is 3d forum:

http://forum.openstreetmap.org/viewforum.php?id=42

things-change wrote:

Wie macht ihr das mit dem Taggen von Gebäudehöhen und Farben?

Die kann ich ja nur schätzen, aber dann hätte man auf jeden Fall eine bessere 3D-Karte, als wenn dort nur diese gleichhohen, gleichfarbigen Gebäude mit roten Flachdächern wären.

Der große Kontrapunkt: Wenn ich am Gebäude eine (geschätzte) Höhe eingebe, kann man sich fast sicher sein, dass jeder von ausgeht, das hat wer eingegeben, der es weiss, und nie wieder angefasst wird. Tagge ich nichts, ist es offensichtlich, dass die Höhe fehlt.

Ich tagge einfach die Stockwerkanzahl, die ist nämlich immer leicht ersichtlich. Die Höhe tagge ich eigentlich nur bei Kirchen oder ähnlichem wo die Höhe bekannt ist (z.B. via Wikipedia). Und wenn ich etwas mit Höhe taggen will wo die Stockwerkzahl unangebracht ist, verwende ich est_height und schätze die Höhe anhand von Nachbargebäuden oder ähnlichem.

Das passt dann auch zu OSM2World: Es sucht erst nach dem height-tag, dann nach est-height. Ist beides nicht vorhanden wird die Stockwerkzahl als Abschätzung verwendet.

Bzgl. Farben habe ich auch noch kein brauchbares System zumal ich mit dem Farbcode nicht so ganz zurecht komme. Die Farbe im gerenderten Zustand sieht dann doch immer wieder etwas anders aus als ich es mir gedacht hatte. Daher verwende ich nur die Grundfarben: green, yellow, red, ...

mit der Farbe der Fassade:
1. Fassade bei hellem Tageslicht fotografieren.
2. Den Ausschnitt wählen in dem nur die Fassade ist - keine Tür, kein Fenster etc. und zuschneiden.
3. Für diesen Ausschnitt den Durchschnitt berechnen.
4. RGB Werte dieses Abschnitts als Farbe eintragen.

Falls die Beschreibung zu kryptisch ist, bitte Bescheid sagen. Ich werde mich dann um Beispiele kümmern.

Grüße,
Marek

Hi,

bevor ich jetzt raus gehe und anfange komplexe Dächer (https://wiki.openstreetmap.org/wiki/Roof_table) zu taggen und vermessen und Fassaden fotografiere oder sonst was - ist ja ein verdammt aufwändiges Stück Arbeit - würde mich interessieren, ob die Arbeit nicht in 2 Jahren umsonst war, weil ein neues 3D-Schema kommt oder so. Ich meine, was ist jetzt wirklich nutzbar und das in absehbarer Zeit auch gültig. Mein (geringer) Überblick sagt mir was von mindestens 2 verschiedenen 3D-Schemata. Woran sollte man sich halten. Wie gesagt, habe keine Lust, jetzt Tage Arbeit zu investieren, um am Ende zu sehen: Uups, schade, das andere Schema wurde allgemein anerkannt und kennt derlei Tags nicht. Vorher tagge ich nämlich lieber weiter Hydranten 😄

Gruß S-Man

@S-Man42:

Ich denke da gibt es zwei Möglichkeiten:

1.) Das Schema das sich zuerst etabliert gewinnt.

2.) Das Schema das unterliegt, kann ziemlich leicht "portiert" werden... (wir sprechen von Dachformen, deren Linien alle eindeutige Namen haben und auch in einem anderen Schema wieder an der selben Stelle auftauchen müssen...)

Somit glaube ich, dass Dinge wie diese sehr leicht getagged werden können ohne Gefahr zu laufen, dass die Taggings verloren gehen...

S-Man42 wrote:

bevor ich jetzt raus gehe und anfange komplexe Dächer (https://wiki.openstreetmap.org/wiki/Roof_table) zu taggen und vermessen und Fassaden fotografiere oder sonst was - ist ja ein verdammt aufwändiges Stück Arbeit - würde mich interessieren, ob die Arbeit nicht in 2 Jahren umsonst war, weil ein neues 3D-Schema kommt oder so. Ich meine, was ist jetzt wirklich nutzbar und das in absehbarer Zeit auch gültig. Mein (geringer) Überblick sagt mir was von mindestens 2 verschiedenen 3D-Schemata. Woran sollte man sich halten. Wie gesagt, habe keine Lust, jetzt Tage Arbeit zu investieren, um am Ende zu sehen: Uups, schade, das andere Schema wurde allgemein anerkannt und kennt derlei Tags nicht. Vorher tagge ich nämlich lieber weiter Hydranten 😄

Hallo S-Man

Das 3dr-Schema nach der von dir erwähnten Wiki-Seite wird sich wahrscheinlich in der jetzigen Form nicht durchsetzen. Dafür ist es viel zu kryptisch für die meisten Mapper. Auf der anderen Seite ist es mit dem prefix "3dr:" klar zu erkennen, so dass es relativ leicht sein wird, das zu einem Nachfolger oder einem anderen 3D-Schema zu ändern (tunnelbauer erwähnte das bereits).

Was mit großer Wahrscheinlichkeit Bestand haben wird, sind die Simple 3D Buildings. Die sind einfach genug, um ohne jedesmal Nachschlagen zu müssen, eingetragen werden zu können. Dafür gibt es dann eben nur eine kleine Auswahl von gängigen Dachformen. Für komplexere Dachformen muss man dann als Ergänzung etwas anderes zur Hilfe nehmen.

Edbert (EvanE)

Hallo S-Man42,
ich verstehe Dich wirklich gut. Als Autor des 3dr-Schema von dem auch die Simple 3D Buildings (Dachformen) abgeleitet wurden, kann ich nur sagen, dass ich selbst momentan kaum in 3D mappe, weil es viel Arbeit ist und ich kann die Ergebnisse nicht sofort sehen, bzw. in 3D modifizieren.
Ich warte noch bis ein Editor entsteht der komfortabler ist. Ich versuchte ja auch eine Testentwicklung in diese Richtung an der TU-Lodz zu Ende zu bringen. Solange die Jungs dort 24 Monate Zeit haben um die Dissertationen abzuschliessen, liegt die Entwicklung brach. Vielleicht wird Tordanik / Kendzi in aller Ruhe Schritt nach Schritt soweit sein bevor sie durch sind.

Peda wrote:

Das passt dann auch zu OSM2World: Es sucht erst nach dem height-tag, dann nach est-height. Ist beides nicht vorhanden wird die Stockwerkzahl als Abschätzung verwendet.

Wenn die Anzahl der Stockwerke berücksichtigt wird, ist das ja ausreichend. Dann brauch ich ja keine Höhen raten.
Bei vielen Häusern (Wohnblöcken) ist der Keller halb über dem Erdboden. Wird das irgendwie berücksichtigt?

Eigentlich sollte es berücksichtigt werden. (Ohne in Wiki geschaut zu haben).
Nur- ein Hinweis an alle: die OSM Community sowie Firmen, die kommerziel Daten erheben: die 3D Darstellung basiert auf der Anzahl der Stockwerke funktioniert zwar und sieht sogar nett aus, hat aber mit der Realität unter Umständen wenig zu tun. Es ist sozusagen das allermideste was man machen kann um überhaupt den Eindruck zu erwecken, dass man 3D Daten hat.
Ich konnte während meiner Arbeit mit dem 3D Modell von Hamburg gesehen, dass das Modell welches auf der Anzahl der Stockwerke basiert, derart Müll ist, dass man es nur für die ganz grobe Visualisierung verwenden kann.
Gründe:
- Sehr verschiedene Höhen der Stockwerke, teliweise Erdgeschoß höher als die anderen Stockwerke
- Halbe Stockwerke (Suterrain) sowie Dachböden die zwar kein Stockwerk sind aber trotzdem zu der Fassadenhöhe beitragen.
- Gebäude am Hang: Auf der einer Seite ein Stockwerk mehr oder weniger. Die "Höhe" hängt davon ab, von wo man die Anzahl der Stockwerke zählt.
- Gebäude mit einem künstlichen Sockel

Oft haben Kirchen, Industriehallen ein bzw. 2 Stockwerke. Dort weichen beim Rendering die Höhen am meisten ab.

Mein Rat an verrückte die 3D mögen: Billigstes Entfernungsmessgerät (Laser bzw. Ultraschall). Ich habe 1998 mit einer Gruppe von Teenies aus Krzywin ( http://osm.org/go/0Mv_PBZL , ca. 1800 Einwohner, 90% der Stadt in SOM nicht vorhanden 🤔 ) Gebäude in dem ganzen Städtchen innerhalb von 4 Tagen vermessen - jeweils First und Traufe. Anschliessend bauten wir ein 3D Modell der Stadt in einem CAD Programm auf. Ich habe wirklich Lust dies irgendwo in Deutschland zu wiederholen. Es wäre eine schöne Mapping Party...

Wo kommt dieses Dreieck mit der Spitze nach Norden her? Etwas nordöstlich davon nochmal in einer Ausführung kleiner? Ich finde da nichts in den Daten:(
http://maps.osm2world.org/?zoom=18&lat= … ers=B0TTFF

Geändert wurde da kürzlich nichts, ausser Häuser....soweit ich weiß.

SunCobalt wrote:

Wo kommt dieses Dreieck mit der Spitze nach Norden her? Etwas nordöstlich davon nochmal in einer Ausführung kleiner? Ich finde da nichts in den Daten:(
http://maps.osm2world.org/?zoom=18&lat= … ers=B0TTFF

Geändert wurde da kürzlich nichts, ausser Häuser....soweit ich weiß.

Das ist vermutlich eine Kreuzung/Einmündung. Manchmal bekommt osm2world diese nicht richtig hin und dann gibt es solche Dreiecke z.B. hier.

Edbert (EvanE)

Moin,
welches Tag ist für die Generierung der Fenster zuständig?
Chris

Die building:levels=n Anzahl. Ich glaube wie viele das jeweils an der Wand sind, kann man derzeit (noch) nicht regeln.
Bitte bedenken, dass man mit parametrisierbaren 3D Modellen nicht 100%ig (mit realistischem Aufwand) alles an einem Gebäude nachbilden kann. Hebt am besten die Fotos auf, dann kann man die später für "richtige" indivituelle 3D Modelle noch mal nutzen.

chris66 wrote:

welches Tag ist für die Generierung der Fenster zuständig?

building:levels=X

chris66 wrote:

welches Tag ist für die Generierung der Fenster zuständig?

Hallo Chris

Sehr wahrscheinlich building:levels.
Dann weiß osm2world wieviele Fenster es übereinander zeichnen kann/soll. Beispiel: http://maps.osm2world.org/?h=128&view=N … ers=B0TTFF

Da schließt sich gleich eine Frage an: Wertet osm2world building:part=yes aus, oder hat sich das bei dem Gebäude nur unglücklich überschnitten.
- Änderung der Daten Sonntag, 03. Februar 2013, 01:02 Uhr (MEZ/UTC?)
- Neu gerendert 2013-02-03 21:46:56 (MEZ/UTC?)
Oder habe ich noch etwas übersehen?

Edbert (EvanE)

Schöne neue 3D-Welt in Düsseldorf 🙂

Moin

osm2world wertet das building_part=yes aus, klar. Sonst wären die Abschnitte der Häuser nicht unterschiedlich gefärbt - z.b. in Graz.
ABER die Buildings sollten dann in einer Relation type=building sein.

Und ich hab ne Frage: Häuser in L-Form, wo der Dachfirst in L-Form ist, hab ich eigentlich als 2 Rechtecke getaggt mit building:parts=yes und einmal roof:orientation=along und am kurzen =across. Oder beim Kreuz etwa so: http://www.openstreetmap.org/browse/relation/2734736
Nun kam mir die Idee: man sollte die building:parts doch am besten an der Schnittkante der Dächer entlangführen, damit keine hässlichen Lücken entsthen.
Somit sieht das dann so aus:
http://www.openstreetmap.org/browse/relation/2740729

Gibt die letztere Variante Probleme? IMHO ist sie besser.

Amiga4000

Hallo,

osm2world-windows.bat -i test.osm -o test.png

liefert mir hunderte Java Fehlermeldungen (hauptsächlich NPEs). Welche Parameter sind denn mandatory?
v0.2.0
Chris

EvanE wrote:

Da schließt sich gleich eine Frage an: Wertet osm2world building:part=yes aus, oder hat sich das bei dem Gebäude nur unglücklich überschnitten.
- Änderung der Daten Sonntag, 03. Februar 2013, 01:02 Uhr (MEZ/UTC?)
- Neu gerendert 2013-02-03 21:46:56 (MEZ/UTC?)
Oder habe ich noch etwas übersehen?

Das mit der Datenänderung ist technisch etwas doof. Das Datum der Änderung (das in der About-Seite) ist das Datum vom letzten Download von Frederiks Dumps. Die Daten sind zu diesem Zeitpunkt normal schon ca. 1 Tag alt. Das neu rendern bezieht sich dann immer auf die heruntergeladenen Daten. Bis deine Änderungen vom Sonntag drin sind kann daher derzeit bis zu einer Woche vergehen.

Amiga4000 wrote:

Gibt die letztere Variante Probleme? IMHO ist sie besser.

Ich bin mir bei beiden Varianten nicht so wirklich sicher, da das ja doch etwas "Tagging für den Renderer" ist. Ich nehme building:parts eher bei bauartlicher Trennung, unterschiedlichen Höhen,.. her. Was aber immer klappt und von OSM2World auch so unterstützt wird ist das Proposal von Aschilli mit Roof Lines.

Edit: Wie auf dem 2. 3D Workshop in Garching vereinbart unterstützt OSM2World übrigens eine leicht modifizierte Version von Aschillis Vorschlag: Das 'building:'-Präfix wird weggelassen.

chris66 wrote:

osm2world-windows.bat -i test.osm -o test.png

liefert mir hunderte Java Fehlermeldungen (hauptsächlich NPEs). Welche Parameter sind denn mandatory?
v0.2.0

Bei PNG-Output brauchst du zusätzlich noch Kameraparameter, die einfachste Form ist tilebasiert (--oview.tiles <zoom>,<tileX>,<tileY>). Genaue Dokumentation im Wiki.

Mit deinem Aufruf wirst du außerdem keine Texturen haben - falls dich das stört, kannst du dir die Beispieltexturen herunterladen und über --config einbinden. Für einen ersten Test ist das aber nicht nötig.

Zu den Fehlermeldungen: Bestimmte Exceptions entstehen durch Mappingfehler, Rechenungenauigkeiten oder andere Probleme und werden dann ignoriert und nur auf der Konsole ausgegeben. Dann steht normal was von "Ignored exception" davor. Die eigentliche Konversion läuft aber trotzdem weiter, nur das eine betroffene Objekt wird ggf. nicht (vollständig) dargestellt. Also solange es kein sichtbares Problem mit der Ausgabe gibt, sind die meisten Exceptions nicht weiter schlimm.

Amiga4000 wrote:

osm2world wertet das building_part=yes aus, klar. Sonst wären die Abschnitte der Häuser nicht unterschiedlich gefärbt - z.b. in Graz.
ABER die Buildings sollten dann in einer Relation type=building sein.

Hallo Amiga4000

Wozu soll das gut sein, wenn wie bei meinem Beispiel die komplette Fläche des Gebäudes durch building:part abgedeckt ist?
Wenn nur einzelne Teile mit building:part markiert sind, mag das ja sinnvoll sein, aber bei einer kompletten Abdeckung sollte das meiner Meinung nach nicht notwendig sein.

<Allgemein>
Irgendwie habe ich das Gefühl, dass immer wenn jemand nicht genau weiß, wie etwas gehen soll, eine Relation als Allheilmittel vorgeschlagen wird. Wer soll die alle berücksichtigen/auswerten?
</Allgemein>

An Tordanik und Peda geht die Frage:
Ist eine Gebäude-Relation notwendig oder wird das (zur Zeit) gar nicht ausgewertet?
Falls die notwendig ist, ergänze ich die natürlich noch.

Edbert (EvanE)

Peda wrote:

Das mit der Datenänderung ist technisch etwas doof. Das Datum der Änderung (das in der About-Seite) ist das Datum vom letzten Download von Frederiks Dumps. Die Daten sind zu diesem Zeitpunkt normal schon ca. 1 Tag alt. Das neu rendern bezieht sich dann immer auf die heruntergeladenen Daten. Bis deine Änderungen vom Sonntag drin sind kann daher derzeit bis zu einer Woche vergehen.

Danke für die Aufklärung.
Das Datum in der About-Seite lautet "2013-01-31 03:44:40", ist somit älter als meine Änderungen.

Edbert (EvanE)

Amiga4000 wrote:

Nun kam mir die Idee: man sollte die building:parts doch am besten an der Schnittkante der Dächer entlangführen, damit keine hässlichen Lücken entsthen.
Somit sieht das dann so aus:
http://www.openstreetmap.org/browse/relation/2740729

Gibt die letztere Variante Probleme? IMHO ist sie besser.

Amiga4000

Sieht doch sehr nach Tagging für Renderer aus. Entlang deiner Schnittkante ist in 99% aller Fällen kein echter Teil eines Gebäudes gegeben. Und nur weil die 3D-Renderer das nicht sauber verarbeiten (kann ich nix zu sagen!), da einen Building-Part draus schnippeln, halte ich für absolut falsch.

reneman wrote:

Schöne neue 3D-Welt in Düsseldorf 🙂

Hm, ok...

Fragwürdiger finde ich das hier: http://maps.osm2world.org/?h=128&view=E … ers=B0FFFF
Die Siegessäule in Berlin. Gemappt aus 1000 einzelnen Buildings. Nicht mal Building-Parts, sondern Buildings. Selbst wenn man mit viel Augen-Zu-Drücken sagt, dass der Sockel, von mir aus auch die Säule selbst ein Gebäude darstellt (ist dem so? Meine Definition ist da irgendwie anders...), ist die Statue oben drauf ganz sicher KEIN Gebäude. Und schon gar nicht mehrere... Tagging für den Renderer at its best.

Mir ist aufgefallen, dass building=chapel nicht gerendert wird. Wäre gut, wenn auch diese Gebäude angezeigt werden.

Moin

1. Gebäude Relationen werden ausgewertet - ich hatte da mal Sorgen mit fehlenden Teilen (wenn man building:parts hat, sollte eine Relation genutzt werden. Ohne Relation werden gewisse Teile des Gebäudes nicht gerendert)

2. Ein Gebäude hat Parts oder nicht. Wenn es Parts hat, muß der gesamte Gebäudegrundriss mit 2-x building:part=yes überdeckt sein, am Aussenumriss kommt building=yes dran.
Was nun ein Gebäudeteil ist, ist eine Streitfrage. Im wiki steht:

A way with the tag building:part=yes describes a part of a building, where some building attributes are different from the general attributes of the whole building.

Somit wäre das schon bei einer anderen Aussenwandfarbe gegeben, oder bei der Änderung der Dachform/Firstrichtung...
Ja, teilweise Mappen für den Renderer, aber andererseits: das Gebäude ist so, das möchte ich so abbilden - je mehr Details ich taggen kann, umso besser (solange es nicht redundant wird).

Amiga4000

EvanE wrote:

An Tordanik und Peda geht die Frage:
Ist eine Gebäude-Relation notwendig oder wird das (zur Zeit) gar nicht ausgewertet?
Falls die notwendig ist, ergänze ich die natürlich noch.

Es gibt Situationen, in denen man die Gebäude-Relation auf jeden Fall braucht - speziell dann, wenn sich Gebäude vertikal überlagern. Auch beim verwandten Thema Indoor-Mapping kommt sie wohl zum Einsatz.

In anderen, einfacheren Situationen kann ein Auswerter auch ohne Relation herausfinden, was Sache ist. OSM2World geht derzeit diesen Weg.

Ich muss allerdings dazu sagen, dass das bei der Diskussion über Simple 3D manche Entwickler anders gesehen haben. Die Leute von OSM-3D wünschen sich immer eine Relation, weil das die Auswertung einfacher und effizienter macht. Da sie im Gegensatz zu OSM2World bereits einen Service mit weltweiter Abdeckung haben, kann ich mir vorstellen, dass sie deshalb auch mehr auf die Effizienz angewiesen sind.

S-Man42 wrote:

Fragwürdiger finde ich das hier: http://maps.osm2world.org/?h=128&view=E … ers=B0FFFF
Die Siegessäule in Berlin. Gemappt aus 1000 einzelnen Buildings. Nicht mal Building-Parts, sondern Buildings. Selbst wenn man mit viel Augen-Zu-Drücken sagt, dass der Sockel, von mir aus auch die Säule selbst ein Gebäude darstellt (ist dem so? Meine Definition ist da irgendwie anders...), ist die Statue oben drauf ganz sicher KEIN Gebäude. Und schon gar nicht mehrere... Tagging für den Renderer at its best.

Das ist von 2011, damals gab es noch kein Simple 3D mit building:part und die Argumentation "wir stellen jedes Gebäudeteil als einzelnen building-Way dar, genauso wie wir ja jedes Stück einer Straße als separaten highway-Way eintragen und nicht als highway:part" war völlig berechtigt. Also bitte nicht zu sehr auf den Pionieren rumhacken. 😉

Nach jetzigem Stand sollte man das natürlich als ersten Schritt auf building:part umbauen und ein paar Material-Definitionen ergänzen. Und dann ist halt die Frage, ob man extra so etwas wie "monument parts" haben will, damit es besser passt...

efred wrote:

Mir ist aufgefallen, dass building=chapel nicht gerendert wird. Wäre gut, wenn auch diese Gebäude angezeigt werden.

Gerendert wird building=* für alle Werte außer "no". Manche Werte bekommen eine Sonderbehandlung, andere - darunter derzeit auch chapel - nicht. Aber auftauchen sollten die Gebäude eigentlich. Wenn nicht, liegt es an etwas anderem.

Tordanik wrote:

Das ist von 2011, damals gab es noch kein Simple 3D mit building:part und die Argumentation "wir stellen jedes Gebäudeteil als einzelnen building-Way dar, genauso wie wir ja jedes Stück einer Straße als separaten highway-Way eintragen und nicht als highway:part" war völlig berechtigt. Also bitte nicht zu sehr auf den Pionieren rumhacken. 😉

OK 🙂

Nun ja, ich würde es ja in Building:Parts umtaggen, mein Problem ist allerdings, dass es meines Erachtens nach nicht mal ein Gebäude ist, oder? Ist ja eigentlich ein Monument mit ner Metall-Else oben druff 🙂 Wie macht mans am Besten?

Sieht ja schon wirklich gut aus (wenn die Mapper sich Mühe geben). Wie sieht's denn mit den einfachen landuse grass, scrub, farmland aus? Gerade grass würde eine Stadt nochmal deutlich schöner machen - zumal surface=* ja anscheinend teilweise schon ausgewertet wird.

Und noch ein Bugreport hinterher: Wenn die Blickrichtung etwas anderes als nach Norden ist, funktioniert das Umschalten zu Mapnik nicht.

Tordanik wrote:

Gerendert wird building=* für alle Werte außer "no". Manche Werte bekommen eine Sonderbehandlung, andere - darunter derzeit auch chapel - nicht. Aber auftauchen sollten die Gebäude eigentlich. Wenn nicht, liegt es an etwas anderem.

Seltsam... könntest Du mal das Objekt http://www.openstreetmap.org/browse/way/97246569 anschauen? Ich habe zwar vorhin das Gebäude auf building=yes umgetaggt, nachdem ich gesehen habe dass building=chapel nicht gerendert wurde. Aber vielleicht siehst Du auch sonst noch etwas, was ich falsch gemacht hatte.
Oder liegt es vielleicht daran, dass bis vorhin noch height=5 drin war, statt height=5 m (was ich unterdessen auch schon geändert habe)?

Tordanik wrote:

Mit deinem Aufruf wirst du außerdem keine Texturen haben - falls dich das stört, kannst du dir die Beispieltexturen herunterladen und über --config einbinden. Für einen ersten Test ist das aber nicht nötig.

Erstmal möchte ich den Look von der osm2world/maps Webseite haben, damit ich meine Gebäude öfter als einmal pro
Woche kontrollieren kann. Steht der dazu nötige Aufruf im Wiki?
Texturen werden über building:material getriggert ?
Chris

Amiga4000 wrote:

1. Gebäude Relationen werden ausgewertet - ich hatte da mal Sorgen mit fehlenden Teilen (wenn man building:parts hat, sollte eine Relation genutzt werden. Ohne Relation werden gewisse Teile des Gebäudes nicht gerendert)
...

Hallo Amiga4000

Alles ganz nett mit der Building-Relation, nur geht die in keiner Weise auf building:part ein.
Insbesondere fehlt die Aussage, welche Rolle ein building:part in dieser Relation haben soll.

Die Aussage "ohne Relation werden gewisse Teile des Gebäudes nicht gerendert)" trifft nur zu, wenn die building:part nicht das ganze Gebäude erfassen (was ich persönlich für falsch halte und daher nicht mache).

In Simple 3D Buildings steht dazu im Abschnitt "Building Parts":
"Note that if a building has at least one area tagged as building:part=yes,
the building outline is no longer considered for volume rendering,
unless it is also tagged as a building part."

Wie auch immer es sein mag, die Frage, ob eine Relation notwendig ist, respektive überhaupt beachtet wird, können uns nur die Entwickler der verschiedenen 3D-Programme sicher beantworten. Das mag dann noch von Programm zu Programm verschieden sein.

Edbert (EvanE)

efred wrote:

Oder liegt es vielleicht daran, dass bis vorhin noch height=5 drin war, statt height=5 m (was ich unterdessen auch schon geändert habe)?

Hm, laut wiki reicht auch height=5 ohne das m. Ich habe immer ohne m gemappt und das wird ausgewertet.
Sonst sind die Tags anscheinend OK.
http://www.openstreetmap.org/user/Amiga4000/diary - da hab ich mal meine gemappten Tags notiert gehabt...

Amiga4000

Falls euch Gebäude auffallen, die man mit dem aktuellen Schema rein gar nicht erfassen kann, würden wir uns sehr über Fotos freuen:
http://wiki.openstreetmap.org/wiki/Talk … imitations
Das hilft dann ungemein bei Diskussionen zu neuen Features eines darauf aufbauenden Schemas für komplexere Gebäude.

EvanE wrote:

Hallo Amiga4000

Alles ganz nett mit der Building-Relation, nur geht die in keiner Weise auf building:part ein.
Insbesondere fehlt die Aussage, welche Rolle ein building:part in dieser Relation haben soll.

Ok, das war ohne Zusammenhang geschrieben, aber in der Relation type=building setze ich nie Rollen.
Einfach nur "neue Relation" mit "type=building" und die Aussenlinie, die building:part und neuerdings die Eingänge als Members ohne Rollen. Fertig.
Und sie werden gerendert.

EvanE wrote:

Die Aussage "ohne Relation werden gewisse Teile des Gebäudes nicht gerendert)" trifft nur zu, wenn die building:part nicht das ganze Gebäude erfassen (was ich persönlich für falsch halte und daher nicht mache).

In Simple 3D Buildings steht dazu im Abschnitt "Building Parts":
"Note that if a building has at least one area tagged as building:part=yes,
the building outline is no longer considered for volume rendering,
unless it is also tagged as a building part."

Wie auch immer es sein mag, die Frage, ob eine Relation notwendig ist, respektive überhaupt beachtet wird, können uns nur die Entwickler der verschiedenen 3D-Programme sicher beantworten. Das mag dann noch von Programm zu Programm verschieden sein.

Edbert (EvanE)

Da steht halt drinne: wenn ein Gebäude auch nur einen Teil des Gebäudes mit building:part=yes hat, werden NUR die building:part Teile gerendert (im 3D Volumen), die Aussenlinie, an der building=yes klebt, wird nur noch für 2D genutzt.
Deswegen sollte das gesamt Gebäude entweder:
1. nur eine building=*
oder
2. 2-x building:part=yes
haben, wobei bei 2. die den gesamten Bereich des Gebäudes füllen sollten.

Die Relation ist halt für die einfacherere Auswertung vorhanden. Und beim Kendzi 3D Plugin wird mit building:parts nur mit Relation gerendert, bei osm2world braucht man die Relation bei ineinandergreifende Gebäude (wie Tordanik schrieb).
Somit setze ich die Relation immer sobald ich building:part=yes habe. (was ja auch bei ineinandergreifende Gebäude nötig ist)

Amiga4000

Amiga4000 wrote:

EvanE wrote:

Alles ganz nett mit der Building-Relation, nur geht die in keiner Weise auf building:part ein.
Insbesondere fehlt die Aussage, welche Rolle ein building:part in dieser Relation haben soll.

Ok, das war ohne Zusammenhang geschrieben, aber in der Relation type=building setze ich nie Rollen.
Einfach nur "neue Relation" mit "type=building" und die Aussenlinie, die building:part und neuerdings die Eingänge als Members ohne Rollen. Fertig.
Und sie werden gerendert.

In Relations/Proposed/Buildings ist für alle Mitglieder eine Rolle vorgesehen. Insbesondere ist für den Gebäudeumfang die Rolle outline vorgesehen. (Wie gesagt, geht das Proposal bisher nicht auf building:part ein.) Von daher finde ich es etwas befremdlich, jetzt dort Mitglieder ohne Rolle zu verwenden.
Mein Vorschlag: Für building:part die Rolle part nehmen.

Die Tatsache, dass ein Gebäude in osm2world gerendert wird, bedeutet ja nicht, dass die Relation richtig resp. sinnvoll angelegt ist. Das heißt erst mal nur, dass osm2world mit der Summe der vorhandenen Informationen, das Gebäude darstellen kann.

Edbert (EvanE)

Ich denke euer Input zum Simple 3D Buildings-Schema ist super, sollte allerdings dann doch eher in einem eigenen Thread im 3D Forum stehen, damit es nicht untergeht. Es ist ja nicht spezifisch für OSM2World und auch alle anderen Coder würden bestimmt gerne auf die Hinweise eingehen 🙂

Moin

Hmm, sieh an, ein Gebäude Relation proposal aus 2008. Da müsste man das mal "offiziell" machen und alle Häuser entsprechend anpassen.
Wieder was gelernt, man lernt nie aus.
Schaden kanns ja ned, oder?

Amiga4000

Amiga4000 wrote:

Deswegen sollte das gesamt Gebäude entweder:
1. nur eine building=*
oder
2. 2-x building:part=yes
haben, wobei bei 2. die den gesamten Bereich des Gebäudes füllen sollten.

Die Relation ist halt für die einfacherere Auswertung vorhanden. Und beim Kendzi 3D Plugin wird mit building:parts nur mit Relation gerendert, bei osm2world braucht man die Relation bei ineinandergreifende Gebäude (wie Tordanik schrieb).
Somit setze ich die Relation immer sobald ich building:part=yes habe

Denkt bitte an den einfachen Mapper, der nur sein building=* einträgt (eintragen möchte). Auch wenn manche Gebäude aus mehreren building=* zusammengesetzt sind. Wenn er dann denkt, building:part ist eine Teilbeschreibung (Haupthaus: building:part=house, Nebengebäude/Stall: building:part=yes), ist dann die Auswertung noch möglich? (sowohl 2D als auch simple3D?)

Das Neue (bessere, Erweiterung) sollte immer auf dem einfachsten (bereits vorhandenen) aufbauen bzw. dies voraussetzen.

Prinzipell würde ich nach dem 2D-mappen ein einfaches 3D-mappen befürworten: Haus (eventuell aus mehreren Teilhäusern), Stockwerke, Dachform (eventuell noch Dach und Fassadenfarbe).

Genauer kann dann noch ein fortgeschrittener erweitern: Höhen, Texturen, ...

Aber kompliziert - mit mehreren buildigng:part ineinander, hight, min:height, ... und in Relationen packen - sollte für Spezialfälle durch Spezialisten erfolgen/ergänzen.

Ok, ich probier mich grad aus. Ich hab hier http://www.openstreetmap.org/browse/way/189991255 zwei Haushälften, beide building = yes.
Würde ich also building:part = yes draus machen und ringsum (auf den Außenkanten) einen neuen Way mit building = yes machen, und gebe dem dann building:levels und roof:shape? Richtig?

Klingt vernünftig 🙂 Die Building:parts verändern überschreiben immer die Werte desjeningen Teils, die sie abdecken. Der Rest wird einfach vom Gebäudeumriss übernommen. Mit ein wenig Übung ist das gar nicht schwer, ich gebe aber zu an unserer Doku müssen wir noch feilen 🤔

Moin

geri-oc: es ist eigentlich ganz einfach, nur hier schwer verständlich geschrieben.
Zum einen: Ein Haus ist ein building. Nebengebäude sind wieder ein eigenes building. Man kann mehrere zusammenhängende Buildings mit einer Site relation zusammenfassen (z.B. Uni, Krankenhaus,...).
Sonderfall: Reihenhäuser, ob das nun x einzelne Buildings sind oder ein einziges, ist oft schwer zu erkennen. Im Zweifel ein einziges, großes.

In 2D reicht es, einfach den Grundriss des Hauses zu zeichnen und building=* dranhängen, hinzu entrance=* und die Adressdaten (an building=* oder an der entrance, ich nehme entrance, da kann man später genauer routen).
Für 3D nimmt man diesen Grundriss und trennt an den kanten, wo sich einzelne Tags unterscheiden, Bereiche ab. Jeder Bereich bekommt ein building:part=yes. Solange bis die gesame 2D Grundrissfläche mit einzelnen building:part bereichen ausgefüllt ist.

Sonderfall: 4 eckiges haus mit einem Fahrstuhlschacht in der Mitte. Da können sich building:part Bereiche überdecken.

Für die Tags gilt: an building=* kann man Tags kleben, die für alle Bereiche des Hauses gleich sind. Ansonsten kommen die Tags an die building:part=yes Polygonzüge.

Jetzt baut man eine Relation und packt den Grundriss, die building:part und die Eingänge des Gebäudes in die Realtion.
Fertig.

Soweit baut das aufeinander auf, angefangen vom 2D-Grundriss, der auch schon Tags für 3D haben kann (z.B. eine Garage oder ein einfaches Haus), ohne building:part oder ohne Relation.

Soweit verständlich?

Problematisch ist daran IMHO nur die Erkennung der Unterschiede (wo man das Gebäude in Teile aufteilt) und das man alle Tags zusammen hat. Dafür ist das 3D Building preset von kendzi in JOSM sehr hilfreich.
Ich gehe immer so vor: Umriss vom Haus zeichnen, building:part alle zeichnen, für jeden Building:part das 3d building preset öffnen, mit daten füllen, eingänge setzen, relation erstellen. Zufahrten/zugänge mappen. Barriers mappen auf Grundstück, weiter zum nächsten...

Amiga4000

!i! wrote:

Klingt vernünftig 🙂 Die Building:parts verändern überschreiben immer die Werte desjeningen Teils, die sie abdecken. Der Rest wird einfach vom Gebäudeumriss übernommen. Mit ein wenig Übung ist das gar nicht schwer, ich gebe aber zu an unserer Doku müssen wir noch feilen 🤔

Das klingt vernünftig und wäre eine mögliche Festlegung, aber es ist nicht der derzeit gültige Konsens.

Ich erinnere mich, dass wir auf dem 3D Workshop #2 darüber gesprochen haben (unter anderem weil OSM2World derzeit toleriert, wenn ein "Rest" vorhanden ist, der nicht von Gebäudeteilen verdeckt wird, und dann wie von dir beschrieben vorgeht). Ergebnis war aber, dass der Gebäudeumriss komplett ignoriert werden kann, sobald ein Gebäudeteil vorhanden ist und das haben wir auch so dokumentiert.

Von daher entspricht dieser Edit von Edbert auch nicht dem, wovon die anderen Entwickler ausgehen.

Gut, laut !i! ist mein Ansatz richtig, laut Amiga4000 brauche ich zusätzlich noch eine Relation, wo ich den building-way udn die beiden parts und die beiden Eingänge reinhaue. Was ist denn nun erwünschter. Und wie sieht die Relation aus:
type = building und die Rollen?

wie wird eigentlich ein abgerundes Dach getaggt? unter roof:shape habe ich hierzu leider nichts gefunden.
Wie z.b. in dieser Grafik:

Tordanik wrote:

Das klingt vernünftig und wäre eine mögliche Festlegung, aber es ist nicht der derzeit gültige Konsens.

Ich erinnere mich, dass wir auf dem 3D Workshop #2 darüber gesprochen haben (unter anderem weil OSM2World derzeit toleriert, wenn ein "Rest" vorhanden ist, der nicht von Gebäudeteilen verdeckt wird, und dann wie von dir beschrieben vorgeht). Ergebnis war aber, dass der Gebäudeumriss komplett ignoriert werden kann, sobald ein Gebäudeteil vorhanden ist und das haben wir auch so dokumentiert.

Von daher entspricht dieser Edit von Edbert auch nicht dem, wovon die anderen Entwickler ausgehen.

Es ist das, was ich aus Simple 3D Buildings und der Diskussion zu OSM2WORLD hier entnommen habe.
Wenn andere 3D-Software andere/weitere Anforderungen haben, dann ergänze ich das gerne. Ich muss das halt nur wissen.

Mir war erst mal wichtig, diese Informationen überhaupt zu erfassen.

Neben der Seite Simple 3D Buildings habe ich diese Verwendung der Building-Relation auch auf der Seite Relations/Proposed/Buildings im Abschnitt “Other Usage" eingetragen. Dort habe ich auch noch roof:ridge und roof:edge aus User:Aschilli/ProposedRoofLines eingetragen. In letzterem steht lapidar der Satz "Roof lines are traced as ways and nodes and connected to the building via relations.". Das habe ich auf diese Weise auch genauer festgelegt.

Wie immer bin ich für Hinweise auf Fehl-Interpretationen oder andere Verwendungen dankbar und werde das soweit sinnvoll einarbeiten.

Persönlich:
Natürlich bin ich über die Kaperung einer bestehenden Relation durch die 3D-Gemeinde nicht besonders glücklich. Allerdings sind die Verwendungen (bisher) disjunkt, so dass kein wirklicher Schaden entstanden ist.

Edit:
Danke für den Hinweis, Ich werde das gerne anpassen, sobald wir herausgefunden haben, was genauer zu sagen wäre.

Edbert (EvanE)

efred wrote:

wie wird eigentlich ein abgerundes Dach getaggt? unter roof:shape habe ich hierzu leider nichts gefunden

Das ist ja noch harmlos - bei uns gibt es sowas:

War drin gewesen - einfach phantastisch und dennoch bewohnbar. Architekt wohnt selber drin.
http://www.hs-rm.de/fab/ueber-uns/perso … index.html
http://www.openstreetmap.org/browse/way/92810100

wambacher wrote:

Das ist ja noch harmlos - bei uns gibt es sowas:

ufff... das zu taggen, könnte schon recht schwierig sein (ja wobei, mehrere building:part=yes; roof:shape=Richtiges_Tag_für_Abgerundetes_Dach).
Aber ein "normales" abgerundetes Dach, sollte zum taggen machbar sein - vorallem kommt sowas noch recht häufig vor (ich weiss gerade von Turnhallen, Einstell- und Vorführhallen, ein Schwimmbad). Gibt es da etwas? über taginfo bin ich auf roof:shape=round gestossen, was ich aber nicht so optimal finde - ausserdem wird es nur 11x eingesetzt.
(ob die Statik bei solchen Dächern optimal ist oder nicht, ist ein anderes Thema. Mir gehts nur drum, dass solche Dächer existieren und wenn ich nun schon anfange mit 3D-tagging, würde ich solche Dächer dann auch gleich demensprechend taggen)

wambacher wrote:

efred wrote:

wie wird eigentlich ein abgerundes Dach getaggt? unter roof:shape habe ich hierzu leider nichts gefunden

Das ist ja noch harmlos - bei uns gibt es sowas:
http://www.hs-rm.de/uploads/pics/WBS-Su … ng-550.JPG
War drin gewesen - einfach phantastisch und dennoch bewohnbar. Architekt wohnt selber drin.
http://www.hs-rm.de/fab/ueber-uns/perso … index.html ...

Die Idee "Musikalischer Klang und architektonische Gestalt sollten sich in der Form ihres Hauses verbinden." laut obigen Artikel erklärt die abgerundeten Formen dieses Hauses. Meiner Meinung nach ist das sogar sehr gut umgesetzt.

Edbert (EvanE)

Beispiel: Kirche:

Hab ich derzeit mit 2 Ways getaggt:
A : building=yes (Gesamtgebäude)
B : building:part=yes (Turm)

Wenn ich's richtig verstehe fehlt also noch die Relation und A muss gleichzeitig auch ein building:part sein?

marek kleciak wrote:

Mein Rat an verrückte die 3D mögen: Billigstes Entfernungsmessgerät (Laser bzw. Ultraschall).

Haste 'ne Empfehlung? Bosch PLR 25 ok?

moin

chris66: wenn beides ein Gebäude ist, fehlt der building:part von A OHNE B (mal C genannt) und dann die Relation mit A,B und C.
So wie hier: http://84.115.129.21/gallery3/var/albums/OSM/ABC.png

Da sieht man, das B und C zusammen A ergeben. Getaggt werden B und C unterschiedlich, gemeinsame Tags (z.B. material=stone) kann an A dran.

• edit*
  

Nur bei dem hier (ABCD):
http://84.115.129.21/gallery3/index.php/OSM/ABCD

tagge ich das so, das C und D sich durchdringen (D ist z.B. ein Turm, der höher als C ist).
Z.B. tagge ich C mit height=10, und dann bei D height=20
Man kann bei D min_height= setzen, welches die height von C ist (sozusagen auf C einen Teil draufsetzen).
Z.B.: C height=10 ; bei D dann: min_height=10 height=20. So das beim rendern erst C gerendert wird und dadrauf dann D extra gerendert wird, das macht aber bei schrägen Dächern Probleme.
Eigentlich müsste man aus C den Teil von D ausschneiden, aber das ist zu kompliziert... *edit*

Amiga4000

Wenn ich das gewünschte Taggingschema richtig verstanden habe, sind da 2 Dinge die ich nicht verstehe, bzw. wo ich das Tagung nicht intuitiv und unnötig kompliziert finde:

1. Warum muss jeder Teil mit building:part getagt werden. Angenommen jemand tagt eine Kirche und denkt sich, der Turm ist ja höher. Zeichnet das Kästchen rein als building:part, trägt die Höhe ein und denkt nicht an den Rest des Gebäudes. Ergebnis: In 3D wird nur der Turm gezeichnet. Der Rest des buildings nicht.
Ein building ohne parts wird ja schliesslich auch in 3d gezeichnet. Das ist ja ein Widerspruch in sich. Dann dürfte man kein building ohne parts rendern.

2. Warum soll ich das ganze in eine Relation packen, wenn die doch nichts abbildet, bzw. keinen Informationsgehalt hat? Das Building umrahmt schliesslich bereits das gesamte Gebäude, und die parts sich im building enthalten.

things-change wrote:

2. Warum soll ich das ganze in eine Relation packen, wenn die doch nichts abbildet, bzw. keinen Informationsgehalt hat? Das Building umrahmt schliesslich bereits das gesamte Gebäude, und die parts sich im building enthalten.

Dieser Satz aus dem Abschnitt Building parts sollte das erklären:
"Note that if a building has at least one area tagged as building:part=yes,
the building outline is no longer considered for volume rendering,
unless it is also tagged as a building part."

Zu Deutsch:
Wenn es ein Building Part gibt, dann wird das Gesamtgebäude nicht mehr zum 3D-Rendern verwendet, es sei denn, es ist ebenfalls als Building Part erfasst.

Wie das genau zu interpretieren ist, und ob/wann die Relation notwendig ist, konnten wir in diesem Thread bisher nicht genau klären. OSM2WORLD braucht die Building Relation wohl nicht, wenn alle Teile als Building Part erfasst sind. Andere 3D-Renderer könnten ggfs. die Building Relation immer brauchen.

Die Building Relation stellt eine Verbindung zwischen den verschiedenen Building Part und dem Building Outline her. Von daher wäre es falsch zu sagen, dass sie keine Information enthält.

Edbert (EvanE)

chris66 wrote:

marek kleciak wrote:

Mein Rat an verrückte die 3D mögen: Billigstes Entfernungsmessgerät (Laser bzw. Ultraschall).

Haste 'ne Empfehlung? Bosch PLR 25 ok?

Ich wollte es ja eigentlich nicht schreiben, aber wo nun gerade danach gefragt wird.
Bei Aldi-Süd gibt es ab diesen Donnerstag (also morgen 7.2.2013) einen Laser-Entfernungsmesser LRF-600 G für 100 Euro mit sechsfacher Vergößerung des Suchers und angegebenen (bis zu) 600 Meter Messdistanz.

Interessant vielleicht auch diese Vorstellung mit Leser-Kommentaren, um das Gerät wenigstens grob einschätzen zu können.
Eine Suche nach "LRF-600 G" sollte noch weitere Treffer bringen, da das Gerät bereits einmal bei Aldi Süd angeboten wurde.

Edbert (EvanE)

Ha, gerade gefunden:
http://wiki.openstreetmap.org/wiki/3D_building

-)␣Amiga

Moin,
meine Fragen von gestern sind wohl in der Diskussion um building:part untergegangen, aber ich schiebe einfach nochmal eine hinterher:

Kann es sein, dass die Angabe des Standes der Daten nicht stimmt? "About" sagt "Last update contains data up to 2013-02-06 03:57:56.", Gebäude von gestern sind aber nicht enthalten, obwohl der Timestamp der Tiles neu ist.

Bzgl. der building parts eine Frage, weil die Diskussion über die verschiedenen Möglichkeiten wohl nicht dokumentiert ist: Warum wird das eigentliche Building ignoriert, sobald ein building:part vorhanden ist? Für mich klingt das am Ende sehr kompliziert (gerade auch wenn noch eine Relation gefordert wird). Da muss ich things-change zustimmen, das klingt für mich nach einem komplizierten Tagging um das Rendering einfacher zu gestalten.

mueschel wrote:

Kann es sein, dass die Angabe des Standes der Daten nicht stimmt? "About" sagt "Last update contains data up to 2013-02-06 03:57:56.", Gebäude von gestern sind aber nicht enthalten, obwohl der Timestamp der Tiles neu ist.

Glaube ich eigentlich nicht, liegt aber evtl. daran, dass das ganze etwas komplizierter ist: Das Datum in der About-Seite sagt, wann wir den letzten Dump runtergeladen haben. Zu diesem Zeitpunkt sind die darin enthaltenen Daten aber schon ca. 1 Tag alt. Alle Tiles die nach diesem Zeitpunkt gerendert werden, sind von diesem neuen Dump. Den Zeitpunkt der Kachel solltest du dann bei zoom=13-18 anschaun. Bei zoom=12 ist es immer das Datum der aktuellsten zoom=13-Kachel.

Falls du dennoch meinst, dass hier ein Fehler vorliegt, sag mir bitte die Tilenummer, dann überprüfe ich das.

mueschel wrote:

Und noch ein Bugreport hinterher: Wenn die Blickrichtung etwas anderes als nach Norden ist, funktioniert das Umschalten zu Mapnik nicht.

Das ist technisch etwas schwer weil der Mapnik-Layer ja nicht von uns kommt. Wenn wir den jetzt drehen stehen aber alle Beschriftungen,.. auf dem Kopf. Außerdem müssten wir das Drehen selbst auch noch irgendwo programmieren: Entweder unsere Server als Proxy verwenden und dort on-the-fly drehen oder irgendwie in OpenLayers mit JS drehen. Aber wegen den Beschriftungen denk ich nicht dass wir das machen werden oder es überhaupt viel Sinn macht.

Ich versuche mal etwas Klarheit in die Diskussion um building:part zu bringen. Dabei ist es wichtig zu unterscheiden, 1. was "Simple 3D Buildings" spezifiziert, 2. was evtl. eine sinnvolle Konvention wäre und 3. was OSM2World unterstützt.

Die Vorgehensweise nach Simple 3D Buildings:

• building=yes wird für die Gesamtfläche genutzt. Dort stehen auch die Tags fürs Gesamtgebäude.
• die Teile werden jeweils als building:part eingetragen. Dabei muss die Gesamtfläche noch einmal komplett mit building:part-Flächen überdeckt sein, einen "Rest" darf es nicht geben.
• Tags, die nur für ein Gebäudeteil gelten, stehen am Gebäudeteil - ansonsten werden Tags wie Höhe oder Material vom Gesamtgebäude "geerbt".
• eine Relation mit type=building wird angelegt, die die building-Fläche und die building:part-Flächen als Member enthält. Die Rolle für Gebäudeteile ist dabei nicht spezifiziert und auch eigentlich egal, da ein Teil ja bereits durch das building:part-Tag als solches erkennbar ist.

Es scheint in der Diskussion zwei Aspekte dieses Schemas zu geben, die besonders oft als unpraktisch empfunden werden: Die Relationen sowie die Notwendigkeit, die gesamte Fläche noch einmal mit building:part abzudecken.

Die Relationen wurden aus zwei Gründen eingeführt: Weil sie in einigen wenigen Fällen unverzichtbar für eine einfache Auswertung sind (nämlich dann, wenn sich die "Footprints" von Gebäuden in 2D überlappen), und weil sie auch in anderen Fällen die Auswertung effizienter und einfacher machen.
Sehr viele Mapper verwenden die Relation allerdings in der Praxis bei Fällen der zweiten Gruppe nicht. Wer die Relation unpraktisch findet, der sollte sie meiner Meinung nach lieber weglassen als gar keine 3D-Gebäude zu taggen. OSM2World benötigt die Relation nicht.

Dass wir uns auf dem 3D-Workshop entschieden haben, eine komplette Überlappung der Gesamtfläche mit building:part-Flächen zu fordern, hat auch wieder mehrere Gründe. Der wichtigste ist aber, dass wir nichts am Tagging normaler Gebäude, also der building-Flächen, ändern wollten. Die Tags am building=* (also name etc., aber auch Dinge wie height) sollen daher weiterhin fürs Gesamtgebäude gelten.
Das bedeutet, dass z.B. ein Kirchturm mit ins height-Tag am Gesamtgebäude eingerechnet werden müsste, auch wenn der Kirchturm noch einmal einzeln als building:part gemappt ist. Also würde das Gesamtgebäude zwangsläufig alle niedrigeren Teile "verschlucken", wenn es trotz Vorhandensein eines oder mehrerer building:part weiterhin gerendert würde.
OSM2World ist auch hier wieder etwas toleranter: Flächen von Gebäudeteilen werden von der Gesamtfläche subtrahiert und der verbliebene Rest wird mit den Attributen - Höhe, Material etc. - des Gesamtgebäudes gerendert. Das funktioniert allerdings nicht zuverlässig, wird von anderen Renderern definitiv nicht unterstützt und führt bisweilen zu Darstellungsfehlern. Hier bin ich mir daher nicht sicher, ob das wirklich eine gute Idee ist.

Ich hoffe, dass diese Erklärung etwas weiterhilft. 🙂

PS: Zum Datum hat Peda ja schon etwas geschrieben. Ich werde später auch noch mal alle Posts durchgehen, um nach "untergegangenen" Fragen zu suchen.

Peda wrote:

mueschel wrote:

Gebäude von gestern

Das Datum in der About-Seite sagt, wann wir den letzten Dump runtergeladen haben. Zu diesem Zeitpunkt sind die darin enthaltenen Daten aber schon ca. 1 Tag alt.

Dann passt das ja und der dump ist schon etwa 10 Stunden alt gewesen zu diesem Zeitpunkt. "contains data up to" habe ich so verstanden, dass das die tatsächliche Zeit wäre.

Peda wrote:

mueschel wrote:

Und noch ein Bugreport hinterher: Wenn die Blickrichtung etwas anderes als nach Norden ist, funktioniert das Umschalten zu Mapnik nicht.

Das ist technisch etwas schwer weil der Mapnik-Layer ja nicht von uns kommt. Wenn wir den jetzt drehen stehen aber alle Beschriftungen,.. auf dem Kopf. Außerdem müssten wir das Drehen selbst auch noch irgendwo programmieren: Entweder unsere Server als Proxy verwenden und dort on-the-fly drehen oder irgendwie in OpenLayers mit JS drehen. Aber wegen den Beschriftungen denk ich nicht dass wir das machen werden oder es überhaupt viel Sinn macht.

Vielleicht kann man entweder die Funktion deaktivieren oder einfach die nach Norden ausgerichtete Karte zeigen - mittem im Indischen Ozean zu landen macht die Sache für den User etwas kompliziert :-)

Tordanik wrote:

Ich versuche mal etwas Klarheit in die Diskussion um building:part zu bringen. Dabei ist es wichtig zu unterscheiden, 1. was "Simple 3D Buildings" spezifiziert, 2. was evtl. eine sinnvolle Konvention wäre und 3. was OSM2World unterstützt.

Die Vorgehensweise nach Simple 3D Buildings:

• building=yes wird für die Gesamtfläche genutzt. Dort stehen auch die Tags fürs Gesamtgebäude.
• die Teile werden jeweils als building:part eingetragen. Dabei muss die Gesamtfläche noch einmal komplett mit building:part-Flächen überdeckt sein, einen "Rest" darf es nicht geben.
• Tags, die nur für ein Gebäudeteil gelten, stehen am Gebäudeteil - ansonsten werden Tags wie Höhe oder Material vom Gesamtgebäude "geerbt".
• eine Relation mit type=building wird angelegt, die die building-Fläche und die building:part-Flächen als Member enthält. Die Rolle für Gebäudeteile ist dabei nicht spezifiziert und auch eigentlich egal, da ein Teil ja bereits durch das building:part-Tag als solches erkennbar ist.

Die Relation mit type=building ist insoweit ein Problem, als es die schon in einem anderen Zusammenhang gibt. Gemeinsamkeit ist eigentlich nur die Gesamtfläche also das Building-Outline. Von daher schlage ich vor, die Rollen "outline" und "part" zu verwenden, auch wenn dies von Simple 3D Buildings aus nicht erforderlich wären. So kann man die verschiedenen Nutzungsfälle anhand der benutzten Rollen auseinanderhalten oder ggfs. sogar kombinieren.

Tordanik wrote:

Die Relationen wurden aus zwei Gründen eingeführt: Weil sie in einigen wenigen Fällen unverzichtbar für eine einfache Auswertung sind (nämlich dann, wenn sich die "Footprints" von Gebäuden in 2D überlappen), und weil sie auch in anderen Fällen die Auswertung effizienter und einfacher machen.
Sehr viele Mapper verwenden die Relation allerdings in der Praxis bei Fällen der zweiten Gruppe nicht. Wer die Relation unpraktisch findet, der sollte sie meiner Meinung nach lieber weglassen als gar keine 3D-Gebäude zu taggen. OSM2World benötigt die Relation nicht.

Da bin ich mal gespannt, wie mein Beispiel gerendert wird. Da überlappen sich die building:part nämlich in Realität und in meinen Daten. Bis jetzt habe ich noch keine Relation verwendet, was nach deiner Erklärung zu Problemen führen kann. Die Relation werde ich unabhängig vom Ergebnis nach dem nächsten Renderlauf ergänzen.

Tordanik wrote:

Dass wir uns auf dem 3D-Workshop entschieden haben, eine komplette Überlappung der Gesamtfläche mit building:part-Flächen zu fordern, hat auch wieder mehrere Gründe. Der wichtigste ist aber, dass wir nichts am Tagging normaler Gebäude, also der building-Flächen, ändern wollten. ...
Das bedeutet, dass z.B. ein Kirchturm mit ins height-Tag am Gesamtgebäude eingerechnet werden müsste, auch wenn der Kirchturm noch einmal einzeln als building:part gemappt ist. Also würde das Gesamtgebäude zwangsläufig alle niedrigeren Teile "verschlucken", wenn es trotz Vorhandensein eines oder mehrerer building:part weiterhin gerendert würde.
OSM2World ist auch hier wieder etwas toleranter: ... Das funktioniert allerdings nicht zuverlässig, wird von anderen Renderern definitiv nicht unterstützt und führt bisweilen zu Darstellungsfehlern. Hier bin ich mir daher nicht sicher, ob das wirklich eine gute Idee ist.

Ich hoffe, dass diese Erklärung etwas weiterhilft. 🙂

Mir hat das auf jeden Fall geholfen.
Oder kurz ausgedrückt: Vollständige Überdeckung mit Building Parts, damit die 3D-Informationen unabhängig von der Grundfläche sind. (Ausnahme: Gebäude ohne Building Parts)

Edbert (EvanE)

Was mache ich bei einem rechteckigen Gebäude, das in der Mitte einen höheren Teil hat? Bis jetzt habe ich ersteinmal das Gebäude mit der Höhe des niedrigen Teils plus einen "Aufbau" der oben drauf sitzt - das passt auch vom Material und Farbe her.
Dürfte ich jetzt an das Hauptgebäude einfach noch ein building:part dazu setzen? Oder muss ich ein neues Objekt dafür anlegen mit der gesamten Grundfläche? Oder, dritte Möglichkeit, ein multipolygon für den äußeren, niedrigen Gebäudering?
Und die umgekehrte Variante davon ist mir auch noch nicht ganz klar: Ein zweistöckiges Gebäude mit einem kleinen Innenhof, der aber nur ein Stockwerk "tief" ist.
Vielleicht können wir ja ein paar weitere Beispiele mit Tagging im wiki sammeln.

Achja, vielleicht noch eine Idee für die default-Settings: Gebäude scheinen etwa 10 Meter hoch zu sein, building:roof hängt aber irgendwo auf 2m - vielleicht könnte man das etwas höher machen wenn keine Werte angegeben sind? Würde wahrscheinlich besser aussehen.

Moin!

Mueschel: ich hab in so einem Fall einfach 2 building:part gemacht, einmal das building outline und einmal die mitte mit dem höheren Teil. Dazu die Höhen bei beiden Teilen korrekt. Wichtig ist in diesesm Fall die Relation.
Dann wirds korrekt gerendert.
http://maps.osm2world.org/?h=128&view=N … ers=B0TTFF
Dort die Hochhäuser mit dem Kasten für den Lift auf dem Dach habe ich so gemappt.
http://www.openstreetmap.org/browse/relation/2443818

Also: einmal das Outline mappen mit building=*
Dann die building:part IN dem outline mappen, in deinem Fall einmal das gesamt Gebäude, dann extra dazu den höheren Teil.
Und jedem building:part eine entsprechende Höhe geben.

Beim umgekehrten Fall würd ich erstmal tricksen: den innenhof als einen building:part mappen, dann das drumherum in 2 building:part aufteilen. Und dann die Höhen zuweisen.
Etwas komplizierter: http://www.openstreetmap.org/browse/relation/2452410

Amiga

@Amiga4000: Interessant finde ich an deinem Vorschlag, dass du dem way 108215648

building=yes
UND
building:part␣=␣yes

gegeben hast. Wenn das so funktioniert, dann ist es für Kirchen auch leichter. Relation(1xGrundgebäude und 1xTurm [als building:part "oben drauf"]), fertig.

Edit: Das hatte ich aus den bisherigen Erklärungen nicht so heraus gelesen. Da hatte ich es immer so verstanden, dass ein
A: 1xway -> Building=yes
B: 1xway -> building:part = yes (für den Kirch-Turm)
C: 1xway -> building:part = yes (für um den Kirch-Turm herum)
benötigt wird. Und dann noch eine Relation.

Bisher:

Deine Version: A = way/108215648

@Amiga4000: Habe grad gesehn, dass du auf der Doktor-Robert-Graf-Straße 6 ein Gebäude "gebaut" hast das in osm2world eine interessante Dachform hat. Wäre es möglich, das Dach nach dem von User:Aschilli/ProposedRoofLines beschriebenen Prinzip zu mappen und damit der Realität ein Stück näher zu kommen? Dann wären auch nicht mehr zwei zusätzliche Linien (188969510 und 188969511) für je eine Gebäudehälfte erforderlich. Und wenn dies funktionieren würde, kann die Relation dann gelöscht werden?

Moins,

!i! wrote:

Falls euch Gebäude auffallen, die man mit dem aktuellen Schema rein gar nicht erfassen kann, würden wir uns sehr über Fotos freuen:
http://wiki.openstreetmap.org/wiki/Talk … imitations
Das hilft dann ungemein bei Diskussionen zu neuen Features eines darauf aufbauenden Schemas für komplexere Gebäude.

Konstruiertes Beispiel: ein rechteckiges Gebäude mit Innenhof, bei dem allen Dachteile (nur) Richtung Innenhof geneigt sind. Das würde so ziemlich alle meine Frage beantworten.

Gruß Wolf

Hallo Wolf,
3dr:type=2.5
Du kannst dort auch Donut Topologie haben.

Moin

reneman: ja, da kann man was machen, kam nur noch ned dazu. Kannst ja ändern, Luftbilder hat der JOSM.

Und die Geschichte mit der Kirche: ja, das geht auch so. ABER vorsicht! Wenn A ein spitzes Dach hat, du bei B eine min_height angibst, kann unter B ein Loch entstehen!
Und es kann 3D Renderer gebenm die A und B genau auswerten wollen und Überschneidungen absolut nicht mögen.
Ich bleibe da lieber bei dem ABC Ansatz: http://84.115.129.21/gallery3/index.php/OSM/ABCD
(wo wie gesagt, D etwas problematischer ist).

Amiga4000

Wie taggt man eigentlich Gebäude an einem Hang (mit unterschiedlicher Anzahl von Stockwerken)?

Simon

Moins,

marek kleciak wrote:

Hallo Wolf,
3dr:type=2.5
Du kannst dort auch Donut Topologie haben.

• Wo ist der Innenhof?
  
• Wie erreiche ich, dass das Dach nach innen geneigt ist? (im Beipiel nach außen geneigt)
  

Das Haus mit Innenhof kann ich nur mit einer Relation darstellen mit einem outer und einem inner und dem building=yes an der Relation.

• Welche Tags an die Relation? Welche Tags an die Innenlinie? Welche Tags an die Außenline?
  
• Und: wird das gerendert?
  

Gruß Wolf

SimonPoole wrote:

Wie taggt man eigentlich Gebäude an einem Hang (mit unterschiedlicher Anzahl von Stockwerken)?

Zu der Frage fällt mir nur diese Grafik ein:
Und aus dieser Grafik schließe ich: Wenn du die Etagen angibst, dann alle.
Da wo der Hang höher ist, wird das untere EG dann halt nicht mehr sichtbar / nicht mehr dargestellt.

Ob das in der Realität auch bei 3D so funktioniert? Quelle: DE:OSM-4D

Nahmd,

reneman wrote:

Und aus dieser Grafik schließe ich: Wenn du die Etagen angibst, dann alle.
Da wo der Hang höher ist, wird das untere EG dann halt nicht mehr sichtbar / nicht mehr dargestellt.

Ich würde die Seite mit dem Haupteingang nehmen.

Das ist aber reines Gefühl und ich kann es nicht begründen.

Gruß Wolf

Netzwolf wrote:

reneman wrote:

Und aus dieser Grafik schließe ich: Wenn du die Etagen angibst, dann alle.
Da wo der Hang höher ist, wird das untere EG dann halt nicht mehr sichtbar / nicht mehr dargestellt.

Ich würde die Seite mit dem Haupteingang nehmen.

Ich würde die Stelle nehmen, wo das Gelände am niedrigsten ist - wie in der Grafik dargestellt, die reneman verlinkt hat.

Und ich kann es sogar begründen: Ist so mit den anderen 3D-Entwicklern vereinbart. 😉

Ich dachte eher an sowas

So sehe ich das:

Aber wie mappe ich den Schornstein? 😉

@SimonPoole... Vielleicht im Stil vom Silverline Tower? OSM 3D Gute Beispiele

efred wrote:

Vielleicht im Stil vom Silverline Tower?

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:

reneman wrote:

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.

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.

efred wrote:

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?

reneman wrote:

efred wrote:

Vielleicht im Stil vom Silverline Tower?

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

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 … ers=B0TTFF
Flachdachfarben gehen zumindest im Web: http://maps.osm2world.org/?h=128&view=N … ers=B0TTFF
Auch half-hipped wird ausgewertet: http://maps.osm2world.org/?h=128&view=N … ers=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. 🙂

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

Danke für deine Antwort, aber:

things-change wrote:

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.

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

S-Man42 wrote:

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

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 😄
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...' 😉

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

Amiga4000 wrote:

Das mit dem verdrehtem Dach ist nen Thema...

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

S-Man42 wrote:

things-change wrote:

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.

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

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.

things-change wrote:

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

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

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

efred wrote:

wie wird eigentlich ein abgerundes Dach getaggt? unter roof:shape habe ich hierzu leider nichts gefunden.
Wie z.b. in dieser Grafik:

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

efred wrote:

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

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 🙂

chris66 wrote:

Farbe bei Flachdächern klappt nicht?

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

roof:shape=half-hipped wird noch nicht unterstützt?

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

-i bei GUI wird anscheinend nicht ausgewertet, könntest Du alternativ eine recent-File-List ins Menü bauen?

Ja, lässt sich wohl machen.

Bei Gebäuden mit fehlender Ecke ist das Dach verdreht.

Leider ein bekanntes Problem.

reneman wrote:

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

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

und roof:shape=round ist korrekt? naja, ich würde das jetzt eher als kreisförmiges Dach (auf evtl. rundem Gebäude) betrachten, aber nicht als abgerundetes Dach wie in obigen Bildern... naja, dann halt...

und in meinem Beispiel height=10 am Gebäude (also Gesamthöhe in der Mitte, also inkl. Dach) ist auch korrekt?

efred wrote:

und roof:shape=round ist korrekt?

lt. http://wiki.openstreetmap.org/wiki/Roof … ranslation ist roof:shape=round korrekt.

efred wrote:

und in meinem Beispiel height=10 am Gebäude (also Gesamthöhe in der Mitte, also inkl. Dach) ist auch korrekt?

ja

reneman wrote:

efred wrote:

und roof:shape=round ist korrekt?

lt. http://wiki.openstreetmap.org/wiki/Roof … ranslation ist roof:shape=round korrekt.

ah super... danke vielmals. Anscheinend habe ich diese wiki-site noch gar nie gesehen. So eine Vorlage wie diese http://wiki.openstreetmap.org/w/images/ … formen.pdf ist doch wieder sehr hilfreich.

reneman wrote:

efred wrote:

und in meinem Beispiel height=10 am Gebäude (also Gesamthöhe in der Mitte, also inkl. Dach) ist auch korrekt?

ja

cool... danke.

@things-change, Tordanik: Hm... Ok. N bissel klarer ist das. Und dann gehört noch ne Relation drumrum?

@things-change: Warum sollten überdachte Verandas oder andere Vordächer (http://binged.it/YeUpSx oderhttp://binged.it/YeUxBp oder http://binged.it/14XopJ1) nicht zum Building gehören? Abgesehen davon: Ja, stückeln muss ich in jedem Fall, wenn es seltsam-zusammengesetzte Dachformen gibt. Hab hier innem Einfamilienviertel ein Dach, das ich nicht ohne Stückelung (und mit Standardformen - also nicht mit OSM-4D-Zeug) ordentilich machen könnte... Gibt leider noch kein Luftbild von. In etwa so https://commons.wikimedia.org/wiki/File … ffurt3.JPG Nur eben mit quadratischem Grundriss.

@S-Man42: du brauchst doch das Haus nicht zerhacken. Nach dem hier genannten Prinzip zeichnest du zusätzliche Linien ein und hängst an jede linie die eigenschaft roof:ridge = yes oder roof:edge = yes. fertig

vgl. in der Grafik der kleine Anbau mitterechts

reneman wrote:

zeichnest du zusätzliche Linien ein und hängst an jede linie die eigenschaft roof:ridge = yes oder roof:edge = yes.

Wird das von osm2world unterstützt? Ich suche ja noch die "richtige" Taggingvariante für meine geneigten Flachdächer.
obere Kante mit roof:ridge=yes markieren?

Edit: Geht.

vgl. hier: http://osm2world.org/docs/taglist.txt
Da sind die Attribute aufgeführt, daher sollten sie auch korrekt interpretiert werden.
Sobald ich meine paar Häuser in OSM2World aktualisiert bekommen habe, weiß ich es definitiv.
Beachte aber diesen Post: http://forum.openstreetmap.org/viewtopi … 08#p311208
Inwieweit dies auch auf building:roof:shape vs. roof:shape gilt, weiß ich auch noch nicht genau...

Ah, ok, danke... Hm, mal schauen. 😄

So, und wie komme ich jetzt an Farben und Höhen, ohne Kripo und Bürgermiliz auf den Plan zu rufen? 😄

S-Man42 wrote:

So, und wie komme ich jetzt an Farben [...]

In manchen Gegenden sind die Bing-Bilder in einer gewissen Schräglage fotografiert. Da kann man die Farbe schon in Bing sehen, je höher das Haus desto einfacher geht es 🙂
Oder du benutzt bei Bing die Schrägansicht http://binged.it/14XwoG5, inwieweit die dafür heran gezogen werden darf? k.a.

Ja, das wäre meine Notlösung, aber auch da sind Farben oft verfälscht. Egal... Ich versuch mich einfach mal an ein paar Beispielen.

Andere Frage: Warum sind manche Wälder weniger dicht als andere? Nur ein optisches Schmankerl, oder steckt da ein tieferer Sinn hinter?
http://maps.osm2world.org/?h=128&view=N … ers=B0TTFF

chris66 wrote:

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

Hätte ich auch gedacht. War auch schon länger auf meiner TODO-Liste. Letzte Woche wollte ich das dann angehen und habe dann feststellen müssen, dass das ein nicht-lineares Optimierungsproblem darstellt und nicht so einfach zu lösen ist. Für Spezialfälle klappts, im Allgemeinen aber nicht. Vielleicht übersehe ich auch etwas und jemand hat eine gute Idee wie man das algorithmisch effizient lösen kann 🙂

Wie auch immer: Einer der Gründe warum es im 3D-Forumsteil die Diskussion um die Dachrichtungen gibt.

S-Man42 wrote:

Andere Frage: Warum sind manche Wälder weniger dicht als andere? Nur ein optisches Schmankerl, oder steckt da ein tieferer Sinn hinter?

Das passiert bei Multipolygonen wenn der Outer-way und die Relation als Wald getaggt sind. Dann wird der Wald zweimal eingezeichnet. Meiner Meinung nach ein Tagging-Fehler und in meinen Regionen habe ich das auch immer entsprechend gefixt.

Moin

Kurzer HInweis auf diesen Post: http://forum.openstreetmap.org/viewtopi … 06#p311306

Ich hab ein video von Graz in einem OSM 3D Modell in unserer DAVE gemacht.

Amiga4000

Frage zum Handling in JOSM:

Habe jetzt ein Building in Parts geteilt. Sprich, zum Linien einzeichnen auf der Aussenwand die vorhandenen Punkte genutzt, und dann in der Mitte die Hälfte geschlossen. Mit dem 2. Part genauso. Also die Parts nutzen die vorhandenen Nodes des Buildings. Mein Problem jetzt: Ich kriege den einen Building-Part nicht angeklickt... 🙁 Klicke ich die Aussenwand an, wird das gesamte Building markiert. Klicke ich in der Mitte auf die teilende Linie, wird der linke Part markiert. Aber wie markiere ich den rechten Part? 🤔

Und noch ne Frage zur Dachform: Was mache ich denn, wenn bei gabled die Spitze nicht in der Mitte liegt?

things-change wrote:

Mein Problem jetzt: Ich kriege den einen Building-Part nicht angeklickt... 🙁

Haha, kenn ich, das Problem 🙂 Bis ich die mittlere Maustaste entdeckt habe, damit kann man übereinanderliegende Nodes/Ways durchklicken.

things-change wrote:

Und noch ne Frage zur Dachform: Was mache ich denn, wenn bei gabled die Spitze nicht in der Mitte liegt?

Ziehe eine Linie entlang des Dachfirsten und gib ihr roof:ridge=yes
Zum 2. Problem: Hab ich in Potlatch2 auch häufig, klicke auf ein Objekt das im Weg ist, lösche es, klicke auf dein Wunschobjekt, klicke auf rückgängig.
In aller Regel liegt das zuletzt markierte Objekt oben.

things-change wrote:

Frage zum Handling in JOSM: Mein Problem jetzt: Ich kriege den einen Building-Part nicht angeklickt

man kann auch mit gedrückter [ALT]-Taste die Ways durchklicken.

efred wrote:

things-change wrote:

Frage zum Handling in JOSM: Mein Problem jetzt: Ich kriege den einen Building-Part nicht angeklickt

man kann auch mit gedrückter [ALT]-Taste die Ways durchklicken.

In Potlatch2 funzt das nicht 🙁

reneman wrote:

In Potlatch2 funzt das nicht

things-change fragte aber nach JOSM... und dort funktioniert das.

efred wrote:

reneman wrote:

In Potlatch2 funzt das nicht

things-change fragte aber nach JOSM... und dort funktioniert das.

Jo, ist schon klar. Nur hätte ich mich gefreut, wenn es in P2 mit der Tastenkombination auch funktioniert hätte...

Danke euch!

Alt-Klick hilft, und roof:ridge=yes funktioniert auch.

Jetzt würde ich noch eine Relation erstellen, wenn das unbedingt notwendig ist. Hab ich aber noch nie...
Linke Seite 'alle Relationen anzeigen' aufrufen, habe ich gefunden, und dann '+' für neue Relation. Aber was muss ich dann machen?

reneman wrote:

...
Zum 2. Problem: Hab ich in Potlatch2 auch häufig, klicke auf ein Objekt das im Weg ist, lösche es, klicke auf dein Wunschobjekt, klicke auf rückgängig.
In aller Regel liegt das zuletzt markierte Objekt oben.

Besser: eine gemeinsamen node (Punkt) auswählen -> # wechselt die damit verbunden ways -> beim richtigen way -> weiterarbeiten.

S-Man42 wrote:

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

Die Antwort hab ich grad im Wiki gefunden:

http://wiki.openstreetmap.org/wiki/Key:building:levels wrote:

P + S zählt zu building:levels=2
K zählt als building:levels:underground=1
D zählt als roof:levels=1

Wenn also das Dachgeschoss eine eigene Etage ist, dann ist dies separat im Key roof:levels anzugeben. 🙂

Oh, ist mir neu. -> alles umtaggen 😉

Siehe auch:

http://wiki.openstreetmap.org/wiki/Simple_3D_Buildings

building:levels=* Number of floors of the building above ground(without levels in the roof), to be able to texture the building in a nice way.
If you tag new buildings, try to give a height value. Try to use building:levels=* only in addition to an height tag!

🙂

Hier musste ich beim umgebenden building height=1 setzen, weil ja sonst eine Röhre um den Turm gemalt wird... 🤔

http://www.openstreetmap.org/browse/relation/2747647

Osm2world scheint sich nicht an die Regel im Wiki zu halten: Note that if a building has at least one area tagged as building:part=yes, the building outline is no longer considered for volume rendering, unless it is also tagged as a building part.

Ich habe mir mal erlaubt ein buntes Beispiel in die Seite http://wiki.openstreetmap.org/wiki/DE:S … A4udeteile zu setzen. Ist es verständlich? Habt ihr Vorschläge?

Nahmd,

vielleicht wäre es sinnvoll, eine how to 3D-map a… zu erstellen und prominent zu verlinken. Denn das aktuelle Vorgehen, die nötigen Informationen quer durch Wiki und Foren zu verteilen, macht den Einstieg in 3D unnötig schwierig. Dazu gehört auch, dass die 3D-Experten sich auf ein gemeinsames Format einigen: eine Liste von Möglichkeiten, die zur Zeit jede Implementation schafft. Solange Flächennutzung und Fassadenfarben nicht gerendert werden, braucht man über komplexe Hausformen nicht zu diskutieren. Und solange überstehende Dächer nicht erfasst und gerendert werden (können), bleibt das Ergebnis eine Welt aus Bauklötzen.

3D braucht viele Zulieferer; solange es nur ein paar “Proof-of-concept”-Regionen gibt, ist es nicht wirklich attraktiv.

Ich sehe für mich, dass ich an einem Abend Quadratkilometer weit Flächen und Dörfer erfassen kann (mit entsprechendem Erfolgserlebnis), während bei 3D-Erfassung ich vielleicht eine Straße in einem Dorf schaffe, und das auch nur, wenn ich vorher jedes Haus fotografiert habe: dieser Aufwand will auch ein Ergebnis sehen.

Ein “How-to” braucht und sollte nur sehr wenige Formen beschreiben: genau jene, die häufig vorkommen, mit denen ich aber – Pareto lässt grüßen – die allermeisten Häuser abdecken kann. Dazu vielleicht eine Bildupload-Möglichkeit und ein Tag, das sagt: “3D-Infos sind da, ich weiß aber nicht, wie ich die taggen soll”. Das könnten dann die 3D-Profis übernehmen; denn die Sagrada Famila muss nun wirklich nicht jeder erfassen können.

Gruß Wolf

reneman wrote:

vgl. hier: http://osm2world.org/docs/taglist.txt
Da sind die Attribute aufgeführt, daher sollten sie auch korrekt interpretiert werden.
Sobald ich meine paar Häuser in OSM2World aktualisiert bekommen habe, weiß ich es definitiv.
Beachte aber diesen Post: http://forum.openstreetmap.org/viewtopi … 08#p311208
Inwieweit dies auch auf building:roof:shape vs. roof:shape gilt, weiß ich auch noch nicht genau...

So, das Warten hat ein Ende, hab mir jetzt auch den OSM2World-Viewer runter geladen.
Und siehe da, mein Eckhaus mit roof:ridge und roof:edge funktioniert 🙂

Und auch mit diesem Experiment bin ich sehr zufrieden:

Das ganze vordere Haus besteht aus:

3xway␣building=residential␣inkl.␣eigenen␣Postadressen␣und␣building:levels=2
1xway␣roof:ridge=yes␣von␣Edge␣zu␣Edge␣(4␣Nodes)
2xway␣roof:edge=yes␣je␣am␣Ende␣des␣Hauses␣aus␣je␣3␣Nodes
KEINE␣RELATION;␣OHNE␣building:part=yes

Weiß einer wie ich im Viewer Stockwerke, Farben, Materialien angezeigt bekomme?

Netzwolf wrote:

vielleicht wäre es sinnvoll, eine how to 3D-map a… zu erstellen und prominent zu verlinken. Denn das aktuelle Vorgehen, die nötigen Informationen quer durch Wiki und Foren zu verteilen, macht den Einstieg in 3D unnötig schwierig.

Also für eine Tutorial-Seite wäre ich durchaus zu haben, vielleicht lassen sich da auch konzeptionelle Einführungen wie die beschriftete Beispielkirche von reneman unterbringen? Am liebsten wäre es mir, wenn dieses Vorhaben statt von 3D-Entwicklern von Nutzern angepackt würde, weil ihr wahrscheinlich leichter seht, wo aus der Mapper-Perspektive überhaupt Erklärungsbedarf besteht und wie man es am besten rüberbringt. Dann könnte man auch im Wiki eine klare Aufgabenteilung zwischen der "technischen" Dokumentation, wo nur kurz und eher abstrakt strukturiert die Tagdefinitionen stehen, und der erklärenden Einstiegshilfe einhalten.

Dazu gehört auch, dass die 3D-Experten sich auf ein gemeinsames Format einigen: eine Liste von Möglichkeiten, die zur Zeit jede Implementation schafft.

Ich fürchte, diese Liste endet derzeit bei "Simple 3D Buildings". 🤔 Aber wir diskutieren ja gerade - auch auf Grundlage des bisherigen Feedbacks - weiter und können die Schnittmenge der Implementierungen hoffentlich schnell ausbauen.

Ich habe vor längerm einmal angefangen sowas zu erstellen:
http://wiki.openstreetmap.org/wiki/User:Viw/OSM3D

Bei dem "Kirchenbild" würde ich aber die Gesamthöhe (4) nicht am Gebäudeumriss festmachen (eventuell Höhe des "Kirchenschiff").

roof:levels=* Etagen im Dachgeschoss muss in der "blauen" Version "Kirchenschiff" sein.

Bei building:levels=* habe ich immer nur die Höhe ohne Dach (non roofs) + eventuell roof:levels=* betrachtet. Was ist richtig?

@Tordanik:
Als Idee: Die Angabe der Gebäudeetagen finde ich als erste "Angabe" sehr gut. Könnte dort auch building:levels=3.5 stehen? (Hochparterre - halbe Etage)
so könnte man auch roof:levels=0.5 (flaches Spitzdach) nutzen.

Hat jemand eine Idee wie man das hier genannte Schleppdach hinkriegt?:

http://www.lintz-holzbau.de/tipps_dachformen.php

Gerne auch nur an einer Seite eingeschnitten.
Mit dem was ich bisher versucht habe, bekomme ich nur 'eingefallene' Dächer hin.

3dr:type 2.0 und einfach den Umriß zeichnen.
Sind die Anbauflächen nur auf der einen Seite, hast Du
3dr:type = 3.0
Siehe Bild http://wiki.openstreetmap.org/wiki/File … utline.jpg

aus der WikiSeite: http://wiki.openstreetmap.org/wiki/DE:OSM-4D/Roof_table

Je mehr ihr in Detail geht umso mehr werdet Ihr sehen, dass das simpe 3D Schema nicht ausreicht um die Realität abzubilden. 🤔 .
Es gibt ja schlichtweg zu viele Formen, die nicht durch das Einfache abgedeckt werden.

Ok, aber wer stellt das dar?

Das kendzi3d plugin für josm scheint gar keine Building-Parts zu können, und osm2world scheint das 3dr-Schema nicht zu verwenden, dort entsteht ein Flachdach.

Die wiki ist auch sehr sperrig geschrieben, aber ich denke, ich habs nach der Vorgabe richtig getaggt.

Es geht um folgendes Building:

http://www.openstreetmap.org/browse/way/148091534

Es sind praktisch 2 Dächer dieser Form:

http://wiki.openstreetmap.org/wiki/File … ample2.jpg

(Das Dach bitte einmal gedanklich über X und Y spiegeln, und dann die Häuser in den Lücken ineinanderschieben.)

Erst wenn es gelungen ist, das richtig zu taggen (und sofort irgendwo zu sehen, z.B. kendzi3d, osm2world), dann bin ich bereit, weiter 3D zu tagen. 😎

MOin

things-change: kendzi 3d plugin kann building:part. Aber es braucht unbedingt eine Relation dazu!

Amiga4000

efred wrote:

efred wrote:

wie wird eigentlich ein abgerundes Dach getaggt? unter roof:shape habe ich hierzu leider nichts gefunden.
Wie z.b. in dieser Grafik:
http://ww3.cad.de/foren/ubb/uploads/Schatz/Ansicht.png

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):
http://www.duedingen.ch/cms/upload/bild … cker04.jpg
http://www.regionaleisbahn.ch/Index/Logo%20II.jpg
http://www.regionaleisbahn.ch/Index/PICT9630.JPG

Ich habe mal versucht lokal deine Eisporthalle im osm2world-Viewer sehen zu können.
Mit roof:shape=round habe ich absolut nix rundes entdecken können.
Auch mit

building␣=␣yes
building:roof:shape=3dr
3dr:type=5.0
3dr:height1=5m

wollte es nicht klappen 🙁
Aber mit vielen Hilfslinien (roof:edge=yes + roof:height=x.x) hab ich das hier geschafft:

Download Eishalle.osm (klicke auf den kleinen grün-weißen Download-Button unter der Angabe "Datum" + "Dateigröße" und NICHT auf die Werbung re+li ) Edit: Hab grad gesehn, dass ich offenbar zu viel in der Downloaddatei gelöscht habe, der Gebäudeumriss fehlt 🙁

Amiga4000 wrote:

MOin

things-change: kendzi 3d plugin kann building:part. Aber es braucht unbedingt eine Relation dazu!

Amiga4000

Ok, hab ich bisher nicht hingekriegt.

Könnte mir jemand erklären, was man in diesem josm dialogfenster machen/eintragen muss?

marek kleciak wrote:

mit der Farbe der Fassade:
1. Fassade bei hellem Tageslicht fotografieren.
2. Den Ausschnitt wählen in dem nur die Fassade ist - keine Tür, kein Fenster etc. und zuschneiden.
3. Für diesen Ausschnitt den Durchschnitt berechnen.
4. RGB Werte dieses Abschnitts als Farbe eintragen.

Moin Marek,
so wird's in der Regel zu dunkel:

Man sollte also einen gehörigen Schuss die Helligkeit erhöhen.
Chris

Hallo,

Mit ist auch solch ein Gebäude mit gebogenem Dach bekannt (hier ein weiteres Bild) - aber als umgekehrte Parabel, zusätzlich geht das Glas-Dach seitlich bis auf den Boden und steht am höchsten Punkt etwa 8 m über die Ränder des Gebäudes über. Ein fertiges Modell habe ich im Wiki nicht gefunden und Tonnenförmig wie Typ 5.0 auf dieser Seite ist es auch nicht, weil der Winkel des Daches am Boden nicht 90° nach oben geht, um dann im Querschnitt kreisförmig zur Maximalhöhe des Gebäudes zu verlaufen.

Da bleibt dann wohl nur, dieses wie bei der Eissporthalle aus einzelnen Linien mit angegebener Höhe zu modellieren. Hier beginnt ja das Dach bereits am Boden, da gibt es dann wohl kein building:height=*, -:levels=* oder -:colour=*, sondern alles unter roof:*=*.

Welche Farbe nehmt Ihr denn für Glasfassaden. Von der Seite gesehen ist dieses Gebäude an den drei Abschnitten, wo innen Bäume stehen dunkler als die vier Bereiche wo die Buros bis ans seitlich aufsteigende Dach gehen.

Nur, wie lasse ich das gebogene Dach an den Seiten überstehen - mit vielleicht einem Meter Dicke, oben viel, unten gar nicht. Sollte dieser Überstand unabhängig vom Gebäude modelliert werden? Aber wie stelle ich es an, solch ein schräges Dachstück in unterschiedlichen Neigungen aneinandergelegt mit einer Dicke von einem Meter zu modellieren? - min_height/height geht da wohl nicht - dann würden die Segmente treppenförmig verlaufen.

Fragende Grüße,
Franz

reneman wrote:

http://i49.tinypic.com/u6ck2.png
Download Eishalle.osm (klicke auf den kleinen grün-weißen Download-Button unter der Angabe "Datum" + "Dateigröße" und NICHT auf die Werbung re+li ) Edit: Hab grad gesehn, dass ich offenbar zu viel in der Downloaddatei gelöscht habe, der Gebäudeumriss fehlt 🙁

jo, hab ich mir gerade aus der Schweiz besorgt 😉 (*)

Gibt es eigentlich einen Thread, der sich rein mit technischen Fragen zum Programm beschäftig - also alles ausser Tagging? Ich schlage mich mit der Gui rum, muß bei jeden Aufruf das Datenfile neu angeben (--input=... --gui funzt nicht) und bei "Reload OSM-File" knallt das Teil. Also -für mich- schwer zu bedienen.

Gruss
walter

• ) was ist Werbung? Ich nutze Adblock Plus
  

EvanE wrote:

Amiga4000 wrote:

EvanE wrote:

Alles ganz nett mit der Building-Relation, nur geht die in keiner Weise auf building:part ein.
Insbesondere fehlt die Aussage, welche Rolle ein building:part in dieser Relation haben soll.

Ok, das war ohne Zusammenhang geschrieben, aber in der Relation type=building setze ich nie Rollen.
Einfach nur "neue Relation" mit "type=building" und die Aussenlinie, die building:part und neuerdings die Eingänge als Members ohne Rollen. Fertig.
Und sie werden gerendert.

In Relations/Proposed/Buildings ist für alle Mitglieder eine Rolle vorgesehen. Insbesondere ist für den Gebäudeumfang die Rolle outline vorgesehen. (Wie gesagt, geht das Proposal bisher nicht auf building:part ein.) Von daher finde ich es etwas befremdlich, jetzt dort Mitglieder ohne Rolle zu verwenden.
Mein Vorschlag: Für building:part die Rolle part nehmen.

Jetzt mal Butter bei die Fische: Nicht, dass ichs nicht selber herausfinden möchte, aber da ich a) noch nie eine Relation erstellt habe und b) irgendwie nicht ganz Einigkeit zu bestehen scheint bzw. die Members einer Relation mir nix sagen, kann ich es nicht selber herausfinden.

Bitte einmal kurz erklären.

Ups, halber Nachmittag wech uns schon so viele Fragen.
FV Gordon: Berliner Bogen wird mit 3dr:type=8.2 beschrieben.
Siehe: http://wiki.openstreetmap.org/wiki/DE:O … _table#8.B
Mathematisch gesehen, ist die momentane Beschreibung leider unvollständig, da es sich um einen umgekerten Parabelausschnitt handelt. Zusätzlich benötigt wird ein dritter Höhenpunkt auf der Parabel (der erste ist in der TTerrainebene, der zweite ist der höchste Punkt) damit die Kurve eindeutig beschrieben wird. Gestatte mir, dass ich es Montag ergänze: damit ist die Beschreibung eindeutig.

things-change wrote:

Ok, aber wer stellt das dar?

Das kendzi3d plugin für josm scheint gar keine Building-Parts zu können, und osm2world scheint das 3dr-Schema nicht zu verwenden, dort entsteht ein Flachdach.

Die wiki ist auch sehr sperrig geschrieben, aber ich denke, ich habs nach der Vorgabe richtig getaggt.

- kendzi3d tut das nun. osm2world: ich glaube, wenn Tordanik die hybride Bezeichnung zuläßt, wird es auch gehen. Letzt endlich geht es nur um eine Namensgebung für diesen Typ. "3dr" haben wir mit Kendzi gezielt gewählt, um zu zeigen dass es künstlich ist. Menschennahe Beschreibung ist eleganter, aber es ist schwieriger sich für einige Dachtypen die richtige Bezeichnung auszudenken.
- Du hast absolut Recht: Die Wiki Seite muß unbedingt ergänzt werden. Bitte um Hinweise: was, wo und warum zu wenig und zu kryptisch erscheint. Ich versuch´s zu verbessern.

Chris66 wrote:

Moin Marek, so wird's in der Regel zu dunkel:
13402426lj.jpg
Man sollte also einen gehörigen Schuss die Helligkeit erhöhen

Ich vergass hier den Hinweis zu geben: Ist die Fassade im Schatten, den Trick mit Weißabgleich verwenden:
http://wiki.openstreetmap.org/wiki/Phot … C3.9Fpunkt Danach sieht´s meistens ok aus..

FvGordon, Im Übrigen:
wie ein 3D Modell von Deinem Beispiel - http://www.hamburgwiki.de/wiki/Berliner_Bogen aussieht, findest Du hier:

http://www.spiegel.de/fotostrecke/landm … 901-4.html

Mein Team hat das vor ungefähr 10 Jahren in 3D modelliert.
Interessant: Es ist ein Testmodell gewesen: Einmal wurde dieses Objekt mit einem präzisen 3D-Laserscanner erfasst, einmal basierend auf einem Luftbild plus manuell von der Straße gemachten Fotos. Die Abweichung betrug weniger als 5%, vor allem deswegen weil die Luftbilder damals relativ schlecht waren.

Was ich damit sagen will: OSM hat das Potenziall sehr hübsche und mit ein Wenig Erfahrung relativ genaue 3D Modelle zu schaffen.

reneman wrote:

efred wrote:

efred wrote:

wie wird eigentlich ein abgerundes Dach getaggt? unter roof:shape habe ich hierzu leider nichts gefunden.
Wie z.b. in dieser Grafik:
http://ww3.cad.de/foren/ubb/uploads/Schatz/Ansicht.png

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):
http://www.duedingen.ch/cms/upload/bild … cker04.jpg
http://www.regionaleisbahn.ch/Index/Logo%20II.jpg
http://www.regionaleisbahn.ch/Index/PICT9630.JPG

Ich habe mal versucht lokal deine Eisporthalle im osm2world-Viewer sehen zu können.
Mit roof:shape=round habe ich absolut nix rundes entdecken können.
Auch mit

building␣=␣yes
building:roof:shape=3dr
3dr:type=5.0
3dr:height1=5m

wollte es nicht klappen 🙁
Aber mit vielen Hilfslinien (roof:edge=yes + roof:height=x.x) hab ich das hier geschafft:
http://i49.tinypic.com/u6ck2.png
Download Eishalle.osm (klicke auf den kleinen grün-weißen Download-Button unter der Angabe "Datum" + "Dateigröße" und NICHT auf die Werbung re+li ) Edit: Hab grad gesehn, dass ich offenbar zu viel in der Downloaddatei gelöscht habe, der Gebäudeumriss fehlt 🙁

Auch ohne Gebäudeumriss... cool...danke.

marek kleciak wrote:

...Die Wiki Seite muß unbedingt ergänzt werden. Bitte um Hinweise: was, wo und warum zu wenig und zu kryptisch erscheint. Ich versuch´s zu verbessern...

Oben bei den Dachformen stehen sogenannte 'Parameter' ohne Erläuterung. Wie ich das als Tag ausdrücke muss ich weit unten auf der Seite unter Taggingvorschlag suchen. Die Tags könnten direkt bei den Dachformen stehen. Ich hab die ganze Zeit hin- und hergescrollt.
Dazu kommt, dass ich ewig gebraucht habe die Skizze zu verstehen. (Zu 2.0) Ich dachte zunächst, h1 wäre bis zum Erdboden gezogen und l1 wäre rechts neben dem Haus.
Bei den Skizzen zu den 0.x Typen fehlt übrigens komplett, für was die Parameter stehen, da die Skizzen umbeschriftet sind.

Und dann noch ein kleiner Tippfehler bei Taggingvorschlag: 3dr:lenght1 steht natürlich für L1 und nicht L2.

Und zudem Einwand, das Taggingschema wird sich nicht durchsetzen, da zu kryptisch. Unter Translationtabelle sind doch alle Bezeichnungen für die Typen und Untertypen, müßte man nur mal auf deutsch übersetzen. Achse der Link dort zu (9) führt zu einer praktisch leeren Seite.

Hallo things-change.
Dann habe ich mal zu tun. Danke für die Hinweise, werde ich einbauen.
Was kann man machen, damit die Beschreibung weniger kryptisch ist?

Einige Formen aus dieser Beschreibung werden nach und nach von Kendzi implementiert.
Es ist übrigens der Grund, warum man die Beschreibung:

building = yes
building:roof:shape=3dr
3dr:type=5.0
3dr:height1=5m

nicht sehen konnte.

Wie gesagt, die Tags direkt bei den Dachbeschreibungen würden schon viel bringen.
Vielleicht wäre noch eine Grundsätzliche Einleitung hilfreich. Z.b. mit dem Bild des Dachtypen 2.0, der wohl häufigste Dachtyp bei Einfamilienhäusern.
"Mit dem 3dr-Schema werden Dachformen beschrieben. 3dr:type beschreibt die Dachform, das Tag 3dr:height1 (H1) grundsätzlich die gesamte Dachhöhe (bzw. die erste Höhe bei komplexeren Dächern), 3dr:lenght1 die (erste) Länge. Für komplexere Dächer sind die Tags den Tabellen zu entnehmen."

So in der Art.

Der Hinweis, dass eine Form 2.0 auch bei nicht rechteckigen Dächern (also z.B. mein Schleppdach) verwendet werden kann, sollte auch nicht fehlen.

Und noch was: Bei Paramtern steht z.B.: L1*a. Das liest sich wie eine Rechenformel, und nicht wie eine Fussnote.

EDIT: Oh, und zu welchem absoluten Bezugspunkt sind die Tags gemeint. Also ist L1 immer von unten die erste Länge? Was ist den unten? Analog bei orientation:along/across (welches in dem Artikel glaub ich gar nicht vorkommt, aber auch benötigt wird.) Across zu was?

PS. Und bitte nicht falsch verstehen. Will nicht meckern, nur helfen... 😉

Moin

things-change: relation in josm sind recht einfach.
1. Du markierst einen, mehrere oder alle Elemente, die in die Relation sollen
2. Du klickst rechts (standard josm) auf neue relation erstellen (das Zahnrad Icon mit dem plus)
3. das neue Relationen Fenster geht auf. Oben unter Key trägst du type ein, unter Value building
4. unten sieht man dann links die members der Relation, rechts die ausgewählten Elemente - einfach die Elemente mit dem Button "tabelle pfeil nach links" von dem Selection Bereich in den "Members" Bereich übernehmen. Man kann auch jetzt noch weitere Elemente im JOSM Hauptfenster markieren
5. Sicher stellen, das alle Elemente des Hauses in der Liste der Members notiert sind - gibt lustige Fehler, wenn nicht ;-)
6. jetzt kann man für jedes Member noch eine Rolle anheften - hab ich noch nie gemacht, wird aber gewünscht
7. Mit Klick auf OK haste die Relation für ein Gebäude erstellt

Hinweis: beim Upload meckert josm über unbekannten RelationsTyp Building - einfach ignorieren

Amiga4000

Wie sollte man eigentlich Glasfassaden taggen? Habe hierzu leider nichts gefunden (ich denke, wir sollten wirklich das wiki bezüglich 3D überarbeiten - es ist zu sehr fragmentiert und dadurch zu unübersichtlich)

Schau mal:

http://wiki.openstreetmap.org/wiki/Key: … g:material

building:material=glass

Gefunden ausgehend von:

http://wiki.openstreetmap.org/wiki/Simple_3D_Buildings

Guter Ausgangspunkt für solche Suchen.

geri-oc wrote:

@Tordanik:
Als Idee: Die Angabe der Gebäudeetagen finde ich als erste "Angabe" sehr gut. Könnte dort auch building:levels=3.5 stehen? (Hochparterre - halbe Etage)
so könnte man auch roof:levels=0.5 (flaches Spitzdach) nutzen.

Da ist nicht unbedingt klar, wo sich das halbe Stockwerk befindet. Ich gebe dir allerdings recht, dass man das irgendwie wiedergeben muss.

Weil ich aber nicht genau weiß, was sich z.B. die indoor-Leute dazu ausgedacht haben, würde ich mich da für den Moment mit einem Lösungsvorschlag zurückhalten.

things-change wrote:

Analog bei orientation:along/across (welches in dem Artikel glaub ich gar nicht vorkommt, aber auch benötigt wird.) Across zu was?

Ich antworte mal zu dem einzigen Tag aus deinem Post, das mit OSM2World zu tun hat: along/across funktionieren nur bei annähernd rechteckigen Gebäuden. Bei along verläuft der Giebel parallel zur längeren Seite des Rechtecks, bei across parallel zur kürzeren.

wambacher wrote:

Gibt es eigentlich einen Thread, der sich rein mit technischen Fragen zum Programm beschäftig - also alles ausser Tagging?

Gute Idee. Jetzt schon, einfach hier rein mit den technische Fragen 🙂

@tordanik

Ok, im OSM2World-Wiki steht, unterstützter Tagging-style für Buildings ist Simple3DBuildings, und dort steht 'parts' von roof_table werden verwendet.

Ich hab jetzt 2 Möglichkeiten, das Ergebnis meiner Arbeit zu sehen: direkt in JOSM mit kendzi3D und mittels OSM2World.
Es wäre natürlich wünschenswert, wenn einheitliches Tagging genutzt würde.

roof_table ist ausführlicher und kann Dächer abbilden, die mit den in Simple3DBuildings genannten Keys nicht unbedingt darstellbar sind. Mit 3dr:type=2.0 kann OSM2World anscheinend nichts anfangen. Wie gesagt, eine Vereinheitlichung wäre da schön.

Wunsch für den osm2world viewer: Einladen und Abspielen eines GPX tracks. 😎
So könnte man schön mit einem parallel aufgezeichneten Video vergleichen.

Den Gedanken hatte ich auch, dachte aber eher daran, dass ich z.b. in OSRM eine Route/Straße auswähle und dann kann ich diese im 3D-Viewer abfahren (Wie als würde ich im Auto sitzen, einfach toll).

things-change wrote:

Ok, im OSM2World-Wiki steht, unterstützter Tagging-style für Buildings ist Simple3DBuildings, und dort steht 'parts' von roof_table werden verwendet.

Genau genommen steht dort, dass das eventuell Quelle für zukünftige Erweiterungen sein könnte ("may be introduced later").

roof_table ist ausführlicher und kann Dächer abbilden, die mit den in Simple3DBuildings genannten Keys nicht unbedingt darstellbar sind. Mit 3dr:type=2.0 kann OSM2World anscheinend nichts anfangen. Wie gesagt, eine Vereinheitlichung wäre da schön.

Ja, einheitliches Tagging ist wünschenswert. Und nichts anderes ist Simple 3D Buildings. Dafür haben sich die 3D-Entwickler zusammengesetzt und versucht, das Tagging zu vereinheitlichen. Und genau darauf wurde sich dann eben geeinigt und alle anwesenden Entwickler haben zugesagt, das soweit zu unterstützen.

Aber das bedeutet leider auch, dass es nicht sofort fertige Antworten auf alle Tagging-Fragen geben kann. Die Diskussion mit den anderen Entwicklern und die Implementierung in den verschiedenen Programmen dauert länger als die Vergabe einer neuen Nummer.

Eine Unterstützung des konkreten Tags 3dr:type=2.0 durch OSM2World ist in meinen Augen nicht besonders sinnvoll, weil das nur ein Synonym für roof:shape=gabled ist. Angesichts dessen, dass es nicht für alle Dachformen bereits sprechende Namen gibt, kann ich durchaus nachvollziehen, wenn bei namenlosen Dächern vorerst die Nummer verwendet wird. Aber wo es einen menschenlesbaren Wert gibt, ist dieser in meinen Augen doch klar vorzuziehen?

Tordanik wrote:

Eine Unterstützung des konkreten Tags 3dr:type=2.0 durch OSM2World ist in meinen Augen nicht besonders sinnvoll, weil das nur ein Synonym für roof:shape=gabled ist. Angesichts dessen, dass es nicht für alle Dachformen bereits sprechende Namen gibt, kann ich durchaus nachvollziehen, wenn bei namenlosen Dächern vorerst die Nummer verwendet wird. Aber wo es einen menschenlesbaren Wert gibt, ist dieser in meinen Augen doch klar vorzuziehen?

+1

Es ist aber auch möglich beides anzugeben?

roof:shape=round

und

building:roof:shape=3dr
3dr:type=5.0

chris66 wrote:

Wunsch für den osm2world viewer: Einladen und Abspielen eines GPX tracks. 😎
So könnte man schön mit einem parallel aufgezeichneten Video vergleichen.

Das ist in der Tat eine gute Idee und auch so schon länger geplant und stellt eines meiner TODOs dar. Es kommt sicher früher oder später, kann aber noch etwas dauern 😉

Gibt übrigens auch einen Featurerequest von Matthias hier (#34) mit weiteren Informationen.

efred wrote:

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

Dict.leo.og liefert zum Stichwort Bogendach den Wert: - arched roof [arch.]
Sucht man nach Tonnendach kommt noch - barrel-shaped roof - hinzu.

Daher schlage ich roof:shape=arched für diesen Fall vor, da dies der in der Architektur gebräuchliche Begriff zu sein scheint.

Bei der Gelegenheit möchte ich anregen, einige Ergänzungen in Simple 3D Building vorzunehmen:
- Das Bogendach mit roof:shape=arched bei den Dachformen zu ergänzen
- roof:ridge/:edge=yes aus User:Aschilli/ProposedRoofLines für den Dachfirst resp. -knicke aufzunehmen.
Mit dem zweiten können dann auch viele asymmetrische Dachaufteilungen relativ einfach erfasst werden.

Mir ist klar, dass eine Änderung von Simple 3D Building einer Vereinbarung der verschiedenen 3D Entwickler bedarf. Von daher will ich das nicht einfach dort eintragen.

Edbert (EvanE)

Klar, 3dr:type=2.0 oder auch die anderen ist ja nichts meher als eine Typologie. Hat man einen anderen Namen gefunden, der die Leute anspricht, sollte man´s verwenden.

Auch sollte man aber dringen Namen für andere Geometrietypen finden und nach und nach implementieren.
Die Einigung auf Simple 3D Buildings (S3DB) kam aus Sorge, dass der durchschnittliche Mapper mit dem Mappen überfordert wird, wenn die Auswahl zu groß wird.
Ich arbeite seit mittlerweile 16 Jahren mit 3D Stadtmodellen, mir ist klar, dass man mit 5,6 oder 7 Grudformen etwa 60 bis 80% der Bausubstanz abdecken kann. Umso deutlicher hebne wir uns aber von den Modellen ab, die alles richtig darstellen, weil sie Dächer als Summe einzelner Flächen darstellen.

Und nichts fällt deutlicher auf, ale Ungereimheiten in einem 3D Modell. 😐

Das gute an dem Grundsystem der S3DB ist, dass sich diese Modelle sehr gut generalisieren lassen und weniger fehlerauffälig sind als die Oberflächenmodelle: Es kann dort nämlich gar nicht passieren, dass jemand aus Versehen die 3D Flächen falsch zuschneidet und dazwischen Löcher sind.

Tordanik wrote:

Eine Unterstützung des konkreten Tags 3dr:type=2.0 durch OSM2World ist in meinen Augen nicht besonders sinnvoll, weil das nur ein Synonym für roof:shape=gabled ist ... Aber wo es einen menschenlesbaren Wert gibt, ist dieser in meinen Augen doch klar vorzuziehen?

Da stimme ich dir zu.

Ich habe einfach nur meine ersten Gehversuche im 3D-Tagging gemacht, und versucht, zitiertes 'Schleppdach' zu erzeugen. Mit roof:shape=gabled hat OSM2World merkwürdige Ergebnisse geliefert. Die Draufsicht auf das Dach ist ja ein Rechteck mit ausgeschnittener Ecke, und OSM2World erzeugt dann komischerweise eine geneigte Aussenkante des Dachs. Gerne würde ich wieder zu roof:shape=gabled umtaggen, wenn die daraus resultierende Darstellung richtig ist.
Ich bin auch unsicher, wie das roof:shape=... und das 3dr:type=... in Kombination mit einer Linie roof:ridge=yes funktionieren.

Werde da beim noch ein bisschen rumprobieren.

Btw., das ist praktisch das erste Dach, dass ich darstellen möchte, und das dieses unscheinbare Häuschen solch eine kompliziert darzustellende Dachform hat, hätte ich natürlich nicht gedacht. Ich werde auch nicht mit anderen Häusern weitermachen, bevor ich dieses Dach nicht hinbekommen habe... 😉

EDIT:

Habe jetzt noch etwas rumprobiert. Dächer, die über eine rechteckige Form hinausgehen, stellt OSM2World fehlerhaft dar. Wenn das Dach eine ausgeschnittene Ecke hat, nimmt OSM2World den Mittelpunkt der beiden äusseren Dachlinien und zieht dann darüber den Dachfirst. Der ist dann natürlich nicht rechtwinklig und komischerweise ist die Aussenkante des Daches dann auch nicht parallel zum Erdboden.
Setzt man dann eine Linie mit roof:ridge=yes, bilded OSM2World diese richtig, allerdings ist die 'Dachhaut' dann nicht eine Fläche, sondern 'eingefallen'

things-change wrote:

Habe jetzt noch etwas rumprobiert. Dächer, die über eine rechteckige Form hinausgehen, stellt OSM2World fehlerhaft dar. Wenn das Dach eine ausgeschnittene Ecke hat, nimmt OSM2World den Mittelpunkt der beiden äusseren Dachlinien und zieht dann darüber den Dachfirst. Der ist dann natürlich nicht rechtwinklig und komischerweise ist die Aussenkante des Daches dann auch nicht parallel zum Erdboden.
Setzt man dann eine Linie mit roof:ridge=yes, bilded OSM2World diese richtig, allerdings ist die 'Dachhaut' dann nicht eine Fläche, sondern 'eingefallen'

Ein Beispiel-Bild wäre nützlich. Unter 'eingefallen' kann ich mir nicht vorstellen, was du damit genau meinst.

Eventuell hilft es, noch eine Linie mit roof:edge=yes als Verlängerung der Schleppdachkante einzufügen.

Edbert (EvanE)

Dächer, die über eine rechteckige Form hinausgehen, stellt OSM2World fehlerhaft dar..

Noch ein Grund mehr, sich zusammen zu schließen und gemeinsam zu entwickeln.
Kendzi hat in der Hinsicht schon viel gemacht.

Ok, hier das Fallbeispiel:

6 Buildings. Beginnend einfach mit

1) einem Rechteck in die Pampa gezeichnet. (ganz links). Attribute: building=yes, height=10, roof:shape=gabled, roof:height=5.
2) Die ausgeschnittene Dachform. Attribute wie (1). Dachorientierung falschrum.
3) Zusätzlich zu (2) roof:orientation:across. Darstellung in kendzi richtig, in O2W ist der Dachfirst schief. Anscheinend wird hier vom Mittelpunkt der linken Linie zum Mittelpunkt der rechten Linie ein (schiefer) Dachfirst gebildet. (Im O2W-Bild das 2. von links, hier fehlt das erste, rechteckige Building).
4) Hier habe ich eine Linie eingezeichnet, roof:ridge=yes. kendzi interessiert der Tag nicht (auch nicht building:roof:ridge:yes), hier wird einfach die Mitte als First genommen, allerdings immer parallel. Mit den 3dr-Tags könnte man hier sicherlich Einfluss nehmen.
Darstellung in O2W: roof:ridge:yes wird verarbeitet und richtig dargestellt, allerdings ist das Dach hier 'eingefallen'. Man sieht die unterschiedlichen Schattierungen. Ich habe keine bessere Perspektive hinbekommen, wenn ich näher rangehe, spinnt das Programm bei mir. Aber das untere, erste Dreieck des Daches ist parallel zum Erdboden.
in 5) und 6) habe ich roof:edge=yes links und rechts bzw. oben und unten eingetragen; keine Veränderung. building:roof:edge=yes ebenso.

Kendzi:
https://www.dropbox.com/s/ceeptvf799na6mg/Kendzi.png

O2W:
https://www.dropbox.com/s/zqhll9sjwxl9ucj/OSM2World.png

Ich nehme an du willst das hier: 🙂

Hallo, things-change,
Danke für Deine Arbeit. Solche Tests sind immer sehr wichtig.
Ich kann nur für Kendzi Implementierung sprechen: Die Dächer mit nennen wir´s, "2.n Typologie" nimmt immer an, dass der First des Daches mittig liegt. Das "3.0" erlaubt eine beliebige Lage / Neigungen beider Dachfächen.

Ich werde die Beschreibung in der Wiki, wie versprochen, aktualisieren.

Also Leute, bevor ihr euch zu viel den Kopf zerbrecht: Dieses Dach sollte als roof:shape=gabled eingetragen werden. Das Verhalten von Kendzi3D bei diesem Tagging ist korrekt, das von OSM2World nicht.

Man kann zwar mit roof:ridge etc. arbeiten, es sollte aber bei so einem einfachen Dach gar nicht nötig sein. Das ist einfach nur ein Renderer-Bug.

@euch, danke für die Rückmeldung. @reneman, genau so ein Dach ist das, wobei ich mich frage, ob die Perspektive dort verzerrt, oder der Dachwinkel Unterkante zu Oberkante nicht gleich ist, und wie das getaggt ist für diese Darstellung in O2W.

@tordanik: Danke für die Info, dass das lediglich ein Bug ist. Hoffentlich wird das behoben. Dass man bei so einem Dach nicht mit roof:ridge=yes arbeiten muss, stimmt allerdings nicht, da der Dachfirst nicht genau in der Mitte des Daches liegt.

Tordanik wrote:

Dass wir uns auf dem 3D-Workshop entschieden haben, eine komplette Überlappung der Gesamtfläche mit building:part-Flächen zu fordern

-1 Hier sollte man nochmal nachdenken und eine einfache, konsistente Lösung suchen.
Insbesonders sollte das building nicht verschwinden wenn es gleichzeitig als building:part markiert ist (Bug?).
Chris

chris66 wrote:

Tordanik wrote:

Dass wir uns auf dem 3D-Workshop entschieden haben, eine komplette Überlappung der Gesamtfläche mit building:part-Flächen zu fordern

-1 Hier sollte man nochmal nachdenken und eine einfache, konsistente Lösung suchen.
Insbesonders sollte das building nicht verschwinden wenn es gleichzeitig als building:part markiert ist (Bug?).
Chris

Stimmt, es sollte dann durchaus auch laut Dokumentation nicht verschwinden. Aber hast du wirklich einen Fall gefunden, wo man das brauchen könnte? Uns ist keiner eingefallen, bei dem nicht gegen die Konvention verstoßen würde, dass sich Tags am building eben (auch) aufs Gesamtgebäude beziehen lassen sollen.

Hi, das Beispiel such ich noch raus, bin grad mit Tempo 290 unterwegs.
was anderes:
ich wuensch mir eine Implizierung fuer surface, zB sollte surface grass bei landuse grass u. meadow,
U. village-green default sein.

Spricht was dagegen die geneigten Flachdaecher (skillion) in die simple building wiki Seite aufzunehmen?
Wird ja mittlerweile auch von Kenzi unterstuetzt (allerdings um 180 grad gedreht).

chris66 wrote:

Spricht was dagegen die geneigten Flachdaecher (skillion) in die simple building wiki Seite aufzunehmen?
Wird ja mittlerweile auch von Kenzi unterstuetzt (allerdings um 180 grad gedreht).

Ja, dass es noch keine Einigung über die Art der Richtungsangabe bei diesen Dächern gibt. Genau das Thema diskutieren wir allerdings gerade.

Die implizierten surfaces sollten sich machen lassen.

Bitte, sieht Euch dies an:
http://wiki.openstreetmap.org/wiki/DE:O … l.C3.A4che
Ich habe dort alte Fehler von Kendzi entfernt.
Ich glaube, damit wären alle Probleme gelöst, da die Beschreibung mathematisch eindeutig ist.

Zu berücksichtigen beim Zeichnen ist allerdings der erste Punkt (S) aus dem man das Zeichnen des Gebäudeumrisses beginnt, sowie die Richtung in die man zeichnet. In Uhrzeigersinn bzw gegen Uhrzeigersinn ergibt im 3D ein gespiegeltes Objekt.

Grüße,
Marek

Nach dem Simple3DBuildings Schema lassen sich ja schon recht komplexe Gebäude darstellen, solange keine konischen Säulen oder Kugeln enthalten sind.
Das Problem ist aber das erstellen mit JOSM. Ich habe meinetwegen ein Haus, von dem ich die Maße weiss. Die Höhe eintragen geht ja gut, ist ja ein Tag. Aber zeichne ich ein rechteckiges Haus auf Maß (was ja an sich schon recht fummelig ist) und drücke dann 'q' zum rechtwinklig Machen, ist mein Maß dahin. Auch z.B. Säulen in regelmäßigen Abständen, oder gar im Kreis angeordnet, geht kaum.

Gibt es die Möglichkeit in JOSM, das komfortabler zu machen?
Oder geht das mit anderen Programmen, von denen man dann importieren kann? Müssen ja nicht mal dreidimensionale Modelle sein, es wird ja nur die Grundfläche benötigt.

Moin,

things-change wrote:

Das Problem ist aber das erstellen mit JOSM. Ich habe meinetwegen ein Haus, von dem ich die Maße weiss. Die Höhe eintragen geht ja gut, ist ja ein Tag. Aber zeichne ich ein rechteckiges Haus auf Maß (was ja an sich schon recht fummelig ist) und drücke dann 'q' zum rechtwinklig Machen, ist mein Maß dahin. Auch z.B. Säulen in regelmäßigen Abständen, oder gar im Kreis angeordnet, geht kaum.

Gibt es die Möglichkeit in JOSM, das komfortabler zu machen?

Dann kennst Du die komfortable Methode A) wohl definitiv noch nicht.
B) und C) sind keine direkten Methoden und auch nicht unbedingt komfortabel, aber hilfreich, falls evtl. noch nicht bekannt:

A) Rechteckiges Haus:
Zeichne eine Seite des Hauses maßgenau.
Mit "Flächen erstellen" (Taste X) zieht man das Haus maßgenau zum Rechteck auf - und spart sich das (Q) "Rechtwinklig machen".

B) Kreis anordnen:
Mit der Einstellung "createcircle.nodecount" = x kann man die Anzahl der nodes (Säulen) direkt setzen.
Zeichne dann einmal einen Durchmesser zwischen zwei Säulen-Mittelpunkten.
Mit (Shift + O) wird daraus ein Kreis mit x Säulen-Mittelpunkten.

C) Regelmäßige Abstände
Mit "Punkte in einer Gerade anordnen" (L) kann man eine Linie mit mehreren Punkten zwischen den Endpunkten gerade ausrichten. Macht Shift + B automatisch ...
Mit "Punkte verteilen" (Shift + B) kann man die vorhandenen Punkte gleichmäßig auf der Linie verteilen.

Mit diesen Hilfskonstruktionen sowie einem Hilfskreuz für die Säulen-Mittelpunkte kann man dann die Säulen genauer positionieren.

Gruß
Georg

Generell bin ich der Meinung, dass:

(1) building und building:part im 3D Rendering gleichberechtigt sein sollte
(2) das Rendern des buildings wahlweise erfolgen sollte, z.B. indem es immer gerendert wird, außer
falls es als outline in der Relation definiert und nicht als building:part markiert ist
(3) die Relation optional sein sollte

Damit wäre es möglich:

-Bei Fernsehtürmen nur die Fußfläche als building , den "Kopf" als überstehenden part zu definieren.
-Schornsteine man_made=chimney mit building:part zu markieren (sind ja keine buildings)

Beides ist in osm2world derzeit nicht möglich (wird nicht gerendert).

Chris

marek kleciak wrote:

Mein Rat an verrückte die 3D mögen: Billigstes Entfernungsmessgerät (Laser bzw. Ultraschall).

ich komme mit poor-man's-photogrammetrie ganz gut klar:

Also, einfach das Objekt (senkrecht) fotografieren und per Grafikprogramm vermessen. 😉
Die Konstante 2650 muss halt einmal per Referenz bestimmt werden (gilt für Samsung S1+, höchste Auflösung).

Edit: Beim LG G2 beträgt die Konstante 3580.

Natürlich geht das, wenn man genug Abstand zum Objekt hat.
Schwieriger ist es, wenn man eine Gasse hat. Da muss man bis zur Regenrinne messen und mit dem Entfernungsmesser ist man schneller.

Jetzt muss ich doch nochmal fragen: Gibt's bei der Online-Karte im Moment ein Render-Problem? Da gibt es einige Gebäude seit dem 5.2. die noch nicht erscheinen, Tiles sind nicht neu, auch wenn es seit dem schon mindestens zwei updates (laut About-Seite) gab. Z.B. hier: http://maps.osm2world.org/?h=128&view=N … ers=B0TTFF

(PS: Ja, die Gleise die da im Nichts enden mache ich noch fertig, beim letzten Versuch ist mir JOSM komplett abgeschmirt... sogar die automatische Sicherung war kaputt... 🙁 )

World In Black 😉

MOin

Mueschel, der osm2world schafft es nur etwa 1 mal die woche, eine Ecke zu rendern. Meine Ecke macht er so alle 8 Tage nur. In deinem Bereich sind die Kacheln vom 6.2., da sollte er bald wieder rüber gehen (wenn es denn Änderungen gegeben hat).
Wenn du die Änderungen schneller sehen willst, hilft leider nur selber rendern...

Amiga4000

Hmm ok, bei mir gibt es den komischen Effekt, dass ich den Eindruck habe, dass er nur ganz langsam Stück für Stück die Änderungen anwendet. Also quasi nicht mit einem Schlag die gesammte Karte, sondern für einen Bereich häufig nur einen Stand, der schon lange nicht mehr aktuell ist.

@Tordanik magst du ganz kurz erklären wie bei euch Updates eingespielt werden?

Vielleicht hängt das aber auch mit den anderen Problemen zusammen. Die Geofabrikupdates hatten ja auch gerade Probleme und diese sind die Grundlage für den Server.

!i! wrote:

@Tordanik magst du ganz kurz erklären wie bei euch Updates eingespielt werden?

Ich hoff mal ich darf auch antworten 🙂

Zur Erklärung was wir machen: Wir laden einen Dump von Frederik herunter und zerteilen den in lauter Datenfiles der Größe z=13. Das Datum des Dumps steht in der About-Seite und enthält Daten, die da bereits ca 1-2 Tage alt sind. Dann kommen die Renderserver und suchen sich per Zufallsgenerator eine Kachel aus und rendern diese (das ist dann das Datum, dass im Timestamplayer steht). Wenn alle Kacheln gerendert wurden (dauert 3-7 Tage) dann wird ein neuer Dump heruntergeladen. Im übrigen werden nur die Datenkacheln gespeichert und somit gerendert, die sich geändert hatten, d.h. die Menge an Arbeit hängt auch von der Anzahl an Änderungen ab.

mueschel wrote:

Jetzt muss ich doch nochmal fragen: Gibt's bei der Online-Karte im Moment ein Render-Problem? Da gibt es einige Gebäude seit dem 5.2. die noch nicht erscheinen, Tiles sind nicht neu, auch wenn es seit dem schon mindestens zwei updates (laut About-Seite) gab. Z.B. hier: http://maps.osm2world.org/?h=128&view=N … ers=B0TTFF

Ich denke das passt so schon. Das letzte mal wurde die Kachel am 6.2. gerendert, leider kann ich nicht mehr nachschaun, wie aktuell die Daten zu diesem Zeitpunkt waren. Das werden wir demnächst noch ändern um das etwas transparenter zu gestalten. Der neue Dump von gestern sollte deine Daten sicher enthalten und beim nächsten Rendern dieses Tiles (Zufallgenerator, spätestens in 3 Tagen) sind deine Daten dann auch sicher dabei. Falls nicht, gäbe es wirklich einen Bug.

reneman wrote:

World In Black

Das passiert leider manchmal. Habe ich mal manuell gefixt.

Peda wrote:

Das werden wir demnächst noch ändern um das etwas transparenter zu gestalten.

Den Ablauf
1. ca. 1 Tag alten Dump laden, 2. geändertes neu rendern, 3. warten auf nächsten Dump
hatte einer von euch ja schonmal gepostet, soweit ist das auch klar. Ein Absatz über den Ablauf auf der About-Seite sollte völlig reichen für die Transparenz, insbesondere das Alter des Dumps ist für den ungeduldigen User wichtig zu wissen. :-)

Peda wrote:

Das letzte mal wurde die Kachel am 6.2. gerendert, leider kann ich nicht mehr nachschaun, wie aktuell die Daten zu diesem Zeitpunkt waren. Der neue Dump von gestern sollte deine Daten sicher enthalten und beim nächsten Rendern dieses Tiles (Zufallgenerator, spätestens in 3 Tagen) sind deine Daten dann auch sicher dabei. Falls nicht, gäbe es wirklich einen Bug.

Gerendert am 6.2. um 6 Uhr, Dump-Datum war etwa drei Stunden früher (klar, hier sind die Änderungen vom 5.2. noch nicht drin). Dann gabs laut About einen Dump vom 12.2. und gestern stand da dann der 15.2. Evtl. noch einen Dump dazwischen den ich nicht mitbekommen habe.

Btw., wäre es möglich ein paar mehr Gebäudetypen mit default-Werten zu versehen? Ich benutze hier z.B. relativ häufig shed für Gartenschuppen und die sehen mit 10 Metern Höhe einfach merkwürdig aus. Vielleicht kann man einen default von 2.5 m und brauner Farbe machen?

mueschel wrote:

Btw., wäre es möglich ein paar mehr Gebäudetypen mit default-Werten zu versehen? Ich benutze hier z.B. relativ häufig shed für Gartenschuppen und die sehen mit 10 Metern Höhe einfach merkwürdig aus. Vielleicht kann man einen default von 2.5 m und brauner Farbe machen?

Da wäre ein est_height=2.5 (wird bei OSM2World ausgewertet) deutlich einfacher. Das ist näher an der Realität und verschiebt nicht die Verantwortung auf den Renderer.

Das Problem ist, dass man mit Default-Werten auch heftig daneben liegen kann.
Du magst das so wie im Wiki beschrieben nutzen. Andere mögen das als Synonym für Scheune (barn) verwenden, da das nicht bei building definiert ist. Dann wäre damit ein Gebäude-Typ mit meist zwei Stockwerken gemeint.

Edbert (EvanE)

EvanE wrote:

Da wäre ein est_height=2.5 (wird bei OSM2World ausgewertet) deutlich einfacher.

Das erste was ich dachte war: Vom Regen in die Traufe.
Denn est_height ist m.E. eine komplett undokumentierte Eigenschaft.
Außer in dieser Tabelle konnte ich in der schnelle nix darüber finden. 🙁

reneman wrote:

EvanE wrote:

Da wäre ein est_height=2.5 (wird bei OSM2World ausgewertet) deutlich einfacher.

Das erste was ich dachte war: Vom Regen in die Traufe.
Denn est_height ist m.E. eine komplett undokumentierte Eigenschaft.
Außer in dieser Tabelle konnte ich in der schnelle nix darüber finden. 🙁

Das ist doch eigentlich mein Part, auf solche Unzulänglichkeiten hinzuweisen. 😉

Allerdings sehe ich im Vergleich zu est_width keine Gründe, das auch analog für length oder height zu nutzen. Man könnte natürlich auch height=* + source:height=estimation schreiben. Das scheint mir aber bei weitem nicht so klar zu sein. Wer wertet denn zusätzlich das source:* noch aus?

Edbert (EvanE)

EvanE wrote:

mueschel wrote:

Btw., wäre es möglich ein paar mehr Gebäudetypen mit default-Werten zu versehen? Ich benutze hier z.B. relativ häufig shed für Gartenschuppen und die sehen mit 10 Metern Höhe einfach merkwürdig aus. Vielleicht kann man einen default von 2.5 m und brauner Farbe machen?

Da wäre ein est_height=2.5 (wird bei OSM2World ausgewertet) deutlich einfacher. Das ist näher an der Realität und verschiebt nicht die Verantwortung auf den Renderer.

Da bin ich absolut dagegen. Dann brauchen wir noch est_material (wenn ich es nur gesehen, aber nicht angefasst habe), est_color (wenn es schon dämmrig war beim Betrachten) und in den meisten Fällen ein est_roof:type, weil man das Dach meist nur von der Straße aus sieht und die Rückseite raten muss.

Die Höhe ergibt sich aus der Definition des Gebäudetyps. Alles andere gaukelt nur Informationen vor, die in Wirklichkeit gar nicht vorliegen. Wenn ich est_height setze, dann heißt das, ich habe danebengestanden, und bin mir über die Höhe sicher, hatte aber gerade keinen Zollstock dabei. Über den Typ 'shed' kann ich aber auch Aussagen treffen, wenn ich in 50 Meter Entfernung vorbeigegangen bin oder sogar nur ein Luftbild hatte.

EvanE wrote:

Das Problem ist, dass man mit Default-Werten auch heftig daneben liegen kann.
Du magst das so wie im Wiki beschrieben nutzen. Andere mögen das als Synonym für Scheune (barn) verwenden, da das nicht bei building definiert ist. Dann wäre damit ein Gebäude-Typ mit meist zwei Stockwerken gemeint.

Ein shed ist im wiki eindeutig definiert, sogar ohne irgendwelche Mehrdeutigkeiten in den Übersetzungen die ich lesen kann. Wenn das jemand falsch benutzt ist das kein Problem, das ein renderer beachten muss. Eine Scheune ist ebenso eindeutig farm_auxiliary (auch wenn ich 'barn' gut fände).

@EvanE: Die Unzulänglichkeit ist in meinen Augen die, dass man est_* garnicht braucht. Es macht dem Renderer/3D-Interpreter die Arbeit nur schwerer, schließlich muss dafür dann eine extra Regel geschrieben werden. Doch eigentlich ist das unnötig, denn ein bestimmtes Objekt kann nur eine Höhe haben. Ob dies eine gemessene oder geschätze ist, spielt keine Rolle. Es ist nur für den Mapper interessant, da dieser dann die Info erhält, dass hier der Bedarf für einen exakteren Wert besteht. Doch eben der Mapper kann lesen und das Attribut "source:height" auch auswerten. Daher tendiere ich zur Verwendung von

EvanE wrote:

height=* + source:height=estimation

Auf der Seite "key:height" steht daher auch: Die Quelle der Höhenangabe kann mittels source:height=* definiert werden.
Dies führt dazu, dass diese Tabelle ein Stück übersichtlicher wird und der Mapper nicht ausversehen height und est_height gleichzeitig verwendet, was wieder zu einer zusätzlichen Interpretationsregel führen würde.

mueschel wrote:

Ein shed ist im wiki eindeutig definiert, sogar ohne irgendwelche Mehrdeutigkeiten in den Übersetzungen die ich lesen kann.

Meinst du diese "eindeutige" Definition? http://wiki.openstreetmap.org/wiki/Tag:building%3Dshed 😉
Außer einem Foto ist hier nix zu sehen...

reneman wrote:

mueschel wrote:

Ein shed ist im wiki eindeutig definiert, sogar ohne irgendwelche Mehrdeutigkeiten in den Übersetzungen die ich lesen kann.

Meinst du diese "eindeutige" Definition? http://wiki.openstreetmap.org/wiki/Tag:building%3Dshed 😉
Außer einem Foto ist hier nix zu sehen...

Nein, ich meine die Übersichtsseite zu building: http://wiki.openstreetmap.org/wiki/Key:building

mueschel wrote:

reneman wrote:

mueschel wrote:

Ein shed ist im wiki eindeutig definiert, sogar ohne irgendwelche Mehrdeutigkeiten in den Übersetzungen die ich lesen kann.

Meinst du diese "eindeutige" Definition? http://wiki.openstreetmap.org/wiki/Tag:building%3Dshed 😉
Außer einem Foto ist hier nix zu sehen...

Nein, ich meine die Übersichtsseite zu building: http://wiki.openstreetmap.org/wiki/Key:building

Danke, hab die Attributbeschreibung von Key:building nach Tag:building=shed übernommen 🙂

Leute, wollen wir tagging-Diskussionen zu 3D nicht auslagern? Das ist doch nichts spezifisches von O2W und gehört eigentlich zur Thematik allgemeines 3D. Wenn ihr das nur hier schreibt, dann geht es doch total unter?

@Peda Nein kein Problem wenn du antwortest 😉 Danke auch gleich für die Erläuterungen! Gibt es einen bestimmten Grund, wieso vom Scheduler die Gebiete zufällig ausgewählt werden? Es wäre später vielleicht gut, wenn Gebiete mit vielen/gravierenden Änderungen vielleicht schneller/häufiger aktualisiert werden?

Ich weiß das klingt nach Wunschliste, aber habt ihr mal geschaut, ob euch jemand hilft eine DB aufzusetzen, die sich permanent aktualisiert?

Darf ich fragen, ob man demnächst evtl. den Kanton Freiburg wieder neu rendern kann? Ich habe letzthin ein paar 3D-Änderungen vorgenommen und würde gerne sehen, ob diese o.k. sind. Danke.

efred wrote:

Darf ich fragen, ob man demnächst evtl. den Kanton Freiburg wieder neu rendern kann? Ich habe letzthin ein paar 3D-Änderungen vorgenommen und würde gerne sehen, ob diese o.k. sind. Danke.

Mache ich ansich regelmässig aber es gibt immer keine Änderungen. Laut unseren Skripten sind die letzten Änderungen die in OSM gemacht wurden vom 3.2.2013. Ich nehme also fast an, dass da was mit Frederiks Dump für die Schweiz nicht ok ist. Ich werde das mal weiter untersuchen bzw. Frederik anschreiben/fragen.

Könnte man vielleicht die Priorität einiger Gebiete durch Pizza-Spenden günstiger beeinflussen? 😄 Ich warte schon sehnsuchtsvoll auf Warnemünde und die Rostocker Innenstadt 🙂

Peda wrote:

aut unseren Skripten sind die letzten Änderungen die in OSM gemacht wurden vom 3.2.2013. Ich nehme also fast an, dass da was mit Frederiks Dump für die Schweiz nicht ok ist. Ich werde das mal weiter untersuchen bzw. Frederik anschreiben/fragen.

Vielen Dank, dass Du Dich dieser Sache annimmst. Jedenfalls zwischen 05.02 und 13.02 habe ich doch einiges an 3D-Daten hinzugefügt/geändert in meiner Region - siehe z.b. meine Edits hier: http://www.openstreetmap.org/user/efred/edits?page=2.

!i! wrote:

Könnte man vielleicht die Priorität einiger Gebiete durch Pizza-Spenden günstiger beeinflussen? 😄 Ich warte schon sehnsuchtsvoll auf Warnemünde und die Rostocker Innenstadt 🙂

Klares JA 🙂

Sag mir welches Gebiet/welche Kacheln. Du spendierst dann die Pizza bei unserem nächsten Hackevening, an dem wir die SlippyMap, Rendergeschwindigkeit, Kartendetails,... verbessern 😉

Peda wrote:

mueschel wrote:

Jetzt muss ich doch nochmal fragen: Gibt's bei der Online-Karte im Moment ein Render-Problem? Da gibt es einige Gebäude seit dem 5.2. die noch nicht erscheinen, Tiles sind nicht neu, auch wenn es seit dem schon mindestens zwei updates (laut About-Seite) gab. Z.B. hier: http://maps.osm2world.org/?h=128&view=N … ers=B0TTFF

Ich denke das passt so schon. Das letzte mal wurde die Kachel am 6.2. gerendert, leider kann ich nicht mehr nachschaun, wie aktuell die Daten zu diesem Zeitpunkt waren. Das werden wir demnächst noch ändern um das etwas transparenter zu gestalten. Der neue Dump von gestern sollte deine Daten sicher enthalten und beim nächsten Rendern dieses Tiles (Zufallgenerator, spätestens in 3 Tagen) sind deine Daten dann auch sicher dabei. Falls nicht, gäbe es wirklich einen Bug.

Also da scheint wirklich etwas nicht zu funktionieren. Rundherum sind tiles schon zum zweiten oder dritten Mal neu gerendert, einige Tiles (das verlinkte Gebiet und weiter nördlich) nicht, obwohl es teilweise mehrfach Änderungen gab. Nicht dass jetzt einer glaubt, ich wäre versessen meine eigenen Änderungen unbedingt sehen zu wollen - da ist nichts spektakuläres dabei :-)

Nahmd.

Ha! Meine Testhütte ist endlich gerendert. Jetzt muss ich nur noch was mit der Motorsäge beigehn, um mir das Ergebnis von allen Seiten anschauen zu können. Da bedanke ich mich doch artigst. 🙂

Gruß Wolf

Netzwolf wrote:

Ha! Meine Testhütte ist endlich gerendert. Jetzt muss ich nur noch was mit der Motorsäge beigehn, um mir das Ergebnis von allen Seiten anschauen zu können.

Von dem Holz kannst du dann gleich noch eine Hütte "bauen". 😄

Warnemünde ist auch fertig geworden:
http://maps.osm2world.org/?h=128&view=S … ers=B0FFFF
Ich finde es ganz schön geworden, ihr könnt ja mal vergleichen:
http://commons.wikimedia.org/wiki/File: … un_Ost.jpg
http://commons.wikimedia.org/wiki/File: … n_West.jpg

Ich finde es auch "Klasse" - ist aber auch eine Menge Daten.

Das zeigt es auch teilweise (aber nur am Tage) livespotting.tv.

Hossa. Ich habe gerade ein kleines Tagging-Problem:

Diese beiden Gebäude bzw. Gebäudeteile liegen direkt aneinander. Um das linke Dach korrekt zu beschreiben muss(?) zwischen den beiden Gebäuden ein roof:ridge hinzugefügt werden. Das beeinflusst fälschlicherweise aber auch das Dach des rechten Gebäudes, da es sich um die gleichen Knoten handelt. Ich habe schon erfolglos auf der slippy map nach einem ähnlichen Fall gesucht.

Sehe ich den Wald vor lauter Bäumen nicht oder lässt sich dieser doch eigentlich nicht all zu unübliche Fall momentan nicht realisieren?

bisher habe ich 2 building:parts gesetzt. Das linke hätte dann eben nur ein roof:shape=flat und das Haupthaus eben wie gewohnt getaggt. Nicht gut?

scai wrote:

Hossa. Ich habe gerade ein kleines Tagging-Problem:
http://i.imgur.com/znWqKpt.png
Diese beiden Gebäude bzw. Gebäudeteile liegen direkt aneinander. Um das linke Dach korrekt zu beschreiben muss(?) zwischen den beiden Gebäuden ein roof:ridge hinzugefügt werden. Das beeinflusst fälschlicherweise aber auch das Dach des rechten Gebäudes, da es sich um die gleichen Knoten handelt. Ich habe schon erfolglos auf der slippy map nach einem ähnlichen Fall gesucht.

Sehe ich den Wald vor lauter Bäumen nicht oder lässt sich dieser doch eigentlich nicht all zu unübliche Fall momentan nicht realisieren?

Bei dem kleinen Nebengebäude würde ich roof:shape=gabled setzen und eine Linie ziemlich nahe an der Hauswand zum großen Gebäude zeichnen mit roof:ridge=yes. Ist bis auf weiteres halt eine Notlösung.

So habe ich Shed-Dächer auf Fabrikgebäuden gezeichnet.

Viele Grüße

Dietmar aka okilimu

!i! wrote:

bisher habe ich 2 building:parts gesetzt. Das linke hätte dann eben nur ein roof:shape=flat und das Haupthaus eben wie gewohnt getaggt. Nicht gut?

Dann ist das linke Dach flach, was es nicht ist. Nicht gut 🙂.

okilimu wrote:

Bei dem kleinen Nebengebäude würde ich roof:shape=gabled setzen und eine Linie ziemlich nahe an der Hauswand zum großen Gebäude zeichnen mit roof:ridge=yes. Ist bis auf weiteres halt eine Notlösung.

Danke. Das ist bisher auch das einzige, was mir als Notlösung eingefallen ist. Daher wollte ich vorher lieber nochmal nachfragen, nicht dass ich etwas übersehen habe.

Nebengebäude ist eben roof:shape=skilion

sehe: http://wiki.openstreetmap.org/wiki/DE:O … l.C3.A4che

Das dafür eigentlich vorgesehenes type 6.0 mit dem Auslassen einiger Parameter habe ich noch nicht ausreichend beschrieben.

Nachtrag:
osm2world braucht dringend ein Dach mit einer Ebene (skilion). Genauso wie die:
http://wiki.openstreetmap.org/wiki/Simple_3D_Buildings
Die Auswahl der Dachtypen dort gehört ergänzt um diese Form.

Bei dem 3D Meeting in Garching hat die Mehrheit eine Auswahl getroffen. Eben eine falsche weil keiner davon ein Architekt ist 😉
Nach dem Doppleschrägdach und Flachdach ist ein Dach mit einer Schräge die Form die man am öftesten trifft.
Daher bitte an alle: verwendet auch diese Form unter Beachtung der Umrisssrichtung und des Startpunktes des Umrisses, S.

Bedenkt aber bitte, das diese Erweiterungen alle zur Zeit experimentell sind. Es kann sein, dass sie nicht Einzug in ein weiterentickeltetes Simple 3D buildings-Schema halten und dann wieder geändert werden müssen.
Ein einzelnes Dach, was nicht schräg ist empfinde ich in Maßstäben eines Stadtmodells derzeit als vertretbaren Kompromiss 🙂

Liebe Leute, an diese Stelle teile ich diese Sorge nicht.
Ein Schrägdach muß rein selbst in die elementarste Form bzw. Library.

Wohl wahr. Aber momentan tagge ich eh nur das, was ich direkt mit dem OSM2World-Viewer überprüfen kann. Von daher lasse ich diesen Fall erst einmal.

geri-oc wrote:

Ich finde es auch "Klasse" - ist aber auch eine Menge Daten.

Auf jeden Fall, man muss sich wirklich überlegen, ob das großflächig überall so aussehen soll. Für mich ist es derzeit erstmal ein Demogebiet, um zu ermitteln was man so aus S3DB rausholen kann und wo die Grenzen sind.

marek kleciak wrote:

Liebe Leute, an diese Stelle teile ich diese Sorge nicht.
Ein Schrägdach muß rein selbst in die elementarste Form bzw. Library.

Ich sage nicht, dass es nicht reinkommen sollte. Allerdings sollte sich zu gegebener Zeit (wenn mehr Erfahrungen mit S3DB vorliegen) mal überlegt werden, wie man die Problemfälle mit einem neuen komplexeren Schema abdecken kann:
http://wiki.openstreetmap.org/wiki/Talk … imitations
Das dazu bereits Ansätze erprobt werden finde ich immer gut 🙂

efred wrote:

Darf ich fragen, ob man demnächst evtl. den Kanton Freiburg wieder neu rendern kann? Ich habe letzthin ein paar 3D-Änderungen vorgenommen und würde gerne sehen, ob diese o.k. sind. Danke.

War ein Bug. Hängt jetzt wieder in der Queue und sollte nach spätestens 4 Tagen gerendert sein.

!i! wrote:

marek kleciak wrote:

... Ein Schrägdach muß rein selbst in die elementarste Form bzw. Library.

Ich sage nicht, dass es nicht reinkommen sollte. Allerdings sollte sich zu gegebener Zeit (...) mal überlegt werden, wie man die Problemfälle mit einem neuen komplexeren Schema abdecken kann:
http://wiki.openstreetmap.org/wiki/Talk … imitations ...

Was wirklich fehlt ist ein Runddach (roof:shape=arched) und die Möglichkeit Dachfirst und -kanten (roof:ridge/:edge=yes) zu spezifizieren.
Mit Dachfirst und -kanten kann man asymmetrische und viele komplexen Dachformen sehr effizient eintragen. Dafür braucht es meist kein darüber hinaus gehendes komplexeres Schema.

OSM2World unterstützt roof:ridge/:edge=yes und das ist bei vielen Dachformen recht hilfreich.

Edbert (EvanE)

!i! wrote:

marek kleciak wrote:

Liebe Leute, an diese Stelle teile ich diese Sorge nicht.
Ein Schrägdach muß rein selbst in die elementarste Form bzw. Library.

Ich sage nicht, dass es nicht reinkommen sollte. Allerdings sollte sich zu gegebener Zeit (wenn mehr Erfahrungen mit S3DB vorliegen) mal überlegt werden, wie man die Problemfälle mit einem neuen komplexeren Schema abdecken kann:
http://wiki.openstreetmap.org/wiki/Talk … imitations
Das dazu bereits Ansätze erprobt werden finde ich immer gut 🙂

Darf ich mal Fragen, warum man es für ein einfaches schräges Dach so kompliziert machen will? Damit meine ich sowas wie: Startpunkt oder der Richtung von roof-Linien, etc.
Kann man nicht einfach statt dem hier ein roof:shape=skillion und für:
- Version 1.0: auf die zwei Nodes ein roof:height=x (die anderen beiden brauchen keinen Wert, da Standard=0)
- Version 1.1: auf den höchsten Node ein roof:height=x (der gegenüber ist 0, ergibts schräge glatte fläche)
- Version 1.1 alternativ: auf den höchsten Node ein roof:height=x, die jeweils angrenzenden Nodes bekommen ebenfalls ein roof:height=y bzw. z (ergibt individuell schräges dach)
Ich gehe von einen rechteckigen Building bestehend aus 4 Nodes aus.

"Mein" Vorschlag klingt für mich wesentlich einfacher und leicht verständlich (gegenüber Start- und Endpunkten, Linienrichtungen, etc.).

Hallo Reneman,
es spricht nichts gegen Deinen Vorschlag. Es ist mathematisch identisch.
Grüße,
Marek

Hmm. Das klingt positiv bedeutet aber für die Zukunft was? 🙂

reneman wrote:

"Mein" Vorschlag klingt für mich wesentlich einfacher und leicht verständlich (gegenüber Start- und Endpunkten, Linienrichtungen, etc.).

Ausgangspunkt der Überlegung war allerdings ja ein Beispiel, wo das Dach gemeinsame Knoten mit dem Hauptgebäude hat. So etwas ist auch mit deinem Vorschlag ein Problem, da der roof:height-Wert am gemeinsamen Knoten nur für eines der Gebäude passt.

Daneben gibt es noch einen Nachteil: Es gibt viele Gründe, Knoten in Gebäudeumrisse einzufügen, die nichts mit dem Dach zu tun haben - etwa an Eingängen, wenn dort ein Zaun anfängt, weil das Gebäude dort mit einem Nachbargebäude verbunden ist und so weiter. An vielen wird die Annahme "Standard=0" nicht gelten, man müsste also unter Umständen also noch mehrere weitere Knoten mit Höhenangaben versehen - das ist zusätzlicher Aufwand und wird vermutlich leicht vergessen, vor allem wenn es ein anderer Mapper macht.

Mir selbst ist bei solchen Dächern die Angabe über ein direction-Tag am Gebäude am sympathischsten. Die Lösung kommt mit den wenigsten Tags aus, die zudem alle am selben Objekt sind (gut für Potlatch und JOSM-Presets), und zwingt nicht zu einer Höhenschätzung, wenn man nur die Neigungsrichtung angeben möchte.

Über die Verbesserung der Möglichkeiten beim Dachtagging diskutiere ich aber auch gerade mit Kendzi. So wie es aussieht, werden wir wohl beide unsere Programme mit weiteren Dachtypen ausstatten - in S3DB fehlen ja doch noch einige offensichtliche Typen wie eben das Schrägdach - und jeweils verschiedene Optionen für die Angabe der Richtung erlauben.

Tordanik hat Recht: Zwar ist die Beschreibung mathematisch identisch, müßte aber garantieren dass der Punkt eindeutig einem Gebäude zuweisbar ist. Nehmen wir als Beispiel ein Rechteck, aufgeteilt in 4 kleinere Rechtecke. Der Punt in der Mitte gehörte dann zu 4 verschiedenen Rechtecken. Tagging wäre da sehr mühsam.

Ich freue mich, dass Tordanik und Kendzi weitere Dachformen berücksichtigen möchten. Super!
Ich selbst werde mein Versprechen halten und nach und nach die uneindeutige Beschreibung der Dachformen in der http://wiki.openstreetmap.org/wiki/DE:OSM-4D/Roof_table ergänzen.

Besonders wichtig werden Effekte, die man erreichen kann wenn bestimmte Parameter auf null gesetzt werden oder einfach nicht eingetragen werden (sehe Typ 0.3 bzw. Flat_with_three_terraces ). Auch überlegenswert ist, ob man möchte dass bestimmte Parameter negative Werte annehmen können. In solchen Fällen wären bestimmte Dachformen noch variabler. Beispiele platziere ich noch auf der Seite.

mueschel wrote:

Also da scheint wirklich etwas nicht zu funktionieren. Rundherum sind tiles schon zum zweiten oder dritten Mal neu gerendert, einige Tiles (das verlinkte Gebiet und weiter nördlich) nicht, obwohl es teilweise mehrfach Änderungen gab. Nicht dass jetzt einer glaubt, ich wäre versessen meine eigenen Änderungen unbedingt sehen zu wollen - da ist nichts spektakuläres dabei :-)

Ja, du hattest Recht. Ein dummer Bug von mir den wir jetzt gefixt haben. Ab jetzt sollte es aber wirklich wieder ganz normal gerendert werden. Damit das warten nicht noch länger dauert habe ich die Kachel jetzt mal "per Hand" erneuert 😉

Hallo,

einige Gegenden mit fehlerhaftem Rendern habe ich auf Eurer OSM2World-Karte für Eure QA gefunden:
Zwischen Gesthacht und Lauenburg liegen drei Nur-Hintergrund-Rechtecke ohne Bebauung oder Wald, die die Elbe unterbrechen.

Schwarze Rechtecke südlich von Schwerin (gleich südlich der Autobahn Hamburg-Berlin), mitten im Ort Neubrandenburg, gleich südlich von Rheinsberg mit dunklerem Wald parallel zu den Seiten des Rechtecks, nord-östlich Brandenburg an der Havel, östlich Meschede, süd-westlich Bamberg, südlich Schweinfurt, ein etwas beschnittenes Dreieck westlich Kronach, auch eine weiße, aus mehreren Quadraten zusammengesetzte Fläche zwischen Celle und Gifhorn gibt es.

Grüße,
Franz

Hallo,

was ist mit folgender Dachform?:

https://www.dropbox.com/s/ewbmvu0k4m4b7 … 20Dach.png

Es sind einfach 2 verschachtelte Dächer. (Die Gaube jetzt mal aussen vor gelassen). Ich hab es nur hingekriegt, wenn ich 2 verschachtelte Quadrate zeichne und jeweils als Dach tagge. Aber es kommt mir nicht richtig vor, schliesslich geht das eine Dach ja nicht in dem Anderen weiter. Das Foto ist aus kendzi3d, in OSM2W sieht es nicht ganz richtig aus, das Thema 'eingefallene' Dächer hab ich ja schon mal beschrieben.
Aber wenn ich die Dächer nicht verschachtele, sondern an der Innenkante jeweils aufhören lasse, werden Dachflächen senkrecht nach unten oder anders falsch gezeichnet.
Ist dieses Tagging ok, oder eher nicht? Ich halts für fragwürdig.

things-change wrote:

Es sind einfach 2 verschachtelte Dächer. (Die Gaube jetzt mal aussen vor gelassen). Ich hab es nur hingekriegt, wenn ich 2 verschachtelte Quadrate zeichne und jeweils als Dach tagge. Aber es kommt mir nicht richtig vor, schliesslich geht das eine Dach ja nicht in dem Anderen weiter.

Das ist AFAIK der derzeitige Stand sowas mit S3DB zu modellieren. Ich stimme dir zu, dass es semantisch nicht völlig korrekt ist. Meiner Meinung nach müsste man dann aber erst mal Anwendungen finden, die sich daran stören, denn für 3D Druck/CAM werden ja eh nur die wirklichen Außenkanten berechnet. Rendern als Wireframe wäre dann natürlich trotzdem etwas verwirrend 😉
Wenn du magst, kannst du es ja hier ergänzen:
http://wiki.openstreetmap.org/wiki/Talk … imitations

Falls Kendzi die Dachformen richtig implementiert hat (ich glabue, das hat er 😉 ), müßte man für die beiden Gebäude Typ 2.0 nehmen (bzw. die wörtliche Beschreibung) und sie etwa so aufteilen:
____________

| |
| |
| |
|_______________ |

Ich glaube, ich muss dafür in Wiki ein Beispiel bauen, um es zu veranschaulichen...

@marek:
So hatte ich es auch schon, kendzi stellt es nicht ganz richtig dar:

https://www.dropbox.com/s/57i1idr1wn14m … falsch.png

Die eine innere Kante geht senkrecht runter

@!!!

In S3DB wohl auch nicht. Hab gesehen, dass ich leider für eine Hälfte die 3dr tags gesetzt habe und nicht roof:shape=gabled. Hab das jetzt nochmal geändert und warte, dass es neu gerendert wird. Aber bei S3DB beeinflussen sich die Kante irgendwie gegenseitig, was zu falschen Knicken in den Dächern führt.

Ich bin beruhigt. Kendzi macht es richtig und die Software stellt das dar, was man eingibt.

Wo liegt der Denkfehler des Erfassers bzw. die Schwierigkeit für ihn:

Stellen wir uns vor dass diese http://www.welsch.com/gallery/3d/Zweita … on_855.jpg Pyramide durch parallelverschiebung dupliziert wird und sich die beiden Körper durchdringen, wobei die eine Pyramide größer als die andere ist. Wo wirklich die richtige Verschneidung beider Flächen ist, würde man erst in der Seitenansicht sehen und von dort aus die Lage dieser Verschneidung in dem Grundriß eintragen. Dü müßtest diese Aussparung etwa mehr in Richtung des Hauses mit der Dachgaube (auf Deinem Beispielsbild im Vordergrund) verschieben. Leider ist dies eine try and error Methode aber ich bin mir sicher dass wir mit der Zeit mehr und mehr CAD Werkzeuge in diese Tools integrieren werden...

Vielen Dank für Deine Arbeit, finde ich wirklich super!

Gut, dann sag ich mal so: Das Abzeichnen des Daches per Luftbild ist ja nur eine Annäherung. Die Schnittfläche müsste aber genau eingezeichnet werden; für den Erfasser gar nicht möglich.
Es müsste also der Editor wie JOSM automatisch die Linie korrigieren, was aber gar nicht möglich ist, weil a) der Erfasser evt. gar nicht für 3D einzeichnet und b) JOSM gar nicht weiss, dass solch eine Dachform erzeugt werden soll. Also müsste diese spezielle Dachform ein eigenes Tag bekommen, was aber übertrieben wäre...

Der vielleicht einfachere Weg: 2 Dächer einzeichnen (wie in Beispiel 1) und festlegen, dass sich schneidende Dachflächen so erfasst werden können (und 'innen' nicht weitergehen)

Das Abzeichnen des Daches per Luftbild ist ja nur eine Annäherung. Die Schnittfläche müsste aber genau eingezeichnet werden

Wie das der Erfasser exakt machen kann, beschreibe ich gerne im Wiki. Leider ist es mühsam:
Man müsste sich sozusagen die Seitenansicht als Hilfskonstruktion bauen, die Lage von dem Punkt der in der Seitenansicht die Verschneidungsgerade beider Ebenen im Raum abbildet und dies auf den Grundriss übertragen.

Es ist also machbar, aber extrem mühsam.
Simple Lösung wenn:
A. Beide Gebäude Parallel zueinader liegen
B. Dachneigungen gleich sind
C. Höhe der Trauflinie gleich ist

sieht man hier:
http://wiki.openstreetmap.org/wiki/File … oblem1.jpg
Die grüne Linie bildet das gewünschte Teilungsergebnis - die richtige Teilungslinie liegt dann exakt in der Mitte zwischen beiden Gebäudekanten.

Viel richtiger wäre aber eine "Echte" CAD Lösung. Sehr gut führt das z.B. das Programm ArchiCAD in dem 3D Fenster vor:
Eine Kante anklicken, die Zweite anklicken und Befehl "Anpassen" durchführen.
Beide Grundrisse werden korrigiert. Die Studentenversion können sich die Studenten kostenlos zum lernen downloaden .

Ich denke auch, dass wir mit purem OSM irgendwann auch einfach Grenzen haben werden, wo der Aufwand nicht mehr die Ergebnisse rechtfertigt. Das wird aber eher die Zukunft zeigen, ob wir da unbedingt ganze Städte in 3D haben wollen, oder eher einige ausgewählte Objekte. Schauen wir mal 🙂

Wir wollen alles und zwar richtig 😉
Dafür müssen wir unsere Editoren nach und nach optimieren.
Ich bin sehr froh, dass man hier so viele gute und berechtigte Fragen stellt.
Das Zusammenstellen der ToDo Liste werden wir schnell abschließen.
Wie wir das realisieren, ist eine weitere Frage...

Ok, habe einen Workflow für ein relativ einfaches Einzeichnen der Dachform nach #249 von Marek in JOSM:

-Beide parts nicht überlappend einzeichnen
-Gebäude, Dachform usw. komplett taggen
-Bei installiertem kendzi3D Plugin nah an die Schnittkante ranzoomen, am Besten von der Seite/schräg oben
-in JOSM die beiden Punkte der Schnittlinie auswählen
-einen Punkt hoch/runter bewegen, der andere Punkt und somit die Linie verschiebt sich mit
-die Änderung ist live im Kendzi3D Fenster zu sehen, verschieben, bis sich die beiden Dachhälften richtig treffen

btw., sollten wir das evt. in einen ext. Thread auslagern? 😄

things-change wrote:

Ok, habe einen Workflow für ein relativ einfaches Einzeichnen der Dachform nach #249 von Marek in JOSM:

-Beide parts nicht überlappend einzeichnen
-Gebäude, Dachform usw. komplett taggen
-Bei installiertem kendzi3D Plugin nah an die Schnittkante ranzoomen, am Besten von der Seite/schräg oben
-in JOSM die beiden Punkte der Schnittlinie auswählen
-einen Punkt hoch/runter bewegen, der andere Punkt und somit die Linie verschiebt sich mit
-die Änderung ist live im Kendzi3D Fenster zu sehen, verschieben, bis sich die beiden Dachhälften richtig treffen

btw., sollten wir das evt. in einen ext. Thread auslagern? 😄

Besser auf eine WIKI-Seite - damit man es wiederfindet als Anleitung.

Thema: Fachwerk

Ich habe das schon genutzte timber_framing schon in building:material ergänzt. Die Farbe der Gefache habe ich, da sie die größte Fläche am Gebäude bedeckt in "meinem" Fall mit building:colour erfasst. Was jetzt noch fehlt wäre die Farbe der Balken und das Material der Zwischenräume.

Für die Farbe der Balken würde ich timber_framing:colour=* vorschlagen. Bei der englischen Bezeichnung für Gefache bin ich mir unsicher. Wäre timber_framing:space:material=* evtl. eine Möglichkeit? Sollte man dann evtl. auch explizit timber_framing:space:colour=* nutzen?

timber_framing:colour=*

Guter Vorschlag. Es sit ellgemeiner als Fachwerk und könnte für andere Dinge verwendet werden.

Hallo
Wie oft wird die Karte aktualisiert ?

Habe einmal mein 1. Test Gebäude eingetragen (taucht auf der Karte nicht auf )
Oder es ist was falsch ?

auf dem Gebäude hab ich

addr:city=Köthen
addr:country=DE
addr:postcode=06366
addr:street=Lelitzer␣Straße
building=yes

Auf dem Inneren Knoten den Eingang:

addr:housenumber=88
building=entrance

und innerhalb des Gebäudes hab ich:

building:colour=silver
building:levels=5
building:part=yes
building=yes
height=20
roof:colour=gray
roof:height=1
roof:shape=flat

Aber von der Karte wird es nicht angenommen?

Wenn es läuft werde ich alle neuen Gebäude die ich male so eintragen.

PS:
Wär auch für eine Anleitung für 3D Karten in Garmin dankbar
Karte machen ist kein Problem.
Beste Grüße

Du kannst OSM2World auch auf deinem Rechner starten und den Bereich mit JOSM als .osm abspeichern. Dann kannst du direkt anschauen, wie es aussehen wird.

Die Karte wird meines Wissens nur etwa alle 2 Wochen neu eingelesen und meistens dauert es auch eine Woche, ehe die eigenen Kartenkacheln neu gerendert wurden.

Was meinst du mit 3D Karten in Garmin?

Hallo

Ich hab keine Ahnung davon Anleitung nirgends gefunden
Gruß

Anleitung:
1. Osm2world herunterladen
2. Osm2world starten
3. Osm-Datei öffnen über Datei-Öffnen.

Hallo
Ich vesuch mal was
Ich hab Ubuntu 13.04
Beste Grüße

Hallo
Die Vorschau zeigt aber andere Farben und nicht die kleinen mini Fenster ?

Das Haus ist aber höher jetzt als alle anderen dargestellt.

Vorschau mal ein paar tage hier:
Eingang ist da

http://ubuntuone.com/6Y4A3X7e20cbUeHTR36MLo

Mit der o.g. cods
Gruß

Nutze mal statt building=entrance entrance=*

Hallo

Keine Veränderung am Haus

oder die Vorschau ist nicht getreu?
Vorschau mit entrance=yes

http://ubuntuone.com/3pyNeVmiWWparSlimhmw1V
Gruß

Win32netsky wrote:

Die Vorschau zeigt aber andere Farben und nicht die kleinen mini Fenster ?

Dazu müsstest du noch die Texturen installieren (geht leider noch nicht automatisch). Grob erklärt im ersten Post hier.

Hallo

Im selben Ordner entpackt
starten mit

java␣-Xmx2G␣-jar␣--config␣texture_config.properties␣--gui␣OSM2World.jar

geht nicht?

starten mit

java␣-Xmx2G␣-jar␣OSM2World.jar

geht ohne Veränderung der Häuser Ansicht
Gruß

Versuch mal:

java␣-Xmx2G␣-jar␣OSM2World.jar␣--config␣texture_config.properties␣--gui

Das "OSM2World.jar" ist nämlich der Wert für den Parameter "-jar" und sollte direkt danach kommen.

Hallo

Das ist es !!

Ich bin auf einem guten richtigen Weg.
Ansicht:
http://ubuntuone.com/62A9fOSbUoCGDiauBz0cTh

Das Haus ist ein altes mit Flachdach 5 Stockwerke (Wie es aussieht wäre es richtig?)

Nur der Eingang auf dem Gebäude entfernt die Fenster ?

Habe es

So kann ich das für alle Häuser (Mit Flachdach) übernehmen?

http://ubuntuone.com/6Ts4pj1diYHNmZfiHbF9Ff

Dann ist es richtig ?

Hier noch mal eines mit schräg Dach fertig
http://ubuntuone.com/1WGgIsGkyGjfM5u2MuhyHZ

Werde versuchen mir viel Mühe zu geben.

weiß wer ob das schon in Garmin geht?
Gruß

Win32netsky wrote:

weiß wer ob das schon in Garmin geht?

Jain.

Die neueren Outdoor-Garmins können ein 3D-Gelände darstellen. Vermutlich jedoch keine Gebäude.

Die aktuellen/besseren Auto-Navis von Garmin können wohl auch 3D-Gebäude darstellen.
Wie das geht und wie man das dann in Karten aus OSM-Daten einbinden könnte, das ist wohl noch nicht entschlüsselt.

Ob die neueren Outdoor Garmins (Montana und Oregon 600/650) mit einer Garmin Autokarte 3D-Gebäude anzeigen können ist mir nicht bekannt.

Edit:
Die neueren Outdoor-Garmins brauchen ein Digitales Geländemodell um ein 3D-Gelände anzeigen zu können.
Auch das ist bisher nicht entschlüsselt und kann daher bisher auch nicht aus Fremddaten (z.B. SRMT) erstellt werden.

Edbert (EvanE)

Ich finde es ja klasse was bereits alles mit Gebäuden in Städten geht. Ich wohne allerdings in einem Dorf, daß habe ich mir auch mal in osm2world angesehen (http://maps.osm2world.org/?zoom=18&lat= … ers=B0TTFF). Sieht gar nicht mal schlecht aus dafür das ich noch keine 3D Tags an die Gebäude getaggt habe (werde ich demnächst nachholen). Klasse finde ich das in entsprechenden Vergrößerungen sogar Feuerwehrhydranten und Sitzbänke gezeigt werden (klein angedeutet), das ist bereits eine Menge Detailreichtum. Interessant ist auch das sogar ein Gewächshaus als solches erkennbar ist (building=greenhouse). Was mir dort aber fehlt: Der Maibaum. Der ist in einem solchen Dorf schon ein Charakteristikum welches für eine realistische Darstellung benötigt wird. Eingetragen habe ich den in OSM als man_made=maypole. Könnte man so etwas auch noch umsetzen?

Außerdem: Wenn man nicht nur Städte in osm2world haben will, sondern das ganze Land wäre es auch toll landuses und natural-Tags besser darzustellen. Also nicht nur Wald rendern, sondern zum Beispiel auch natural=(wetland/scree/scrub/heath/...) etc. Bei wetland auch die verschiedenen wetland=* unterschiedlich darstellen. Dann könnte man eine realistischere Darstellung auch außerhalb von Städten erreichen.

Gruß
unixasket

unixasket wrote:

Klasse finde ich das in entsprechenden Vergrößerungen sogar Feuerwehrhydranten und Sitzbänke gezeigt werden

ja, und Condomautomaten... ;-)

Wie kann man so ein Gebäude korrekt eintragen:
http://www.ibp.fraunhofer.de/content/da … 103299.jpg

Wie kann man einen Turm oben am Gebäude taggen und wie die beiden abgesetzen Gebäudeteile deren Dächer aber an das Dach des Hauptteiles abschließt?

Weitere Fotos:
http://www.roggersdorf.de/html/st__margareth.htm
http://mw2.google.com/mw-panoramio/phot … 678719.jpg

Edit: Gebäude in OSM:
http://www.openstreetmap.org/?mlat=47.8 … 8&layers=M
Gruß

unixasket

Und noch eine Frage: Wie kann man unterschiedliche Farben und Materialien für ein Gebäude im Erdgeschoß und im 1. Stock angeben. Zum Beispiel gibt es im ländlichen Bayern viele Gebäude die im Erdgeschoß weiß verputzt sind, aber im 1. Stock eine braune Holzverkleidung haben.

Ist es auch möglich anzugeben, daß ein Gebäude Holzbalkone hat?

Gruß
unixasket

Hallo
Also mein 660 zeigt kein 3D Gebäude an.
Owohl es die Einstellung 3D hat ?
Liegt wohl noch an Mkgmap?

Gruß

unixasket wrote:

Und noch eine Frage: Wie kann man unterschiedliche Farben und Materialien für ein Gebäude im Erdgeschoß und im 1. Stock angeben.

Indem man 2 building parts übereinander stapelt!?

Im Prinzip kann man mit dem Simple Building Parts alles abbilden, wenn man nur die Legosteine Voxels klein genug macht. 😉

Von Garmin sind nur Teile des alten KArtenformats bekannt. AFAIK gehören 3D-Gebäude zum NT-Format (also dem neuen Format). Ohne jetzt pessimistisch zu sein, aber mach dir da keine Gedanken, dass das in nächster Zeit unterstützt wird.

chris66 wrote:

unixasket wrote:

Und noch eine Frage: Wie kann man unterschiedliche Farben und Materialien für ein Gebäude im Erdgeschoß und im 1. Stock angeben.

Indem man 2 building parts übereinander stapelt!?

Wie geht das? Wie kann man man das mit JOSM und mit Potlatch eingeben?

Gruß
unixasket

Mehrere Objekte übereinander zeichnen. Wenn das untere Rechteck fertig ist, fängst du an einem der Nodes an (mit Shift) über die gleichen Nodes eine zweite Linie zu zeichnen.
Die wichtigsten Attribute sind height und building:min_level und building:part=yes.
vgl. auch hier: http://wiki.osm.org/wiki/DE:Simple_3D_Buildings

Edit: Müssen die Nodes anschließend noch mit Shift-J getrennt werden?

Hallo

Aber lieber jetzt schon alles in 3D eintragen?

Und auf alle Fälle die Vorschau nutzen vor dem Hochladen
Das geht gut.
siehe josm basic editieren.
http://wiki.openstreetmap.org/wiki/DE:J … _eintragen

Aber lieber jetzt schon alles in 3D eintragen?

Würde ich sagen.
Selbst wenn wir in Zukunft Was ergänzen, werden wir auf dem Grundgerüßst von Simple 3D Buildings aufbauen. So dass die Arbeit sicherlich nicht umsonst ist.

@unixasket: Wie sollten die Maibäume denn aussehen? Da gibts ja doch wohl unterschiedliche regionale Varianten. Kann man noch nicht taggen, oder?

Den Turm bekommst du als building:part mit min:height und roof:shape=onion hin. Fürs Hauptdach reicht Simple 3D Buildings leider (noch) nicht, aber du könntest dort mit Firstlinien arbeiten.

Balkone sind leider auch noch nicht im Sortiment. Gibt noch viel zu tun. 😉

Win32netsky wrote:

siehe josm basic editieren.
http://wiki.openstreetmap.org/wiki/DE:J … _eintragen

Beim Überfliegen richtig, aber ist das "basic editing"-Tutorial die richtige Wikiseite dafür? Ich freu mich ja immer, wenn möglichst viele 3D-Daten eintragen, nur ist es wohl doch eher ein Fortgeschrittenen-Thema. Was meinen denn anderen dazu?

Tordanik wrote:

Beim Überfliegen richtig, aber ist das "basic editing"-Tutorial die richtige Wikiseite dafür? Ich freu mich ja immer, wenn möglichst viele 3D-Daten eintragen, nur ist es wohl doch eher ein Fortgeschrittenen-Thema. Was meinen denn anderen dazu?

+1

Tordanik wrote:

Win32netsky wrote:

siehe josm basic editieren.
http://wiki.openstreetmap.org/wiki/DE:J … _eintragen

Beim Überfliegen richtig, aber ist das "basic editing"-Tutorial die richtige Wikiseite dafür? Ich freu mich ja immer, wenn möglichst viele 3D-Daten eintragen, nur ist es wohl doch eher ein Fortgeschrittenen-Thema. Was meinen denn anderen dazu?

Größtenteils nicht. Dinge wie building:levels/building:colour oder roof:shape/roof:height/roof:colour passen durchaus noch zu Basic Editing. Anderes wie Building-Parts roof:ridge/roof:edge ist eher für Fortgeschrittene interessant.

Edbert (EvanE)

Tordanik wrote:

@unixasket: Wie sollten die Maibäume denn aussehen? Da gibts ja doch wohl unterschiedliche regionale Varianten.

Naja, in Bayern sind sie immer weiß-blau geringelt und haben oben mehrere Ausleger mit Zunftwappen. Siehe:
http://commons.wikimedia.org/wiki/File: … aibaum.JPG
Das weiß-blau ist sicherlich typisch bayerisch, aber außerhalb Bayerns scheint die Maibaumtradition auch nicht sonderlich entwickelt zu sein. Es gibt ja sogar Regionen in Deutschland in denen Maibaum eine komplett andere Bedeutung hat, wie etwa in der Nordeifel, wo in der Nacht zum 1. Mai die jungen Männer ihrer Angebeteten einen Maibaum (meist eine kleine Birke) im Vorgarten aufstellen. Manchmal sind Maibäum auch in Bayern aus ungefärbten Holz:
http://www.berchtesgadener-land.com/med … llen-2.jpg
http://commons.wikimedia.org/wiki/File: … m_2008.jpg

Darstellung also vielleicht einfach als hoher Holzstab mit oben einem Aufsatz. Farbe läßt sich ja als Attribut angeben (aber wie gibt man bei colour 2 Farben an). An zusätzlichen Attributen fürs 3D Rendering braucht man wohl colour und height.

Tordanik wrote:

Kann man noch nicht taggen, oder?

Doch als man_made=maypole. Hier sind viele Maibäume so getaggt und es steht inzwischen auch im Wiki (http://wiki.openstreetmap.org/wiki/DE:How_to_map_a#M, nur defacto, als nicht approved), aber ich kenne noch keine Karte die das auch rendert.

Gruß
unixasket

Generell wegen 2 Farben: Wie wäre es so etwas wie colour:stripes=(2. Farbwert) einzuführen (colour=* definiert dann die Hauptfarbe). Dann könnte man zum Beispiel auch colour:diamond (für Karo/Raute), colour:squares (für Quadrate), colour:dots (für Punkte), etc. machen um 2-farbige Muster darzustellen. Ich weiß ja nicht ob sonst noch wo Bedarf an der Darstellung 2-farbiger Muster außer bei Maibäumen besteht, aber damit müßten sich alle derartigen Fälle abdecken lassen (eventuell noch so etwas wie colour:dots:size=* dazu).

Gruß
unixasket

Generell sind 2 Farben ok, jedoch außer Maibaum nicht allzu oft zu finden. Ein Gradient bei dem eine Farbe allmählich beginnt und andere verschwindet (streifenweise) findet man hingegen wahrscheinlich öfter.

Tordanik wrote:

Den Turm bekommst du als building:part mit min:height und roof:shape=onion hin. Fürs Hauptdach reicht Simple 3D Buildings leider (noch) nicht, aber du könntest dort mit Firstlinien arbeiten.

OK, danke, den Turm habe ich jetzt. Kann mal jemand nachsehen ob das Tagging jetzt so paßt:
http://www.openstreetmap.org/?lat=47.88 … 8&layers=M
Foto:
http://upload.wikimedia.org/wikipedia/c … pt2012.jpg

Gruß
unixasket

Auffälligkeiten:
- building und building:part kleben am selben Objekt.
- das untere Objekt ist 18m hoch, der Turm hat nur min_height=8m, paßt nicht zusammen
- Wozu für die Kirchlichenattribute ein eigener Node? Das kommt an das Objekt mit building=*
- Wikipedia + image fehlt
Schau dir dieses Beispiel an: http://wiki.osm.org/wiki/DE:Simple_3D_Buildings 🙂

... und achte auch auf:

reneman wrote:

- building und building:part kleben am selben Objekt.

Wo muß denn das building hin?

reneman wrote:

- das untere Objekt ist 18m hoch, der Turm hat nur min_height=8m, paßt nicht zusammen

Ich dachte height bezieht sich auf die Gesamthöhe. Gemeint ist: 8 m Gebäude plus 10 m Turm = 18 m (sind aber alles nur ganz grob geschätzte Werte und wenn ich mir das Foto noch mal ansehe müßte ich den Turm wohl kleiner machen).

reneman wrote:

- Wozu für die Kirchlichenattribute ein eigener Node? Das kommt an das Objekt mit building=*

Ist nicht von mir, ich hatte es einfach so wie es war stehen gelassen um die Historie nicht zu löschen.

reneman wrote:

- Wikipedia + image fehlt

Die Kirche hat keinen Wikipediaeintrag. Nicht mal Roggersdorf hat einen Wikipediaeintrag.

Gruß
unixasket

unixasket wrote:

Wo muß denn das building hin?

Soweit ich weiß, ist jedes building:part ein Objekt, ebenso wie building ein eigenes Objekt um alles ist.

unixasket wrote:

reneman wrote:

- das untere Objekt ist 18m hoch, der Turm hat nur min_height=8m, paßt nicht zusammen

Ich dachte height bezieht sich auf die Gesamthöhe. Gemeint ist: 8 m Gebäude plus 10 m Turm = 18 m (sind aber alles nur ganz grob geschätzte Werte und wenn ich mir das Foto noch mal ansehe müßte ich den Turm wohl kleiner machen).

height = Gesamthöhe am Objekt "building"
ein Objekt building:part braucht eine eigene (i.d.r. abweichende) Höhe

unixasket wrote:

reneman wrote:

- Wozu für die Kirchlichenattribute ein eigener Node? Das kommt an das Objekt mit building=*

Ist nicht von mir, ich hatte es einfach so wie es war stehen gelassen um die Historie nicht zu löschen.

Man hätte den Node als einen der Ecknodes verwenden können, dann bleibt er erhalten. 😉

unixasket wrote:

reneman wrote:

- Wikipedia + image fehlt

Die Kirche hat keinen Wikipediaeintrag. Nicht mal Roggersdorf hat einen Wikipediaeintrag.

Auf ein eigenes Wikipedialemma hab ich jetzt nicht geprüft, du hattest aber ein Bild von Wikimedia angegeben. Welches in image verwendet werden kann.

Wikipedia:

Katholische Filialkirche, im Kern romanisch, um 1200. Anfang 18. Jahrhundert barockisiert. Im Friedhof barockes schmiedeeisernes Grabkreuz. Roggersdorfer Straße 112

addr:postcode=83607
addr:street=Roggersdorfer␣Straße
addr:housenumber=112
image=File:SanktMargarethaHolzkirchenOrtsteilRoggersdorfimSept2012.jpg
wikipedia=de:Liste␣der␣Baudenkmäler␣in␣Holzkirchen␣(Oberbayern)#Roggersdorf
start_date=~C12
name=St.␣Margaretha

Name bitte prüfen! <> N676010627 St. Margaret
PS: denomination=catholic sollte ebenfalls geprüft werden (<> roman_catholic)
Soviel zum kleinen Ausflug der "normalen" Attribute einer Kirche... 😉

Ich will jetzt auch mal mit 3D anfangen und habe gleich 'ne Frage:
Wie mache ich das bei einer offenen Reithalle, die keine Seitenwände hat, also nur aus einem Dach besteht. Den Reitplatz selbst unter dem Dach will ich als pitch=equestrian auf layer=0 (ohne layer-tag) setzen. Darüber muss dann das Dach "schweben". Geht das mit min_height ohne building:levels?

hurdygurdyman wrote:

Ich will jetzt auch mal mit 3D anfangen und habe gleich 'ne Frage:
Wie mache ich das bei einer offenen Reithalle, die keine Seitenwände hat, also nur aus einem Dach besteht. Den Reitplatz selbst unter dem Dach will ich als pitch=equestrian auf layer=0 (ohne layer-tag) setzen. Darüber muss dann das Dach "schweben". Geht das mit min_height ohne building:levels?

Ja das geht mit min_height. Du solltest aber das Dach mit roof:shape=*, roof:colour=* und vor allem roof:height=* passend beschreiben. Was zur Zeit nicht geht, ist die Säulen, die das Dach tragen, für 3D zu beschreiben. Da wird erst dran gearbeitet.

Edbert (EvanE)

Wieso? Das geht doch mit building-parts. Kreis zeichnen, height angeben, fertig.

things-change wrote:

Wieso? Das geht doch mit building-parts. Kreis zeichnen, height angeben, fertig.

Kleine Kreise für Säulen, je Säule einer... korrekt?
Und statt einem Kreis nur einen Node zu setzen, würde nicht funktionieren?

EvanE wrote:

...
Ja das geht mit min_height. Du solltest aber das Dach mit roof:shape=*, roof:colour=* und vor allem roof:height=* passend beschreiben. Was zur Zeit nicht geht, ist die Säulen, die das Dach tragen, für 3D zu beschreiben. Da wird erst dran gearbeitet.
...
Edbert (EvanE)

Alles klar. Danke.
Die von dir genannten roof:*=* waren mir klar und werden dazugepackt. Die "Säulen" lasse ich erst mal weg. Das mit den Kreisen als building-parts würde sowieso nicht passen, da Holzbinder zum Einsatz kamen.

reneman wrote:

things-change wrote:

Wieso? Das geht doch mit building-parts. Kreis zeichnen, height angeben, fertig.

Kleine Kreise für Säulen, je Säule einer... korrekt?
Und statt einem Kreis nur einen Node zu setzen, würde nicht funktionieren?

Genau. Einfach die Draufsicht zeichnen. Das Schema ist zwar bisher recht einfach gehalten, allerdings kann man alles darstellen, was von der Seitansicht sich nicht verjüngt, rund, konisch... ist.

Du kannst ja auch, wenn du viel Zeit hast, Treppen modellieren...
Allerdings ist das mit JOSM sehr fummelig, da es für geometrische Modellierungen ursprünglich nicht gemacht ist.

Einen Node für eine Säule und den Durchmesser als Tag, das ist (leider) nicht möglich

Ich verstehe immer noch nicht, wie man mit 2 Ways übereinander im Editor umgeht. Wenn ich eine 2. Way direkt über die erste Fläche zeichne, geht das zwar, aber danach kann ich nicht mehr den anderen Way auswählen. Wie kann ich die Auswahl zwischen 2 Ways die genau übereinander sind umschalten, damit beide Bearbeitbar bleiben (in JOSM)?

Gruß
unixasket

Mittlere Maustaste gedrückt halten 😉

Mittlere Maustaste, dann Strg gedrückt halten und dann mit der Maus den gewollten Weg im Menü auswählen.

unixasket wrote:

Ich verstehe immer noch nicht, wie man mit 2 Ways übereinander im Editor umgeht. Wenn ich eine 2. Way direkt über die erste Fläche zeichne, geht das zwar, aber danach kann ich nicht mehr den anderen Way auswählen. Wie kann ich die Auswahl zwischen 2 Ways die genau übereinander sind umschalten, damit beide Bearbeitbar bleiben (in JOSM)?

Gruß
unixasket

mausrad drücken und festhalten. eventuell mit strg zusammen.

Gruss
walter

Ich kann dir nur sagen, wie es in Potlatch2 funktioniert.
Einen der Nodes anklicken und dann mit der #-Taste durch die Objekte wechseln,
die am ausgewählten Node verfügbar sind.

errt wrote:

Mittlere Maustaste gedrückt halten 😉

Super, danke, das hatte mir gefehlt.

Gruß
unixasket

unixasket wrote:

Ich verstehe immer noch nicht, wie man mit 2 Ways übereinander im Editor umgeht. Wenn ich eine 2. Way direkt über die erste Fläche zeichne, geht das zwar, aber danach kann ich nicht mehr den anderen Way auswählen. Wie kann ich die Auswahl zwischen 2 Ways die genau übereinander sind umschalten, damit beide Bearbeitbar bleiben (in JOSM)?

Hallo unixasket

Einfach mit ALT-Klick zwischen den verschiedenen Wegen und ggfs. Relationen umschalten.
Die andere Möglichkeit in JOSM ist die mittlere Maustaste, sofeern man eine hat.

Edbert (EvanE)

Hallo
Wechseln der Hausebenen

AltGr-Taste gedrückt halten und mit der linken Maustaste auf die jeweilige Linie klicken.
der Markierungsrahmen ändert sich (sofern mehr Linien dazu gehören) auch die Werte im Fenster rechts ändern sich.

Wolltest Du das wissen?

Eventuell hilft josm basic
Glaubenshaus ( Kirche der letzen der heiligen Tage )
als Vorlage
Vorschau:
http://wiki.openstreetmap.org/wiki/File:Haus3D-7.png

Ich habe Zeit und entwerfe noch weitere Vorlagen (als Beispiele)

Hab mich mal an unserer Kirche versucht mit Brückenelement hoch in den Türmen
und daneben unser Rathaus
Ansicht
http://ubuntuone.com/1NLZ3VgIQJcsEe5vGspmQt

hier mal unser Wohngebiet, da haben wir Häuser mit Metall eingefassten Glaskuppl Dächern und Häuser mit Gauben
Ich finde das ist ganz gut geworden.
Ansicht:
http://ubuntuone.com/3GMDm2L5yXJadMczdhzvqH

Beste Grüße

GRATULIERE!
Schöne Beispiele!
Mach´s weiter so!

Marek

Hallo
schön das es jemandem gefällt.

Wir haben auch Gebäude mit 2 verschiedenen Gauben.
Und mal eine 3D Straßenlampe
Ansicht:
http://ubuntuone.com/5Zbsjnt5Z9kZ3Y3Ef83AuB

Hier ist Support für OSM2World unter Ubuntu
wem das was nützt.
ist aber noch nicht freigegeben für das Wiki, liegt noch in der Baustelle
http://wiki.ubuntuusers.de/Baustelle/OSM2World

Meine Karte ist jetzt schon an den neuen Standard angepasst.
Die Hausnummern von building=entrance werden auf dem Display angezeigt.

Beste Grüße

Unterstützt Ihr eigentlich schon street:area=value?

marek kleciak wrote:

Unterstützt Ihr eigentlich schon street:area=value?

Für was ist das ? Was sollte das bewirken?
Gruß

osm2world geht die gleiche Entwicklung durch, die schon viele Hersteller der Stadtmodelle in 3D gemacht haben:
Früher oder später stellt man fest, dass die Gebäude sehr schön aussehen. Bäume, Laternen, Bänke, Zäune, Brücken etc etc machen diese Modelle noch hübscher. Früher oder später fällt einem ein, dass die Modelle beschissen aussehen, weil das in diesen bereichen erreichte Detailreichtum sich mit der Strassendarstellung beißt.
Diese wird erreicht, indem man eine Breite als Multiplikator von der Anzahl der Spuren nimmt. Dies ist aber nicht realistisch genug.

Was hat man also versucht: Cool, wir kaufen Satellitenbilder (WIR in OSM dürfen es nicht...) Ergebnis: Noch mehr beschissen: Satellitenbild und Gebäudemodelle passen oft nicht zusammen, auflösung der Texturen sowieso.
Der einzig gute Auswqeg den testsweise die Firma Zenrin aus Japan gemacht hat, war die Erfassung der Strassen als Flächen, wobei sie auch nicht gerade sooo detailliert waren.

Schaut mal her zum testen der Areas: http://osm.org/go/0JBK8x9VB--
Grüße,
Marek

ich weiß nicht so recht warum dort nur Flächen für die Straßen eingeszeichnet sind. Für die Fuß und Radwege habe ich sowas nicht gesehen.
Außerdem denke ich das win32netsky auch eher beschreibt was schon heute mit OSM2World möglich ist.

ich weiß nicht so recht warum dort nur Flächen für die Straßen eingeszeichnet sind

Es ist ja der Anfang. 😉 Die Fuß und Radwege sollen hinzu kommen.

Eigentlich muß die Frage nach street:area=<value> direkt an Tordanik gestellt werden.

Stimmt.

Hallo
Ja ich mache / beschreibe das was geht im Moment

Besagter Link zeigt alles asphaltierte Wege?
In meinem Wohngebiet ist alles Plaster (auch so gezeigt)
Gruß

Und nochmal: das machst Du wunderbar! Vielen Dank!

Marek

Hallo
Habt Ihr das gemeint?

Bei mir ist das so
Fußweg zum Haus
hi. path material pflaster
http://ubuntuone.com/69xySNnwDXcvNE4xUEoCZ3
Gruß

Genau. Ist es eine Fläche oder way mit width=<value>?

Hallo

Das ist ein Fußweg (Weg)

Hier mal die Eintragung
"
highway=footway
lit=yes
motor_vehicle=no
surface=paving_stones

"
Ab morgen eine WO im Urlaub
Gruß

marek kleciak wrote:

Eigentlich muß die Frage nach street:area=<value> direkt an Tordanik gestellt werden.

Der liest hier mit. 😉

Ich würde mir durchaus wünschen, in OSM2World Straßenflächen zu unterstützen - meines Wissens ist derzeit area:highway=<value> das Tag der Wahl. Derzeit ist dafür allerdings noch keine Unterstützung vorhanden, weil die Programmierung recht komplex ist.

Win32netsky: erhol´Dich gut 😎
Tordanik: Schön, dass Du´s liest 😉 Ich dachte, area:highway=<value> bzw. street:area=<value> kann genau so betrachtet werden wie die anderen landuse=<value>
Die habt Ihr schon, oder?

Grüße,
Marek

Puuh, sieht das in Mapnik blöd aus, da er zwar nicht die Fläche aber den Namen der Fläche malt.

Richtig. Daher muss man erst mal ohne Namen auskommen. Wer könnte eigentlich diese Regel in Mapnik berücksichtigen. Wer hat die Hand drauf?

Grüße,
Marek

http://wiki.openstreetmap.org/wiki/DE:M … enschaften

Ich meinte eher eine Person. Wohl Artem Pavlenko, oder?

marek kleciak wrote:

Ich meinte eher eine Person. Wohl Artem Pavlenko, oder?

Die Entwickler von Mapnik haben nichts mit dem "Mapnik" Style von OSM zu tun. Änderungen am Style werden wieder möglich so bald alles auf die Carto Version des Styles umgestellt ist (Zeitraum RSN).

Simon

marek kleciak wrote:

Tordanik: Schön, dass Du´s liest 😉 Ich dachte, area:highway=<value> bzw. street:area=<value> kann genau so betrachtet werden wie die anderen landuse=<value>
Die habt Ihr schon, oder?

Einheitlich gefärbte oder texturierte Flächen haben wir schon, ja. Aber bei Straßenflächen will man ja etwas anderes: Dort sollen die Fahrspuren und sonstige aus den Tags am Way abgeleitete, richtungsabhängige Informationen weiterhin sichtbar bleiben - nur muss die Straße als Ganzes ihre Form verändern. Die Lösung dafür muss also gesondert programmiert werden.

SimonPoole wrote:

Änderungen am Style werden wieder möglich so bald alles auf die Carto Version des Styles umgestellt ist (Zeitraum RSN).

Hallo Simon

Die Änderungsblockade durch den Wechsel zu Carto dauert ja schon mehrere Monate.
Ist es absehbar, wie lange die noch dauert? Oder was bedeutet "Zeitraum RSN"?

Edbert (EvanE)

Hallo Tordanik,
danke für Deine Antwort. Verstehe.
Möchte man die Abgeleitete Informationen darstellen, ist das natürlich Zeitaufwand.
Wie wäre es aber vorläufig mit der Darstellung der Flächen ohne Anzeige der Zusatzinformation?
Bei der momentan maximaler Zoomstufe von http://maps.osm2world.org/ sind sie nicht sehr gut erkennbar.
Und für die User wäre das ein guter Grund, um die Strassengeometrie zu erfassen weil man endlich eine möglichkeit hätte, das Endergebnis zu sehen.

Viele Grüße,
Marek

EvanE wrote:

Oder was bedeutet "Zeitraum RSN"?

http://en.wiktionary.org/wiki/RSN

Wer arbeitet an der Carto Version des Styles?
Grüße,
Marek

errt wrote:

EvanE wrote:

Oder was bedeutet "Zeitraum RSN"?

http://en.wiktionary.org/wiki/RSN

Ja danke.
Für alle, die nicht nachsehen mögen. RSN bedeutet Real Soon Now (Sehr Bald Jetzt).
Das wird gerne auch skeptisch verwendet (z.B. wenn es halt fertig ist).

Letztlich kann man daraus keine wirkliche Information über die voraussichtliche Zeit entnehmen.
Höchstens die Hoffnung, dass man es demnächst in den Griff bekommt.

Edbert (Evan)

marek kleciak wrote:

Wer arbeitet an der Carto Version des Styles?
...

Andy Allan hat die Style Sheets aus dem Mapnik .xml Format "übersetzt". Im Augenblick geht es aber eher um die operationelle Integration. Siehe auch http://wiki.osmfoundation.org/wiki/Work … 2013-04-29

Ich würde doch stark empfehlen wenn man an der Sache wirklich interessiert ist, die dev Mailinglist zu abonnieren und die EWG Minutes zu lesen, wenn nicht sogar bei der EWG mitzumachen.

Simon

unixasket 2013-04-30 12:21:01 wrote:

Tordanik wrote:

Den Turm bekommst du als building:part mit min:height und roof:shape=onion hin. Fürs Hauptdach reicht Simple 3D Buildings leider (noch) nicht, aber du könntest dort mit Firstlinien arbeiten.

OK, danke, den Turm habe ich jetzt. Kann mal jemand nachsehen ob das Tagging jetzt so paßt:
http://www.openstreetmap.org/?lat=47.88 … 8&layers=M
Foto: http://upload.wikimedia.org/wikipedia/c … pt2012.jpg

Gruß unixasket

Sorry, dass ich diesen Beitrag noch einmal hervor hole, aber ich habe nun extra 14 Tage gewartet, bis die Kirche gestern Nachmittag neu gerendert wurde:
Wie das folgende Bild zeigt, paßt es nicht (Kirche liegt leider auf 2 Kacheln...).

Den die Werte für die Höhe sind falsch angegeben.

reneman 2013-04-30 12:32:09 wrote:

- das untere Objekt ist 18m hoch, der Turm hat nur min_height=8m, paßt nicht zusammen

Habe ich auch grade gesehen. Ich habe die Höhe (und auch die Dachfarbe) korrigiert. Dumm, das man das Ergebnis wieder erst in 2 Wochen sieht.

Gruß
unixasket

Es gibt die Möglichkeit einer lokalen Vorschau mit der hier zur Verfügung gestellten Software: http://osm2world.org/download/

Edit: Es gibt auch noch roof:height 🙂

Ich hab euch mal das Kirchlein neu gerendert und mir die Daten dazu angeschaut.
Ich würde das min_height entfernen, der Turm beginnt ja nicht in der Luft sondern am Boden.

reneman wrote:

Edit: Es gibt auch noch roof:height 🙂

Genau 🙂

(Anmerkung: Ist aber Teil der Höhe, also: height == Gebäudehöhe + roof:height)

reneman wrote:

Es gibt die Möglichkeit einer lokalen Vorschau mit der hier zur Verfügung gestellten Software: http://osm2world.org/download/

Das funktioniert auf meinem OpenBSD System nicht, obwohl es ein Javaprogramm ist und ich Java installiert habe. Beim aufruf von osm2world.sh kommt erst mal:

./osm2world.sh:␣bad␣interpreter:␣/bin/bash:␣no␣such␣file␣or␣directory

. OK, das ist soweit klar, also erst mal die Erste Zeile im Script auf

#!/bin/sh

geändert. Nächster Aufruf:

No␣parameters,␣running␣graphical␣interface.
If␣you␣want␣to␣use␣the␣command␣line,␣use␣the␣--help␣parameter␣for␣a␣list␣of␣available␣parameters.
Exception␣in␣thread␣"main"␣java.lang.UnsatisfiedLinkError:␣/home/rene/osm2world/lib/jogl/linux-i586/libgluegen-rt.so:␣File␣not␣an␣ELF␣object␣(Possible␣cause:␣architecture␣word␣width␣mismatch)
at␣java.lang.ClassLoader$NativeLibrary.load(Native␣Method)
at␣java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1974)
at␣java.lang.ClassLoader.loadLibrary(ClassLoader.java:1857)
at␣java.lang.Runtime.loadLibrary0(Runtime.java:845)
at␣java.lang.System.loadLibrary(System.java:1084)
at␣com.sun.gluegen.runtime.NativeLibLoader.loadLibraryInternal(NativeLibLoader.java:102)
at␣com.sun.gluegen.runtime.NativeLibLoader.access$000(NativeLibLoader.java:51)
at␣com.sun.gluegen.runtime.NativeLibLoader$1.run(NativeLibLoader.java:70)
at␣java.security.AccessController.doPrivileged(Native␣Method)
at␣com.sun.gluegen.runtime.NativeLibLoader.loadGlueGenRT(NativeLibLoader.java:68)
at␣com.sun.gluegen.runtime.NativeLibrary.ensureNativeLibLoaded(NativeLibrary.java:399)
at␣com.sun.gluegen.runtime.NativeLibrary.open(NativeLibrary.java:163)
at␣com.sun.gluegen.runtime.NativeLibrary.open(NativeLibrary.java:129)
at␣com.sun.opengl.impl.x11.DRIHack.begin(DRIHack.java:109)
at␣com.sun.opengl.impl.x11.X11GLDrawableFactory.<clinit>(X11GLDrawableFactory.java:99)
at␣java.lang.Class.forName0(Native␣Method)
at␣java.lang.Class.forName(Class.java:186)
at␣javax.media.opengl.GLDrawableFactory.getFactory(GLDrawableFactory.java:111)
at␣javax.media.opengl.GLCanvas.chooseGraphicsConfiguration(GLCanvas.java:520)
at␣javax.media.opengl.GLCanvas.<init>(GLCanvas.java:131)
at␣javax.media.opengl.GLCanvas.<init>(GLCanvas.java:90)
at␣org.osm2world.viewer.view.ViewerGLCanvas.<init>(Unknown␣Source)
at␣org.osm2world.viewer.view.ViewerFrame.<init>(Unknown␣Source)
at␣org.osm2world.console.OSM2World.executeArgumentsGroup(Unknown␣Source)
at␣org.osm2world.console.OSM2World.main(Unknown␣Source)

Da scheint es Teile zu geben die nur für Linux kompiliert wurden.

Gruß
unixasket

unixasket wrote:

Habe ich auch grade gesehen. Ich habe die Höhe (und auch die Dachfarbe) korrigiert. Dumm, das man das Ergebnis wieder erst in 2 Wochen sieht.

Gruß
unixasket

Dann hast Du aber Glück meine Kacheln sind zum Teil vom 23.04! :-(

unixasket wrote:

Da scheint es Teile zu geben die nur für Linux kompiliert wurden.

Ja, das ist korrekt. Das Programm an sich ist zwar in Java geschrieben und du könntest auf deinem System auch z.B. die Exportfunktionalität nach .obj oder .pov nutzen. Für hardwarebeschleunigtes Rendering mit OpenGL werden allerdings die nativ kompilierten JOGL-Bibliotheken verwendet.

Im Verzeichnis lib/jogl/ liegen solche kompilierten Versionen für Linux, Windows und Mac OS. Ich habe sie nicht selber übersetzt, sondern die Builds von der JOGL-Website verwendet. Dort stehen außer den genannten noch Versionen für Android (auf ARM) und Solaris zur Verfügung, aber soweit ich sehe leider keine für OpenBSD. Ob es prinzipielle Probleme dabei gäbe, JOGL für OpenBSD zu kompilieren, oder ob sich einfach keiner darum kümmert, weiß ich nicht.

Ach ja, ist der Output da zufällig von 0.1.9? Das beschriebene Problem sollte auch aktuelle Versionen betreffen, aber wenn du schon experimentierst wären mir Erkenntnisse zur aktuellen Version natürlich lieber. 😉

Gibt es derzeit Probleme? Beim Durchlauf gestern Abend sind hier alle Grasflächen auf der Slippy Map schwarz gerendert worden.

BBO wrote:

Gibt es derzeit Probleme? Beim Durchlauf gestern Abend sind hier alle Grasflächen auf der Slippy Map schwarz gerendert worden.

Ups, du hast recht. Müssen wir mal nachforschen.

Ich vermute einen Zusammenhang mit einem Patch, der weitere Tags als "Grasfläche" erkennt.

Hallo

wieder zurück aus dem Urlaub.

Hier mal support zum voransehen der Änderungen.
Unter Ubuntu 13.04
http://wiki.ubuntuusers.de/Baustelle/OSM2World

Jetzt ist schon ein teil drin
Hier mal ein Ausblick:
Mein Wohngebiet
http://maps.osm2world.org/?h=128&view=N … ers=B0TTFF

Hier ist mal die Kirche und Rathaus:
http://maps.osm2world.org/?h=128&view=N … ers=B0TTFF

Das zoomen geht aber nicht so weit ran ?

Gruß

Tordanik wrote:

BBO wrote:

Gibt es derzeit Probleme? Beim Durchlauf gestern Abend sind hier alle Grasflächen auf der Slippy Map schwarz gerendert worden.

Ups, du hast recht. Müssen wir mal nachforschen.

Ich vermute einen Zusammenhang mit einem Patch, der weitere Tags als "Grasfläche" erkennt.

Als Erklärung hierzu vielleicht noch den Link auf issue 58: Es handelt sich um ein Problem beim Grafikkartentreiber.

Der Patch führt nur dazu, dass es diesmal mehr Flächen betroffen hat, ist aber nicht direkt verantwortlich.

http://maps.osm2world.org/?zoom=18&lat= … ers=B0TTFF

Ein 3D Versuch :-)

http://www.ludwich.de/iweb/osm/OSM4.html
http://www.ludwich.de/iweb/osm/OSM5.html
http://www.ludwich.de/iweb/osm/OSM6.html

Gruß Ludwich

Gut gemacht!
Eigentlich brauchen wir einen solchen Dienst auch außerhalb von BRD damit man die Leute besser aktivieren kann...

Viele Grüße!
Marek

chris66 wrote:

Schade, ich hatte seinerzeit die beiden Knoten des Firstes mit building:roof:ridge = yes markiert.
Inklusive aller Varianten (roof:ridge / building:roof:ridge auf Node oder Kante) immerhin 1300 mal in Verwendung.

Zum Vergleich: roof:slope:direction gibt es 35 mal.

Bei OSM2World sollte es funktionieren den First eines Schrägdachs mit einem roof:ridge way zu markieren. An nodes wird der Tag nicht interpretiert.

... oh ein bischen späte Antwort 🙂

Danke, aber ich nutze mittlerweile die roof:slope:direction dafür.
Das wird in beiden großen 3D Renderen ausgewertet. (Bis vor kurzem allerdings seitenverkehrt, weiss
nicht ob Kenzi das mittlerweile behoben hat).

Hallo
Die Wo wieder frei.

"
@Ludwich
Das sieht gut aus:
Propyläen München
"

Kann man das Zoom Level noch anpassen ?

so bis hier:
z.B.
http://wiki.openstreetmap.org/wiki/File:Haus3D-7.png
Gruß

chris66 wrote:

Danke, aber ich nutze mittlerweile die roof:slope:direction dafür.
Das wird in beiden großen 3D Renderen ausgewertet. (Bis vor kurzem allerdings seitenverkehrt, weiss
nicht ob Kenzi das mittlerweile behoben hat).

ich wollte grade meine Änderung an Notre Dame dahingehend korrigieren und gesehen dass ich auch nur skillion ohne extra ridge verwendet habe. roof:slope:direction ist gleich, aber scheinbar wird 'pyramidal' von OSM2World und kendzi3D verschieden interpretiert.

http://city.informatik.uni-bremen.de/~j … ndzi3d.png
http://city.informatik.uni-bremen.de/~j … redame.png

j3d wrote:

scheinbar wird 'pyramidal' von OSM2World und kendzi3D verschieden interpretiert.

Richtig beobachtet, da hatten wir in diesem Thread eine Definitionslücke in Simple 3D Buildings gefunden, die zu unterschiedlichen Interpretationen geführt hat.

ich versuche gerade eine Kirche zu erstellen. Eigentlich eine ganz normale 08/15 Kirche wie diese hier http://binged.it/1aOdUrB Auf der einen Seite der Kirchturm und am anderen Ende diese -von oben gesehene- halbe Rundung. Ich kriege diese halbe Rundung nicht hin. Bei 3dr weiß ich nicht, was 1st und 2nd height/length sein sollen und bei Simple 3d finde ich keine Dachform. Gibts irgendwo ein Beispiel, wo jemand sowas modelliert hat? Danke

SunCobalt wrote:

ich versuche gerade eine Kirche zu erstellen. Eigentlich eine ganz normale 08/15 Kirche wie diese hier http://binged.it/1aOdUrB Auf der einen Seite der Kirchturm und am anderen Ende diese -von oben gesehene- halbe Rundung. Ich kriege diese halbe Rundung nicht hin. Bei 3dr weiß ich nicht, was 1st und 2nd height/length sein sollen und bei Simple 3d finde ich keine Dachform. Gibts irgendwo ein Beispiel, wo jemand sowas modelliert hat? Danke

Probier mal roof:ridge plus roof:edge=yes.
Beispiel: Diese Kirche (ca. in der Mitte).

PS: Das gehört meiner Meinung nach als Ergänzung zu "Simple 3D Buildings".

Edbert (EvanE)

Die ist aber sehr klein für eine Kirche

@Sun Cobalt
Hier hast Du verschiedene Tests
http://wiki.openstreetmap.org/wiki/DE:J … ic_editing

Wenn Du hier mal schaust: Eventuell hilft es auch, mein Bastel Wohngebiet.
http://maps.osm2world.org/?h=128&view=N … ers=B0TTFF

Eventuell kannst Du was davon umsetzen.
Hier mal unser Rathaus und Markt Kirche
http://maps.osm2world.org/?h=128&view=W … ers=B0FFFF

Habe heute meine erste Garmin 3D Karte gemacht
Als erster Versuch ist die Gestaltung des Baumes.
Ist ganz gut geworden.
http://ubuntuone.com/5g2NulszxMCCJ3JQdy25dj
Leider lässt Typ Wiz nur 32 Pixel zu, in der Vorverarbeitung? Gibt es eine neuere Version?

Wie ist es mit dem Zoom Level geht es weiter ran an die Gebäude?

Beste Grüße

Hat jemand eine Ahnung, wie mann/frau solche Dächer modelliert?
http://www.lahr.de/sixcms/media.php/5/t … .41251.jpg

hurdygurdyman wrote:

Hat jemand eine Ahnung, wie mann/frau solche Dächer modelliert?
http://www.lahr.de/sixcms/media.php/5/t … .41251.jpg

Ist es ein Schrägdach (das Bild ist nicht gerade Super-Ultra-HD)?

Wenn ja:
roof:shape=skillion
roof:slope:direction=<Grad> (die Himmelsrichtung, in der das Dach sich neigt; 180 bedeutet also, dass die Nordkante am höchsten ist und die Südkante am niedrigsten)
roof:height=<Maximale Dachhöhe in m>

MetiorErgoSum wrote:

hurdygurdyman wrote:

Hat jemand eine Ahnung, wie mann/frau solche Dächer modelliert?
http://www.lahr.de/sixcms/media.php/5/t … .41251.jpg

Ist es ein Schrägdach (das Bild ist nicht gerade Super-Ultra-HD)?

Wenn ja:
roof:shape=skillion
roof:slope:direction=<Grad> (die Himmelsrichtung, in der das Dach sich neigt; 180 bedeutet also, dass die Nordkante am höchsten ist und die Südkante am niedrigsten)
roof:height=<Maximale Dachhöhe in m>

Sorry wegen des Bildes 🙁
Das Dach ist für mich ein Pultdach http://de.wikipedia.org/wiki/Pultdach und skillion scheint die Übersetzung zu sein. Das Gebäude und vergleichbare hier stehen etwas schräg zu den Himmelsrichtungen. Bei dem gezeigten Beispiel müsste ich dann wohl geschätzt so etwa 115 Grad angeben, weil das Dach grob Ostsüdost geneigt ist. http://www.openstreetmap.org/browse/way/51188957.
Aber die Wandmalerei lasse ich erst mal weg 🤔 😄
Danke mal MetiorErgoSum

MetiorErgoSum wrote:

hurdygurdyman wrote:

Hat jemand eine Ahnung, wie mann/frau solche Dächer modelliert?
http://www.lahr.de/sixcms/media.php/5/t … .41251.jpg

Ist es ein Schrägdach (...)?

Wenn ja:
roof:shape=skillion
roof:slope:direction=<Grad> (die Himmelsrichtung, in der das Dach sich neigt; ...)
roof:height=<Maximale Dachhöhe in m>

Man kann es sich auch einfacher machen, indem man das als roof:shape=gabled definiert und mit einer zusätzlichen Kante mittels roof:ridge=yes den First sehr nah an die eine Außenwand setzt. Durch das explizite Einzeichnen des Dachfirstes geht man allen Problemen mit *:direction aus dem Weg.

Eine sinnvolle Ergänzung wären noch roof:height und roof:colour (unabhängig von roof:shape)

Edbert (EvanE)

EvanE wrote:

Man kann es sich auch einfacher machen, indem man das als roof:shape=gabled definiert und mit einer zusätzlichen Kante mittels roof:ridge=yes den First sehr nah an die eine Außenwand setzt. Durch das explizite Einzeichnen des Dachfirstes geht man allen Problemen mit *:direction aus dem Weg.

Eine sinnvolle Ergänzung wären noch roof:height und roof:colour (unabhängig von roof:shape)

Edbert (EvanE)

Toll. Danke.
Habe dazu nichts in der Wiki gefunden. Kenne nur die Seite zu dem Thema http://wiki.openstreetmap.org/wiki/DE:S … _Buildings und da fehlen sowohl skillion als auch roof:ridge 🤔
Werten irgendwelche Renderer das auch schon aus?

P.S.: Fange gerade erst mit 3D-Modelling in OSM an 🙄

roof:shape=skillion und roof:direction werden von den populären Renderern unterstützt. Die genaue roof:direction bekommst du in JOSM in dem du temporär einen way entlang der Dachschräge anlegst (steht dann solange in der unteren Leiste im Fester). roof:ridge wird bisher nur von OSM2World unterstützt, also besser nur dann verwenden wenn die einfachen Tags nicht ausreichen.

hurdygurdyman wrote:

Das Gebäude und vergleichbare hier stehen etwas schräg zu den Himmelsrichtungen. Bei dem gezeigten Beispiel müsste ich dann wohl geschätzt so etwa 115 Grad angeben, weil das Dach grob Ostsüdost geneigt ist.

Wenn die Methode, die Tordanik in diesem Post beschrieben hat, noch angewendet wird, dann reicht es, wenn du die Richtung ungefähr angibst. Zumindest bei rechteckigen Häusern müsste der Renderer es selbst schaffen, die Dachneigung exakt auszurichten.

EvanE wrote:

Man kann es sich auch einfacher machen, indem man das als roof:shape=gabled definiert und mit einer zusätzlichen Kante mittels roof:ridge=yes den First sehr nah an die eine Außenwand setzt. Durch das explizite Einzeichnen des Dachfirstes geht man allen Problemen mit *:direction aus dem Weg.

Die Lösung finde ich nicht gut. roof:shape=gabled bedeutet, dass es sich um ein Satteldach handelt. Wesentliches Merkmal des Satteldaches ist nun mal, dass der Dachfirst sich in der Mitte befindet; vielleicht nicht immer exakt, aber zumindest vom Prinzip her. Ein solches Pultdach ist etwas anderes. Es wird nur durch die verschobene Firstlinie der Renderer ausgetrickst.

j3d wrote:

roof:shape=skillion und roof:direction werden von den populären Renderern unterstützt. Die genaue roof:direction bekommst du in JOSM in dem du temporär einen way entlang der Dachschräge anlegst (steht dann solange in der unteren Leiste im Fester). roof:ridge wird bisher nur von OSM2World unterstützt, also besser nur dann verwenden wenn die einfachen Tags nicht ausreichen.

Was ihr so alles wisst 😎
Ich denke, es wäre zur Verbreitung des 3D-Mappings förderlich, wenn das alles mal irgendwo auffindbar aufgeschrieben wäre, und hier eine Menge Fragen sparen.

Versuche es mal mit beiden Varianten. Ich habe hier mehrere Pultdach-Häuser.

hurdygurdyman wrote:

EvanE wrote:

Man kann es sich auch einfacher machen, indem man das als roof:shape=gabled definiert und mit einer zusätzlichen Kante mittels roof:ridge=yes den First sehr nah an die eine Außenwand setzt. Durch das explizite Einzeichnen des Dachfirstes geht man allen Problemen mit *:direction aus dem Weg.

Toll. Danke.
Habe dazu nichts in der Wiki gefunden. Kenne nur die Seite zu dem Thema http://wiki.openstreetmap.org/wiki/DE:S … _Buildings und da fehlen sowohl skillion als auch roof:ridge 🤔
Werten irgendwelche Renderer das auch schon aus?

P.S.: Fange gerade erst mit 3D-Modelling in OSM an 🙄

OSM2World wertet roof:ridge und roof:edge aus. (Siehe: User:Aschilli/ProposedRoofLines)

Meines Erachtens gehören beide dringend in die Simple 3D Buildings.
Eine explizite Linie ist meines Erachtens deutlich einfacher und verständlicher als das Rumgewürge mit Himmelsrichtungen für die Dachneigung. Schon bei einem einfachen Walmdach wäre das nicht mehr eindeutig.
Bei Gebäuden mit einer komplizierteren Form als einem Rechteck wird es zunehmend schwieriger eine allgemeingültige Dachneigung festzulegen. Siehe als Beispiel das Rheinauen Carré und die Kindertageseinrichtung in Bonn.

Edbert (EvanE)

Vote up http://wiki.openstreetmap.org/wiki/S3DB … for_S3DBv2 😉

Für den Renderer wären explizite roof und ridge bei komplizierteren Gebäuden wohl auch einfacher zu interpretieren. Allerdings ist das in vielen Fällen wesentlich schwieriger zu mappen solange es keinen Editor gibt der das Erstellen von Dachstrukturen unterstützt (e.g. mit Straight-Skeletons). Mein Versuch ein Dach mit verschiedenen Höhen zu modellieren war auch ein ziemliches rumgewurschte..
http://maps.osm2world.org/?h=128&view=N … 0599579548

Ganz zu schweigen von dem fein modellierter Dom,den mittlerweile jemand durch S3DB Tags ersetzt hat.. https://github.com/tordanik/OSM2World/pull/55

hurdygurdyman wrote:

j3d wrote:

roof:shape=skillion und roof:direction werden von den populären Renderern unterstützt. Die genaue roof:direction bekommst du in JOSM in dem du temporär einen way entlang der Dachschräge anlegst (steht dann solange in der unteren Leiste im Fester). roof:ridge wird bisher nur von OSM2World unterstützt, also besser nur dann verwenden wenn die einfachen Tags nicht ausreichen.

Mit roof:shape=skillion sieht es ganz gut aus. http://map.f4-group.com/#lon=7.8250178& … hi=-52.149 🙂
habe es mit building:part=yes sogar geschafft, die seitliche Verkleidung im Wandbereich schwarz zu bekommen. http://www.lahr.de/sixcms/media.php/5/t … 41251.jpg#
Fehlt bloß noch das rote Tor 🤔

Wow, was ist dass denn für ne coole neue Seite?
Kaum ist man im Urlaub bekommt man die ganzen Neuigkeiten nicht mehr mit. 😎

http://wiki.map.f4-group.com/wiki/Main_Page

Sogar Springbrunnen sind animiert. Staun.
http://map.f4-group.com/#lon=7.4430272& … phi=-2.099

Das ist schon cool visualisiert, die Art und Weise, wie sie sich der 3D Sache genähert haben, hat mir persönlich aber nicht so ganz gefallen. Anyway, nun haut das mit der S3DB-Interpretation ja einigermaßen hin und optisch macht das natürlich einiges her 🙂

!i! wrote:

Das ist schon cool visualisiert, die Art und Weise, wie sie sich der 3D Sache genähert haben, hat mir persönlich aber nicht so ganz gefallen. Anyway, nun haut das mit der S3DB-Interpretation ja einigermaßen hin und optisch macht das natürlich einiges her 🙂

Sowas http://map.f4-group.com/#lon=2.2940277& … .phi=5.443
sieht schon toll aus.
Wie machen die das?

hurdygurdyman wrote:

Wie machen die das?

F4 wiki wrote:

"Special" buildings

We're using a proprietary modeled building database (check the Eiffel Tower) transfered as a binary form.

They can be disabled using the "Buildings Customized By F4" button on top of the page.

Ist also eine Eigenentwicklung der französischen Spiele Firma.

Leider werden Dachkanten anscheinend nicht ausgewertet (roof:ridge).

Es gibt schon einige freie 3D Modelle:
http://www.greatbuildings.com/types/mod … odels.html

Ich würde für die Full 3DB vorschlagen, dass ein markantes, frei stehendes Bauwerk als link in die Karte eingebaut werden kann. Dann könnte man schon eine Vielzahl der freien 3D Modelle importieren..

Auch nicht schlecht und nur OSM, auch wenn building:part=* zur Geländemodellierung (unten rechts hellgrün)missbraucht wird 🤔
http://map.f4-group.com/#lon=11.4175154 … eta=79.624

Edit:
sogar Schornsteine und Kühltürme rauchen: http://map.f4-group.com/#lon=8.4365370& … eta=45.665

Beim rumgucken entdeckt:
Wie bekommt man die Kugel des Fernsehturms rund. Obere Hälfte mit dome wäre ja schon mal 'ne Annäherung.