Beiträge von kiozen

Zitat von Glücki

Welche freie Karte für Garmin-Geräte für allgemeinen Einsatz in Deutschland haltet ihr derzeit als die beste?

Mir geht es um eine "Standard" Karte, die z. B. auch für Navigation mit Auto oder zu Fuß geeignet ist.

Derzeit im Gebrauch habe ich De_all in One (allgemeine Verwendung) und OpenMTBmap (Verwendung auf dem Fahrrad), insbesondere deshalb, weil beide Karten routingfähig sind.

Gibt es Alternativen, die diesen Karten überlegen sind?

Danke!

Alles anzeigen

Über Geschmack lässt sich streiten. Da aber alle OSM Karten auf der selben Datenbasis aufbauen, gibt es Inhaltlich keine bessere OSM Karte. Nur die Darstellung ist anders. Welche Darstellung Dir besser gefällt, kann niemand für Dich entscheiden.

Meiner privaten Meinung nach, hast Du schon die beiden Besten ausgewählt. Aber am Schluss von diesem Thread wirst Du alle Karten, die es gibt, empfohlen bekommen haben

Grüße

Oliver

Zitat von t31_a

Mittelalter, der Konkurrenz wirds freuen.

Welche Konkurrenz im Bereich der Vektorkarten-basierenden Outdoorgeräte?

Magellan hat sich erfolgreich weggebeamt. CompeGPS, Lowrance, Delorme und wie sie alle heißen versuchen ihr Glück in der Nische "Rasterkarten für echte Männer". TomTom fragt: Outdoor was ist das? Und dandylike, ohne Empfang mit einem IPhone/Googlephone/Ähnlichem in der Pampas stehen, bringt es auch nicht.

Ich bin bei weitem kein Freund von Garmin. Aber bei der Konkurrenz ist es nur verständlich alle Outdoor Kunden hart an der Kandare zu nehmen und ordentlich zur Kasse zu bitten. Ich glaube Garmin könnte sogar in die Verpackung s......, die Leute müssten/würden kaufen.

just my 2 cent

Oliver

Zitat von JürgenD

Moin,

das Maß der Dinge ist für mich Garmin. Was der Online-Editor oder QLandkarte machen ist mir dagegen relativ egal. 'koizen' schreibt da was von einem 1. Byte 0x6e ( in Polygon ? ). Da ist Bit 6 gesetzt, was ich bisher in keiner Garmin TYP-Datei gesehen habe. Folglich werde ich es auch nicht setzen ( wobei es Garmin scheinbar nicht weiter auswertet, zumindest nicht in MapSource ).

Hallo Jürgen,

es geht darum zu erkennen ob die erweiterten Typen in der DrawOrder Tabelle als Wert oder als Bitfeld kodiert wurden. Bisher dient mir dazu das allererste Byte in der Typdatei. Sollte es auch anders gehen, wäre es schön wenn Du dich dazu äußern könntest.

Grüße

Oliver

Zitat von extemecarver

Das erklaert mir aber nicht warum 0x28 oder 0x1100e nicht dargestellt werden. 0x110?? wird inzwischen auch von Garmin verwendet, nur ati.land loescht die leider gnadenlos raus. IMHO

Wen das erste Byte in der Typ Datei 0x6E ist, sollte es keine Probleme geben. QLGT trägt dann alle Polygone in die DrawOrder Tabelle ein. Und was in dieser Tabelle steht, wird auch später beim Zeichnen berücksichtigt. Wenn nicht, brauche ich ein nachvollziehbares Beispiel.

Zitat von extemecarver

Leider ist von maptk kein Sourcecode erhaeltlich - bei ati.land ist aber AFAIK auch lange nicht alles quelloffen.

