Luftbilder von Aerowest

Communities Deutschland (Germany)
62

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

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

65

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

66

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

67

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

68

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

69

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

70

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

72

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

73

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

st

74

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.

75

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

76

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

77

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.

78

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

79

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

80

Nein.

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

Unwahrscheinlich, dass der Speicherplatz automatisch wieder freigegeben wird.

Gruß,
Monschein

81

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

Gruß,
Mondschein

82

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.

83

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