[OSM in MV] Band 57, Eintrag 1; Südstadtklinikum und Radiologie-Gebäude in Rostock

[Martin Garbe]

On 22.10.2013 20:46, Rainer Paulke wrote:
> On 121.10.2013 23:01, Martin Garbe wrote:
>>> ...
>> Oha, das Rendering von OSM2World und der F4-Group bringt jetzt 2
>> unterschiedliche Ergebnisse.
> 
>> Weiß einer was es bei F4-Group (siehe Link oben) mit dem Südöstlichen
>> Teil des Gebäude für ein Problem gibt? Der Teil des Gebäudes hat nur 2
>> Stockwerke und das steht im Polygon. Es ist auch als "Building:part=yes"
>> und in der building-Relation enthalten. Beim OSM2World funktioniert es.
> 
>> Gruß
>> Martin
> 
> Yeap, kurz gesagt: weil der gesamte OSM-Aufbau des Südstadtklinikums
> noch immer nicht so ist, wie er eigentlich sein sollte.
> Allerdings ist das Südstadtklinikum auch nicht so einfach ...
> Aber der Reihe nach ...
> 1) Derzeit ist die Gebäudekontur (Gebäudeumriss und Innenhöfe) korrekt
> in einer multipolygon-relation verpackt.
> 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 ?
> 3) Zusätzlich gibt es noch zwei weitere Fehler - siehe 'Kochrezept'
> Punkte a) und b) ...
> 
> Kochrezept für die Korrektur:
> 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
>     (diese beiden Innenhöfe müssen natürlich in beiden relations als
> role=inner auftauchen, damit sie auch aus beiden Definitionen ausgespart
> werden).
> 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.
> c) die building-relation am besten neu aufbauen:
> 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.
> d) so mache ich es zumindest: Kontrolle mit OSM2World.jar
> <http://osm2world.org/download/> (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 !
> 
> 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 ;-)
> 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 ...
> 
> Jetzt gibt es drei Möglichkeiten:
> 01) Du greifst wieder selbst in die Tasten ...
> 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
> 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 ...)

Ich bin auch für die zeitsparende Lösung. Habe mir den alten Stand der
Klinik lokal gesichert. Die Änderungen kann ich mir dann später im
Detail anschauen.

Die OSM2World jar knöpfe ich mir dann auch vor.

Vielen Dank für die sehr ausführliche Hilfe,
Martin

> 
> Wie wollen wir verfahren ??
> Viele Grüße
> Rainer
> 
> 
> 
> _______________________________________________
> MeckPomm mailing list
> MeckPomm at lists.openstreetmap.de
> http://lists.openstreetmap.de/mailman/listinfo/meckpomm
> 


-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 4741 bytes
Beschreibung: S/MIME Cryptographic Signature
URL         : <https://lists.openstreetmap.de/pipermail/meckpomm/attachments/20131023/0d172d4d/smime-0001.p7s>