TK25-Karten basierend auf OpenTopoMap.org?

Ja… dem ist so… Beispiel: Ich habe hier ein TK10-Blatt aus meiner Heimat: 3949-NW ETRS-Ausgabe). Dessen Nordwest-Ecke 52° 05’ 55,1’’ und 13° 49’ 53,5’’ (GRS80-Ellipsoid des ETRS89). Das Meßtischblatt 3949 (Stand: Oktober 1938) benennt die selbe Ecke mit 52° 6’ und 13° 50’’ (Bessel-Ellipsoid)

Das Meßtischblatt-Raster wird also beibehalten und nur nach ETRS89 umgerechnet. Der Blattschnitt wird also beibehalten und nicht verschoben.

Zu mindestens für den Online-Vertrieb (digitale Taten im tif-Format) von Karten wird auf Blattschnittfreiheit gesetzt. Ich kann bei uns Brandenburg im Geobroker (der im Moment leider Offline ist :frowning: ) einen freien Rahmen aufziehen, ein 5x5km ETRS-Kachel wählen (z.B. Shape-Datei dtk25_k10_utm33s aus dem BKG-Datensatz) oder eine TK10/ TK25 Blattnummer wählen. Ich bekomme dann die Daten entsprechend: hier ein Beispiel aus dem Brandenburg-Viewer: http://bb-viewer.geobasis-bb.de/?zoom=3&lat=5755975.56864&lon=421963.08862&layers=B000FFFFF0000FFFFTFFFFFFFFFFFTFFFFFTFFFFFFFFFFFFFFFFFFFFFFFFFFFFTTTF (die K10-Kachelbezeichnungen weichen ab).
Da unser Geobroker im Moment Offline ist (Fehler 502), kann ich nicht schauen, wie aktuell die Papierkarten vertrieben werden…

Die TK-25 Blattnummern werden aber sicher nicht ihre Bedeutung verlieren, spiegeln sie sich doch in vielen anderen Dingen wider: z.B. Netzknotenkarte: http://www.ls.brandenburg.de/media_fast/4055/Dahme-Spreewald.16055347.pdf (Achtung 9,7 MB) die Nummerierung der Netzknoten erfolgt innerhalb eines Meßtischblattes von 1-n

Sven

Ich hab mal 5 Blätter gemacht. Die vier sächsischen aus #38 oben und eine bayerische.

(4x Sachsen, 45 MByte): http://geo.dianacht.de/messtischtest/5041.zip
(1x Bayern, 18MB): http://geo.dianacht.de/messtischtest/7446.zip

Könnte mal ein Kundiger drüberschauen, ob Lage und Blattschnitt passt?

tfw-Dateien sind keine dabei, aber ich weiss eh nicht, wozu man die braucht, wenn man geotiffs hat. Aber egal, die sind leicht zu erzeugen. Das grosse Problem ist die Datenmenge… Mal schaun was man da noch machen kann, sicher habe ich nach der Verarbeitung viel zu viele Farben. Die Testblätter gibt es deshalb auch nur mit 3m/Pixel, 1.5m/Pixel hielte ich für die ideale Auflösung, aber so lange ich so grosse Brocken erzeuge, will ich gar nicht so ne hohe Auflösung…

Grüße, Max

in der tfw-Datei stehen einige Angaben, wie Breite und Höhe , dann Drehung und Position des linken unteren Pixels der Kartendatei… http://de.wikipedia.org/wiki/World_file

Ansonsten die sächsischen Blätter:

Blatt: 5426

NW-Ecke:
NO-Ecke:
SW-Ecke:
SO-Ecke:

getestet mit: ArcGis 10.2.2 (10.2.2.3552)

Datenrahmen: EPSG 25833
TK25-Kartenrahmen: Ebene b25_utm33s aus dem BKG-Datensatz
OSM-Rasterdateien: für 5041, 5042, 5141, und 5142 als geographische Ausdehnung EPSG 31468 festgelegt.
angewendete Transformationsmethode: DHDN_To_ETRS_1989_NTv2

