Beiträge von kiozen

Zitat von asterix22

Hallo.
Habe meinen Pc neu aufsetzt. QlandkarteGT diesmal sleber bauen müssen.
Ist jetzt aber leider Englisch. Kann man auf Deutsch umstellen. Hatte zuvor einen
Link (der nicht mehr geht), da war es fertig gebaut auf Deutsch.

Es gibt 2 mögliche Fehlerquellen:

* Die Umgebungsvariable LANG ist nicht zu de_DE gesetzt.

* Die Sprachdateien sind nicht im erwarteten Pfad. Ohne Änderungen installiert cmake alles mit Prefix /usr/local. Viele System erwarten bei der Installation allerdings den Prefix /usr. Das kann man mit ccmake einfach einstellen.

Zitat von asterix22

Habe noch ein weiteres Problem.
Habe die Höhendaten laut Anleitung gebaut. Alles Funktioniert.
Nur wenn ich auf 3D umschalte kommt kein Bild mehr.
Wahrscheinlich wie bei Googel-Earht 5.1 ein Problem mit dem Grafiktreiber.
Zuvor mit älteren qlandkarteGT ging es super.
Danke
leo

Alles anzeigen

Wahrscheinlich hat deine Qt Installation keine OpenGL Unterstützung.

Grüße

Oliver

Zitat von extemecarver

@oliver - hast du dir mal den Sourcecode von GPSMapedit angeschaut bezueglich Darstellung oder Routing? Die Darstellung ist soweit ich sehen kann Großteils im Open Source Code drinnen - Routing konnte ich nicht finden.

Ja, der Konstantin lässt dann halt doch nicht immer 100% die Hosen runter.

Aber zum Problem Routing: Egal was Du machst, die Herausforderung ist immer auf dem PC die gleiche Route zu bekommen wie im Gerät. Alle diese Algorithmen basieren auf dem Gewichten von Kriterien und dem Ziehen des besten Ergebnisses, um dann iterativ weiter zu machen. Solche rekursiven Systeme bitexakt auf verschiedener Hardware laufen zu lassen ist nur mit einer Fixpoint-Implementierung zuverlässig zu realisieren. Garmin scheint dieses nicht zu machen, da Gerät und MapSource oft verschiedener Meinung sind.

Möchte man folglich die Routenplanung des Gerätes nachbilden, sollte man die selben Gewichte benützen, den selben Algorithmus und am besten die selbe Quantisierung. Alles andere führt zu einem Routing, das mit dem auf den Gerät, wenig gemein hat.

Ich bin deshalb von Anfang an dazu übergegangen mir nur Wegepunkte abzuspeichern und das Gerät die Route berechnen zu lassen. Ein Autorouting auf dem PC habe ich nie vermisst. Wer es unbedingt will, darf es gerne einbauen.

Mein Ziel heißt übrigens weg von Garmin hin zur "Rasterkarte". Mit denen kann ich mehr anfangen als mit Vektorkarten. Deswegen konnte ich mich auch die letzten 2 Jahre immer gut davon abhalten ein eigenes Vektorformat zu entwickeln. Abgesehen davon, dass das meine altruistische Ader dann doch überstrapazieren würde. So etwas macht nur Sinn mit vorhandener Hardware und einer Strategie für die Vermarktung. Und spätestens da möchte ich auch was vom Topf sehen.

Aber das ist alles Offtopic. Ich will den Thread nicht entführen. Wenn es stört kann es gerne auch wieder gelöscht werden.

Oliver

Zitat von macnetz

Hallo Oliver,

was Felix mit den TYP-Dateien macht ist nicht von Bedeutung.
Der Sündenfall ist vorher - die TYP-Basteleien sollen das nur ausbügeln.

Grüsse - Anton

Ich finde auch hier setzt er nur konsequent um, was das Format hergibt.

Beim Reverseengineering des Formates fällt jedoch auf, dass Garmin's Softwareentwicklung anscheinend nie 100% das ursprüngliche Kartenformat verstanden hat, oder keine Lust hatte sich daran zu halten. Bzw. die Abteilung für das Karten encodieren es versaut hat und die Decoderseite zwingt ein paar sehr merkwürdige Dinge zu machen.

