2008/12/10 Stefan Hirschmann <[EMAIL PROTECTED]>: > André Reichelt wrote: >> Miriam Tolke schrieb: >>> Um das Ganze mit is_in in den Griff zu bekommen kommt es dann zu sowas: >>> is_in:Roth,Mittelfranken,Bayern,Bundesrepublik Deutschland,Europe >> >> Soweit ich informiert bin, ist dieses Tagging-Schema veraltet. Heute >> löst man etwas eigentlich mit Relations. > > Es gibt zwar auch eine Relation dafür. Aber: "is_in=Europe" als > Relation? Spätestens da merkt man, dass Relationen nicht unbedingt etwas > sind, was skalieren. > > Nächstes Problem: Nehmen wir eine Stadt mit über 100.000 Einwohnern. > Diese bekommt ziemlich schnell mehr als 2000 Objekte zusammen. Doch 2000 > ist laut API schon die Grenze für Relationen. > > Daraus folgt: Relationen sind eine nette Spielerei. Aber für große > Gebiete einfach ungeeignet.
Naja, es ist ja gar nicht nötig, jedes Objekt (oder jeden Place - wie auch immer) der sich in Europa befindet, in eine relation "Europe" zu packen. Zum einen haben wir Flächenpolygone (die durch Relationen abgebildet sind) die zumindest bald alle Landkreisgrenzen erfassen. Und alles darüber. D.h. ein Rechner kann herausfinden, wo ein Objekt ist. Und wenn man schnelle Suche use braucht, muss man halt die Daten vorverarbeiten und sich entsprechende is_in aus den Relationen selbst bauen. Kein Problem! Und falls man doch unbedingt is_ins verwenden will, muss man auch nicht jeden place in in Europa in die Relation Europe packen. Sondern alle Ortsteile in eine Relation "Gemeinde", alle Gemeinden in eine Relation "Landkreis", alle Landkreise in eine Relation "Bezirk", alle Bezirke in eine Relation "Bundesland", .... Da muss sich das auswertende Prog. evtl 10 Relationen ansehen, ABER dafür sind die Anzahl der Elemente sehr überschaubar (~20 würde ich mal sagen). Die genau Hierachie sollte man sich noch genau überlegen und dann auch synchron mit den admin_level der boundarys halten. Mein Beispiel oben ist nur schnell hingeklatscht.. Aber nochmal: grundsärtlich bin ich dagegen is_in zu verwenden. Wenn, dann aber so. Dominik _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
