Beiträge von kiozen

Zitat von Cletus

Hallo Helmut,
hier nur auf die Schnelle (hier brennt es ...):

Aber hoffentlich nicht wegen QLGT!?

Zitat von Cletus

habe WinXP,
die QLandkarte-Version ist 1.0.1 (müsste die neueste sein)
hatte ALLES gewählt zum installieren

Bitte auf jedenfall V1.1.0. benutzen. Helmut scheint die abendliche Debugsession bezüglich der Custom Maps unter Windows schon vergessen zu haben.

Mein oben genanntes gdalwarp Kommando möchte ich revidieren. Das führt zu keinem schönen Ergebnis.

gdalwarp -t_srs "+proj=merc +datum=WGS84"  <infile> <outfile>

Die vorher verwendete longlat Projektion hätte zu einer gestauchten Karte geführt. Bei Merkator sollte es mehr oder weniger mit einer leichten Drehung getan sein. GDAL verwendet hierbei die "nearest neighbour" Methode zum Interpolieren. Das kann zu etwas griseligen Ergebnissen führen.

Besser wäre natürlich eine bilineare oder kubische Interpolation. Die geht aber nur bei 32bit RGB Dateien. Und das Ergebnis bleibt bei 32bit, da ja jetzt deutlich mehr als 256 Farben der Farbtabelle auftauchen. Eine Datei mit 8bit Fabtabelle wandelt man in eine 32Bit RGB Datei wie folgt um:

gdal_translate -expand RGB <infile> <outfile>

Und ändert dann die Projektion:

gdalwarp -t_srs "+proj=merc +datum=WGS84"  -r cubic <infile> <outfile>

Versteht sich von selbst, dass damit die Datei deutlich größer wird und bleibt, da ein Weg zurück zur Farbtabelle, die Qualität zunichte macht. Die Datei sollte aber noch ein wenig optimiert werden, um Arbeitsspeicher zu schonen. Dazu wird sie intern in Kacheln zerlegt.

gdal_translate -co tiled=yes <infile> <outfile>

Um für ein flüssiges Zoom zu sorgen, sollten noch ein paar Überblicksebenen hinzugefügt werden:

gdaladdo -r cubic --config COMPRESS_OVERVIEW JPEG <infile> 2 4 8 16

Fertig. An für sich reicht der anfängliche Aufruf von gdalwarp. Sollte man jedoch Wert auf die Bildqualität legen, empfiehlt sich der Weg über die 32bit RGB Datei. Die letzten beiden Kommandos sind vor allem bei großen Dateien wichtig, weil ohne diese Optimierungen kein Programm die Karte schnell darstellen kann. Zusammengefasst, ohne verwirrende Erklärung:

gdalwarp -t_srs "+proj=merc +datum=WGS84"  infile.tif temp1.tif
gdal_translate -co tiled=yes temp1.tif outfile.tif
gdaladdo -r cubic --config COMPRESS_OVERVIEW JPEG outfile.tif 2 4 8 16

Zitat von Cletus

Und QLandkarte habe ich auch installiert, es steigt aber aus mit der Meldung: gdal_fw.dll nicht gefunden. Nochmalige Installation brachte nix.

Das ist aber ärgerlich. Ich werde dem Windows Maintainer gleich Bescheid geben, damit er sich darum kümmert.

Zu der Dateigröße: Abhängig von der Beschaffenheit der Datenquelle ist das eine oder das andere Kompressionsformat besser. Während JPEG auf Fotos spezialisiert ist, also auf Bilder bei denen kein Pixel den selben Farbwert hat, benutzt TIF in der Regel einen Lauflängenalgorithmus. Der ist ideal für Karten die Linien und Flächen mit einem Farbwert haben. Wobei mit 300k vs 10M schon arg komisch vorkommt.

Grüße

Oliver

Zitat von Cletus

danke für die Antwort. Garmin Custom Maps scheint mir eben nicht für meine Zwecke tauglich, denn meine Karten sind ja schon exakt eingepaßt ("georeferenziert" oder in der GPS-Welt "kalibriert"). Warum sich also nochmal in GE mit Paßpunkten rumplagen? Genauer wirds davon bestimmt nicht. Daher kann mir wohl in diesem Fall auch der OZI nicht weiterhelfen.