Aber das Wesentliche, um mit den Typdateien klar zukommen, schon. Ich will dem Author von maptk auch keinen Vorwurf machen. Es ist seine Arbeit und er soll frei darüber entscheiden. Nur kann so etwas eben nicht als Referenz hergenommen werden. Dazu taugt nur der öffentlich bekannte Codestand. Aus meiner Sicht ist der im Moment für alle quelloffenen Projekte auch ausreichend. Und bis auf die paar kleinen Unstimmigkeiten deckt sich alles mit maptk.

Und was Garmin in der letzten Zeit anstellt, interessiert mich nicht. Sollen die nur ihr Format fix ändern, dann habe ich endlich Ruhe

Grüße

Oliver

Zitat von extemecarver

ati.land erkennt leider nicht alle Typen, und ist IMHO auch sonst nicht besonders bugfrei.

Es decodiert sicher nicht alles. Aber das was es macht, sieht vernünftig aus. Maptk ist meines Wissens Closed Source und damit als Referenz wertlos. Korrigiere mich wenn der Source Code doch irgendwo herumliegen sollte. Ich habe auch keine Lust Pyc Dateien wieder in Quellcode zu verwandeln. Also würde ich doch vorschlagen, dass offener Quellcode die Referenz sein sollte und nicht die Geheimniskrämerei.

Zitat von extemecarver

zu 1. werde ich mal Juergen von maptk fragen. Ati Land jammert da immer rum, und ich verstehe den Grund nicht. Ati Land ist ja auch

Es gibt einen Unterschied in der Codierung der erweiterten Typen innerhalb der "Draw Order". Ati Land benützt zur Unterscheidung das Descriptor Byte. Möglich dass es auch noch eine andere Unterscheidung gibt. Nur ist die mir nicht bekannt.

Zitat von extemecarver

nicht in der Lage die Typfiles von neuen Garmin Karten auch nur annaehernd korrekt zu bearbeiten und produziert da zig Fehler (etwa typfile von der Garmin Transalpin Demokachel).

Ja, schreibt er ja auch. Das Format ist ihm nicht bekannt.

Zitat von extemecarver

und 0x2d kommt gar nicht im Typfile vor.

Im Typ nicht, aber in der Karte. Und da es dafür keine Standarddefinition gibt, jammer QLGT auf der Konsole und zeichnet 0x2D in schönstem Magenta. IMHO sollte es deshalb im Typ definiert werden wenn es benutzt wird. Bei anderen Karten tritt das Problem nicht auf. Sie benutzen 0x2D entweder nicht oder liefern eine Definition.

Zitat von extemecarver

Siehe hier die Sektion als .prj - ich wuesste nicht wo da ein Fehler sein sollte - schon klar dass es nicht darstellbar ist, kommt ja auch nicht in der Karte vor.:

Code

[Polygon]
Type=0x0f
DrawOrder=2
String=4,invisible
[END]

-- Hab hier mal das .prj fuer dich mal gezipped angehaengt (.prj ist ein reines Textformat von maptk).

Das Ding erscheint als color type 8 in der Polygonsektion. Es fehlt aber die zu color type 8 fehlende Farb- und Bitmapinformation. Mir ist auch keine Bit aufgefallen, das dem Decoder das Fehlen dieser Information anzeigt. Wenn es eh nur ein Platzhalter ist, lass es doch einfach weg.

Grüße

Oliver

Zitat von extemecarver

So damit es nicht untergeht als eigener Post. Leider werden ein paar Polygone gar nicht angezeigt. Etwa 0x28 oder 0x1100e. Schau dir mal die "Legendenkarte" in Mapsource vs Qlandkarte GT an. Es gibt ein paar Typen die scheinbar fallengellassen werden.

Ok was sagt dazu meine Kristallkugel auf http://ati.land.cz/gps/typdecomp/

• Header is in OLD format, but DrawOrder sections uses short types with subtype bitmap. It will be converted automatically.
• Corrupted file or file in unknown format! Last address in TYP file is 0x100f8, but first datablock in TYP ends at address 0xff52!
• Unknown datablock #1 at 0x0000ff53: ; 00000000 00 00 4D 61 70 54 6B 20 - 32 2E 37 00 ..MapTk 2.7.

