Beiträge von frank334

Zitat von Silver34

Man wird es kaum glauben aber er kann!
Einzig man muß es ihm sagen!

Stimmt. Kaum zu glauben. Der "primitivste Editor aller Zeiten" kann UTF, sogar unter XP/SP3.
Ich benutze ausschließlich Notepad++, auch zum Programmieren.

Übrigens: man beachte, die jp2-Gesamtkarte ist deutlich unschärfer
als das GoogleEarth-Overlay hier:
http://rumsey.s3.amazonaws.com/Germany1893.kmz

Manche Beschriftungen kann man im jp2 kaum noch lesen.

Leider hatte ich es noch nicht geschafft das Overlay herunterzuladen. Dazu müssen die Links in den KMLs rekursiv verfolgt werden. Im Ergebnis hätte man sofort scharfe Glopus-taugliche Kacheln, wenn die Kalibrierdaten im KML in KALs umgeschrieben werden. Insgesamt ist alles nicht schwierig. Man müsste nur Zeit zum Programmieren haben.

Übrigens habe ich hier einen relativ einfachen Weg vom Geotiff zu Glopus beschrieben:

Historische Karten und GLOPUS

via MapTiler und Mobile Atlas Creator am Beispiel der Reichskarte (Geotiff-Export vom .jp2).
Das dürfte auch für andere Geotiff-Karten funktionieren.

MapTiler steuert GDAL an, so wie ich es im "geotiffsplit" gemacht hatte, bietet aber eine grafische Bedienoberfläche.

Ach was mir noch auffällt: das XML-Encoding ist UTF-8. Dein Editor muss das natürlich auch können. Ob der Windoof-Notepad das kann wage ich zu bezweifeln. Nimm einen Profieditor wie "Notepad++". Der kann UTF und auch XML-Syntaxhighlightning.

Wie gesagt, deine mobac-Version ist vermutlich veraltet (1.9 final) und kennt das <backgroundColor>-Feld noch nicht. Aktuell ist die Version 1.9.8. Entweder du machst einen Update oder versuchst es mit einer Anpassung des XML.

p.s.
Man kann auch mehrere mobac-Versionen in versch. Verzeichnissen parallel installieren, falls man seine Alte behalten will. Die Kachelverzeichnisse würde ich sowieso auf eine große Datenpartition auslagern. Anpassung der Pfade in "settings.xml" so

<directories>
<atlasOutputDirectory>d:\download\karte-mobac</atlasOutputDirectory>
<tileStoreDirectory>d:\download\karte-mobac\tilestore</tileStoreDirectory>
</directories>

Zitat von Wunibald

Hallo Frank,
ich bin auch ganz begeistert von dieser Karte, aber schaffe die Integration in MOBAC nicht.
Könntest Du die einzelnen Schritte genauer beschreiben, besonders auch die Kartenquellendefinition.
Ich bekomme diese Fehlermeldung.

Die obige Methode ist eigentlich sehr einfach und intuitiv (ohne commandline :-).

Die Fehlermeldung besagt, dass dein mobac den Tag "backgroundColor" nicht versteht.
Hast du auch die aktuelle Version?
Weiterhin muss natürlich der Dateipfad <sourceFolder> zu den lokalen Tile-Quellen in der XML-Datei angepasst werden.

Wie es genau mit den ext. Kartenquellen in mobac funktioniert steht in der mobac-Anleitung. Die hier Multi-Layer-Methode war für die <localTileFiles> zwar nicht dokumentiert, geht aber trotzdem.

Interessant wäre es vielleicht noch, das OSM-Wegenetz zu überlagern (transparente Layer), wie es Glopus mit den Vektordaten macht (also ohne die Füllflächen). Gibt es dazu OSM-Tile-Quellen online? Das sollte natürlich nicht den Kontrast der Rasterkarte beeinflussen. Für Glopus ist das zwar wegen der IMG-Vektorkarten nicht nötig, aber auf Smartphones habe ich so eine schöne Raster-Vektor-Überlagerung noch nicht gesehen, bzw. nur durch Mischen der Layers und resultierender Kontrastminderung. Auch die offiziellen (numerierten) Rad-/Wanderwegenetze wären sehr schön für eine Überlagerung.

Wer mit dem Smartphone durch die Landschaft fährt, kann nun auch mal schauen, was
es dort 1893 schon alles gab. Die Karte des deutschen Reiches ist recht detailliert.

http://www.davidrumsey.com/blo…es-deutschen-reiches-1893

Die Gesamtkarte kann in JPEG2000-Form geladen werden, 2.6 GB groß:

http://rumsey3.s3.amazonaws.co…ny1893GeoJP2/g5820727.jp2