Egal was der wirkliche Grund ist, Garmin's Decoder ist nur mittelmäßig und wird den eigentlichen Grundgedanken des Formates nicht immer gerecht.

Da aber Garmin lieber Entwicklungszeit spendiert, laufend neue Spin-offs des alten Formates zu kreieren, anstatt mal ordentlich aufzuräumen, befürchte ich, dass sich an der Situation wenig ändert. Zumal es dem zahlenden Kunden reichlich egal sein dürfte, solange ein halbwegs zeitnahes Update ihn von seinen Qualen befreit.

Oliver

Ziemlich wirr das alles...

Also, ich brauche für QLandkarte wirklich jemanden der sich mit Windows auskennt. Das ist kein Allgemeinplatz, sondern eine ehrliche Feststellung. Aber das nur am Rande.

Desweiteren sind nicht die Typ Spielereien vom Felix das Problem, sondern dass Garmin sein eigenes Formatwirrwar nicht auf die Reihe bekommt. Ich habe Garminkarten die crashen immer an der selben Stelle. Der Unterschied zu OSM Karten ist doch nur, dass Garmin für seinen eignen Kram irgendwann einen Fix herausgibt.

Die Dateien vom Felix setzen konsequent um, was die Spezifikation der Typ Datei hergibt. Machen wir uns nichts vor. Typ Dateien sind kein Programmcode, sondern schlichte lineare Attributtabellen für die einzelnen Kartenelemente. Solange die Dateien einen korrekten binären Inhalt aufweisen, liegt der Bug in der dekodierenden Software und nicht an den Daten selber.

Diese Erkenntnis bringt uns natürlich nicht weiter, weil Garmin eben Mainstream ist und resistent gegen Bitten, ihren Kram doch endlich mal richtig zu machen. Aber dem Felix immer vorzuwerfen, dass seine Karten falsch sind, ist doch eine verkehrte Welt. Die Aussage ist doch eher: Mit Garmin ist das nicht sauber zu machen, weil die ihre eigenen Formate nicht 100% verstehen.

Den FUD über Linux lasse ich jetzt mal links liegen.

Oliver

Edit: Zudem muss man sagen, dass Felix uns sehr genau aufzeigt, was ein Kartenformat alles können sollte. Das ist mehr wert als das ständige Genörgel.

Zitat von Klaus_K

Verstehe mich nicht falsch, ich bin großer Befürworter von freien Karten,
aber leider versucht die OSM-Gemeinde zur Zeit der Linux-Gemeinde den
ersten Rang an multiplen Try and Error-Systemen abzunehmen.

Da muss ich schon schmunzeln. Garmin hat so um die 18 Wegepunktformate. Bei den Typ Dateien gibt es anscheinen 3 verschieden Formate. In den letzten Jahren hat Garmin laufend seine Codierung für die Karten geändert. Selten zum Besseren. Meistens von grauselig zu grauselig.

Also wenn es ein Beispiel für Try and Error gibt, dann schein Garmin kein schlechter Kandidat zu sein. Der Benutzer merkt es nur nicht, weil alles hinter Mapsource und der Gerätefirmware versteckt wird. Eine sauber designte Software würde jedoch schneller sein und auch einfacher zu portieren.

Zitat von Klaus_K

Auch wenn ich jetzt bei der kompletten Linux-Fraktion versch.... habe, bis
die Hölle zufriert, ich weiß wovon ich rede! SORRY.

Immer wieder lustig, wenn jemand nach ein paar Allgemeinplätzen trotzig die allgemeine Deutungshoheit für sich beansprucht.

Mir persönlich wäre es nur recht wenn die Formathölle bei Garmin zufriert und ein durchdachteres offenes Kartenformat den Kram ersetzt. Ich hege da allerdings meine Zweifel. Schön wäre es trotzdem.

Oliver

Zitat von extemecarver

Nein, das geht leider nicht. Das Routinglayer welches fuer Garmin Geraete benutzt wird, wird als allerletztes gerendert (geht nicht anders) - daher kann ich vorher nicht die Namen loeschen.

Namen loeschen per {set name = ''} zeigt leider auf einigen Geraeten dann '' an. Was du umsetzen solltest ist einfach wo du Namen renderst und wo nicht. Dies ist im Typfile definiert. Ich hab immer nur am routingfaehigen Weg eine Beschriftung im Typfile aktiviert.

