[Talk-de] Garminkacheln (war: All in One mit git)

[Carsten Schwede]

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