Sven

ok, danke… Also immer um 2-3 Meter zu weit links. Mal sehn, ob ichs hinbiegen kann oder ignoriere oder fettere Linien male :wink:

Hallo Max,

keine Ahnung, ob das weiterhilft: Habe gerade die TIFF-Datei angeschaut und festgestellt, dass die (verlustfreie) LZW-Komprimierung nicht aktiviert ist. Oder wird sie bei GeoTIFFs nicht unterstützt?

Gruß, Andreas

Ich weiß jetzt aber nicht ob hier bereits die Abweichung zwischen WGS84 und GRS80 zu Tragen kommt…

(ich bin Müde… und lege mich schlafen…)

Sven

Doch, ich denke schon. Ich muss mal versuchen, die Kombinationsmöglichkeiten des Mapservers zu verstehen oder durchzuprobieren.

Hier gibts übrigens schon mal Vorschaubilder (pngs, keine georeferenzierten Bilder), die Seite ist aber noch Baustelle.

Ich weiss, woher das kommt: Die Daten für die Karte kommen aus Mapproxy und Mapserver. Die machen NTv2. Die Kanten kommen aus Postgis und das macht eine Helmert-Transformation. Ich glaube, ich nehme dann mal Postgis das Rechnen ab.

Grüße, Max

Aus der Doku:
GDAL/GTiff: Supports the “TILED=YES”, “BLOCKXSIZE=n”, “BLOCKYSIZE=n”, “INTERLEAVE=[PIXEL/BAND]” and “COMPRESS=[NONE,PACKBITS,JPEG,LZW,DEFLATE]” format specific options.

Cool. :slight_smile: Danke für Deine Mühe!

Gruß, Andreas

Guten Morgen Max,

wäre es möglich, den Urheber- und Lizenzhinweis außerhalb der Kartenkachel zu positionieren, beispielsweise durch das Anflanschen eines schmalen Streifens oder durch eine breitere Überlappung am unteren Ende der Kachel?

Gruß, Andreas

Gerne, falls es nicht stört, dass das Eck des Blattes nicht an der Unterkante sitzt… Dann gebe ich da 20 oder 30 Pixel zu und bau dort auch noch einen Maßstab ein, gehört sich ja eigentlich so.

Kann mir nicht vorstellen, dass das stört - gute Idee, in den Bereich auch noch den Maßstab zu integrieren. Aber das kann letztlich nur Herr Seiger, der Entwickler der Programmbasis, bestätigen. Wie schon mal angedeutet, ist der Kontakt zu ihm langatmig, weshalb ich nicht mal eben nachfragen kann.

Gruß, Andreas

Ich hab mal 2 Blätter mit 1.5, 2, 2.5 und 3 Meter/Pixel gemacht, die Größe eines Blattes wäre dann zwischen 20 MByte für die 3m-Version und 90MByte für die 1.5m-Version (jetzt neu mit Komprimierung und .tfw-Datei). Kannst mal schaun, welche Kompromisse zwischen Größe und Auflösung du eingehen möchtest? Irgendwie will man ja die Karten dann später auch verteilen…

(Zip mit insgesamt 363MByte): http://geo.dianacht.de/messtischtest/mtbv2.zip

Grüße, Max

Nachtrag: Könntest Du mal zwei Pilze am Funtensee finden, z.B. am Schloßkopf oder im Stuhlgraben? Da weicht nämlich die Blattnummer vom sonstigen Schema ab. Eigentlich gibt es im Grenzgebiet manchmal Doppelblätter, wenn sich für ein Stückchen Ausland kein neues Papier lohnt, so wie hier auf den amtlichen Blattgrenzen das Blatt 8244/8344. Unten auf dem Bild ist aber auch das Blatt 8543 zu sehen, dass zwischen den Gitternetzlinien hängt. Wäre interessant, ob die Pilzsucher diese Wunderlichkeit mitmachen oder stur dem Gitter folgen.

