auch noch auswertet, und man dann im Typfile dieselbe Flaeche mit unterschiedlicher DP anlegt (dazu gibt es aber nicht genug IDs).
Reichen die 16bit IDs nicht aus? Man muss ja nicht jedem Polygon eine eigene ID verpassen. Aber der ID Raum sollte doch ausreichen, um alles in der richtigen Reihenfolge zu zeichnen. Sicher, dass man das Problem nicht auch durch cleveres Strukturieren der Daten lösen kann?
Was mir nicht gefallen hat: Bei Einstellung details=-1, sieht man max resolution 22, resolution 24 wird dann gar nicht angezeigt. Besser waere wenn es so wie in Mapsource gehandhabt wird, dass es einfach nur einen Zoomschritt spaeter/frueher kommt.
Hm, ja, bei den Details manipuliere ich nur die Zuordnung Zoomlevel<->Bits. Und daraus resultiert der Maplevel. Das ist nicht gut. Besser wäre es wie Garmin damit Elementfilter zu steuern, die bestimmte Elementgruppen anzeigen oder unterdrücken. Wenn es halt nicht so ein erbärmliches Gefrickel wäre...
Ausserdem scheinen mir die Zoomschritte zuerst recht langsam weniger Detail, dann aber sind recht schnell alle Details weg. Mapsource/GPS aendern die resolutionen weniger rasant.
Die Zuordnung Zoomlevel<->Bits ist auf Garminkarten abgestimmt und behält ein wenig länger die höchste Detailstufe als MapSource auf "normal". IMHO sollte das die Referenz sein. Wenn Dir das zu rasant ist fehlt ein Level 
Drittens, faende ich es gut wenn ab dem Zeitpunkt wo keine Daten mehr vorliegen, die Kachelgrenzen angezeigt werden. So denkt man sich manchmal dass die Karte gar nicht funktioniert (klar ist F3 und dann reinzoomen immer funktionierend, nur wenn man Mapsource gewoehnt ist, dann denkt man die Karte ist kaputt/fehlt).
Das ist ein Feature von deiner Karte. Alle anderen haben ihre Kachelgrenzen ordentlich in der Basemap abgelegt. Es funktionieren sogar mit nicht rechteckige Grenzen verschiedener Auflösungen.
Nachtrag: ich sehe gerade, es funktioniert doch auch mit deiner Karte. openmtbmap_de. Wo liegt das Problem? 
Nachtrag2: Bei der openmtbmap_dby_09.11.2009 geht es nicht. Da sind nur 2 Rechtecke zu sehen. Da scheint der Wurm in der Basiskarte zu sein.
Ist aber nicht so wichtig, nur halt etwas ungewohnt. Wichtiger waere das was wir schon "hatten. Etwa vorauscachen oder aehnliches um schnelleren Kartenaufbau hinzubekommen. Aber soweit ich dich verstanden hab, wird das nicht gehen da die Renderingengine ja nicht von dir kommt, bzw waere es superviel Aufwand.
Doch die Renderengine kommt 100% von mir. Nur mit dem Cachen habe ich Probleme. Ich will nicht das gleiche Datengrab wie MapSource bauen. Interessanter wäre in diesem Fall die Polygone in einem Thread zu zeichnen, und das Gui peu a peu neu zu Zeichnen. Auf einem Singlecore dauert das länger, auf einem Multicore ungefähr gleich. Gefühlt wird es wahrscheinlich schneller, weil sich was tut und das Gui nicht blockiert. Ist reine Psychologie.
Ist jetzt eh schon viel viel besser wie noch vor ein paar Versionen. Evtl waere es ja auch moeglich dass die Linien nacheinander aufbauen, und nicht alle auf einmal, oder beim pannen duenne schwaerze Ersatzlinien angezeigt werden, die dann uebermalt werden. Falls die Bitmaps das Problem sind, koennte Qlandkarte GT evtl intern ein ExpressTypfile erstellen, welches nur einfarbige duenne Straßen hat (basierend auf einer verwendeten Farbe), und dann von den korrekten Bitmaps uebermalt wird.
Das ist mit 0.17.0 Geschichte. QLGT benützt jetzt nur noch Bitmaplinien wenn diese explizit im Typ so eingestellt wurden.
Ich wuerde eh noch resolution=23 in die Karten aufnehmen, um 22 etwas zu leeren, aber die Kartengroeße fuer Downloads steigt dadurch halt recht stark an (wenn ich 24,23,22,21,20,19,18,16 statt 24,23,22,21,20,19,18,16 benutze - je "hoeher" die resolution desto teurer ist jedes extralevel.)
Wenn es schön smooth gehen soll ist eine Leveleinstellung wie bei den Garminkarten unumgänglich. Eine Basiskarte mit einem groben Straßennetz und Hauptstädten würde auch dazu beitragen.
Grüße
Oliver
).