Bei Garmin GPS/Mapsource ist das loeschen des Wegnamens daher nicht noetig.

Ich suche mir hier gerade den Bären nach diesem Flag. Wo muss ich unter http://ati.land.cz/ hintreten um es zu finden?

Oliver

Hallo Felix,

wäre es möglich bei den ganzen übereinander gelegten Linien nur einer den Straßennamen zu geben und allen anderen keinen Text. Wir hatten das schon mal ;). Die Lesbarkeit würde enorm steigen. Zudem müsste weniger Text entlang der Linien gerendert werden. Das schadet bestimmt auch nicht.

Oliver

Zitat von morgen1

edit: den Dateinamen der preview kann man nicht aus der TDB auslesen. Es steht nur der Mapnamen drin. Da irrte ich.

Die Basemap ist nur anhand ihrer Zoom Levels zu erkennen. Ich überlege schon andauernd ob ich eine automatische Erkennung in QLandkarte einbauen soll. Nur leider gibt es Kartenhersteller, die sehr virtuos mit den Zoom Levels umgehen. Die freie Neuseelandkarte ist so ein Beispiel. In diesem Fall würde der Algorithmus auf die Nase fallen. Ist halt auch keine narrensichere Lösung. Leider.

Oliver

Zitat von asterix22

Kann man auch Höhenlinien einfügen?
Danke

Du kannst mit den Radioknöpfen, unten in der Statuszeile, eine Schattierung über die Karte legen. Linien selber gehen nicht. Ein Gradientenalgorithmus wäre zu aufwendig, um die Linien on-the-fly zu berechnen. Zudem ist so etwas nicht einfach, wie man bei der Topo Südtirol sieht. Bei steilen, zerklüfteten Bergen versagen viele Algorithmen.

Wenn Du jedoch Höhenlinien einzeln im Garminformat hast, kannst Du die über der Karte anzeigen. Dazu einfach die "M" Spalte bei der Höhenlinienkarte anklicken. "M" für Mode, "T" für Typ. Damit kannst Du auch beliebige Vektorkarten überlagern, bzw Vektorkarten über Rasterkarten legen.

Grüße

Oliver

Zitat von asterix22

hallo.
Wahnsinn Euer Wissen. Ist mir aber noch alles zu hoch.
Ich habe nur ein Problem beim reinzoomen.
Qlandkarte GT hängt sich bei Tirol ab 3km auf.

Link zur verwendeten Karte. Koordinate. Ansonsten kann Dir keiner helfen. Kristallkugeln sind rar Wenn ich den Fehler reproduzieren kann, hast Du eine Chance, dass wir das lösen können.

Oliver

Zitat von extemecarver

Waere es denn moeglich eine eigene Zusatzdatei fuer Qlandkarte GT zu schreiben, wo definiert wird, welche Linie durchgaengig ohne Bitmap anzeigbar ist, plus Farbdefinition?
Bzw dazu noch ein paar fixe Muster die ohne Bitmaps dargestellt werden koennen?

So etwas ähnliches gab es im alten QLandkarte :). Aber das ist auch keine Lösung. Das mag für Dich und mich ok sein. Für viele andere Nutzer ist das zu kompliziert. Im alten QLandkarte hat es nie jemand benutzt.

Ich denke es geht nur mit Optimierung. Entweder über OpenGL oder mit einem Cache ähnlich MapSource. Für beides fehlt mir jedoch im Moment die Zeit und die Geduld. Vielleicht macht sich ja jemand anderes mal dran. Immerhin gibt es eine gute Vorlage. Das ist besser als sich den Kram von Anfang an selber aus den Fingern zu saugen.

Oliver

Zitat von extemecarver

Gerade die Landschaft hilft einem ja noch in Qlandkarte GT sich zurechtzufinden da sie bei mir zumindest verzoegerungsfrei aufgebaut wird und beim pannen weiter angezeigt wird. Das groeßte Performanceproblem sind Hohenlinien. Wenn man die anpasst (damit sie etwas unauffaelliger sind) dann wirds leider selbst mit gutem Rechner langsam (2-3 sek fuer Bildaufbau im Gebirge).

