[Talk-de] is_in ist tot? (Re: is_in validation)

Marcus Wolschon Marcus at wolschon.biz
Di Okt 21 10:36:40 UTC 2008


Am 21. Oktober 2008 09:28 schrieb Florian Lohoff <flo at rfc822.org>:
> Ich finde grenzpolygone noch schlechter als die bestehenden is_ins denn
> der rechenaufwand um herauszufinden wo ein element sich befindet ist um
> viele exponenten groesser bei sowas.

Genau andersherum.
Das durchsuchen der ganzen Welt mit String-Matching nach einem Namen
(potentiell incl. Falschschreibungen und ue<->ü oder
 "Badenwürtemberg"<->"Baden Wuerttenberg") ist um vielfaches Aufwendiger
als die Anzahl der Schnittpunkte eines Strals entlang der X-Achse von
dem Punkt durch das Polygon zu testen (ungerade=ist im Polygon).

Das ist triviale Mathematik (was Rechner super können) gegen
natürlichsprachiges Indizieren von Texten (was Rechner schlecht können).

> Ich wuerde straßen tendentiell eher ueber relations zu einer
> geographischen groesse (stadt, stadtteil etc) zusammenfassen. Das ist
> eindeutig und auch simpel technisch auszuwerten. Wenn man das
> vernuenftig hierarchisch macht - d.h. die relations der stadtteile
> wieder zur Stadt zusammenfuegt ist der pflegeaufwand auch simpel.

Das halte ich für genauso fehleranfällig wie is_in.
Theoretisch ist es die schönste Lösung, wenn nicht 3 Probleme
bestehen würden:
a) Diese Relation wird groß...sehr groß.
  (Denke mal an eine kleine Hinterhof-Einfahrt, für welche jetzt der
  nicht ortsansässige Mapper keine Ahnung hat wie der Stadt-Teil
  heißt und das an den Ort hängt.)
b) Genauso wie bei is_in hast du ein enormes Problem, wenn
    da mal an einer Straße vergessen oder gar falsch eingetragen wurde,
   wozu die gehört.
c) Dann ist die Straße zwar Teil des Ortes aber keiner hat sie
    der PLZ oder dem Orts-Teil oder den Ort dem Bundesland oder
    das Dorf der Region zugewiesen. Das ufert vollkommen unnötig
    in einen nicht zu überschaubaren Arbeits- Pflege- und Kontroll-Aufwand
   aus.

Bei einem Polygon ist der Pflegeaufwand = 0 und Fehler können
einfach nicht passieren.

Mein Fazit:
 Ich werte is_in in TS nicht aus. Die Suche ist zu aufwendig
 und die erlangte Information uneindeutig und potentiell falsch.

Marcus


Mehr Informationen über die Mailingliste Talk-de