[Talk-at] Bawag PSK
Norbert Wenzel
norbert.wenzel.lists at gmail.com
Thu Dec 13 10:20:08 UTC 2012
On 12/13/2012 11:02 AM, Martin Raifer wrote:
> Am 13.12.2012, 10:37 Uhr, schrieb Norbert Wenzel
> <norbert.wenzel.lists at gmail.com>:
>> [...] aber wenn ich mit den Daten selbst arbeiten will, dann wird's
>> mitgetrennten Nodes deutlich schwieriger.
>
> Das kann man nicht so verallgemeinern. Es kommt ganz auf die Anwendung
> darauf an. Wenn man wissen will, wo sich Bank+Post Kombifilialen
> befinden, ist die Strichpunkt-Notation auf dem ersten Blick
> vielleicht(!) komfortabler, allerdings ist sie bei dem viel
> wahrscheinlicheren Anwendungsfall: "Liste aller Postfilialen in X" mit
> Abstand deutlich unterlegen. Und zwar (wie bereits gepostet wurde) wegen
> der sehr schwierigen Indizierung der Datenbank nach solchen multiplen POIs.
Das Problem dabei hab ich ja schon früher geschrieben: wir haben leider
keinen direkten Zugang auf die Datenbank. Wir dürfen nur Strings
reinwerfen und dabei ist es uns nicht erlaubt zu einem Key mehrere
Values zu speichern. Daher geb ich dir Recht, dass die
Strichpunktnotation eine Krücke ist, aber eben die einzig erlaubte.
Wenn du dir OSM Daten lädst und in deine eigene, optimierte Datenbank
fütterst, dann musst du halt mehrere Values zum selben Key erlauben und
kannst dann dort indizieren, wie du es für dein Service brauchst.
Und die ganze Indizierung einer Datenbank nach entweder post_office oder
bank nutzt nichts, wenn ich für eine Bank- & Postfiliale
amenity=post_and_bank erfinden muss. Oder so abstruse Tagkombinationen
wie amentiy=bank & postal_service=yes & priority_postal_service = main
oder sonstwas in der Art.
Wie auch schon weiter oben geschrieben: postal_service ist toll für den
Fleischhauer der zwei Pakerl am Tag annimmt, aber wenn das Geschäft
gleichbedeutend Bank und Post ist, dann bleibt imo nur die Erfindung
einer neuen amenity. Und da würd ich dann doch post_office;bank vor
post_and_bank bevorzugen.
Norbert
More information about the Talk-at
mailing list