Ein großer Fortschritt waere also, falls 0x20-0x26 erst gerendert werden, wenn der Rest schon fertig ist.

Klar. Mit dem Typisieren der Höhenlinie machst Du aus einer Vektorlinie eine Bitmaplinie. Da ja jeder jede Linie nach Gusto abändern will, geht es nicht anders. Das war früher besser. Da habe ich aus dem Bitmap im Typ versucht eine Strichlinie zu erraten. Hat auch super funktioniert, solange das Bitmap auch eine Strichlinie war. Bei komplexen Bitmaps kam es zu lustigen Ergebnissen.

Ich kann es nur wiederholen: Entweder die Karten halten sich an einen gewissen Standard auf den man hin optimieren kann. Oder man lässt alle Freiheiten zu. Dann ist es halt langsam. Ein so schön optimierte Renderengine für Bitmaplinien wie auf den Geräten selber haben wir auf dem PC leider nicht.

Zitat von extemecarver

Weitere Loesungen waeren, beim verziehen den alten Bildschirminhalt noch anzeigen - dies wuerde ungemein helfen (also nicht nur Polygone sondern auch noch die alten Polylinien) - evtl koennt ja zumindest 1000Pixel Umkreis um die aktuelle Kachel an Polylinien vorausgecached werden die dann beim verschieben noch angezeigt werden. Nach loslassen werden diese dann neu gerendert.

Das würde sicherlich beim Ziehen helfen. Beim Zoomen nicht. Und es müsste in einem Backgroundthread laufen. Zusätzlich müsste das Rendern im Hintergrund sofort abgebrochen werden, wenn die Karte erneut gezogen wird. Das ist alles recht tricky und fehleranfällig. Und ich weiß nicht wie das bei Leuten mit Singlecore funktioniert. Die könnten dabei die Leidtragenden sein.

Oliver

Zitat von extemecarver

Du koenntest versuchen die Performance so wie Mapsource >6.13.7 zu verberssern, indem einfach vorausschauend bei nichtstun Karten als bmp gecached werden. Also 1. zoom in eine Stufe, 2. Zoom out eine Stufe, 3. auf aktueller Zoomeinstellung, Anzeigegroeße "mal 9 außen rum legen"

