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

$ 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

Ciao,
Frank

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

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.
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

Hi,

da mir das Plugin nach wie vor nur gequetschte Bilder bietet, habe ich mal den Geoserver von
http://geoserver.org/display/GEOS/Download
als lokalen WMS verwendet. Ob der besser oder schlechter als mapserver ist, kann ich nicht beurteilen. Hier meine Anleitung:

Einbindung von Aerowest-Luftbildern in Josm über eigenen Geoserver-WMS

Hier gezeigt für Bilder aus Westdeutschland (Gauß-Krüger Zone 2 EPSG:31466)

Start/Programme/Geoserver 2.1.1/Geoserver Web Admin Page
username:admin ->Login
oder http://localhost:8080/geoserver/web

linke Spalte:
(DE) Data
(DE) Workspaces
+ Add new workspace
(DE) Name: Aerowest
(DE) Namespace: http://opengeo.org/aerowest
(x) Default Workspace

Linke Spalte:
(DE) Stores
+ (DE) Add new Store
(DE) Raster Data Sources ->WorldImage
(oder GeoTiff wenn man bereits in diese umgewandelt hat)
->neue Seite
(DE) Data Source Name: Aerowest 31466
(DE) URL ->Browse... -> Im Dateisystem jpg-Datei auswählen
(DE)Save
->neue Seite
->Publish

(DE) Declared SRS -> (DE) Find...
(DE) Search ->31466 Enter
auf 31466 vorne in der zeile klicken

(DE Bounding Boxes
Link (DE) Compute from data
Link (DE) Compute from native bounds

(DE) Save

Linke Spalte:
(DE) Data
->Layer Preview
In der Zeile mit Aerowest:31466 auf Link Openlayers klicken
dann sollte das Bild in Gauß-Krüger-Koordinaten erscheinen

Josm Starten
Symbol mit Schaltern
Symbol WMS TMS
rechts auf das Plus

Menüname: Aerowest 31466
Service_URL: http://localhost:8080/geoserver/wms?
->Ebenen abfragen
auf das + vor Geoserver Web Map Service klicken
31466 auswählen
OK
OK

Daten laden (vom server oder lokal)
Hintergrund -> Aerowest 31466

Das Laden des Hintergrundes dauert einige Zeit, eventuell fehlende Kacheln mit Rechtsklick auf die Bildebene 
-> fehlerhafte Kacheln nachladen

Das Laden geht schneller, wenn man die jpg-datei in geotiff umwandelt.
Die Projektion in Josm braucht nicht auf WGS84 geändert werden, funktioniert aber auch dort. Nach dem Umschalten muß man allerdings die alte WMS-Ebene löschen und neu abrufen.

moin moin,

ich verfolge diesen Thread eigentlich nur noch um zu sehen, ob jemand einen praktikable Lösung für die Sache findet.
Ihr dreht da an allen möglchen Koordinatentransformationen mittels diverser Tools rum und parallelel ändert irgendwer (wer?) dauernd den Plugin.

Ist es denn schon jemanden gelungen, mit den Autoren des Plugin in Kontakt zu kommen?
Da wären doch alle Anpassungen bestens aufgehoben.

gruss
walter

p.s. auf der mailing-liste ist das thema anscheinend tot.

Hi !

ich habe das mit dem Geoserver gerade mal ausprobiert anhand meines Beispiels aus Ostrohe.

Das Ergebnis ist zu finden unter http://www.tappenbeck.net/forum/osm/aerowest_ostrohe_geoserver.jpg

Sieht ja ganz gut aus - aber paßt auch nicht mit dem Haus von Kellerma (in JOSM rot!) überein !!!

Versuchte mal eine Katasterkarte zu bekommen um einen Vergleich zu haben.

Einige Fragen ergeben sich jetzt aus der Beschreibung #164 (ajoessen):

• ->Layer Preview … den Punkt habe ich nicht finden können !
• hast Du das schon mal ausprobiert mehrere GK-Streifen gleichzeitig einzubinden ?
• ich muss ja explizit eine Bilddatei zuweisen - wie machst Du das mit meheren - alle zu einem verschmelzen ?

Allgemein: gibt es schon einen Ansatz größere Bilder zu downloaden oder … ? Ansonsten ist es sehr müßig !

Edit: hier noch der Vergleich zu Bing: http://www.tappenbeck.net/forum/osm/aerowest_ostrohe_geoserver_vergleich_bing.jpg
Edit2: und nochmal zum Katasturm http://www.tappenbeck.net/forum/osm/aerowest_ostrohe_geoserver_vergleich_kataster.jpg - habe für die Orientierung den Gewerbebau oben Rechts angehalten und siehe da die anderen Häuser aus dem lokalen Geoserver passen. Bitte die Urheberrechte entsprechend zu achten.

Gruß Jan .-)

was nun “richtig” ist weiß ich auch nicht. Wer garantiert denn, dass die Aerowest-Bilder besser georeferenziert sind als die von bing? Nebenbei hast du mit dem WMS (im Gegensatz zum Plugin) die Möglichkeit, in josm einen Versatz anzugeben.