Punkt 1 ist das Problem. Das Perlskript mag ja gerne eine Datenanalyse machen und daraufhin auf das richtige Format tippen. QLandkarte kann sich solche Dinge nicht leisten. Also richtige Format ID (erstes Byte 0x6e) und es klappt auch mit QLandkarte.

Die anderen beiden Punkte sehe ich jetzt als weniger problematisch an. Aber Polygon 0x0f ist definitiv kaputt. Da fehlen Bytes. Ist mir schon beim Entwickeln aufgefallen. Und Polygon 0x2D ist meines Wissens kein "welknown" Polygon. Also für GT auch nicht definiert.

Ansonsten sieht es nach einer "Formatwäsche" auf http://ati.land.cz/gps/typdecomp/ gut aus.

Grüße

Oliver

Zitat von extemecarver

auch noch auswertet, und man dann im Typfile dieselbe Flaeche mit unterschiedlicher DP anlegt (dazu gibt es aber nicht genug IDs).

Reichen die 16bit IDs nicht aus? Man muss ja nicht jedem Polygon eine eigene ID verpassen. Aber der ID Raum sollte doch ausreichen, um alles in der richtigen Reihenfolge zu zeichnen. Sicher, dass man das Problem nicht auch durch cleveres Strukturieren der Daten lösen kann?

Zitat von extemecarver

Was mir nicht gefallen hat: Bei Einstellung details=-1, sieht man max resolution 22, resolution 24 wird dann gar nicht angezeigt. Besser waere wenn es so wie in Mapsource gehandhabt wird, dass es einfach nur einen Zoomschritt spaeter/frueher kommt.

Hm, ja, bei den Details manipuliere ich nur die Zuordnung Zoomlevel<->Bits. Und daraus resultiert der Maplevel. Das ist nicht gut. Besser wäre es wie Garmin damit Elementfilter zu steuern, die bestimmte Elementgruppen anzeigen oder unterdrücken. Wenn es halt nicht so ein erbärmliches Gefrickel wäre...

Zitat von extemecarver

Ausserdem scheinen mir die Zoomschritte zuerst recht langsam weniger Detail, dann aber sind recht schnell alle Details weg. Mapsource/GPS aendern die resolutionen weniger rasant.

Die Zuordnung Zoomlevel<->Bits ist auf Garminkarten abgestimmt und behält ein wenig länger die höchste Detailstufe als MapSource auf "normal". IMHO sollte das die Referenz sein. Wenn Dir das zu rasant ist fehlt ein Level

Zitat von extemecarver

Drittens, faende ich es gut wenn ab dem Zeitpunkt wo keine Daten mehr vorliegen, die Kachelgrenzen angezeigt werden. So denkt man sich manchmal dass die Karte gar nicht funktioniert (klar ist F3 und dann reinzoomen immer funktionierend, nur wenn man Mapsource gewoehnt ist, dann denkt man die Karte ist kaputt/fehlt).

Das ist ein Feature von deiner Karte. Alle anderen haben ihre Kachelgrenzen ordentlich in der Basemap abgelegt. Es funktionieren sogar mit nicht rechteckige Grenzen verschiedener Auflösungen.

Nachtrag: ich sehe gerade, es funktioniert doch auch mit deiner Karte. openmtbmap_de. Wo liegt das Problem?

Nachtrag2: Bei der openmtbmap_dby_09.11.2009 geht es nicht. Da sind nur 2 Rechtecke zu sehen. Da scheint der Wurm in der Basiskarte zu sein.

Zitat von extemecarver

Ist aber nicht so wichtig, nur halt etwas ungewohnt. Wichtiger waere das was wir schon "hatten. Etwa vorauscachen oder aehnliches um schnelleren Kartenaufbau hinzubekommen. Aber soweit ich dich verstanden hab, wird das nicht gehen da die Renderingengine ja nicht von dir kommt, bzw waere es superviel Aufwand.