Ein richtig referenziert Karte in einem offenen, bekannten Format (tif + Worldfile is ok) sollte sich problemlos in QLandkarte GT einbinden lassen. Vom Hautmenü mit F1->F6 den Dialog dazu öffnen. Du brauchst den ersten Punkt in der Combobox. Von da sollte es selbsterklärend sein bzw die ? Buttons helfen.

Auf einer so eingebundenen Karte kann man einen Bereich auswählen. Dabei werden schon die 1024x1024 Kacheln angezeigt. Die Auswahl kann als Garmin Custom Map exportiert werden.

Wie Anton schon bemerkt hat, solltest Du aber vorher deiner Datei eine merkatorähnlich Projektion verpassen. Transversal Merkator kann Garmin nicht. Das geht mit gdalwarp:

gdalwarp -t_srs "+proj=longlat +datum=WGS84" <infile> <outfile>

Zitat von Cletus

Ich muß zugeben: die Fülle an verfügbarer Software ist für ein Greenhorn wie mich erschlagend: GPSMapEdit, GlobalMapper, Ozi, QLandkarte, Mapsource, Basecamp, MOBAC ... wer blickt denn da noch durch was man braucht? Hat sich zufällig jemand mal die Mühe gemacht, das ein wenig zu entwirren? Nach dem Motto: was ist gut und für welchen Zweck geeignet? Wo hat welches Programm seinen Schwerpunkt und wo seine Schwächen? Puh ...

Gruß, Cl.

http://www.naviboard.de/vb/showthread.php?t=30510

Ein Bewertung in Schwerpunkte und Schwächen endet in einer wüsten Diskussion. Wie üblich im Leben, musst Du selber wissen, was gut für dich ist. Eine steile Lernkurve gehört bei einem so komplexen Thema wie GPS dazu.

Grüße

Oliver

Zitat von wanderer200

Hallo kiozen,

danke für die Hinweise. Ich werde mir die Sache mal anschauen. Es ist doch gut, wenn man auf die Erfahrung anderer Benutzer zurückgreifen kann. Da fehlt mir doch noch einiges.

Viele Grüße Wanderer200

Ja das Thema ist komplex und die angebotenen Lösungen stagnieren seit Jahren auf Mittelmaß. Outdoorgeräte sind nur eine kleine Nische im gesamten GPS Markt und die Marktdominanz von Garmin lässt wenig Konkurrenz zu. Deshalb bewegt sich alles nur sehr langsam und der Verbraucher muss die Widrigkeiten mit allerhand Eigeninitiative umschiffen. Dazu gehört eine steile Lernkurve und die Akzeptanz, dass einige Dinge so dämlich sind, wie sie sind.

Zitat von wanderer200

es liegt wirklich nicht an den Einstellung. Habe mittlerweile eine routingfähige OSM Karte. Die Ergebnisse sind aber trotzdem ernüchternd. Kurze Routen funktionieren. Allerdings sind Zieleingaben wie Adresseingaben, Städte usw. sehr umständlich und dauern sehr lange wenn man entsprechende Eingrenzungen vornimmt.

Vorsicht! Das ist ein bekanntes Problem bei OSM und wurde erst vor ein paar Tagen verbessert. Die neue Version von mkgmap, das Tool im OSM Daten in das Garminformat zu bringen, wurde dahingehend optimiert. Bis sich das in allen angebotenen Karten durchgesetzt hat, dauert.

Zitat von wanderer200

Allerdings ist das Autorouting wirklich nur eine untergeordnete Funktion. ( Bei Fahrradtouren wäre es ganz schön) Ich werde weiter experimentieren, weil es ja auch keine gute Beschreibung dafür gibt.

Mal ein ganz andere Ansatz:

Garmin bietet für's Fahrradrouting nur wenig. Deshalb bedient sich die OpenMTB Karte eines Tricks. Relevante Radstrecken werden als Autobahn markiert, und Autobahnen als irgendwas, nur keine Straße. Damit kann der für KFZs optimierte Algorithmus im Gerät ein ordentliches Ergebnis für Radfahrer erzielen.

Es geht aber auch anders. Auf www.openrouteservice.org (ORS) wird direkt auf den OSM Daten gearbeitet. Für Radfahrer gibt es mehrere Möglichkeiten. Eine Tour kann als GPX gespeichert werden.

