<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div>On 121.10.2013 23:01, Martin Garbe wrote:<br>>> ...<br>
> Oha, das Rendering von OSM2World und der F4-Group bringt jetzt 2<br>
> unterschiedliche Ergebnisse.<br>
<br>
> Weiß einer was es bei F4-Group (siehe Link oben) mit dem Südöstlichen<br>
> Teil des Gebäude für ein Problem gibt? Der Teil des Gebäudes hat nur 2<br>
> Stockwerke und das steht im Polygon. Es ist auch als "Building:part=yes"<br>
> und in der building-Relation enthalten. Beim OSM2World funktioniert es.<br>
<br>
> Gruß<br>
> Martin<br><br></div>Yeap, kurz gesagt: weil der gesamte OSM-Aufbau des Südstadtklinikums noch immer nicht so ist, wie er eigentlich sein sollte.<br>Allerdings ist das Südstadtklinikum auch nicht so einfach ...<br>
</div>Aber der Reihe nach ...<br></div>1) Derzeit ist die Gebäudekontur (Gebäudeumriss und Innenhöfe) korrekt in einer multipolygon-relation verpackt.<br></div>2) Nicht gut ist es, dass dann wiederum alle Elemente aus 1) einzeln in der building-relation auftauchen - warum nicht die multipolygon-relation en bloc ?<br>
</div>3) Zusätzlich gibt es noch zwei weitere Fehler - siehe 'Kochrezept' Punkte a) und b) ...<br><br></div>Kochrezept für die Korrektur:<br></div>a) der nördliche Gebäudeteil mit 2 Etagen und den beiden Innenhöfen ist so zu modifizieren, dass nicht die multipolygon-relation mit den drei Elementen, sondern das Umriss-Element selbst die tags trägt - analog zum Gesamt-Gebäudeumriss mit seinen Innenhöfen<br>
</div><div> (diese beiden Innenhöfe müssen natürlich in beiden relations als role=inner auftauchen, damit sie auch aus beiden Definitionen ausgespart werden).<br>
</div>b) der östliche Gebäudeteil hat ein ähnliches Problem: der Innenhof ist zwar per multipolygon-relation an den Gebäudeumriss gekoppelt, nicht aber an die building:part-Definition mit den beiden Etagen. D.h. der Innenhof würde zwei-etagig überbaut werden. Also den Innenhof hier auch via multipolygon-relation als role=inner an das entsprechende building:part-Objekt dranhängen.<br>
</div>c) die building-relation am besten neu aufbauen:<br></div>Rein kommen da die Gebäudekontur als multipolygon aus 1) und die beiden multipolygon-relations aus a) und b) sowie alle building:part-Objekte, dienoch nicht in 1), a) oder b) 'verarbeitet' sind.<br>
</div>d) so mache ich es zumindest: Kontrolle mit <a href="http://osm2world.org/download/" target="_blank">OSM2World.jar</a> (lokal auf dem PC starten) und der zuvor entsprechend bearbeiteten und lokal (!) abgespeicherten osm-Datei. Bei mir schaut das nach Änderung entsprechend a) bis c) prima aus !<br>
<br>
</div>Dass OSM2World und F4 nun voneinander abweichen, liegt wohl daran, dass sie offenbar unterschiedlich auf die beschriebenen Fehler reagieren. Warum - wissen nur die Götter - so sie beide Quellcodes kennen und auch lesen wollen ;-)<br>
</div>Bin mal gespannt, ob F4 nach Upload der beschriebenen Korrektur das gleiche Bild zeigt wie OSM2World, denn das F4-Rendering kann man meines Wissens nach nicht rein lokal laufen lassen - hier hilft nur das Warten auf die Aktualisierung der F4-Daten und hoffen ...<br>
<div><div><div><br>Jetzt gibt es drei Möglichkeiten:<br></div><div>01) Du greifst wieder selbst in die Tasten ...<br>
</div>
<div>02) ich sende Dir an Deine Uni-email einen Screenshot vom Korrekturergebnis nach lokalem Rendering bei mir und Du greifst selbst in die Tasten; nur vergleichst Du vor dem Upload Dein lokales Rendering mit dem Screenshot<br>
</div><div>03) ich uploade die Änderungen, die ich ja bereits lokal auf Platte habe, selbst und Du schaust Dir die Änderungen dann direkt in den OSM-Daten an (- die für uns beide zeitsparende Lösung ...)<br><br></div><div>
Wie wollen wir verfahren ??<br></div><div>
Viele Grüße<br></div><div>Rainer<br></div><div><br></div></div></div></div>