[Talk-de] Routingfähige Garminkarten: Notwendigkeit zur Qualitätssicherung

Marcus Wolschon Marcus at wolschon.biz
Di Okt 28 13:10:23 UTC 2008


2008/10/28 Florian Lohoff <flo at rfc822.org>:
>>       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


Mehr Informationen über die Mailingliste Talk-de