Beiträge von kiozen

Zitat von Eumel153

Was meinst Du mit versagen ? Kartengenauigkeit oder GPS Genauigkeit ?
Die modernen GPS Empfänger versagen doch nur noch in absoluten Extremsituationen.

Beides plus Robustheit.

Kartengenauigkeit: Keine der mir bekannten Vektorkarten sind im Gelände brauchbar. Hier haben Rasterkarten auf der Basis von gut gezeichneten Topokarten immer noch die Nase vorne.

Empfindlichkeit: Viele Handy GPS sind mit dem GSM Empfänger gekoppelt und haben ohne GSM Empfang eine grottige Genauigkeit. Hinzu kommt oft eine suboptimal verbaute Antenne.

Robustheit: Ein Handy ist trendy. Aber nicht in Regen und Schnee. Und es funktioniert auch nicht 10 Stunden mit Display und allem.

Und zu Letzt die Daten. Bei den ganzen Karten für lau sollst du online sein um online Werbung zu bekommen. Offline gibt es nix für lau. Zudem sind die Karten von Navtec, Telealtlas und auch Google Straßenkarten. Die hören da auf, wo Fußgänger endlich alleine sind.

Zitat von Eumel153

Auch die Karten finde ich gar nicht so schlecht. Z.B. die Topo D v2/v3. Ich würde mir zwar manchmal eine bessere Unterscheidung der Wege wünschen (Forststrasse, Wanderweg- , -pfad, großer Weg, kleiner Weg) und manchmal gibt es auch Probleme mit der Genauigkeit (Weg wird angezeigt, ist aber tatsächlich gar nicht vorhanden und umgekehrt) aber insgesamt finde ich die Karten schon in Ordnung.
Wer noch mehr braucht, der kann sich dann bei Spezialkarten bedienen.

Die Topos von Garmin sind auf der Datenbasis der LVAs. Und diese sehen überhaupt nicht ein, etwas für lau zu lizenzieren. Abgesehen davon sind die Top XX der LVAs das Genaueste was Du von DE bekommen kannst.

Zitat von Eumel153

Die meisten Wanderer und Outdoor Sportler brauchen doch gar kein Gerät für 300-500 €. Wenn Garmin ein Gerät mit

Die meisten benötigen überhaupt kein GPS zur Orientierung. Der Weg zur nächsten Kneipe ist gut ausgeschildert. Und für den Rest trottet man der Horde hinterher. Eine GPS Maus um die glorreichen paar Kilometer aufzuzeichnen reicht. Und genau dieses Klientel hat das Handy in der Tasche. Das ist in Zukunft kein Markt mehr für Garmin.

Zitat von Eumel153

2,5"-3" Farbdisplay auf den Markt bringen würde, mit einfacher Firmware aber der Möglichkeit Tracks in MS zu planen und einer vernünftigen Vermarktung (z.B. Elektronikkette), dann würde es Garmin sicher auf ansehnliche Stückzahlen bringen.

Genau das macht Garmin mit der eTrex und Edge Reihe doch erfolgreich.

Zitat von Eumel153

Leider gibt es zu Garmin wirklich wenig Alternativen.

Ja, leider. Aber das liegt nicht an Garmin, sondern an der Konkurrenz, die eine Lachnummer nach der anderen abzieht. Allen voran Magellan. Der Laden hat sich nach allen Regeln der Kunst vom Marktführer zum Nichts bugsiert. Es ist unglaublich.

Grüße

Oliver

Zitat von extemecarver

Ich glaube nicht, dass in 2 Jahren noch mehr als ein paar Prozent der User bereit sind, fuer Karten zu zahlen.

Im Bereich der Städtenavigation und des Feld/Wald und Wiesenwanderns mit gut ausgeschilderten Wegen bei Schönwetter hast Du sicherlich recht. Nur versagen alle diese Dienste genau dann, wenn ich wirklich ein GPS benötige.

Ich könnte mir deshalb vorstellen, dass die Karten eher teurer werden. Kleiner Markt und Nische mit wenig Alternativen. Das war noch nie gut für den Preis.

Oliver

Zitat von morgen1