Ein andere, komfortabler Weg, auf ORS zu zugreifen, ist QLandkarte GT (www.qlandkarte.org). Dort wird die Route auch über ORS berechnet. Kann aber dann mit Höhendaten angereichert in einen Track oder eine änderbare Linie umgewandelt werden. Das hat den Vorteil, dass man das Ergebnis individuell anpassen kann. Der fertige Track wird zum Schluss auf das Gerät übertragen. Die Route zu übertragen mach wenig Sinn, da das Gerät die Route neu berechnen wird und unter Umständen zu einer sehr seltsamen Lösung kommt.

Sicherlich alles keine Lösung auf dem Gerät, aber die Routendefinition war bei den Garmin Outdoorgeräte immer schon nur ein Notnagel und kein Konzept.

Zitat von wanderer200

Nachgedacht habe ich schon, aber wer kennt als Neueinsteiger schon die genauen Funktionen und eine etwas umständliche Bedienung. Die Geräte kann man in der Regel beim Kauf auch nicht testen.

Vielleicht kannst Du es ja noch zurückgeben. Und wenn Du uns verrätst, zu was Du das Gerät brauchst, dann kann man sagen was besser ist.

Zitat von Sardinien

Dass ca. 90 % der PC Anwender über Windows verfügen und dafür viele Programme, wie beispielsweise Globalmapper, perfekt drauf gehen, sollte nicht unbeachtet bleiben. Linux bringt sehr viele Treiber mit, doch ob es immer die richtigen sind für den Normalanwender? Dass speziell im Grafikbereich eine native Unterstützung von Programmen wichtig ist, um die volle Leistungsfähigkeit auszuschöpfen, leuchtet selbst mir als Person ohne Programmierkenntnisse, ein.

Zu deiner Information: QT macht regen Gebrauch der OpenGL Schnittstelle. Auch im 2D Bereich. D.h. betriebssystemunabhängig wird die Hardwarebeschleunigung deiner Grafikkarte ausgenutzt. Das gilt übrigens heutzutage für jedes moderne graphische Toolkit. Hat die Grafikkarte eine saubere OpenGL Implementierung laufen auch grafikintensive Anwendung problemlos. Eine billige Grafikkarte macht unter Windows genauso Ärger wie unter Linux.

Aber sag mal, kommt es mir nur so vor, oder schmeißt Du gerne mal mit FUD um dich? Das ist mir jetzt schon öfters bei deinen Beiträgen übel aufgestoßen. Tut das Not?

Zitat von gerhardg

auch ecw ist bis 500mb kein problem, von solchen mengen können garmin user auch nur träumen

Ich glaube Du hast über Weihnachten den BirdsEye Hack verschlafen

Zitat von Sardinien

-können ecw dargestellt werden

Wenn GDAL mit ECW Support kompiliert wurde, ja.

Zitat von Sardinien

-können aus Teleatlas oder Navteq Daten generierte Europa oder World Straßenkarten zur Routenplanung über Rastermaps verwendet werden und damit vollautomatische Tracks und Routen erstellt werden

QLGT benutzt OpenRouteService zur Routenberechnung und greift damit auf den Datensatz von OSM zu. Das hat Vor- und Nachteile gegenüber Teleatlas und Navteq. Der Ansatz erlaubt auch auf jeden andern OpenLS basierenden Routingservice zuzugreifen. Routen lassen sich in Tracks umwandlen, oder in Distanzlinien um manuell nachbearbeitet zu werden.

Zitat von Sardinien

-welche kaufbaren Rasterkarten können angezeigt werden

Alle von GDAL unterstützen Format werden auch von QLGT verwendet. Wenn deine Karte im proprietären Format nicht dabei ist, musst Du sie in ein offenes Format umwandeln. Wie das geht pfeifen bei Google die Spatzen von den Dächern.

Zitat von Sardinien

- können RMAPS oder ECW generiert werden
- welche Garmin/TwoNav geeignete Vektorkarten können ohne Umwege geschrieben werden

