Magellanboard.de

Hi zusammen...
vielleicht hat jemand eine Antwort...

Warum bzw. woher kommen die Beschränkungen des *rmp-Formats?
- 18.000 * 18.000
- 2GB

Lässt sich daran ggf. irgendwas drehen? - Welche Folgen hätte es?
Danke,
Haiko

Pico2220 hatte dies aufgebracht und auch so in seinem code untergebracht.
Größere rmps als (18k x 18k) sind aber durchaus möglich, theoretisch jedenfalls... da aber sein Code in allen funktionierenden Tools zu finden ist, ist es praktisch momentan nicht möglich.

Möglicherweise bau ich mal einen Compiler der das macht.

Aber die 2GB Grenze, liegt m.E. am FAT system des Speichers und der Speicherkarten, welche größere Dateien nicht verwalten können. Dies kann man aber mit meinem RMP Tool umgehen und ihnen die gleiche Gruppe zuweisen. Dann werden sie gemeinsam angezeigt, auch wenn sie in mehreren Dateien liegen.

VG
Sockeye

Hi,

erstmal Danke für die Informationen...

Ich stoße nämlich immer wieder an die Größenbegrenzung 18.000 * 18.000 wobei ich bei 2 GB keine Probleme sehe.
Meine Ø Kartengröße (Erstellt mit MOBAC) beläuft sich auf ca. 30-60 MB...

Wenn ich allerdings über Zoomstufe 15 hinaus möchte... bekomme ich immer die Meldung der Beschränkung von Pkt. 1