Hier mal ein gedankliches Horrorscenario:
Alle von Garmin verkauften Karten sind bekanntlich mit Code geschützt. (Ausnahme vielleicht Trip&waypointmanager, das ist zu vernachlässigen) Deshalb könnte Garmin ein zukünftiges MS -Release so bauen, daß nur noch geschützte Karten angezeigt werden, Folge --> alle OSM Karten laufen nicht mehr und zähneknirschend werden wohl einige Leute mehr mangels Alternative die Garminkarten kaufen müssen.

Was Garmin in MS macht interessiert nicht. Auf die Geräte kommt es an. Dort müssten Karten im alten Format ausgesperrt werden. Garmin müsste damit einen guten Teil seiner eigene Karten beim Benutzer entwerten.

Zitat von morgen1

Wechseln zu TomTom &Consorten bringt auch nichts, weil die ebenfalls Geld wollen. Ziel erreicht :Konkurrenz ausgebootet ,Gewinn gesteigert. Unter marktwirtschaftlichen Gesichtspunkten würde das Sinn machen und wird kommen. Die programmiertechnische Vorarbeit ist schon geleistet.

Ein Wechsel lohnt nicht, weil es keine Outdoorgeräte mit einem ebenso bekannten Format gibt. Das könnten Garmins Mitbewerber aber ändern. Nur stellen die sich noch dämlicher an.

Zitat von morgen1

Vermutlich müßte nur noch die Variable <FID> von derzeit 2046 (? oder so ähnlich) runtergesetzt werden auf Null. Man könnte einwenden, daß die alten Versionen benutzt werden können. Das ist richtig, aber der Trieb der Massen geht zu modernen Versionen. Damit werden die alten Karten dann schnell überholt sein. Kann nur hoffen , dass ich zu schwarz sehe.

Das wird in 3-5 Jahren so sein. Spätestens dann sind die alten eTrex und GPSMap Serien am Ende. Ob es bis dahin eine "offene" Outdoor GPS Platform gibt sei dahingestellt.

Zitat von morgen1

Lowrance hat es mit MMO doch vorgemacht, da war erst kurzzeitig Version 1.0 zu haben , die alles konnte und dann nur noch eingeschränkte Nachfolgeversionen.
morgen1

Hier würde mich mal wirklich interessieren, was bei den Geräteherstellern hinten herum passiert. Ich glaube ja, dass hinter dem ganzen DRM die Kartendatenbesitzer (also Navtec, Teleatlas, und die Kartenverlage) stecken. Für einen Gerätehersteller ist DRM nur ärgerlich. Aber was soll er machen. Er braucht Karten und tanzt deshalb nach der Pfeife der Datenanbieter. Bei Garmin im Speziellen dürfte zudem noch ein satter Gewinn durch die Karten die Entscheidung versüßen.

Ich träume ja immer noch von einem GPL Outdoor GPS. Warum tuen sich die Hardwarespezialisten immer nur so schwer, mal was aus Spass und Interesse für die Allgemeinheit zu tun? In der Softwareentwicklung geht es doch auch.

Oliver

Ich verstehe die ganze Hysterie um den UnLock Key nicht. Die bösen Buben erstellen sich doch keinen Key, sondern restaurieren den verschlüsselten Abschnitt in der Karte selber. Da Garmin hier ein "rosa Spielzeugschloss" verwendet, war das auch nicht schwer. Und auch ohne Experte für Polynomfaltung zu sein, kann man die Stelle alleine aus den Seiteninformationen, die als Klartext im Kartenformat stehen, wieder restaurieren.

Und das ist doch das eigentliche Problem von Garmin. Mich würde nicht wundern, wenn mit dem neuen Mechanismus auch eine stärkere Verschlüsselung einhergeht. Damit, und nur damit, hätte Garmin wieder für eine gewisse Zeit Ruhe vor dem Thema.

Und was OSM angeht: Solange Garmin das alte Format in seinen Geräten unterstützt ist doch alles in Butter, oder? Und danach wird der Markt halt neu gemischt. Wen das stört, soll sich halt hinsetzten und für einen anderen Hersteller das Format entschlüsseln. Die bestehenden Tools umzubauen ist weniger das Problem.

Oliver

Zitat von Wanderreiter

Gibt's doch schon!
Du brauchst nur ein Laptop.

Eli

Helau!