Danke für Deine Mühe. Habe die Frage an Peter Karasch, den Landeskoordinator für Pilzkartierung in Bayern, und an Frank Dämmrich, den MykIS-Admin, weitergereicht - ich zitiere aus meiner E-Mail:

Gruß, Andreas

PS: Das mit den Doppelblättern prüfe ich gleich im Anschluss.

Da kein Kartenmaterial hinterlegt ist, kann ich nicht ausprobieren, ob eine Doppelkarte geladen wird oder nicht. Aber nachdem die Übersichtskarte von Bayern zur MTB/TK-Auswahl strikt nach dem MTB-Raster gegliedert ist, gehe ich von Einzelkarten aus.

Gruß, Andreas

Logisch, aber nicht amtlich. Ist gut, weil ich habs auch so gemacht. Ich hatte keine Ahnung von der Besonderheit des Funtensees und dachte auch, das sei eigentlich der Witz an diesem Blattschnitt: Ein Reich, Ein Raster :wink:

Hallo Max,

ich habe nur eine Frage interessehalber… die gerechneten Karten sind ja in RGB…

Ließe sich es seitens des Renderings machen, die Karten auf 256 Farbwerte zu reduzieren? Das hätte mehrere Vorteile: die Dateigrößen würden sich (erheblich) verringern. Man könnte bestimmen, welcher Farbwert eine bestimte Inhalteebene belegt. Die Rasterdaten, die z.B. wir in Brandenburg über die Landesvermessung bekommen, haben 256 Farben und nur die Farbwerte 0-31 werden für 21 Inhalteebenen verwendet.

Sven

Mal gucken… Weisst Du wie man sowas mit GDAL erzeugt?

256 Farben wäre kein grosser Verlust… Wers ausprobieren will: http://geo.dianacht.de/tests/preview.php?format=png8&mtb=7137&res=15
(der Link hat 3 Parameter: res=3…18 Auflösung im m/px, mtb=… die Blattnummer und format=png|png8|jpeg|gif|gtiff das Ausgabeformat. gif und png8 sind 256 Farben.

Bei Gdal kannst Du mit -ot den Datentype in der Ausgabedatei ändern

z.B.

-ot int16

oder

-ot Byte

Byte sollte den 256 Farben entsprechen

Edit: Ich verwende so was um bei DEM-Geotiffs mit Float32 die Größe durch eine Umwandlung in int16 zu reduzieren. Ob eine Reduzierung auf Byte noch gut aussieht (keine Ahnung ob gdal dithering kann) kann ich nicht sagen.

Byte liefert ein Bild mit 256 Graustufen. INT16 vermutlich 65536 Graustufen, aber ich hab keine Software, die das anzeigen würde…
Mit “DISCARD_LSB=4” kann ich die unteren 4 Bit jedes Farbwertes auf 0 setzen und hätte sowas wie ein 12-bit-Bild, das hilft deutlich beim Komprimieren. Aber eine ganz normale Farbreduzierung mit “die passendsten 256 Farben suchen, Palette draus erzeugen und dann jeden Bildpunkt darauf verweisen lassen” hab ich noch nicht gefunden.

Grüße, Max

Ist PNG (ohne Reduktion auf 256 Farben) bezogen auf den Speicherplatzverbrauch günstiger als TIF mit LZW-Kompression? Habe gerade auf der Website des Gis gesehen, dass neben TIF auch PNG unterstützt wird - das müsste doch dann alternativ funktionieren?

Zum Vergleich von PNG8 und PNG: Der Farbverlauf bei 256 Farben (PNG8, RES3) ist grober gestuft und helle Abstufungen werden gleich als Weiß interpretiert (sieht nicht nach Dithering aus). Außerdem erscheinen die Höhenlinien unschärfer/etwas dünner.

Nachtrag: Vielleicht lässt sich bei den TIFs mit der Deflate-Kompression noch etwas Dateigröße einsparen - nachdem was ich recherchiert habe, wird diese verlustfreie Datenkompression bereits bei GZIP und PNG verwendet.

Gruß, Andreas