Freizeitkarte in qlandkarte-gt: Alles verzerrt

Ich habe mir gerade die Freizeitkarte (Deutschland) heruntergeladen und in qlandkarte gt geladen. Dort musste ich aber mit Schrecken feststellen, dass alles unregelmäßig verzerrt ist (siehe Bild).

Zum Vergleich: http://www.openstreetmap.org/?lat=52.617968&lon=10.0916&zoom=18&layers=M

Hat jemand eine Idee, woher das kommt und wie man es beheben kann?

Habe mir gerade mal die Garmin Topo V2 im Osten Deutschlands angeschaut (in den neuen Bundesländern sind dort auch Gebäude eingetragen). Dort sieht es ähnlich aus.

Sollte das Garmin-Format echt nicht in der Lage sein, die Koordinaten genauer zu speichern? Aber warum ist mir das in den letzten 5 Jahren noch nie aufgefallen bei den Garmin-Karten?

Poste das mal bitte hier:
http://www.naviboard.de/vb/forumdisplay.php?s=ee3a6faf5178b3ff3b1fe7c355f00aa6&f=152
da liest Oliver das früher. Welche Version von QLGT nutzt du, welches Betriebssystem?
Ich bin nur der, der Online(WMS) Karten für QLGT "macht".
Bei mir im Norden von Nürnberg, kann ich den Fehler in der Freizeitkarte nicht bemerken/feststellen. Ich bin Linuxuser und nutze die aktuelle, selbst kompilierte Version von QLGT.
Darf aber sagen das Oliver (QLGT), Klaus (Freizeitkarte) und ich in Kontakt sind.

Grüße
Teleskopix

Ich lese hier auch mit

Aber es ist tatsächlich so. Garmin benutzt auf der höchsten Detailstufe nur 24 Bit um eine Koordinate darzustellen. Wenn man den Breitenkreis nimmt und durch 2^24 teilt, dann kommt man auf ein paar Meter pro Bit. Und jetzt benutzen manche Karten noch nicht mal 24 Bit in der höchsten Detailstufe!

Natürlich sind die Koordinaten bei OSM wesentlich besser abgespeichert. Und die Renderprogramme für die Onlinekarten rechnen mit der vollen Genauigkeit, was zu sehr ansehnlichen Ergebnissen führt. Das ist aber leider Nichts für Outdoor Geräte, weil es zu viele Prozessorleistung und auch Speicher vergeigt. Nicht umsonst laufen Garmingeräte wirklich länger als 10h und DE passt auf 4GB.

Aber natürlich mit dem Nachteil, dass die Karten nicht so schön wie aus dem Ei gepellt aussehen, sondern deutlich Quantisierungsfehler aufweisen. Wobei man mit der richtigen Rundung noch ein wenig herausholen kann. Ich weiß allerdings nicht, ob die einzelnen Kartengeneratoren das richtig machen. Dazu müsste ich mir den Code ansehen. Gut möglich dass da noch was zu holen ist, da ich glaube dass Quantisierung ist nicht gerade ein Thema ist, mit dem sich rundum-sorglos-Java Programmierer in der Regel beschäftigen. Aber ohne es zu wissen, ist das nur eine kleine gemeine Stichelei

Gut, danke für die Antworten!

Dann werde ich mir die Freizeitkarte auf mein Garmin packen und auf dem Computer einen WMS-Server nutzen (sowie ich Lust dazu habe).

