Hallo Leute, gibt es hier jemanden, der schon immer mal ne Landkarte auf seinem Mikrocontroller haben wollte? Nun, mich hat dieses Thema interessiert und ich hab deswegen geschaut, was es so alles gibt. Ja, es gibt bereits ne Menge, von Navis auf WinCe an abwärts. Aber eigentlich nix, was auch auf nem STM32 oder LPCxxx laufen könnte. Also hab ich mir mal ein paar Gedanken gemacht und mir was einfallen lassen. Wen's interessiert, der schaue sich die beigefügte Datei an (ca. 2.5 MB, hoffentlich geht's durch). Ich hab keine fertigen Quellcode gepostet, aber ne Doku, wie es geht, ein Programm zum Map erzeugen (genauer eigentlich zum Umwandeln, man will sich ja nicht mit den Federn von OSM, Trekbuddy und Co. schmücken), ein paar Beispielmaps und einen Betrachter. W.S.
W.S. schrieb: > Ja, es gibt bereits > ne Menge, von Navis auf WinCe an abwärts. Aber eigentlich nix, was auch > auf nem STM32 oder LPCxxx laufen könnte. Also ich hab vor 2-3 Wochen bei OBI für 30 Öhre je Stück zwei Navis gekauft, und da war ein schicker kleiner arm drin. Hab mir schon überlegt wie ich den in die "Nachverwendung" überführe wenn die Karten veraltet sind. Daher sag ich mal, für den Preis bekommst Du nicht mal das GPS mit Chip-Antenne und nen µC. Dann doch lieber das 30 € Navi hacken und mit eigener SW ausstatten. Gruß Heiko
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.
Manche Leute glauben also tatsächlich, ein Gerät mit Landkartendarstellung muss immer ein Navi sein...
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.
Edi R. schrieb: > Manche Leute glauben also tatsächlich, ein Gerät mit > Landkartendarstellung muss immer ein Navi sein... Ja, so ein "Gerät" habe ich auch. Es nennt sich "Atlas", und ist wesentlich übersichtlicher wie jedes Navi... Gruss Gruss Harald
@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.
Texas Instruments stellt Mikrokontroller her, auf deren Gehäusen die Landkarte von Texas abgebildet ist... ;-) http://newscenter.ti.com/index.php?s=32902&item=886 Flücht Paul
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.