DOP ist nicht deckungsgleich

Ich habe ein DOP1,6m meiner Stadt beim LVA Lizenziert und heute per Email zugestellt bekommen.

Inhalt: eine TIFF Datei, tfw, wld und txt. Die letzteren drei enthalten nur paar Zahlenwerte welche die Koordinate des Bildausschnittes wiedergeben.

Das TIFF habe ich in ein JPG umgewandelt und dann mit JOSM und dem PicLayer Modul reingeladen. Das Foto entsprechend skaliert damit es deckungsgleich ist. Soweit alles toll, nur je weiter ich von dem zentrierten Punkt mich in Josm entferne, um so größer werden die Abweichungen von Luftbild und OSM Daten. Das sind dann Abweichungen von bis zu 100m. Das Luftbild kann ich an diesen Abweichstellen deckungsgleich hinschieben und verlagere das Problem dann bei einem anderen Bereich.

Sieht für mich nach dem selben Problem aus, welches damals dieser PlanAT Type hatte, wo auch nichts so 100% richtig passte.

Wie entzerre ich diesen Scheiß in die richtige Projektion, damit das Luftbild wie bei dem WMS aussieht?

einfach: http://warper.geothings.net/ da anmelden, uploaden (als private) kontrollpunkte mit bereits vorhandener OSM karte setzen und die url mit wms-plugin von josm einspielen.

ist zwar ungenau (immerhin verwendest du zur korrektur ungenaue osm kartenpunkte) … aber eben doch am schnellsten.

Evtl. kann man beim JOSM die angezeigte Projektion so ändern, dass das unveränderte DOP dazu passt.

Ansonsten: GRASS soll sowas können.
http://www.gdf-hannover.de/lit_html/grasshandbuch_v12/node173.html

Weide

naja das tiff könntest auch mit gdal (linux) bzw. den fwtools (gdal für windows) umrechnen. dazu brauchst halt deine projektion (dürfte gauss-krüger koordinatensystem sein) und dein datum damit du es auf wgs84+mercator umrechnen kannst. du könntest aus dem tiff (ich nehme an es ist ein geoTiff) genau diese werte auslesen und die projektion umrechnen (alles mit gdal).

Edit: Trotzdem müsstest du glaub ich das geoTiff schlussendlich in einem lokalen WMS-Server verwenden, damit du das genau wie bei JOSM verwenden kannst. Arbeitsaufwand geschätzt: 8h (solltest du nicht wissen wie das alles funktioniert). mit dem map-warper lässt sich das ganze (wenn auch ungenau) in ca. 30 Minuten erledigen.

Ich habe geothing ausprobiert und nachdem ich 30 Punkte gesetzt habe, passt es und alles ist weitestgehend deckungsgleich. Dafür ist die Bildqualität die mir geothing liefert unter aller Sau und in der Auflösung stark verschlechtert.

Das Original hat 3344x2709 Pixel und der Export von Geothing liefert nur 1713x953

Dann rechnen Sie die Längen-/Brei"-tengrad-Rand"-koordinaten der Längen-/Brei"-tengrad-location “`naxosll”’ mit dem Modul $ m.proj in das UTM-System um… Ich verstehe nur Bahnhof :smiley:

Mir geht’s da auch nicht besser; das grenzt an Arbeit :slight_smile:

Was ist mit der anderen Idee, also die Projektionsmethode im JOSM zu verstellen (z.B. von Mercator auf WGS84). Da müssten doch eigentlich die Verzerrungen deutlich geringer werden…

Weide

Tim von geothings meinte, ich soll das Luftbild stückeln, dann würde der Server das nicht mehr künstlich verkleinern. Das habe ich nun gemacht und es funktioniert. Das Ergebnis ist optisch immer noch nicht so schön wie das Original, aber man kann damit arbeiten.

@edwin-ldbg: JOSM hat so viele Projektionsmethoden dabei, meinst nicht, dass eine davon “die richtige” ist für Deine Bilder?

Immerhin verzerrst Du jetzt die Bilder.

Abgesehen von der Vergrößerung sind das Bild absolut deckungsgleich zu den Bildern, die man beim Bayernviewer sehen kann. http://www.geodaten.bayern.de/BayernViewer/index.cgi?rw=4340990&hw=5275210&layer=DOP&step=1

Merkator passt im Zentrierten Bereich, darum herum gibt es immer größer werdende Abweichungen. WGS84 bringt nichts brauchbares und das restliche Zeug wie Estland, Frankreich, Schweiz Gitter brauch ich nicht testen. Die UTMs liefern auch nur Müll.

Laut Freund Google soll das Zeug in Gauss-Krüger projeziert sein, was laut Google das Programm Josm nicht kann.

Das da klingt gut, richtet sich aber an Profis :smiley: http://www.gdf-hannover.de/lit_html/grasshandbuch_v12/node42.html

Hallo Edwin,

Hm - dann hast Du vielleicht falsch bestellt?

Falls ja: ruf nochmal an, entschuldige Dich für den Fehler, und frage ob sie Dir vielleicht die Bilder nochmal in WGS-84 schicken könnten?
Das ist für die Spezialisten vom LVA-Bayern ganz einfach und da machen sie sicher gern wenn Du nett fragst.

Gruss, Markus

Das Zeug was man damals für das Oberpfalzprojekt erhalten hat, war genau das selbe.

also nochmal… die längere/genau lösung des problems
mit gdal auf geoTiff:

gdalinfo xxx.tif

dann weisst du welche GK-system verwendet werden also entweder: EPSG: 31464, 31468, 31494

und dann musst du nur noch umprojezieren mit:

gdalwarp -t_srs ‘+proj=mercator +zone=32 +datum=WGS84’ EPSGXXXXX.tif wgs84merk.tif (oder so ähnlich)