Es ist ewig her, dass ich das RMP Format analysiert habe, wenn ich es aber recht im Kopf habe war das so:
das RMP Format besteht intern aus Kacheln der Größe 256x256. Für die Kacheln gibt es eine Art Index, dessen "Offset-Zeiger" eine maximale Größe haben. Damit kann der Index nicht beliebig wachsen. Die Größe von 18k x 18k wurde so gewählt, dass alle möglichen Kartenformen im Index abbildbar sind. Größere Karten sind daher grundsätzlich möglich aber es kann eben Sonderfälle geben, bei denen das Format dann nicht mehr funktioniert. Aber selbst wenn man die 18k x 18k Grenze entfernen würde, käme man mit Sicherheit noch weit vor der 2GB Grenze an die maximale Größe des Index. (Wenn ich mich recht erinnere, wäre bei einer quadratischen Karte bei knapp über 20k x 20k endgültig Schluss. Die 2GB Grenze ist nur relevant, wenn mehrere Layer in einer Karte enthalten sind und diese somit in der Summe mehr als 2GB groß werden.

Hi pico,

vielen Dank für die ausführliche Info

pico2220 wrote:Es ist ewig her, dass ich das RMP Format analysiert habe, wenn ich es aber recht im Kopf habe war das so:

Hi pico

Darf ich den Thread wiederbeleben?

Ich sitze gerade über dem Code in Mobac. Ich vermute mal den hast Du geschrieben. Was mir dabei auffällt ist, dass vom ersten Block im TLM Abschnitt aus es immer einen "Previous" Block gibt und dann weitere "Following" Blöcke. Warum macht man das so? Würde nicht einfach ein Block mit lauter "Following" Blöcken reichen? Hat das einen technischen Hintergrund, oder ist das einfach Spielerei weil es geht?

Die Sache mit den 18kx18k bzw 20kx20k Limit kann ich inzwischen nachvollziehen. Sind diese Zahlen eigentlich in Stein gemeißelt? Immerhin wird der Zähler 99 für die Blöcke ja mit abgespeichert. Könnte man den erhöhen? Bekommen dann die Geräte das Grausen?

In wie weit ist eigentlich die Kachelgröße auf 256x256 limitiert? Könnten das auch 512x512 sein? Oder 1024x1024?

Ich frag deswegen so doof, weil ich wohl früher oder später für QLandkarte GT einen Konverter GeoTiff -> RMP schreiben werde. Und da wäre es ganz praktisch zu wissen, was wirkliche bekannte Limits sind und was einfach nur so angenommen wurde. Dann wird der Code vielleicht ein wenig sauberer.

pico2220 wrote:Aber selbst wenn man die 18k x 18k Grenze entfernen würde, käme man mit Sicherheit noch weit vor der 2GB Grenze an die maximale Größe des Index. (Wenn ich mich recht erinnere, wäre bei einer quadratischen Karte bei knapp über 20k x 20k endgültig Schluss.

Also RMP-Karten mit 1,95 GB habe ich auch schon mit Mobac erstellt. Siehe unten.

Die 2GB sind durch das Filesystem vorgegeben.

Interne Grenzen müssten getestet werden. Pic hat mehr oder weniger das NatGeo RMP Format nachprogrammiert.

VG
Sockeye

kiozen wrote: Ich sitze gerade über dem Code in Mobac. Ich vermute mal den hast Du geschrieben. Was mir dabei auffällt ist, dass vom ersten Block im TLM Abschnitt aus es immer einen "Previous" Block gibt und dann weitere "Following" Blöcke. Warum macht man das so? Würde nicht einfach ein Block mit lauter "Following" Blöcken reichen? Hat das einen technischen Hintergrund, oder ist das einfach Spielerei weil es geht?

Das Problem beim RMP Format ist, dass es dazu keine offizielle Dokumentation gibt. Alles was man tun kann, ist bestehende Muster anzuschauen und das so gut wie es geht nachzubilden. In den (wenigen) verfügbaren Mustern war das immer so, deshalb habe ich es auch übernommen. Ob das zwingend so sein muss, weiß aber höchstens Magellan selbst, wenn überhaupt. Es kann natürlich sein, dass diese ungewöhnliche Reihenfolge ein Bug in der Magellan Software ist, die bisher nur noch niemand entdeckt hat.

kiozen wrote: Die Sache mit den 18kx18k bzw 20kx20k Limit kann ich inzwischen nachvollziehen. Sind diese Zahlen eigentlich in Stein gemeißelt? Immerhin wird der Zähler 99 für die Blöcke ja mit abgespeichert. Könnte man den erhöhen? Bekommen dann die Geräte das Grausen?

Nach damaligem Stand war das nicht erweiterbar. Allerdings habe ich auf einem Triton getestet. Die aktuellen Explorist Geräte haben da möglicherweise keine Probleme. VantagePoint konnte schon immer einiges Anzeigen, was auf dem Triton dann nicht mehr funktioniert hat

kiozen wrote: In wie weit ist eigentlich die Kachelgröße auf 256x256 limitiert? Könnten das auch 512x512 sein? Oder 1024x1024?

Hier gilt das Gleiche: In VantagePoint ist eine andere Kachelgröße überhaupt kein Problem. Der Triton kann aber nur 256x256. Es ist denkbar, dass der Explorist auch mehr kann als nur eine Größe. Da ich aber nie einen Explorist besessen habe, habe ich immer nur mit meinem alten Triton getestet.

Andreas

Hallo Andreas,

vielen Dank für die Erklärungen. Ich werde das dann genauso machen müssen, um zu den Tritons kompatibel zu bleiben. Macht es halt noch einen Tick komplizierter. Ich frag mich nur warum sich Magellan ein so aufwändiges Format ausdenken, um dann doch weit hinter den Möglichkeiten zu bleiben. Aber das wissen die wahrscheinlich selber nicht

Eine Sache, die mir noch aufgefallen ist, sind die weißen Ränder. Die kommen weil jede Kachel aktuell zwingend 256x256 Pixel haben muss. Und damit werden die Randkacheln nicht unbedingt ganz ausgefüllt. Rein von der Logik muss das nicht sein. Jede Kachel hat ihre eigene Koordinate. Und in JPEG sind die Dimensionen in Pixel abgespeichert. Zusammen mit der Kachelskalierung könnte man auch Kacheln kleiner 256x256 richtig anzeigen. Die Frage ist nur: Machen das die Geräte? Wurde das schon mal ausprobiert?

Gibt es bei der Unterteilung noch irgendwelche Grenzfälle? Oder ist man da frei solange man die 100 Container mit 100(80?) Kacheln nicht überschreitet?

Anzeigen kann ich die RMP Dateien schon. Ich habe mit MOBAC auch mehrere RMPs erstellt und diese über die Produkt und Provider ID verbunden. Sprich man lädt in QLGT eine RMP Datei und QLGT findet die anderen Dateien im Verzeichnis. Keine Ahnung ob das auch mit anderen Karten geht. Ich habe nichts anderes zum testen. Wenn Interesse besteht kann ich auch gerne ein Binary für Windows mit dem aktuellen Entwicklungsstand aufsetzen.

Ich hoffe dass ich bald mein 610er zurück bekomme und es endlich funktioniert wie es soll. Dann kann ich mit dem Export richtig anfangen. Wenn ich es richtig sehe gibt es keinen GeoTiff -> RMP Konverter der unte Linux, OS X und Windows läuft, oder?


Grüße

Oliver

Noch mehr Fragen

Wenn ich eine Karte mit Übersichtskarten habe, kann ich die ja in eine RMP Datei stopfen. Jede Karte in ihrem eigenen Level. Sollte ich aber die magischen 20736x20736 Pixel im detailreichsten Level überschreiten, dann muss ich mehrere RMP Dateien anlegen. Soweit so gut. Dazu muss ich aber auch die Übersichtskarten zerschneiden. Und, gesetzt den Fall, dass man immer ganze 256x256 Kacheln gefüllt haben möchte um weiße Ränder zu vermeiden, dürften diese Übersichtskarten etwas größer als die Karte mit der höchsten Auflösung sein.

Daraus folgt, dass in den Übersichtsebenen die Karten sich überlappen. Funktioniert das ohne Fehler?

Wenn man das jetzt ein wenig weiter spinnt, könnte man auch sagen, man verpackt jede einzelne Karte in ein oder mehrere Dateien. Sprich jede RMP Datei hat jetzt nur einen Level. Z.B. würde sich eine Karte von mir in 6 RMP Dateien für die detailreichste Karte, in 2 RMP für die nächste Detailstufe und eine RMP Datei für die letzte Übersichtskarte aufteilen. Also 9 Dateien mit unterschiedlichen Auflösungen vom selben Gebiet. Über die Provider und Product ID als ein Kartensatz verbunden.

Würden die Geräte so etwas richtig anzeigen? Oder anders gefragt: Wird bei Dateien, die sich überlagern immer die mit der besten Auflösung für den jeweiligen Zoomlevel verwendet? Oder müssen alle Dateien immer die selben Layer mit den selben Auflösungen haben, wenn sie zu einem Kartensatz verbunden werden.

Ich hoffe die Fragen sind verständlich

Oliver

Also da muss ich jetzt passen. Mit mehreren Karten, die sich überlappen, habe ich noch nicht experimentiert.

Naja, bei Mobac entsteht eigentlich teilweise das gleiche Problem. Die Karten in den gröberen Ebenen sind größer als die eigentliche detaillierte Karte. Wenn ich zwei solche "Mobac" Karten nebeneinander habe überlappen die sich in den gröberen Zoomleveln. Was würde dann auf dem Gerät passieren? Beim 610er kann ich es hoffentlich bald ausprobieren. Aber wie würden sich die Tritons verhalten?

@Sockeye Wie machst Du das eigentlich mit deinen Rasterkarten? Sind dort verschiedene Karten mit unterschiedlicher Auflösung drinnen. Oder ist jeder Level im RMP nur ein skaliertes Abbild der Grundkarte.

Hm... ich könnte natürlich die Übersichtskarten auch auf ein ganzzahliges Vielfaches der Grundkarte skalieren, damit alle Ebenen exakt die gleiche Fläche mit einer ganzzahligen Anzahl an Kacheln abdecken. Ist halt immer schade schon zu Beginn eine Skalierung einzubauen. Beim nochmaligen Skalieren auf dem Gerät wird es ja nicht besser.

Ok, beim Graben im Forumsarchiv fündig geworden. Überlappende Karte werden am Rand mit einer orangen Linie versehen. Und das geht wohl auch mit verschiedenen Auflösungen.

Karten mit nur einem Layer werden auf der optimalen Zoomstufe +-1 angezeigt.

Sprich, ich muss wohl doch die unterschiedlichen Karten bröckerlweise in den RMP Dateien verpacken.

Sorry for Offtopic, aber ich bewundere Deinen Elan!