Du bist ja voll im Bilde, was den Inhalt des Threads angeht. Komm was soll der Scheiß? Wir diskutieren hier gerade im Speziellen, dass Compe offene Ansätze zum Unterstützen des RMAP Formates dicht macht. Und im Allgemeinen, dass die Kartenverlage durch proprietäre Formate und Lizenzpolitik den Benutzer mehrfach schröpfen. Dabei scheinen frei Implementierung nur zu stören und werden mit Anwaltsschreiben dicht gemacht. Glaub mir die Barrieren liegen hier auf der juristischen Seite, nicht auf der technischen. Mich ärgert nur, dass der Benutzer davon nur Nachteile hat und keinen Vorteil.

Zitat von Sardinien

Deine kostenlose Bereitstellung von Qlandkarte finde ich Klasse. Doch bitte bedenke, dass manche Personen/Firma von Ihrer Arbeit auch ihren Lebensunterhalt bzw. Ihre Existenz bestreiten müssen.

Ich habe nichts gegen TTQV. Ich sage nur dass QLandkarte eine ernstzunehmende Alternative ist, die auf Linux, OSX und Windows läuft. Bevor sich also irgendjemand unglücklich macht und eine Raubkopie von TTQV installiert, weil er den Preis nicht zahlen will, sollte er sich auch mal die Alternative ansehen.

Zitat von Sardinien

Habe schon einige Euros für Maps/Soft investiert, nur so funktioniert ein für uns alle interessantes Gesamtsystem.;)

So sehe ich das auch. Ich kaufe gerne meine Karten. Ich hätte früher sogar für eine gute Softwarelösung unter Linux gezahlt. Jetzt ist QLandkarte so weit, dass es keinen Sinn mehr macht. Und wenn Compe sich später doch mal überlegt mit Offenheit freie Entwicklung zu gewinnen, dann kaufe ich mir gerne ein Gerät und auch die eine oder andere Karte dazu. Das würde auf dem monatlich ca 40 köpfigen Geocachestammtisch, der neben ein paar iPhones zu 100% in Garmins Hand liegt, wie eine Bombe einschlagen. So verkauft man Geräte

Zitat von wanderer200

Ich habe jetzt jedenfalls begriffen, dass man mit dem Gerät eigentlich nur einer selbst erstellten oder heruntergeladener Route aus dem Internet nachlaufen kann. Etwas wenig Gegenleistung für soviel Geld.

Nun ja, das kommt darauf an was man damit macht. Ich hätte keinen Lust mit meinem Autonavi bei strömenden Regen durch die Berge zu latschen. Auch weiß ich die lange Akkulaufzeit zu schätzen. Zudem kann ich Raster und Vektorkarten mit dem Gerät benutzen. Das ist im Gebirge von unschätzbaren Wert. Autorouting in den Bergen habe ich allerdings noch nie gebraucht. Dafür aber eine saubere Trackaufzeichnung mit einem ordentlichen Höhenwert. Für diesen Gebrauch wüsste ich jetzt auf die Schnelle kein Gerät das preiswerter ist.

Kann es sein, dass wir beim Kaufen nicht nachgedacht haben? :D:D

Zitat von Sardinien

Oliver,
wie viele orig. Garmin-Maps und Kompasskarten+ECW Maps (Grenzgebiete) kann deine Software Hybrid in einem bzw. mehreren Kartenfenstern gleichzeitig darstellen und automatische Routen/Tracks dabei erstellen mit allen Punkten und Höhenangaben? Bei den Länderübergängen sollten die Raster-Maps transparent geschaltet werden können. 3 D ist natürlich selbstverständlich für alle Maps.

Das ist mit dem selben Frikelaufwand möglich wie Du das unter TTQV zu Wege bringst. Einziger Nachteil: Ich muss mich an offene Formate halten. GeoTiff ist allerdings durchaus in der Lage Transparenz zu definieren. QLGT kann verschiedene Dateien auf einer Ebene anzeigen. Karten verschiedener Auflösung lassen sich auch in QLGT übereinander legen. Vektorkarten lassen sich unabhängig davon in beliebiger Anzahl überlagern. Bis dir vor lauter Linien schwindlig wird. Das Höhenmodell und die Karten sind mehr oder weniger unabhängig in QLGT. Genauso wie die Routenplanung und künstliche Tracks. Und, ja, 3D kann es auch mit jeder Karte. Wer's braucht . Glaubst Du denn im Ernst nur bei TTQV haben die Leute die Weisheit mit Löffeln gefressen?

Zitat von Sardinien

