Re: [Talk-de] Routingfähige Garminkarten: Notwendigk eit zur Qualitätssicherung
Am 28. Oktober 2008 14:10 schrieb Marcus Wolschon [EMAIL PROTECTED]: - 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. ist nicht unklar, sondern falsch. Richtig ist Baden-Württemberg, und sonst nichts. Vor Rechtschreibfehlern ist man halt nicht gefeit, aber unklar ist das nicht. Ich bin im uebrigen ja unter anderem gerade aus diesem Grund dafuer, Polygone zu verwenden. 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. 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. jajaja! Full ACK. Ich will doch nicht bei jedem neuen Objekt erstmal ne Relation ergaenzen, wo das eigentliche Problem ohne jeden weiteren Zusatzaufwand mit Polygonen schon geloest ist. Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routingfähige Garminkarten: Notwendigk eit zur Qualitätssicherung
Am 28. Oktober 2008 09:23 schrieb Florian Lohoff [EMAIL PROTECTED]: Was allerdings viel schwerer wiegt ist das jetzt fehler oder unvollstaendigkeit der Daten zu Tage treten. So ist die Addresssuche in den Daten eine Tortur. So wie es aussieht ist obwohl es die Deutschland Karte ist das ganze in zig laender unterteilt d.h. es gibt laender Deutschland, Deutschland., Bundesrepublik Deutschland, de, Germany, Nrw, Nordrhein-Westfalen, Northrine-Westfalia und jeder ort ist in einem dieser Laender. Nur in welchem? Das ist genau der Grund, warum ist ständig gegen is_in wettere und korrekte Staats-Grenzen propagiere. Wer jetzt was von wegen Vorverarbeitung und Suchen und Ersetzen sagt, den möchte ich an die Namen von Ortschaften erinnern. Das sind schlichtweg zu viele um so einen Ansatz zur Notreparatur einer Krücke zu fahren. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routingfähige Garminkarten: Notwendigk eit zur Qualitätssicherung
Am 28. Oktober 2008 10:21 schrieb Holger Issle [EMAIL PROTECTED]: On Tue, 28 Oct 2008 09:55:12 +0100, Marcus Wolschon wrote: Das ist genau der Grund, warum ist ständig gegen is_in wettere und korrekte Staats-Grenzen propagiere. Dann mußt Du aber in Konsequenz genauso Länder, Regierungsbezirke, Städte und Stadtteile korrekt eingrenzen. Und all das über Polygone zuweisen. Viel Spaß, denn all das ist nicht oder nicht korrekt eingetragen... :( -- Ciao, Holger (GUS-KOTAL, GUS#1100, GRR#51) tja, aber ist wohl zu tun, so oder so, auch wenn es viel Arbeit ist, so fuehrt m.E. kein Weg dran vorbei. PS: Die Italiener haben in den letzten Tagen ihre Grenzen importiert. Das staatliche Statistikamt (ISTAT) hat die Daten gespendet. Zur Qualitaet kann ich noch nichts sagen, aber drin ist sicher erstmal besser als nicht... Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routingfähige Garminkarten: Notwendigk eit zur Qualitätssicherung
Am 28. Oktober 2008 10:21 schrieb Holger Issle [EMAIL PROTECTED]: Das ist genau der Grund, warum ist ständig gegen is_in wettere und korrekte Staats-Grenzen propagiere. Dann mußt Du aber in Konsequenz genauso Länder, Regierungsbezirke, Städte und Stadtteile korrekt eingrenzen. Und all das über Polygone zuweisen. Viel Spaß, denn all das ist nicht oder nicht korrekt eingetragen... :( Ja. Für kleinere Orts, wo ich das sinnvoll abschätzen kann tue ich das regelmäßig. Einen guten Teil der Deutschen Außengrenze bin ich ebenfalls abgegangen und habe etliche Fehler korrigiert. (Ist schon etwas her.) Wir werden nicht darum herum kommen. Ob das jetzt ein Polygon ist ist mehrere, nicht-geschlossene Wege die in der richtigen Reihenfolge ein Polygon bilden können und per Relation zusammengefasst werden ist mir egal. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routingfähige Garminkarten: Notwendigk eit 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. 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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routingfähige Garminkarten: Notwendigk eit zur Qualitätssicherung
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
Re: [Talk-de] Routingfähige Garminkarten: Notwendigk eit zur Qualitätssicherung
Martin Koppenhoefer schrieb: - 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. Wenn ich in den DE:Mapfeatures als Beispiel is_in=Berlin,Germany sehe, dann ist klar dass es nicht klar ist, ob dort Englische oder Deutsche Bezeichner reingehoeren. ;-) Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
