Beiträge von Erik Heinz

Hallo Leute,

auf der Suche nach topographischen Karten für Albanien bin ich darauf gestoßen, dass in einigen US-amerikanischen Online-Shops Karten vom ehemaligen Staatsinstitut "Institutin Topografik të Ushtrisë" verkauft werden. Bei "eastview cartographic" (http://www.cartographic.com/) z.B. kostet das Kartenblatt 1:25000 $39 (Papier) bzw. $29 (digitales Raster). Angeblich sollen diese Karten wesentlich detailreicher sein als die bekannten sowjetischen Militärkarten.

Fragen: Kennt jemand diese Karten? Wie ist die Qualität einzuschätzen? Gibt es europäische oder preiswertere Bezugsquellen? Welches Gitter wird verwendet?

Danke und Gruß,
Erik

Das verstehe ich jetzt nicht. Die Definition der PROJ-Bibliothek für EPSG:31468 sieht so aus:

# DHDN / Gauss-Kruger zone 4
<31468> +proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0 +ellps=bessel +datum=potsdam +units=m +no_defs <>

PROJ kennt offenbar nur das Datum Potsdam und setzt es gleich mit DHDN. Was ist der Unterschied?

Gruß,
Erik

Hallo Leute,

mit Hilfe der GDAL-Bibliothek habe ich einige Karten im GeoTIFF-Format erzeugt, mit dem Parameter "-a_srs epsg:31468". EPSG 31468 ist Gauss-Krüger Zone 4, also keine besonders exotische Projektion. TTQV meint allerdings "PCS = 31468 (name unknown)" und möchte, dass ich neu kalibriere. Wo liegt das Problem?

Detaillierte Information folgt unten (Ausgabe von "lsgeo").

Danke,
Erik

Geotiff_Information:
Version: 1
Key_Revision: 1.0
Tagged_Information:
ModelTiepointTag (2,3):
0 0 0
4440000 5640000 0
ModelPixelScaleTag (1,3):
1 1 0
End_Of_Tags.
Keyed_Information:
GTModelTypeGeoKey (Short,1): ModelTypeProjected
GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
GTCitationGeoKey (Ascii,36): "DHDN / 3-degree Gauss-Kruger zone 4"
GeogCitationGeoKey (Ascii,5): "DHDN"
GeogAngularUnitsGeoKey (Short,1): Angular_Degree
ProjectedCSTypeGeoKey (Short,1): Unknown-31468
ProjLinearUnitsGeoKey (Short,1): Linear_Meter
End_Of_Keys.
End_Of_Geotiff.

PCS = 31468 (DHDN / Gauss-Kruger zone 4)
Projection = 16264 (3-degree Gauss-Kruger zone 4)
Projection Method: CT_TransverseMercator
ProjNatOriginLatGeoKey: 0.000000 ( 0d 0' 0.00"N)
ProjNatOriginLongGeoKey: 12.000000 ( 12d 0' 0.00"E)
ProjScaleAtNatOriginGeoKey: 1.000000
ProjFalseEastingGeoKey: 4500000.000000 m
ProjFalseNorthingGeoKey: 0.000000 m
GCS: 4314/DHDN
Datum: 6314/Deutsches Hauptdreiecksnetz
Ellipsoid: 7004/Bessel 1841 (6377397.16,6356078.96)
Prime Meridian: 8901/Greenwich (0.000000/ 0d 0' 0.00"E)
Projection Linear Units: 9001/metre (1.000000m)

Corner Coordinates:
Upper Left ( 4440000.000, 5640000.000) ( 11d 8'49.60"E, 50d53'36.42"N)
Lower Left ( 4440000.000, 5620000.000) ( 11d 9' 1.36"E, 50d42'49.19"N)
Upper Right ( 4460000.000, 5640000.000) ( 11d25'53.00"E, 50d53'42.65"N)
Lower Right ( 4460000.000, 5620000.000) ( 11d26' 0.84"E, 50d42'55.38"N)
Center ( 4450000.000, 5630000.000) ( 11d17'26.20"E, 50d48'16.22"N)

Klingt ja spannend. Für welche Karten braucht man das?

Gruß,
Erik

Hallo Joern,

> CompeGPS hat jetzt noch eins draufgelegt und mit ihrem privaten
> RMAP-Format alle einzelnen Karten in ein gemeinsame Datei gesteckt.

Das ist nichts neues. TIFF bzw. GeoTIFF kann schon lange mehrere Auflösungen in einer Datei. Das nennt sich dort "pyramids". Qgis unterstützt das z.B.

> Habe ich etwas vergessen?

JA! Das optimale Datenformat für Karten müsste öffentlich verfügbar, wohldokumentiert und frei von Patenten sein sowie eine Referenzimplementation in Open Source haben. Idealerweise wird es irgendwann von einem geeigneten Gremium zum Standard erklärt.

Dieser Wildwuchs proprietärer Kartenformate im Consumerbereich, die den Nutzer mehr gängeln als ihm nützen, behindert den technischen Fortschritt und wird sich irgendwann hoffentlich überlebt haben. Die Zukunft ist das ganz bestimmt nicht.

viele Grüße,
Erik

Das Problem ist gelöst in Version 4.0.110.

Vielen Dank!
Erik

Zitat von "jockel"

Tom wird die DEM der Thüringen V5 sicher anpassen, sobald er die CD hat.

Wo ist das Problem? Ich habe meine CD direkt vom TLVermGeo und leihe sie Euch gerne, wenn das hilfreich wäre.

Zitat von "ynyny"

Zumindest über den Umweg des SRTM-Formats sollten sich die DEMs (dann
natürlich unter Verringerung der Auflösung) nach TTQV bringen lassen, oder?

Wie macht man das? Falls Du die libmpr von Christian Zietz verwendest: könntest Du mir bitte die letzte Version per Mail zukommen lassen? Das wäre echt nett. Auf der Webseite ist sie (aus Gründen, die man sich denken kann) nicht mehr verfügbar. Meine Adresse: eh2008 (at) 42net.de. Vielen Dank.

Gruß,
Erik

Mangels Antwort hake ich selber nochmal nach. Wie stehen denn die Chancen für das 25m-DEM der TOP50 Thüringen v5 in TTQV?

Frage in die Runde: wie sieht es denn bei den anderen bereits erschienen TOP50 v5 aus? Ist das Höhenmodell dort in TTQV importierbar?

Gruß,
Erik

Zitat von "Joern_Weber"

Klar ist das verlockend. Mich würde dann mal interessieren was es wirklich bringt.

Der Radroutenplaner des Tourexplorer verwendet eine eingefrorene Version des Datenbestandes aus dem ADFC-Tourenportal: http://www.adfc-tourenportal.de/adfc/.
Dort kann man sich das Netz anschauen. Abdeckung und Qualität der Daten ist regional sehr unterschiedlich. Zumindest alle Fernradwege sind aber drin.

Über die Entscheidung des ADFC für eine Kooperation mit MagicMaps anstelle einer offenen Lösung bin ich (als ADFC-Mitglied und stückweise auch -Aktiver) auch nicht glücklich, aber die Würfel sind da vorerst gefallen.

Gruß,
Erik

Nun hat auch Thüringen seine TOP50 Version 5. Die gute Nachricht ist, fast alle enthaltenen Karten lassen sich problemlos in TTQV importieren. Als Wermutstropfen gibt es aber Probleme mit dem 25m-DEM, auf das ich mich besonders gefreut hatte. Fehlermeldung: "Kalibrierung nicht erfolgreich. Fehler (x,y) = 55311,20300". Meine TTQV-Version ist die 4.0.107.

Da lässt sich doch bestimmt noch was machen?

vielen Dank im voraus,
Erik

Aussichtslos ist das Vorhaben trotzdem nicht. Man kann die kostenpflichtigen Versionen von cgpsmapper 30 Tage lang testen. Bei guter Vorbereitung sollte das ausreichen, um eine routingfähige Karte zum Laufen zu bringen. Der größte Teil der Arbeit ist ohnehin die Vor- und Aufbereitung der Daten.

Für die Vervollkommnung der Karte könnte man dann den freien online-Compiler unter http://mapcenter.cgpsmapper.com/ verwenden.

Gruß.
Erik

Hallo Leute,

es geht jetzt und die Ursache war in der Tat die "maximale TIF-Größe". Ich habe jetzt 5000 eingestellt. Vielen Dank nochmal für alle Antworten.

Die TIFF-Datei habe ich bereits beim Erzeugen mit dem Konvertierprogramm gdal_translate gekachelt, welches letzlich die freie libtiff-Bibliothek verwendet. Die Geschwindigkeit beim Anzeigen ist in Ordnung, auf jeden Fall schneller als ECW. Schöner als bei ECW ist auch die Darstellung gezoomter Karten. Die Optimierung der Kachelanordnung für TTQV kann ich mangels PU-Lizenz leider nicht testen, aber ich bin so schon völlig zufrieden.

Tschüs,
Erik

Danke für die Antworten. Ich habe Version 4.0.97 Standard. Neustart des Rechners habe ich nicht probiert, Neustart von TTQV schon.

Die TIF-Datei ist gut 200MB groß, 9200 x 8800 Pixel, 24 Bit RGB, gekachelt und LZW-komprimiert. Die maximale TIF-Größe aus den Einstellungen habe ich auf 100000 erhöht, das hat nichts geholfen.

Gruß,
Erik

Hallo Leute,

gibt es bekannte Probleme beim Import von Karten im Geotiff-Format?

Ich hatte gestern folgenden Effekt: die Karte wird klaglos importiert, aber nicht dargestellt. Beim Versuch, ins Kartenfenster zu wechseln, kam immer wieder der Explorer. "Kalibrieren" ließ sich auch nicht aufrufen. Die Geotiff-Datei hatte ich mit gdal_translate erzeugt. Mit ECW als Format hat es dann funktioniert. Trotzdem würde mich interessieren, wo das Problem liegt. Unten ein paar Informationen zur Datei.

Danke,
Erik

TIFF Directory at offset 0xce260d2 (216162514)
Image Width: 9200 Image Length: 8800
Tile Width: 256 Tile Length: 256
Bits/Sample: 8
Sample Format: unsigned integer
Compression Scheme: LZW
Photometric Interpretation: RGB color
Samples/Pixel: 3
Planar Configuration: separate image planes

Geotiff_Information:
Version: 1
Key_Revision: 1.0
Tagged_Information:
ModelTiepointTag (2,3):
0 0 0
532000 4462000 0
ModelPixelScaleTag (1,3):
2.5 2.5 0
End_Of_Tags.
Keyed_Information:
GTModelTypeGeoKey (Short,1): ModelTypeProjected
GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
GTCitationGeoKey (Ascii,33): "UTM Zone 32, Northern Hemisphere"
GeogCitationGeoKey (Ascii,7): "WGS 84"
GeogAngularUnitsGeoKey (Short,1): Angular_Degree
ProjectedCSTypeGeoKey (Short,1): PCS_WGS84_UTM_zone_32N
ProjLinearUnitsGeoKey (Short,1): Linear_Meter
End_Of_Keys.
End_Of_Geotiff.

PCS = 32632 (WGS 84 / UTM zone 32N)
Projection = 16032 (UTM zone 32N)
Projection Method: CT_TransverseMercator
ProjNatOriginLatGeoKey: 0.000000 ( 0d 0' 0.00"N)
ProjNatOriginLongGeoKey: 9.000000 ( 9d 0' 0.00"E)
ProjScaleAtNatOriginGeoKey: 0.999600
ProjFalseEastingGeoKey: 500000.000000 m
ProjFalseNorthingGeoKey: 0.000000 m
GCS: 4326/WGS 84
Datum: 6326/World Geodetic System 1984
Ellipsoid: 7030/WGS 84 (6378137.00,6356752.31)
Prime Meridian: 8901/Greenwich (0.000000/ 0d 0' 0.00"E)
Projection Linear Units: 9001/metre (1.000000m)

Corner Coordinates:
Upper Left ( 532000.000, 4462000.000) ( 9d22'35.69"E, 40d18'28.44"N)
Lower Left ( 532000.000, 4440000.000) ( 9d22'31.75"E, 40d 6'34.90"N)
Upper Right ( 555000.000, 4462000.000) ( 9d38'50.05"E, 40d18'24.13"N)
Lower Right ( 555000.000, 4440000.000) ( 9d38'43.27"E, 40d 6'30.62"N)
Center ( 543500.000, 4451000.000) ( 9d30'40.19"E, 40d12'29.81"N)

OK, nochmal etwas ausführlicher, in der Hoffnung, dass ich keinen Unsinn erzähle - in Kartographie bin ich nicht 100% sattelfest.

Die Google-Maps-API verwendet Formeln der Kugel-Mercator-Projektion zur Adressierung der Kacheln und Pixel, daher haben die aus den Kacheln zusammengesetzten Bitmap-Karten offenbar auch diese Projektion, sonst würde das ganze ja nicht zusammenpassen. Dabei hat jede Zoomstufe quasi ihr eigenes Koordinatensystem: 2^n Kacheln a 256*256 Pixel decken die ganze Welt ab.

Nach außen wird aber immer Lat/Lon verwendet und _diese_ Koordinaten beziehen sich natürlich auf WGS84, ansonsten könnten die meisten Nutzer ja nichts damit anfangen. Die Karten sind offenbar entsprechend umprojiziert. Damit wird das Frontend einfach und der Aufwand steckt in der Aufbereitung der Kartendaten, was ja Sinn macht.

Zum Kalibrieren einer solchen Karte sind die Eckpunktkoordinaten auf jeden Fall auf WGS84 zu beziehen. Ob man für die Projektion jetzt Ellipsoid oder Kugel annimmt, ist mir nicht ganz klar. Für kleine Kartenausschnitte ist das aber irrelevant: bei meiner Beispielkarte von etwa 10km x 10km wäre der Fehler etwa 2cm. Ich habe es letztlich so gemacht: Eckpunktkoordinaten in EPSG 41001 umgerechnet, Bitmap in ECW konvertiert und als ECW-Projektion "MRWORLD2" eingetragen. Weitere Kalibrierung ist nicht erforderlich und Fehler habe ich noch keine feststellen können.

Gruß,
Erik

Ich will ja nicht nerven, aber ein Fehler ist ein Fehler, auch wenn er die meisten Anwender nicht stört. Und diesen hier hat der Programmierer in 10 Minuten behoben, denke ich mal.

Also bitte nicht vergessen.

Danke,
Erik

Kleine Ergänzung zum Thema, habe den Thread gerade erst gesehen und mich in den letzten Tagen selber damit beschäftigt.

Google Maps verwendet durchgängig eine ganz simple Mercator-Projektion, und zwar streng genommen mit Kugel, nicht mit WGS84-Ellipsoid. Wenn man das weiß, wird die Kalibrierung noch einfacher, bzw. - bei großen Karten - auch genauer.

Die Kacheln kann man ohne weiteres auch per Script herunterladen, ohne Browser und Javascript. Wie die URLs zu konstruieren sind, erfährt man z.B. hier: http://www.codeproject.com/scr…/googlemap.asp?print=true. Man beachte allerdings, dass die Nutzung der Kartendaten außerhalb der Google-Maps-API, egal wie man sie heruntergeladen hat, den Nutzungsbedingungen widerspricht.

viele Grüße,
Erik

Hallo Leute,

wie mir scheint, erzeugt TTQV beim Export von Tracks mit mehreren Tracksegmenten ins Polish Format fehlerhafte Daten. Das Ergebnis sieht bei mir beispielsweise so aus (Datensegmente gekürzt):

[POLYLINE]
Type=0x5
Label=RR1

Data0=(50.92842,11.555464),...,(50.939302,11.549172)[POLYLINE]
Type=0x5
Label=RR1

Data0=(50.918379,11.546002),...,(50.918606,11.558218)[POLYLINE]
Type=0x5
Label=RR1

Data0=(50.908195,11.551219),...,(50.904524,11.558003)
[END]

Da fehlen nach meinem Verständnis des MP-Formates Zeilenumbrüche und [END]-Tags. Aussehen sollte es entweder so (bei Aufspaltung in mehrere POLYLINEs):

[POLYLINE]
Type=0x5
Label=RR1
Data0=(50.92842,11.555464),...,(50.939302,11.549172)
[END]

[POLYLINE]
Type=0x5
Label=RR1
Data0=(50.918379,11.546002),...,(50.918606,11.558218)
[END]

[POLYLINE]
Type=0x5
Label=RR1
Data0=(50.908195,11.551219),...,(50.904524,11.558003)
[END]

Oder so (als POLYLINE mit mehreren Datensegmenten):

[POLYLINE]
Type=0x5
Label=RR1
Data0=(50.92842,11.555464),...,(50.939302,11.549172)
Data0=(50.918379,11.546002),...,(50.918606,11.558218)
Data0=(50.908195,11.551219),...,(50.904524,11.558003)
[END]

Ich persönlich würde die Aufspaltung in mehrere POLYLINEs bevorzugen, da man sonst leichter Probleme mit Überschneidungen bekommt, wenn man in Richtung routingfähiger Karten gehen möchte. Momentan habe ich das Problem mit externer Nachbearbeitung der Dateien gelöst, aber vielleicht könntet Ihr den Fehler gelegentlich beheben?

Danke,
Erik

Ich muss nochmal nachhaken. Letzlich geht es mir gar nicht um TOP50-Overlays, sondern ich suche nur _irgendeine_ Möglichkeit, als ASCII vorliegende Koordinaten als Zeichnung mit geschlossenen Polygonen zu importieren.

Gibt es vielleicht einen Trick, das über einen Umweg zu erreichen?

Danke,
Erik

Ich verwende TTQV 4.0.79 Standard. Die Overlays hatte ich kurz vorher als Test erzeugt. Sie bestehen nur aus wenigen Punkten und in der TOP50-Software kann ich sie problemlos wieder einlesen.