[Talk-at] Rendering von Gebäuden in Mapnik geändert

Boris Cornet borisC at osm-at.org
Tue Apr 10 09:49:02 UTC 2012


Servus!
> Entweder alles zusammen auf die Relation oder auf den äußeren Weg.

Obwohl ich mich schon eher zu den Puristen zähle, hier werde ich ganz
schnell zum fundamentalen Pragmatiker.

Ich empfehle dringend, Adressen *NUR* auf den äußeren Weg zu taggen.
Warum: Nichts ist unschöner als doppelte Informationen (der Purist
bleckt schon wieder durch ;-). Da aber kaum jemand tatsächlich die
tags von multipolygonen checkt, wird früher oder später jemand
vermeintlich draufkommen, dass da die Adresse fehlt, und sie
nachtragen.

Und was auch häufig vorkommt, ist, dass jemand den Häuserblock in
einzelne Häuser unterteilt (nach Stiegen o.ä.). Damit wird die
relation uberflüssig und verschwindet, und damit auch die Adresse.

Und relationen haben sowieso die unangenehme Angewohnheit, ständig
kaputt zu sein. Wenn die Adressen am Außenring sind, bleiben sie
erhalten, auch wenn der Innenhof gerade mal wieder verschwunden ist.

Die Renderer verstehen beides, schon alleine deshalb, weil geschätzte
99,998% der Multipolygon-Häuser am äußeren Ring getaggt sind.

Und außerdem finde ich (Abschweifung zu dem anderen thread), dass
shops, amenities u.ä. innerhalb eines Gebäudes keine extra addr:*
tags bekommen sollten. Zum einen ist die Information ohnehin schon da
(durch das umgebende Haus), und zum anderen ist der Aufwand sehr viel
geringer, den Shop an eine neue Position zu bringen, wenn er umzieht
(und das kommt weiß Gott nicht so selten vor).

Jetzt wird gleich jemand antworten, aber das ist doch kompliziert wenn
man die Adresse aus einem umgebenden Polygon ablesen muss, und ich
antworte vorsorglich schon darauf, dass jede Anwendung, die ernsthaft
mit Adressdaten arbeiten will, mit Sicherheit eine GIS-taugliche
Datenbank verwendet, und eine IsWithin-Abfrage ist so ziemlich das
einfachste für so eine Datenbank.

Und dann noch: Wie seht denn das aus - zehn mal die gleiche Hausnummer
in einem Haus? [duck]

-- 
Bis demnächst,
   Boris






More information about the Talk-at mailing list