Das ist natürlich noch zu groß für Smartphone-GPS-Programme. Mit dem GeoViewer können aber regionale Ausschnitte als Geotiff gepeichert werden, die dann passend aufbereitet werden.

Folgende Tools kann ich dazu empfehlen:

LizardTech GeoViewer
http://www.lizardtech.com/down…ction=geoviewer#geoviewer

MapTiler
http://www.maptiler.org/

Mobile Atlas Creator
http://mobac.sourceforge.net/

Im GeoViewer kann man größere Ausschnitte markieren und als GeoTIFF exportieren (Full Resolution aktivieren).

Das GeoTiff wiederum kann der "MapTiler" in eine OSM/GoogleMaps-kompatible Kachelsammlung zerstückeln. MapTiler selbst basiert wiederum auf GDAL, im Grunde ein ähnlicher Weg wie "geotiffsplit" in meiner geotools-Sammlung (siehe Glopus-Forum). Der große Vorteil nun: kachelkompatibel zum mobac.

Der Mobile Atlas Creator kann schließlich die Kachelsammlung als Quelle nutzen und verschiedene Atlas-Exportformate generieren, z.B. für Glopus oder auch Smartphone GPS-Programme (Oruxmaps SQL, OsmAnd SQL).

Als Beispiel hänge ich mal eine Hybridquellen-Definition für mobac an, die gröbere Zoomlevels aus OSM ergänzt (wo man auf der Reichskarte nichts mehr erkennen kann). Ansonsten reicht auch nur der <localTileFiles> Eintrag, wenn man auf den OSM-Layer verzichten will.

Ich habe nun einen Weg gefunden, auch relativ große Ausschnitte der Reichskarte auf Glopus zu übertragen. Sehr praktisch ist dann auch die Überlagerung der OSM/IMG-Vektorkarte (Darstellung: Punkte und Linien/Wege aktivieren, Flächen deaktivieren) auf die alte Rasterkarte. Mit dieser Kombikarte auf dem Rad durch die Historie zu fahren gibt einem gleich einen neuen Eindruck von der Siedlungslandschaft.

Für diesen Weg werden folgende Tools benötigt:

LizardTech GeoViewer
http://www.lizardtech.com/down…ction=geoviewer#geoviewer

MapTiler
http://www.maptiler.org/

Mobile Atlas Creator
http://mobac.sourceforge.net/

Im GeoViewer kann man größere Ausschnitte markieren und als GeoTIFF exportieren (Full Resolution aktivieren).

Das GeoTiff wiederum kann der "MapTiler" in eine OSM/GoogleMaps-kompatible Kachelsammlung zerstückeln. MapTiler selbst basiert wiederum auf GDAL, im Grunde ein ähnlicher Weg wie "geotiffsplit" in meiner geotools-Sammlung. Der große Vorteil nun: kachelkompatibel zum mobac.

Der Mobile Atlas Creator kann schließlich die Kachelsammlung als Quelle nutzen und verschiedene Atlas-Exportformate generieren, z.B. für Glopus oder auch Smartphone GPS-Programme (Oruxmaps SQL, OsmAnd SQL).

Als Beispiel hänge ich mal eine Hybridquellen-Definition für mobac an, die gröbere Zoomlevels aus OSM ergänzt (wo man auf der Reichskarte nichts mehr erkennen kann). Ansonsten reicht auch nur der <localTileFiles> Eintrag, wenn man auf den OSM-Layer verzichten will. Das hat jetzt nichts mit dem OSM/IMG-Vektoroverlay in Glopus zu tun, den man separat aktivieren kann, um das heutige Wegenetz erkennen zu können.

So schnell entwickelt sich das nicht.
Oder gibt es mittlerweile eine fertige Lösung?
Die Kacheln alleine reichen nicht.

Oruxmaps hatte ich mir angesehen, beeindruckend. Die Unterstützung von Waypoints, Tracks u.s.w. in Verbindung mit Rasterkarten ist gut gelungen.

Mittlerweile kann OpenStreetMap aber in Wälden und Feldern durchaus mit den amtlichen Rastertopokarten mithalten. Sehr häufig sind auf den Rasterkarten noch Waldwege verzeichnet die gar nicht mehr existieren oder nicht mit dem Rad befahrbar sind. In meiner Umgebung ist OpenStreetMap mittlerweile zuverlässiger.

Zu OpenStreetMap ist vermutlich OsmAnd die beste Applikation. Ich hab sie ein paar mal getestet und war in einem Punkt total überrascht:
Es war damit eine automatische Routenführung für Fahrräder auf Waldwegen möglich. Das OSM-Material war offenbar routingfähig. Und noch überraschender: die automatische Route war fast exakt so wie ich sie mir manuell an der Wanderkarte auch ausgesucht hatte. Also hab ich mir das Eintragen der Waypoints gespart und bin gleich mit der Automatik losgefahren. Ob dazu eine Onlineverbindung nötig war weiss ich nicht mehr. Das OSM-Material selbst war zumindest auf der Speicherkarte. Auch ein Neuberechnen der Route gibt es, wenn man den vorgegebenen Pfad verlässt.