Nach Beendigung der Planung werden die Maps auf die Geräte gesandt in Tiles, die entlang der Strecke benötigt werden. Könnte für eine Tour von München nach Santiago de Compostella wichtig sein. Geht dies ebenfalls?

Ich kann mit QLGT Ausschnitte aus Raster- sowie Vektorkarten exportieren. Entlang der Route geht nicht automatisch. Aber sollte ich das mal wirklich brauchen, baue ich es ein. Und wann hast Du das letzte Mal bei TTQV um ein Feature gebettelt?

Zitat von Sardinien

Linux ist bei den Entwicklern sehr beliebt, bei uns normalen hat es einen Marktanteil von 1 % (PC-Bereich) mit fallender Tendenz. Mir ist schon bekannt, dass Linux (Dream-Box) gepaart mit der richtigen Soft einiges kann und für Bastler enorme Möglichkeiten offenbart.

Mal wieder so eine fundierte Marktanalyse. Warum werden dann die Anfrage bezüglich Ubuntu und QLandkarte in meiner Mailbox täglich mehr?

Wir kochen hier alle nur mit Wasser. TTQV ist sicherlich sein Geld wert, wobei ein guter Teil in eine absolut verquere Lizenzpolitik fließen dürfte. DRM und Formatlizenzpoker schaffen keine Werte. Gerade bei den Rasterformaten ist die Innovation flach. Das ganze Zeug ist nur gut um, Pfründe zu sichern, anstatt Mehrwert zu schaffen. Für den Kunden heißt es ein und das selbe Produkt wieder und wieder zu kaufen. Oder hinten herum über Lizenzen doppelt und dreifach zu bezahlen. Ich habe kein Problem für Leistung zu zahlen. Aber ich habe keinen Bock auf digitale Barrieren. Vor allem nicht wenn ich dadurch immer wieder geschröpft werde. Das mag der BWL Heini in den Verlagen witzig finden. Als Kunde bin ich dazu nicht bereit.

Zitat von gerhardg

von soviel "freiheit" können garmin user nur träumen.

Das wäre für mich eher eine Alptraum wenn ich mkgmap mit einer beschnittenen Version von cgpsl und QLandkarte mit TTQV tauschen müsste. Zumal mir diese Software Windows aufdrängt. Bleibt einzig ECW als portable Lösung. Von der Lizenz her ist ECW aber auch problematisch.

Versteht mich nicht falsch. Ich will keinen Compe/Garmin sonst was Krieg provozieren. Auch liegt es mit fern eine Lanze für Mobac zu brechen. Ich würde mich freuen wenn andere Hersteller Garmins Dominanz zurückdrängen. Compe hat dazu durchaus das Potenzial. Allerdings müssen sie dann auch den Pool an Benutzern anzapfen, der Garmin so viel Erfolg verschafft. Und das ist durchaus die OSM und Opensource Gemeinde. Benutzer die Linux haben kaufen Garmin weil es OSM Karten und QLandkarte gibt. Ich treffe sogar immer mehr Windowsbenutzer, für die das auch ausschlaggebend ist. Andere Hersteller würden mit mehr Offenheit diesen Pool anzapfen können. Und das sind in der Regel Benutzer, die von anderen gefragt werden, welches Gerät sie empfehlen.

Hallo Martin,

und an CompeLand verdient Compe natürlich nichts Mal abgesehen von dem unschätzbaren Vorteil, den Benutzer unter Kontrolle zu haben. Apple macht es vor. Mit einem System dass dem Benutzer keine Alternativen lässt, kann man an jedem Pubs mit verdienen.

Mir ist ein solches Verhalten suspekt. Und ich habe auf Linux bestehende, funktionierende Lösungen für Garmin. Es wäre durchaus interessant das alles auch Compe Benutzern zur Verfügung zu stellen. Zumal Compe unfähig ist portable Software zu schreiben. Aber wenn es schon so losgeht, sinkt die Bereitschaft rapide auf Null.

Zitat von dancingman

Mmh, verstehe nicht, weshalb Compe da ein Problem mit hat. Weil das Format "gehackt" wurde?

Weil sich so der Kunde besser abzocken lässt. Der muss nämlich entweder die teuren Karten vom Hersteller kaufen. Oder er zahlt indirekt über die Lizenzgebühren bei offiziell zugelassener Software. OpenSource und sogar noch umsonst geht da gar nicht.

