Hallo Mobutu,
das ist schon richtig.
Beim Oziexplorer durchläuft man ein Importmenue und ich habe eigentlich nur die Vorauswahl bestätigt.
Später habe ich es mit dem Geoid Potsdam Rauthenberg versucht.
Der Track lag dann aber deutlich neben der Wirklichkeit.
Klaus
Mea culpa: hatte die OziGeoTiff.dll noch nicht nachgerüstet. Trotzdem, bei Import über die vorgewählten Einstellungen ist meine map drastisch falsch (mehrere geogr.Grad). Das jp2 selbst (zu sehen in den Viewern) ist bei einer Kontrolle mit der DTK25 ziemlich präzise (0,1 bis 0,4sek in beide Richtungen).
Mir ist nicht bewußt, dass ich diese dll nachgerüstet habe. Geotiff-Karten habe ich kaum benutzt.
Beim Export vom Geo Viewer habe ich die Erstellung eines Worldkalibrationfile mit angehakt und auch eine tfw bekommen.
Der Import von DRG-Karten ist m.W. ein Standardmenue beim Ozi und das weiß anscheinend mit der tfw-Datei umzugehen.
Klaus
Auf einem W7-Rechner habe ich mit dem Geo Viewer einzelne Karten nach Geotiff exportiert und diese im Oziexplorer Trial geladen.
Das Exportformat ist offenbar wirklich egal, die tfw/pgw-Kal-Datei zeigt jedenfalls die Eckwerte, wie sie auch im GeoViewer (per Zoomstufe) gewählt wurden. Mir scheint, ein systemischer Fehler liegt bei mir: zeigt der GV offenbar genaue Lat/Lon-Daten, kann ich die WGS84/World-Mercator-Werte nicht überprüfen; es sind jedenfalls nicht die UTM-Werte. Im GV wähle ich als CRS Native (sonst ist die Karte sehr verzerrt); stimmt es soweit (Bsp Maximilianeum München)? Im Ozi-Import (DRG) lasse ich alles Vorgewählte, aber es misslingt immer.
Hallo,
hier ist eine Karte mit Track in der Standardkalibrierung.
Ich bin mit dem Ergebnis zufrieden.
Klaus
Danke, Klaus, für die Präzisierung: ganz klein ist der Link "Full Image Download", ein jp2 von 2,5GB.
Der angesprochene Viewer bzw das Plugin funktioniert ja tadellos, auch dies ein superwertvoller Tipp! Für Recherche und Trockenflüge noch smarter verwendbar als Ozi. Frage: die Kalibrierungspunkte müssen beim Laden des TIFF manuell gesetzt werden? Dachte, GeoTIFF beinhaltet Kal-Daten - oder welche Importparameter muss ich bei Ozi auswählen?
Da hatte ich auch lange gesucht. Vor lauter Einzelblätter hatte ich auch anfangs die "composite" Karte nicht gefunden. Interessanterweise trägt jp2 auch gleich die Kalibrierung. Nun ja, so ein File ist nicht so praktisch zu handhaben wie die große Google-Earth Overlaykarte.
GeoTIFF kann auf verschiedene Weise Kalibrierungen enthalten (control points, borders etc.) enthalten. Im Rahmen der "geotools" hatte ich damit experimentiert. Manche konnte ich auslesen und verarbeiten, manche auch nicht. Eine Alternative sind die "world files" tfw, für die ich einen KAL-Konverter geschrieben hatte (in der Scriptsammlung).
In Google Earth ist die Ansicht praktisch, weil Vektorelemente und POI aus der aktuellen Karte überlagert werden können. Die interessantere Frage hier im Forum wäre natürlich, wie man die Karte auf Glopus bekommt. Leider ist die Exportgröße des GeoViewers sehr beschränkt (kein GeoTIFF full export), nur 6000x6000 pixels.
Am besten wäre es, wenn man die GoogleEarth-Overlays herunterladen würde und die handlichen Kacheln für Glopus aufbereitet. Dann hätte man gleich eine Multilevel-Zoomansicht. Die Konvertierung der Kacheln mit KAL-Generierung würde ich hinbekommen. Auch geografische Selektion von Gebieten im GMF wäre kein Problem. Nur der Download ist etwas schwieriger, weil die KMZs für die Hierarchie interpretiert werden müssen. Ich hatte es mit einfachen regex(sed) scripts probiert, aber das ist dafür wohl zu komplex. Man sollte es besser mit einem richtigen KML/XML-Parser machen. Kennt jemand Beispielcode zu so einem Thema?
Frage an die Spezialisten:
habt ihr einen Tipp für ein Konvertierungsprogramm JP2 nach JPG od PNG ?
Kalibrierinfo muss nicht zwingend erhalten bleiben.
Habe es mit verschieden Programmen aus dem Netz probiert, scheitern aber alle. Selbst Irfanview bringt mir immer einen Abruch wegen Dekodierungsfehler (auch nach Upgrade auf die neueste JPG2000.dll vom 26.3.2012)
Besten Dank für Eure Tipps
Bernd M aus F
habt ihr einen Tipp für ein Konvertierungsprogramm JP2 nach JPG od PNG ?
Wie vorhin beschrieben kann der Lizardtech GeoViewer JP2 lesen und nach Tiff/PNG/JPG exportieren, auch die Worldfiles zur Kalibrierung:
http://www.lizardtech.com/downloads/viewers.php
Intern nutzt er einen Haufen OpenSource-Komponenten wie GDAL. GDAL selbst kann es auch. Damit hatte ich experimentiert und z.B. einen Glopus-Kachelextraktor geschrieben (läuft leider sehr sehr langsam bei Riesenkarten). Auch für die World-Files zu Glopus-KAL-Konvertierung hatte ich Scripts gemacht. Details dazu finden sich in der Beschreibung der "geotools" Sammlung.
Klingt irgendwie alles ziemlich kompliziert. Kann nicht jemand fertige GMFs zum Download bereitstellen? Das Urheberrecht ist ja lange abgelaufen.
Dazu müsste man das GMF erstmal haben. Es gibt 2 Alternativen:
- 1. Gesamtkarte in Kacheln splitten
- 2. die für Google Earth bereits in handliche Kacheln zerteilte Kartenstücke laden
Zu 1. habe ich das Tool "geotiffsplit"-Script das man evtl. anpassen könnte. Leider ist es bei Gigabyte-Karten extrem langsam und kommt kaum zum Ende. Das hatte ich mit Nasa-Weltkarten bereits probiert. Ob das mit JP2 auch funktioniert wie in den Features angegeben weiss ich nicht. Alternativen wären GlobalMapper oder andere kommerzielle Tools, die in Kacheln teilen können. Meine Bedenken sind allerdings, dass die Kalibrierung der Gesamtkarte nicht so perfekt ist, dass sie bei der Nahansicht der Topokarte noch stimmt.
Zu 2. nimmt man den Google-Earth-Link der Overlay-Karte als Ausgangspunkt. KMZ sind gezippte KML-Dateien, in denen die unteren Hierarchien referenziert werden. Man müsste die KMLs interpretieren und rekursiv downloaden. Die Konvertierung in das KAL-Format ist kein Problem (Eckkalibrierpunkte). Mein einfacher Ansatz per rekursivem Bash-Script und Regex-URL-Extraktion war leider nicht gelungen. Wenn jemand den rekursiven Download anders programmieren kann, wäre der Weg ins GMF nicht mehr so schwierig. Ich habe momentan leider keine Zeit zum Programmieren.
Zu 2. nimmt man den Google-Earth-Link der Overlay-Karte als Ausgangspunkt. KMZ sind gezippte KML-Dateien, in denen die unteren Hierarchien referenziert werden. Man müsste die KMLs interpretieren und rekursiv downloaden. Die Konvertierung in das KAL-Format ist kein Problem (Eckkalibrierpunkte). Mein einfacher Ansatz per rekursivem Bash-Script und Regex-URL-Extraktion war leider nicht gelungen. Wenn jemand den rekursiven Download anders programmieren kann, wäre der Weg ins GMF nicht mehr so schwierig. Ich habe momentan leider keine Zeit zum Programmieren.
Hab das 'mal "per Hand" im Browser gemacht und habe das Prinzip halbwegs verstanden (die "Folder" sind mir noch etwas schleierhaft). Ich wollte mich ohnehin mal wieder mit Programmierung beschäftigen und behaupte vorsichtig, dass ich das Herunterladen hinbekommen sollte. Nur wie ich von den "north", "south", "east" und "west"-Werten auf Kalibrierungspunkte für Glopus komme, ist mir unklar. Oder soll ich Dir die vier Werte einfach 1:1 in eine Datei schreiben? In welchem Format? Kannst Du eine Beispieldatei anhängen, wie das aussehen soll?
MfG
Edit: OK, wie ich KAL-Dateien aus den Werten bauen kann, habe ich herausgefunden. Noch eine Frage: Die Kacheln, die ich manuell heruntergeladen habe, sind verschwommen. Wahrscheinlich interessieren für unser Projekt nur die Kacheln der "untersten Ebene" / maximalen Zoomstufe. Woran erkenne ich diese "unterste Ebene"? Ein Link zu einer Beispiel-KMZ der untersten Ebene wäre hilfreich.
Edit: OK, wie ich KAL-Dateien aus den Werten bauen kann, habe ich herausgefunden. Noch eine Frage: Die Kacheln, die ich manuell heruntergeladen habe, sind verschwommen. Wahrscheinlich interessieren für unser Projekt nur die Kacheln der "untersten Ebene" / maximalen Zoomstufe. Woran erkenne ich diese "unterste Ebene"? Ein Link zu einer Beispiel-KMZ der untersten Ebene wäre hilfreich.
Stimmt schon, die obersten Zoomlevels bringen nicht viel, weil die Karte darauf nicht optimiert ist. Es sind im Original viele einzelne Kartenblätter. Nur es hilft nichts, die Hierarchie durch die KMZ-Dateien muss der Downloader trotzdem durchrattern. Bei 2 GB macht das keiner von Hand. Aber auch wenn man nur Ausschnitte haben will ist der Weg über die ganze Karte praktisch - mit dem gmfselect-Tool kann man daraus geografisch begrenzte Gebiete (Polygone) ausschneiden.
Die unterste Ebene wird erkannt, wenn keine weiteren KMZ mehr referenziert werden, d.h. nur das PNG-Image drin ist. Anhand der Verzeichnispfade kann man die Pfadtiefe erkennen. Da das Gebiet aber nicht rechteckig ist hilft es nicht, mit 2 einfachen For-Schleifen die Kachelnummern zu iterieren.
Mit regular expressions (sed) und bash bin ich beim rekursiven Abstieg leider an Grenzen der einfachen Scriptsprachen gestossen. Man müsste wohl was leistungsfähigeres nehmen. Z.b. in Python kann man alles mögliche implementieren, die Unzip-Routine, XML/KML-Parser etc. Man muss nur etwas Zeit dafür übrighaben ....
p.s. falls es jemand doch mit bash/sed probieren will, hier mein Ansatz im Anhang. Das KMZ wird entzippt und die Referenzen im doc.kml extrahiert. Mein Problem war meine ich, dass es Mehrdeutigkeiten bei den Referenzen gab, die man so einfach nicht interpretieren konnte. Hatte leider keine Zeit mehr, das Problem weiter zu untersuchen.
So, lädt gerade (mit Java)... Wird etwas dauern, da ich noch nicht beim Kapitel "Threads" angekommen bin 
Die Kalibierung mit Point(0,0) und Point (256,256) wie im Beispiel auf der Glopus-Homepage kommt mir bei 256x256 Pixeln noch etwas spanisch vor?
Wohin kann ich das fertige GMF hochladen?
MfG
Die Kalibierung mit Point(0,0) und Point (256,256) wie im Beispiel auf der Glopus-Homepage kommt mir bei 256x256 Pixeln noch etwas spanisch vor?
Wohin kann ich das fertige GMF hochladen?
Da hat man sich wohl um 1 Pixel verrechnet oder es bei den Arrayindizes nicht so genau genommen. Das hat mich auch gewundert.
Aber andererseits muss man es so verstehen: die Kalibrierpixel indizieren nicht direkt die Bitmap-Pixel, sondern sind nur für die Koordinatenumrechnung relevant. So gesehen dürfen die dann sogar außerhalb der eigentlichen Bitmap liegen, als gedachte Bildpixel zur WGS84-Sollkoordinate. 1 Pixel Ungenauigkeit fällt visuell kaum auf.
Zur Speicherung: die GB große Nasa-Weltkarte hatte ich bei radpidshare geladen. Anmeldung ist nicht erforderlich. Nur wird es dort gelöscht, wenn längere Zeit kein Download durchgeführt wurde. Ab einer bestimmten Größe ist eine Stückelung notwendig (ZIP- oder rar-Split, Unix split etc.).
Da hat man sich wohl um 1 Pixel verrechnet oder es bei den Arrayindizes nicht so genau genommen. Das hat mich auch gewundert.
Aber andererseits muss man es so verstehen: die Kalibrierpixel indizieren nicht direkt die Bitmap-Pixel, sondern sind nur für die Koordinatenumrechnung relevant. So gesehen dürfen die dann sogar außerhalb der eigentlichen Bitmap liegen, als gedachte Bildpixel zur WGS84-Sollkoordinate. 1 Pixel Ungenauigkeit fällt visuell kaum auf.
Eine "Ungenauigkeit" spielt da keine Rolle. Nicht vergessen: ein Pixel in einer Bitmap entspricht einer Fläche! Wenn man sich darauf einigt, dass (0,0) die obere linke Ecke eines Bitmap-Bereichs darstellt, geben die Koordinaten des Punktes (256,256) die Koordinaten der unteren rechten Ecke einer Bitmap (0,0)-(255,255) an.
Grüße
Helge
