Beiträge von frank334

    Die Frage ist, was will man genau. OSM-Karten braucht man nicht zu konvertieren, weil es genügend Vektorkartenprogramme für Android gibt, wie z.B. OsmAnd. Im Android-Forum gibt es einige Ratschäge für Offroad-Kartenprogramme. Eins kann sogar Ozi-Karten lesen und ein Ozi gibt es auch für Android. Also, wenn es Ozi-Karten gibt, könnte man diese direkt nutzen.


    Es bleibt dann nur bei den Karten, die man für Glopus in so 1000x1000'er Kacheln zerstückelt hat. Aber da ist eine einzige Kachel noch keine richtige Karte. Typisch sind z.B. die 7000 topografischen 1:25000 Kacheln für Bayern-Süd. Die Quelle war aber eine Mercator-Projektion. Also muss jede Kachel eigens kalibriert werden. Im Oruxmaps-sqlite haben die Kacheln aber keine eigene Kalibrierung, sondern werden aus einer Gesamtkalibrierung per Indexwert errechnet. Das funktioniert so nicht mit der Mercatorprojektion. Also würde ich erstmal sagen, auf diese Art kann man es vergessen. Oder man nimmt eine Riesen-Ozikarte (ohne Kachelstückelung) für Android. Aber ob die beiden Programme das vertragen? Dann gibt's noch Kauflösungen wie die Medion-Rasterkarten-App. Es klingt aber so als werden die Kacheln dort einzeln abgerechnet, also dass man seine Topo-Karten-CD damit nicht nutzen könnte. Dann gibt's noch "MagicMaps", auch mit Android-Anbindung. Anscheinend kann man damit aber auch keine ganzen Karten auf Android mitnehmen, sondern nur kleinere Ausschnitte.


    Naja, für mich bleibt Glopus immer noch 1. Wahl bei Radtouren. Solange es die Navis noch gibt, und ihre Akkus durchhalten ...


    Einzigartig bei Glopus:
    - komplette topografische Rasterkarten eines Bundeslandes auf SD-Card für unterwegs mitnehmen
    - Einblendung von Linien und POI aus OpenStreetMap auf die Rasterkarte

    Hier geht's um Glopus, nicht um OziExplorer.


    Ozi kann nur deshalb die Lambert-Projektion, weil es keine Kacheln nebeneinander Darstellen kann. Es kann dort immer nur eine Karte gleichzeitig dargestellt werden. In Glopus kann alles gemischt werden. Damit das funktioniert müssen alle Kacheln die gleiche Projektion haben, im Fall von Glopus eben die übliche Rektangularprojektion. Für Glopus wird wohl eine Entzerrung notwendig sein.


    Im Geotiff steckt diese Offset für die Kalibrierung drin:
    Origin = (50000.000000000000000,6580000.000000000000000)


    Das ist kein WGS84, sondern RGF.


    Die anderen Kalibrierdateien sind auch RGF, wie das WorldFile tfw. Ozi-"MAP" selbst ist nicht dabei.
    In meinem Ozi (aktueller Download->Trial) kann zwar das Geotiff geöffnet werden, es steht "WGS84" und Lon/Lat-Projektion da (der Default), aber keine gültige Georeferenzierung. Die Projektion kann man zwar umstellen, aber die Georeferenzierung fehlt immer noch.

    AGPS unterstützen mittlerweile fast alle Geräte. Ich frag mich aber, ob auch die EGNOS-Korrekturdaten per Internet eingespielt werden können. In Garmin-GPS-Geräten wird mit EGNOS/WAAS-Unterstützung geworben. Sie müssen dafür aber einen eigenen Kanal auswerten (dekodieren). Bei Androids hatte ich den Eindruck, dass sie mehrheitlich auf einem Qualcomm-Chipset aufbauen, der gerade kein WAAS unterstützt. Stimm das? Oder lässt sich das doch irgendwie per Software nachrüsten? Mit AGPS werden lediglich Bahndaten übermittelt. WAAS Korrekturdaten sind m.W. ein eigenständiger Datensatz, der nichts mit AGPS zu tun hat. Eigentlich merkwürdig. Wenn schon eine Datenverbindung besteht könnte man doch beides zusammen übertragen.

    Ich frage mich, ob das überall so schlecht läuft. Bei manchen Geräten dauert der First Fix extrem lange, obwohl AGPS-Daten vorliegen.


    Teilweise scheint es an einer falschen Zeitsynchronisierung im Gerät zu liegen, wo beispielsweise irgendwelche amerikanischen NTP-Server eingetragen sind mit einer Extremlatenz. Mit FasterFix/FasterGPS kann man das auf deutsche NTP-Server umbiegen, z.B. 0.de.pool.ntp.org, indem die gps.conf entsprechende Einträge bekommt. Andererseits gibt es Tools wie "Mobile TimeSync Expert", um die Systemzeit per SNTP oder GPS zu synchronisieren. Hat jemand Erfahrung damit? Oder gibt es auch Android-Geräte, die ab Werk bereits AGPS-unterstützt einen schnellen First Fix finden?

    Die Kalibrierdateien nutzen aber nichts, wenn man das Koordinatensystem bzw. -Datum nicht kennt. Es könnte UTM sein (dann fehlt noch die UTM-Zone), oder das französische RGF93. Die Projektion ist Lambert 93, was aber noch nichts über das Kartendatum aussagt. Ich dachte, Glopus könnte verschiedene Projektionen anhand eines Parameters in den KAL-Dateien unterstützen, z.B. Mercator. Ohne Projektionsunterstützung kann man die Karte in diesem Maßstab nicht nehmen, weil die Positionierung sonst recht falsch laufen würde. An einer "groben Kalibrierung" liegt es sicher nicht - die dürfte bei staatlichen Karten sehr exakt sein. Falsche Projektionen fallen nur bei kleinräumigen Kacheln nicht auf, z.B. die Kacheln aus topogr. Karten. Solch große Kacheln müssten entzerrt werden. Das geht z.B. mit GDAL. Hatte ich mal bei der Deutschlandkarte ausprobiert - es hat funktioniert, sah aber nach der Entzerrung nicht mehr so schön aus. Stattdessen nehme ich für D die Generalkarte, erhältlich für den Geogrid-Viewer (also mit einem Weg zu Glopus).

    Ich habe die Maps mal geladen. Zwar ist es keine Detailkarte, aber als Autobahnübersichtskarte ganz schön. Auf Anhieb konnte ich kein richtiges KAL bekommen. 2 Dinge sind mir unklar:


    - Kann Glopus überhaupt die "Lambert 93" Projektion verarbeiten, wenn ja mit welcher Konfiguration?
    falls nicht könnte man zwar mittels GDAL die Projektion entzerren, aber dann sieht das Rasterbild nicht mehr gut aus, macht dann also keinen Sinn mehr


    - Anscheinend ist das Koordinatensystem UTM. Mein "geotiff2kal-utm-all" sollte eigentlich die UTM-Zone erkennen, ging aber nicht. In der TIF-Information ("gdalinfo") fehlt diese Angabe. Also, welche UTM-Zone liegt vor? Falls man die UTM-Zone kennt, lassen sich auch die World-Files *.tfw auswerten (tfw2kal-utm-all)

    Die geotools Programme&Scripts laufen bei mir alle unter Windows XP. Installation&Benutzung sind allerdings nicht so einfach, vor allem gibt es keine grafische Oberfläche.


    Geotiff kann viel bedeuten. Wenn einfache 4 Eckpunkte in WGS84-Koordinaten drinstecken geht die KAL-Generierung problemlos. UTM geht auch, aber dafür muss man die Zone kennen. Außerdem sind optional noch GCP Kalibrierpunkte möglich (geotiffgcp2kal). Also, nicht so einfach. Man muss also erstmal analysieren was für ein GeoTiff überhaupt dahinter steckt. Als Hilfsprogramme dienen "gdal" und "proj".


    Einfacher geht es sicher mit den kommerziellen GIS-Programmen wie ESRI oder GlobalMapper. Ich hatte mich immer mit der Bastellösung zufrieden gegeben.

    Ja ich weiss, 1000'er Kacheln sind die Empfehlung. Aber 256'er werden sicher auch gut laufen. Wenn es nur ein paar Prozent Performanceunterschied sind würde ich den Aufwand der Konvertierung nicht machen. Vor allem geht es ja auch nicht, wenn die ganze Riesenkarte im RAM liegen muss. Es sei denn der MapManager würde das im Batchbetrieb machen. Meist verliert man ja auch Qualität bei der verlustbehafteten Jpeg-Komprimierung. Ich denke mit dem GMF-Format wird der Nachteil der kleinen Kacheln nicht so groß sein. Kann man ja mal testen ....


    Stimmt, den Offset konnte ich nachvollziehen. Ca. 50-60m Ost-Drift. Ich kann dir mal meine Umrechnungsformeln zur Lon/Lat zu Metrisch geben:


    // long/lat Grade [°] in Länge [m] umrechnen
    double len_x(double delta_x, double y) { return(111325.0*cos(2.0/360.0*Pi*y)*delta_x); }
    double len_y(double delta_y) { return(111325.0*delta_y); }


    Ich hab's selbst nicht nachgerechnet, aber es hat bei mir immer gut gepasst. Es kann sein, dass die Koeffizienten ortsabhängig sind, aber nicht so stark. x geht Richtung Ost und y Richtung Nord. Breitengrad y ist ein Absolutwert, der Rest sind Deltas. Zur Lon/Lat-Korrektur kehrt man die Formeln um:
    delta_x = len_x/111325.0*cos(2.0/360.0*Pi*y)
    delta_y = len_y/111325.0


    Um delta_x wären also bei Ostverschiebung die Längengrade in den KAL-Dateien zu korrigieren.

    Oh ja, interessant. Ich dachte in Google Earth wäre das nur die Umsetzung der 2.6 GB Jpeg2000-Karte. Aber dort ist es tatsächlich schärfer dargestellt. Jpeg selbst ist ja schon i.d.R. größer als Jpeg2000 und wenn dann noch mehr Details drin sind ... Man kann aber auch Jpeg noch gut optimieren. Meist ist Default 80% Qualität eingestellt. Bei Kartenbildmaterial reicht auch oft schon 40% für eine ansehnliche Karte. Bei Irfanview gibt es eine praktische Batch-Bildkonvertierung für solche Aufgaben.


    "Neu berechnen" wird vermutlich nicht nötig sein. Glopus kommt relativ gut mit Riesenkarten zurecht, wenn man das GMF-Format benutzt. Der MapManager ist nicht nötig. Wenn er die ganzen Kacheln im Memory halten müsste wäre das in der Tat problematisch. Einfaches Einpacken der Bilder+KAL geht aber auch so per Commandline. Dann spielt es fast keine Rolle wie viele es sind.


    Den Kartenoffset könnte man leicht beseitigen solange er konstant auf der gleichen Kartenfläche vorhanden ist. Dazu müsste man nur auf den KAL-Kalibrierdaten einen kleinen Offset addieren. Aus dem metrischen Offset lässt sich ein Long/Lat-Offset berechnen (natürlich nicht für die ganze Weltkugel einheitlich, aber für den Landkreis wird der Approximierungsfehler klein bleiben).


    p.s. wer nachträglich noch einen Ausschnitt aus der Karte produzieren will: dafür habe ich das "gmf-selection"-Programm geschrieben. Man definiert in Google Earth oder Geogrid Viewer einen Polygonausschnitt und gmf-selection erzeugt ein neues GMF mit Kacheln aus dem entsprechenden Ausschnitt. Großer Vorteil gegeüber man anderen Tools: der Ausschnitt muss nicht rechteckig sein sondern schön sauber genau das was man auch braucht, ohne unnötig Platz für uninteressante Gebiete zu verschwenden.

    Approximation meinte ich auch nicht, sondern mehr Interpolation als exakte Rekonstruktion. Solange die Nyquist-Bedingung eingehalten wird kann man theoretisch exakt mit Subpixelpositionen umgehen. Im Subpixelbereich sind Berechnungen oft einfacher wenn eine mittige Lage angenommen wird, gerade bei digitalen Filtern oder Korrelatoren. Praktische Beispiele für Subpixelverarbeitung sind das Antialiasing oder Motion Estimation in übertakteten TV-Geräten. Neuere Literatur ist voll von Schlagwörten wie "sparse sampling", "compressed sampling" oder super-resolution. Sehr interessant, aber natürlich bei der Glopus-Kartenkalibrierung wenig relevant ...

    Wenn man das so versteht wäre es durchaus exakt. Dann wäre die
    WGS84-Referenz nicht auf die Pixelmitte bezogen. Bei
    Interpolationsproblemen nehme ich sonst immer die Samplemitte als
    Ankerpunkt. Es gibt technische Anwendungen wo die Lage der Indizes
    durchaus eine Rolle spielt. Aber hier würde es wohl kaum auffallen.

    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.).

    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.

    Dateien

    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.