Doch die Renderengine kommt 100% von mir. Nur mit dem Cachen habe ich Probleme. Ich will nicht das gleiche Datengrab wie MapSource bauen. Interessanter wäre in diesem Fall die Polygone in einem Thread zu zeichnen, und das Gui peu a peu neu zu Zeichnen. Auf einem Singlecore dauert das länger, auf einem Multicore ungefähr gleich. Gefühlt wird es wahrscheinlich schneller, weil sich was tut und das Gui nicht blockiert. Ist reine Psychologie.

Zitat von extemecarver

Ist jetzt eh schon viel viel besser wie noch vor ein paar Versionen. Evtl waere es ja auch moeglich dass die Linien nacheinander aufbauen, und nicht alle auf einmal, oder beim pannen duenne schwaerze Ersatzlinien angezeigt werden, die dann uebermalt werden. Falls die Bitmaps das Problem sind, koennte Qlandkarte GT evtl intern ein ExpressTypfile erstellen, welches nur einfarbige duenne Straßen hat (basierend auf einer verwendeten Farbe), und dann von den korrekten Bitmaps uebermalt wird.

Das ist mit 0.17.0 Geschichte. QLGT benützt jetzt nur noch Bitmaplinien wenn diese explizit im Typ so eingestellt wurden.

Zitat von extemecarver

Ich wuerde eh noch resolution=23 in die Karten aufnehmen, um 22 etwas zu leeren, aber die Kartengroeße fuer Downloads steigt dadurch halt recht stark an (wenn ich 24,23,22,21,20,19,18,16 statt 24,23,22,21,20,19,18,16 benutze - je "hoeher" die resolution desto teurer ist jedes extralevel.)

Wenn es schön smooth gehen soll ist eine Leveleinstellung wie bei den Garminkarten unumgänglich. Eine Basiskarte mit einem groben Straßennetz und Hauptstädten würde auch dazu beitragen.

Grüße

Oliver

Zitat von extemecarver

2. Mehr oder weniger 100% korrekte Darstellung.

"Mehr oder weniger" oder "100%"? Beides zusammen ist nicht. Und wenn "Mehr oder weniger", wo liegt das "weniger"?

Aber jetzt mal ohne Flachs: Wenn noch was fehlt, bitte die Koordinaten mit Fehlerbeschreibung an mich. Das ist sicher nicht das letzte Wort zu dem Thema, und einige Dinge im TYP werden zwar dekodiert, aber nicht in der Renderunit umgesetzt, da mir einfach das Verständnis dafür fehlt.

Naja und die Geschwindigkeit bzw das Routing hatten wir ja schon....

Grüße

Oliver

Zitat von lost

Verwende TTQV zum Erstellen meiner Touren - bzw. zum Erkunden unbekannten Geländes ;-)) - und in weiterer Folge zum Export der Routen auf den Oregon.

