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