Aber das ist dumm und kurzsichtig von Compe. Ein guter Grund für Garmin ist das Vorhandensein von freien Karten und einer handvoll alternativer Software, die auch auf was anderem als Windows läuft. Wer denkt er könnte das ignorieren und zudem den Kunden mit DRM mehr als nötig gängeln, der arbeitet am Markt vorbei. Und ob man in einer winzigen Nische, für eine kleine Avantgarde von Benutzern, auf Dauer ausreichend Geld verdient, um das Produkt schnell genug zu einer Reife und breiten Marktakzeptanz zu entwickeln, ist fraglich. Magellan hat nicht zuletzt deshalb eine Bauchlandung hingelegt.

@macnetz: Das ist Käse. Wer offizielle Karten von Compe klauen will macht das. Mit oder ohne OpenSource. Bei Mobac können sich die Anbieter von Web Karten beschweren. Das würde ich verstehen. Compe sollte lieber froh sein, dass es Aufmerksamkeit bekommt.

Eine Route auf dem Gerät zu planen, ist wirklich nur ein Notnagel, den ich versuche zu vermeiden. Straßennavis sind hier deutlich besser. Für ein Outdoor GPS ist das aber auch nicht so wichtig. Ich persönlich füttere das Gerät vor einer Tour mit allen wichtigen Wegpunkten vom PC aus. Dann muss ich nur noch den entsprechenden Wegpunkt anwählen.

Zitat von wanderer200

Von der Empfindlichkeit des SAT-Empfängers bin ich etwas enttäuscht. Mein Autonavi bekommt noch Signale wo das Garmin schon Schwierigkeiten hat.

Ich hatte bisher nicht das Gefühl, dass das 62er früher als andere GPS seinen Fix verliert.