PS: Weil danach gefragt wurde: 1.7 auf Windows 7 sowie Arch, 1.4 auf Ubuntu (warum gibt's da kein vernünftiges PPA mit der aktuellsten Version?).

Also so stark habe ich noch kaum in die Karten reingezoomt, aber der "Bug" scheint grundsätzlich vorhanden, egal ob Freizeitkarte, Kowoma oder Kleineisel bzw. Nops Wanderkarte.
Mmh, it's not a bug, it's a feature.

Teleskopix schrieb:

Also so stark habe ich noch kaum in die Karten reingezoomt

Zum Vergrößern anklicken....

Als Mapper mit Hang zum Micromapping ist das eine meiner ersten Aktionen. Aber an Garmins Format kann man halt nichts ändern.

Gibt es denn einen anderen Renderer in QLGT (oder Pläne einen zu machen), der genauere Koordinaten unterstützt? Anbieten würde sich zum Beispiel das relativ einfache und gut komprimierte Format von Mapsforge (Android). Damit würde die Beliebtheit von QLGT sicher noch um einiges steigen.

http://code.google.com/p/mapsforge/wiki/SpecificationBinaryMapFile
http://code.google.com/p/mapsforge/wiki/RenderThemeAPI

Ich hatte schon versucht Kiozen zu überzeugen Mapsforge in QLGT zu intergrieren,
nur er nutzt Android nicht in Verbindung mit QLGT. Er ist Rasterkartenfreak.
Bei Rasterkarten egal ob WMS/TMS oder Geotiff, tritt der Bug nicht auf.
Vielleicht kannst Du ihn überzeugen - es wurde ja schon hier und da gefragt Mapsforge unter Windows darstellen zu können.

Teleskopix schrieb:

Bei Rasterkarten egal ob WMS/TMS oder Geotiff, tritt der Bug nicht auf.

Zum Vergrößern anklicken....

Logisch, da - wie schon gesagt wurde - das Garmin-Format Schuld ist. Deswegen auch mein Workaround mittels lokalem WMS-Server.

Bezüglich Ubuntu und QLGT: Ich habe den Überblick verloren, wo, wie, welches Repository für welche Version. Das ist ein ziemliches Kuddelmuddel. Am besten fragst Du mal in einem Ubuntuforum nach.

Zum Mapsforgeformat: An sich ist ein offenes Vektorformat eine gute Idee. Nur leider ist das ganze OSM Zeugs leider in Java geschrieben. Solange das Runtime Environment von Java quasi das Betriebssystem stellt, wie bei Android, ist das sicherlich praktisch. Außerhalb dieser Insel ist der Java Code nichts wert. Um Mapsforge zu nützen, muss man den komplette Rendercode neu schreiben. Das ist viel Arbeit, die sich nur lohnt, wenn dadurch ein echter Mehrwert entsteht.

Aktuell gibt es die Garminkarten. Die kann ich auf dem Gerät direkt benutzen. Und auf dem PC zum Planen von Routen. Das Format ist recht gut komprimiert. Ich bekomme ganze Länder mit wenig Datenvolumen. Also eigentlich alles was ich will.

Mit Mapsforge würde es nur etwas schöner aussehen. Aber schon der Download wäre aufwendiger. Die Karten sind zwar direkt auf Android zu benutzen. Für alles andere muss ich mir aufbereitete Daten besorgen. Und dafür so viel Arbeit in ein neues Vektorformat stecken? Da kommt bei mir nicht so richtig die Motivation auf. Und komischerweise auch nicht bei bei allen, denen ich vorschlage sich damit einzubringen.

Mal langsam.

kiozen schrieb:

Zum Mapsforgeformat: An sich ist ein offenes Vektorformat eine gute Idee. Nur leider ist das ganze OSM Zeugs leider in Java geschrieben.

Zum Vergrößern anklicken....

Mir fällt kein Teil von OpenStreetMap ein, der in Java geschrieben ist. Hauptsächlich ist es C, C++ sowie Python (und Ruby und noch ein paar lustige Sprachen).

kiozen schrieb:

Solange das Runtime Environment von Java quasi das Betriebssystem stellt, wie bei Android, ist das sicherlich praktisch. Außerhalb dieser Insel ist der Java Code nichts wert.

Zum Vergrößern anklicken....

Dir ist bewusst, dass es Java für fast alle Plattformen gibt? Klar, eine Interaktion mit C++ macht keinen Spaß (geht aber). Theoretisch könnte man einen gewissen Teil von Mapsforge übernehmen. Relativ schnell kommen aber Android-Bibliotheken ins Spiel (für einige Datenstrukturen und sehr stark beim Rendering).

kiozen schrieb:

Um Mapsforge zu nützen, muss man den komplette Rendercode neu schreiben. Das ist viel Arbeit, die sich nur lohnt, wenn dadurch ein echter Mehrwert entsteht.

Zum Vergrößern anklicken....

Meine Anfrage zielte darauf ab, für die Mapsforge-Datenstruktur einen Renderer zu schreiben. Von Grund auf, genau. Der Mehrwert liegt eigentlich auf der Hand: QLGT würde ein weiteres, sehr verbreitetes Format unterstützen und würde zugleich die erste Desktop-Anwendung sein, welche dieses Format unterstützt. Nach wenigen Tagen würde es einige tausend Nutzer mehr geben.

kiozen schrieb:

Mit Mapsforge würde es nur etwas schöner aussehen. Aber schon der Download wäre aufwendiger. Die Karten sind zwar direkt auf Android zu benutzen. Für alles andere muss ich mir aufbereitete Daten besorgen.

Zum Vergrößern anklicken....

Warum wäre der Download aufwändiger? Germany.map herunterladen (700 MB) und fertig. Im Vergleich zur *.img (1,6 GB) ist das Mapsforge-Format um einiges stärker komprimiert, wie es mir scheint. Die darin enthaltenen Daten sollten identisch sein.
Auf Android, welches unter Smartphones die höchste Verbreitung hat, funktionieren diese Karten mit über 20 oft genutzten Apps. Neben dem Format von OsmAnd (für das es keine Bibliothek gibt) ist es das einzige Vektor-Format für Android.
Für welches "andere" musst du dir "speziell aufbereitete Daten" besorgen? Mapsforge ist Mapsforge und momentan gibt es das nur für Android.

kiozen schrieb:

Und dafür so viel Arbeit in ein neues Vektorformat stecken? Da kommt bei mir nicht so richtig die Motivation auf. Und komischerweise auch nicht bei bei allen, denen ich vorschlage sich damit einzubringen.

Zum Vergrößern anklicken....

Deine Motivation ist natürlich etwas anderes. Zwingen kann dich dazu niemand und wenn du mit Rasterkarten und der Garmin-Krücke zufrieden bist, dann ist das deine Sache. Sehr viele Nutzer würden die Unterstützung eines freien und weit verbreiteten Vektorformats aber begrüßen.
Meine Hilfe hatte ich bereits angeboten, aber ich habe in der Tat keine Motivation, mich in die Architektur von QLGT einzuarbeiten oder einen Renderer von Grund auf neu zu schreiben. Abgegrenzte, unabhängige Teile könnte ich implementieren, solange ich mir nicht wochenlang Gedanken über die grundlegende Architektur des Ganzen machen muss. (Letztendlich sollte es nicht viel anders als der Garmin-Renderer sein, nur dass die Daten und Styles aus einer anderen Quelle stammen.)

Ubuntu, das ppa ist hier https://launchpad.net/~mms-prodeia/+archive/qlandkarte
der Stand ist Version 1.4 (no comment)
Deshalb ist http://blog.dafb-o.de/howto-ubuntu-qlandkarte-gt
das immer noch die beste Lösung.

Immer wenn ich in der Vergangenheit OSM etwas mehr in QLGT integrieren wollte, war alles was ich gefunden habe Java. Eigenen IMG Dateien aus OSM mit Point-n-click erstellen? Schön wenn man das als Lib integrieren könnte. Aber der Konverter ist Java und zieht einen Rattenschwanz an zusätzlicher Installation mit sich. Wie toll das bei den Benutzern ankommt habe ich mit GDAL unter Windows kennengelernt. FWTools parallel zu QLGT installieren. Gefühlte 100 Möglichkeiten etwas falsch zu machen. Seitdem GDAL fest mit QLGT gebündelt wird, ist die Installation ewig fett, aber dafür funktioniert es. Java will ich nicht auch noch mit einbauen müssen.

Und mit Mapsforge ist es das selbe. Eine Integration auf API Ebene ist nicht möglich. Und als Subprozess? Ich weiß nicht. Schöner wäre es die ganze Arbeit wäre in einer C++ Bibliothek und könnte jetzt in Skriptsprachen als auch Kompilersprachen eingebunden werden. GDAL ist da ein wirklich gutes Beispiel. Deswegen wird GDAL auch in so vielen unterschiedlichen Projekten verwendet. Von der GUI Applikation über den GeoServer bis hin zum Datencruncherskript ist alles dabei.

Einen eignen Kartentyp in QLGT einzubinden ist übrigens nicht besonders schwer. Es gibt eine Basisklasse IMap. Auf der bauen alle Karten auf. Diese Klasse hat einige rein virtuelle Funktionen, die implementiert werden müssen. Da muss man von QLGT selber nicht viel wissen.

Versteh mich nicht falsch. Ich bin nicht gegen OSM und Mapsforge. Ich fände es auch toll, wenn das in QLGT mit dabei wäre. Aber aktuell sehe ich keinen Weg das mit einem vertretbaren Aufwand zu machen. Ich weiß sehr genau, wie viel Zeit im Garmin Render steckt. Und soviel wird auch in den Mapsforge Render fleißen müssen, wenn man alles selber schreiben muss. Um soviel Zeit zu spendieren muss man einen direkten Nutzen haben und keine Alternative. Ersterer fehlt mir und zweitere habe ich. Aber natürlich unterstütze ich jeden mit Rat und Tat, der es einbauen will. Und ich habe über alles was läuft bestimmt nicht den Überblick. Es mag also durchaus eine einfache Lösung geben, die ich nicht sehe. Davon lasse ich mich gerne überzeugen.

kiozen schrieb:

Immer wenn ich in der Vergangenheit OSM etwas mehr in QLGT integrieren wollte, war alles was ich gefunden habe Java.

Zum Vergrößern anklicken....

OSM selbst ist erstmal nur eine Datenbank. Du kannst die Daten in einem Binärformat bekommen oder als XML. Anschließend gibt es etliche Tools, welche diese Daten in etliche andere Formate konvertieren (oder in diverse Datenbanken importieren).

kiozen schrieb:

Eigenen IMG Dateien aus OSM mit Point-n-click erstellen?

Zum Vergrößern anklicken....

Das ist eine mögliche Anwendung mit den Daten von OSM.

kiozen schrieb:

Schön wenn man das als Lib integrieren könnte.

Zum Vergrößern anklicken....

Ins Garmin-IMG-Format? Damit hat doch alles angefangen. Wie du selbst gesagt hattest, ist es nicht in der Lage, die Koordinaten genauer zu speichern.

kiozen schrieb:

Und mit Mapsforge ist es das selbe. Eine Integration auf API Ebene ist nicht möglich. Und als Subprozess? Ich weiß nicht. Schöner wäre es die ganze Arbeit wäre in einer C++ Bibliothek und könnte jetzt in Skriptsprachen als auch Kompilersprachen eingebunden werden.

Zum Vergrößern anklicken....

Die Mapsforge-Bibliothek ist in Java unter intensiver Nutzung der Android-Bibliothek geschrieben. Das ist auch der Grund, warum man sie nicht in eine Desktop-Java-Anwendung einbinden kann. Daran, Mapsforge außerhalb von Android zu nutzen, hatten die Entwickler damals nicht gedacht.

Mein Vorschlag war deshalb, die Datenstruktur aus den Mapsforge-Dateien in eine interne Datenstruktur zu konvertieren, die anschließend in QLGT gerendert werden kann. Alleine schaffe ich das nicht und da von deiner Seite kein Interesse besteht, hat sich das Thema somit auch erledigt.

Mein Vorschlag war deshalb, die Datenstruktur aus den Mapsforge-Dateien in eine interne Datenstruktur zu konvertieren, die anschließend in QLGT gerendert werden kann. Alleine schaffe ich das nicht und da von deiner Seite kein Interesse besteht, hat sich das Thema somit auch erledigt.

Zum Vergrößern anklicken....

Wenn es so einfach wäre Das Garminformat ist reichlich verquer mit seinen Zoom Levels, Draworders und Stilen. Zudem erlaubt sich QLGT den "Luxus" eines Echtzeitrenders. Und der sollte auf 10 Frames pro Sekunde kommen, damit alles schön rund läuft. Der Vorteil davon ist, dass man die Projektion der Karte nach Belieben manipulieren kann und somit jede andere Karte mit den Vektorkarten überlagern kann. Damit das alles so schön funktioniert wurde viel Zeit in die Optimierung des Codes gesteckt. Was zwangsläufig dazu führt Abstraktionen fallen zu lassen.

Lange Rede kurzer Sinn, es ist besser für weitere Vektorformate einen eigene Render Engine zu bauen. Da gibt es dann bestimmt auch so einige Spezialitäten, die betüddelt werden wollen.

Die Mapsforge Java Bibliothek scheint übrigens folgendes zu machen: Die benutzt wohl eine der vorhandenen Render Applikationen/Bibliotheken, um Kacheln zu erstellen und diese Kacheln werden im weiteren Verlauf immer angezeigt. Somit dauert das erste Mal lange und dann geht es fix. Das ist auf einem mobilen Gerät natürlich eine gute Idee. Für QLGT, das Vektorkarten als Overlay benutzen kann, nicht so gut. Wie immer steckt der Teufel im Detail. Leider.

@teleskopix: Bezüglich deiner PM und dem osm.pbf Format gilt natürlich das selbe. Wobei es schon eine große Hilfe wäre eine Bibliothek zu haben, mit der sich das Format lesen ließe. Da muss ich mal recherchieren. Das wäre schon mal die halbe Miete. Shape Files habe ich mir auch schon angesehen. Aber auch dort fehlt mir ein Ansatz zum effizienten Auslesen der Daten. GDAL bietet hier leider nur sehr rudimentäre Funktionen an. Kostet also auch einiges an Zeit.

kiozen schrieb:

Die Mapsforge Java Bibliothek scheint übrigens folgendes zu machen: Die benutzt wohl eine der vorhandenen Render Applikationen/Bibliotheken, um Kacheln zu erstellen und diese Kacheln werden im weiteren Verlauf immer angezeigt.

Zum Vergrößern anklicken....

Die Daten sind soweit ich weiß im Mapsforge-Format bereits zu einzelnen Zellen/Tiles zusammengefasst. Zum Anzeigen werden dann die Tile-Koordinaten berechnet und das entsprechende Tile aus der Kartendatei (mit Hilfe des Indexes und berechneten Offsets) geladen. Die dort gespeicherten Vektordaten (Nodes, Ways, Areas) werden dann nacheinander in einem Canvas gerendert. Daraus wird ein Bitmap erzeugt, welches in der Grundeinstellung im RAM gecached wird (in einer LRU-Queue). Es scheint auch möglich zu sein, den Cache auf einen Datenträger auszulagern.

Die einzigen externen Bibliotheken, die genutzt werden, stammen von Android und bieten Strukturen und Methoden für den Canvas, Bitmaps etc.

Das Ganze geschieht in der Mapsforge-Bibliothek. Wenn man sie nutzen möchte (auf Android), dann kann man die View direkt in sein Layout einbauen, Handler für Interaktion sind auch schon alle fertig (man kann sie aber beliebig überschreiben und auch eigene Overlays hinzufügen).

Das Hauptproblem ist halt, dass Mapsforge so viele Android-Grafikfunktionen benutzt (Canvas, drawRectangle() etc.). Wäre das weiter abstrahiert, könnte man die Bibliothek leicht auf eine andere Java-Umgebung portieren.

Ging-Buh schreibt hier: http://forum.geoclub.de/viewtopic.php?f=114&t=70660
das Mapsforge 0.4.0 unter Java läuft und kein Android mehr braucht.
Ob das von Vorteil ist kann ich nicht bewerten.

Und wenn man noch weiter will, kann man die Mapsforge Libs in dll's wandeln und sich die Zeichen Methoden in .Net umsetzen. Aber erst seit der noch nicht veröffentlichten 0.4.0.

Hier sind die Zeichen Methoden sehr Abstract.

Gesendet von meinem GT-I9300 mit Tapatalk 2

Das ist natürlich genial. Damit würde es endlich eine OSM-Bibliothek für den Desktop geben.

Gibt es eine grobe Einschätzung wann mit der Version 0.4 zu rechnen ist ?

Gruß Klaus