Landkarten auf dem Mikrocontroller

Heiko Jakob schrieb:
> Also ich hab

Ja, klar, ich hab auch neulich ein komplettes Navi für 15 Euro bei Ebay 
gekauft..

Ähem, der Sinn hier dahinter ist eigentlich was ganz anderes, nämlich 
sowas selber zu können. Jedenfalls für mich. Ich räume allerdings ein, 
daß es wohl nicht jedermanns Sache ist, sich sowas selber zu schreiben.

W.S.

W.S. schrieb:
> Ähem, der Sinn hier dahinter ist eigentlich was ganz anderes, nämlich
> sowas selber zu können

Ist ja schön und gut, allerdings einfach nur ein paar Koordinaten auf 
dem Mikrocontroller zu haben und die dann mit Farben zu füllen ist nicht 
gerade die Kunst und zudem ziemlich nutzlos.
Beeindruckt wäre ich wenn Du ein Sprachgesteuertes Navi draus bastelst. 
Oder wenigstens Eines das arbeitet wie vor 10 Jahren bei denen 
Entfernung zur nächsten Abzweigung zusammen mit einem Pfeil angezeigt 
wurden. Natürlich sollte die Navigation dann auch funktionieren und die 
Routenplanung in akzeptabler Zeit geschehen. Das wäre ein interessantes 
Projekt.

naja schrieb:
> ... ein Sprachgesteuertes Navi ...

Na klar...

Nee, du verwechselst hier was. ein Navi ist was anderes als ne 
Landkarte. Es funktioniert innerlich auch ganz anders, da es eigentlich 
keine Landkarten, sondern (erlaubte) Fahrspuren verwaltet.

Also mach du da mal was draus, zum Beispiel eben genau das, was du 
angesprochen hast. Die Steilvorlage von mir hast du ja bereits :-)

W.S.

Das war ein netter Hinweis auf die Nutzlosigkeit deines Projektes... Ich 
verwechsle auch nichts ich habe geschrieben, dass es beeindruckend wäre 
wenn du daraus ein Navi machst. Das ist eine Tatsache und keine Frage 
nach dem Wie.

Eine Steilvorlage für etwas Sinnvolles? Ich glaube nicht... Ich wüsste 
nicht was man damit sollte und Profilierungspotential hat es auch nicht.

Kennt ihr das Projekt NaviPOWM? Es ist eine freie Firmware für Navis: 
http://sourceforge.net/projects/navipowm/

Interessantes Projekt!

Allerdings passen bei mir die Koordinaten nicht.
Ich habe mit MOBAC die OpenStreetMap Karten in die tared trekbuddy Daten 
umgewandelt und diese dann mit der MapConvert weiterverarbeitet.
Wenn ich mir die erstellten Daten mit dem MapViewer anschaue und die 
Koordinaten auslese und in google maps, OpenStreetMap o.ä. wieder 
eingebe, lande ich je nach Zoomlevel immer einige 100m bis >20km 
südlicher, als die Stelle die mir der MapViewer anzeigt! In Ost/West 
Richtung passt die Position perfekt. Je größer der Kartenausschnitt ist, 
desto extremer werden die Abweichungen. D.h. verwende ich einen 
100x100km Ausschnitt sind die Abweichungen nur einigen 100m. Bei einer 
Deutschlandkarte sind es dagegen schnell mehrere km.
Ich habe mir irgendwas in der Mitte von Deutschland angeschaut, denn da 
scheint die Abweichung am größten zu sein.

@W.S.
Ich habe das Problem mit der Verschiebung in y Richtung gefunden:

Du zählst den Breitengrad bei den Tiles linear hoch, was nicht ganz 
richtig ist. Wenn ich die y Position so wie hier berechne, komme ich auf 
der Karte an die richtige Position:
http://wiki.openstreetmap.org/wiki/Slippy_map_tilenames#Derivation_of_tile_names

Daher jetzt meine Bitte an dich:
Könntest du deine MapConvert Software entsprechend korrigieren, so dass 
diese die Koordinaten bei jedem Tile korrekt angibt (also den 
Breitengrad nicht linear wie bisher durch zählen, sondern entsprechend 
der Formel korrigiert)? Dann könnte man sich auf dem Mikrocontroller 
diese doch recht aufwendige Fließkommaberechnung sparen, da auf kleiner 
Fläche (also innerhalb einer Tile) die Koordinaten ausreichend linear 
sind.

