> 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.
> - 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?
> Die mapper sind sich nicht einig ob die ; oder
> , zum abgrenzen nehmen sollen und ansonsten ist auch die hierarchie
> ungeklaert so das manchmal bis Europe alles da ist - manchmal aber eben
> auch nur bis zum Kreis ...
>
> jede Strasse bis zur Welt aufzudroeseln ist sicher nicht zielfuehrend,
> 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.
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 ...
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
