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

[Martin Koppenhoefer]

> 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.


> Solange das der fall ist macht es sinn is_in zumindest da zu reparieren
> wo es wirklich kaputt ist. Wenn du unter reparieren verstehst "Loeschen"
> ist das auch okay - Defakto sind aber die daten in den is_ins nicht nur
> nicht eindeutig (was ihmo das groesste problem ist) sondern defakto im
> moment falsch


tja


> - 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.


> 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.

Martin
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.openstreetmap.org/pipermail/talk-de/attachments/20081028/60073c85/attachment.htm>