Anton schrieb:
> Könntest du deine MapConvert Software entsprechend korrigieren

Ich werd's mir mal für die nächste Zeit vornehmen oder schlichtweg mal 
die Quelle posten, dann kann's jeder Interessent nach seinem Gusto 
verschönern..

W.S.

Nachtrag:

Es ist komplizierter, als angenommen - und ich bin mir im Moment noch 
nicht ganz klar über die nötigen Korrekturen. Immerhin haben wir ja nur 
folgendes:

- Breitenangabe der Nordkante der Karte

- Breitenangabe der Südkante der Karte

- Anzahl der Pixel in Y-Richtung.
und gesucht ist die Breitenangabe eines beliebigen Punktes auf der 
Karte.

Der "EDV-mäßig" simpelste Weg wäre, den Umweg über die Trekbuddykarten 
wegzurationalisieren oder aus den Grobkoordinaten der Tiles deren echte 
Tilenummer zu bestimmen und die dafür geltenden tatsächliche Koordinaten 
zu benutzen.

Dann reicht auch ne simple lineare Interpolation innerhalb eines Tiles 
aus. Im Moment macht der Viewer noch ne Interpolation über die gegebenen 
Koordinaten der Gesamtkarte und der Konverter ebenfalls.

Das gibt ein kleines logisches Problem: Nur dann, wenn bei der 
Erstellung der Tiles sich an die Regeln nach

http://wiki.openstreetmap.org/wiki/Slippy_map_tile...

gehalten wurde, kann man aus den groben Koordinaten eines Tiles (die ja 
aus den Koordinaten der Gesamtkarte per Interpolation gewonnen wurden) 
die Nummer des ursprünglichen Tiles ermitteln und dessen normgerechte 
Koordinaten errechnen.

Wenn die Tiles aus ner anderen Quelle stammen oder anders skaliert sind, 
ist das nicht zwangsläufig gegeben.
Das ist das Problemchen.


Der mathematische Weg, aus den o.g. Daten das Ergebnis zu berechnen, 
läuft wahrscheinlich auf's Eingabeln hinaus.

hmm, mal sehen.

@Anton:
"Wenn ich die y Position so wie hier berechne.."

Ähem.. du hast die Daten aus dem Viewer in deinen Taschenrechner o.ä. 
abgetippt und dann sozusagen zu Fuß korrigert?

W.S.

Hast du noch eine andere Kartenquelle als Openstreetmap mit MOBAC?
Dann könnte man leicht ausprobieren, ob alle ihre Tiles nach diesem 
Verfahren berechnen.
Ich habe ein weiteres Programm getestet, das mir tared trekbuddy Daten 
mit jpg statt png erzeugt hat, was deine Software aber anscheinend nicht 
weiterverarbeiten kann. Ansonsten habe ich nichts weiter gefunden.

Der Hintergrund des ganzen Aufwands:
Ich versuche diese aufwendige Breitengradberechnung möglichst auf die PC 
Seite zu verlagern, was mir bisher aber noch nicht ganz gelungen ist. 
Mit den korrekten Koordinaten in den Tiles kann man zumindest diese für 
weitere Berechnungen verwenden:
Damit erspare ich mir die Berechnung nicht komplett, muss aber immer nur 
einmal rechnen (um die passende Tile zu finden die angezeigt werden 
muss). Danach kann ich aus den Koordinaten der Tile zumindest auf 
kleiner Fläche linear interpolieren um Objekte an passende Koordinaten 
zu zeichnen. Das geht mit den falschen Koordinaten bisher nicht, da die 
Skalierung (also Pixel pro Breitengrad) sich von Norden nach Süden 
deutlich ändert.
Als Workaround habe ich mir daher eine kleine Software gebastelt, die 
die Koordinaten in deinen Kartendaten korrigiert. Damit passt die 
berechnete Position dann auf einer Deutschlandkarte auf wenige Pixel 
genau.
In dem Zusammenhang verdrehe ich auch die 16bit Farbtabelle, da bei 
deiner Variante rot und blau gegenüber dem üblichen RGB565 Format 
vertauscht sind (in der Form wird es nämlich auch bei TFT Modulen 
verwendet):
http://msdn.microsoft.com/en-us/library/windows/desktop/dd390989%28v=vs.85%29.aspx

