Luftbilder von Aerowest

Ich habe die gdal-Diskussion nur grob verfolgt, v.a. weil ich von dem Tool keine Ahnung habe, daher folgende etwas naive Frage:

Führt die gdal-Trickserei auf ein Bild, daß sich auch mit dem PicLayer-Plugin verwenden läßt und korrekte Referenzierung dafür enthält? Oder sieht jemand eine andere Möglichkeit, die Aerowest-Bilder PicLayer-tauglich zu bekommen? Wenn ja, kann dafür mal jemand eine halbwegs idiotensichere Anleitung schreiben?

Leider ist das ImportImagePlugin bei mir unheimlich langsam und speicherhungrig, mal abgesehen von seinen übrigen Bedienschwächen. (Schon allein, daß es sich nicht das zuletzt geöffnete Verzeichnis merken kann…) Seit ich das Plugin installiert habe, stößt JOSM beim Hochladen regelmäßig an seine Speichergrenzen. Speichern geht noch, Hochladen nicht mehr (vermutlich, weil der zuvor auszuführende Validator dann nicht mehr in den Speicher paßt). Vor Installation des Plugins hatte ich dieses Problem nie, auch nicht mit der aktuell installierten JOSM-Version. “Erfolgreich” reproduziert auf mehreren Rechnern, darunter ein Phenom II X4 mit 4 GB RAM.

Der Extremfall war vorhin, als ich ein paar Hektar Stadtgebiet heruntergeladen und eine einzige Relation angelegt habe - mit aktivem Plugin, aber ohne ein Bild zu laden (!), und beim Hochladen die wohlbekannte Nachricht “JOSM is out of memory” bekam. JOSM belegte da 848 MB Arbeitsspeicher bei einem geladenen Gebiet, das als .osm-Datei etwa 2 MB groß ist…

Nein, die PicLayer Kalibrierungsdatei ist ein Eigengewächs. Was Du machen könntest, wäre mit dem ImageLayerPlugin 4 Referenzpunkte setzen, dann das Bild in Mercator umwandeln, mit PicLayer öffnen und an die richtige Stelle schieben. Aber befriedigend ist das nicht.

Ja, hab ich - aber Du anscheinend deine Tappenbeck-Family-Mail noch nicht abgerufen, da habe ich geantwortet, als heute vormittag OSM hakte. :wink:

Ich kann beim Plugin Ver. 26413 kein 90°-Problem feststellen, funzt ganz normal und wie gewünscht (JOSM 4223).

Nein, sieht es nicht. Bei Dir ist das Bild nicht gedreht, aber anscheinend mit der Projektion 3146 projiziert, dann sieht jedenfalls Dein Ausschnitt bei mir auch so aus.
Prüfe bitte nochmal Dein “Source Reference System” im Plugin und stell es ggf. neu ein wie in Post #10 beschrieben.

Gruß
Georg

hi Georg,

ich habe mir das nochmal angesehen und auch mit http://www.tappenbeck.net/forum/osm/aero_bilder_31467.jpg sieht das sch… aus.

ersetze bei einer eMail bitte die FAMILIE durch OSM!

Gruß Jan :slight_smile:

Sieht es besser aus, wenn der Haken bei Easting first raus ist?

Gruß,
ajoessen

so, ich hab -mal wieder- openjdk rausgeschmissen und fahre jetzt mit sun-java.
es funktioniert endlich.

Gruss
walter

hi !

was soll den Easting first überhaupt bedeuten ??

gruß Jan :slight_smile:

Vermutlich, dass die Angabe der Ostrichtung vor der der Nordrichtung erfolgt. Siehe http://en.wikipedia.org/wiki/Easting_and_northing

Hi Jan,

nein, nur ungewohnt.

Hab Deinen Ausschnitt mal angeschaut: Und es funktioniert (JOSM 4276, ImportImagePlugin 26413), wie von Georg beschrieben:

Hab mir erlaubt, ein kleines Häuschen abzumalen :wink:

Ciao,
Frank

hi !

ich habe nochmal josm geupdatet - auch die version vom plugin verglichen und auch alles wiederholt.

mit dem east-flag stehe ich auf dem Kopf und ansonsten lande ich in arabien !!!

…???

gruß Jan :slight_smile:

Hi,

mit der neuen Plugin-Version 26413 hatte ich auch keine gute Erfahrung => Rücksprung zu 26174.

Meine Datei “pluginProperties.properties” schaut so aus


#Fri Jul 29 20:03:37 CEST 
<snip>
default_crs_srid=EPSG\:31467
default_crs_eastingfirst=true

Ciao,
Frank

hi !

… und wie bist du auf diese zurückgekommen ? ist es nicht so, dass immer mit einem josm-update auch die plugins neu gezogen werden !!!

