Luftbilder von Aerowest

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: )

Danke!

Jetzt funktioniert das auch bei mir. :smiley:

Verwendet habe ich JOSM 4277.

  1. “Merkator” unter “Bearbeiten → Einstellungen → Karten-Einstellungen → Projektionsmethode” einstellen

  2. ImportImagePlugin Version 26413 installieren

  3. JOSM neu starten

  4. Im JOSM-Verzeichnis unter plugins/ImportImagePlugin/pluginProperties.properties steht bei mir:

    default_crs_srid=EPSG\:31467
    libraries=<nicht verÀndert>
    default_crs_eastingfirst=true
    
  5. Das von Aerowest heruntergeladene Bild (jpg- und die zugehörige jgw-Datei mĂŒssen im selben Verzeichnis liegen) mit gdal_translate oder gdalwarp umwandeln:

    gdal_translate -a_srs epsg:31467 -of GTiff exportimg.jpg bild.tif
    
    gdalwarp -s_srs epsg:31467 -of GTiff exportimg.jpg bild.tif
    

    Verwendet habe ich “GDAL 1.5.2, released 2008/05/29” aus Debian Lenny.

  6. Entweder vor dem Importieren des Bildes eine neue Datenebene ĂŒber “Datei → Neue Ebene” erstellen oder die Kartendaten des Bereichs herunterladen, in welchem sich das Bild befindet oder nach dem Importieren des Bildes die Kartendaten des Bereichs herunterladen, in welchem sich das Bild befindet.
    Denn sonst wird das Bild nicht sichtbar.
    Und das Bild ĂŒber “Datei → Import image” importieren.

  7. Daten erstellen und Hochladen. :slight_smile:

Hinweis:
Zu beachten ist, dass ich hier bei gdal_translate und ImportImagePlugin jeweils EPSG 31467 (= DHDN / Gauß-KrĂŒger Zone 3) angegeben habe, da dies beim Herunterladen des Bildes von Aerowest angezeigt wurde.
Der Quell-EPSG-Wert muss also evtl. angepasst werden.
Andere Bilder mit Koordinatensystemen oder Zonen kann ich derzeit nicht ausprobieren, da die Aerowest-Seite z.Zt. nicht funktioniert.

“gdalinfo bild.tif” zeigt an:

Gruß,
Mondschein

Sieht nach “WGS 84” aus, da die GebĂ€ude alle schief aussehen.
Ich empfehle dringend “Merkator” zu verwenden.
Wie das funktioniert, wurde hier heute gezeigt.

Gruß,
Mondschein

mal ne “ketzerische” Frage in die Runde:

soll das etwa so bleiben?
da muss es doch eine lösung geben, die der grossen masse der mapper eine chance gibt, die aerowest-bilder auch zu nutzen.

ich krieg das wohl auch noch hin, aber was ist mit oberförster und co? :wink:

gruss
walter

Mir ist das auch zu umstĂ€ndlich. Somit warte ich auf ein “richtiges” JOSM WMS Plugin.

st

Zustimmung
mal fĂŒr ein Dorf mag es gehen
aber in der Zeit, in der ich dann ein Dorf gemappt hab, hab ich in einem anderen Land mit guten Bing-Bildern deutlich mehr gemappt und das sind dann meiner Meinung nach auch wichtigere Infos, als die GebĂ€ude etc.

Ich habe folgende interessanten Entdeckungen gemacht:

  1. Mit (siehe kellerma bzw. meine Anleitung)

    gdal_translate -a_srs epsg:31467 -of GTiff exportimg.jpg bild.tif
    

    oder

    gdalwarp -s_srs epsg:31467 -of GTiff exportimg.jpg bild.tif
    

    sieht das erzeugte GeoTiff in einem Bildbetrachter genauso aus, wie das Original-JPEG (somit auch ohne schwarze Bereiche am Rand).
    Erst in JOSM wird das Bild transformiert angezeigt, das sieht man an den dadurch entstehenden schwarzen Bereichen am Rand des Bildes.

  2. Mit

    gdalwarp -s_srs epsg:31467 -t_srs epsg:900913 -of GTiff exportimg.jpg bild.tif
    

    sieht das Bild ĂŒbrigens auch schon im Bildbetrachter transformiert aus und zwar genau so, wie es bei 1.) in JOSM aussieht, lĂ€sst sich dann aber nicht in JOSM importieren:

  3. Mit

    gdalwarp -s_srs epsg:31467 -t_srs epsg:3857 -of GTiff exportimg.jpg bild.tif
    

    kann meine GDAL-Version nichts anfangen, ist nicht aktuell genug.

Gruß,
Mondschein

Hallo,
der Server von Aerowest hat scheinbar den Ansturm der OSM User nicht standgehalten. Er ist down. Weis jemand ob an dem Problem gearbeitet wird?
Ciao Holger