Rein theoretisch könnte man die aufwendige Berechnung einsparen, indem 
man als Näherung linear interpoliert, die Koordinaten aus der 
errechneten Tile liest und sich so Stück für Stück an die gesuchte Tile 
herantastet. Ob das allerdings schneller ist, als die 
Fließkommaberechnung ist fraglich.

Ich berechne mit der Korrekturformel den Wert am oberen sowie unteren 
Ende der Karte, sowie dem gewünschten Breitengrad. Bei den nun 
korrigierten Werten kann man linear interpolieren um die gewünschte Tile 
bzw. Pixelposition zu finden. Hier das ganze rückwärts um die 
Koordinaten der Tile tiley zu berechnen/korrigieren:

1

TLevelHeader lheader;

2

THeader theader;

3

double lat, latpos, lattop, latbot;

4

< hier Header lesen >

5

lat=lheader.Top/1000000.0;

6

lattop=1.0 - log(tan(lat * PI/180.0) + 1.0 / cos(lat * PI/180.0)) / PI; 

7

lat=lheader.Bot/1000000.0;

8

latbot=1.0 - log(tan(lat * PI/180.0) + 1.0 / cos(lat * PI/180.0)) / PI; 

9

latpos=lattop-(lattop-latbot)*tiley/lheader.numY;

10

lat=atan(sinh(PI * (1 - latpos)))*180.0/PI;

11

printf ("Header: %9.5lf, correct: %9.5lf, delta: %8.5lf\n", theader.Top/1000000.0, lat, theader.Top/1000000.0-lat);

Damit sieht man schön, dass der Fehler am oberen sowie unteren Ende der 
Karte 0 ist und in der Mitte am größten ist.

So, mal sehen, ob es jetzt klappt. Ich hab aus Top- und Bottom- 
Breitengrad deren prinzipielle Map-Koordinate berechnet, dort linear 
interpoliert (weil die Pixel als solche ja linear sind) und dann zurück 
den zugehörigen Winkel zurückgerechnet. Sollte eigentlich so klappen. 
Beim Konverter kann man die Differenzen zum linearen Interpolieren aus 
der Logdatei ersehen.

Ich hab mal zur Kontrolle die Koordinaten der Mitte vom Brandenburger 
Tor mit Euroroute 2008 verglichen und das stimmt jetzt exakt. Die 
einzelnen Tiles haben ja ihre eigenen Koordinaten und da kann man wohl 
in jedem Falle linear interpolieren. Auffallend wird es ja nur, wenn man 
einige 100 Tiles in N-S Richtung in der Karte hat.

Ansonsten zur Farbgestaltung: uC mäßig bin ich auf Fujitsu FR - und der 
ist bigendian, weswegen meine Farb-Grafik auch ein bissel anders 
gestrickt ist. Bei dem unter Win laufenden Viewer wird das alles auf 24 
Bit Farbe umgerubelt, da ist die Position RGB oder BGR in der Palette 
erstmal egal. Aber wenn das Streß macht, kann ich es ja im Konverter 
umstellen.

Ach ja, zum Input: Ich hatte anfangs auch mit JPG-Tiles begonnen, weil 
das GDI JPG von selbst kann und PNG ne ätzend häßliche Sache ist, wenn 
man es zu Fuß auseinandernehmen muß. Irgendjemand hatte dann mal ne Art 
Universal-Bitmap für Delphi geschrieben, was auch PNG kann, aber das 
Teil hatte ein nicht stopfbares Memory-Leak und nach so etwa 20000 Tiles 
war Out of Memory und Absturz angesagt, also nicht verwendbar. Ich 
benutze jetzt das Gdiplus und damit läuft alles. Aber ich hab derzeit 
eben nur PNG-Input vorgesehen, obwohl JPG im Prinzip auch ginge. Ist JPG 
für dich ein so großes Thema?

Eins noch: Es gibt offenbar mehrere Quellen für die Trekbuddy-Tar's, die 
die Datei- und Verzeichnisnamen bei mehrteiligen Tars unterschiedlich 
bilden und auch die Formate der MAP-Dateien sind gelegentlich 
unterschiedlich. Manchmal führende Nullen und manchmal nicht, manchmal 
die Referenzpunkte nicht in den Ecken und so. Kann durchaus sein, daß es 
gelegentlich an sowas hängt.

