Luftbilder von Aerowest

Also ich denke das der Fehler woanders liegt. Denn ich hatte auch unter XP schon das Glück mit diesem Plugin zu arbeiten. Im Moment funktioniert es aber leider nicht mehr. Warum weiß ich auch nicht.

Diese Meldung bekomme ich, wenn das TIF den falschen EPSG-Wert hat.

Hast du es denn mit meiner Anleitung (#69) probiert?
http://forum.openstreetmap.org/viewtopic.php?pid=181065#p181065

Hast du die Aerowest-Bilder vorher irgendwie behandelt, wenn ja, wie?

Ich habe mir den Quellcode des Plugins angesehen, das verwendet aber zur Projektion nur wieder irgendwelche jar-Dateien.
Habe deshalb noch nicht herausgefunden, was das genau macht.

Ich werde das vermutlich heute Abend überprüfen, ich habe hier Referenzdaten.

Gruß,
Mondschein

Weiter vorne gabs ja den Hinweis auf eine frühere Plugin-Version. Stehen die in irgendeinem svn noch?

Gruß,
ajoessen

Wenn ich mich richtig erinnere, dann konnte ich mit dem alten Plugin, direkt die jpg- und jgw-Dateien einlesen, allerdings funktioniert das nicht mit Mercator, weshalb hier jemand die Methode mit der Umwandlung in ein GeoTiff entwickelt hat, mit dem das dann auch mit Mercator geht (mit dem neuen Plugin).
Habe hier ein Backup des Plugins, das ist oft hilfreich. :slight_smile:

md5sum
8d7c626404367155c10df5a7fcb2c593 ImportImagePlugin.jar

Gruß,
Mondschein

Also egal ob ich aus dem 31466-jpg erst ein Geotiff mache oder nicht: Erstmal erscheint das Bild prinzipiell bei 7°Nord und 51°Ost; unabhängig davon, was in der properties-Datei voreingestellt ist. Setze ich den Haken bei Easting manuell, wird das Bild gequetscht an der richtigen Position gesetzt.

Den Error bekomme ich nicht, die Umprojezierung mache ich in Quantum GIS (was sein eigenes GDAL dabei hat).
Dort sieht das Bild hinterher ordentlich aus.

Gruß,
ajoessen

Wobei dir die Umwandlung in EPSG 3857 für den Mapserver wenig bringt, da JOSM grundsätzlich immer nur EPSG 4326 Tiles vom Server holt, unabhängig davon, ob der Server andere EPSG anbietet oder welche Projektionsmethode in JOSM eingestellt wurde, JOSM probiert sogar EPSG 4326 Tiles herunterzuladen, wenn der Server diese gar nicht anbietet.

Hier mein bisheriges Vorgehen.
Später werde ich die Dateien direkt in EPSG 4326 umwandeln (wenn ich mein GDAL-Problem mit den verbesserten Koordinateninformationen gelöst habe), damit der Mapserver keine Umprojektion mehr vornehmen muss:

for i in /data/jpg/*.jpg; do filename=$(basename $i); gdal_translate -of GTiff -co COMPRESS=JPEG -a_srs epsg:31467 $i /data/tif/${filename%.*}.tif; done;
gdal_merge.py -v -of GTiff -co COMPRESS=JPEG -co TILED=YES -o /data/epsg-31467_tiled.tif /data/tif/*.tif
gdaladdo --config COMPRESS_OVERVIEW JPEG /data/epsg-31467_tiled.tif 2 4 8 16 32 64 128 256

Zusätzlich gebe ich dem Mapserver die verbesserten Koordinateninformationen mit, siehe:
http://forum.openstreetmap.org/viewtopic.php?pid=181728#p181728
Das wird nicht mehr nötig sein, wenn ich mein GDAL-Problem gelöst habe.

Gruß,
Mondschein

Nein, die Bilder waren im Originalformat (EPSG:31467) von Aerowest bzw. ATKIS.

Hi !

ich habe gerade nochmal einen neuen Anlauf genommen auf Basis von #30.

Jetzt habe ich nochmal mit

gdalwarp -s_srs epsg:31467 -t_srs epsg:4326 C:\Users\tappenbeck\Desktop\Aerowest\aerowest_ostrohe_spanngrund_christin.jpg C:\Users\tappenbeck\Desktop\Aerowest\aerowest_ostrohe_spanngrund_christin_4326.tif

transformiert und in JOSM 4279 / imageimport… 26413 einfach unter der Merkator-Darstellung eingelesen. (http://www.tappenbeck.net/forum/osm/aerowest_ostrohe_4326.tif

Wenn ich Bing darüberlege sieht das “identisch” aus.

Einzig das Haus von kellerma (#55) - was er nach seinem test (http://www.openstreetmap.org/browse/way/123623837) eingezeichnet hat paßt nicht aus meiner Sicht nicht.

… und ich habe keine weitere Projekt zugewiesen. Mal sehen was andere Stellen bringen

Gruß Jan .-)

Das Häuschen ist das einzige, welches gestimmt hat.
Jetzt hat ein gewisser “Lübeck” lauter um 3 m verschobe Häuser und Garage plaziert.
Kennt den jemand?

Ciao,
Frank

Der wohnt in ner WG mit Edwin

Hallo Jan,

hoffe, Du verstehtst ein bisschen Spass :wink:

Welche gdal-Version benutzt Du?

gdalinfo --version
GDAL 1.8.1, released 2011/07/09

Vielen Dank.

Ciao,
Frank

hi !

ich wollte gerade sagen - ich weiß doch mit wem ich zusammen wohne …!

GDAL 1.7.0b2, FWTools 2.4.7, released 2010/01/19

Wenn ich mir so

http://sautter.com/map/?lat=54.21441&lon=9.12931&zoom=17&layers=00B0000TFFFFFTFF

in den verschiedenen Karten ansehe, dann weiß ich schon einmal nicht was überhaupt richtig sein soll !!!

Bei meinem obrigen Versucht hatte ich auch Bing eingeblendet und etwas mit transparenz gespielt - das machte keinen so schlechten Eindruck - soweit das erkennbar war.

… und wie geht es sonst jetzt weiter - die “falschen” Häuser zu löschen ist das einfachste.

Gruß jan :slight_smile:

Wenn ich mit dem Debian 6 mitgelieferten gdal 1.6 das aerowest-bild konvertiere, dann komm ich ziemlich gut auf Deine Häuser hin.

Was jetzt wirklich besser ist, weiss ich auch nicht :wink:

Ciao,
Frank

Vorsicht, JOSM verlangt vom WMS zwar EPSG 4326, aber mit einer für EPSG 4326 falschen Bounding Box. Dadurch wird die “Transformation” nach Mercator erreicht. Ich würde daher möglichst wenig Vorverarbeitung machen, damit der Datenverlust gering ist (bei EPSG 4326 wird das Bild ja gequetscht). Das geht dann natürlich etwas auf die WMS-Performance.

OT Frage: Gehört hier jetzt nicht genau hin. Kann mal jemand mit einer gdal Version > 1.6 schauen, wie EPSG 31277 aussieht? Ich habe mich hier ja vornehm zurück gehalten, da ich dachte nichts mit UTM Koords zu tun zu haben. Aber jetzt habe ich ein identischen Problem (Shift von einigen Metern) weit weit weg. Bei mir siehts so aus

MGI / Balkans zone 7 (deprecated)

<31277> +proj=tmerc +lat_0=0 +lon_0=21 +k=0.9999 +x_0=7500000 +y_0=0 +ellps=bessel +datum=hermannskogel +units=m +no_defs <>
alternativ auch so
<31277> +proj=tmerc +lat_0=0 +lon_0=18 +k=0.9999 +x_0=6500000 +y_0=0 +ellps=bessel +towgs84=550.499,164.116,475.142,5.80967,2.07902,-11.62386,0.99999445824 +units=m

ich suche nach weiteren Möglichkeiten.

Ich kenne sogar die richtigen Parameter, weiß aber nicht, wie ich sie in dem String unterbringe:

Coordinate System Parameters

CS_NAME: SERBIA
DESC_NM: Serbia/ Balkans zone 7- Globalni
DT_NAME: MGI_Serbia
GROUP: EUROPE
MAP_SCL: 1MGI
PARM1: 21
PROJ: TM
QUAD: 1
SCL_RED: 0.9999
SOURCE: EPSG, V6.3, 31277 [Large and medium scale topographic mappi]
UNIT: METER
X_OFF: 7500000
ZERO_X: 0.0001
ZERO_Y: 0.0001

Datum Parameters

BWSCALE: 6.88933
DELTA_X: 574.02732
DELTA_Y: 170.17492
DELTA_Z: 401.5453
DESC_NM: Serbia; uses MGI grid shift
ELLIPSOID: BESSEL
ROT_X: -4.88786
ROT_Y: 0.66524
ROT_Z: 13.24673
USE: 7PARAMETER

Ellipsoid Parameters

DESC_NM: Bessel, 1841
E_RAD: 6377397.155
P_RAD: 6356078.963
SOURCE: US Defense Mapping Agency, TR-8350.2-B, December 1987

OGC WKT Description

PROJCS[“Serbia/ Balkans zone 7- Globalni”,
GEOGCS[“MGI_Serbia”,
DATUM[“MGI_Serbia”,
SPHEROID[“Bessel, 1841”,6377397.155,299.1528153513275]],
PRIMEM[“Greenwich”,0],
UNIT[“degree”,0.0174532925199433]],
PROJECTION[“Transverse_Mercator”],
PARAMETER[“latitude_of_origin”,0],
PARAMETER[“central_meridian”,21],
PARAMETER[“scale_factor”,0.9999],
PARAMETER[“false_easting”,7500000],
PARAMETER[“false_northing”,0],
UNIT[“METER”,1]]

ESRI WKT Description

PROJCS[“Serbia_Balkans_zone_7_Globalni”,GEOGCS[“GCS_MGI_Serbia”,DATUM[“D_MGI_Serbia”,SPHEROID[“Bessel_1841”,6377397.155,299.1528153513275]],PRIMEM[“Greenwich”,0],UNIT[“Degree”,0.017453292519943295]],PROJECTION[“Transverse_Mercator”],PARAMETER[“latitude_of_origin”,0],PARAMETER[“central_meridian”,21],PARAMETER[“scale_factor”,0.9999],PARAMETER[“false_easting”,7500000],PARAMETER[“false_northing”,0],UNIT[“Meter”,1]]

Das ist nicht gdal, das ist proj :wink:


$ grep 31277 /usr/share/proj/*
/usr/share/proj/epsg:<31277> +proj=tmerc +lat_0=0 +lon_0=21 +k=0.9999 +x_0=7500000 +y_0=0 +ellps=bessel +datum=hermannskogel +units=m +no_defs  <>
/usr/share/proj/epsg_new:<31277> +proj=tmerc +lat_0=0 +lon_0=21 +k=0.9999 +x_0=7500000 +y_0=0 +ellps=bessel +datum=hermannskogel +units=m +no_defs  <>
/usr/share/proj/epsg_orig:<31277> +proj=tmerc +lat_0=0 +lon_0=21 +k=0.9999 +x_0=7500000 +y_0=0 +ellps=bessel +datum=hermannskogel +units=m +no_defs  <>
/usr/share/proj/epsg_south:<31277> +proj=tmerc +lat_0=0 +lon_0=21 +k=0.9999 +x_0=7500000 +y_0=0 +ellps=bessel +datum=hermannskogel +units=m +no_defs  <>
/usr/share/proj/esri:<31277> +proj=tmerc +lat_0=0 +lon_0=21 +k=0.999900 +x_0=7500000 +y_0=0 +ellps=bessel +units=m +no_defs  no_defs <>

Kann gut sein, dass “hermannskogel” ähnlich wie “potsdam” hard reinkompiliert wird bei proj.

“gdal” schaut so aus:


$ grep -r 31277 gdal-1.8.1/*
gdal-1.8.1/data/pcs.csv:31277,"MGI / Balkans zone 7",9001,4312,18277,9807,1,1,4530,8801,0,9102,8802,21,9102,8805,0.9999,9201,8806,7500000,9001,8807,0,9001,,,,,,

Ciao,
Frank

ohja, sorry. Mein Fehler. gdal hat mich nicht interessiert. Das ganze wird bei mir noch schlimmer. Wie es aussieht, werden trotz gleichem epsg Code je nach Land verschiedene 0-Meridiane (Theodor Albrecht’s “Ferro Meridian” vs Greenwich) genommen. Na dann lass ich euch mal wieder alleine. Wäre ja zu schön gewesen, wenn es ein ähnliches Problem gewesen wäre.

die Datum Parameters dürften die 7-paramet. Helmert-Trafo sein, somit


+ellps=bessel +towgs84=574.02732,170.17492,<etc>

Du kennst
http://www.spatial-analyst.net/wiki/index.php?title=MGI_/_Balkans_coordinate_systems
?

Ciao,
Frank

So, back on topic:

In Nürnberg holt
PROJECTION
“init=epsg:31468”
“towgs84=597.1,71.4,412.1,0.894,0.068,-1.563,7.58”
END
noch mal 50 cm raus zu
“towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.70”

Es fehlt aber immer noch knapp 1 m zum ImportImagePlugin.
Wird Beta2007 wohl auch nicht mehr schaffen :wink:

Ciao,
Frank

PS
Beim Testen
~/.josm$ rm -rf wms-cache/*
nicht vergessen :wink:

Jetzt bekomme ich von aeroview.de folgende Fehlermeldung:

Die Festplatte des Servers ist anscheinend wieder voll.

Oh, das ist aber ich schön…

Also wäre die folgende Lösung besser?

for i in /data/jpg/*.jpg; do filename=$(basename $i); /usr/local/bin/gdal_translate -of GTiff -co COMPRESS=JPEG -a_srs epsg:31467 $i /data/tif/${filename%.*}.tif; done;
/usr/local/bin/gdal_merge.py -v -of GTiff -co COMPRESS=JPEG -co TILED=YES -o /data/epsg-31467_tiled.tif /data/tif/*.tif
/usr/local/bin/gdaladdo --config COMPRESS_OVERVIEW JPEG /data/epsg-31467_tiled.tif 2 4 8 16 32 64 128 256

Mit folgendem Eintrag im Mapfile:


PROJECTION
    "init=epsg:31467"
    "nadgrids=/mapserver/data/BETA2007.gsb"
END

Also sein gekacheltes GeoTiff in EPSG3146x mit Auflösungspyramide und BeTA2007 Korrekturdaten im Mapfile.

Habe mir übrigens für die obigen Befehle GDAL 1.8.1 gebaut und verwendet, das erstellt die Dateien jetzt deutlich schneller. :slight_smile:
So habe ich das unter Debian Squeeze gebaut:

$ ./configure --prefix=/usr/local --with-threads --with-ogr --with-geos --without-libtool --with-libz=internal --with-libtiff=internal --with-geotiff=internal --with-png=internal --with-jpeg=internal --with-gif=internal --with-python --without-pg --without-grass --without-libgrass --without-cfitsio --without-pcraster --without-netcdf --without-ogdi --without-fme --without-hdf4 --without-hdf5 --without-jasper --without-ecw --without-kakadu --without-mrsid --without-jp2mrsid --without-bsb --without-grib --without-mysql --without-ingres --without-xerces --without-expat --without-odbc --without-curl --without-sqlite3 --without-dwgdirect --without-idb --without-sde --without-perl --without-php --without-ruby

$ make

# checkinstall -D make install

# echo "/usr/local/lib" >> /etc/ld.so.conf
# ldconfig

Ich habe jetzt von “towgs84=…” auf BeTA2007 umgestellt, das hat aber keine Änderung bewirkt.
Scheint also schon nahe am Optimum zu sein.

Der entsprechende Eintrag im Mapfile sieht jetzt so aus:


PROJECTION
    "init=epsg:31467"
    "nadgrids=/mapserver/data/BETA2007.gsb"
END

Gruß,
Mondschein