Edit: das ist wohl mehr als ungewohnt !!! http://www.tappenbeck.net/forum/osm/aero_bilder_31467_2.jpg

Edit2: bevor ich jetzt immer etwas übergehe frage ich lieber nochmal nach: nach dem image laden wird immer nach einer projektionsdatei gefragt; die habe ich bisher immer ignoriert !!!

gruß Jan :slight_smile:

Sicherheitskopie, mein Lieber!


-rw-r--r--  1 user user 10399379 29. Jul 19:38 ImportImagePlugin.jar26174
-rw-r--r--  1 user user 10396675 29. Jul 20:24 ImportImagePlugin.jar26413

Ah, mein Häuschen, passt perfekt, mit der richtigen Projektion :wink:

Ciao,
Frank

EDIT
Die Meldung
“No projection file (.prj) found.
Use the default Coordinate Reference System instead?”
mit “Ja” beantworten (dazu sollte 31467 auch Dein Default sein).

hi !

kannst Du mir mal einige screenshoots von den einstellungen mailen ???

kurzform von openstreetmap @ tappenbeck Punkt - englische Bezeichnung für Netz

Gruß Jan :slight_smile:

Hört sich gut an 3857 entspricht auch 900913. Super, Du hast das Problem gelöst


# WGS 84 / Pseudo-Mercator
<3857> +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext  +no_defs <>

#Google
<900913> +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +no_defs <>

Man soll den Abend nicht vor Mitternacht loben :wink:

Hab’ bei mir mal in Nürnberg (und somit mit 31468) getestet:
Version 26174 geht nicht, bringt nur lauter “Error: NaN in greatCircleDistance”
Version 26413 schaut schon besser aus, Geometrie scheint zu stimmern, aber ca. 150 m nordöstlicher Versatz.

Mmmh …

Ciao,
Frank

EDIT:
Welche gdalwarp-Version benutzt Du?
Meine Debian 6 ist schon betagt:
$ gdalwarp --version
GDAL 1.6.3, released 2009/11/19

an gdal sollte es nicht liegen. Gdal wird von so vielen benutzt, dass da ein Fehler recht schnell beseitigt wäre. Und umprojezieren sollte für gdal in etwas sowas sein, wie für uns eine residential Straße einzeichnen, also Tagesgeschäft

Also es lag doch an gdal (in einem gewissen Sinne :wink:

Auf meinen System werden die defs nicht richtig angezogen:


$ gdalinfo ergebnis.tif 
Driver: GTiff/GeoTIFF
Files: ergebnis.tif
Size is 2990, 2137
Coordinate System is:
PROJCS["unnamed",
    GEOGCS["unnamed ellipse",
        DATUM["unknown",
            SPHEROID["unretrievable - using WGS84",6378137,298.257223563]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    AUTHORITY["EPSG","3857"]]
Origin = (1243991.927688059629872,6355015.164821581915021)
Pixel Size = (0.097630155625427,-0.097630155625427)
<etc etc etc>

Hab nun die libgeotiff nachinstalliert (Bäh non-free!), hat aber nix geholfen.

Erst ein Konvertierung via
gdal_translate -a_srs epsg:31468 -of GTiff exportimg2011729195139255566.jpg b.tif
hat geholfen:


$ gdalinfo b.tif 
Driver: GTiff/GeoTIFF
Files: b.tif
Size is 2970, 2099
Coordinate System is:
PROJCS["DHDN / Gauss-Kruger zone 4",
    GEOGCS["DHDN",
        DATUM["Deutsches_Hauptdreiecksnetz",
            SPHEROID["Bessel 1841",6377397.155,299.1528128000008,
                AUTHORITY["EPSG","7004"]],
            AUTHORITY["EPSG","6314"]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433],
        AUTHORITY["EPSG","4314"]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",12],
    PARAMETER["scale_factor",1],
    PARAMETER["false_easting",4500000],
    PARAMETER["false_northing",0],
<etc etc etc>

=> man kann die Einstellung auf “Merkator” lassen.

Supi mmd!

Ende gut, alles gut :slight_smile:

Ciao,
Frank

Könnte jemand das offensichtlich ältere aber fehlerfreie Plugin zum download anbieten?

Hi, ich hab mir mal ein paar Bilder von der Seite gespeichert und wie in der Anleitung auf Seite 2 eingebunden.

Da ich noch relativ neu mit der Materie bin wollte ich mal ein paar der erfahreneren Leute drüberschauen lassen…

Wenn ich die Wege und einige Objekte im gesamten so vergleiche denke ich mal das die Bilder georaphisch passen und ich halt die “fehlerhaft” einzeichneten Gebäude einfach nun korrigieren kann oder?!

Klicken zum Vergrößern ( :wink: )