Würde gern die Windows - Variante umgehen, geht aber scheinbar nicht.....:(

QLandkarte GT läuft auch unter OSX. Beim aktuellen Release sind viele Patches für Macs dabei. Für "big edian" als auch "little endian" Maschinen. Einziger Wermutstropfen: Du musst im Moment noch alles selber kompilieren. Wie das geht steht in der Datei INSTALL. Vielleicht erbarmt sich ja auch jemand aus dem Apple Lager und bietet einen Build Service für Pakete an. Wer weiß...

Oliver

Hallo Klaus,

alles klar. Vertragen wir uns wieder :D:D:D

Zu deiner Frage warum das nicht so einfach geht wie bei Windows:

Das liegt zum einen daran, dass Windows seit Jahren nichts an seiner API ändert. Das hat den Vorteil, dass die Software auf den ollen und den neuen Kamellen läuft. Das hat den Nachteil, dass seit Jahren Entwickler über die wirklich seltsame API stöhnen. Da bewegt sich nix.

Zum anderen ist jedes Programm unter Windows ein Autist. Offene Kooperation von Software gibt es nur bedingt. Eine Applikation für Windows hat ihr Verzeichniss und schleppt allen Kram, den sie benötigt, mit. Aus diesem Grund ist der Installer von QLGT für Windows auch so fett. Da ist bis auf FWTools alles mit dabei. Und die zusätzliche Installation von FWTools macht auch des öfteren den Ärger.

Linux tickt hier anders. Programme teilen sich die Verzeichnisstruktur. Alle Ressourcen sollten im Idealfall nur einmal im System vorhanden sein. Zudem werden die APIs der Bibliotheken schonungslos, ohne Rücksicht auf Verluste, weiter entwickelt. Da jeder alles neu kompelieren kann ist das auch kein Beinbruch wie bei Windows. Obwohl es ja vermehrt Stimmen gibt die fordern endlich bei der libc damit aufzuhören :D. Der Vorteil davon ist eine enorme Innovation. Wenn sich etwas nicht bewährt fliegt es raus. Neue Konzepte werden gerne übernommen. Das sorgt für Unruhe, wirft aber auch viele wirklich gute und brauchbare Konzepte ab.

Diesem Umstand ist es zu verdanken, dass die Software für jede Distribution, ja sogar für jede Version innerhalb einer Distribution neu kompeliert werden muss. Bei einer gut funktionierenden Distribution ist das kein Problem. Bei weniger gut aufgestellten geht es schnell in Richtung Albtraum.

Nun zu Ubuntu. Das basiert auf Debian. Debian ist sehr konservativ was das Übernehmen neuer Bibliotheksversionen angeht. Manchmal von Vorteil. Ärgerlich wenn deshalb eine GDAL Version mit Bugs über ein Jahr im System hängt und nur Probleme bereitet. Das ist zum Glück inzwischen gefixed. Aber leider wird wohl der Sektor GIS bei Ubuntu weiter stiefmütterlich behandelt. Da fühlt sich keiner aktiv verantwortlich. Deshalb sind die Pakete veraltet, bzw die Pakete die es gibt, wollen nicht immer auf jeder Version. Und für's selber kompelieren ist Ubuntu nicht per default ausgelegt. Das ist bei denen Konzept und Ziel. Was nicht heißt, dass es nicht genauso gut geht. Nur halt nicht aus der 0815 Installation heraus.

Könnte man es besser machen? Klar ich könnte ähnlich wie Firefox oder ähnliche Software alles statisch linken und wie bei Windows als großen binären Blob anbieten. Solange an der libc nicht gedreht wird, könnte das auch funktionieren. Diese Windows-fizierung wird aber nicht gerne gesehen und sollte auch nicht Schule machen. Das entspricht nicht dem Grundgedanken des Systems.

Folglich landen wir wieder bei den Distributionen. Und hier kann ich nur empfehlen entweder eine Passende zu suchen, oder Bugreports zu schreiben. Je mehr User in Bugzilla ningeln, dass eine bestimmte Software veraltet ist, oder sich nicht sauber installieren lässt, desto eher kommt das Problem bei den Distributionspflegern auf den Tisch. Das ist wie im Vogelnest. Der größte Schnabel bekommt den Wurm.

So, ich hoffe ein wenig Licht in die Geschichte gebracht zu haben.

Grüße

Oliver

Klaus,

Zitat von Klaus_K

Hallo Oliver,
den Schuh ziehe ich mir nicht an und weise das weit von mir.

ich kann Dich nur über deine Beiträge zu dem Thema beurteilen. Und die wirken nun mal etwas undifferenziert. Da oben steht ein genereller Rundumschlag über Linux, Ubuntu, virtuelle Maschinen, Google Earth und zu allerletzt wird QLandkarte mit einer zugegeben wirren Anleitung vorgeführt, die von einem 3., also nicht dem Autor der Software, geschrieben wurde. Also was soll ich davon bitte halten? Für mich klingt das so, als ob jemand sich beweisen wollte, dass das alles Mist ist, und danach einfach mal ein wenig in die Richtung stänkert. Wir sind hier in der Plauderecke, es sei Dir vergönnt. Nur akzeptiere auch wie Du dabei wirkst.

Zitat von Klaus_K

Wenn ich die Systeme von Kunden administrieren müsste und der eine hat Ubuntu, der nächste RedHat wieder ein anderer schwört auf Knoppix oder Kubuntu, dann würde ich denen den Vogel zeigen und sagen, sie sollten sich mal auf ein System einigen.

In meinem Büro darf jeder haben was er will. Da schwirren diverse Linux- und Windowsversionen herum. Jeder ist damit glücklich, alle arbeiten zusammen. Das geht, wenn man will.

[quote='Klaus_K','http://www.naviboard.de/_wbb/index.php?thread/&postID=334863#post334863']
Den Wahn stellt folgende Grafik dar, leider stellt sie nur die Entwicklung bis
2008 dar. Das reicht mir aber auch schon.
Klick auf die Grafik zum Vergrößern
[/quote]

Ja, so kann man das sehen. Erinnert mich ein wenig an die Kampagne von Mircosoft mit den Wolperdingern. Nur muss man ja nicht alle diese Distributionen auch verfolgen und die wenigsten haben wirtschaftliche Relevanz.

Mein rein persönlicher Favorit seit über 10 Jahren ist SuSE. Während dieser Zeit gab es Höhen und Tiefen. Einige DVDs, vor allem die mit einer 0 am Ende, wurden grausam 'ermordet'. Verglichen zum Kollegen mit Windows war die Zeit aber nicht schlechter. Als z.B. Vista kam hatten wir genauso viel zu Lachen. Es ist ehrlich gesagt Jacke wie Hose. Unter Windows habe ich ein Image mit allem. Linux kann man mit allem Pipapo in der selben Zeit installieren. Die übliche 0815 Software ist bei beiden gleich.

Einziger Unterschied ist die Verfügbarkeit von spezieller Software. Hier patzen die Hersteller und versäumen es portable Software zu schreiben. Nicht zuletzt weil sie sich von Microsofts proprietären Lösungen haben einlullen lassen. Das ist bedauerlich, aber wenig zu ändern. So bleibt unter Linux oft nur der Weg des Reverseengineering. Und damit ist man natürlich in der Regel immer einen Schritt hinterher. Wobei es auch Spaß macht diese Probleme anzugehen und tiefere Einblicke in die Materie zu erlangen. Zudem ist man bald nicht mehr allein. Man bekommt Hilfe. Für ein Hobby eine respektable Bilanz. Außerdem steigt die fachliche Kompetenz. Ein schöner, positiver Nebeneffekt für die eigene berufliche Existenz. Es gibt also auch gute Gründe sich mal durchzubeißen und nicht gleich nach der ersten fehlgeschlagenen Installation zu heulen. Ist halt alles eine Frage der inneren Einstellung. Wenn Dir das nicht liegt, dann lass es bleiben. Mit Windows lebt es sich genauso gut. Aber tue mir einen Gefallen: Stänkere nicht einfach in die andere Richtung. Amen

Oliver

Zitat von brainwave

Mit einem fehlerfreien Image ist das in einer halben Stunde erledigt, geht viel schneller als endlos rumzudoktorn.
Aber wer zuviel Zeit hat...

Ja, das fehlerfrei Image habe ich während dem ganzen Elend auch einmal aufgespielt. Nur hilft das auch nicht, wenn die neue Software nicht mit dem Rest will. Oder das WLan aus unerklärlichen Gründen jedes 10te mal nicht aus den Puschen kommt.

Unter Linux habe ich in diesem Fall ein detailliertes Log und beim manuellen Starten des Dienstes eine Ausgabe auf der Konsole. Gut möglich, dass es das auch unter Windows gibt. Nur als Noob habe ich keine Ahnung wo ich gucken soll. Anfängern unter Linux und OSX geht es ähnlich.

Und wenn man sich mal die Threads über die Probleme bei der Installation von Mapsource ansieht, dann weiß man, dass dort auch nur mit Wasser gekocht wird.

Allerdings fällt mir der Klaus jetzt schon zum zweiten Mal mit undifferenziertem FUD über Linux auf. Scheint ihm halt ein Anliegen zu sein. Kann man nix machen.

Grüße

Oliver

Zitat von extemecarver

Und wie man unter MacOsx Qlandkarte kompiliert, dass ist wohl ein noch groeßeres Raetsel wie unter windows.

Nö, das geht bis auf den letzten Schritt wie unter Linux. Ist ja schließlich fast das Selbe. Die aktuelle SVN Version funktioniert übrigens auf Intel und Motorola Macs. Eine Anleitung steht in INSTALL.

Unter Windows ist es auch halb so wild. MSVC Express gibt es für lau. QT als Installationspacket auch. FWTools sowieso. Einzige Falle: FWTools kloppt sich mit Windows um die Definitionshoheit von PVALUE. Über Google erfährt man allerdings sehr schnell wie das zu fixen ist. Und CMake bäckt eine schöne *sln Datei. Alles Klicki-Klacki-Bunti

Zu Ubuntu: In der Tat bekomme ich des öfteren Probleme mit Ubuntu gemeldet. Eigentlich ausschließlich Ubuntu. Die Probleme sind in der Regel ärgerlich und oft auf eine vermurkste Packetquelle zurückzuführen. Gerade im Bereich GIS scheint Ubuntu seine 7 Tassen nicht im Griff zu haben.

In einem sauberen Linux System, mit den üblichen Entwicklungstools vorinstalliert, kann man GDAL und Proj4 mit

./configure && make && sudo make install

installieren. Und QLandkarte GT mit:

cmake ../QLandkarteGT && make && sudo make install

Bei SuSE ist QLandkarte GT übrigens als 1-click Installation verfügbar.

Es kommt bei Linux halt immer ein wenig auf die Distribution an. Da gibt es gewaltige Unterschiede. Ich persönlich halte aufgrund meiner Supporterfahrungen Ubuntu für nicht gelungen. Es gibt aber auch viele die behaupten Ubuntu selber ist ok. Nur die Benutzer, die es anspricht, stellen sich gerne ein wenig an. Was jetzt der genau Grund ist, weiß ich nicht.

Und weil wir gerade so schön dabei sind: Die binäre Installation unter Windows. DAS ist wirklich eine Baustelle. Mir wurde von einem Benutzer das NSI Skript, um das Paket zu schnüren, gestiftet. Es enthält offensichtlich Fehler. Der Installer trägt nicht immer das Richtige in die Registry ein. Warum auch immer. Ich kenne mich mit Windows nicht aus. Ich freue mich über jeden der mir ein besseres Skript schreibt. Ich würde mir wünschen es wäre so einfach wie unter Linux.

Grüße

Oliver

Und was heißt hier: Windows ist einfach. Über die Feiertage durfte ich mal wieder den PC meines Vaters gerade biegen. Ungefähr die Hälfte des Wahnsinns habe ich geschafft. Für den Rest habe ich immer noch keine Lösung. Über vernünftige Fehlermeldungen und Logs hätte ich mich gefreut. Gerne auch auf der Konsole

Und meine zweite Freude hatte ich beim Installieren von Myst (Adventure) auf einer virtuellen Maschine. Es war unmöglich.

Also erzähle mir nix von Windows ist einfach. Das ist der selbe Schiet wie alles andere auch.

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