Dann wuerde die langsame Performance auch bei 1920x1200 nicht so auffallen.
(nur im Gegensatz zu Mapsource nach schließen des Programms am besten die alten bmps loeschen, oder Speichergrenze festlegen, damit man nicht Hunderte GB Tempfiles rumliegen hat wie bei Mapsource.

:D:D:D Die Sache stinkt in Mapsource. Sie wird auch in GT stinken.

Das Problem sind in erster Linie die Bitmaplinien. So schön die auch sind und was man damit nicht alles anstellen kann. Nur ist keine mir bekannte Renderengine darauf optimiert.

Eine Idee war mal alles auf OpenGL umzustellen. Dann müßte nicht die CPU alles machen. Nur beißen dabei alle ATI und no name Graphikkartenbesitzer ins Gras. Eine weitere Idee wäre Multithreading zu benützen. Dann wären alle Multicorebesitzer glücklich. Nur ich hätte noch weniger Haare und die wären alle grau.

Eine einfachere Linien Graphik würde schon helfen. Aber die will ja niemand mehr. Also die einzige Lösung: Kauft euch anständige Rechner. Auf meinem Quadcore geht es auch mit 2560x1600 noch recht nett.

Ach ja 500ms Verzögerung beim Zeichnen sind übrigens normal. Das wird beim Zoomen und Schieben benötigt. D.h. die Karte baut sich erst nach 500ms ohne Veränderung mit Linien neu auf.

Und für die Kartenhersteller: Vermeidet in den oberen Zoomleveln jedes überflüssige Polygon-/Polyliniensegment. Alles außerhalb des Levels mit der größten Detaildichte benötigt sowieso kaum noch Information. Wenn ich sehe, wie zum Teil immer noch Wald bis in den kleinsten Zipfel dargestellt wird und jeder Bach mit Teil der Übersicht ist, dann wundert mich nichts mehr. Die OSM Karte hat in dieser Richtung schon gut optimiert. Aber da geht noch was.

Oliver

Zitat von 24shorty

Da hier grad recht intensive Diskussionen sind:

Hab es nun geschafft QLandkarte unter Win7 zu installieren udn die ersten Karten laden können. Leider läuft das Programm sehr stockend und langsam.

Aber egal: Ich wollte fragen wo ich denn diese schicke contour shading Ansicht einstellen kann?

Hab die OpenMTBMap und OSM Radkarte drin. mindestens die 2. hat ja die Conturlienien mit drin in der Karte. Bei der ersten müsste man wohl die Höhenlinien noch drüber legen. geht das?
Wo stelle ich diese "3D Karte" ein. Bisher ist die 3D Karte ein flaches Brett

Alles anzeigen

Dazu benötigst Du Höhendaten. Eine gute Auswahl findest Du hier: http://www.viewfinderpanoramas.org/dem3.html. Als nächstes musst Du diese Daten in ein Format bringen, das von QLandkarte verstanden wird. Außerdem müssen die Daten die richtige Projektion und das richtige Kartendatum haben. Solange Du Vektorkarten für Garmin benützt ist das einfach, weil diese sich auf die Projektion/Datum der SRTM Daten anpassen können. Bei Rasterkarten musst Du die Projektion kennen. Wenn etwas nicht stimmt wird dir QLandkarte jedoch sagen was Sache ist.

Ok, soweit die Theorie. Um deine eigene SRTM Datei zu erstellen benötigst DU GDAL. Wie praktisch dass dieses schon installiert ist. GDAL bietet eine Shell an. Diese solltest Du benutzen.

Damit wandelst Du eine Datei vom oben genannten Server in ein GeoTiff um:

gdalwarp -t_srs "+proj=merc +lon_0=0 +k=1 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84 +units=m +no_defs " -r cubic <sourcefile> <target>.tif

Als nächstes kannst Du mehrere Dateien zusammensetzen. Das geht so:

gdalwarp -r cubic  <file1> <file2> .... tmp.tif

Und zum Schluss willst Du die Sache noch etwas optimieren:

gdal_translate -co tiled=yes -co blockxsize=256 -co blockysize=256 -co compress=deflate -co predictor=1 tmp.tif srtm.tif

Fertig. Im Sourcecodearchiv von QLandkarte GT gibt es dazu auch ein Pythonskript, dass alle Dateien in einem Verzeichnis konvertiert, zusammensetzt und optimiert. (srtmconvert.py)

Nun zum 3D View: Du musst in QLandkarte deine neuen SRTM Daten mit der Karte verbinden. Dazu zeigst Du die Karte an und klickst mit der rechten Maustaste auf den Eintrag in der Kartenliste links. "DEM hinzufügen" Danach sollte QLandkarte zu den Mauskoordinaten auch die Höhe mit angeben. Natürlich nur für das Gebiet von dem Du die Höhendaten auch hast. Wenn das klappt kannst Du in die 3D Ansicht wechseln. Mit der rechten Maustatste auf der Karte kannst Du zwischen der flachen und der modellierten Ansicht wechseln.

Zur Performanz unter Windows kann ich wenig sagen. Unter Linux und einem halbwegs aktuellen Rechner läuft es ganz gut. Wobei die Anforderungen der aktuellen Kartenspielereien auch dort spürbar die Performanz gedrosselt haben. Aber ihr wollt es ja nicht anders haben

Oliver

Ja stimmt. Da hat sich was geändert. POIs und Points (Garmin macht da Unterschiede) werden jetzt beim Text gleich behandelt. D.h. erst beim nahen Zoom angezeigt. Der Grund dafür war der immer dichter werdende Punktewald, der, wenn Text angezeigt wird, die Karten unübersichtlich macht.

Oliver

Zitat von asterix22

Das erste mal zeigte er dann die Dateien mit **.img an. Jetzt kann ich aber keine Weitere mehr auswählen.

Du musst an dieser Stelle die Basiskarte wählen. Keine Detailkachel. Leider ist der Name der Basiskarte nicht verbindlich und somit macht jeder Kartenhersteller es anders. Bei Garmin heißen die meistens basemap.img. Im OSM Projekt hat in der Regel die Basiskarte den selben Namen wie die TDB Datei.

Wähle mal eine andere Karte als die jetzt falsch eingebundenen Vektorkarte. Dann mit der rechten Maustaste auf die Vektorkarte klicken und "löschen" auswählen.

Jetzt kannst Du es nochmal versuchen. Und bei den Dialogen genau lesen Es steht dort in der Regel immer sehr genau, was erwartet wird.

Oliver

Zitat von mrueger

Im Kartenfenster werden bei mir keinerlei Ortsnamen (rote Punkte MG Europe9 nur wenn man mit Mauszeiger drüberläuft wird der Ortsname im rechten oberen gelben Fenster angezeit) angezeigt.
Ist das Absicht oder ein Einstellungsproblem (gefunden habe ich nichts, vielleicht muss man die conf-Datei editieren ?). Das ging glaube ich in einer früheren Version mal.

Die Texte von Punkten und POIs werden erst ab einem gewissen Zoomlevel angezeigt. Also hol die Karte mal nah ran, dann sollte auch Text zu sehen sein. In den neueren Versionen von QLandkarte gibt es auch eine Checkbox in der Statuszeile mit der man die Texte an und aus schalten kann. Das ist in Stadtzentren recht hilfreich wenn man vor lauter Text keine Karte mehr lesen kann.

asterix22: Es ist leider nicht wirklich ersichtlich was Du genau machst und was nicht funktioniert. Ich vermute mal, dass du eine einzelne IMG Datei laden möchtest. Das geht in der Tat nicht mehr. QLandkarte GT benötigt eine Kachelsammlung bestehend aus einer *tdb Datei, einer Basiskarte und mehreren Kacheldateien. Die üblichen OSM Karten werden auch immer als solches angeboten.

HTH

Oliver

Zitat von extemecarver

proj_fw.dll muss in den Systempfad. dann klapt es. Wird leider glaube ich von der Installation standardmaeßig nicht gemacht.

Sollte der QLandkarte Installer eigentlich automatisch kopieren. Ansonsten proj.dll einfach nach proj_fw.dll kopieren. Kann auch nix dafür dass FWTools nicht sauber installiert.

Ich bräuchte wirklich mal jemanden der sich mit Windows auskennt. Ist nicht meine Welt.

Oliver

Zitat von extemecarver

Muss es noch mal unter Ubuntu probiern, mein XP 32bit laeuft einfach nicht mehr rund auf dem Rechner (und am Laptop ist Qlandkarte GT einfach unfassbar langsam).

Jo, kein Wunder. Die ganzen Kartenspielereien die mittlerweile im Netz rumkreuchen und fleuchen zwingen mich ja auch sukzessive jeglich Optimierung zu begraben und die Sache auf die übelste Art zu realisieren. Mit dem neuen Release habe ich z.B. die Straßen in der Grundeinstellung auf Bitmap-Polylinien umstellen müssen, weil wohl im Moment weiße Straßen en vogue sind. Und eine weiße Linie auf weißem Grund macht sich nicht gut, es seiden sie hat einen schwarzen Rand. Und der geht nur über ein Bitmap. Das effizient über 2 Polylinien zu realisieren habe ich schon vor einem halben Jahr begraben, weil sowieso jegliche Linie, auch die trivialen, in den Typfiles als Bitmap abgelegt werden.

Aber zum Glück ist die Bottomline bald erreicht. Schlimmer geht es dann nimmer.

Oliver

Zitat von extemecarver

Perfekt, funktioniert nun unter Windows 7 x64 (und damit wohl auch unter Vista).

Ein kleines Problem gibt es aber.....

Bei meinen Karten verschwinden die Straßen hinter dem Map Background Polygon. Koenntest du schauen dass 0x4b und 0x4a NIE angzeigt werden, bzw wenn nur im Hintergrund?
Diese Polygone sorgen dafuer, dass am GPS der Hintergrund nicht gelb ist.

Das wäre schön wenn sich die Probleme mit Vista so einfach lösen lassen.

Zum Background: sollte nicht das Typfile die Reihenfolge bestimmen? Und warum verschwinden die Straßen? Polylinien werden doch erst nach den Polygonen gezeichnet. Felix! was machst Du nur wieder! Ich muss mir mal die aktuelle Karte ziehen...

Oliver