Re: [Talk-de] Garminkacheln (war: All in One mit git)
Hi, Am 14.03.2010 13:32, schrieb Torsten Leistikow: Vielleicht mal die neuste Version von mkgmap probieren. WanMil hat ja gerade mit Es war letzte Woche die 1599 Release 1601 seinen neusten multipolygon-Patch veroeffentlicht. Wenn das auch damit nicht will, solltest du ihm die von splitter erzeugte OSM-Datei zuschicken, damit er da mal einen Blick draufwerfen kann. Mal sehen was diese Woche passiert, aber ich gehe davon aus, daß es einfach Gebiete sind, sie zu Groß sind, so daß der Überlappungsbereich nicht reicht. Ich habe übrigens ein sprachliches Problem, den Briten das genau zu erklären, hatte ich am Anfang des Threads auch erwähnt. -- Viele Grüße Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkacheln (war: All in One mit git)
Hi, Am 14.03.2010 13:27, schrieb Torsten Leistikow: Nö, sehe ich nicht so, das Grenzproblem an sich muss gelöst werden und nicht am Symptom gedoktort werden. Das setzt voraus, dass das Problem auch wirklich loesbar ist. Wenn es nun aber gar nicht von der Gestalltung der Kachelgrenzen abhaengt, sondern die interne Es liegt an den Karten, die Umsetzung im GPS-Gerät funktioniert ja, zumindest kann mkgmap das entsprechend erzeugen. Also muss nur der Kachelschneideproßeß an mkgmap angepaßt werden. Ich weiss aber im Moment noch nicht genau, was mkgmap an diesen weiterführenden Straßen erwartet. Sicher keine Überlappung, sondern eher ein spezielles Tag, was von splitter erzeugt wird. Ich habe neulichst mal meine Karten so umgebaut, dass die einzelnen Kacheln nicht mit irgend einer Nummer sondern mit einem sprechenden Namen auf dem Navi angezeigt werden. Bei rein schematisch geschnittenen Kacheln ist das manchmal ziemlich schwer, dann einen passenden Namen fuer den Ausschnitt zu finden. Nö, wieso? Einfach die zuerst auftretende City verwenden. Und dann in bestimmter Weise die Orte nach Wichtigkeit absteigend. Die Kacheln von Garmin sind da auch nicht viel intelligenter benannt. (ist bei CutTheOSMPlanet in der Pipeline das zu realisieren) Ausserdem koennte man bei freiem Kachelschnitt auch Themenkarten erzeugen, die sich an aeusseren Vorgaben ausrichten. Z.B. Wanderkarten die entsprechend den Tourismusregionen oder den ausschildernden Wanderverbaenden geschnitten waeren. Hier sehe ich das besser so, daß man doch die Umgebung lieber mitnehmen soll, was nützt es denn, wenn ich zwar ein Gebiet drin habe, mein Hotel aber gerade außerhalb ist, und ich dann doch wieder eine zweite Karte hinzufügen muss. Wenn man sich eine Garmin-Karte selber baut, so ist man bestimmt die Haelfte der Zeit damit beschaeftigt, fuer irgendwelche Probleme einen Workaround zu finden. Na bei mir hält es sich mittlerweile in Grenzen, aber ich bin ja auch mehr an Standards interessiert und kein Freund von ständigen Änderungen. Und die andere Haelfte der Zeit verbringt man damit, die Workarounds wieder zurueck zu bauen, wenn die mkgmap-Gemeinde ein neues Feature entschluesselt und verwirklicht hat. Das war in der Anfangszeit tatsächlich so, hat aber ziemlich stark nachgelassen. -- Viele Grüße Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkacheln (war: All in One mit git)
Carsten Schwede schrieb am 15.03.2010 20:35: Es liegt an den Karten, die Umsetzung im GPS-Gerät funktioniert ja, zumindest kann mkgmap das entsprechend erzeugen. Soweit ich gehoert habe, macht das Routing immer noch Probleme, wenn es ueber zu viele Kachelgrenzen geht. Das koennte durchaus eine Einschraenkung sein, die in der Geraetehardware begruendet ist und auch mit besserer Schnitttechnik nicht geloest werden kann. Wenn dem so ist, dann waere ein festes Kachelgitter deutlich suboptimal. Nö, wieso? Einfach die zuerst auftretende City verwenden. Im Prinzip sicherlich ja. Doch in der Praxis habe ich recht haeufig den Fall gehabt, dass die groesste Stadt gerade noch so am Rand einer Kachel liegt und deshalb zur Benennung des Gebietes denkbar ungeeignet ist. Hier sehe ich das besser so, daß man doch die Umgebung lieber mitnehmen soll, was nützt es denn, wenn ich zwar ein Gebiet drin habe, mein Hotel aber gerade außerhalb ist, und ich dann doch wieder eine zweite Karte hinzufügen muss. Mit den speziellen Themenkarten hatte ich auch nicht an den Urlauber gedacht, sondern eher an den Verband, der sich genau fuer sein Gebiet interessiert. Da kann z.B. aus Gruenden der Eigenwerbung eine exakte Abgrenzung wuenschenswert sein. Und die andere Haelfte der Zeit verbringt man damit, die Workarounds wieder zurueck zu bauen, wenn die mkgmap-Gemeinde ein neues Feature entschluesselt und verwirklicht hat. Das war in der Anfangszeit tatsächlich so, hat aber ziemlich stark nachgelassen. Deine Karten sind zwar schon ganz schoen ausgereift, aber lassen auch noch genug Potential fuer Erweiterungen und Spezialisierungen. Wenn man sich z.B. anguckt, was die OpenMTBMap fuer einen Aufwand beim Routing betreibt, dann muss man nicht befuerchten, dass das Thema Garmin-Karten_Bauen demnaechst ausreizt ist. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkacheln (war: All in One mit git)
Carsten Schwede schrieb am 14.03.2010 08:31: Die Polygone komplett wegzuwerfen finde ich nicht sehr gut. Es ist im Moment so, daß dann ganze Wälder weg sind. Splitter wirft polygone innerhalb der Kacheln komplett weg? Hast du mal ein Beispiel dafuer? Ich benutze Splitter nur im Zusammenspiel mit mkgmap, deshalb interessiert es mich normalerweise nicht, wer von beiden was genau macht. Nur falls es zu Problemen kommt, schaue ich dann mal genauer hin. Und z.Z. sind mir da keine Probleme bekannt, wobei ich natuerlich nur die Bereiche beobachte, von denen ich auch weiss, was ich als Ergebnis erwarte. Meinem Verstaendniss nach uebernimmt splitter in der Standardeinstellung sogar mehr, als man eigentlich durch die Kachelgrenzen vorgibt. Die Kachelgrenzen selber werden mit in der XML-Datei gespeichert und mkgmap uebrnimmt dann das genaue Zuschneiden. Die Groesse dieses ueberstehenden Bereiches kann man per Parameter vorgeben, keine Ahnung was passiert, wenn man da auf Null runter geht. Ich vermute mal, dass das fuer die Garminkartenerzeugung auch nicht sinnvoll ist, sonst wuerde man das ja standardmaessig tun. Nebenbei bemerkt: Der Ansatz mit der festen Zuordnung von Kacheln hat ein prinzipielles Problem. Die maximale Anzahl der Elemente in einer Garminkachel ist naemlich offensichtlich begrenzt (auch wenn noch nicht genau verstanden ist, wieviele Knoten, Wege und Flaechen maximal moeglich sind). Nun ist die OSM-Datenbank ja aber stetig am Wachsen, und ich denke mal, dass man davon ausgehen kann, dass das noch eine ganze Weile so bleiben wird. Da ist es dann nur eine Frage der Zeit, bis einige der heute festgelegten Kacheln in Zukunft die Maximalgroesse ueberschreiten. Das Problem wird noch dadurch verstaerkt, dass man wohl davon ausgehen kann, dass dort, wo die Datendichte schon jetzt am groessten ist, auch in absehbarer Zeit das Wachstum am groessten sein wird. Insofern duerfte dein 1° Raster langfristig fuer die Garminkarten denkbar ungeeignet sein. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkacheln (war: All in One mit git)
Hi, Am 14.03.2010 10:55, schrieb Torsten Leistikow: Splitter wirft polygone innerhalb der Kacheln komplett weg? Hast du mal ein Beispiel dafuer? Nicht innerhalb der Kacheln, sondern am Rand. Welche Konstellation dazu führt weiß ich auch nicht, es passiert nicht immer. http://openstreetmap.teddynetz.de:81/fehler_splitter.jpg http://openstreetmap.teddynetz.de:81/ohnefehler.jpg Meinem Verstaendniss nach uebernimmt splitter in der Standardeinstellung sogar mehr, als man eigentlich durch die Kachelgrenzen vorgibt. Die Kachelgrenzen Das weiss ich, das ist für mich eben meine Aussage, daß die Grenzelemente verdoppelt werden. selber werden mit in der XML-Datei gespeichert und mkgmap uebrnimmt dann das genaue Zuschneiden. mkgmap schneidet normalerweise exakt an den im xml-File vorgegebenen Boundary-Grenzen, und zwar rigoros. Die werden allerdings von splitter offenbar entsprechend großzügig erzeugt. Die Groesse dieses ueberstehenden Bereiches kann man per Parameter vorgeben, keine Ahnung was passiert, wenn man da auf Null runter geht. Ich vermute mal, dass das fuer die Garminkartenerzeugung auch nicht sinnvoll ist, sonst wuerde man das ja standardmaessig tun. Meine Meinung ist, daß es deshalb sein muß, weil eben genau dann echte Lücken entstehen, weil eben keine Zwischenpunkte berechnet werden. Der Ansatz mit der festen Zuordnung von Kacheln hat ein prinzipielles Problem. Die maximale Anzahl der Elemente in einer Garminkachel ist naemlich offensichtlich begrenzt (auch wenn noch nicht genau verstanden ist, wieviele Knoten, Wege und Flaechen maximal moeglich sind). Nun ist die OSM-Datenbank ja Das weiß im Moment wie es aussieht niemand außer Garmin selbst. aber stetig am Wachsen, und ich denke mal, dass man davon ausgehen kann, dass das noch eine ganze Weile so bleiben wird. Da ist es dann nur eine Frage der Zeit, bis einige der heute festgelegten Kacheln in Zukunft die Maximalgroesse ueberschreiten. Mein Kachelsystem verwende ich seit 2 Jahren konstant. Das Problem wird noch dadurch verstaerkt, dass man wohl davon ausgehen kann, dass dort, wo die Datendichte schon jetzt am groessten ist, auch in absehbarer Zeit das Wachstum am groessten sein wird. Insofern duerfte dein 1° Raster langfristig fuer die Garminkarten denkbar ungeeignet sein. Der Witz ist, daß ich problemlos die Kacheln nochmals unterteilen kann, wenn es erforderlich wird. Dazu ist nur eine Parameteränderung notwendig, die dann wieder auf Jahre ein konstantes Nummernsystem erzeugt. Und ich denke alle paar Jahre eine solche Änderung, die eben einen einmaligen Aufwand erfordert ist nicht wirklich ein Problem. Selbst in den Niederlanden oder in DE ist noch kein Problem diesbezüglich entstanden. Es scheint auch so, daß es eine Verschiebung dieser Grenze gegeben hat, vor einiger Zeit gab es nämlich ein solches Problem kurzfristig, was mit der nächsten mkgmap-Version wieder verschwunden war. Es läßt sich ja auch relativ einfach steuern, was in der Karte erscheint, und selbst wenn die Daten noch viel dichter werden, was davon in den Garminkacheln ankommt ist doch per Style geregelt, also selbst wenn jeder Pflasterstein in der Datenbank ist, muß das trotzdem nicht heißen, dass die Garminkachel dann ein Problem bekommt. Ich würde dann diese eben einfach weglassen, da sie für die Karte im GPS-Gerät keine Rolle spielen. -- Viele Grüße Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkacheln (war: All in One mit git)
Carsten Schwede schrieb am 14.03.2010 11:20: Nicht innerhalb der Kacheln, sondern am Rand. Welche Konstellation dazu führt weiß ich auch nicht, es passiert nicht immer. http://openstreetmap.teddynetz.de:81/fehler_splitter.jpg http://openstreetmap.teddynetz.de:81/ohnefehler.jpg Hast du dir die geschnittene Kachel mal als OSM-Datei in JOSM angeschaut? Meine Frage zielt darauf, ob der Fehler wirklich beim splitter liegt, oder ob beim finalen Schnitt bei mkgmap was schief laeuft. Letztens hatte ich naemlich aehnliche Effekte, die allerdings durch die Multipolygonverarbeitung in mkgmap verursacht wurden (Von einem Polygon, dass durch die Kachelgrenze in mehrer Teile zerteilt wird, erschien nur einer dieser Teile in der Garminkarte). Meine Meinung ist, daß es deshalb sein muß, weil eben genau dann echte Lücken entstehen, weil eben keine Zwischenpunkte berechnet werden. Naja, diese Berechnung ist nun mal nach mkgmap verlagert worden. Ob sie da besser aufgehoben ist oder nicht, mag ich nicht beurteilen. Mein Kachelsystem verwende ich seit 2 Jahren konstant. Und die Interstate-35W-Mississippi-River-Brücke hat 40 Jahre gehalten, ohne dass da jemals was passiert waere :-) Und ich denke alle paar Jahre eine solche Änderung, die eben einen einmaligen Aufwand erfordert ist nicht wirklich ein Problem. Fuer eine einzige Karte sicherlich nicht. Weiter oben im Thread ging es aber mal darum, wie man die verschiedenen Kartenstile besser aufeinander abstimmen koennte. Es läßt sich ja auch relativ einfach steuern, was in der Karte erscheint, und selbst wenn die Daten noch viel dichter werden, was davon in den Garminkacheln ankommt ist doch per Style geregelt, also selbst wenn jeder Pflasterstein in der Datenbank ist, muß das trotzdem nicht heißen, dass die Garminkachel dann ein Problem bekommt. Ich würde dann diese eben einfach weglassen, da sie für die Karte im GPS-Gerät keine Rolle spielen. Auch hier greift das Argument wieder nur fuer eine einzige Karte, nicht aber fuer einen einheitlichen Aufbau von unterschiedlichen Kartenstilen. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkacheln (war: All in One mit git)
Hi, Am 14.03.2010 11:41, schrieb Torsten Leistikow: Hast du dir die geschnittene Kachel mal als OSM-Datei in JOSM angeschaut? Meine Nein. Bei mir ist das Polygon ja komplett. Was sollte ich da in josm mehr sehen? Frage zielt darauf, ob der Fehler wirklich beim splitter liegt, oder ob beim finalen Schnitt bei mkgmap was schief laeuft. Letztens hatte ich naemlich Ich selbst habe das Schneiden in mkgmap deshalb abgeschaltet, damit mkgmap mir da nicht reinfunkt. verursacht wurden (Von einem Polygon, dass durch die Kachelgrenze in mehrer Teile zerteilt wird, erschien nur einer dieser Teile in der Garminkarte). Ja davon spreche ich ja, vielleicht ist das ja in meinem Beispiel genau sowas. Und die Interstate-35W-Mississippi-River-Brücke hat 40 Jahre gehalten, ohne dass da jemals was passiert waere :-) Toller Vergleich. Fuer eine einzige Karte sicherlich nicht. Weiter oben im Thread ging es aber mal darum, wie man die verschiedenen Kartenstile besser aufeinander abstimmen koennte. Das ist von den Kartenstilen doch unabhängig, mir geht es darum eine einheitliche Basis zu haben. Wenn eben so eine Basis auf eine sinnvolle Kachelgröße, die vorraussichtlich die nächsten 5 Jahre hält getellt wird, dann wird jetzt ein Schnitt gemacht, und gut ist es. Ich glaube kaum, daß z.B. eine Halbierung der Kacheln auf 0,5°x1° für so einen Zeitraum nicht reichen sollte. Selbst wenn wirklich viele Daten hizukommen. (OK wenn ich mir alle Gebäude in DE vorstelle, dann kann es eng werden) Auch hier greift das Argument wieder nur fuer eine einzige Karte, nicht aber fuer einen einheitlichen Aufbau von unterschiedlichen Kartenstilen. Ich dachte wir sprechen von einer Grundlage für Garminkarten? Wer kommt hier auf die Idee in einen einzigen Layer (=eine unabhängige Kartenkachel) alle Elemente der Datenbank abzubilden? Die AllInOne hat genau daher mehrere Layer. -- Viele Grüße Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkacheln (war: All in One mit git)
Carsten Schwede schrieb am 14.03.2010 11:55: Nein. Bei mir ist das Polygon ja komplett. Was sollte ich da in josm mehr sehen? Ich meinte, du solltest dir mal die OSM-Datei angucken, die aus splitter raus kommt, damit man entscheiden kann, ob das wirklich ein splitter Problem ist oder ein mkgmap Problem. Wenn man ein Problem genau einkreisen und mit einem Beispiel versehen kann, dann findet sich auf der mkgmap Liste eiegtnlcih meist auch recht schnell jemand, der sich dessen annimmt. Toller Vergleich. Deshalb ja auch der Smiley. Mir ging es nur darum, dass man aus einem Funktionieren in der Vergangenheit recht schlecht ein Funktionieren in der Zukunft ableiten kann. (OK wenn ich mir alle Gebäude in DE vorstelle, dann kann es eng werden) Die kleinsten Kacheln hat bei mir splitter bislang in der Region Udine geliefert, wo genau damit angefangen wurde. Und zum Kippen des einheitlichen Rasters reicht ja allein ein Problemfall aus. Ich dachte wir sprechen von einer Grundlage für Garminkarten? Wer kommt hier auf die Idee in einen einzigen Layer (=eine unabhängige Kartenkachel) alle Elemente der Datenbank abzubilden? Die AllInOne hat genau daher mehrere Layer. Naja, da Mapsource ja nur einen Layer zur Zeit darstellen kann, ist die Idee nicht ganz so abwegig. Von der Idee finde ich deinen Ansatz eigentlich gut, und ich habe mich frueher auch an deinem Raster orientiert. Inzwischen bin ich damit aber wiederholt in Schwierigkeiten gekommen (z.B. bei SRTM-Daten), so dass ich eine variablerer Kachelaufteilung bevorzuge. Da die Kachelgrenzen mindestens potentielle Problemstellen sind, sollte man bestrebt sein, moeglichst wenige, d.h. also moeglichst gleichmaessig gefuellte, Kacheln zu haben. Da die Datenlage bei OSM regional aber sehr unterschiedlich ist, geht das mit einem derartig starren Raster nicht. Die originalen Garminkarten sind uebrigens nicht rechteckig sondern entlang von Verwalltungsgrenzen geschnitten. Das ist natuerlich auch nett, nur fuer sowas fehlen uns bislang noch die passenden Werkzeuge. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkacheln (war: All in One mit git)
Hi, Am 14.03.2010 12:22, schrieb Torsten Leistikow: Ich meinte, du solltest dir mal die OSM-Datei angucken, die aus splitter raus kommt, damit man entscheiden kann, ob das wirklich ein splitter Problem ist oder Achso, das kann ich mal machen. Mir ging es nur darum, dass man aus einem Funktionieren in der Vergangenheit recht schlecht ein Funktionieren in der Zukunft ableiten kann. Neine, das natürlich nicht, aber ich kann auch nicht imemr das Schlimmste annehmen, nur damit ich ja kein Risiko eingehe. (OK wenn ich mir alle Gebäude in DE vorstelle, dann kann es eng werden) Die kleinsten Kacheln hat bei mir splitter bislang in der Region Udine geliefert, wo genau damit angefangen wurde. Und zum Kippen des einheitlichen Rasters reicht ja allein ein Problemfall aus. Ist bei mir überhaupt kein Problem, trotz 1°x1° Raster. Siehe aktueller EU-Ausschnitt von mir (vom 10.3.10) Naja, da Mapsource ja nur einen Layer zur Zeit darstellen kann, ist die Idee nicht ganz so abwegig. Mapsource ist nicht das Maß aller Dinge, und ich denke, wir sollten eher auf QLandkarte setzen, der kann übrigens mehrere Karten als Layer übereinander darstellen. Außerdem können wir hier auf die Entwicklung des Programmes direkten Einfluß nehmen, wie ich ja im Prinzip auch schon getan habe, wegen der Einführung von Typ-Dateien in meinen Karten hat Oliver die Darstellung ebendieser in QLandkarte nämlich eingebaut. Schwierigkeiten gekommen (z.B. bei SRTM-Daten), so dass ich eine variablerer Kachelaufteilung bevorzuge. Die srtm-Dateien sind in der Tat schwierig, wobei ich nicht begriffen habe warum überhaupt. Datentechnisch können da eigentlich gar nicht soviele Daten drin sein. Da die Kachelgrenzen mindestens potentielle Problemstellen sind, sollte man bestrebt sein, moeglichst wenige, d.h. also moeglichst gleichmaessig gefuellte, Kacheln zu haben. Da die Datenlage bei OSM regional aber sehr unterschiedlich ist, geht das mit einem derartig starren Raster nicht. Nö, sehe ich nicht so, das Grenzproblem an sich muss gelöst werden und nicht am Symptom gedoktort werden. Die originalen Garminkarten sind uebrigens nicht rechteckig sondern entlang von Verwalltungsgrenzen geschnitten. Das ist natuerlich auch nett, nur fuer sowas fehlen uns bislang noch die passenden Werkzeuge. Was nützt Dir so eine Kachelung denn. Ich hier in Frankfurt habe deswegen bisher keinen Sinn darin gesehen, weil mir hier eine Kachelung nichts nützt, wenn ich von anderen Ländern umgeben bin. Dann muss man eh die Kacheln drumherum mitnehmen. Außerdem hilft es auch bei Grenzen an anderen Staaten nicht, weil da die Einteilung in Bundesländer oder so ja meist völlig anders ist. Ich persönlich würde es eher sinnvoll finden die ganze Welt in eine nutzbare Karte zu packen. (Ich weiss auch schon ungefähr wie ich das machen kann, mal sehen wo da die Grenzen der Technik dann liegen) Die originalen Garminkarten sind aber auch eine gute Grundlage, wo man sicher auch mal hinsehen sollte, hier gibt es nämlich soetwas wie übereinanderliegende Kartelemente oder doppelte Wege gar nicht. (Siehe z.B. Topo V1 in mapedit) -- Viele Grüße Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkacheln (war: All in One mit git)
Hi, Am 14.03.2010 12:22, schrieb Torsten Leistikow: Ich meinte, du solltest dir mal die OSM-Datei angucken, die aus splitter raus kommt, damit man entscheiden kann, ob das wirklich ein splitter Problem ist oder Ich habe mit das jetzt mal an der Ecke angesehen, also es sieht danach aus, daß mkgmap das wegwirft. In der con splitter produzierten OSM-Datei ist die fehlende Waldecke drin. Ansonsten habe ich aber auch gesehen, daß der Overhead doch recht massiv ist, was splitter da erzeugt. -- Viele Grüße Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkacheln (war: All in One mit git)
Carsten Schwede schrieb am 14.03.2010 12:41: Mapsource ist nicht das Maß aller Dinge, und ich denke, wir sollten eher auf QLandkarte setzen, der kann übrigens mehrere Karten als Layer übereinander darstellen. Außerdem können wir hier auf die Entwicklung des Programmes direkten Einfluß nehmen, wie ich ja im Prinzip auch schon getan habe, wegen der Einführung von Typ-Dateien in meinen Karten hat Oliver die Darstellung ebendieser in QLandkarte nämlich eingebaut. Mapsource ist sicherlich eine Kruecke. Es ist fuer mich aber erste Wahl, um am PC die Routing-Funktionen der Karte auszuprobieren. Normalerweise liefert Mapsource da ja die gleichen Ergebnisse wie das Navi-Geraet, aber am viel groesseren PC-Bildschirm kann man sich die natuerlich besser anschauen. Nö, sehe ich nicht so, das Grenzproblem an sich muss gelöst werden und nicht am Symptom gedoktort werden. Das setzt voraus, dass das Problem auch wirklich loesbar ist. Wenn es nun aber gar nicht von der Gestalltung der Kachelgrenzen abhaengt, sondern die interne Software der Navis das begrenzende Element ist? Da das ja aber z.Z. nicht bekannt ist, bevorzuge ich einen moeglichst pragmatischen Ansatz, will sagen: Ich will mit heutigem, freien Wissen und den verfuegbaren Werkzeugen moeglichst gute Resultate erzielen. Was nützt Dir so eine Kachelung denn. Ich hier in Frankfurt habe deswegen bisher keinen Sinn darin gesehen, weil mir hier eine Kachelung nichts nützt, wenn ich von anderen Ländern umgeben bin. Dann muss man eh die Kacheln drumherum mitnehmen. Ich habe neulichst mal meine Karten so umgebaut, dass die einzelnen Kacheln nicht mit irgend einer Nummer sondern mit einem sprechenden Namen auf dem Navi angezeigt werden. Bei rein schematisch geschnittenen Kacheln ist das manchmal ziemlich schwer, dann einen passenden Namen fuer den Ausschnitt zu finden. Ausserdem koennte man bei freiem Kachelschnitt auch Themenkarten erzeugen, die sich an aeusseren Vorgaben ausrichten. Z.B. Wanderkarten die entsprechend den Tourismusregionen oder den ausschildernden Wanderverbaenden geschnitten waeren. Die originalen Garminkarten sind aber auch eine gute Grundlage, wo man sicher auch mal hinsehen sollte, hier gibt es nämlich soetwas wie übereinanderliegende Kartelemente oder doppelte Wege gar nicht. (Siehe z.B. Topo V1 in mapedit) Yepp. Schade, dass wir nicht bei allen Sachen wissen, wie das genau funktioniert. Wenn man sich eine Garmin-Karte selber baut, so ist man bestimmt die Haelfte der Zeit damit beschaeftigt, fuer irgendwelche Probleme einen Workaround zu finden. Und die andere Haelfte der Zeit verbringt man damit, die Workarounds wieder zurueck zu bauen, wenn die mkgmap-Gemeinde ein neues Feature entschluesselt und verwirklicht hat. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkacheln (war: All in One mit git)
Carsten Schwede schrieb am 14.03.2010 13:24: Ich habe mit das jetzt mal an der Ecke angesehen, also es sieht danach aus, daß mkgmap das wegwirft. In der con splitter produzierten OSM-Datei ist die fehlende Waldecke drin. Vielleicht mal die neuste Version von mkgmap probieren. WanMil hat ja gerade mit Release 1601 seinen neusten multipolygon-Patch veroeffentlicht. Wenn das auch damit nicht will, solltest du ihm die von splitter erzeugte OSM-Datei zuschicken, damit er da mal einen Blick draufwerfen kann. Ansonsten habe ich aber auch gesehen, daß der Overhead doch recht massiv ist, was splitter da erzeugt. Das kann man ja einstellen. (Was auch immer das fuer Auswirkungen haben mag.) Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkacheln (war: All in One mit git)
Hallo, Carsten Schwede wrote: Das ist eigentlich das geringste Problem. Wenn mein Cutter irgendwann so arbeitet, daß alles in den Kacheln drinbleibt und die herausragenden Wege auch korrekt abgeteilt werden (das ist der nächste Entwicklungsschritt) Ich hab das jetzt eine Weile nicht verfolgt. Ist Dein Cutter inzwischen veroeffentlicht, so dass andere evtl. bei dem Problem helfen koennen? Als ich damals das osmcut.c geschrieben hab, war Deine Loesung glaube ich im Stadium wird irgendwann vielleicht mal veroeffentlicht oder so. Das ist ja auch ein erhoffter Effekt des dev-Servers, dass man da ein bisschen die Entwicklungskapazitaet buendeln kann und nicht jeder die gleichen Probleme fuer sich selber loesen muss. Ist denn bekannt, welche Anforderungen eine Kachel-Teilung erfuellen muss, damit Routing ueber die Kachelgrenzen hinweg funktioniert? Ich spreche jetzt als Garmin-Karten-Aussenseiter, bitte also um Nachsicht, falls die Frage naiv ist. Wenn ich einen Way A-B-C-D habe, und die Kachelgrenze liegt zwischen B und C, was tun die gaengigen Cutter dann im Moment? Wenn ich nun einen kuenstlichen Node X auf der Kachelgenze zwischen B und C einfuehren wuerde, der in beiden Kacheln enthalten waere, koennte dann ein korrektes Routing erfolgen? Der Splitter muesste vermutlich fuer den kuenstlichen Node X entweder eine negative ID oder eine, die hoeher ist als die hoechste sonst vorkommende, vergeben, richtig? Was geschaehe, wenn ich zwei Kacheln aus verschiedenen Splitter-Laeufen im Garmingeraet miteinander kombinieren wuerde - eine Kachel, in der der Node X die ID -50 bekommen hat, und eine aus einem spaeteren Lauf, in der der Node die ID -298 bekommen hat? Merkt das Garmin-Geraet das ueberhaupt noch, oder geht das nur noch nach der Position des Nodes? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkacheln (war: All in One mit git)
Hallo, Am 13.03.2010 12:07, schrieb Frederik Ramm: Ich hab das jetzt eine Weile nicht verfolgt. Ist Dein Cutter inzwischen veroeffentlicht, so dass andere evtl. bei dem Problem helfen koennen? Noch nicht ganz, aber eigentlich kurz davor. Ich habe die letzten Tage auf den Programmierer eingewirkt, es sollte eigentlich kein Problem mehr sein. ich schreib ihm gleich nochmal. Als ich damals das osmcut.c geschrieben hab, war Deine Loesung glaube ich im Stadium wird irgendwann vielleicht mal veroeffentlicht oder so. Ja. :-) Ist denn bekannt, welche Anforderungen eine Kachel-Teilung erfuellen muss, damit Routing ueber die Kachelgrenzen hinweg funktioniert? Ich spreche jetzt als Garmin-Karten-Aussenseiter, bitte also um Nachsicht, falls die Frage naiv ist. Ist nicht naiv. Prinzipiell ist es bekannt wie das geht, auch wenn ich es noch nicht ganz verstanden habe. Es werden auf die abgeschnittenen Wege marker gesetzt. So macht das splitter.jar. Darauf bezieht sich dann mkgmap beim Erzeugen der Routingkarte. Wenn ich einen Way A-B-C-D habe, und die Kachelgrenze liegt zwischen B und C, was tun die gaengigen Cutter dann im Moment? Wenn ich nun einen Mein Cutter übernimmt den kompletten Weg in die Kachel, in der er beginnt, also da wo die erste Node ist. Daher kommen bei mir die langen Äste, die aus den Kacheln ragen. kuenstlichen Node X auf der Kachelgenze zwischen B und C einfuehren wuerde, der in beiden Kacheln enthalten waere, koennte dann ein korrektes Routing erfolgen? Das ist egal, ob man da einen Node hinzufügt. Es muss nur jeweils der Anschluß entsprechend markiert sein. Ist auch glaube ich für eine effektive Kachelung zu rechenaufwändig da einen Node zu berechnen. Der Splitter muesste vermutlich fuer den kuenstlichen Node X entweder eine negative ID oder eine, die hoeher ist als die hoechste sonst vorkommende, vergeben, richtig? Was geschaehe, wenn ich zwei Kacheln aus verschiedenen Splitter-Laeufen im Garmingeraet miteinander kombinieren wuerde - eine Kachel, in der der Node X die ID -50 bekommen hat, und eine aus einem spaeteren Lauf, in der der Node die ID -298 bekommen hat? Merkt das Garmin-Geraet das ueberhaupt noch, oder geht das nur noch nach der Position des Nodes? Das kann ich nicht sagen. Am wichtigsten wäre es wohl erstmal herauszubekommen was genau splitter.jar an dieser Stelle macht und was mkgmap erwartet. Dazu reichen aber meine Englischkenntnisse leider nicht aus um Steve danach zu fragen. -- Viele Grüße Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkacheln (war: All in One mit git)
Hallo, Am 13.03.2010 14:16, schrieb Torsten Leistikow: Nochmal konkret gefragt: Was abgesehen vom Speicherbedarf stoert dich an splitter.jar? Die ungeordneten Kacheln, die damit entstehen, diese Woche kann meine Kachel für einen bestimmten Punkt eine Nummer haben, nächste Woche hat sie eine andere Größe und dann noch eine andere Nummer. Für die automatische Erstellung von Kartenausschnitten ist das sehr hinderlich. (z.B. Haiti und Chileausschnitte). Es gibt auch etliche Leute, die über das Kachelaussuchinterface einzelne Kacheln von irgendwo auf der Welt holen, oder gar direkt durch Angabe einer oder weniger spezieller Kacheln, das kann ich problemlos mit aktuellen Daten hinterlegen, was eben bei Nutzung von splitter nicht so einfach geht. Im Prinzip stammt splitter ja von den selben Leuten wie mkgmap, so dass da schon der Kern des OSM-zu-Garmin-Wissens dahinter steckt. Ja klar. Der Nachteil ist aber hier auch, dass die beiden Programme sehr aufeinander angewiesen sind. Mein Ziel wäre, daß man die Kacheln imemr und überall verwenden kann, also auch für die Erstellung von ganz anderen Karten, nicht nur Garminkarten. Von mir aus kann es gerne mehrere Schnittprogramme geben. Sinnvoller Weise haette dann jedes seine Vor- und Nachteile, wobei ich z.Z. eben nicht sehe, wo dein Programm splitter.jar ueberlegen ist. die Vorteile meines Programmes sind: - festes Raster für die ganze Welt - eindeutige Kachelnummern - keine Doppelungen von Wegen an Schnittgrenzen - keine abgeschnittenen oder verstümmelten Polygone/Wege - keine zusätzlich berechnteten Nodes nötig - geringerer Speicherbedarf auf Kosten der Laufzeit (wobei ich nicht weiss wie lange splitter an der ganzen Welt rechnen würde) Das sollte es soweit sein. -- Viele Grüße Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkacheln (war: All in One mit git)
Carsten Schwede schrieb am 13.03.2010 14:51: Die ungeordneten Kacheln, die damit entstehen, diese Woche kann meine Kachel für einen bestimmten Punkt eine Nummer haben, nächste Woche hat sie eine andere Größe und dann noch eine andere Nummer. Das kannst du ganz einfach verhindern, indem du splitter.jar eine area-list vorgibst. Ueber diese Datei kann man die Eckpunkte sowie den Dateiname fuer jede auszuschneidende Kachel definieren. Einziger Haken an der Sache ist, dass man die Eckpunkte nicht beliebig vorgeben kann, sondern nur als Vielfache von 360 Grad geteilt durch 2 hoch irgendwas. Das liegt aber wohl nicht am Splitter, sondern am Garmin-Koordinatensystem. Ja klar. Der Nachteil ist aber hier auch, dass die beiden Programme sehr aufeinander angewiesen sind. Mein Ziel wäre, daß man die Kacheln imemr und überall verwenden kann, also auch für die Erstellung von ganz anderen Karten, nicht nur Garminkarten. Naja. Ich fuerchte, dass die Kacheln fuer die Garminkartenerzeugung bestimmte Bedingungen erfuellen muessen (vorallem fuer das Routing ueber Kachelgrenzen hinweg, oder fuer das multipolygon-Handling). Insofern wird es wohl noetig sein, dass ein Split-Programm darauf Ruecksicht nimmt und deshalb das Schnittergebnis zwangslaeufig auf einen Einsatzzweck hin optimiert sein muss. (Ich habe mich nie damit beschaeftigt, was fuer das Inter-Tile-Routing notwendig ist, ich vertraue einfach darauf, dass die Autoren von splitter.jar wissen, was sie da machen.) die Vorteile meines Programmes sind: - festes Raster für die ganze Welt - eindeutige Kachelnummern Das kann splitter.jar auch, siehe oben. - keine Doppelungen von Wegen an Schnittgrenzen Das koennte fuers Routing notwendig sein, - keine abgeschnittenen oder verstümmelten Polygone/Wege Sehe ich nicht als Vorteil, ist wohl eher eine Geschmacksfrage. - keine zusätzlich berechnteten Nodes nötig Auch das koennte fuers Routing notwendig sein, - geringerer Speicherbedarf auf Kosten der Laufzeit (wobei ich nicht weiss wie lange splitter an der ganzen Welt rechnen würde) Pah, als ordentlicher Informatiker verschwendet man keine Gedanken an solche Kleinigkeiten ;-) Wobei bei mir bisher immer mkgmap mehr Speicherhunger hatte als splitter, ich schneide meine Karten allerdings auch maximal aus dem Europa-Auszug von Geofabrik. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkacheln (war: All in One mit git)
2010/3/13 Torsten Leistikow de_m...@gmx.de - keine Doppelungen von Wegen an Schnittgrenzen Das koennte fuers Routing notwendig sein, ja das ist notwendig. jeder weg muss mindestens einen node ausserhalb der kachel haben. mkgmap generiert dann exakt auf der Grenze einen boundary node - keine abgeschnittenen oder verstümmelten Polygone/Wege Sehe ich nicht als Vorteil, ist wohl eher eine Geschmacksfrage. seh ich auch so wozu sollte der Rest gut sein. Deshalb wird ja in Kacheln aufgeteilt damit eben der ganze Rest weg ist. - keine zusätzlich berechnteten Nodes nötig Auch das koennte fuers Routing notwendig sein, splitter generiert keine nodes. mkgmap muss das machen - geringerer Speicherbedarf auf Kosten der Laufzeit (wobei ich nicht weiss wie lange splitter an der ganzen Welt rechnen würde) Die aktuelle splitter version ist sehr schnell braucht relative wenig speicher und kann bei knappem speicher ein komplettes planet files in mehreren iterationen splitten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garminkacheln (war: All in One mit git)
Hi, Apollinaris Schoell schrieb: ja das ist notwendig. jeder weg muss mindestens einen node ausserhalb der kachel haben. mkgmap generiert dann exakt auf der Grenze einen boundary node Wie genau geht das? Muss also mindestens der Weg von beiden Seiten einen node in der jeweiligen Nachbarkachel haben? - keine abgeschnittenen oder verstümmelten Polygone/Wege Sehe ich nicht als Vorteil, ist wohl eher eine Geschmacksfrage. seh ich auch so wozu sollte der Rest gut sein. Deshalb wird ja in Kacheln aufgeteilt damit eben der ganze Rest weg ist. Die Polygone komplett wegzuwerfen finde ich nicht sehr gut. Es ist im Moment so, daß dann ganze Wälder weg sind. Die aktuelle splitter version ist sehr schnell braucht relative wenig speicher und kann bei knappem speicher ein komplettes planet files in mehreren iterationen splitten. Wie lange braucht Splitter und wieviel Speicher genau, um die Welt zu rechnen? -- Viele Gruesse Computerteddy ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