Und wann gibt es endlich ein portables MapSource? Oder sollte ich lieber nicht fragen? :D:D:D

Oliver

Ach noch was ganz anderes: Es gibt OSX Binaries.

http://sourceforge.net/projects/qlandkartegt/files/

Bitte vorher das hier lesen.

Grüße

Oliver

Ich habe die Installation auf ein Netzwerklaufwerk ausgeführt. FWTools und QLandkarte. Es läuft durch. Kann es folglich auch nicht sein.

An der Stelle wo es bei Dir hakt werden eine handvoll Einträge in der Registry gemacht. Sicher, dass hier nichts blockiert?

Ansonsten bin ich mit meinem Latein für Windows auch am Ende. Wie schon öfters erwähnt stammt das Installerskript nicht von mir. Der original Autor ist auch Linuxbenutzer. Ich fürchte solange sich niemand aus der Windowswelt dem Kind annimmt, wird es eine etwas schräge Installation bleiben.

Grüße

Oliver

Zitat von AndreasL

QLandkarteGT.0.17.0_1.exe ist bei mir nicht installierbar (XP). Der Installer bleibt ohne Möglichkeit zum schließen beim Erzeugen des 2. Desktop Shortcuts einfach stehen. Irgendwas ist zwar installiert worden, aber nicht lauffähig. Anwendung kann wegen fehlender .dlls nicht gestartet werden.

Zumindest der Uninstaller scheint zu funktionieren.

Hallo Andreas,

das ist natürlich ärgerlich. Ich habe die Installation gerade in einer virtuellen Maschine (XP) getestet. Der Installer funktioniert also mal grundsätzlich.

Deine Fehlerbeschreibung macht mir ein paar Probleme. Zum einen verstehe ich nicht was du unter "Der Installer bleibt ohne Möglichkeit zum schließen beim Erzeugen des 2. Desktop Shortcuts (????) einfach stehen." verstehst. Zum anderen ist es hilfreich zu wissen welche Dlls nicht gefunden werden. Meines Wissens steht das immer in der Messagebox mit dabei.

Zusätzlich wäre es gut zu wissen, ob die Installation von FWTools fehlgeschlagen ist, oder nur die von QLandkarte GT. Falls es nicht aufgefallen ist: Hier werden 2 getrennte Softwarepakete installiert.

Eine geglückte Installation von QLandkarte GT sollte wie im Anhang aussehen.

Grüße

Oliver

Zitat von JürgenD

  kiozen: Das erste Byte der TYP-Datei ist das Längenbyte eines Subfile-Header. 'Normal' ist 0x5b. Was zusätzlich bei Längen von 0x6e und 0x9c in der Datei versteckt ist habe ich bisher nicht analysiert. Sobald die erweiterten Typen auftauchen muss mit einem 32-Bit-Feld die Reihenfolge definiert werden. Mir ist es dabei egal ob das wirklich nötig ist. MapTk benutzt immer das Bitfeld. Auch für die 'alten' Typen, da ist das Bitfeld 0x00000000 (andere Werte blenden das Polygon aus ). Daran scheint Garmin zu erkennen, dass es sich um den traditionellen Stil handelt. Eine Kennzeichnung im Kopf braucht es dazu nicht.
JürgenD

Ok, das heißt für Dich gibt es nur die Grundtypen mit Bitfeld 0x00000000 und erweiterte Typen bitcodiert. Erweiterte Typen als Type|Subtype codiert kommen nicht vor. Das werde ich jetzt erstmal sacken lassen und mir bei allen möglichen Typdateien ansehen. Jedenfalls danke für den Tip.

Solltest Du eventuell doch mal vor haben deinen Code zu teilen, wäre ich sehr daran Interessiert. Da ich mit QLandkarte zwischen allen Stühlen sitze und jeder meint, seines sollte doch immer richtig angezeigt werden, würde mir einfach konkreter Sourcecode viel helfen. Da wir alle Garmin hinterher rennen, wäre es schön, wenn wir uns nicht noch gegenseitig behindern. Anderseits kann ich deine Entscheidung akzeptieren und mir das Dekompilieren des Bytecodes verkneifen. Ich denke es sollte, wenn schon, kooperativ funktionieren.

Grüße

Oliver

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