Re: [Talk-de] is_in ist tot? (Re: is_in validation)
On Tue, Oct 21, 2008 at 08:44:04AM +0200, Sven Anders wrote: Am Montag, 20. Oktober 2008 22:35 schrieb Martin Koppenhoefer: ich dachte, is_in ist tot, d.h. sollte nicht mehr verwendet werden, da redundante Daten, und die Probleme, für die es gedacht ist, kann man anscheinend besser mit Grenzpolygonen lösen... Ich denke: Tot gesagte leben länger. Es wäre zwar schön auf is_in zu verzichten. Wenn ich aber keine Grenzdaten vorliegen habe und trotzdem angeben möchte wozu dieses Element gehört, finde ich is_in ganz praktisch. Wenn ich das mit einer Relation machen soll, muss ich die Übergeordnete Relation erst einmal kennen. Also warum nicht verwenden? Wenn wir irgendwann mal alle Grenze von allen Bundesländern, Kreisen, Städten, Gemeinden, Stadtteilen, Orstteilen drinn haben, dann brauchen wir das evtl. nicht mehr. Wobei is_in universell ist, ich kann es z.B. auch benutzen um anzugeben in welchen Kirchenkreis eine Dorfkirche ist (Kann man natürlich auch mit Relationen machen.) 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. 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. Ich rede aber im moment mal nur von places und da wurde ja auch durch das opengeodb zeugs die is_ins importiert. Jeder pflegt das nach gusto jetzt so weiter habe ich das gefuehl nur ob das sinnvoll ist weiss derzeit mal gerade keiner. Flo -- Florian Lohoff [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] is_in ist tot? (Re: is_in validation)
Am 21. Oktober 2008 09:28 schrieb Florian Lohoff [EMAIL PROTECTED]: 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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