Admins arbeiten 24/7 - Das Problem dĂŒrften eher zu kleine Server sein, da der Ansturm am Anfang sicher gigantisch ist. Wenn Aero-West sagt “Warten wir 2 Wochen das gibt sich schon”, dann kann man das denen auch nicht böse nehmen. Denn mehr Server = Mehr Kosten. Und wenn es jetzt wirklich nur die “Neugierde” am Anfang ist


Wobei, wenn es ein perfektes JOSM-Plugin gibt (Eins, welches die Bilder automatisch runter lĂ€dt und einbindet) dĂŒrfte der Ansturm noch grĂ¶ĂŸer werden.

Da ist wohl die Festplatte voll:

Evtl. wurden zu viele Logs oder evtl. sogar alle erzeugten ZIP-Dateien auf der Festplatte gespeichert
 :roll_eyes:

Gruß,
Mondschein

Wer automatisch mehrere JPEG-Dateien transformieren möchte (Shell):

EPSG=31467; for i in *.jpg; do gdalwarp -s_srs epsg:$EPSG -of GTiff $i ${i%.*}.tif; done;

EPSG evtl. anpassen.

Gruß,
Mondschein

Nein.

Eher eine zu kleine Festplatte oder was ich hier eher vermute: Inkompetenz.

Unwahrscheinlich, dass der Speicherplatz automatisch wieder freigegeben wird.

Gruß,
Monschein

Der Server funktioniert jetzt wieder.
Es kann weiter gehen. :slight_smile:

Gruß,
Mondschein

Okay, wenn die Festplatte voll ist, dann ist das ein Problem.

Es seie ihnen verziehen, es war sicher das erste mal, daß die Admins, (oder der Admin) ihre Daten fĂŒr eine so große Usermenge freigegeben haben. Jeder lernt nur mit der Erfahrung. Und ich gebe zu, ich wĂŒrde die Zips auch im Temp-Dir speichern und ein Cron um Mitternacht wĂŒrde alle 2-Tage-alten Zips löschen. Wenn das Sytem seit Monaten schon fĂŒr die Dresden (?) Bilder oder fĂŒr einzelne ausgewĂ€hlte User verwendet wird, und es seit Monaten schon einwandfrei funktioniert, dann wurde vermutlich nur ein neues User “OSM” mit angelegt. Es ist hier ja nicht Google mit Millionen Usern gleichzeitig sondern es ist Aero-West die das erste mal Fotos fĂŒr uns freigegeben haben.

Ich wette, das Handy vom Admin ist schon “explodiert”, erst die System-Warn-SMS, dann die SMS vom externen Dienstleister, Anrufe vom Vorgesetzten, evtl. sogar vom Chef. Und dann die lieben Kollegen, die alle die Kurzwahl vom Admin kennen
 Jeder ruft nach 10 Sekunden an “Da kam ein Popup, und nur reagiert Outlook nicht mehr” 
 Wenn er selber gerade mit der Family auf einem Samstagsausflug ist, kommt er sicher ein wenig in Panik, wer jetzt wichtiger ist, die Family mit Kindern oder die OSM-User mit der “Disk Full” Message.


 15 Minuten SpÀter: Schon wieder Down alles 
 aber ich konnte nen Screenshot erstelen, es sind neuere Bilder als in Google-Maps vorhanden.

Moin moin,

solange “aeroview.de” noch nicht verwendbar ist, fassen wir unsere “Hausaufgaben” zusammen:

A) Das ImportImagePlugin des JOSM wird geflickt, insbesondere
A1) sein riesiger Speicherverbrauch, was das Teil unglaublich langsam macht
A2) georeferenzierte jpegs können direkt mit JOSM (dort dann in Mercator-projektion) verarbeitet werden, sodass die vorausgehende Umwandlung nach (Geo)Tiffs durch gdal_translate/gdalwarp/etc. entfÀllt.
Ein ticket hab’ ich schon eröffnet, weitere könnten vielleicht die Aufmerksamkeit erhöhen :wink:

B) Anleitung fĂŒr das Bearbeiten der Bild- sowie osm-Daten direkt in QGIS
B1) Hat qgis die "Q-Funktion"von JOSM (HĂ€uschen rechteckig machen)? Ein nochmaliges Bearbeitung hierfĂŒr in JOSM ist zu umstĂ€ndlich.

C) Schritt-fĂŒr-Schritt-Anleitung fĂŒr Aufsetzen eines lokalen (127.0.0.1) WMS-Servers
Im Falle von z. B. mapserver also incl. mapfile und URL zum Eintragen in JOSM etc.
C1) Leute wie Mondschein und ich mĂŒĂŸten ihre GDAL-Tools auf Vordermann bringen, damit die Umprojezierung von 31466/31467/31468 nach 3857 problemlos klappt.

D) Aerowest/someoneelse bietet einen globalen/regionalen WMS-Dienst an

Ciao,
Frank