2008/10/28 Florian Lohoff <[EMAIL PROTECTED]>: >> Routingfähige Garminkarten: Notwendigkeit zur Qualitätssicherung >> >> Mal davon >> abgesehen das ich die polygon nummer immer noch fuer viel zu CPU >> intensiv halte um praktikabel zu sein. >> >> das ist bereits vielfach widerlegt worden. Das Gegenteil ist richtig. > > Hast du eine referenz? Mail? Code? Benchmark? Ich habe bisher nichts > gesehen ausser immer wieder behauptungen.
Schau im Backlog und schreib mal beides in einer Programmiersprache hin. Da hast du einen haufen unscharfer Volltext-Suchen auf großen Datenbeständen (is_in) gegenüber einem simplen Polygon-Test den dir ein Abi-Schüler mit minimalem Geometrie-Wissen aus dem Kopf runter schreibt. (Stichwort: Anzahl der Schnittpunkte eines Strahls mit den Polygon-Linien muss gerade oder ungerade sein.) >> - Es ist nicht geklaert ob dort Englische oder Deutsche >> Bezeichner reingehoeren. >> >> das sollte eigentlich klar sein: in der Landessprache, wo sich das feature >> befindet. Das Brandenburger Tor nennst Du ja auch nicht name=Brandenburg >> Gate sondern maximal name:en=Brandenburg Gate, bzw. heisst Muenchen bei >> uns nicht Munich. > > Und warum ist dann so viel falsch wenn das so klar ist? Halte ich leider auch für Unklar. Schon is_in "Baden" "Baden Württemberg" "Baden-Württemberg" "Baden Wuertemberg" ist ja unklar. >> jede Strasse bis zur Welt aufzudroeseln ist sicher nicht zielfuehrend, Ja bis wohin denn? Wenn ich wissen will, ob auf einer Straße Tempo 50 gelten, muss ich das bis zum Staatsgebiet aufdröseln. >> unheimlich redundant und zeigt eigentlich schon, dass dieser Ansatz zum >> Scheitern verurteilt ist. Die zur Korrektur erforderlich Energie und Zeit >> ist in die Erstellung (ggf. vorlaeufiger, grober) Polygone sicher besser >> investiert. > > Ich rede nicht von Straßen - is_in auf Straßen halte ich fuer falsch und > will die auch nicht korrigieren. Ich rede von place=suburb und groesser. und an was hängt dein place=suburb? Und wie ordnest du den linken Teil einer Durchgangsstraße eben diesem Stadtteil zu? > Straßen zu einer Postleitzahl oder Suburb/City/Village/Hamlet zuzuordnen > wuerde ich ueber eine relation loesen. Die ist eindeutig und eindeutig > schneller aufzuloesen als ein polygon ... Was gegenüber vergessenen Elementen (mal eine neue Kirche eingezeichnet, mal eine Straße geteilt,...) genauso fehleranfällig wie is_in. Nein danke. Wie soll ich denn bitteschön damit die PLZ einer Telephonzelle finden, wenn jemand diese Telephonzelle ohne sie in die (dem vorbeifahrenden Mapper nicht bekannte) Relation zu packen hingesetzt hat? Auch wenn die Straße daneben oder noch eine Straße weiter in der Relation ist, kann ich das nicht mehr herausfinden. Mit einem Polygon ist das trivial und vor allem eindeutig und unmißverständlich. Kein verschobenes Objekt weiter draußen kann in diesem Suburb liegen und alles was in diesem Suburb-Polygon liegt ist auch Teil des Suburb aufgrund seiner geographischen Lage. Eine Relation ist hier nicht nur unnötig kompliziert und groß (wie viele Straßen hat der Suburb Karlsruhe-Mitte? Wie viele Dörfchen hat das Bundesland Bayern? Wie viel Ram brauche ich um dieses eine Relations-Objekt mit den enthaltenen Objekt-IDs zu laden?) sondern, wie eben dargelegt, vermeidbar fehleranfällig. Marcus _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
