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

[Rainer Paulke]

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

Wie wollen wir verfahren ??
Viele Grüße
Rainer
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <https://lists.openstreetmap.de/pipermail/meckpomm/attachments/20131022/759a27e2/attachment.htm>