Ich fahre sonst immer mit Rasterkarten auf einem umfrisierten Navi. Aber das hatte mich dann doch schwer beeindruckt. Die eingebauten POI auf der OSM-Karten sind ebenfalls praktisch. Nicht alles davon ist in der Rasterkarte verzeichnet. POI-Suche nach Kategorien, Adresssuche ... und falls OSM mal ein Gebiet nicht abdeckt können immer noch Rasterkarten eingeblendet werden. Es geht angeblich sogar ein Mix aus Rasterkarte mit überlagertem OSM-Wegenetz. Das hatte ich allerdings nicht geschafft zu konfigurieren.

Zitat von mike0007

Gibt es auch ein Programm als gpl oder freeware

Falls man sich mit der Commandline anfreunden kann:
Zum Kachel-Splitten gibt es eine Lösung: GDAL (www.gdal.org).

Ich hatte hier

http://forum.pocketnavigation.de/forum96-glopus/

das bash-script "geotiffsplit" publiziert, das GDAL soweit automatisiert,
dass aus einem kalibrierten Geotiff kalibrierte Kacheln extrahiert werden.
Ich glaube alternativ werden auch WorldFiles Kalibrierdateien akzeptiert.

Wie man die Kacheln dann für OSM verwertbar macht ist natürlich eine andere Frage.
Ich hatte die Kacheln immer nur für Glopus aufbereitet.
Die Kachelmatrix ist durchindiziert im Dateinamen.
Eck-Kalibrierpunkte lassen sich aus den Eckkacheln extrahieren.
Vermutlich wird man sich auf die Mercator-Projektion beschränken müssen,
oder mit GDAL die Karten entsprechend reprojezieren. Das geht aber.
GDAL kennt fast alle Projektionsarten.

Der Vorteil mit GDAL ist, dass man beliebige Funktionen programmieren kann.
Mit den kommerziellen Programmen ist man immer auf deren Features beschränkt,
falls sie selbst nicht scriptingfähig sind.

Zitat von Wastl

Outdoor = draussen. Also auch ausserhalb eines Fahrzeuges.

Ach stimmt, wenn man es so sieht. Und es gibt noch die Nebenbedeutung "outdoor = ohne Dach überm Kopf". Also wäre das sprachlich Ok, sogar für Engländer. Ich hatte nur als Kontrast immer diese Forschungsaktivität "Indoor-Navigation" im Kopf, die nie so richtig funktionieren wollte. Fürs Marketing denke ich bei Outdoor wieder eher an wasserfest und für den harten Einsatz geeignet. Das wäre nicht das Problem der Software. Nur sehr wenige Android-Hardware wird heutzutage eine Regenschauer aushalten. Schade eigentlich, bei den tollen GPS-Programmen die es dafür gibt.

Also dann viel Spass beim "public viewing" (engl. für "öffentliche Aufbahrung eines Toten"). An Sport denken die Amerikaner dabei nicht. Hier hat der Duden bei der Neudefinition der engl. Sprache nachgeholfen.

Ach stimmt, hatte ich vergessen: die Mercator ist mittlerweile fast überall Standard. Google Maps hatte 2005 von Rektangular auf Mercator umgestellt. OSM-Tileserver machen auch Mercator. Im Kleinen fällt das kaum auf (kleine Topokacheln), im Großen aber schon (Deutschland-Kacheln). Glopus basiert meines wissens auf Rectangular-Projektion, wobei mal interessant wäre wie genau der Support für die neuen Projektionsparameter im KAL aussieht, also was genau projeziert wird, Bilder, oder welche Koordinaten.

Richtig, zu Mercator braucht man einen weiteren Parameter, den Zentralmeridian. Andererseits kann der auch über Kalibrierpunkte bestimmt werden, wenn es genug davon gibt. Eine Näherungslösung wäre auch denkbar, wenn man die Projektion überhaupt nicht kennt und eine Entzerrung anhand mehrerer Kalibrierpunkte approximiert (wovon dann günstigerweise auch einige in Kartenmitte liegen sollten).

Ein Stitchen der Kacheln ist für Glopus nicht unbedingt nötig, wenn sie schön gleichmäßig als Matrix ohne Schnittränder und Lücken zusammenpassen. Dann könnten sie weiter in Glopus-taugliche kleinere Kacheln zerstückelt werden. Und mit einer gewissen Regularität dürfte es auch gehen, daraus ein Oruxmaps sqlite zu generieren, wie es auch MOBAC macht (also nur die Eckkalibrierung der Gesamtkarte angeben und die Zwischenwerte berechnen lassen).