aber schau einfach selbst:
http://spatialreference.org/ref/epsg/31468/
und http://gdal.org/gdalwarp.html

achja für windows einfach fwtools 2.1 installieren, da is gdal dabei …

und noch was ich kenn mich damit auch nicht wirklich aus und bin selbst noch ein bisschen beim herumspielen also keine garantie für alle aussagen :wink:

also deine tif datei müsste mit gdalinfo eigentlich folgendes ausspucken:

PPROJCS[“DHDN / Gauss-Kruger zone 3”,
GEOGCS[“DHDN”,
DATUM[“Deutsches_Hauptdreiecksnetz”,
SPHEROID[“Bessel 1841”,6377397.155,299.1528128,
AUTHORITY[“EPSG”,“7004”]],
AUTHORITY[“EPSG”,“6314”]],
PRIMEM[“Greenwich”,0,
AUTHORITY[“EPSG”,“8901”]],
UNIT[“degree”,0.01745329251994328,
AUTHORITY[“EPSG”,“9122”]],
AUTHORITY[“EPSG”,“4314”]],
UNIT[“metre”,1,
AUTHORITY[“EPSG”,“9001”]],
PROJECTION[“Transverse_Mercator”],
PARAMETER[“latitude_of_origin”,0],
PARAMETER[“central_meridian”,9],
PARAMETER[“scale_factor”,1],
PARAMETER[“false_easting”,3500000],
PARAMETER[“false_northing”,0],
AUTHORITY[“EPSG”,“31467”],
AXIS[“Y”,EAST],
AXIS[“X”,NORTH]]

… sag ob ich mich irre :wink:

Driver: GTiff/GeoTIFF
Files: fuck.tif
Size is 3344, 2709
Coordinate System is:
PROJCS[“unnamed”,
GEOGCS[“unnamed”,
DATUM[“unknown”,
SPHEROID[“unretrievable - using WGS84”,6378137,298.257223563]],
PRIMEM[“Greenwich”,0],
UNIT[“degree”,0.0174532925199433]],
UNIT[“metre”,1,
AUTHORITY[“EPSG”,“9001”]],
AUTHORITY[“EPSG”,“31468”]]
Origin = (4339136.179999999700000,5278047.320000000300000)
Pixel Size = (1.600000000000000,-1.600000000000000)
Metadata:
AREA_OR_POINT=Area
TIFFTAG_SOFTWARE=Geodaten Bestellung von Matthias Schulze
TIFFTAG_DATETIME=09.06.2006 00:00:00
TIFFTAG_COPYRIGHT=Landesamt für Vermessung und Geoinformation
TIFFTAG_XRESOLUTION=31
TIFFTAG_YRESOLUTION=31
TIFFTAG_RESOLUTIONUNIT=3 (pixels/cm)
Image Structure Metadata:
INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left ( 4339136.180, 5278047.320)
Lower Left ( 4339136.180, 5273712.920)
Upper Right ( 4344486.580, 5278047.320)
Lower Right ( 4344486.580, 5273712.920)
Center ( 4341811.380, 5275880.120)
Band 1 Block=3344x8 Type=Byte, ColorInterp=Red
Band 2 Block=3344x8 Type=Byte, ColorInterp=Green
Band 3 Block=3344x8 Type=Byte, ColorInterp=Blue

Ich hab mal deinen “So oder so ähnlich Code” ausprobiert. Da kommen nur Fehler 1 oder Fehler 4. Hab paar Parameter geändert, die `in " geändert, da epsg:31468 oder nur 31468 eingegeben. Bringt alles nix.

Im Web hab ich dann das da gefunden. gdalwarp -of GTiff -co “TILED=YES” -srcnodata 31468 -dstnodata wgs84 -t_srs “+proj=merc +ellps=sphere +R=6378137 +a=6378137 +units=m” -rcs -order 3 -multi fuck.tif warped.tif

Da arbeitet dann was von 0-100% und erzeugt eine TIF die leicht gedreht ist. Deckungsgleich ist da aber immer noch nichts :smiley: Was die ganzen Parameter bedeuten, keine Ahnung :smiley:

was steht denn eigentlich in den mitgelieferten Textdateien… vielleicht etwas vonwegen GK3 oder GK4 oder EPSG:…?

In der Textdatei steht

Kachelname: /4339136_5273713
Bildflugnummer: 106022
Bildflugunternummer: 0
Aufnahmetag: 9.6.2006
Auflösung: 79.4 dpi
Bodenauflösung: 1.60 m

Sw-Koordinate: [4339136.00:5273712.00]
Nw-Koordinate: [4339136.00:5278048.00]
No-Koordinate: [4344486.40:5278048.00]
So-Koordinate: [4344486.40:5273712.00]

In den anderen zwei Dateien steht nur das da

1.60000000
0.00000000
0.00000000
-1.60000000
4339136.80000
5278047.20000

probier mal:
gdalwarp s_srs ‘+proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0 +ellps=bessel +datum=potsdam +units=m +no_defs’ t_srs ‘+proj=tmerc +zone=32 +ellps=WGS84 +datum=WGS84 +units=m +no_defs’ fuck.tif wgs84_fragezeichen.tif

aber bin mir nicht sicher ob du EPSG:31467 oder 31468 bist. eigentlich ist dein ort in 31467, aber laut http://www.gdi.bayern.de/home_data/Kopie%20von%20GDI-Web/Geowebdienste/geowebdienste.htm benutzt bayern 31467 nicht sondern nur 31468.
daher auch: sw-koordinate: 4339136.00 < x_0=4500000

ERROR 4: `s_srs’ does not exist in the file system,
and is not recognised as a supported dataset name.

-s_srs und -t_srs sorry

ERROR 1: Translating source or target SRS failed:
'+proj=tmerc