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

[Martin Garbe]

On 10/3/13 10:02 AM, Rainer Paulke wrote:
> Moin,
> 
> hmm, da gibt's 'ne ganze Reihe von Schwierigkeiten, nicht nur die
> fehlenden Innenhöfe des Südstadtklinikums in Mapnik ...
> 
> Schau Dir mal die OSM2World-Map
> <http://maps.osm2world.org/?h=128&view=N&zoom=18&lat=54.07247&lon=12.10749&layers=B0TTFF>
> an. Dem Radiologie-Gebäude fehlt der westliche Innenhof, beim
> Südstadtklinikum der westliche und östliche Innenhof. Dafür erhebt sich
> über dem westlichen Innenhof des Klinikums dann eine achtgeschossige
> Bebauung!
> Oder die F4-map
> <http://map.f4-group.com/#lat=54.0718786&lon=12.1068017&zoom=18&camera.theta=72.807&camera.phi=-165.585>;
> hier klappt das mit den Innenhöfen im Südstadtklinikum gar nicht mehr!
> 
> Was ist hierfür die Ursache, wo doch scheinbar die Gebäuderelationen
> (outer/inner) aus 2D-Sicht korrekt sind ?
> 
> Kleiner Exkurs zum 3D-Gebäude-Mapping:
> 1) Alle gebäudeweiten Infos (Adresstags, Kontaktangaben, Namen, sonstige
> Eigenschaften, ggf. auch die Gesamthöhe) kommen an den Gebäudeumriss -
> und NUR dahin.
> 2) Gibt es Innenhöfe, so werden diese durch eine Relation
> (type=multipolygon) dem Gebäudeumriss zugeordnet. Die Relation selbst
> erhält keine weiteren tags; sie dient nur der Zuordnung der Innenhöfe.
> 3) Unterschiedliche Gebäudeteile (in Höhe, Geschoßzahl, Fassadenfarbe,
> Material, Dachform etc.) werden durch building:part=yes und die
> entsprechenden weiteren tags beschrieben; gibt es für Teilbereiche des
> Gesamtgebäudes keine eigenen "building:part=yes"-Objekte, so greift - so
> vorhanden - die Definition des Gebäudeumrisses (auch wenn das so nicht
> im wiki <http://wiki.openstreetmap.org/wiki/DE:Simple_3D_Buildings>
> dokumentiert ist). Und: KEIN "building:part=yes"-Objekt darf aus dem
> Gebäudeumriss herausragen.
> 4) Zum Schluß wird das ganze Gebäudepuzzle noch in eine Relation
> (type=building) gesteckt.
> 
> Nun zu den Gründen für die Fehler:
> a) das Radiologie-Gebäude:
> der westliche Innenhof wird vollflächig von zwei building:part-Objekten
> überdeckt und ist damit zwar in Mapnik & Co prima zu sehen, da hier nur
> die Relation (type=multipolygon) ausgewertet wird; in den 3D-Viewern
> aber ist dieser Innenhof 'zugemauert'. Punkt 4) fehlt ...
> 
> b) das Klinik-Gebäude:
> Auch hier passt die Relation (type=multipolygon) für die Zuordnung der
> neun Innenhöfe, die Relation selbst trägt aber viele weitere tags, die
> ALLE an den Gebäudeumriss gehören. Dummerweise auch amenity=hospital!
> Damit erhebt sich über der Kontur des Gebäudeumrisses (building=yes) ein
> zweites Gebäude - das Krankenhaus. Wenn man genauer hinschaut, dann
> sieht man das auch wunderbar beim Mapnik bzw. 'open.mapquest'. Und es
> erklärt die mit 'Türmen ausgefüllten' Innenhöfe in der F4-map; mit
> building:height=22, so wie definiert.
> Diese hatte !i! zuvor offenbar auch bei OSM2World erhalten und als
> Reparaturmaßnahme die tags building:height=0 und building:part=yes für
> einzelne Höfe ergänzt. Das braucht's nach einer Korrektur dann natürlich
> nicht mehr ...
> Und für die Kür: Die Durchfahrten im östlichen Gebäudeteil sind als
> Tunnel getagt (ist das nicht covered=yes?) und sie ragen sie aus der
> Gebäudekontur heraus, was bei nahem Hinsehen (oder Selbst-Rendern)
> häßliche Verwerfungen mit der Bodenfläche zur Folge hat. Am besten wäre
> es, hier für die Gebäudeteile genau oberhalb der Durchfahrten mit
> min_height=4 (o.ä) zu arbeiten, covered=yes am highway zu ergänzen und
> auf die Tunnel ganz zu verzichten. Zumindest aber müßten die Tunnel
> gekürzt werden.
> Und ... Punkt 4) fehlt ...

Hab schon mal erste Korrekturen vorgenommen. Vielen vielen Dank an Rainer.

Gruß
Martin

> 
> Viel Erfolg beim 'Schrauben' - local mapper first ;-)
> 
> Viele Grüße aus Lübeck
> 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/20131018/fd3a0a65/smime.p7s>