Wie unterscheidet man Outdoor-Navis von Indoor-Navis? Indoor-GPS-Geräte kenne ich nicht. Ich vermute man meint mit "Outdoor" Geräte, die außerhalb des Straßennetzes topografische Details und Wanderwege zeigen sollen. Das würde ich dann als "Offroad" bezeichnen. Vielleicht solltet ihr mal das Foren-Topic ändern.

Ach, alles klar. Jetzt weiss ich woher du die Ozi-Kalibrierung hast. Im Geotiff fehlt nämlich die Projektionsangabe (das ist in der Beziehung nicht korrekt), auch im Worldfile ist keine drin (geht auch nicht). Beide beziehen sich auf RGF93, nicht auf WGS94. Aber in der MapInfo *.tab-Kalibrierung ist eine Projektionsangabe. Bei einem Preis von fast 3000€ ist Mapinfo nicht unbedingt ein Konsumprodukt. Allerdings erkennen manche GIS-Programme die *.tab-Datei und ergänzen diese Info zum TIFF-Kartenmaterial.

Mein Ozi macht es aber nicht, obwohl ich die Geotiff-Erweiterung drin habe. Du hast dann sicher noch eine andere Erweiterung drin, die *.tab lesen kann. Mein Ozi-Trial erkennt es nicht.

Stimmt, entzerren ist nur eine Notlösung, die zu hässlichen Bildern führt. Bei der Deutschlandkarte hatte ich entsprechende Erfahrungen gemacht. Besser war die Konvertierung der Generalkarte im Geogrid-Viewer.

Zum Splitten habe ich in der "geotools"-Sammlung das Script "geotiffsplit". Falls man die Geotiffs repariert (die richtige Projektion einträgt), könnte es damit funktionieren. geotiffsplit basiert auf GDAL und berücksichtigt auch die Projektion. D.h. die neu erzeugten Kalibrierpunkte werden projektionsrichtig berechnet, die Kacheln aber nicht entzerrt. Also genau das was man braucht. Am Ende kann man mit "geotiff2kal-all *.tif" aus den Geotiffs noch die Glopus KAL-Dateien generieren und alles zusammen in ein GMF packen. Ist relativ einfach, wenn man es schafft die ganzen Tools zu installieren (ich glaube GDAL habe ich sogar auf Cygwin selbst kompiliert).

Wer es einfacher haben will: die kommerzielle Software "Global Mapper" kann auch Geotiffs in Kacheln splitten. Ozi kann es nicht soweit ich weiss. Glopus Map Manager kann zwar splitten, aber vermutlich die Einzelkachel-Kalibrierwerte nicht richtig berechnen. Dafür müsste es die Lambert-Projektion verstehen. Oder man splittet mit GMM und berechnet die Kalibrierwerte selbst. Dabei kann PROJ helfen, das Zahlentabellen in alle mögliche Geokoordinatensysteme umrechnen kann.

Tja, wer sich kein teures GIS-System leistet muss eben selbst basteln ... (macht ja auch Spass)

Die Kacheln haben keine Kalibrierinformationen im sqlite. Das hatte ich mir schon angesehen, aus einem MOBAC-Export. Die Einträge in *.otrk2.xml sind mir bekannt. Doch da stehen nur die Eckkalibrierungen der Gesamtkarte drin, nicht der einzelnen Kacheln. Das geht solange gut, wie die Einzelkachel-Werte anhand der Indizes berechnet werden können. Bei einer regulären OSM-Kachelung geht das, im Allgemeinen aber nicht. Denn bei Glopus-GMF kann jede Kachel individuell kalibriert werden. Im GlopusMapMaker gibt es je nach Verfahren auch einen kleinen Schnittrand bzw. Überlappungsbereich. Das kann Oruxmaps nicht wissen. Die Chancen stehen schon besser beim Karten-Split einer Riesenkarte. Dann kommt es darauf an, ob Oruxmaps mit der Projektion über die Kachelgrenzen hinweg zurechtkommt.

In GMF stehen zu jeder Kachel die Kalibrierpunkte einzeln drin. Was fehlt ist nur die Angabe der Projektion. Das könnte nachträglich ergänzt werden, weil ja i.d.R. alle Kacheln einer Karte die gleiche Projektion besitzen. Ich weiss nur nicht so recht, wie die Projektionsunterstützung in Glopus konkret aussieht, welche unterstützt werden. Man kann auch durchaus eine Lambert-Projektion mit WGS84-Koordinaten kalibrieren, wenn die entsprechenden Pixel/Karte-Kalibrierpunkte bekannt sind (d.h. die 4 RGM-Koordinaten müsste man für jede Kachel umrechnen).