steht bei mir in der linken Spalte von geoserver als erster Punkt unter (DE) Data

Nein, noch nicht. Hab ja auch nur den halben gestrigen Abend nutzen können, nachdem ich mit dem Plugin keine Erfolge hatte.

So im groben: Mit dem gleichen Dateinamen für das Bild müsste man nur die bounding boxes neu ermitteln lassen.

Quantum GIS kann mehrere Aerowest-Bilder zusammensetzen. Irgednwie soll das auch als lokaler WMS-Server konfigurierbar sein. hab ich aber nich nicht ausprobiert.
Wenn du mit “mehrere” GK-Streifen meinst, GK Zone 2 und Zone 3 zusammen auf dem Bildschirm, wird das möglicherweise nicht funktionieren. Zumindest ist mit Überschneidungen zu rechnen. Hat Aerowest den nicht für jedes Luftbildgebiet eine einheitlichen GK-Zone genommen?

Gruß,
ajoessen

hi !

ich muss mal sehen - für Lübeck habe ich die Schachtkoordinaten der Kanalisation als Referenz. Müssen wir die nächsten Tage mal vergleichen.

… und wie ist es mit einer Idee größere Datenbereich zu bekommen ?? Sonst heißt es 1000x mal heruntergeladen und immer noch keine Fläche zusammen - … und es hat zoom gemacht !! .-)

Gruß Jan

So wie es aussieht scheint der JOSM Import der Aerowest nicht zu funktionieren…
Meine Bitte wäre - wenn eine Lösung erarbeitet worden ist, wieder eine Komplettanleitung zu posten.

Ich möchte es gerne nutzen, hab aber ehrlich gesagt keinen Nerv Stunden rumzuprobieren, oder mich durch 168 Posts mit Ideen zu kämpfen.
Auch, weil mir einfach die Kenntnisse fehlen. Ich möchte Mappen, nicht entwicklen

Und - Danke an alle, die den Nerv HABEN, sich da durch zu kämpfen…

Gruss
Sonny76

Moin Walter,

Nö, an dem Plugin wird nicht rumgedreht (das ist ja das Problem!), sieht man auch im svn das sich die Versionsnummer nicht ändert.
Ändern tut sich der JOSM und das Plugin ist scheinbar sehr “empfindlich”

Autoren von Plugins finden sich auf http://josm.openstreetmap.de/wiki/Plugins
Im Fall von ImportImagePlugin wärens:
Christoph Beekmans, Fabian Kowitz, Anna Robaszkiewicz, Oliver Kuhn, Martin Ulitzny

Hab mir schon mal gedacht, ich schreib an josm-dev, ob Dirk/Paul/Frederick mal drüber schauen könnten …

Ciao,
Frank

Ich weiß ja nicht, welcher frederik da zugange war:
https://github.com/openstreetmap/josm-plugins/tree/master/ImportImagePlugin/src

Gruß,
ajoessen

Das war der “Sprung” auf 26413, wahrscheinlich von “unserem” Frederik"
Aber es reicht halt nicht (z. B. für Windows).
Entwickelt scheinbar hat es die “Skobbler-Truppe” im letzten Jahr …

Ciao,
Frank

Ich hab jetzt noch mal ein weiteres Ticket aufgemacht:

http://josm.openstreetmap.de/ticket/6665

Gibts noch mehr Defekte außer dem Versatz, dessen Urheberschaft noch unklar ist?

Gruß,
ajoessen

hi !

habe das mit dem geoserver nochmal für Lübeck ausprobiert - anderer GK-Streifen - und das macht auch einen guten Eindruck.

http://www.tappenbeck.net/forum/osm/aerowest_ostrohe_geoserver_vergleich_bing_luebeck.jpg

Die zwei Kontrolllinien (siehe blauer Pfeil) sind von Bing abgezeichnet und sichtbar ist Aerowest.

Gruß Jan

Danke für die Info. Werd mir mal den neuesten Josm per svn besorgen und das nochmal ausprobleren.

Gruss
Walter

@ajoessen: hast Du eigentlich es schon einmal hinbekommen eine Geoserver mit einer neuen Kachel für denselben Bereich zu füttern ? Bei mir lassen sich irgendwie die Grenzen nicht neudefinieren !!!

Jetzt nach einem Rechner-Neustart ist alles ROT !

Gruß Jan

Hi,

nach ein bisschen Rumgesuche würd’ ich sagen, “ImportImagePlugin” benutzt die “geotools” und insbesondere
http://svn.osgeo.org/geotools/trunk/modules/plugin/epsg-wkt/src/main/resources/org/geotools/referencing/crs/epsg.properties

Unter 31467 (und auch 31466/8/9 ) finden wir
TOWGS84[612.4, 77.0, 440.2, -0.054, 0.057, -2.797, 2.55]
Das ist
“Germany (Sachsen)” “Accuracy <1m”
und erklärt die “1 m Abweichung”, zuminderst in Nürnberg

Doch testet selbst

Ciao,
Frank