Die restlichen Fragen sind ausreichend im Handbuch beschrieben. Ich empfehle auch den Thread mit den Tips und Tricks (http://www.naviboard.de/vb/showthread.php?t=44414) zu lesen.

GDAL (FWTool) sollte das meines Wissens können. Wenn die Dateien referenziert sind, sollte:

gdalwarp file1 file2 <und so weiter> outpufile

reichen.

Zitat von thomas_rolf

Code

EXTENSION['PROJ4','+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext  +no_defs'],
    UNIT['metre',1,

Ok, Merkator. D.h. Angaben in Meter

Zitat von thomas_rolf

Code

Origin = (9680403.680058261400000,6335385.307206181800000)
Pixel Size = (39.000290546521789,-39.000290546521789)

Das hier ist der obere, linke Punkt in Metern. Und darunter der Skalierungsfaktor in [m/pixel]

Zitat von thomas_rolf

Code

Upper Left  ( 9680403.680, 6335385.307) ( 86d57'37.96"E, 49d 9'54.43"N)
Lower Left  ( 9680403.680, 6214913.410) ( 86d57'37.96"E, 48d27'16.18"N)
Upper Right ( 9800017.571, 6335385.307) ( 88d 2'6.20"E, 49d 9'54.43"N)
Lower Right ( 9800017.571, 6214913.410) ( 88d 2'6.20"E, 48d27'16.18"N)
Center      ( 9740210.626, 6275149.358) ( 87d29'52.08"E, 48d48'39.81"N)

Und weil es gar so schön ist alle 4 Ecken.

So, und jetzt willst Du freilich von mir wissen, wie Du Koordinaten in Grad in Koordinaten in Meter umrechnest. Richtig? Das geht mit GDALs Bruder Proj4. Und weil QLandkarte bei Dir läuft ist auch schon alles installiert. Das nötige Kommando heißt "cs2cs"

cs2cs +proj=longlat +datum=WGS84 +to +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext  +no_defs

Nach dem Return erwartet das Programm eine Eingabe wie

86.5 49.3

Und spuckt auch gleich die zugehörigen Koordinaten in Metern aus.

9629135.95      6325919.27 0.00

Mit welcher Skriptsprache arbeitest Du eigentlich? GDAL unterstützt Python und alle diese Befehle sollten auch in Python eingebettet sein. Ich habe es aber noch nie ausprobiert um genaueres zu sagen.

Zitat von thomas_rolf

Hallo zusammen,

bin gerade am Ausprobieren, was man mit gdal_translate beim Zuschneiden der Karten so alles anstellen kann. Weiß jemand, in welchem Format beim gdal_translate-Parameter -projwin die Eckpunkte angegeben werden müssen (ulx, uly, lrx, lry)? Vorliegen habe ich die Lat/Lon-Werte direkt von der Karte (sie stehen ja auch im map-File), aber wie muss ich die angeben? Einfach die Dezimalwerte nehmen klappt nicht, gdal_translate vermutet den gesuchten Ausschnitt weit ausserhalb der Karte.
Gruß,
Thomas

Kommt auf die Projektion an. Bei Mercator oder Transversal Merkator (z.B. UTM) müssen die Werte in [m] sein. Bei eine lon/lat Projektion in Grad, dezimal. Genaueres kann man nur sagen, wenn Du die Ausgabe von gdalinfo verrätst.

Aber würde -srcwin nicht reichen? Das wäre in Pixel. Und der Rand ist doch fast immer gleich, bis auf ein paar Pixel Sicherheit. Und überlappen müssen sich die Karten sowieso damit das was wird.

Zitat von Lacor4711

Hallo Oliver,
gibt's irgendwo eine Beschreibung zu QLandkarteGT?

http://www.qlandkarte.org/

http://sourceforge.net/apps/me…title=Main_Page&Itemid=20

Zitat von thomas_rolf

@Helmut:vielen Dank für die Info zu EPSG. Dass die Nummern mal eben um die halbe Welt umziehen können, findet sich auf der EPSG-Seite natürlich nicht so direkt...

Ärgerlich, dass es so ist. Ich habe früher den Leuten den Projektionsstring ("+proj....") direkt um die Ohren gehauen. Das hat, vor allem bei Neulingen, immer zu Hyperventilation geführt. Deshalb bin ich zu den EPSG Codes übergegangen. Das scheint aber eine schlechte Idee zu sein.

Zitat von thomas_rolf

Der Fehler tritt nur auf, wenn man in QLandkarteGT zwei oder mehr Karten (die sich in meinem Fall leicht überlappen, wegen des Kartenrandes) in einer Kartensammlung zusammengefasst hat und dann einen Kartenausschnitt zum Exportieren über den Rand einer der Teilkarten hinweg definiert. QLandkarte GT exportiert den Ausschnitt, legt dabei aber keine Kacheln an, die Teile aus beiden benachbarten Teilkarten enthalten, sondern erzeugt am Übergang kleinere Kacheln, die jeweils am Teilkartenrand enden. Wenn ich die Teilkacheln dann in Google Earth lade, liegen diese nicht mehr nebeneinander, sondern alle übereinander, ausserdem sind sie in der x-Achse verzerrt.
Wenn ich den Ausschnitt nur innerhalb einer Teilkarte wähle, werden die Kacheln ordentlich erzeugt, jedenfalls, sieht in Google Earth alles ordentlich aus.

Ist gut möglich, dass es da Probleme gibt. Dieser Fall kommt praktisch bei mir nie vor, da ich nur mit großflächigen Karten arbeite. Das Feature, pro Level mehrere Dateien zu lesen, war eher dafür gedacht, die 4GB Grenze zu überschreiten. Das werde ich mal in einer ruhigen Minute fixen müssen. Mein favorisierter Weg ist sowieso, die Einzelkarten zu einer Großen zusammen zusetzten. Nicht zuletzt, da die Custom Map auf 100 Dateien begrenzt ist. Da möchte man nicht unnötige halbe Kacheln haben.

Zitat von thomas_rolf

Wenn ich die Teilkarten mit 'gdalwarp file1.tif file2.tif (usw.) file_out.tif' vorher zu einer Karte zusammenbaue, tritt der Fehler nicht auf, für QLandkarteGT ist das ja dann eine Karte. Beim Kopieren wurde bei mir allerdings nur der erste tif-File korrekt nach file_out übertragen, beim zweiten File war die Auflösung irgendwie deutlich geringer als vorher, ausserdem war die Farb-Map korrupt. Muss ich da noch weitere Parameter setzen?

Die Dateien benutzen eine Farbpalette, oder? Und die ist für jede Datei anders? Das vergesse ich auch immer wieder. Entweder Du bringst die Quelldateien alle auf die selbe Farbpalette, oder Du benutzt gdal_translate mit "-expand" um 32bit RGBA Dateien herzustellen.