W.S.

Vielen Danke für die Anpassung! Die Koordinaten passen jetzt perfekt.
Allerdings hat sich irgendwo ein Fehler eingeschlichen:
Wenn ich eine große, mehrteilige Karte (z.B. Zoomlevel 13 von ganz 
Deutschland) umwandeln möchte, kommt die Meldung "kann Koordinaten-Info 
im TAR-File nicht auswerten" und anschließend die Meldung, dass er die 
Datei nicht findet. Mit dem alten Konverter funktioniert es mit den 
selben Dateien.

Kennst du noch andere Quelle für Karten, oder zufällig eine Software um 
googlemaps Daten umzuwandeln? Die Karten von openstreetview gefallen mir 
nicht so ganz, da dort kaum Ortsnamen erscheinen. Man muss schon sehr 
weit rein zoomen um etwas brauchbares angezeigt zu bekommen.

Anton schrieb:
> Allerdings...

Ich sag's ja: irgendwas ist immer mal anders in den Mapdateien. Muß 
morgen mal danach suchen. Du kannst aber auch selber danach suchen, im 
Prinzip ist es immer wieder ein Ärger mit den Dateinamen, also wie die 
Namen bei geteilten Leveln gebildet werden.

Ansonsten probier mal ne ältere Version, siehe Anhang. Da müßten noch 
MS, Yahoo und Konsorten mit drin sein.

W.S.

Nachtrag:

Schau mal im Tar-File nach der Datei xxxx.map (also z.B. EU_MAP 12 
(00).map)

und dort drin nach

MMPXY, 1,     0,     0
MMPXY, 2, 18943,     0
MMPXY, 3, 18943, 17407
MMPXY, 4,     0, 17407
MMPLL, 1, -12.656250, 62.915233
MMPLL, 2, 39.372253, 62.915233
MMPLL, 3, 39.372253, 31.954493
MMPLL, 4, -12.656250, 31.954493

Entweder gibt's dort ne Ungereimtheit oder im Filenamen.
Notfalls postest du mal das Mapfile.

W.S.

Ich habe beide Map Dateien angehängt (12 funktioniert, 13 nicht), aber 
ich denke nicht dass er daran liegt, denn wie gesagt: Mit der vorherigen 
Version von deinem Map Converter funktionieren beide Karten, mit der 
neuen nur  Karten, die nicht auf mehrere Teile unterteilt sind.

PS: Danke für die alte Version von MOBAC.

Ich glaub, ich habe das Problem. Mach mal folgendes:
Du hast ja irgendwo ne Directory-Struktur so etwa:
c:\maps\deutschland\deutschland 10\...
c:\maps\deutschland\deutschland 11\...
c:\maps\deutschland\deutschland 12\...
c:\maps\deutschland\deutschland 13 (0)\deutschland 13 (0).tar
                                      \deutschland 13 (0).tmi
usw. bis
c:\maps\deutschland\deutschland 13 (3)\...

und nun füge mal in alle runden Klammern (Pfad und Dateien) ne 0 ein, 
also
deutschland 13 (0).tar --> deutschland 13 (00).tar   usw.

Jetzt muß ich bloß noch ne Unterscheidung einbauen zwischen Pfadnamen 
mit einstelliger Teilnummer und zweistelliger Teilnummer. Grmpf..

W.S.

Das ist die Ursache, mit der zusätzlichen 0 funktioniert es.

Hab noch ein Problem gefunden: Bei Levels, die in mehr als 4 Teile 
aufgeteilt sind (6 oder 8 oder noch mehr) tut sich mein 
Arrangier-Algorithmus noch schwer - aber das sind dann ja auch 
Riesenkarten, die hoffentlich so bald nicht gebraucht werden. Ich hoffe 
bloß, daß sich Google und Konsorten inzwischen beruhigt haben und einen 
beim Tilesaugen nicht abklemmen...

W.S.

So, die nächste Runde ist dran. Hab das Arrangieren der geteilten Levels 
neu geschrieben und bin einstweilig damit zufrieden.

Viel Spaß damit.

W.S.

Danke, funktioniert wunderbar!