Luftbilder von Aerowest

Das sind ja sehr schöne Neuigkeiten. Hier habe ich schon mal ein tolles Plugin gefunden: http://wiki.openstreetmap.org/wiki/JOSM … magePlugin
Allerdings mangelt es derzeit noch an einer prj. damit man mit den Koordinaten etwas anfangen kann.

Klasse Bilder 😎
Leider ist mein Landkreis nicht dabei 🙁
Aber endlich kann ich die Bienenhütte meines Vaters aus 500 km Entfernung lagegenau mappen 😉

hurdygurdyman wrote:

Klasse Bilder 😎
Leider ist mein Landkreis nicht dabei 🙁

gratuliere,

leider krieg ich das teil bei mir auf die schnelle nicht ans rennen.

ist als java-applett erstellt und will bei mir -noch- nicht. ubuntu 11, java openjdk-6, ff-5
Da "meine" Ecke eh nicht dabei ist, werd ich mich irgendwann mal drum kümmern - oder auf 'nen wms-server warten

Gruss
Walter

wambacher wrote:

leider krieg ich das teil bei mir auf die schnelle nicht ans rennen.

ist als java-applett erstellt und will bei mir -noch- nicht. ubuntu 11, java openjdk-6, ff-5

Sitze gerade an einer "powered by Bill Gates"-Kiste. Werde das dann heute abend unter ubuntu 10.10 mal probieren.

Die Bilder sehen wirklich gut aus.

Übrigens: .jgp = .wld

Passende .prj findet man unter http://spatialreference.org/.

Für die Hannover-Luftbilder beispielsweise: http://spatialreference.org/ref/epsg/31467/

Leider schmiert mir das ImportImagePlugin-Plugin mit einer Reprojections-Exception ab... Vielleicht bin ich heute abend schlauer.

Grüße,
Micha

Moin,

hofoen wrote:

Übrigens: .jgp = .wld

Eher *.jgw = *.wld für JPEG-Bilder.

hofoen wrote:

Passende .prj findet man unter http://spatialreference.org/.

Für die Hannover-Luftbilder beispielsweise: http://spatialreference.org/ref/epsg/31467/

Leider schmiert mir das ImportImagePlugin-Plugin mit einer Reprojections-Exception ab... Vielleicht bin ich heute abend schlauer.

Mit der von Dir genannten *.prj Datei bei mir auch.
Aber EPSG 31467 ist als Standard-Projection im Plugin vorgewählt (aus der Unzahl bereits implementierter).
Und damit funktioniert es bei mir auch ohne *.prj Datei.

Andere Projektionen kann man sich in der Liste der implementierten heraussuchen und einstellen.
Die integrierte Suche sucht aber von links nach rechts - und bleibt dann bei 3146 stecken, man muss in der Liste manuell suchen, sie ist nach den EPSG-Werten aufsteigend sortiert.

Edit:
ACHTUNG: In JOSM muss auf die Projektionsmethode "WGS84 geografisch" umgestellt werden - mit den zu beachtenden Auswirkungen (Kreise und rechte Winkel)!

Gruß
Georg

hurdygurdyman wrote:

Klasse Bilder 😎
Leider ist mein Landkreis nicht dabei 🙁

Dem kann ich mich 100%ig anschließen.

Wie wäre es, wenn ihr das jetzt noch mal so erklärt, dass jeder weiß, was er mit den beiden Dateien machen soll, um sie in josm richtig zu sehen. 😉

Na gut, dann nochmal als Liste, aber von Anfang an:

- Im Browser http://www.aeroview.de/aerowest_IWS/ind … wd=osmonly aufrufen
(Oder von der Hauptseite http://www.aerowest.de aus heranhangeln und sich entsprechen mit Benutzer "osm" und Passwort "osmonly" einloggen)
- Bildausschnitt wählen
- Unten rechts den EPSG-Wert merken (wird für die Projektion bei JOSM benötigt)
- Auf den Button "Bildansicht als Georeferenzierte JPEG speichern" klicken
(Icon: Kamera mit blauer Sprechblase oder so neben "Hausnummer")
- Das Zip-Archiv abspeichern, so dass man es wiederfindet (ich kenn' da so ein paar Experten ...)
- Das Zip-Archiv auspacken, beide Dateien müssen im gleichen Verzeichnis sein (und den gleichen (Vor)Namen tragen!)

- In JOSM das ImportImagePlugin installieren
(Dessen "Source Reference System" ist standardmäßig auf EPSG 31467 eingestellt)
- In JOSM in den Einstellungen die Projektionsmethode auf "WGS84 geografisch" umstellen
(Bei der Arbeit dann unbedingt die entsprechenden Auswirkungen auf Kreise und rechte Winkel beachten!)
- JOSM Neustart nicht vergessen

- In JOSM Menü "Datei" - "Bild importieren" auswählen
- Die gewünschte Bilddatei (*.jpg) laden

Sollte die Projektion bei Aerowest von EPSG 31467 abweichen:
- In JOSM im Ebenendialog bei der Image-Datei rechte Maustaste - "Ebenen-Eigenschaften" auswählen
- Im Dialog den Reiter "Source Reference System" auswählen
- Den EPSG-Code in das Suchfeld eingeben und ENTER-Taste drücken, dann den markierten Listen-Eintrag.
Oder in der Liste den erforderlichen EPSG-Code auswählen (ist nach Codewerten sortiert).
- In den meisten (allen?) Fällen muss noch "Easting first" ausgewählt werden
- Anwenden ("Apply selection"), ggf. vorher "Set as default" - je nachdem, ob man die Projektion öfter braucht.

Deutlich schöner wäre es, wenn das ImportImagePlugin auch "Merkator" als Ausgang bieten würde, denn so ist es etwas umständlich Gebäude abzuzeichen und rechtwinklig zu machen, da man ja ständig zwischen den Projektionsmethoden umschalten muss!

Gruß
Georg

Edit:
- URL korrigiert
- Nachsatz Dateinamen
- EPSG-Code Suche korrigiert

GeorgFausB wrote:

- In der Liste den erforderlichen EPSG-Code auswählen (die Suche funzt nicht ganz richtig, die Liste ist aber nach Codewerten sortiert) und anwenden
(Entweder "Apply selection" oder "Set as default" - je nachdem, ob man die Projektion öfter braucht)

Wenn man nach der Eingabe des EPSG-Codes Enter drückt, klappt auch die Suche.

Bei mir (Aachen/31466) war auch noch "Easting first" nötig.

Hallo Georg, danke für die Anleitung.
für Erfurt musste ich auf 31468 umstellen. Allerdings landet das Bild im Meer westlich der Türkei. Hast du eine Ahnung, woran das liegen könnte?

EDIT: Der Tip von Oli-Wan war richtig...easting first hat das Problem gelöst.

Gibt es auch eine Möglichkeit die Bilder mit der Merkator Projektion in JOSM einzubinden?

Oli-Wan wrote:

GeorgFausB wrote:

- ... (die Suche funzt nicht ganz richtig, die Liste ist aber nach Codewerten sortiert) ...

Wenn man nach der Eingabe des EPSG-Codes Enter drückt, klappt auch die Suche.

Ah, danke, die hat ich nicht probiert, da
- die Suche bereits bei der Eingabe loslief
- ich die ENTER-Taste automatisch mit dem OK-Button verknüpfe ...
- und "Search" gar kein Button ist ...

aighes wrote:

Allerdings landet das Bild im Meer westlich der Türkei. Hast du eine Ahnung, woran das liegen könnte?

"Easting first" setzen.
Bei meinem ersten Laden klappte es auf Anhieb, anscheinend ist auch dort "Easting first" voreingestellt.
Beim manuellen Setzen ohne "Easting first" landete ich auch im Nirwana.

Gruß
Georg

GeorgFausB wrote:

Ah, danke, die hat ich nicht probiert, da
...

Ja, hat bei mir auch etwas länger gedauert, bis ich dahintergekommen bin.

Die Luftbilder sind jedenfalls ein Kracher. Vielen Dank an die Dortmunder Kollegen, die den Deal eingefädelt haben!

Gibt es irgendeine Möglichkeit, in JOSM per Symbolleisten-Button oder Tastenkürzel zwischen Projektionen umzuschalten? Also eine Art Makro?

Dem Dank kann ich mich nur anschließen...auch an alle, die für das Projekt gevoted haben.

Was bei dem josm-Plugin noch super Verbesserungen wären:
- mehrere Bilder auf einmal importieren
- den schwarzen Rand, der bei der Projizierung entsteht transparent machen (ja ich weiß, jpg unterstützt keine Transparenz, aber evtl. lässt sich da ja was machen)

aighes wrote:

Dem Dank kann ich mich nur anschließen...auch an alle, die für das Projekt gevoted haben.

+1

Die Bilder sind echt super. Nur die Einbindung in JOSM könnte verbessert werden. (Aber das ist ja auch nicht zwingend eine Sache derer, die die Bilder besorgt haben.)

Super Sache mit den Bildern - ich bin nach Anleitung von GeorgFausB vorgegangen und es klappt tadellos. Dankeschön an Georg!

Wie geht ihr mit den Auswirkungen auf Gerade und rechte Winkel um? Zieht ihr alles dann noch mal im Standard-Projektionsmodus (Merkator, oder?) zurecht?

tumsi wrote:

Wie geht ihr mit den Auswirkungen auf Gerade und rechte Winkel um? Zieht ihr alles dann noch mal im Standard-Projektionsmodus (Merkator, oder?) zurecht?

Mit WGS84 z.B. ein (real rechtwinkliges) Gebäude krumm abzeichnen, dann zu Mercator umschalten und "Q" drücken, damit es rechtwinklig wird. Natürlich nicht nach jedem einzelnen Gebäude, sondern in größeren Gruppen.

Hallo Forum,
auch von mir ein herzliches Dankeschön für die Bereitstellung der Bilder.
Auch bei mir hat das einbinden geklappt. Wie lange dürfen wir die Luftbilder verwenden? Auf welchen Zeitraum können wir uns einstellen?
Danke und Ciao
Holger

man kann die Bilder mit gdal auch in Mercator umwandeln
gdalwarp -s_srs epsg:4326 -t_srs epsg:900913 quelldatei.tif zieldatei.tif

SunCobalt wrote:

man kann die Bilder mit gdal auch in Mercator umwandeln
gdalwarp -s_srs epsg:4326 -t_srs epsg:900913 quelldatei.tif zieldatei.tif

Das verstehe ich nicht.

EPSG 4326 ist "WGS84 geografisch", oder?
Und EPSG 900913 ist dann Merkator?

Aerowest zeigt mir EPSG 31467 an, ich hätte erwartet, dass das irgendwie beim gdalwarp-Aufruf übergeben muss?

Du verwendest hier tif-Dateien, ich habe hier aber jpg- und jgw-Dateien, wie funktioniert das dann mit der Umprojektion mittels gdalwarp?

Gruß,
Mondschein

Mondschein wrote:

SunCobalt wrote:

man kann die Bilder mit gdal auch in Mercator umwandeln
gdalwarp -s_srs epsg:4326 -t_srs epsg:900913 quelldatei.tif zieldatei.tif

Das verstehe ich nicht.

EPSG 4326 ist "WGS84 geografisch", oder?
Und EPSG 900913 ist dann Merkator?

Aerowest zeigt mir EPSG 31467 an, ich hätte erwartet, dass das irgendwie beim gdalwarp-Aufruf übergeben muss?

Du verwendest hier tif-Dateien, ich habe hier aber jpg- und jgw-Dateien, wie funktioniert das dann mit der Umprojektion mittels gdalwarp?

Gruß,
Mondschein

dann versuchs mit

gdalwarp -s_srs epsg:31467 -t_srs epsg:900913 quelldatei.jpg zieldatei.jpg

s_srs steht für Source Spatial Reference System, t_srs für Target Spatial Reference System

Es kann sein, dass in der epsg Datei (Bei mir unter /usr/share/proj/epsg) 900913 nicht definiert ist.
Dann müsste das da rein:

#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␣<>

einfach oben reinschreiben

SunCobalt wrote:

dann versuchs mit

gdalwarp -s_srs epsg:31467 -t_srs epsg:900913 quelldatei.jpg zieldatei.jpg

Danke, das hat funktioniert.
Die neue JPEG-Datei ist jetzt 18 MB groß, das Original hingegen nur 0,5 MB.

SunCobalt wrote:

einfach oben reinschreiben

War hier nicht nötig.

Das hilft mir jetzt aber auch nicht wirklich weiter, oder?
Denn das ImportImagePlugin kann nur "WGS84 geografisch" ausgeben, da kann ich mit der JPEG-Datei vorher machen was ich will, das ändert daran nichts, oder?

Gruß,
Mondschein

hi !

ich habe die Transformation in GDAL erstellen können - nur meine jgw-Datei hat sich nicht aktualisiert bzw. ist entsprechend erstellt worden.

Würdest Du die "alte" von Aerowest verwenden ??

Gruß Jan :-)

Mondschein wrote:

SunCobalt wrote:

dann versuchs mit

gdalwarp -s_srs epsg:31467 -t_srs epsg:900913 quelldatei.jpg zieldatei.jpg

Danke, das hat funktioniert.
Die neue JPEG-Datei ist jetzt 18 MB groß, das Original hingegen nur 0,5 MB.

oops. Ändere mal die Endung der Zieldatei von jpg in tif. So ist es trotz der Endung ein GeoTiff geworden. Richtiger wäre es wahrscheinlich gewesen, das Output Format mit -of anzugeben.

gdalwarp␣-s_srs␣epsg:4326␣-of␣JPEG␣-t_srs␣epsg:900913␣kragujevac.tif␣kragujevac.jpg

Geht aber bei mir nicht....Scheint ein generelles Problem zu sein, wenn ich das so im Internet lese

Mondschein wrote:

[
Das hilft mir jetzt aber auch nicht wirklich weiter, oder?
Denn das ImportImagePlugin kann nur "WGS84 geografisch" ausgeben, da kann ich mit der JPEG-Datei vorher machen was ich will, das ändert daran nichts, oder?

Kann das Plugin keine Bilder mit Mercator Projection lesen bzw in Mercator darstellen? Das wäre aber ziemlich ungünstig, da wir ja in Mercator mappen. JOSM selber holt sich die Bilder von einem WMS in WGS84 und wandelt sie in Mercator um, das sollte das Plagin eigentlich schon können.

Lübeck wrote:

hi !

ich habe die Transformation in GDAL erstellen können - nur meine jgw-Datei hat sich nicht aktualisiert bzw. ist entsprechend erstellt worden.

Würdest Du die "alte" von Aerowest verwenden ??

Gruß Jan :-)

da die Output File ein GeoTiff ist (sorry für die Verwirrung) brauchst Du glaub keine *w (worldfile).

Mach mal

gdalinfo␣deine_datei.tif␣|␣more

da müsstest Du dann sowas sehen

thomas@suncobalt:~$␣gdalinfo␣test.tif␣|␣more
Driver:␣GTiff/GeoTIFF
Files:␣test.tif
Size␣is␣12081,␣12137
Coordinate␣System␣is:
PROJCS["Google␣Maps␣Global␣Mercator",
GEOGCS["WGS␣84",
DATUM["WGS_1984",
SPHEROID["WGS␣84",6378137,298.2572235630016,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4326"]],
PROJECTION["Mercator_1SP"],
PARAMETER["central_meridian",0],
PARAMETER["scale_factor",1],
PARAMETER["false_easting",0],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]]]

hi !

jetzt habe ich auch eine geotiff - wenn ich nun unter windows erst die osm-Daten aus dem Bereich ziehe und dann das geotiff laden will, dann bekoimme ich die Meldung

Error while creating image layer: null

Habe ich da noch etwas falsch gemacht ??

Edit: hat sich einer von Euch schon mal Gedanken darüber gemacht in welchem Maßstab er die Bilder zieht - ich würde ja gerne 1:500 nehmen. Dann ist aber auf einem Bild nicht viel drauf und man ist ja nur am Daten ziehen....

Gruß Jan :-)

SunCobalt wrote:

Kann das Plugin keine Bilder mit Mercator Projection lesen bzw in Mercator darstellen?

Ja, so scheint es zu sein.
Ich lasse mich aber gerne vom Gegenteil überzeugen.

Wenn man in JOSM nicht "WGS84 geografisch" eingestellt hat, dann funktioniert das Importieren eines Bildes nicht mehr, es wird nicht angezeigt und in der Konsole steht:

bbox: [ x: NaN -> NaN, y: NaN -> NaN ] is out of the world

Hier sieht das ähnlich aus:

GeorgFausB wrote:

Deutlich schöner wäre es, wenn das ImportImagePlugin auch "Merkator" als Ausgang bieten würde, denn so ist es etwas umständlich Gebäude abzuzeichen und rechtwinklig zu machen, da man ja ständig zwischen den Projektionsmethoden umschalten muss!

Ich hoffe, dass es irgend eine (WMS-)Lösung geben wird, denn so ist der Aufwand für mich zu hoch, um größere Gebiete in guter Qualität zu erfassen.

Lübeck wrote:

hat sich einer von Euch schon mal Gedanken darüber gemacht in welchem Maßstab er die Bilder zieht - ich würde ja gerne 1:500 nehmen. Dann ist aber auf einem Bild nicht viel drauf und man ist ja nur am Daten ziehen....

Ich nehme 1:500, sonst könnte ich gleich Bing verwenden. 🙂

Gruß,
Mondschein

moin !

wenn ich mein josm auf wgs84 (epsg 4326) und dann das heruntergeladene aerowest-jpg in jsom einbinde, dann sieht es aus wie in

http://www.tappenbeck.net/forum/osm/aer … r_test.jpg

als referenzsystem habe ich das default angewandt - die epsg nummer stimmt überein mit der in aerowest.

was kann ich dann noch falsch gemacht haben ??

falls einer es nachbauen möchte - der ausschnitt ist in schleswig-holstein > dithmarschen > ostrohe (http://www.openstreetmap.org/?lat=54.21 … 47&zoom=19).

gruß Jan :-)

Ticket #6655 (new enhancement)
Make "Mercator" the default projection in ImportImage Plugin

Switching back and forth between ""WGS84 geografisch" and "Mercator" is too cumbersome for most JOSM user: http://forum.openstreetmap.org/viewtopi … 78#p180578

Priority set to "critical" set because of high impact (Aereowest Imagery will be available only for 12 months)

Thanks a lot,
Frank

@Walter
Hab bei mir "sun-java6-plugin_6.26-0squeeze1_amd64.deb" installiert, dann gings auch mit dem Linux-FF

kellerma wrote:

...
Hab bei mir "sun-java6-plugin_6.26-0squeeze1_amd64.deb" installiert, dann gings auch mit dem Linux-FF

So funzt es bei mir auch unter Ubuntu 11.04

Hi,
wer mit dem josm-Teil nicht klar kommt, kann die georeferenzierten Bilder auch in Quantum Gis einladen (auch mehrere gleichzeitig).
Dort kann man alle EPSG-Codes als Projekteinstellung auswählen (on-the-fly dabei ankreuzen!). Für jedes Bild muß man ggf. dann nochmal die gleiche Projektion einstellen, weil das Programm die Projektion nicht aus den Bildinformationen laden kann.

Dazu einen GPX-Layer erstellen mit WGS84, die gewünschten Informationen digitalisieren und das gpx in josm einladen.
Oder in QGIS direkt osm-Daten einlesen. Dann sollte man aber den Flächenlayer gleich abschalten oder nach untenschieben, weil er sonst alles zudeckt.

Gruß,
ajoessen

hi , hab gestern mal anhand der Anleitung mehrere Kacheln für Koblenz (RLP) eingespielt ... jetzt ist mir aber aufgefallen, dass ca 50 der Daten auf den Kacheln verrutscht dargestellt werden... wie bekomme ich denn raus, welche der Daten nun richtig und welche falsch sind?

Und wie könnte ich so ein Bild verschieben ?

hi !

das ist aber derzeit noch alles andere als produktiv....

gruß Jan :-)

wenn Ende August, nach meinen Urlaub, noch keine Lösung gefunden wurde, würde ich eine Stadt hosten und als WMS bereit stellen. Das habe ich ja schön öfter gemacht. Die einzige Frage wäre dann noch, wie man die Daten einer ganzen Stadt bekommt.

Meine Stadt (Kreis Coesfeld) ist nicht drin. Bleibt mir also die ganze Arbeit erspart. 😄

chris66 wrote:

Meine Stadt (Kreis Coesfeld) ist nicht drin. Bleibt mir also die ganze Arbeit erspart. 😄

meine Stadt ist auch aussen vor. Mach Dir nichts draus. Bis spätestens Ende nächsten Jahres (wahrscheinlich früher) hast Du dann auch recht gute Luftbilder.

Hi !

hat es denn nun eigentlich einer von Euch mal geschafft gescheit ein Luftbild unter josm (windows) einzubinden ?? (siehe #30)

Ich möchte doch so gerne loslegen...

Gruß Jan :-)

kellerma wrote:

Hab bei mir "sun-java6-plugin_6.26-0squeeze1_amd64.deb" installiert, dann gings auch mit dem Linux-FF

danke für den Tip.
Hab aber nicht sun-java sondern nur openjdk installiert.daher "motzt" dpkt beim install.
mal sehen ob ich es hinkriege
Gruss
walter

wambacher wrote:

kellerma wrote:

Hab bei mir "sun-java6-plugin_6.26-0squeeze1_amd64.deb" installiert, dann gings auch mit dem Linux-FF

danke für den Tip.
Hab aber nicht sun-java sondern nur openjdk installiert.daher "motzt" dpkt beim install.
mal sehen ob ich es hinkriege
Gruss
walter

Hi Walter,

Du brauchst noch die zwei anderen:
sun-java6-bin sowie sun-java6-jre
dann kannst per "dpkg -i" installieren ohne ein "non-free" in apt.sources zu hinterlegen.

Musst halt aufpassen, dass das openjdk fürs "normale" java noch verwendet wird.
Ggf. mit "update-alternatives --config java" kontrollieren.

Ciao,
Frank

Hallo Forum,
ich habe heute Morgen das ImportImagePlugin auf die Version 26413 aktualisiert. Leider funktioniert es jetzt nicht mehr. Die Bilder werden jetzt bei mir 90Grad gedreht dargestellt.
Wo finde ich die alte Version im Netz? Mit googlen bin ich nicht fündig geworden.
Danke und Ciao
Holger

kellerma wrote:

Du brauchst noch die zwei anderen:
sun-java6-bin sowie sun-java6-jre
dann kannst per "dpkg -i" installieren ohne ein "non-free" in apt.sources zu hinterlegen.

das war mir schon klar - install rennt gerade.
Nur diese kleinen Nebensätze "dann musst halt aufpassen" machen die Sache ja erst interessant 😉
Ich möchte mir meine java developer ecke nicht zerschiessen und osmosis frisst sich gerade durch die diff-daten der letzten nacht

Gruss
Walter

p.s. war wäre denn der source-path für apt.sources? ich hab das paket ergoogled.

hi !

1. 42: Die Bilder werden jetzt bei mir 90Grad gedreht dargestellt. das sieht ja aus wie bei meinem Problem !
   

=> http://www.tappenbeck.net/forum/osm/aer … r_test.jpg

gruß Jan :-)

Hi Walter,

wambacher wrote:

p.s. war wäre denn der source-path für apt.sources? ich hab das paket ergoogled.

Für 11.04? Vermutlich

sudo echo "deb http://archive.canonical.com/ubuntu natty partner" /etc/apt/sources.list

siehe http://wiki.openstreetmap.org/wiki/DE_t … Luftbilder

Aber ich hab' ja nur Debian 😉

Ciao,
Frank

kellerma wrote:

Aber ich hab' ja nur Debian 😉

bin mal etwas stärker eingestiegen. hab jetzt sun-java 6 mit allem drum und dran istalliert und aktiviert. (java -version sieht gut aus)
ff benutzt aber immer noch das openjdk und zieht 90% cpu, wenn ich die seite aufrufe.
werd ich wohl mal die schraube im ff suchen muessen. oder ich mach opensdk halt ganz platt.

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

Oli-Wan wrote:

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?

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.

Lübeck wrote:

Hi !
hat es denn nun eigentlich einer von Euch mal geschafft gescheit ein Luftbild unter josm (windows) einzubinden ?? (siehe #30)

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

Holger-erf wrote:

ich habe heute Morgen das ImportImagePlugin auf die Version 26413 aktualisiert. Leider funktioniert es jetzt nicht mehr. Die Bilder werden jetzt bei mir 90Grad gedreht dargestellt.

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

Lübeck wrote:

1. 42: Die Bilder werden jetzt bei mir 90Grad gedreht dargestellt. das sieht ja aus wie bei meinem Problem !
   

=> http://www.tappenbeck.net/forum/osm/aer … r_test.jpg

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/aer … _31467.jpg sieht das sch.... aus.

ersetze bei einer eMail bitte die FAMILIE durch OSM!

Gruß Jan :-)

Lübeck wrote:

hi Georg,

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

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

Gruß,
ajoessen

wambacher wrote:

oder ich mach opensdk halt ganz platt.

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

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

Hi Jan,

Lübeck wrote:

ich habe mir das nochmal angesehen und auch mit http://www.tappenbeck.net/forum/osm/aer … _31467.jpg sieht das sch.... aus.
Gruß Jan :-)

nein, nur ungewohnt.

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

$ tail log.log
2011-07-29 20:29:46,925 INFO [AWT-EventQueue-0] org.openstreetmap.josm.plugins.ImportImagePlugin.LoadImageAction: File choosed:/home/user/exportimg2011729195139255566.jpg
2011-07-29 20:29:51,993 DEBUG [AWT-EventQueue-0] org.openstreetmap.josm.plugins.ImportImagePlugin.ImageLayer: Coverage created: Resampler2D["", GeneralEnvelope[(54.21410411465883, 9.127259378997095), (54.21540474143782, 9.130395294562636)], DefaultGeographicCRS["WGS 84"]]
│ RenderedSampleDimension("":[0.0 ... 255.0])
│ ‣ Category("":[0...255])
│ RenderedSampleDimension("":[0.0 ... 255.0])
│ ‣ Category("":[0...255])
│ RenderedSampleDimension("":[0.0 ... 255.0])
│ ‣ Category("":[0...255])
└ Image=RenderedOp["Warp"] as views [NATIVE, PACKED, RENDERED, GEOPHYSICS, PHOTOGRAPHIC]

Hab mir erlaubt, ein kleines Häuschen abzumalen 😉

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

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/aer … 1467_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 :-)

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 😉

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

mmd wrote:

Hallo,

ich habe gerade einen kleinen Ausschnitt in Saarbrücken im ECW-Betrachter als georef. JPEG gespeichert, EPSG wurde im ECW-Viewer mit 31466 angegeben. Mit gdalwarp dann von EPSG 31466 nach EPSG 3857 konvertiert (das zeigt JOSM als Projektionsbezeichnung für Merkator an).

gdalwarp␣-s_srs␣epsg:31466␣-t_srs␣epsg:3857␣exportimg....jpg␣ergebnis.tif

Projektion in JOSM auf Merkator gesetzt, die ergebnis.tif Datei habe ich mit ImportImagePlugin Version 26413 importiert.
Ergebnis sah soweit ok aus, auch ohne Verzerrung.

Gruß

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

SunCobalt wrote:

mmd wrote:

Hallo,

ich habe gerade einen kleinen Ausschnitt in Saarbrücken im ECW-Betrachter als georef. JPEG gespeichert, EPSG wurde im ECW-Viewer mit 31466 angegeben. Mit gdalwarp dann von EPSG 31466 nach EPSG 3857 konvertiert (das zeigt JOSM als Projektionsbezeichnung für Merkator an).

gdalwarp␣-s_srs␣epsg:31466␣-t_srs␣epsg:3857␣exportimg....jpg␣ergebnis.tif

Projektion in JOSM auf Merkator gesetzt, die ergebnis.tif Datei habe ich mit ImportImagePlugin Version 26413 importiert.
Ergebnis sah soweit ok aus, auch ohne Verzerrung.

Gruß

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

Man soll den Abend nicht vor Mitternacht loben 😉

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 😉

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 🙂

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 ( 😉 )

kellerma wrote:

Also es lag doch an gdal (in einem gewissen Sinne 😉
[...]
=> man kann die Einstellung auf "Merkator" lassen.

Danke!

Jetzt funktioniert das auch bei mir. 😄

Verwendet habe ich JOSM 4277.

• "Merkator" unter "Bearbeiten -> Einstellungen -> Karten-Einstellungen -> Projektionsmethode" einstellen
• ImportImagePlugin Version 26413 installieren
• JOSM neu starten
• Im JOSM-Verzeichnis unter plugins/ImportImagePlugin/pluginProperties.properties steht bei mir:

default_crs_srid=EPSG\:31467
libraries=<nicht␣verändert>
default_crs_eastingfirst=true

• 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.
• 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.
• Daten erstellen und Hochladen. 🙂

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:

Files: bild.tif
Size is 2970, 2100
Coordinate System is:
PROJCS["DHDN / Gauss-Kruger zone 3",
GEOGCS["DHDN",
DATUM["Deutsches_Hauptdreiecksnetz",
SPHEROID["Bessel 1841",6377397.155,299.1528128000033,
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",9],
PARAMETER["scale_factor",1],
PARAMETER["false_easting",3500000],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AUTHORITY["EPSG","31467"]]
[...]

Gruß,
Mondschein

Pajopath wrote:

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

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? 😉

gruss
walter

wambacher wrote:

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? 😉

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:

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

Error while creating image layer: null

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

Holger-erf wrote:

der Server von Aerowest hat scheinbar den Ansturm der OSM User nicht standgehalten. Er ist down.

Da ist wohl die Festplatte voll:

No space left on device

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

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

Dennis[B] wrote:

Admins arbeiten 24/7

Nein.

Dennis[B] wrote:

Das Problem dürften eher zu kleine Server sein, da der Ansturm am Anfang sicher gigantisch ist.

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

Dennis[B] wrote:

Wenn Aero-West sagt "Warten wir 2 Wochen das gibt sich schon", dann kann man das denen auch nicht böse nehmen.

Unwahrscheinlich, dass der Speicherplatz automatisch wieder freigegeben wird.

Gruß,
Monschein

Der Server funktioniert jetzt wieder.
Es kann weiter gehen. 🙂

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.

Mondschein wrote:

Der Server funktioniert jetzt wieder.
Es kann weiter gehen. 🙂

Gruß,
Mondschein

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

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

kellerma wrote:

Moin moin,

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.

Ich würds so versuchen...kann man sicher noch verfeinern
Bilder runterladen und in ein Verzeichnis packen. Dann
gdal_merge.py -o output.tif -co 'TILED=YES' -n 0 -of GTIFF /pfad/zu/bilder/*.tif

Das Bild "output" tilen
gdal_translate -of GTiff -co "TILED=YES" output.tif output_tiled.tif

Jetzt noch die Übersichten generieren
gdaladdo -ro --config USE_RRD YES -r cubic output_tiled.tif 2 4 8 16 32 64 128 256

Umprojektion
gdalwarp -s_srs epsg:4326 -t_srs epsg:3857 output_tiled.tif output_tiled_3857.tif

Danach sollte die Mapfile so aussehen

MAP
NAME␣OSM-WMS
FONTSET␣"/osm/mapserver/fonts.list"
STATUS␣ON
UNITS␣METERS

WEB
METADATA
"wms_title"␣␣␣␣␣"Thomas␣WMS-Server"
"labelcache_map_edge_buffer"␣"-10"
"wms_onlineresource"␣"to_be_replaced_by_wms.py"
"wms_srs"␣␣␣␣␣␣␣"EPSG:4326␣EPSG:900913"
"wms_connectiontimeout"␣"240"
END
IMAGEPATH␣␣␣␣␣␣␣"/osm/mapserver/imagepath/"

END
CONFIG␣"PROJ_LIB"␣"/usr/share/proj/"
CONFIG␣"MS_ERRORFILE"␣"stderr"
EXTENT␣0␣0␣180␣180
MAXSIZE␣4000
SIZE␣800␣800
UNITS␣dd
IMAGECOLOR␣"#B3C6D4"
PROJECTION
"init=epsg:4326"
END

IMAGETYPE␣png
SHAPEPATH␣"/osm/mapserver/shapepath/"
OUTPUTFORMAT
NAME␣png
DRIVER␣"AGG/PNG"
MIMETYPE␣"image/png"
IMAGEMODE␣RGBA
EXTENSION␣"png"
END

LAYER
NAME␣"MeinAeroWestLayer"
STATUS␣ON
TYPE␣RASTER

DATA␣"/osm/mapserver/bilder/output_tiled_3857.tif"

PROJECTION
"init=epsg:3857"
END

METADATA
"wms_title"␣␣"Wieauchimmer"
"wms_extent"␣"20.024766␣46.040227␣20.073920␣46.081113"
"wms_srs"␣␣␣␣"EPSG:4326"
"copyright"␣␣␣␣""
END
END
END

kellerma wrote:

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

Hatte ich für eine Stadt angeboten. Ich weiß, dass hier noch mehrere Leute Mapserver laufen haben. Nur wie kommt man an die Daten?

Melde dich mal bei den OSM-Projektverantwortlichen. Genau so sollte das mit den WMS-Servern laufen. Der Haken ist, dass der Betreiber dafür sorgen muss, dass die Lizenz (osm-only) eingehalten wird.

-

aighes wrote:

Melde dich mal bei den OSM-Projektverantwortlichen. Genau so sollte das mit den WMS-Servern laufen. Der Haken ist, dass der Betreiber dafür sorgen muss, dass die Lizenz (osm-only) eingehalten wird.

OK, werde ich mal machen. Wegen der Lizenz könnte ich einen Copyright-Hinweis "OSM use only" oder so übers Bild legen.

Hi,

SunCobalt wrote:

Bilder runterladen und in ein Verzeichnis packen. Dann
gdal_merge.py -o output.tif -co 'TILED=YES' -n 0 -of GTIFF /pfad/zu/bilder/*.tif

Fragen:
Wie man schön an Pajopath Bild sieht (Post #68) hat man häufig "Löcher" bei Herunterladen
der Bilder von aeroview, da man es durch das JAVA-Applet nicht passgenau hinbekommt.
Das stellt keine Probleme dar?
Überlappende Bilder beim "Zusammenmanschen" auch nicht?

SunCobalt wrote:

Umprojektion
gdalwarp -s_srs epsg:4326 -t_srs epsg:3857 output_tiled.tif output_tiled_3857.tif

Sollte Source_srs nicht die 31467/etc. sein? Somit
gdalwarp -s_srs epsg:31467 -t_srs epsg:3857 output_tiled.tif output_tiled_3857.tif

JOSM macht irgendwo einen "internen Schmuh" bei Merkator/4326 (Muss da josm-dev nochmals
genau nachlesen), möglicherweise würde sogar ein
gdalwarp -s_srs epsg:31468 -t_srs epsg:4326 output_tiled.tif output_tiled_4326.tif
Besonders für Leute wie Mondschein und ich, denen "3857" zu neu ist 😉
Mein output_tiled_4326.tif ist jetzt leider zum Ausgangbild ca 4 m nach Nord-West versetzt im JOSM.
Mmmh ...

Danke schön.

Ciao,
Frank

kellerma wrote:

Hi,

SunCobalt wrote:

Bilder runterladen und in ein Verzeichnis packen. Dann
gdal_merge.py -o output.tif -co 'TILED=YES' -n 0 -of GTIFF /pfad/zu/bilder/*.tif

Fragen:
Wie man schön an Pajopath Bild sieht (Post #68) hat man häufig "Löcher" bei Herunterladen
der Bilder von aeroview, da man es durch das JAVA-Applet nicht passgenau hinbekommt.
Das stellt keine Probleme dar?
Überlappende Bilder beim "Zusammenmanschen" auch nicht?

Bei der Beschreibung von gdal_merge steht:
This utility will automatically mosaic a set of images. All the images must be in the same coordinate system and have a matching number of bands, but they may be overlapping, and at different resolutions. In areas of overlap, the last image will be copied over earlier ones.

kellerma wrote:

SunCobalt wrote:

Umprojektion
gdalwarp -s_srs epsg:4326 -t_srs epsg:3857 output_tiled.tif output_tiled_3857.tif

Sollte Source_srs nicht die 31467/etc. sein? Somit
gdalwarp -s_srs epsg:31467 -t_srs epsg:3857 output_tiled.tif output_tiled_3857.tif

s_srs sollte man am besten mit gdalinfo rausfinden. Wenn ich das richtig in Erinnerung habe, ist das nicht bei allen Bildern gleich. Das wäre blöd. t_srs hängt davon ab, was man damit machen will. Fürs PicLayer wäre bspw 900913/3857 korrekt. Bei der Einbindung im Mapserver sollte es eigentlich egal sein. Dort kannst Du das EPSG im Layer definieren. Da könnte man sich den Schritt sparen.

Aber warte am besten noch bis heute Abend oder morgen. Da wird es dann vermutlich eine Nachricht geben, die das rumfummeln einzelner Mapper mit einzeln runtergeladenen Bildern überflüssig macht

so, ich darf es posten

Hallo Thomas,

kurze Zusammenfassung wie wir uns das mit den lokalen WMS Servern vorstellen.

aktuell ist ein Test mit einer Stadt geplant, dies wird aller Vorraussicht Göttingen sein. Hierbei geht es vor allem auch darum technische und organisatorische Dinge zu testen. Wir rechnen nach Start mit einer Testphase von 6-8 Wochen.

Danach ist geplant einen Aufruf an lokale Communities/OSM-Stammtische zu starten die Bilder lokale wie du hosten wollen.
Eine Bedingung wird sein das es vor Ort eine aktive Community gibt, sprich keine Einzelkämpfer.
Vermutlich wird es auch eine Rotation bei Vergabe der Bilder für lokale WMS-Server geben. Die Zahl der lokalen WMS wird begrenzt sein und die Bilder werden dann auch nur für einen begrenzten Zeitraum zur Verfügung stehen.

Der Bezug der Bilder würde über Marc oder mich geschehen.

Um welche Stadt geht es denn eigentlich?

Viele Grüße

Olaf

und

Die Bedingungen für die Nutzung der Bilder werden in einem Untervertrag fixiert.

Hi,

SunCobalt wrote:

s_srs sollte man am besten mit gdalinfo rausfinden. Wenn ich das richtig in Erinnerung habe, ist das nicht bei allen Bildern gleich. Das wäre blöd. t_srs hängt davon ab, was man damit machen will. Fürs PicLayer wäre bspw 900913/3857 korrekt. Bei der Einbindung im Mapserver sollte es eigentlich egal sein. Dort kannst Du das EPSG im Layer definieren. Da könnte man sich den Schritt sparen.

Dass innerhalb einer Stadt sich die GK-Zone ändert bei den Bildern - auch wenn die Stadt an beiden Zonen beteiligt ist - halte ich für unwahrscheinlich.
Ich (wie viele andere wohl auch) wollen in JOSM mit Mercator arbeiten, die Bilder liegen aber in GK-2/3/4/5(?) vor, müssen also umprojeziert werden; würde es daher bevorzugen, dies alles schon im "pre-processing" zu erledigen, sodass der mapserver "nur" noch ausliefern muss und auch JOSM selbst sich nicht damit "rumschlagen" muss (allein schon aus Performance-/Speicher-gründen).

SunCobalt wrote:

Aber warte am besten noch bis heute Abend oder morgen. Da wird es dann vermutlich eine Nachricht geben, die das rumfummeln einzelner Mapper mit einzeln runtergeladenen Bildern überflüssig macht

Danke für Deine post; kann verstehen, dass Aerowest die Zahl der "Betreiber" klein halten will; ob man mit dieser "Taktik" das Gross der Mapper errecht?
Viele sind "nicht organisiert" und beleibe nicht alle Mapper Dtl. treffen sich bei den Stammtischen.

We will see 😉

Ciao,
Frank

kellerma wrote:

Hi,

SunCobalt wrote:

s_srs sollte man am besten mit gdalinfo rausfinden. Wenn ich das richtig in Erinnerung habe, ist das nicht bei allen Bildern gleich. Das wäre blöd. t_srs hängt davon ab, was man damit machen will. Fürs PicLayer wäre bspw 900913/3857 korrekt. Bei der Einbindung im Mapserver sollte es eigentlich egal sein. Dort kannst Du das EPSG im Layer definieren. Da könnte man sich den Schritt sparen.

Dass innerhalb einer Stadt sich die GK-Zone ändert bei den Bildern - auch wenn die Stadt an beiden Zonen beteiligt ist - halte ich für unwahrscheinlich.
Ich (wie viele andere wohl auch) wollen in JOSM mit Mercator arbeiten, die Bilder liegen aber in GK-2/3/4/5(?) vor, müssen also umprojeziert werden; würde es daher bevorzugen, dies alles schon im "pre-processing" zu erledigen, sodass der mapserver "nur" noch ausliefern muss und auch JOSM selbst sich nicht damit "rumschlagen" muss (allein schon aus Performance-/Speicher-gründen)

Beim Mapserver gibst Du mit init=epsg... an, wie die Daten vorliegen. Mit wms_srs gibst Du an, wie sie ausgeliefert werden sollen. Das umwandeln macht der Mapserver alleine. Es gibt noch eine vielleicht einfachere Möglichkeit mit einem Shapefileindex. Ich poste das mal heute Abend. Das ist vielleicht einfacher wenn man die Bilder in Mapserver nutzen will und auf das JOSM Plugin verzichtet

Hier die versprochene weitere Möglichkeit viele verschiedene *.tif mittels Shapefile-Index zu benutzen. Man sieht hier bspw auch, dass die Daten nicht in WGS84 vorliegen (PROJECTION "init=epsg:31277") , aber vom Mapserver als WGS84 ("wms_srs" "EPSG:4326") ausgeliefert werden.
Das ist vielleicht einfacher als die Dateien zu verschmelzen. Wie es bei Überlappungen aussieht, weiß ich nicht. Müsste man probieren

gdaltindex senta.shp /osm/fileserver/SentaDOP/*.tif

Das Layer im Mapfile sieht dann so aus

␣LAYER
NAME␣"SentaDOP"
STATUS␣ON
PROJECTION
"init=epsg:31277"
END
METADATA
"wms_title"␣␣"SentaDOP"
"wms_srs"␣␣␣␣"EPSG:4326"
"copyright"␣␣␣␣""
END

TYPE␣RASTER
TILEINDEX␣"/osm/fileserver/SentaDOP/senta.shp"
TILEITEM␣"LOCATION"
END

Heute morgen habe ich eine sauber in WGS84 georefernzierte Katasterkarte für jemanden bereitgestellt. Ich habe mal mitgeschrieben. An den ESPG Codes kann ja jeder selber rumändern

thomas@suncobalt:/osm/mapserver/bajmok$␣gdalinfo␣Bajmok_wgs84.tif␣|␣more
Driver:␣GTiff/GeoTIFF
Files:␣Bajmok_wgs84.tif
Bajmok_wgs84.tif.ovr
Bajmok_wgs84.tif.aux.xml
Size␣is␣70810,␣52531
Coordinate␣System␣is:
GEOGCS["WGS␣84",
DATUM["WGS_1984",
SPHEROID["WGS␣84",6378137,298.2572235630016,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4326"]]
..............

thomas@suncobalt:/osm/mapserver/bajmok$␣python␣/osm/mapserver/print_wms_extent.py␣Bajmok_wgs84.tif
"wms_extent"␣"19.396992␣45.956686␣19.446389␣45.993332"
thomas@suncobalt:/osm/mapserver/bajmok$␣gdal_translate␣-of␣GTiff␣-co␣"TILED=YES"␣Bajmok_wgs84.tif␣Bajmok_wgs84_tiled.tif
Input␣file␣size␣is␣70810,␣52531
0...10...20...30...40...50...60...70...80...90...100␣-␣done.
thomas@suncobalt:/osm/mapserver/bajmok$␣gdaladdo␣-ro␣--config␣USE_RRD␣YES␣-r␣gauss␣Bajmok_wgs84_tiled.tif␣2␣4␣8␣16␣32␣64␣128␣256
0...10...20...30...40...50...60...70...80...90...100␣-␣done.

Abhängig von der Größe kann das u.U. Stunden bis Tage dauern.

Layer in Mapfile definieren

LAYER
NAME␣"Bajmok"
STATUS␣ON
TYPE␣RASTER

DATA␣"/osm/mapserver/bajmok/Bajmok_wgs84_tiled.tif"

PROJECTION
"init=epsg:4326"
END

METADATA
"wms_title"␣␣"Bajmok"
"wms_extent"␣"19.396992␣45.956686␣19.446389␣45.993332"
"wms_srs"␣␣␣␣"EPSG:4326"
"copyright"␣␣"OSM␣use␣only"
END
END

Und dann in JOSM einbinden

-

mmd wrote:

Allerdings war mir nicht so ganz klar, wofür gdal_translate und gdaladdo benötigt werden und hab die beiden kurzerhand weggelassen...

gdal_translate -of GTiff -co "TILED=YES" vorher.tif nachher.tif

ist dafür da, dass ein großes Bild in einzelne Tiles zerlegt wird. Wenn Du bspw ein DOP für ganz DE hast, wäre es etwas blöd wenn JOSM immer ganz DE laden müsste Du aber nur in Buxtehude editieren willst.

gdaladdo -ro --config USE_RRD YES -r cubic meinbild.tif 2 4 8 16 32 64 128 256

bildet eine Vergrößerungspyramide. Also wenn Du bspw in Zoom 12 arbeitest, müssen nicht die Bilder die in Zoom 18 vorliegen, geladen werden. Es werden statt dessen geringer vergrößerte Bilder genommen. Nebenbei werden die Bilder noch bearbeitet. Ich nehme cubic für Luftbilder und Gauss für Schwarzweißkarten.

Das gdalwarp kannst Du Dir sparen, einfach in der Mapfile den EPSG Code angeben, in dem die Daten vorliegen. Die Transformation geschieht dann automatisch

Freut mich, dass es bei Dir geklappt hat.

@mmd

nimm mal die http://suncobalt.homeip.net:82/wms.txt packe sie ins Apache root und nennen sie wms.wsgi. Ich weiß jetzt nicht, ob Du darin noch die Pfade umbenennen musst. Damit sollte es dann möglich sein, mit http://domain.irgendwo/wms? und JOSM auch Deinen WMS Server abzufragen (GetCap)

hi !

was meinst Du mit dem "WMS-Plugin" ?? in meiner JOSM Liste finde ich unter dem Suchbegriff WMS kein entsprechendes Plugin.

gruß Jan :-)

Hi Jan,

Lübeck wrote:

hi !

was meinst Du mit dem "WMS-Plugin" ?? in meiner JOSM Liste finde ich unter dem Suchbegriff WMS kein entsprechendes Plugin.

gruß Jan :-)

Das WMS-Plugin gab es mal extra, irgendwann (JOSM-Version 3000?) wurde es in JOSM-Core integriert so wie der Validator auch,
der frühers ein eigenes Plugin war.

Ciao,
Frank

-

super. Jetzt brauchst Du nur noch nach Post #94 vorgehen. Dann kannst Du eigentlich alles was georeferenziert ist (die *.*w ist die sogenannte world file, die die Referenzierungsdaten enthält - GeoTiffs brauchen sowas nicht. Schau einfach mit gdalinfo nach) auf Deinem Mapserver hosten. Den extend musst Du nicht angeben. Ich mach es immer, aber nur der Form halber. Musst nur schauen, dass die epsg File auch die Definitionen für das gehostete Material enthält.

Ich bin eher ein IT Dummy und mache sowas mit Try&Error. Magst Du eine Anleitung im Wiki erstellen?

achja. Mit Mapserver hast Du übrigends gleich auch einen Renderer und kannst schicke Karte rendern.

mmd wrote:

WSGIScriptAlias␣/wms␣/var/www/wms.wsgi

Im Browser habe ich dann ein GetCapabilities getestet:

http://localhost/wms?service=WMS&request=GetCapabilities

Ergebnis war leider ein Internal Server Error, Apach Error Log file meinte dazu:

[Sun␣Jul␣31␣20:15:10␣2011]␣[error]␣[client␣127.0.0.1]␣Traceback␣(most␣recent␣call␣last):
[Sun␣Jul␣31␣20:15:10␣2011]␣[error]␣[client␣127.0.0.1]␣␣␣File␣"/var/www/wms.wsgi",␣line␣154,␣in␣application
[Sun␣Jul␣31␣20:15:10␣2011]␣[error]␣[client␣127.0.0.1]␣␣␣␣␣cclass=clayer.getClass(0)
[Sun␣Jul␣31␣20:15:10␣2011]␣[error]␣[client␣127.0.0.1]␣AttributeError:␣'NoneType'␣object␣has␣no␣attribute␣'getClass'

Ich habe mal den Autor dazu befragt. Hier die Antwort

.....

und das Forum haben es hinbekommen, MapServer zum laufen zu
bekommen. Es gibt da nur ein Problem. Naja es geht auch ohne,
aber ich weiß nicht, ob es negative Auswirkungen hat.

Jemand bekam die folgenden Fehlermeldungen
[Sun Jul 31 20:15:10 2011] [error] [client 127.0.0.1] Traceback (most recent call last):
[Sun Jul 31 20:15:10 2011] [error] [client 127.0.0.1] File "/var/www/wms.wsgi", line 154, in application
[Sun Jul 31 20:15:10 2011] [error] [client 127.0.0.1] cclass=clayer.getClass(0)
[Sun Jul 31 20:15:10 2011] [error] [client 127.0.0.1] AttributeError: 'NoneType' object has no attribute 'getClass'

Er hat dann einfach die folgenden Zeilen auskommentiert

1. clayer=map.getLayerByName("copyright")
   
2. cclass=clayer.getClass(0)
   
3. cclass.setText(cstring)
   

Und dann gings.

Dein mapfile hat vermutlich keinen Layer mit der Bezeichnung
"copyright". Der ist für das zwangsweise einblenden von Watermarks.
Wie gesagt das script ist nicht irgendwie generisch gebaut. Man
könnte da schon code rumbauen der den Fehelr abfängt, wenn es keinen
"copyright" layer im mapfile gibt.

.....

Mondschein wrote:

Pajopath wrote:

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

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

ähhm und wie mache ich das unter Windows 7 ? 😄

Die Anleitungen (wenn ich es richtig verstehe) beziehen sich ja alle auf eine Linux/Ubuntu Distribution oder?

Hi,

Pajopath wrote:

ähhm und wie mache ich das unter Windows 7 ? 😄

Die Anleitungen (wenn ich es richtig verstehe) beziehen sich ja alle auf eine Linux/Ubuntu Distribution oder?

Mmh, schon mal geschaut, ob
http://www.maptools.org/ms4w/
auf Win 7 läuft?

Ciao,
Frank

Hallo zusammen,

ich habe heute auch etwas mit dem Aufsetzen eines WMS-Servers experimentiert.

Hier mein Ergebnis unter Debian Squeeze (kellerma: kennt auch 3857 🙂)

Zum Erstellen der Tiles kann ich noch nicht viel sagen, da ich noch mit einem kleinen Versatz kämpfe.

• Pakete installieren

apt-get␣install␣mapserver-bin␣cgi-mapserver␣gdal-bin␣apache2␣libapache2-mod-fcgid␣proj␣python-gdal

Wer non-free mag, darf "libapache2-mod-fcgid" aus main, durch "libapache2-mod-fastcgi" aus non-free ersetzen. 😉
• Apache mit mapserv testen:

/usr/lib/cgi-bin/mapserv␣-v

gibt aus

MapServer␣version␣5.6.5␣OUTPUT=GIF␣OUTPUT=PNG␣OUTPUT=JPEG␣OUTPUT=WBMP␣OUTPUT=SWF␣OUTPUT=SVG␣SUPPORTS=PROJ␣SUPPORTS=AGG␣SUPPORTS=FREETYPE␣SUPPORTS=ICONV␣SUPPORTS=FRIBIDI␣SUPPORTS=WMS_SERVER␣SUPPORTS=WMS_CLIENT␣SUPPORTS=WFS_SERVER␣SUPPORTS=WFS_CLIENT␣SUPPORTS=WCS_SERVER␣SUPPORTS=SOS_SERVER␣SUPPORTS=FASTCGI␣SUPPORTS=THREADS␣SUPPORTS=GEOS␣SUPPORTS=RGBA_PNG␣INPUT=EPPL7␣INPUT=POSTGIS␣INPUT=OGR␣INPUT=GDAL␣INPUT=SHAPEFILE

Aufruf von http://127.0.0.1/cgi-bin/mapserv zeigt im Browser an:

No␣query␣information␣to␣decode.␣QUERY_STRING␣is␣set,␣but␣empty.

Also soweit alles ok.
• Tiles erstellen:
Dazu kann ich noch nicht so viel sagen, da ich leider noch einen leichten Versatz habe.
• Mapfile erstellen (Speicherort bei mir /mapserver/data/osm.map), "init=epsg:3857" evtl. anpassen:

MAP
NAME␣OSM-WMS
STATUS␣ON
UNITS␣METERS

PROJECTION
"init=epsg:3857"
END

WEB
METADATA
"wms_title"␣␣␣␣␣"WMS-Server"
"wms_onlineresource"␣"http://127.0.0.1/cgi-bin/mapserv?map=/mapserver/data/osm.map&"
"wms_srs"␣␣␣␣␣␣␣"EPSG:3857␣EPSG:4326␣EPSG:900913"
END
END

LAYER
STATUS␣ON
NAME␣"AerowestOSM"

DATA␣"/mapserver/data/tile.tif"

METADATA
"wms_title"␣␣"Luftbilder"
"wms_srs"␣␣␣␣"EPSG:3857␣EPSG:4326␣EPSG:900913"
END

TILEITEM␣"location"
TYPE␣RASTER
END
END

• Die "Service-URL" (z.B. für JOSM) lautet dann:
http://127.0.0.1/cgi-bin/mapserv?map=/m … a/osm.map&

Die "Service-URL" kann verkürzt werden, hierfür in die Datei /etc/apache2/httpd.conf eintragen:

SetEnvIf␣Request_URI␣"/cgi-bin/mapserv"␣MS_MAPFILE=/mapserver/data/osm.map

Somit lautet die verkürzte "Service-URL": http://127.0.0.1/cgi-bin/mapserv?
Im Mapfile kann dann "wms_onlineresource" ebenfalls verkürzt werden: "http://127.0.0.1/cgi-bin/mapserv?"

Sieht gut aus, bis auf den leichten Versatz, und JOSM läuft deutlich schneller, als mit dem Import-Plugin.

Jetzt werde ich mich noch genauer mit der Erstellung der Tiles befassen.

Gruß,
Mondschein

Hi Mondschein,

Mondschein wrote:

Hier mein Ergebnis unter Debian Squeeze (kellerma: kennt auch 3857 🙂)

Ja, weiss ich inzwischen 😉

Ich hab' mir mal nach /usr/local/bin die gdal-1.8.1 installiert:
Das (debian-)gdalinfo ist (irgendwie) buggy, denn ein gdalinfo (der 1.8.1) liefert tatsächlich

$␣gdalinfo␣ergebnis1.tif
Driver:␣GTiff/GeoTIFF
Files:␣ergebnis1.tif
Size␣is␣2985,␣2144
Coordinate␣System␣is:
PROJCS["WGS␣84␣/␣Pseudo-Mercator",
GEOGCS["WGS␣84",
DATUM["WGS_1984",
<etc␣etc>

eines mit einem gdalwarp (von gdal-1.6) erstelten Tiffs,

Auch ich hab' noch einen Versatz, einmal ca. 4 m und einmal 1 m (zu den original jpegs per ImportImagePlugin),
je nach "shp-" oder "mmd-"Methode 😉

Ciao,
Frank

PS
Iiih, "libapache2-mod-fastcgi" ist ja aus non-free, lässt sich das durch "libapache2-mod-wsgi" (oder so) ersetzen?

kellerma wrote:

Auch ich hab' noch einen Versatz, einmal ca. 4 m und einmal 1 m (zu den original jpegs per ImportImagePlugin)

Fast identisch mit meinen Ergebnissen.

Die vollständige "Bilddienst-URL", welche JOSM (über Klick auf "Ebenen abfragen" ...) durch die GetCapabilities-Abfrage von meinem WMS-Server erhält ist:

http://127.0.0.1/cgi-bin/mapserv?map=/mapserver/data/osm.map&FORMAT=image/jpeg&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&Layers=AerowestOSM&

Gruß,
Mondschein

kellerma wrote:

Iiih, "libapache2-mod-fastcgi" ist ja aus non-free, lässt sich das durch "libapache2-mod-wsgi" (oder so) ersetzen?

Huh, ich sehe gleich mal nach.

Edit:
Funktioniert auch mit "libapache2-mod-fcgid" aus main, anstatt "libapache2-mod-fastcgi" aus non-free.

So,

bin fast geneigt, dass die ca. 4 m -Unterschied zwischen
Methode "TILEINDEX "/mapserver/data/tile.shp"
und
Methode "DATA "/mapserver/data/tile.tif"
daher kommen, dass mapserver proj.4 für die Projektion verwendet (statt gdal_translate), denn wenn ich
"init=epsg:3857"
statt
"init=epsg:31468"
im mapfile verwende, ergibt sich kein (sichtbarer) Unterschied mehr.

Hab' aber immer noch ca. 1,5 m zur "ImportImagePlugin-Projektion".

Egal, schluss für heut 😉

Ciao,
Frank

PS
Der Dienst von Aerowest steht wieder zur Verfügung 🙂

kellerma wrote:

die ca. 4 m -Unterschied

Bei mir ist das WMS-Bild gegenüber dem ImportImagePlugin-Bild um ca. 3 m nach Osten und 4,6 m nach Süden verschoben.
Ich hatte zuerst gehofft, dass der Fehler beim ImportImagePlugin liegt und nicht beim WMS-Server, aber ich habe das mit Bing und anderen Quellen verglichen und diese stimmen mit dem ImportImagePlugin genau überein.

Selbst wenn ich meinem WMS-Server nur die original JPEG-Bilder von Aerowest gebe und einen mit gdaltindex erstellten Index gebe, sind die Bilder verschoben.

Übrigens ist es JOSM etwas weniger träge, wenn man dem ImportImagePlugin ein JPEG komprimiertes TIF (kleinere Dateigröße) anstatt eines unkomprimierten TIF übergibt (nur für Merkator, sonst muss man den Umweg über das TIF nicht machen).

Gruß,
Mondschein

liegt vielleicht an der Definition von 3857. Zumindest gibts im Web ähnliche Meldungen. Man kann ja mal versuchen ob es mit 900913 besser läuft.

in
/usr/share/proj/epsg
sollte das stehen

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

Da wir mit der Ausflösung der Bilder in den Submeterbereich vorstoßen, sind 4 Meter Abweichung (auch bei mir) mit der "normalen" Transformation nicht hinnehmbar. Man sollte noch die amtliche Korrekturdatei BeTA2007 verwenden:

http://www.adv-online.de/icc/extdeu/bro … 8a438ad1b2
http://crs.bkg.bund.de/crseu/crs/descrt … s_beta.php
http://www.fossgis.de/konferenz/2010/at … s-2010.pdf

DD1GJ wrote:

Da wir mit der Ausflösung der Bilder in den Submeterbereich vorstoßen, sind 4 Meter Abweichung (auch bei mir) mit der "normalen" Transformation nicht hinnehmbar. Man sollte noch die amtliche Korrekturdatei BeTA2007 verwenden:

Nunja, so langsam grenzt das ja an Haarspalterei. Für eine korrekte Koordinatentransformation ist auch die Höhe über dem jeweiligen Bezugsellipsoid von Bedeutung. Die liegt uns aber bei 2D-Orthophotos sowieso nicht vor.

Gruß,
ajoessen

SunCobalt wrote:

liegt vielleicht an der Definition von 3857. Zumindest gibts im Web ähnliche Meldungen. Man kann ja mal versuchen ob es mit 900913 besser läuft.

in
/usr/share/proj/epsg
sollte das stehen

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

Hilft leider auch nicht, die Verschiebung bleibt exakt gleich.

DD1GJ wrote:

Da wir mit der Ausflösung der Bilder in den Submeterbereich vorstoßen, sind 4 Meter Abweichung (auch bei mir) mit der "normalen" Transformation nicht hinnehmbar. Man sollte noch die amtliche Korrekturdatei BeTA2007 verwenden:

http://www.adv-online.de/icc/extdeu/bro … 8a438ad1b2
http://crs.bkg.bund.de/crseu/crs/descrt … s_beta.php
http://www.fossgis.de/konferenz/2010/at … s-2010.pdf

Auch mit der Datei BETA2007.gsb bleibt die Verschiebung exakt gleich, egal ob ich nach 4326, 3857 oder 900913 transformiere und egal ob ich für Quelle und/oder Ziel die Datei BETA2007.gsb verwende oder nicht.
Ich habe alle Kombinationen getestet.

🙁

Gruß,
Mondschein

das hier hab ich gefunden "EPSG:3857 didn't exist when 1.6.1 was released, afaik, so it definitely wouldn't be supported."
Wenn Du mit Mapserver arbeitest, brauchst Du die Bilder eigentlich gar nicht in 3857 umzuwandeln. JOSM holt sich die in 4326.

SunCobalt wrote:

Wenn Du mit Mapserver arbeitest, brauchst Du die Bilder eigentlich gar nicht in 3857 umzuwandeln. JOSM holt sich die in 4326.

Ja, leider ist es bei mir aber völlig egal, ob ich die Bilder direkt von Aerowest herunterlade und die JPEG-Dateien zusammen mit den JGW-Dateien unverändert dem WMS-Server gebe und den auf der Aerowest-Seite für diese konkreten Bilder angegebenen EPSG-Wert "31467" im Mapfile angebe oder ob ich die JPEG- und JGW-Dateien vorher in ein anderes Format bzw. andere Projektion umwandle.
Die Verschiebung bleibt immer exakt gleich.

Gibt es denn hier jemanden, der keine Probleme mit der Verschiebung der Aerowest-Bilder bei Verwendung eines WMS-Servers in JOSM hat?

Gruß,
Mondschein

Hi,

SunCobalt wrote:

das hier hab ich gefunden "EPSG:3857 didn't exist when 1.6.1 was released, afaik, so it definitely wouldn't be supported."
Wenn Du mit Mapserver arbeitest, brauchst Du die Bilder eigentlich gar nicht in 3857 umzuwandeln. JOSM holt sich die in 4326.

Nur dass zwischen 3857 und 4326 nicht so wirklich groß der Unterschied ist 😉

Vermute, dass "+datum=potsdam" mit reingspielen könnte. Jenes ist unter "proj" immer noch mit dem alten 1950er 3-parametrigen
Wert fest einkompiliert, evtl. benutzt gdal 1.8/ImportImagePlugin hierfür schon die 7-parametrische Helmert-Trafo (?)

Heute abend mal gucken.

Ciao,
Frank

PS

JOSMs␣WMS-Plugin␣behandelt␣3857␣momentan,␣als␣ob␣es␣4326␣wäre.␣Aufgrund
der␣normalerweise␣angeforderten␣kleinen␣Kachelgrößen␣und␣hohen␣Zoomstufen
können␣wir␣mit␣den␣entstehenden␣Verzerrungen␣leben.␣Sinnvoller␣wäre
natürlich␣ein␣Capabilities-Request␣im␣WMS-Plugin␣und␣dann␣entsprechende
angepasste␣Anfragen.␣Aber␣es␣gibt␣so␣viel,␣was␣zu␣tun␣ist...

Das ist Dirk Stöcker 2009, weiss aber nicht, ob es immer noch so ist ...

kellerma wrote:

ImportImagePlugin

Wo finde ich den den Quellcode?

Edit:
Gefunden:
http://svn.openstreetmap.org/applicatio … agePlugin/

kellerma wrote:

JOSMs␣WMS-Plugin␣behandelt␣3857␣momentan,␣als␣ob␣es␣4326␣wäre.␣Aufgrund
der␣normalerweise␣angeforderten␣kleinen␣Kachelgrößen␣und␣hohen␣Zoomstufen
können␣wir␣mit␣den␣entstehenden␣Verzerrungen␣leben.␣Sinnvoller␣wäre
natürlich␣ein␣Capabilities-Request␣im␣WMS-Plugin␣und␣dann␣entsprechende
angepasste␣Anfragen.␣Aber␣es␣gibt␣so␣viel,␣was␣zu␣tun␣ist...

Das ist Dirk Stöcker 2009, weiss aber nicht, ob es immer noch so ist ...

Wenn das mit unserem Versatz zusammenhängt, dann müsste das doch auch Bing-WMS betreffen? Edit: Falsch, Bing ist nicht WMS.
Doch wenn ich die Bing-WMS-Bilder mit den ImportImagePlugin-Bildern vergleiche, so kann ich hier keinen Versatz feststellen.

Gruß,
Mondschein

Um auszuschließen, dass das Problem bei JOSM liegt, habe ich meinen WMS-Layer in Quantum GIS geladen und die Position mit Hilfen von OSM-Testdaten verglichen.
Das Ergebnis:
Quantum GIS zeigt die Bilder exakt an der gleichen Stelle an, wie JOSM, also mit dem gleichen Versatz.

Vermutlich liegt das Problem also bei GDAL, weshalb ich mir das nochmals genauer angesehen habe:

Zuerst habe ich das JPEG-Bild von Aerowest in ein GeoTiff umgewandelt, ohne dabei die Projektion zu verändern:

gdal_translate␣-a_srs␣epsg:31467␣-of␣GTiff␣exportimg_direkt_von_aerowest.jpg␣epsg_31467.tif

Das schreibt die Koordinaten aus der zugehörigen jgw-Datei in den Header des GeoTiff.
Diese Koordinaten habe ich dann mit

gdalinfo␣epsg_31467.tif

ausgelesen.

"Pixel Size" ist hier mit der Pixelgröße aus der jgw-Datei (1. und 4. Zeile) identisch.
"Origin" weicht hingegen leicht vom Ursprung aus der jgw-Datei (5. und 6. Zeile) ab und zwar um etwa die Hälfte der Größe eines Pixels.
Vermutlich nimmt GDAL hier an, dass die Koordinaten aus der jgw-Datei am linken oberen Rand eines Pixels beginnen, und rechnet das auf die Mitte des Pixels um.
Ich weiß nicht, ob das so spezifiziert ist, aber selbst wenn das ein Fehler sein sollte, so wäre dieser zu klein, um die Abweichungen im Meter-Bereich zu erklären.

Daraufhin habe ich das soeben erstellte GeoTiff in EPSG 4326 umgewandelt:

gdalwarp␣-s_srs␣epsg:31467␣-t_srs␣epsg:4326␣-of␣GTiff␣epsg_31467.tif␣epsg_4326.tif

Dann habe ich das epsg_4326.tif mit dem "ImportImagePlugin" in JOSM geladen und festgestellt, dass es den bekannten Versatz aufweist.
Also hab ich mit dem Mauszeiger die Koordinaten der linken oberen Ecke des Bildes (die Koordinaten des Mauszeigers werden bei JOSM links unten angezeigt) ausgelesen und festgestellt, dass diese mit der Ausgabe von

gdalinfo␣epsg_4326.tif

(siehe "Origin") übereinstimmen.

Also berechnet GDAL hier definitiv beim der Umprojektion falsche Koordinaten!

Weiß jemand, ob das bei der neuesten GDAL-Version (1.8) auch so ist bzw. das Problem bekannt ist?

Ist dieses Problem bei den Betreibern von WMS-Servern (welche GDAL verwenden) noch nicht aufgetreten oder hat das nur keiner bemerkt?

Gruß,
Mondschein

Hallo Mondschein,

kannst Du bitte mal bei Dir testen?

Im mapfile:
"init=epsg:31466"

und dann im /usr/share/proj/epsg
statt

␣<31466>␣+proj=tmerc␣+lat_0=0␣+lon_0=6␣+k=1␣+x_0=2500000␣+y_0=0␣+ellps=bessel␣+datum=potsdam␣+units=m␣+no_defs␣␣<>

nun

␣<31466>␣+proj=tmerc␣+lat_0=0␣+lon_0=6␣+k=1␣+x_0=2500000␣+y_0=0␣+ellps=bessel␣+towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.70␣+units=m␣+no_defs␣␣<>

Danke schön.

Ciao,
Frank

kellerma wrote:

kannst Du bitte mal bei Dir testen?

Hm, dazu brauche ich dann aber ein EPSG 31466 Bild, oder?
Das habe ich aber z.Zt. nicht.
Welche Orte bei Aerowest haben denn diesen EPSG-Wert, damit ich mir das ggfs. besorgen kann.

Gruß,
Mondschein

Ach so, dachte, Du wärst ein Aachener 😉

Dann nimm halt

<31467>␣+proj=tmerc␣+lat_0=0␣+lon_0=9␣+k=1␣+x_0=3500000␣+y_0=0␣+ellps=bessel␣+datum=potsdam␣+units=m␣+no_defs␣␣<>

das

<31467>␣+proj=tmerc␣+lat_0=0␣+lon_0=9␣+k=1␣+x_0=3500000␣+y_0=0␣+ellps=bessel␣+towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.70␣+units=m␣+no_defs␣␣<>

Ciao,
Frank

PS
gdal-1.8.1 zu kompilieren auf Debian 6 ist pretty easy:
$ cd gdal-1.8.1/
$ ./configure
$ make

1. make install
   
2. echo "/usr/local/lib" >> /etc/ld.so.conf
   
3. ldconfig
   

Hat aber auf meinen kleinen netbook ca. 1 h gebraucht 😉

kellerma wrote:

Dann nimm halt

<31467>␣+proj=tmerc␣+lat_0=0␣+lon_0=9␣+k=1␣+x_0=3500000␣+y_0=0␣+ellps=bessel␣+datum=potsdam␣+units=m␣+no_defs␣␣<>

das

<31467>␣+proj=tmerc␣+lat_0=0␣+lon_0=9␣+k=1␣+x_0=3500000␣+y_0=0␣+ellps=bessel␣+towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.70␣+units=m␣+no_defs␣␣<>

Das hat keinerlei Veränderung bewirkt, Versatz identisch.
Deshalb habe ich ein Bild mit verändertem 31467 Eintrag und eines mit unverändertem 31467 Eintrag erzeugt (beide aus gleicher JPEG-Datei) und dann die beiden Ausgaben von gdalinfo mit diff verglichen und das zeigt, bis auf den Dateinamen, keine Unterschiede an.
Ich habe den Verdacht, GDAL verwendet die Info gar nicht.

kellerma wrote:

gdal-1.8.1 zu kompilieren auf Debian 6 ist pretty easy:

Und hat es geholfen?

-

Hi,

Mondschein wrote:

Das hat keinerlei Veränderung bewirkt, Versatz identisch.
Deshalb habe ich ein Bild mit verändertem 31467 Eintrag und eines mit unverändertem 31467 Eintrag erzeugt (beide aus gleicher JPEG-Datei) und dann die beiden Ausgaben von gdalinfo mit diff verglichen und das zeigt, bis auf den Dateinamen, keine Unterschiede an.
Ich habe den Verdacht, GDAL verwendet die Info gar nicht.

ne ne ne, "proj" wird vom mapserver verwendet wenn er die "init=epsg:31467"-Dateien
umprojeziert muss um dem client (JOSM) epsg:4326-Bilder zu liefern. Das hat bei mir einen Versatz von ca. 3-4 m.
Mit der verbesserten "postdam"-Defintion mache ich das wieder weg.
Für Süddeutschland gäbe es sogar noch ein
potsdam "towgs84=597.1,71.4,412.1,0.894,0.068,-1.563,7.58" "Germany (West - South - 47d00N to
50d20'N)" "Accuracy <1m"

Mondschein wrote:

kellerma wrote:

gdal-1.8.1 zu kompilieren auf Debian 6 ist pretty easy:

Und hat es geholfen?

Debian 6 eigenes gdal (1.6) ist bei mir total daneben: "gdalinfo" geht bei 3857-proj. gar nicht und der Versatz
im JOSM ca. 150 m !
Vielleicht hab' ich sie auch beim "Rumspielen mit libgeotiff" zerschossen 😉

Ciao,
Frank

mmd wrote:

Im Kontextmenü könnte man ja über "Neuen Versatz" den Aerowest-Layer an Bing anpassen.

Wobei ich Bing nicht unbedingt als Referenz verwenden würde.

mmd wrote:

Post #120 habe ich noch nicht ausprobiert.

Bin auf den Vergleich gespannt.

kellerma wrote:

ne ne ne, "proj" wird vom mapserver verwendet wenn er die "init=epsg:31467"-Dateien
umprojeziert muss um dem client (JOSM) epsg:4326-Bilder zu liefern.

Aber mapserver verwendet doch dafür wiederum die gdal-Lib, oder nicht?

Ich werde das gleich nochmal Testen.
Gibst du deinem Mapserver direkt die original Aerowest-Bilder (jpg und jgw) oder gibst du ihm ein EPSG 3146x GeoTiff?

Mondschein wrote:

kellerma wrote:

ne ne ne, "proj" wird vom mapserver verwendet wenn er die "init=epsg:31467"-Dateien
umprojeziert muss um dem client (JOSM) epsg:4326-Bilder zu liefern.

Aber mapserver verwendet doch dafür wiederum die gdal-Lib, oder nicht?

Ich werde das gleich nochmal Testen.
Gibst du deinem Mapserver direkt die original Aerowest-Bilder (jpg und jgw) oder gibst du ihm ein EPSG 3146x GeoTiff?

Mapserver nimmt die epsg File. Bei gdal steht "A list of EPSG coordinate systems can be found in the GDAL data files gcs.csv and pcs.csv."

Mondschein wrote:

Aber mapserver verwendet doch dafür wiederum die gdal-Lib, oder nicht?

Einigen wir uns auf ein Unentschieden? 😉

1. ldd /usr/lib/cgi-bin/mapserv
   

...
libproj.so.0 => /usr/lib/libproj.so.0 (0x00007fecc36d7000)
libgdal1.6.0.so.1 => /usr/lib/libgdal1.6.0.so.1 (0x00007fecc2d64000)
...

Mondschein wrote:

Ich werde das gleich nochmal Testen.
Gibst du deinem Mapserver direkt die original Aerowest-Bilder (jpg und jgw) oder gibst du ihm ein EPSG 3146x GeoTiff?

gdal_translate -a_srs epsg:31468 -of GTiff exportimg2011729249507856.jpg nbg4.tif

also als GeoTiff

Ciao,
Frank

-

Gut, mit den verbesserten Koordinateninformationen ist der Versatz jetzt max. 1 m. 😄

kellerma wrote:

Einigen wir uns auf ein Unentschieden? 😉

Ok. 🙂

SunCobalt wrote:

Mapserver nimmt die epsg File. Bei gdal steht "A list of EPSG coordinate systems can be found in the GDAL data files gcs.csv and pcs.csv."

Achso, auch gut. 🙂
Weißt du zufällig auch, wie ich GDAL die verbesserten Koordinateninformation übergeben kann, das mit dem epsg-Datei funktioniert in diesem Fall, wie soeben schmerzhaft festgestellt, nicht.
Denn eine on-the-fly-Umwandlung durch den Mapserver von EPSG 3146x nach EPSG 4326 ist mir zu langsam, ich hätte die Bilder gerne direkt als EPSG 4326 vorliegen, genau das möchte JOSM nämlich haben.

Ich fasse kurz zusammen:

• JOSM fragt den WMS-Server nach EPSG 4326 (WGS84 Geografisch) Tiles
• Wir möchten in JOSM gerne mit EPSG 3857 (Merkator) arbeiten, wegen Winkeln, Kreisen u.s.w.
• Wir möchten einen möglichst geringen Versatz

Folglich

• stellen wir dem Mapserver die Daten in der Originalprojektion von Aerowest (EPSG 3146x, ...) z.B. als GTiff oder HFA zur Verfügung und lassen ihn EPSG 4326 Tiles ausliefern.
• verbessern wir die Projektionsdaten in der epsg-Datei (z.B. /usr/share/proj/epsg), z.B.

#␣DHDN␣/␣3-degree␣Gauss-Kruger␣zone␣3
<31467>␣+proj=tmerc␣+lat_0=0␣+lon_0=9␣+k=1␣+x_0=3500000␣+y_0=0␣+ellps=bessel␣+towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.70␣+units=m␣+no_defs␣␣<>

Das Mapfile sieht z.B. so aus:

MAP
NAME␣␣␣␣OSM-WMS
STATUS␣␣␣␣ON
UNITS␣␣␣␣METERS

PROJECTION
"init=epsg:31467"
END

WEB
METADATA
"wms_title"␣␣␣␣"WMS-Server"
"wms_onlineresource"␣␣␣␣"http://127.0.0.1/cgi-bin/mapserv?"
"wms_srs"␣␣␣␣"EPSG:4326"
END
END

LAYER
STATUS␣␣␣␣ON
NAME␣␣␣␣"AerowestOSM"

DATA␣␣␣␣"/mapserver/data/epsg-31467.tif"

METADATA
"wms_title"␣␣␣␣"Luftbilder"
"wms_srs"␣␣␣␣"EPSG:4326"
END

TILEITEM␣"location"
TYPE␣RASTER
END
END

An der Geschwindigkeit muss noch gearbeitet werden, Vorverarbeitung, Index u.s.w.

Gruß,
Mondschein

-

Mondschein wrote:

SunCobalt wrote:

Mapserver nimmt die epsg File. Bei gdal steht "A list of EPSG coordinate systems can be found in the GDAL data files gcs.csv and pcs.csv."

Achso, auch gut. 🙂
Weißt du zufällig auch, wie ich GDAL die verbesserten Koordinateninformation übergeben kann, das mit dem epsg-Datei funktioniert in diesem Fall, wie soeben schmerzhaft festgestellt, nicht.
Denn eine on-the-fly-Umwandlung durch den Mapserver von EPSG 3146x nach EPSG 4326 ist mir zu langsam, ich hätte die Bilder gerne direkt als EPSG 4326 vorliegen, genau das möchte JOSM nämlich haben.

Hab mich schon gewundert, dass dies bei Dir nicht funktioniert, aber Du benutzt ja gdal 1.6 😉
Nimm die 1.8er Version und mit
gdalwarp -s_srs epsg:31468 -t_srs epsg:4326 -of GTiff 31468.tif 4326.tif
wird Dir so geliefert, als würde der mapserver mit Potsdam-korrektur die 31468.tif direkt ausliefern.

Ciao,
Frank

Hi,

mmd wrote:

Ergebnis ist sichtbar besser geworden, nur noch ganz minimaler Versatz im Vergleich zu bing 🙂

Gruß,

Da Du GK2 benutzt, kommst Du evtl. aus der Aachener Gegend, Du könntest noch
potsdam "towgs84=584.8,67.0,400.3,0.105,0.013,-2.378,10.29" "Germany (West - Middle - 50d20'N to
52d20'N)" "Accuracy <1m"
testen, ob das vielleicht noch etwas bringt.

Evtl. die hier schon erwähnten die Post #113 erwähnten Beta2007, aber der Effekt wird wohl noch geringer sein.

Ciao,
Frank

Mondschein wrote:

Weißt du zufällig auch, wie ich GDAL die verbesserten Koordinateninformation übergeben kann

So geht es:

PROJECTION
"init=epsg:31467"

#"Germany␣(Whole␣Country)"␣"Accuracy␣3m"
"towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.70"

#"Germany␣(Sachsen)"␣"Accuracy␣<1m"
#"towgs84=612.4,77.0,440.2,-0.054,0.057,-2.797,2.55"

#"Germany␣(Thüringen)"␣"Accuracy␣<1m"
#"towgs84=599.4,72.4,419.2,-0.063,-0.022,-2.723,6.46"

#"Germany␣(West␣-␣North␣-␣52d20'N␣to␣55d00'N)"␣"Accuracy␣<1m"
#"towgs84=590.5,69.5,411.6,-0.796,-0.052,-3.601,8.30"

#"Germany␣(West␣-␣Middle␣-␣50d20'N␣to␣52d20'N)"␣"Accuracy␣<1m"
#"towgs84=584.8,67.0,400.3,0.105,0.013,-2.378,10.29"

#"Germany␣(West␣-␣South␣-␣47d00N␣to␣50d20'N)"␣"Accuracy␣<1m"
#"towgs84=597.1,71.4,412.1,0.894,0.068,-1.563,7.58"
END

Gruß,
Mondschein

So,

die spannende Frage ist noch, woher die ~ 1m Diskrepanz zwischen Mapserver (incl. Potsdam-Korrektur)
und dem ImportImagePlugin stammen?

Muessen wir neben der Potsdam (evtl. Beta2007) noch eime weitere Korrektur [die wir
noch nicht bedacht haben] hinzufuegen oder "verhaut" sich das ImportImagePlugin nur?

In Rostock gibt es ja Daten vom Vermessungsamt als Import, wenn ich das aber richtig gelesen habe,
sind die zum Teil um 1 m kuenstlich verschlechert worden.
Leider reichen die Aerowestbilder von Nuernberg nicht bis nach Neunkirchen am Sand., denn dort haetten wir
auch Haeuser aus einem Katasterimport 🙁

Hinzu kommt, wir kennen die Labegenauigkeit der Aerobilder auch nicht.

Ciao,
Frank

kellerma wrote:

Hinzu kommt, wir kennen die Labegenauigkeit der Aerobilder auch nicht.

Ciao,
Frank

Du kannst ja spaßeshalber einfach mal in Sachsen rumprobieren und dann mit den Luftbildern des LVA vergleichen. www.mittelsachsen-atlas.de ist eine OSM Karte mit amtlichen Luftbildern im Hintergrund. Allerdings solltest du vorher schauen welche Objekte sich zum vergleichen eignen, denn die Bilder in Dresden sind doch schon etwas älter. Wie es in Chemnitz oder Leipzig aussieht kann ich nicht sagen.

hi !

ich wollte nochmal nachfragen - die Frage hatte ich zwar schon mal gestellt aber wenn ich nichts übersehe keine Antwort gefunden.

Wenn ich das Bild in GeoTiff konvertiere mit GDAL dann bekomme ich unter JOSM 4279 und Image.. 26413 die Meldung

Error while creating Image Layer: null

unabhängig ob in JOSM Mercator oder WGS eingestellt ist.

Kann mir einer weiterhelfen - möchte doch auch zeichnen !

Gruß Jan :-)

kellerma wrote:

Hinzu kommt, wir kennen die Labegenauigkeit der Aerobilder auch nicht.

Ich habe bei mir in der Gegend ein paar Kanaldeckel mit dem aktuellen amtlichen Luftbild (ATKIS-DOP25, EPSG:31467) mittels QGIS verglichen. Die Abweichung ist kleiner als die Pixelgröße.

Bei dem ImportImagePlugin scheint irgendwas nicht zu stimmen. Vergangenen Mittwoch funktionierte es (4 m Abweichung) und nach einem Update zwei Tage später stimmt überhaupt nichts mehr.

Anstatt überall dezentrale WMS-Server aufzustellen, sollte man sich über ein Plugin ähnlich dem für das französische Kataster Gedanken machen.

Lübeck wrote:

hi !

ich wollte nochmal nachfragen - die Frage hatte ich zwar schon mal gestellt aber wenn ich nichts übersehe keine Antwort gefunden.

Wenn ich das Bild in GeoTiff konvertiere mit GDAL dann bekomme ich unter JOSM 4279 und Image.. 26413 die Meldung

Error while creating Image Layer: null

unabhängig ob in JOSM Mercator oder WGS eingestellt ist.

Kann mir einer weiterhelfen - möchte doch auch zeichnen !

Falls es dich tröstet: Bei mir kommen die Bilder in JOSM auch nur allenfalls hochkant gequetscht :-(
Musst halt warten, bis das plugin mal richtig funktioniert. Vielleicht tuts nur unter Linux-Systemen, weil irgendwas im Windows java anders ist?

Gruß,
ajoessen

hi !

danke - dann muss ich mal meine linux-partition heute abend anwerfen !

bin schon gepannt !

gruß Jan :-)

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.

Lübeck wrote:

Wenn ich das Bild in GeoTiff konvertiere mit GDAL dann bekomme ich unter JOSM 4279 und Image.. 26413 die Meldung

Error while creating Image Layer: null

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/viewtopi … 65#p181065

DD1GJ wrote:

kellerma wrote:

Hinzu kommt, wir kennen die Labegenauigkeit der Aerobilder auch nicht.

Ich habe bei mir in der Gegend ein paar Kanaldeckel mit dem aktuellen amtlichen Luftbild (ATKIS-DOP25, EPSG:31467) mittels QGIS verglichen. Die Abweichung ist kleiner als die Pixelgröße.

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

kellerma wrote:

Muessen wir neben der Potsdam (evtl. Beta2007) noch eime weitere Korrektur [die wir
noch nicht bedacht haben] hinzufuegen oder "verhaut" sich das ImportImagePlugin nur?

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.

kellerma wrote:

Hinzu kommt, wir kennen die Labegenauigkeit der Aerobilder auch nicht.

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

Gruß,
Mondschein

viw wrote:

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.

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

Gruß,
ajoessen

ajoessen wrote:

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

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

md5sum
8d7c626404367155c10df5a7fcb2c593␣ImportImagePlugin.jar

Gruß,
Mondschein

Mondschein wrote:

Lübeck wrote:

Wenn ich das Bild in GeoTiff konvertiere mit GDAL dann bekomme ich unter JOSM 4279 und Image.. 26413 die Meldung

Error while creating Image Layer: null

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/viewtopi … 65#p181065

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

mmd wrote:

gdal_merge.py␣-o␣output.tif␣-co␣TILED=YES␣-co␣COMPRESS=JPEG␣-n␣0␣-of␣GTIFF␣export*.jpg
gdalwarp␣-s_srs␣'+proj=tmerc␣+lat_0=0␣+lon_0=6␣+k=1␣+x_0=2500000␣+y_0=0␣+ellps=bessel␣+towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.70␣+units=m␣+no_defs␣␣<>'␣-t_srs␣epsg:3857␣output.tif␣result.tif␣-co␣COMPRESS=JPEG␣-co␣TILED=YES

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/viewtopi … 28#p181728
Das wird nicht mehr nötig sein, wenn ich mein GDAL-Problem gelöst habe.

Gruß,
Mondschein

Mondschein wrote:

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

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

kellerma wrote:

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?

Der wohnt in ner WG mit Edwin

Hallo Jan,

hoffe, Du verstehtst ein bisschen Spass 😉

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&lo … 0TFFFFFTFF

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

Lübeck wrote:

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

Ciao,
Frank

Mondschein wrote:

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

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

1. 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/ind … te_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:

Error creating image file on disk

Die Festplatte des Servers ist anscheinend wieder voll.

holgermappt wrote:

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.

Oh, das ist aber ich schön...

holgermappt wrote:

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.

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

kellerma wrote:

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

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/aer … server.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/aer … h_bing.jpg
Edit2: und nochmal zum Katasturm http://www.tappenbeck.net/forum/osm/aer … taster.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 .-)

Lübeck wrote:

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/aer … server.jpg

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

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.

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

• ->Layer Preview ... den Punkt habe ich nicht finden können !
  

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

• 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 ?
  

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,

wambacher wrote:

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.

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

kellerma wrote:

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

Ich weiß ja nicht, welcher frederik da zugange war:
https://github.com/openstreetmap/josm-p … Plugin/src

Gruß,
ajoessen

ajoessen wrote:

kellerma wrote:

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

Ich weiß ja nicht, welcher frederik da zugange war:
https://github.com/openstreetmap/josm-p … Plugin/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/aer … uebeck.jpg

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

Gruß Jan :-)

kellerma wrote:

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" 🙁

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/mod … 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

Vielleicht liesse sich die nazgul, ähem, nadgrids Beta2007 auch im ImportImagePlugin verwenden? 🙂

Ciao,
Frank

kellerma wrote:

nach ein bisschen Rumgesuche würd' ich sagen, "ImportImagePlugin" benutzt die "geotools" und insbesondere
http://svn.osgeo.org/geotools/trunk/mod … 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]

Tatsächlich:

31469␣"DHDN␣/␣3-degree␣Gauss-Kruger␣zone␣5",␣[...]␣TOWGS84[612.4,␣77.0,␣440.2,␣-0.054,␣0.057,␣-2.797,␣2.55]␣[...]
31468␣"DHDN␣/␣3-degree␣Gauss-Kruger␣zone␣4",␣[...]␣TOWGS84[612.4,␣77.0,␣440.2,␣-0.054,␣0.057,␣-2.797,␣2.55]␣[...]
31467␣"DHDN␣/␣3-degree␣Gauss-Kruger␣zone␣3",␣[...]␣TOWGS84[612.4,␣77.0,␣440.2,␣-0.054,␣0.057,␣-2.797,␣2.55]␣[...]
31466␣"DHDN␣/␣3-degree␣Gauss-Kruger␣zone␣2",␣[...]␣TOWGS84[612.4,␣77.0,␣440.2,␣-0.054,␣0.057,␣-2.797,␣2.55]␣[...]

🙄

Das erklärt natürlich die seltsamen Ergebnisse beim ImportImagePlugin.

kellerma wrote:

Das ist
"Germany (Sachsen)" "Accuracy <1m"
und erklärt die "1 m Abweichung", zuminderst in Nürnberg 😉

Nicht nur in Nürnberg. 🙂

Also besser das ImportImagePlugin bis auf Weiteres [1] nicht verwenden (außer in Sachsen 😉) und die Korrekturdaten "BeTA2007" bzw. die Werte aus #137 verwenden, oder?

[1]:

kellerma wrote:

Vielleicht liesse sich die nazgul, ähem, nadgrids Beta2007 auch im ImportImagePlugin verwenden? 🙂

Gruß,
Mondschein

Lübeck wrote:

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

Mein Tip, dem Geoserver eine andere Kachel mit gleichem Namen unterzuschieben, scheint nicht zu klappen :-(
Also muß man wohl doch für jedes Aerowest-Bild einen neuen Store und Layer anlegen.

Man kann die Layer aber in einer Layer Group zusammenfassen, und nur diese in josm laden. Nur sinkt die Performance des Geoservers dadurch, und ich bekomme desöfteren nur einzelne Kacheln, und den Rest des Bildschirms weiß.

Gruß,
ajoessen

Hi Mondschein,

Mondschein wrote:

Also besser das ImportImagePlugin bis auf Weiteres [1] nicht verwenden (außer in Sachsen 😉) und die Korrekturdaten "BeTA2007" bzw. die Werte aus #137 verwenden, oder?

Wir dürfen nicht vergessen, dass sicher nicht wenige Mapper gibt, die weder gdal/proj/... noch MapServer/GeoServer/... noch qgis/grass/... haben und
"nur" JOSM benutzen.

Eine "1 m Sachsen-Korrektur" dürfte _deutschlandweit_ immer noch besser sein also gar keine Potsdam-Korrektur.
Ob _deutschlandweit_ "1 m Sachsen-Korrektur" oder "3m Deutschland-Korrektur" besser sind vermag ich nicht zu sagen.

Die JAVA-Lib geotools ist ziemlich heftig, kein Wunder dass sie im "JOSM-svn" nur als BLOB und nicht als Source vorliegt.
Wenn, dann müßte der "Fehler" dort gefixed werden.

_Falls_ jemand gdal benutzt, lautet die Empfehlung 1.8.0 oder 1.8.1.

_Falls_ jemand MapServer lokal verwendet, lautet die Empfehlung - wie Du schon geschrieben hast -

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

Die Datei BETA2007.gsb gibt es hier: http://crs.bkg.bund.de/crseu/crs/descrt … TA2007.gsb (es sind nur 85 kB)

@ajoessen/Lübeck
Vielleicht könntet Ihr noch eine entsprechende GeoServer-Config posten.

Danke schön.

Ciao,
Frank

kellerma wrote:

@ajoessen/Lübeck
Vielleicht könntet Ihr noch eine entsprechende GeoServer-Config posten.

Da bin ich ein wenig überfordert. Ich bin ja schon froh, dass ich mit dem Geoserver was zu sehen bekomme.

Gruß,
ajoessen

hi!

das mit dem Geoserver ist keine Allerwelt-Lösung !!!!

Aufgebaut habe ich mir das nach der Beschreibung aus dem Posting #164 / Seite 7 - dann lade ich mir an einem großen Bildschirm die Bilder 1:500 herunter und verschmelze diese mit gdal_merge...

Dann binde ich diese ein...

Alleine das herunterladen ist ein KRAMPF - da muss es selbst bei einer lokalen Server-Anbindung eine andere Lösung geben. Am 17 Zoll Monitor ist das schon eine Strafe für sich.

Ich habe nun mit diesen Dingen beruflich auch Berührungspunkte - sonsten wird uns auch das Jahr Luftbilder nicht viel weiterbringen in der Masse der Anwender.

Einziger Vorteil ist die Nutzung auch im Zug - Offline.

Da in der ML keine Diskussion läuft und hier auch keine Lösung in sicht ist - bin ich sehr gespannt was die nächsten Tage und Wochen bringen.

Gruß Jan :-)

Lübeck wrote:

hi!

das mit dem Geoserver ist keine Allerwelt-Lösung !!!!
<etc etc pp>

Sehr richtig!
Umd wie schaut jetzt eine Geoserverconfig mit nadgrids aus?

Ciao,
Frank

Hhhmmm,
und wie funktioniert das jetzt?

Hi,

Sonny76 wrote:

Hhhmmm,
und wie funktioniert das jetzt?

sorry wen ich Dich da enttäuschen muß, aber eine einfache Lösung a la
JOSM -> Einstelllungen -> TWM/WMS -> Bilddienst-URL hinzufügen -> FERTIG!
gibt es derzeit nicht.
Und es wird auch weiterhin keine geben.
Zuminderst solange nicht bis sich ein "Provider" (für eine für Dich interessante Region) findet.

Ciao,
Frank

@Mondschein

Sollen wir mal unsere Debian-Erkenntnisse gesammelt ins wiki stellen?

Ciao,
Frank

Ja, ich denke am Wochenende werde ich dafür wieder Zeit haben.

Gruß,
Mondschein

Hi,

Es gibt jetzt eine neue Version des ImportImage Plugins (26452). Die Darstellung in Mercator Projection sollte jetzt funktionieren.

Könnte jemand noch mal genauer erklären, was es mit der Datumskorrektur auf sich hat? Ich werde aus den verschiedenen Angaben gerade nicht so recht schlau. (Bitte auf http://josm.openstreetmap.de/ticket/6665 posten)

kellerma wrote:

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

Entwickelt scheinbar hat es die "Skobbler-Truppe" im letzten Jahr ...

Frank

Fairerweise muss man sagen, dass Oliver Kühn und Skobbler nichts mit diesem ziemlich verbuggten Plugin zu tun haben, die Namensgleichheit (bis auf die Ü-Punkte) scheint Zufall zu sein. (Wenn es jemand schafft, zu den Autoren Kontakt auf zu nehmen, bitte Bescheid sagen!)

bastik wrote:

Hi,

Es gibt jetzt eine neue Version des ImportImage Plugins (26452). Die Darstellung in Mercator Projection sollte jetzt funktionieren.

Könnte jemand noch mal genauer erklären, was es mit der Datumskorrektur auf sich hat? Ich werde aus den verschiedenen Angaben gerade nicht so recht schlau. (Bitte auf http://josm.openstreetmap.de/ticket/6665 posten)

kellerma wrote:

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

Entwickelt scheinbar hat es die "Skobbler-Truppe" im letzten Jahr ...

Frank

Fairerweise muss man sagen, dass Oliver Kühn und Skobbler nichts mit diesem ziemlich verbuggten Plugin zu tun haben, die Namensgleichheit (bis auf die Ü-Punkte) scheint Zufall zu sein. (Wenn es jemand schafft, zu den Autoren Kontakt auf zu nehmen, bitte Bescheid sagen!)

Supi!

Danke für die Klarstellung bzgl. Skobber, unschuldig verdächtigt 😉

Ciao,
Frank

bastik wrote:

Hi,

Es gibt jetzt eine neue Version des ImportImage Plugins (26452). Die Darstellung in Mercator Projection sollte jetzt funktionieren.

Merci, jetzt sehe ich auch was ;-)

Versatz zu bing sind ein paar Meter, das stört mich aber wenig. Ich weiß ja nicht, wer von beiden nun Recht hat.

Gruß,
ajoessen

Hallo!

Warum freuen sich so wenige? 😉

"Darstellung in Mercator Projection" bedeutet,
dass man nun "out of box" die Bilder benutzen kann ohne lästiges Hin- und herprojezieren
dass man die Bilder von jpeg nicht nach GTif per gdal_translate/gdalwarp transformierunen muss.
Und das Plugin unter "Merkator" lief besser als unter "WGS84 Geographisch" (bei mir zuminderst 🙂

Ciao,
Frank

Is alles richtig...aber die ToolChain ist alles andere als nutzerfreundlich. Ordentlich RAM frisst es auch noch.

"Batch-Laden" von Bildern wäre noch was feines. Also 5 Bilder auf einmal auswählen, die dann automatisch nach einander mit der einmal eingestellten Projektion geladen werden.

Für alle, die nicht ihre Heimat mit allerlei Daten versehen wollen/können, sondern einfach Luftbilder abzeichnen wollen, gibt es effektivere Bilder anderer Gegenden 😉

und die Auswahl der Gebiete ist sehr beschränkt. Oft sind die DOPs jetzt da verfügbar, wo eh schon gute Luftbilder von Bing vorhanden waren.

Einfach ist Bing, stimmt: Hintergrund -> Bing Sat
aber

• Bing@Nürnberg - 2001 @ 80 cm
  
• Aerowest@Nürnberg - 2009 @ 10 cm (jetzt und heute)
  
• Bing@Nürnberg - 2012 @ 30 cm nicht vor einem Jahr
  

(denn wenn mir die Juni-Abdeckung des Adv. Aerial Pro. anschaue, haben sie Null qm von Dtl. bisher überflogen)

You see?

Ciao,
Frank

I see, aber es gibt auch noch andere Städte in DE als Nürnberg. In vielen ist der Sprung nicht groß genug für die Hürde. Und in Nürnberg würde ich jetzt mal blind darauf tippen, dass es 50cm sind

Ich sagte doch extra: Für Leute, die ihre Heimat komplettieren wollen, ist es ein Fortschritt, wenn auch mit Hürden verbunden. Für Mapper, deren Heimat nicht abgedeckt ist und sie ohnehin in der Fremde mappen, muss man einfach sagen, dass bing, fugro, GeoImage einfacher sind und man somit mehr Daten/Zeit erfassen kann.

Und ich sag mal so, in Ländern, wo noch Hauptverkehrsstraßen fehlen reichen auch Bingbilder mit 1m und man ist erstmal eine Weile ausgelastet. 😉

Btw: könntest du mal den Link posten, wo man sich über den Stand des Bing-Programms informieren kann.

SunCobalt wrote:

und die Auswahl der Gebiete ist sehr beschränkt. Oft sind die DOPs jetzt da verfügbar, wo eh schon gute Luftbilder von Bing vorhanden waren.

Worauf basiert diese Aussage?

Ich kann nur sagen, dass hier in der Gegend die Bing-Bilder recht bescheiden sind. Besser als alles was es vorher gab, aber Aerowest ist nochmal um Längen besser. Keine Ahnung wie es mit den Bing-Bildern aussieht, aber Aerowest hat 7cm Auflösung und zudem meist laubfreie Bäume.

kellerma wrote:

Warum freuen sich so wenige? 😉

1. Weil nach der Umprojektion durch das Plugin immer noch ein Versatz von 3 Metern besteht.
2. Weil man das Luftbild nicht anhand von eingemessenen Punkten entsprechend verschieben kann.
3. Weil die herunterladbaren Ausschnitte für vernünftiges Arbeiten viel zu klein sind.

Aber:
Die Aerowest-Bilder haben wirklich eine Profi-Qualität und sind in Bezug auf Lagegenauigkeit den amtlichen Luftbildern ebenbürdig und von der Auflösung überlegen. Die Dortmunder Kollegen haben da was Tolles auf die Beine gestellt.
Auf unserer Seite gibt es zwar noch ein paar kleine Problemchen, die sicherlich bald gelöst werden.

PS:
Die Lagegenauigkeit der für 2012/13 angekündigten neuen Bing-Luftbilder ist nicht überwältigend:
"Orthorectified with 2.6 to 5.2-m horizontal accuracy (CE90%)" (http://www.emap-int.com/2011/July/article8.html)

Zum Vergleich ATKIS DOP 20:
Standardabweichung +/- 0,5 Meter (http://www.adv-online.de/icc/extdeu/nav … 07b51a.htm)

Für Nbg hab' ich 76 cm gemessen bei Bing, bin aber kein Photogrammetrist 😉

Here we go: http://www.emap-int.com/2011/June/article1.html

Ciao,
Frank

PS
Ah, DD1GJ war schneller 😉

dt2 wrote:

Worauf basiert diese Aussage?

Auf dem Auswahldialog bei Aerowest

DD1GJ wrote:

1. Weil nach der Umprojektion durch das Plugin immer noch ein Versatz von 3 Metern besteht.

Woher weiss Du das?
Das interessiert mich _brennend_ , ich brauch nämlich "Futter" für Bastiks "It's good enoug"-Aussage,
und das die "Sachsen-Korrektur" nicht ausreichend ist.
Für Nbg hab' ich "nur" 1,2 m Versatz zu NADgrids (die werden höchstwahrscheinlich für das
Plugin nicht kommmen 🙁

2. Weil man das Luftbild nicht anhand von eingemessenen Punkten entsprechend verschieben kann.

Klar, ist ein Schwäche, wäre durch (3) behoben

3. Weil die herunterladbaren Ausschnitte für vernünftiges Arbeiten viel zu klein sind.

Wenn die WMS-Server zum Fliegen kommen würden wär's passe.
Oder wir finden einen Sponsor 😉

Danke.

Ciao,
Frank

DD1GJ wrote:

PS:
Die Lagegenauigkeit der für 2012/13 angekündigten neuen Bing-Luftbilder ist nicht überwältigend:
"Orthorectified with 2.6 to 5.2-m horizontal accuracy (CE90%)" (http://www.emap-int.com/2011/July/article8.html)

Für viele die ausserhalb interessanter Städte wohnen (Bing 50cm, kein AeroWest), wird das schon überwältigend sein. Wenn die über das Plugin kommen, kann man sie ja weiterhin in der Lage korrigieren

kellerma wrote:

Wenn die WMS-Server zum Fliegen kommen würden wär's passe.

hab einen und hatte es angeboten. Die Antwort ist irgendwo in diesem Strang

SunCobalt wrote:

dt2 wrote:

Worauf basiert diese Aussage?

Auf dem Auswahldialog bei Aerowest

Und du kennst für alle in der Liste enthaltenen Städte die Bing-Qualität?

DD1GJ wrote:

kellerma wrote:

Warum freuen sich so wenige? 😉

1. Weil nach der Umprojektion durch das Plugin immer noch ein Versatz von 3 Metern besteht.

Leider kann ich das nur anhand von GPS-Tracks testen, kann schon sein. Kann das je nach Gegend in Deutschland anders sein?

dt2 wrote:

SunCobalt wrote:

dt2 wrote:

Worauf basiert diese Aussage?

Auf dem Auswahldialog bei Aerowest

Und du kennst für alle in der Liste enthaltenen Städte die Bing-Qualität?

Und Du kennst Du Unterschied zwischen "OFT" Und "ALLE" nicht. Laber jemand anderen blöd an

SunCobalt wrote:

dt2 wrote:

SunCobalt wrote:

Auf dem Auswahldialog bei Aerowest

Und du kennst für alle in der Liste enthaltenen Städte die Bing-Qualität?

Und Du kennst Du Unterschied zwischen "OFT" Und "ALLE" nicht. Laber jemand anderen blöd an

Was soll das denn jetzt?

Also, ich mappe grad mit dem ersten Bild von Aerowest.
Funktioniert seit dem Update von ImportImage wunderbar.

Habe einfach das Bild exportiert und in JOSM mit den Default-Werten von Aerowest importiert.
Alles supi.
Danke für die Mühe

Gruss
Sonny76

PS: Und nicht rumschimpfen, genießt doch die Tatsache, das es jetzt geht.... 🙂

-

kellerma wrote:

Einfach ist Bing, stimmt: Hintergrund -> Bing Sat aber
* Bing@Nürnberg - 2001 @ 80 cm
* Aerowest@Nürnberg - 2009 @ 10 cm (jetzt und heute)
* Bing@Nürnberg - 2012 @ 30 cm nicht vor einem Jahr
(denn wenn mir die Juni-Abdeckung des Adv. Aerial Pro. anschaue, haben sie Null qm von Dtl. bisher überflogen)

Hallo Frank

Ähnliches in Köln:
- Bing nur Z17, mit mäßiger Qualität und ca. 2005
- Aerowest 10cm (ungefähr Z20/Z21) und von 2010

Übrigens kann und darf man die Aerowest Bilder parallel (in einem zweiten Fenster) neben dem JOSM Hintergrund benutzen. Das hilft in Bonn trotz der schlechten Qualität der Bing-Bilder diese besser zu interpretieren.

Edbert (EvanE)

mmd wrote:

SunCobalt wrote:

kellerma wrote:

Wenn die WMS-Server zum Fliegen kommen würden wär's passe.

hab einen und hatte es angeboten. Die Antwort ist irgendwo in diesem Strang

Hallo,

mich würde interessieren, wie das im Detail funktioniert. Aktuell lade ich automatisiert JPGs im Maßstab 1:1000 für meinen lokalen WMS Server herunter und kann so auch etwas größere Gebiete relativ problemarm abdecken 🙂 (hoffentlich ist das nicht irgendwo in den Bedingungen explizit ausgeschlossen). Könnte so ein Script auch auf einem Server laufen inkl. Erzeugung des finalen GeoTiff mit gdal_merge.py und gdaladdo? Würde das auch für die Benutzer mit Potlatch funktionieren, wo nur TMS zur Verfügung steht?

Gruß,

Es war eher so gemeint, dass man die Daten für eine Region bekommt und die dann für die Allgemeinheit hostet. Nichts mit einzeln runterladen etc. Mangels Bezug interessiert mich keine der von Aerowest angebotenen Gegenden. So wie ich das verstanden habe, gibt es erstmal ein Pilotprojekt. Und danach werden Leute mit einem WMS ausgesucht, die die Bilder hosten. Schauen wir mal.
Ob Dein Weg erwünscht ist, weiß ich nicht. Vielleicht wäre für Dich gdaltindex besser geeignet als gdal_merge

dt2 wrote:

Leider kann ich das nur anhand von GPS-Tracks testen, kann schon sein. Kann das je nach Gegend in Deutschland anders sein?

Je nach Gegend sind die umrechnungsbedingten Abweichungen unterschiedlich (Baden-Baden 3 m, Karlsruhe 2,66m), deshalb gibt es die Bundeseinheitliche Transformation für ATKIS® (BeTA2007).

kellerma wrote:

DD1GJ wrote:

1. Weil nach der Umprojektion durch das Plugin immer noch ein Versatz von 3 Metern besteht.

Woher weiss Du das?

Das Liegenschaftsamt der Stadt Karlsruhe stellt für OSM-Zwecke das gleiche Luftbild bereit, welches über http://wms.openstreetmap.de/ mittels BeTA 2007 passend für JOSM umgerechnet und bereitgestellt wird. So kann man die Auswirkungen schön vergleichen:

Mit BeTA 2007 : http://www.gassenschmidt.de/OpenStreetM … mtlich.jpg
Plugin: http://www.gassenschmidt.de/OpenStreetMap/KA_Plugin.jpg

Die rote Linie links markiert die Differenz.

Manchem mag die Differenz lächerlich klein vorkommen, aber wenn wir in unserer kostbaren Freizeit die Möglichkeit haben, so genaues Bildmaterial nutzen zu können, dann sollten wir auch das Optimum herausholen. Nachträgliche Korrekturen kosten meistens ein Vielfaches der ursprünglichen Zeit.

DD1GJ wrote:

kellerma wrote:

DD1GJ wrote:

1. Weil nach der Umprojektion durch das Plugin immer noch ein Versatz von 3 Metern besteht.

Woher weiss Du das?

Das Liegenschaftsamt der Stadt Karlsruhe stellt für OSM-Zwecke das gleiche Luftbild bereit, welches über http://wms.openstreetmap.de/ mittels BeTA 2007 passend für JOSM umgerechnet und bereitgestellt wird. So kann man die Auswirkungen schön vergleichen:

Mit BeTA 2007 : http://www.gassenschmidt.de/OpenStreetM … mtlich.jpg
Plugin: http://www.gassenschmidt.de/OpenStreetMap/KA_Plugin.jpg

Die rote Linie links markiert die Differenz.

Manchem mag die Differenz lächerlich klein vorkommen, aber wenn wir in unserer kostbaren Freizeit die Möglichkeit haben, so genaues Bildmaterial nutzen zu können, dann sollten wir auch das Optimum herausholen. Nachträgliche Korrekturen kosten meistens ein Vielfaches der ursprünglichen Zeit.

Vielen Dank!

Gerade hab' ich ganz unscientific Aachen (als relativ weit weg von Sachsen) genommen und als "base" die nadgrids,
da komme ich auf eine Abweichung von 3,3 m.

Wenn ich bastiK richtig verstanden habe, hat dem plugin zugrundeliegende JAVA-lib Geotools aber keine nadgrids-support
und daher wird's für das ImportImagePlugin auch kein NTv2 geben.

Wenn aber die Abweichung von PI mal Daumen 3 m im worstcase für Dtl. stimmt, dann kann auch die "Sachsen-korretur"
potsdam "towgs84=612.4,77.0,440.2,-0.054,0.057,-2.797,2.55" "Germany (Sachsen)" "Accuracy <1m",
die derzeit hardocodiert im geotools und somit im plugin vorliegt, auch drin lassen, da mir nur ein "3 m Deutschland"
potsdam "towgs84=598.1,73.7,418.2,0.202,0.045,-2.455,6.70" "Germany (Whole Country)" "Accuracy 3m"
aber kein "1 m Deutschland" +towgs84 7-param.-Korrektursatz bekannt ist.

Oder kennst Du einen?

Ciao,
Frank

PS
Mit dem bestmöglichen Herausholen was frei und offen verfügbar ist, stimme ich Dir überein!
Ein Grund mehr für das WMS-"Plugin" 😉

DD1GJ wrote:

Manchem mag die Differenz lächerlich klein vorkommen, aber wenn wir in unserer kostbaren Freizeit die Möglichkeit haben, so genaues Bildmaterial nutzen zu können, dann sollten wir auch das Optimum herausholen. Nachträgliche Korrekturen kosten meistens ein Vielfaches der ursprünglichen Zeit.

Ich bin hier absolut deiner Meinung.

Wenn ich das Wort ImportImagePlugin nur höre und weiß, dass die Mitwirkenden dabei sind die Daten mit einem Versatz von mehreren Metern einzutragen, anstatt sich einen WMS-Server mit BeTA2007 aufzusetzen, was übrigens deutlich komfortabler ist, da man nicht einzeln Bilder mit dem Plugin importieren muss, welches dann auch noch Speicher ohne Ende frisst und JOSM verlangsamt, dann habe ich nur noch wenig Motivation hier mitzuwirken.
Ich arbeite gerade an einer verständlichen Anleitung für den Mapserver unter GNU/Linux, das ist wirklich nicht schwer.
Windows-Benutzer sollten sich untereinander austauschen und helfen, ebenfalls eine Anleitung z.B. für MapServer for Windows (MS4W) zu schreiben: http://www.maptools.org/ms4w/
Ich hätte das gerne gemacht, habe aber kein Windows und werde mir das sicher nicht extra dafür kaufen.
Edit: Übrigens enthält MS4W den gleichen MapServer wie GNU/Linux, d.h. die in diesem Thread zusammengetragenen Informationen, Befehle und Konfigurationsdateien sollten sich einfach auf die Windows-Variante übertragen lassen.

dt2 wrote:

Ich kann nur sagen, dass hier in der Gegend die Bing-Bilder recht bescheiden sind. Besser als alles was es vorher gab, aber Aerowest ist nochmal um Längen besser. Keine Ahnung wie es mit den Bing-Bildern aussieht, aber Aerowest hat 7cm Auflösung und zudem meist laubfreie Bäume.

Ja, die Aerowest-Bilder sind besonders in deinem Bereich sehr viel besser, Bing ist dort teilweise völlig unbenutzbar.
Aerowest hat auch von kleineren Städten und Dörfern sehr gute Bilder.

dt2 wrote:

Leider kann ich das nur anhand von GPS-Tracks testen, kann schon sein. Kann das je nach Gegend in Deutschland anders sein?

Die von dir hier eingezeichneten Gebäude sind um ca. 2,20m nach Norden und ca. 0,6m nach Westen verschoben:
http://www.openstreetmap.org/?lat=49.39 … 8&layers=M

Gruß,
Mondschein

Mondschein wrote:

DD1GJ wrote:

Manchem mag die Differenz lächerlich klein vorkommen, aber wenn wir in unserer kostbaren Freizeit die Möglichkeit haben, so genaues Bildmaterial nutzen zu können, dann sollten wir auch das Optimum herausholen. Nachträgliche Korrekturen kosten meistens ein Vielfaches der ursprünglichen Zeit.

Ich bin hier absolut deiner Meinung.

Wenn ich das Wort ImportImagePlugin nur höre und weiß, dass die Mitwirkenden dabei sind die Daten mit einem Versatz von mehreren Metern einzutragen, anstatt sich einen WMS-Server mit BeTA2007 aufzusetzen, was übrigens deutlich komfortabler ist, da man nicht einzeln Bilder mit dem Plugin importieren muss, welches dann auch noch Speicher ohne Ende frisst und JOSM verlangsamt, dann habe ich nur noch wenig Motivation hier mitzuwirken.

Woher soll man den wissen, dass überhaupt ein Versatz besteht? Die meisten dürften von Korrekturdateien und sowas keine Ahnung haben, geschweigedenn wissen wo im Quellcode des Plugins man das findet. Ich habe jedenfalls hier das erste Mal von einem Versatz gelesen und es wird wohl kaum jeder diesen Thread komplett durchlesen, zumal auch viel Technisches drin steht, mit dem nicht jeder viel anfangen kann. Ich finde es natürlich gut, dass ihr euch hier die Mühe macht, aus den Bildern das Optimale rauszuholen. Ich mache jetzt auch erstmal Pause mit dem Abzeichnen.

Einen WMS-Server aufzusetzten klingt allerdings zumindest schonmal deutlich aufwändiger, als einfach ein Plugin aus der Liste auszuwählen. Selbst wenn die paar Befehle für einen erfahrenen Linux-Benutzer schnell eingegeben sind, kann man das wohl kaum von allen (auch erfahrenen) OSM-Mappern behaupten. Ich persönlich werde das aber natürlich gerne versuchen.

Mondschein wrote:

Ich arbeite gerade an einer verständlichen Anleitung für den Mapserver unter GNU/Linux, das ist wirklich nicht schwer.
Windows-Benutzer sollten sich untereinander austauschen und helfen, ebenfalls eine Anleitung z.B. für MapServer for Windows (MS4W) zu schreiben: http://www.maptools.org/ms4w/
Ich hätte das gerne gemacht, habe aber kein Windows und werde mir das sicher nicht extra dafür kaufen.
Edit: Übrigens enthält MS4W den gleichen MapServer wie GNU/Linux, d.h. die in diesem Thread zusammengetragenen Informationen, Befehle und Konfigurationsdateien sollten sich einfach auf die Windows-Variante übertragen lassen.

Dass du an einer Anleitung schreibst ist super. Im Moment ist es doch etwas mühsam, sich hier aus dem inzwischen doch sehr langen Thread die wichtigsten Informationen rauszusuchen, wenn man noch nie Berührungspunkte mit den genannten Programmen und Problemstellungen hatte. Wenn die Anleitung dann eventuell sogar unter Windows gültig ist, wäre das natürlich praktisch.

Neues von unserem allseits 😉 beliebten ImportImapgePlugin:
In der neuen Version scheint es nun .prj-Files zu akzeptieren.
Darin enthaltene TOWGS84[]-Parameter scheinen beharrlich ignoriert zu werden 🙁

Ciao,
Frank

hi !

bei der ganzen diskussion über das einbinden der bilder in josm sollten wir nicht vergessen einen effektiven weg zu finden wie man die entsprechenden daten auf den lokalen rechner bekommt - immer per download ist, wie schon geschrieben, sehr müssig !

leider kann man auch in der aeroview-seite keinen permalink setzen um immer wieder an die richtige stelle zu gelangen - bei größeren städten auch sehr aufwendig.

gruß Jan :-)

Lübeck wrote:

hi !

bei der ganzen diskussion über das einbinden der bilder in josm sollten wir nicht vergessen einen effektiven weg zu finden wie man die entsprechenden daten auf den lokalen rechner bekommt - immer per download ist, wie schon geschrieben, sehr müssig !

leider kann man auch in der aeroview-seite keinen permalink setzen um immer wieder an die richtige stelle zu gelangen - bei größeren städten auch sehr aufwendig.

gruß Jan :-)

Du kennst "Firefox - Copy Download Link"?
Mehr verrat' ich jetzt nicht, aus Angst um den armen AW-Webserver 😉

Svens Vorschlag auf talk-de "Warum das Zeug nicht einfach auf wms.openstreetmap.de schmeissen" und
"Schluß mit IIPlugin-rumgefummel" fand ich jetzt auch nicht so schlecht 😉

Ciao,
Frank

-

So, hier mein erster Versuch:
http://wiki.openstreetmap.org/wiki/DE:I … Luftbilder

Das ist ein Wiki, jeder darf also Änderungen und Verbesserungen vornehmen. 🙂

Gruß,
Mondschein

Mondschein wrote:

So, hier mein erster Versuch:
http://wiki.openstreetmap.org/wiki/DE:I … Luftbilder

Das ist ein Wiki, jeder darf also Änderungen und Verbesserungen vornehmen. 🙂

Danke für die Anleitung. Nach einer Stunde Arbeit sind doch tatsächlich Luftbilder per lokalem WMS in JOSM erschienen. 🙂 Und noch eine Stunde später, ist im Wiki eine ergänzende Anleitung für Windows erschienen. Sicherlich nicht perfekt, aber ein Anfang. Ich habe halt einfach mal die Schritte notiert, wie ich sie in etwa ausgeführt habe. Eventuell geht es auch anders.

Noch eine Frage. Der GetCapabilities-Request an den Mapserver resultierte bei mir in einem Fehler:

msWMSGetCapabilities():␣WMS␣server␣error.␣WMS␣request␣not␣enabled.␣Check␣wms/ows_enable_request␣settings.

Es ging erst, nachdem ich diesen Hinweis beachtet und folgendes im Mapfile unter MAP::WEB eingefügt hatte:

"ows_enable_request"␣␣␣"*"

Hast du eventuell eine andere Mapserver Version laufen oder ist das vielleicht Windows spezifisch? Das aktuelle MS4W installiert offenbar die MapServer CGI Version 6.0.1.

Edit:
Noch eine Frage. Ist bei "gdaltindex bilder.shp /mapserver/data/*.jpg" der Pfad wirklich nötig? Man befindet sich doch schon in dem Verzeichnis. Geht nicht auch einfach "gdaltindex bilder.shp *.jpg"?

Gruß

-

dt2 wrote:

Nach einer Stunde Arbeit sind doch tatsächlich Luftbilder per lokalem WMS in JOSM erschienen. 🙂 Und noch eine Stunde später, ist im Wiki eine ergänzende Anleitung für Windows erschienen.

Sehr schön. 🙂

dt2 wrote:

Hast du eventuell eine andere Mapserver Version laufen oder ist das vielleicht Windows spezifisch? Das aktuelle MS4W installiert offenbar die MapServer CGI Version 6.0.1.

Ja, seit Version 6 hat sich da etwas geändert.

dt2 wrote:

Noch eine Frage. Ist bei "gdaltindex bilder.shp /mapserver/data/*.jpg" der Pfad wirklich nötig?

Nein, ich habe das jetzt entfernt.

Jetzt könnte man noch eine zweite Methode in den Artikel einfügen, also mit GeoTiff, Tiling, Auflösungspyramide ...

Gruß,
Mondschein

Mondschein wrote:

dt2 wrote:

Noch eine Frage. Ist bei "gdaltindex bilder.shp /mapserver/data/*.jpg" der Pfad wirklich nötig?

Nein, ich habe das jetzt entfernt.

Jetzt könnte man noch eine zweite Methode in den Artikel einfügen, also mit GeoTiff, Tiling, Auflösungspyramide ...

Gruß,
Mondschein

bei mir gehts nicht ohne Pfad. Es kommt drauf an, wo die Bilder liegen.

-

mmd wrote:

Hallo Thomas,

Könntest Du mal den Parameter -write_absolute_path ausprobieren? Der sollte eigentlich dasselbe machen, wie den kompletten Pfad anzugeben. Also

gdaltindex␣-write_absolute_path␣bilder.shp␣*.jpg

Gruß,

geht. Danke für den Tipp

Meiner Meinung nach muss ein

␣␣␣PROJECTION
"init=epsg:3146x"
END

ins Layer

Sonst gilt die Zeile 8 afaik für alle Layer. Wenn man die Daten nur in diesem einen EPSG hat, ist das aber nicht weiter schlimm. Ich habe in jedem Layer den EPSG Code einzeln definiert.

Jetzt hab' ich das ImportImagePlugin "überlistet" 😉

Scheinbar matched es auf den Namen => towgs84-Parameter jetzt einstellbar

Inhalt einer "exportimg201185214014830240.prj"-Datei mit absichtlich verkehrt geschriebenem Datum:

PROJCS["DHDN␣/␣3-degree␣Gauss-Kruger␣zone␣4",
GEOGCS["DHDN",
DATUM["Deutsches␣Hauptdreiecksnetz␣-␣Sued",
SPHEROID["Bessel␣1841",␣6377397.155,␣299.1528128,␣AUTHORITY["EPSG","7004"]],
TOWGS84[597.1,71.4,412.1,0.894,0.068,-1.563,7.58],␣AUTHORITY["EPSG","6314"]],
PRIMEM["Greenwich",␣0.0,␣AUTHORITY["EPSG","8901"]],
UNIT["degree",␣0.017453292519943295],
AXIS["Geodetic␣longitude",␣EAST],
AXIS["Geodetic␣latitude",␣NORTH],␣AUTHORITY["EPSG","4314"]],
PROJECTION["Transverse␣Mercator",␣AUTHORITY["EPSG","9807"]],
PARAMETER["central_meridian",␣12.0],
PARAMETER["latitude_of_origin",␣0.0],
PARAMETER["scale_factor",␣1.0],
PARAMETER["false_easting",␣4500000.0],
PARAMETER["false_northing",␣0.0],
UNIT["m",␣1.0],
AXIS["Easting",␣EAST],
AXIS["Northing",␣NORTH],␣AUTHORITY["EPSG","31468"]]

Unterschied in Nürnberg zu nadgrids: ca. 23 cm.
Das, glaube ich, ist verschmerzbar 😉

Die Korrekturdaten hat Mondschein schon hier gepostet:
http://forum.openstreetmap.org/viewtopi … 28#p181728

Ciao,
Frank

PS
Jetzt brauchen wir nur noch einen (1 m accuracy) towgs84-Satz für Meck-Pom 🙂

Wenn du jetzt noch schreibst, was man machen muss und wie man die schöneren Daten für andere Städte bekommt....dann bekommen es auch alle OSM-Normalos hin 😉

aighes wrote:

Wenn du jetzt noch schreibst, was man machen muss und wie man die schöneren Daten für andere Städte bekommt....dann bekommen es auch alle OSM-Normalos hin 😉

Ich denke die Anleitung hier: http://forum.openstreetmap.org/viewtopi … 55#p183055 ist ebenso für viele Anwender geeignet. Es ist lediglich kopieren und das Eingeben einiger Befehle notwendig.

viw wrote:

aighes wrote:

Wenn du jetzt noch schreibst, was man machen muss und wie man die schöneren Daten für andere Städte bekommt....dann bekommen es auch alle OSM-Normalos hin 😉

Ich denke die Anleitung hier: http://forum.openstreetmap.org/viewtopi … 55#p183055 ist ebenso für viele Anwender geeignet. Es ist lediglich kopieren und das Eingeben einiger Befehle notwendig.

Normalos haben Windows und kein Debian. Sorry, aber das ist nur für die wenigsten machbar.

-

mmd wrote:

Die Wiki-Seite beschreibt auch die Installation für Windows:
http://wiki.openstreetmap.org/wiki/DE:I … er#Windows

Eine Kommandozeile öffnen und /ms4w/setenv.bat ausführen, um in dieser Session die PATH-Variable um einige MS4W Ordner zu erweitern.

Das nenne ich die "Täglich Arbeit" unter Windows.

Dann wie beschrieben in den richtigen Ordner wechseln und den Befehl ausführen. <<

Der jenige, der weiß, "Welchen" Ordner und "Welchen" Befehl, der kann weiter machen. Jemand, der sich ganz neu mit dem Thema beschäftigt ist hier leider ein wenig im Regen stehen gelassen. In den obigen Zeilen stehen zig Befehle. Welche davon muss man an diesem Schritt ausführen?

Service URL - Offenbar muss hier ein .exe hinter das auszuführende Programm, also "http://127.0.0.1/cgi-bin/mapserv.exe?ma … r/osm.map&"

Hier steigen dann bei die Fragezeichen auf. Ein Ausführendes Programm unter Windows endet immer auf .exe. Nur in der GUI wird diese Tatsache ausgeblendet.

---

Das Problem ist und bleibt leider bestehen. Der Standard-Windows-Andwender wird mit "Root", "Kommandozeile Öffnen", "PATH-Variable", oder "Pfad wechseln" nie konfrontiert, da man diese Arbeitsschritte unter Windows nicht benötigt bei normalen Programmen. Wenn jetzt all diese Begriffe mit "Offenbar" oder "Einfach" kombiniert werden, wird niemand versuchen die Schritte umzusetzen, da jeder denken wird "Da folgt etwas sau-Kompliziertes" und die Anleitung ist nur für Profis geschrieben, da die kompliziertesten Schritte mit "Einfach" betitelt werden.

Ich habe schon dutzende Anleitungen geschrieben, Wörter wie "Kontextmenü" schaden zu 100%. Auch "Maustaste" sollte immer mit der Definition "Linke Maustaste" definiert werden. Eine "Tabulator-Taste" kennt kaum einer. Wenn man in Anleitungen solche Sachen beachtet, dann wird mit den Anleitungen gearbeitet und die Mehrzahl der Anwender ist zufrieden, daß die Anleitung funktioniert. Allerdings ist dann die Anleitung für einen WMS-Server locker 2-5 A4-Seiten lang...

aighes wrote:

Wenn du jetzt noch schreibst, was man machen muss und wie man die schöneren Daten für andere Städte bekommt....dann bekommen es auch alle OSM-Normalos hin 😉

So richtig einfach wird es dennoch nicht, denn man braucht eine 31468.prj fuer suedtl, eine 31468 fuer mittel, eine fuer norddtl,
eine 31467.prj fuer sueddtl, eine fuer mittel etc etc
😉

Ciao,
Frank

Ich würde mal davon ausgehen, dass auch der Normal-Mapper eine Setup.exe haben möchte oder eine Klick für Klick-Anleitung. Also "Start->Ausführen->cmd" anstatt "Kommandozeile öffnen".
Wenn solch ein User sich die Anleitung durchliest tauchen über ihm ein paar Fragezeichen auf, dann startet er josm und bingt weiter...;)

Dennis[B] wrote:

mmd wrote:

Die Wiki-Seite beschreibt auch die Installation für Windows:
http://wiki.openstreetmap.org/wiki/DE:I … er#Windows

Eine Kommandozeile öffnen und /ms4w/setenv.bat ausführen, um in dieser Session die PATH-Variable um einige MS4W Ordner zu erweitern.

Das nenne ich die "Täglich Arbeit" unter Windows.

Dann wie beschrieben in den richtigen Ordner wechseln und den Befehl ausführen. <<

Der jenige, der weiß, "Welchen" Ordner und "Welchen" Befehl, der kann weiter machen. Jemand, der sich ganz neu mit dem Thema beschäftigt ist hier leider ein wenig im Regen stehen gelassen. In den obigen Zeilen stehen zig Befehle. Welche davon muss man an diesem Schritt ausführen?

Service URL - Offenbar muss hier ein .exe hinter das auszuführende Programm, also "http://127.0.0.1/cgi-bin/mapserv.exe?ma … r/osm.map&"

Hier steigen dann bei die Fragezeichen auf. Ein Ausführendes Programm unter Windows endet immer auf .exe. Nur in der GUI wird diese Tatsache ausgeblendet.

Schön das du die offensichtlichen Mängel der Anleitung erkannt hast. Aber wie im Post beschrieben handelt es sich um ein Wiki und DU bist eingeladen mit deinen Erfahrungen dort Verbesserungen im Sinne des Projektes herbei zu führen.

Ich gehe mit dir konform, wenn man es dem Nutzer so einfach wie möglich machen sollte. Aber ich denke auch das ein Anwender mit der entsprechenden Erklärung durchaus bereits ist neue Wege zu gehen. Je mehr man bereits kennt desto einfach wird es natürlich sein. Es soll sogar Linuxuser geben, die auch noch ein Windows hüten, um unbedarfteren Windowsusern zu helfen.

Ich habe es leider noch nicht schaffen können, so einen Server zum laufen zu kriegen, daher kann ich wenig helfen im Wiki. Nur das Image-Plugin läuft bei mir mit einem Versatz von ca. 8 Metern. Wie aighes gerade schrieb, da "Binge" ich vorerst lieber weiter.

Dennis[B] wrote:

Ich habe es leider noch nicht schaffen können, so einen Server zum laufen zu kriegen, daher kann ich wenig helfen im Wiki. Nur das Image-Plugin läuft bei mir mit einem Versatz von ca. 8 Metern. Wie aighes gerade schrieb, da "Binge" ich vorerst lieber weiter.

Dann wäre eine Info an welcher Stelle du gescheitert bist sinnvoll.

Ich habe den mapserver installiert mittels des Setups. Da Pfad ist E:\Mapserver\ms4w\
Außerdem habe ich einen Ordner E:\Data angelegt. In diesen Ordner werden die heruntergeladenen jpg und jgw Dateien entpackt.
Bei der Installation habe ich Apache als Dienst mit installiert. Prüfe einfach ob der Server bei dir läuft in dem du 127.0.0.1 im Browser aufrufst.

Danach machst du eine Kommandozeile auf. Entweder über Start und dann ausführen und CMD eingeben oder aber du suchst den entsprechenden Menüpunkt meist unter Systemprogramme oder ähnlichem zu finden.
Hier als erstes "e:\mapserver\ms4w\setenv.bat" eingeben und mit Enter bestätigen.
Als zweites in das Verzeichnis mit den Daten wechseln. Das machst du in der Kommandozeile mit "cd mapserver\data"
dort führst du dann einfach das Kommando "e:\mapserver\ms4w\tools\gdal-ogr\gdaltindex.exe bilder.shp *.jpg" aus.

Falls noch nicht geschehen die zwei Dateien für die Konfiguration anlegen. Mit einem Texteditor speicherst du die osm.map im Ordner e:\mapserver und lädst die gsb Datei auch in diesen Ordner runter.
Wichtig ist noch in der osm.map ind er Zeile "init=epsg:3146x" das x gegen die entsprechende Ziffer deiner Bilder auszutauschen.

Wenn all das gemacht wurde, probierst du einfach in Firefox ob der Server antwortet. http://127.0.0.1/cgi-bin/mapserv.exe?ma … r/osm.map&
fürht bei mir zu der folgenden Meldung: "mapserv(): Web application error. Traditional BROWSE mode requires a TEMPLATE in the WEB section, but none was provided."
Jetzt versuchst du das gleiche in Josm. Dort unter Einstellung wms die gleiche URL einfügen die Layer abfragen dann den Layer auswählen und jetzt sollte es klappen.

viw wrote:

Dann wäre eine Info an welcher Stelle du gescheitert bist sinnvoll. (...) In diesen Ordner werden die heruntergeladenen jpg und jgw Dateien entpackt

Fangen wir doch mal ganz am Anfang an. Wie komme ich an die Fotos von ganz (78467) Konstanz in 7-cm Auflösung?

Ich komme immer nur an 100x100-Meter-Bereiche in 10-cm-Auflösung.

Dennis[B] wrote:

viw wrote:

Dann wäre eine Info an welcher Stelle du gescheitert bist sinnvoll. (...) In diesen Ordner werden die heruntergeladenen jpg und jgw Dateien entpackt

Fangen wir doch mal ganz am Anfang an. Wie komme ich an die Fotos von ganz (78467) Konstanz in 7-cm Auflösung?

Ich komme immer nur an 100x100-Meter-Bereiche in 10-cm-Auflösung.

Hier gibt es sowohl mit dem Plugin als auch mit dem WMS Server ein Problem. Denn diese Fotos musst du dir bei Aerowest herunterladen. Später soll es lokale WMS Server geben. Bisher sind die Verträge dafür aber noch nicht unterschreiben.
Wie du auf die 10cm Bodenauflösung kommst verstehe ich noch nicht so ganz. Denn wenn ich mich mit der im Wiki angegebenen Adresse http://www.aeroview.de/aerowest_IWS/map … wd=osmonly anmelde und dann Konstanz als Stadt wähle, habe ich 5cm Bodenauflösung da stehen.
Jetzt den passenden Maßstab wählen. Empfohlen waren hier 1:500 kann man einfach unten bei Maßstab eingeben und dann das Zip Archiv speichern.
Nachzulesen auf der Wikiseite zu den Luftbildern: http://wiki.openstreetmap.org/wiki/DE:W … bilderdann verschiebst du den Ausschnitt und wiederholst das Spiel. Dabei musst du dir natürlich den EPSG Code merken. Für Konstanz scheint das die 31467 zu sein. Im Mapfile also das x durch die 7 austauschen. Im Plugin musst du als Standardprojektion ebenfalls die 31467 einstellen. Ansonsten geht auch das Schief!

Dennis[B] wrote:

mmd wrote:

Die Wiki-Seite beschreibt auch die Installation für Windows:
http://wiki.openstreetmap.org/wiki/DE:I … er#Windows

Eine Kommandozeile öffnen und /ms4w/setenv.bat ausführen, um in dieser Session die PATH-Variable um einige MS4W Ordner zu erweitern.

Das nenne ich die "Täglich Arbeit" unter Windows.

Dann wie beschrieben in den richtigen Ordner wechseln und den Befehl ausführen. <<

Der jenige, der weiß, "Welchen" Ordner und "Welchen" Befehl, der kann weiter machen. Jemand, der sich ganz neu mit dem Thema beschäftigt ist hier leider ein wenig im Regen stehen gelassen. In den obigen Zeilen stehen zig Befehle. Welche davon muss man an diesem Schritt ausführen?

Service URL - Offenbar muss hier ein .exe hinter das auszuführende Programm, also "http://127.0.0.1/cgi-bin/mapserv.exe?ma … r/osm.map&"

Hier steigen dann bei die Fragezeichen auf. Ein Ausführendes Programm unter Windows endet immer auf .exe. Nur in der GUI wird diese Tatsache ausgeblendet.

---

Das Problem ist und bleibt leider bestehen. Der Standard-Windows-Andwender wird mit "Root", "Kommandozeile Öffnen", "PATH-Variable", oder "Pfad wechseln" nie konfrontiert, da man diese Arbeitsschritte unter Windows nicht benötigt bei normalen Programmen. Wenn jetzt all diese Begriffe mit "Offenbar" oder "Einfach" kombiniert werden, wird niemand versuchen die Schritte umzusetzen, da jeder denken wird "Da folgt etwas sau-Kompliziertes" und die Anleitung ist nur für Profis geschrieben, da die kompliziertesten Schritte mit "Einfach" betitelt werden.

Für den Standard-Windows-Anwender ist das auch kaum gedacht. Es sind lediglich Notizen, um es erfahrerenen Anwendern leichter zu machen, die es jetzt auch ausprobieren wollen. Eine richtige Anleitung muss natürlich noch geschrieben werden, wenn es keine leichtere Methode geben wird.

Hallo Forum,
erst einmal vielen Dank für eure Tutorials und Hilfe. Ich bin auch schon einige Zeit am Basteln und stehe sicher kurz davor das es klappt. Ich habe aber noch ein Problem.
Ich versuche den WMS Server unter Windows XP einzurichten. Ich habe soweit alle Schritte befolgt. in der map.osm Datei habe ich in Zeile 8 das x durch eine 8 ersetzt. Wenn ich im Firefox http://127.0.0.1/ eingebe wird mir Apache angezeigt, wenn ich http://127.0.0.1/cgi-bin/mapserv.exe?ma … r/osm.map& im Firefox eingebe wird mir mapserv(): Web application error. Traditional BROWSE mode requires a TEMPLATE in the WEB section, but none was provided. angezeigt. Wenn ich in JOSM unter Einstellungen/WMS gehe und http://127.0.0.1/cgi-bin/mapserv.exe?ma … r/osm.map& einkopiere und auf "Ebenen abfragen" klicke, wird mir auch der WMS Server angezeigt. Wenn ich aber dann die Kacheln aufrufe, werden mir nur rote Felder angezeigt.
Wo könnte der Fehler liegen?
Ich bin im übrigen in Erfurt zu Gange.
Ciao Holger

-

viw wrote:

Wie du auf die 10cm Bodenauflösung kommst verstehe ich noch nicht so ganz.

Mein PWK ist 4,05 Meter lang und hat 37 Pixel wenn ich ganz rangezoomt habe.

habe ich 5cm Bodenauflösung da stehen.

Das ist dann falsch.

Jetzt den passenden Maßstab wählen. Empfohlen waren hier 1:500 kann man einfach unten bei Maßstab eingeben und
dann das Zip Archiv speichern.

Du schreibst hierzu "einfach". Bist Du so nett und lädst mir "einfach" Konstanz runter und schickst mir das per Email? Ich würde dafür Tage brauchen bei den Mini-Ausschnitten die man da wählen kann.

Empfohlen waren hier 1:500 kann man einfach unten bei Maßstab eingeben

Funktioniert leider nicht. In Konstanz wird die Karte weiß, wenn man den Maßstab < 757 eingibt.

Hallo mmd,

die error.log Datei spuckt folgende Fehlermeldung aus:

Aug 07 17:46:55 2011] [notice] Apache/2.2.19 (Win32) configured -- resuming normal operations
[Sun Aug 07 17:46:55 2011] [notice] Server built: May 20 2011 17:39:35
[Sun Aug 07 17:46:55 2011] [notice] Parent: Created child process 456
[Sun Aug 07 17:46:56 2011] [notice] Child 456: Child process is running
[Sun Aug 07 17:46:56 2011] [notice] Child 456: Acquired the start mutex.
[Sun Aug 07 17:46:56 2011] [notice] Child 456: Starting 64 worker threads.
[Sun Aug 07 17:46:56 2011] [notice] Child 456: Starting thread to listen on port 80.
[Sun Aug 07 17:48:14 2011] [error] [client 127.0.0.1] script not found or unable to stat: C:/ms4w/Apache/cgi-bin/mapserv
[Sun Aug 07 17:48:14 2011] [error] [client 127.0.0.1] script not found or unable to stat: C:/ms4w/Apache/cgi-bin/mapserv
[Sun Aug 07 17:48:14 2011] [error] [client 127.0.0.1] script not found or unable to stat: C:/ms4w/Apache/cgi-bin/mapserv
[Sun Aug 07 17:48:16 2011] [error] [client 127.0.0.1] script not found or unable to stat: C:/ms4w/Apache/cgi-bin/mapserv
[Sun Aug 07 17:48:16 2011] [error] [client 127.0.0.1] script not found or unable to stat: C:/ms4w/Apache/cgi-bin/mapserv
[Sun Aug 07 17:48:16 2011] [error] [client 127.0.0.1] script not found or unable to stat: C:/ms4w/Apache/cgi-bin/mapserv
[Sun Aug 07 17:48:17 2011] [error] [client 127.0.0.1] script not found or unable to stat: C:/ms4w/Apache/cgi-bin/mapserv
[Sun Aug 07 17:48:17 2011] [error] [client 127.0.0.1] script not found or unable to stat: C:/ms4w/Apache/cgi-bin/mapserv
[Sun Aug 07 17:48:18 2011] [error] [client 127.0.0.1] script not found or unable to stat: C:/ms4w/Apache/cgi-bin/mapserv
[Sun Aug 07 17:48:19 2011] [error] [client 127.0.0.1] script not found or unable to stat: C:/ms4w/Apache/cgi-bin/mapserv
[Sun Aug 07 17:48:19 2011] [error] [client 127.0.0.1] script not found or unable to stat: C:/ms4w/Apache/cgi-bin/mapserv
[Sun Aug 07 17:48:20 2011] [error] [client 127.0.0.1] script not found or unable to stat: C:/ms4w/Apache/cgi-bin/mapserv
[Sun Aug 07 17:48:20 2011] [error] [client 127.0.0.1] script not found or unable to stat: C:/ms4w/Apache/cgi-bin/mapserv
[Sun Aug 07 17:48:21 2011] [error] [client 127.0.0.1] script not found or unable to stat: C:/ms4w/Apache/cgi-bin/mapserv
[Sun Aug 07 17:48:21 2011] [error] [client 127.0.0.1] script not found or unable to stat: C:/ms4w/Apache/cgi-bin/mapserv
[Sun Aug 07 17:48:22 2011] [error] [client 127.0.0.1] script not found or unable to stat: C:/ms4w/Apache/cgi-bin/mapserv
[Sun Aug 07 17:48:23 2011] [error] [client 127.0.0.1] script not found or unable to stat: C:/ms4w/Apache/cgi-bin/mapserv
[Sun Aug 07 17:48:24 2011] [error] [client 127.0.0.1] script not found or unable to stat: C:/ms4w/Apache/cgi-bin/mapserv
[Sun Aug 07 17:48:26 2011] [error] [client 127.0.0.1] script not found or unable to stat: C:/ms4w/Apache/cgi-bin/mapserv

Irgendein script wird nicht gefunden

Ciao Holger

-

hi!

viw schreibt in #240

"Hier gibt es sowohl mit dem Plugin als auch mit dem WMS Server ein Problem. Denn diese Fotos musst du dir bei Aerowest herunterladen. Später soll es lokale WMS Server geben. Bisher sind die Verträge dafür aber noch nicht unterschreiben."

ist denn da mehr geplant und zu welchen bedingungen ... gibt es schon details ???

gruß Jan :-)

Hallo mmd,
danke für den Tipp. Da waren wir schon auf der richtigen Spur aber es geht immer noch nicht.

Wenn ich im Firefox:

http://127.0.0.1/cgi-bin/mapserv?map=/m … r/osm.map&

kommt die Meldung, dass er die Seite nicht finden konnte.

Wenn ich dann:

http://127.0.0.1/cgi-bin/mapserv.exe?ma … r/osm.map&

eingebe kommt die Meldung: msLoadMap(): Unable to access file. (/mapserver/osm.map)

Also muss die exe in die osm.map eingetragen werden.

Muss ich in der osm.map vielleicht noch einen Path ändern?

ich habe den Mapserver in c:\ms4w\ kopiert und die osm.map in c:\ms4w\mapserver\ und die Bilder in c:\ms4w\mapserver\data

Ciao Holger

'DennisB wrote:

Empfohlen waren hier 1:500 kann man einfach unten bei Maßstab eingeben

Funktioniert leider nicht. In Konstanz wird die Karte weiß, wenn man den Maßstab < 757 eingibt.

Habe soeben ein Bild aus Konstanz mit 1:270 heruntergeladen,
selbst 1:70 scheint zu funktionieren.

Ciao,
Frank

Holger-erf wrote:

Wenn ich dann:

http://127.0.0.1/cgi-bin/mapserv.exe?ma … r/osm.map&

eingebe kommt die Meldung: msLoadMap(): Unable to access file. (/mapserver/osm.map)

Also muss die exe in die osm.map eingetragen werden.

Muss ich in der osm.map vielleicht noch einen Path ändern?

ich habe den Mapserver in c:\ms4w\ kopiert und die osm.map in c:\ms4w\mapserver\ und die Bilder in c:\ms4w\mapserver\data

Dann musst du den Pfad ändern:

http://127.0.0.1/cgi-bin/mapserv.exe?map=/ms4w/mapserver/osm.map&

Eventuell musst du dann auch noch Pfade in der osm.map ändern, da da wohl auch vom Root ausgegangen wird.

-

Ich hab mal ein Flash-Tutorial für Windows XP gemacht, in dem die einzelnen Schritte nochmal gezeigt werden: http://osmtools.de/tutorials/wms/wms.htm

Ist natürlich alles noch nicht unbedingt ideal formuliert, aber so auf die Schnelle vielleicht schon erstmal hilfreich.

Dennis[B] wrote:

viw wrote:

Wie du auf die 10cm Bodenauflösung kommst verstehe ich noch nicht so ganz.

Mein PWK ist 4,05 Meter lang und hat 37 Pixel wenn ich ganz rangezoomt habe.

habe ich 5cm Bodenauflösung da stehen.

Das ist dann falsch.

Jetzt den passenden Maßstab wählen. Empfohlen waren hier 1:500 kann man einfach unten bei Maßstab eingeben und
dann das Zip Archiv speichern.

Du schreibst hierzu "einfach". Bist Du so nett und lädst mir "einfach" Konstanz runter und schickst mir das per Email? Ich würde dafür Tage brauchen bei den Mini-Ausschnitten die man da wählen kann.

Empfohlen waren hier 1:500 kann man einfach unten bei Maßstab eingeben

Funktioniert leider nicht. In Konstanz wird die Karte weiß, wenn man den Maßstab < 757 eingibt.

Bitte entschuldige mich. Aber ehrlich gesagt habe ich weder Zeit noch Lust dir Konstanz herunterzuladen. Schließlich wird ja für mich auch keiner meine Lieblingsstadt herunterladen. Wenn du also die Bilder haben möchtest suchst du dir entweder einen anderen oder aber du lässt es bleiben. Dieser Teil ist im übrigen nie Teil der von dir kritisierten Anleitung gewesen. Wenn dir das Verfahren nicht passt, dann wende dich doch bitte an die Projektbeteiligten, welche in Kontakt mit Aerowest stehen. Vielleicht gibt es dort andere Möglichkeiten.

Lübeck wrote:

hi!

viw schreibt in #240

"Hier gibt es sowohl mit dem Plugin als auch mit dem WMS Server ein Problem. Denn diese Fotos musst du dir bei Aerowest herunterladen. Später soll es lokale WMS Server geben. Bisher sind die Verträge dafür aber noch nicht unterschreiben."

ist denn da mehr geplant und zu welchen bedingungen ... gibt es schon details ???

gruß Jan :-)

Ich habe keine Lust in diesem Thread zu blättern. Aber irgendwo da steht, dass zunächst eine Testphase von 8 Wochen angedacht ist. Wahrscheinlich wird da Göttingen als WMS zur Verfügung stehen. Außerdem hat Suncobalt mehrmals angeboten einen solchen WMS zu hosten.

hi!

@kellerma: ich habe nicht voll mitgelesen, aber...

Habe soeben ein Bild aus Konstanz mit 1:270 heruntergeladen,
selbst 1:70 scheint zu funktionieren.

heißt das du hast die bilder lokal oder ziehst du diese direkt von aerowest ?

gruß Jan :-)

Ich wollte die Mapserver-Konfiguration auf http://wiki.openstreetmap.org/wiki/DE:I … Luftbilder durch eine Version mit mehreren Layern für verschiedene EPSGs ersetzen. Das braucht man schon für die gerade mal drei abgedeckten Städte in Sachsen. Dadurch wird die Anleitung allerdings noch komplizierter. Wie ist eure Meinung dazu? So lassen oder allgemeiner/komplexer machen? Gleiche Frage zum Thema Transparenz. Finde ich toll, macht es aber auch wieder komplexer.

Holger

Lübeck wrote:

hi!

@kellerma: ich habe nicht voll mitgelesen, aber...

Habe soeben ein Bild aus Konstanz mit 1:270 heruntergeladen,
selbst 1:70 scheint zu funktionieren.

heißt das du hast die bilder lokal oder ziehst du diese direkt von aerowest ?

gruß Jan :-)

Wenn ich sie mir von Aerowest runterlade, habe ich sie lokal auf meiner Platte.
Also: Ja, ja 😉

Ciao,
Frank

Da bisher noch keine Nutzungsbedingungen der Aerowest-Luftbilder bekannt geworden sind, habe ich mir mal deren AGB angesehen (http://www.aerowest.de/wp-content/uploa … 01_agb.pdf). Da steht unter C3: "Eine Nutzung/Präsentation der Geodaten in georeferenzierter Form, insbesondere in Geo-Informationssystemen oder MapServices bedarf der ausdrücklichen schriftlichen Zustimmung der Aerowest". Also braucht jemand, der einen (auch lokalen) WMS-Server mit den Luftbildern betreibt, eine schriftliche Zustimmung. Hat die wer? Muss sich da jetzt jeder selber drüm kümmern oder nimmt das mal jemand in die Hand?

Herzlichen Dank an alle die mir geholfen haben.
Es hat jetzt geklappt. Die Luftbilder werden angezeigt.
Ein kleines Problem habe ich noch. Die Bilder werden sehr pixelig (viele kleine Kästchen) angezeigt. Ich habe die Luftbilder mit 1:800 gespeichert. 1:500 war nur geringfügig besser. Kann ich das irgendwo einstellen?
Danke und Ciao Holger

BREAKING NEWS:

Changeset 4289 in josm:
add Gauß-Krüger projection

added: data/BETA2007.gsb

Juhe 🙂

kellerma wrote:

BREAKING NEWS:

Changeset 4289 in josm:
add Gauß-Krüger projection

added: data/BETA2007.gsb

Juhe 🙂

ähm, also kann man in JOSM die Projektion in GK umschalten und muss dann hinterher in Merkator die Gebäude wieder rechtwinklig machen?

SunCobalt wrote:

ähm, also kann man in JOSM die Projektion in GK umschalten und muss dann hinterher in Merkator die Gebäude wieder rechtwinklig machen?

viel besser, Du kannst in GK jetzt "Q" drücken!

kellerma wrote:

SunCobalt wrote:

ähm, also kann man in JOSM die Projektion in GK umschalten und muss dann hinterher in Merkator die Gebäude wieder rechtwinklig machen?

viel besser, Du kannst in GK jetzt "Q" drücken!

Hast Du es probiert? Wenn ich früher 4326 genutzt habe und mit Q die Gebäude rechtwinklig gemacht habe, waren sie nur in 4326 rechtwinklig. In Merkator waren sie dann schief.

Holger-erf wrote:

Ein kleines Problem habe ich noch. Die Bilder werden sehr pixelig (viele kleine Kästchen) angezeigt.

Vermutlich hilft hier bei deiner WMS-Ebene in der "Ebenen"-Übersicht (dort wo deine aktuell vorhandenen Ebenen aufgelistet werden, z.B. deine OSM-Datenebene, deine WMS-Ebene, u.s.w.) einen Rechtsklick zu machen und dort "Auflösung ändern" anzuklicken, wenn du näher herangezoomt hast, denn erst dann wird die neue Auflösung vom WMS-Server abgefragt.
Das ist bei JOSM immer so, egal welcher WMS-Dienst verwendet wird.

Gruß,
Mondschein

kellerma wrote:

Changeset 4289 in josm:
add Gauß-Krüger projection

added: data/BETA2007.gsb

Das hört sich gut an!
http://josm.openstreetmap.de/changeset/4289/josm/

SunCobalt wrote:

kellerma wrote:

SunCobalt wrote:

ähm, also kann man in JOSM die Projektion in GK umschalten und muss dann hinterher in Merkator die Gebäude wieder rechtwinklig machen?

viel besser, Du kannst in GK jetzt "Q" drücken!

Hast Du es probiert? Wenn ich früher 4326 genutzt habe und mit Q die Gebäude rechtwinklig gemacht habe, waren sie nur in 4326 rechtwinklig. In Merkator waren sie dann schief.

Ja, Häuschen gemalt in 31467 mit JOSM 4289, dann nach mercator gewechselt, schaut ziemlich rechtwinklig aus 😉

dt2 wrote:

Ich hab mal ein Flash-Tutorial für Windows XP gemacht, in dem die einzelnen Schritte nochmal gezeigt werden: http://osmtools.de/tutorials/wms/wms.htm

Ist natürlich alles noch nicht unbedingt ideal formuliert, aber so auf die Schnelle vielleicht schon erstmal hilfreich.

Das gefällt mir sehr gut! 🙂
Sollten wir das auch im Wiki verlinken?

Gruß,
Mondschein

Mondschein wrote:

Das hört sich gut an!
http://josm.openstreetmap.de/changeset/4289/josm/

Sehr gut, würd ich sagen.

_Kein_ .prj-Datei mehr notwendig.

A) JOSM auf Gauss-Krüger 3 (oder 2/4/5) einstellen
B) heruntergeladenes Aerowest-jpg laden
C) Dialog poppt auf => "JOSM current projection" auswählen
D) Volle nadgrids-Genauigkeit (wie über WMS-server).

Danke BastiK!

Ciao,
Frank

Hier ein neues Mapfile für JOSM ab Version 4289, falls jemand die neue "Gauss-Krüger"-Projektion von JOSM mit dem WMS-Server testen möchte.
Die Umstellung der Projektion erfolgt wie üblich über "Bearbeiten -> Einstellungen -> Karten-Einstellungen -> Projektionsmethode".
Im Mapfile sind zwei Layer definiert, einer für Merkator (4326) und einer für Gauss-Krüger (3146x).

Wichtig ist hierbei, beim EPSG:3146x-Layer keine BeTA2007-Korrekturdaten anzugeben, denn sonst wird einmal durch den Mapserver und dann nochmal durch JOSM korrigiert, also einmal zu viel.

MAP
NAME␣␣␣␣"AerowestOSM"
STATUS␣␣␣␣ON
UNITS␣␣␣␣METERS

PROJECTION
#␣passenden␣EPSG-Wert␣eintragen,␣also␣das␣"x"␣ersetzen
"init=epsg:3146x"
END

WEB
METADATA
"wms_title"␣␣␣␣"Aerowest␣Luftbilder␣für␣OSM"
"wms_onlineresource"␣␣␣␣"http://127.0.0.1/cgi-bin/mapserv?map=/mapserver/osm.map&"
"wms_srs"␣␣␣␣"EPSG:4326"
"ows_enable_request"␣"*"
END
END

LAYER
STATUS␣␣␣␣ON
NAME␣␣␣␣"Luftbilder_Musterstadt_4326"

PROJECTION
#␣passenden␣EPSG-Wert␣eintragen,␣also␣das␣"x"␣ersetzen
"init=epsg:3146x"
"nadgrids=/mapserver/BETA2007.gsb"
END

METADATA
"wms_title"␣␣␣␣"Luftbilder␣meiner␣Musterstadt␣EPSG␣4326"
"wms_srs"␣␣␣␣"EPSG:4326"
END

TILEITEM␣"location"
#␣Speicherort␣der␣JPEG-Bilder,␣JGW-Dateien␣und␣der␣Index-Dateien
TILEINDEX␣"/mapserver/data/bilder.shp"
TYPE␣RASTER
END

LAYER
STATUS␣␣␣␣ON
NAME␣␣␣␣"Luftbilder_Musterstadt_31467"

PROJECTION
#␣passenden␣EPSG-Wert␣eintragen,␣also␣das␣"x"␣ersetzen
"init=epsg:3146x"
END

METADATA
"wms_title"␣␣␣␣"Luftbilder␣meiner␣Musterstadt␣EPSG␣3146x"
#␣passenden␣EPSG-Wert␣eintragen,␣also␣das␣"x"␣ersetzen
"wms_srs"␣␣␣␣"EPSG:3146x"
END

TILEITEM␣"location"
#␣Speicherort␣der␣JPEG-Bilder,␣JGW-Dateien␣und␣der␣Index-Dateien
TILEINDEX␣"/mapserver/data/bilder.shp"
TYPE␣RASTER
END
END

Passenden EPSG-Wert eintragen, also das "x" entsprechend ersetzen.

Gruß,
Mondschein

Moin,

so, wie ich es bisher verstehe, sind die Bilder mit dem bisher zur Verfügung stehenden Verfahren für die große Mehrheit der Otto-Normalmapper nicht nutzbar. Ich möchte einmal versuchen, wenigstens einige Infos in den Wikibeitrag http://wiki.openstreetmap.org/wiki/DE:W … Luftbilder einzubauen, die für Otto Normalmapper ohne Programmierkenntnisse verständlich sind. Ich verstehe dort und auch in dieser Diskussion und den Anleitungen nur Bahnhof.

Ich habe den Antrag bei Wikimedia über die finanzielle Förderung des Imports der Aerowest Bilder verfolgt und den Moment herbei gesehnt, in dem diese zu nutzen sind. Recht vielen Dank an die Macher. :-)

Nun fällt das Ganze aber etwas anders aus, als vermutet. Ich hatte gedacht, dass man die Bilder ähnlich wie diejenigen von Bing einfach in JOSM aktiviert und fertig. Das Einzige, was ich bisher verstanden habe ist, dass es so nicht funktioniert. Wie man bei Aerowest zu einem gewünschten Punkt navigiert, ist klar. Ich könnte ein Bild durch Bildschirmfotografie von der Aerowest-Seite in ein *.jpg umwandeln und dann einblenden. Wie man es allerdings geografisch korrekt positioniert, weiß ich nicht.

Folgende Fragen:

• Wenn man in der Lage ist, den Anleitungen hier zu folgen: Erreicht man dadurch in JOSM dieselbe Funktionalität (z.B. Raus- und Reinzoomen parallel zur JOSM Darstellung) wie bei den Bing Bildern?
  
• Wenn nein: Ist da irgendetwas in der Mache, was das Einblenden der Bilder in JOSM so vereinfacht, wie bei den Bing Bildern?
  
• Was ist überhaupt derzeit möglich? Bitte aus der Sicht eines JOSM Users erklären, der mit dem Begriff "WMS" nicht mehr anfangen kann, als dass es ein durch Häkchen aktivierbarer Layer ist.
  
• Ist es für solche User überhaupt möglich, die Luftbilder zu nutzen?
  
• Ist vorgesehen, die Bilder auch bei Potlatch einzublenden, denn viele User verstehen die Komplexität von JOSM nicht.
  
• Habe ich richtig verstanden, dass die Bilder bei JOSM nicht rechtwinklig sondern nur winkelverzerrt eingblendet werden?
  
• Wenn ja: Was nutzen Bilder, die aus diesem Grunde nicht deckungsgleich mit der rechtwinkligen Darstellung in JOSM sind?
  
• Auf der Wikiseite http://wiki.openstreetmap.org/wiki/DE:W … Luftbilder heißt es zunächst: "Das Bild ist georeferenziert und liegt dadurch lagerichtig vor." Später widerspricht sich das Wiki nach meinem Verständnis selbst: "Das ImportImagePlugin" verwendet die Korrekturdaten für Sachsen." Sind die Bilder nun lagerichtig oder nicht?
  
• Was versteht man unter Korrekturdaten und wie ermittelt man diese?
  
• Was unterscheidet die OSM-Spezialseite bei Aerowest von der Seite für Nicht-OSMler?
  
• Könnte vielleicht jemand Bildschirmfotos oder ein Video im Wiki hochladen, welche die bei JOSM eingeblendeten Aerowestbilder zeigen und eventuell die aufgeworfenen Fragen wie beispielsweise die Winkelverzerrung illustrieren?
  

Ich bedanke mich schon einmal für Eure Hilfe.

Mondschein wrote:

dt2 wrote:

Ich hab mal ein Flash-Tutorial für Windows XP gemacht, in dem die einzelnen Schritte nochmal gezeigt werden: http://osmtools.de/tutorials/wms/wms.htm

Ist natürlich alles noch nicht unbedingt ideal formuliert, aber so auf die Schnelle vielleicht schon erstmal hilfreich.

Das gefällt mir sehr gut! 🙂
Sollten wir das auch im Wiki verlinken?

Wenn du glaubst, dass es nützlich ist, warum nicht.

Mondschein wrote:

Hier ein neues Mapfile für JOSM ab Version 4289, falls jemand die neue "Gauss-Krüger"-Projektion von JOSM mit dem WMS-Server testen möchte.

Hat Gauss-Krüger irgendeinen Vorteil, wenn man sowieso den WMS-Server benutzt?

dt2 wrote:

Hat Gauss-Krüger irgendeinen Vorteil, wenn man sowieso den WMS-Server benutzt?

Eher nicht, außer das der WMS-Server keine Umprojektion der Bilder vornehmen muss und auch keine Korrekturdaten (BeTA2007) benötigt.
JOSM holt die Bilder bei "Gauss-Krüger" nämlich direkt in der ursprünglichen Projektion (so wie wir diese von Aerowest bekommen) beim Server ab.

Gruß,
Mondschein

Tirkon wrote:

Ich hatte gedacht, dass man die Bilder ähnlich wie diejenigen von Bing einfach in JOSM aktiviert und fertig.

Es wird evtl. für einige Städte (z.B. Göttingen) WMS-Server geben, dazu müssen sich aber erst Mitwirkende finden und entsprechende Verträge unterschrieben werden.
Vermutlich kann oder will Aerowest keinen WMS-Server anbieten.

Tirkon wrote:

Ich könnte ein Bild durch Bildschirmfotografie von der Aerowest-Seite in ein *.jpg umwandeln und dann einblenden. Wie man es allerdings geografisch korrekt positioniert, weiß ich nicht.

Viel zu umständlich, die Bilder können direkt als georeferenzierte JPEG-Bilder heruntergeladen werden.

Tirkon wrote:

• Wenn man in der Lage ist, den Anleitungen hier zu folgen: Erreicht man dadurch in JOSM dieselbe Funktionalität (z.B. Raus- und Reinzoomen parallel zur JOSM Darstellung) wie bei den Bing Bildern?
  

Ja, mit einem lokalen WMS-Server.

Tirkon wrote:

• Wenn nein: Ist da irgendetwas in der Mache, was das Einblenden der Bilder in JOSM so vereinfacht, wie bei den Bing Bildern?
  

Siehe oben.

Tirkon wrote:

• Ist vorgesehen, die Bilder auch bei Potlatch einzublenden, denn viele User verstehen die Komplexität von JOSM nicht.
  

Dazu ist mir nichts bekannt.

Tirkon wrote:

• Habe ich richtig verstanden, dass die Bilder bei JOSM nicht rechtwinklig sondern nur winkelverzerrt eingblendet werden?
  

Nein.

Tirkon wrote:

• Auf der Wikiseite http://wiki.openstreetmap.org/wiki/DE:W … Luftbilder heißt es zunächst: "Das Bild ist georeferenziert und liegt dadurch lagerichtig vor." Später widerspricht sich das Wiki nach meinem Verständnis selbst: "Das ImportImagePlugin" verwendet die Korrekturdaten für Sachsen." Sind die Bilder nun lagerichtig oder nicht?
  

Das ist kein Widerspruch, die Bilder liegen richtig georeferenziert vor, nur das ImportImagePlugin hat diese nicht genau an der richtigen Stelle eingeblendet, dieses Problem wurde gestern behoben.

Tirkon wrote:

• Was unterscheidet die OSM-Spezialseite bei Aerowest von der Seite für Nicht-OSMler?
  

Die Bilder für OSM sind georeferenziert, außerdem wird unten rechts das OSM-Logo eingeblendet.

Tirkon wrote:

• Könnte vielleicht jemand Bildschirmfotos oder ein Video im Wiki hochladen, welche die bei JOSM eingeblendeten Aerowestbilder zeigen und eventuell die aufgeworfenen Fragen wie beispielsweise die Winkelverzerrung illustrieren?
  

Siehe #252, dort ist ein Video verlinkt, welches z.B. am Ende die Bilder in Benutzung zeigt:
http://forum.openstreetmap.org/viewtopi … 98#p183198

Gruß,
Mondschein

-

Eine Alternative zu Tilecache wäre mapproxy (mapproxy.org)

-

ich habe tilecache. Die Konfiguration ist sehr simpel. Aber mit Potlatch habe ich es noch nie ausprobiert
Hier mal eine meiner Konfiguration.

[german]
type=WMSLayer
layers=german
url=http://localhost/wms?
srs=EPSG:900913
bbox=-20037508, -20037508, 20037508, 20037508
extent_type=loose
mime_type=image/png

hi !

nachdem ich am Wochenende einiges an Gebäuden mit dem geoserver(.org) gezeichnet habe bin ich heute auf den mapserver umgestiegen. Der VORTEIL ist das die Bilder einfach einkopiert werden können in das Datenverzeichnis und dann nur noch eine neue Index-Datei erstellt werden muss.

Die Beschreibung im Wiki und der Flash-Film sind übrigens klasse gemacht - es hat auf Anhieb geklappt !

Aber nun zum Problem. Die sauber gezeichneten Gebäude haben einen Versatz von ca. 1m - das ist schon ziemlich viel. Ich würde die Bilder vom geoserver als "richtig" ansehen, da hier in weiten Teilen die vorhandenen OSM-Daten mit den Luftbildern schon harmoniert haben.

Dann habe ich bei Mondschein (#269) von einer neuen map-Datei gelesen - aber dann habe ich nur noch rote Kacheln gesehen. Wieder die alte map-Datei und die versetzten Bilder kommen !

Kann mir einer weiterhelfen - ach ja, habe die JOSM-Version 4304 !

Gruß Jan :-)

Ich hänge dieses einfach nochmal an dieses Posting:

Für Rheinland-Pfalz habe ich gerade folgende offiziellen Koordinaten als Referenzpunkte gefunden: http://www.lvermgeo.rlp.de/index.php?id=5809

Hallo Jan,

habe ich das richtig verstanden:
Du hast einmal mit GeoServer mit nadgrids abgezeichnet und jetzt ist es von MapServer mit nadgrids verschieden?

Waere nett, wenn Du eine OSM-URL mitgeben wuerdest.

Ciao,
Frank

hi !

beim GeoServer bin ich wie hier beschrieben vorgangen - nadgrids habe ich bewußt nicht eingebunden !

Parkgebäude mit Geoserver:
http://www.openstreetmap.org/?lat=53.86 … 08&zoom=18

Mapserver:
http://www.openstreetmap.org/?lat=53.86 … 84&zoom=18

gruß Jan :-)

Lübeck wrote:

Für Rheinland-Pfalz habe ich gerade folgende offiziellen Koordinaten als Referenzpunkte gefunden: http://www.lvermgeo.rlp.de/index.php?id=5809

Hallo Jan

Sehr interessant.
Was mich etwas irritiert ist der Unterschied der geografischen Werte von ca. 3 Bogensekunden, je nachdem ob man von WGS84 oder Gauß-Krüger (Potsdam) ausgeht.

Der Unterschied in der Höhe zwischen Normalhöhe (amtlich) und dem Ellipsoid nach WGS84 von ca. 50 Meter überascht da weniger. Jetzt frage ich mich allerdings welche Höhe mein GPS-Gerät anzeigt.

Edbert (EvanE)

EvanE wrote:

Was mich etwas irritiert ist der Unterschied der geografischen Werte von ca. 3 Bogensekunden, je nachdem ob man von WGS84 oder Gauß-Krüger (Potsdam) ausgeht.

Der Besselellipsoid ist "kleiner", so ist sein Mittelpunkt weniger weit entfernt vo der Erdoberfläche (an Eurasien "angepappt") entfernt und dadurch wird der Winkel größer.

kellerma wrote:

EvanE wrote:

Was mich etwas irritiert ist der Unterschied der geografischen Werte von ca. 3 Bogensekunden, je nachdem ob man von WGS84 oder Gauß-Krüger (Potsdam) ausgeht.

Der Besselellipsoid ist "kleiner", so ist sein Mittelpunkt weniger weit entfernt von der Erdoberfläche (an Eurasien "angepappt") entfernt und dadurch wird der Winkel größer.

Gut, jetzt wissen wir warum es diesen Unterschied gibt. Was heißt das jedoch konkret für die Aerowest Luftbilder?
Die liegen ja mit Gauß-Krüger georeffenziert vor. Wir brauchen aber WGS84 und Merkartor-Projektion.

Edbert (EvanE)

Erst einmal vielen Dank für die Antworten auf meine Fragen, insbesondere an Mondschein. Ich bin von falschen Voraussetzungen ausgegangen. Der Kasus Knacktus war, dass mir nicht klar wurde, dass man nur ein einziges Bild in nur einer Auflösung auf einmal herunterladen kann. So karg hatte ich die Angelegenheit nicht im Kalkül gehabt. Mit dieser Erkenntnis waren dann alle Probleme beseitigt.

Trotz dieser Einschränkung ist das Ganze natürlich ein großartiges Projekt. Dies gilt insbesondere für ländliche Regionen, wo mit den bisherigen Möglichkeiten schon das Abmalen der Häuser zum Problem wurde.

Lübeck wrote:

Die sauber gezeichneten Gebäude haben einen Versatz von ca. 1m - das ist schon ziemlich viel. Ich würde die Bilder vom geoserver als "richtig" ansehen, da hier in weiten Teilen die vorhandenen OSM-Daten mit den Luftbildern schon harmoniert haben.

Hast Du diese Abweichung denn auch dann, wenn Du ein Bild ohne Umweg über WMS nach Josm importierst?

Die Frage, die ich mir in dem Zusammenhang stelle, was Luftbilder überhaupt leisten können. Man müsste darauf einen Referenzpunkt erkennen können und die Antwort fiele leichter. Ich will mal beim Katasteramt nachfragen, ob man die genauen Koordinaten einer Hausecke bekommen kann.

Eine andere Idee von mir war es, die Bodenberührung einer Hausecke bildschirmfüllend zu vergrößern und mit dem Cursor anzufahren. Das Ganze habe ich bei Aerowest, bei Josm und beim amtlichen Niedersachsen Viewer Plus getan. Letzterer läßt sich audf dieser Seite starten:
http://www.geodaten.niedersachsen.de/li … _psmand=28
Bei allen dreien beobachtet man nun die Koordinaten dieser Hausecke, welche gleich sein müssten.

Aerowest zeigt mir EPSG: 31466 an. Um diesen Wert bei Josm zu erreichen, muss ich bei Projektionsmethode "Gauß Krüger" und bei GK-Zone eine 2 einstellen. Beim Nedersachsenviewer kann ich durch Klicken auf das Gitternetz-Icon oben das "Koordinatensystem ändern". Seltsamerweise muss ich hier nicht 2 von der Josm GK-Zone, sondern "Gauß-Krüger, 3. Meridianstreifen" wählen. Mit "2" verschwinden hier die Luftbilder. Auch aus einer Baugenehmigung weiß ich, dass wir uns hier im 3. Meridianstreifen befinden.

Habe ich das alles so eingestellt, bekomme ich bei Josm, Aerowest und beim Niedersachsenviewer jeweils vollkommen unterschiedliche Koordinaten an der Hausecke angezeigt. Auch das Wechseln in ein anderes Koordinatensystem bringt beim Niedersachsenviewer keine Übereinstimmung.

Edit: Die Hausecke ist hier:
http://www.openstreetmap.org/?lat=53.59 … 8&layers=M

Wie geht das Alles zusammen? Ist die GK-Zone "2" in Josm am Ende gar ein Fehler?

Grüße
Tirkon

EvanE wrote:

kellerma wrote:

EvanE wrote:

Was mich etwas irritiert ist der Unterschied der geografischen Werte von ca. 3 Bogensekunden, je nachdem ob man von WGS84 oder Gauß-Krüger (Potsdam) ausgeht.

Der Besselellipsoid ist "kleiner", so ist sein Mittelpunkt weniger weit entfernt von der Erdoberfläche (an Eurasien "angepappt") entfernt und dadurch wird der Winkel größer.

Gut, jetzt wissen wir warum es diesen Unterschied gibt. Was heißt das jedoch konkret für die Aerowest Luftbilder?
Die liegen ja mit Gauß-Krüger georeffenziert vor. Wir brauchen aber WGS84 und Merkartor-Projektion.

Edbert (EvanE)

Merkator brauchst Du, weil Dein Bildschirm (hoffentlich 😉 planar und nicht ellipsoid-förmig ist.
Auch wenn ich mit GK-abezeichne, wird JOSM (hoffentlich 😉 beim Hochladen die Punkte wieder transformieren.

hi !

mit dem direkten Einbinden in JOSM habe ich das noch nicht - vielleicht mal morgen, wenn nicht ein anderer sich heute Nacht der Sache nochmal annimmt. Ich mache jetzt gleich schluss für heute !

Übrigens den Gang zum Katasteramt wirst Du Dir wohl sparen können.

Du brauchst eine Referenzkoordinaten in WGS84 um es in JOSM wirklich vergleichen zu können. Das KA wird Dir vermutlich nur Gauß-Krüger-Koordinaten oder ETRS89/UTM liefern können und dann mußt DU richtig transformieren. Das ist eines der größten "Probleme".

Nachdem ich den Link von Rheinland-Pfalz gefunden hatte habe ich heute mal bei dem KA nachgefragt wo ich gelernt habe - aber selbst die konnten mir leider nicht weiterhelfen.

Vielleicht hat einer Kontakt zu einem Vermesser der Standorte von SAPOS Referenzstationen hat - vielleicht kann man welche davon in den Bildern erkennen und entsprechend vergleichen.

Gute Nacht
Jan :-)

Tirkon wrote:

Eine andere Idee von mir war es, die Bodenberührung einer Hausecke bildschirmfüllend zu vergrößern und mit dem Cursor anzufahren. Das Ganze habe ich bei Aerowest, bei Josm und beim amtlichen Niedersachsen Viewer Plus getan.

Von welcher Stadt (in Niedersachsen) sprichst Du?.
Wenn Du Deine Hausecke hier nicht angeben willst (was sehr nachvollziehbar ist), vielleicht könntest Du
irgendeine Hausecke in 300 m Umgebung als OSM-URL angeben.

Ciao,
Frank

Lübeck wrote:

Dann habe ich bei Mondschein (#269) von einer neuen map-Datei gelesen - aber dann habe ich nur noch rote Kacheln gesehen.

Falls du Windows verwendest, darf hier im Mapfile darf das ".exe" nicht fehlen:

http://127.0.0.1/cgi-bin/mapserv.exe?map=/mapserver/osm.map&

dt2 wrote:

Ich hab mal ein Flash-Tutorial für Windows XP gemacht...

Hat klasse funktioniert! Danke.

Stolperstein:
Beim erstellen des Indexes bekam ich eine Fehlermeldung:

---------------------------
gdaltindex.exe␣-␣Einsprungpunkt␣nicht␣gefunden
---------------------------
Der␣Prozedureinsprungpunkt␣"free_defaults"␣wurde␣in␣der␣DLL␣"LIBMYSQL.dll"␣nicht␣gefunden.
---------------------------
OK
---------------------------

Ursache:
Trotz angepasster PATH-Variable (auch mit absolutem Pfad versucht) schnappt sich gdaltindex die alte (27.03.2002 14:54) libmySQL.dll aus dem Verzeichnis "c:\windows\system32" statt aus "\ms4w\Apache\cgi-bin". Ich habe kurzerhand die alte nach *.org umbenannt und die Version aus cgi-bin nach system32 kopiert: Klappt!

PHerison wrote:

dt2 wrote:

Ich hab mal ein Flash-Tutorial für Windows XP gemacht...

Hat klasse funktioniert! Danke.

Stolperstein:
Beim erstellen des Indexes bekam ich eine Fehlermeldung:

---------------------------
gdaltindex.exe␣-␣Einsprungpunkt␣nicht␣gefunden
---------------------------
Der␣Prozedureinsprungpunkt␣"free_defaults"␣wurde␣in␣der␣DLL␣"LIBMYSQL.dll"␣nicht␣gefunden.
---------------------------
OK
---------------------------

Ursache:
Trotz angepasster PATH-Variable (auch mit absolutem Pfad versucht) schnappt sich gdaltindex die alte (27.03.2002 14:54) libmySQL.dll aus dem Verzeichnis "c:\windows\system32" statt aus "\ms4w\Apache\cgi-bin". Ich habe kurzerhand die alte nach *.org umbenannt und die Version aus cgi-bin nach system32 kopiert: Klappt!

Pathvariable wird der Reihe nach abgearbeitet. Also wenn du die Pfade nur hinten dran schreibst und er weiter eher schon eine Datei findet wird er nicht weiter suchen.

PATH wird durch die BAT d:\ms4w\setenv.bat angepasst:

...
set␣PATH=\ms4w\Apache\cgi-bin;\ms4w\tools\gdal-ogr;\ms4w\tools\mapserv;\ms4w\tools\shapelib;\ms4w\proj\bin;\ms4w\tools\shp2tile;\ms4w\tools\shpdiff;\ms4w\tools\avce00;\ms4w\python\gdal;%PATH%
...

Sollte eigentlich als erstes in \ms4w\Apache\cgi-bin suchen. Tutabernüsch 🙁
Absoluter Pfad

...
set␣PATH=d:\ms4w\Apache\cgi-bin;...;%PATH%
...

hat auch nicht geholfen.

Tirkon wrote:

Aerowest zeigt mir EPSG: 31466 an. Um diesen Wert bei Josm zu erreichen, muss ich bei Projektionsmethode "Gauß Krüger" und bei GK-Zone eine 2 einstellen.

Der Streifen des 6°-Mittelmeridians reicht von 4°30' bis 7°30' östlich und das ist Zone 2 bzw. EPSG 31466.

Tirkon wrote:

Ist die GK-Zone "2" in Josm am Ende gar ein Fehler?

Nein.

Gruß,
Mondschein

kellerma wrote:

Von welcher Stadt (in Niedersachsen) sprichst Du?.

Hab doch glatt den Link vergessen, aber jetzt oben nachgetragen.
Die Hausecke ist hier:
http://www.openstreetmap.org/?lat=53.59 … 8&layers=M
Sie befindet sich in Niedersachsen, Landkreis Aurich, Stadt Norden.

Bei mir im Ort gibt es keine Aerowest Luftbilder - daher problemlos.

Gruß
Tirkon

Hi Tirkon,

es ist schwierig, bei "normalen" Auflösungen (in JOSM den Zeiger links oben bei vielliecht
20 m eingestellt) eine Übereinstimmung von Cursorspitze mit den Koordinatenangaben
eines Punktes rechts im "Auswahldialogfenster" zu erreichen.
Man muss wohl schon in den Submeterbereich reinzommen (also z. b. "0.33 m")
damit man die Koordinatenangabe des Mauszeiger mit Koordinatenangabe des Punktes trifft.

Tirkon wrote:

Die Hausecke ist hier:
http://www.openstreetmap.org/?lat=53.59 … 8&layers=M

Diese Hauseecke hat lon=7.20... und gehört damit offiziell zu GK2 und Aerowest ist richtig.
Nun ist sie aber nicht mehr allzu weit von der "Zonenengreneze" GK2/GK3 von 7.5 Grad entfernt.
Wie Du im wikipedia-Artikel zu Gauss-Krüger nachlesen kannst, wird im "grenznahen Gebiet"
ein Punkt auch mal gerne in der einen als auch in der anderen Zone angegeben, "Überlappung".
Der gleiche Punkt erscheint in GK2 aber anders als in GK3, es ist aber der gleiche Punkt!

Da wohl 90% des Staatsgebiets von Niedersachsen in GK3 liegen, wird der "Niedersachsenviewer"
auch das meiste in GK3 ausgeben, insbesondere "Zonengrenzgebiete".

Ciao,
Frank

kellerma wrote:

Diese Hauseecke hat lon=7.20... und gehört damit offiziell zu GK2 und Aerowest ist richtig.
Nun ist sie aber nicht mehr allzu weit von der "Zonenengreneze" GK2/GK3 von 7.5 Grad entfernt.
Wie Du im wikipedia-Artikel zu Gauss-Krüger nachlesen kannst, wird im "grenznahen Gebiet"
ein Punkt auch mal gerne in der einen als auch in der anderen Zone angegeben, "Überlappung".
Der gleiche Punkt erscheint in GK2 aber anders als in GK3, es ist aber der gleiche Punkt!

Da wohl 90% des Staatsgebiets von Niedersachsen in GK3 liegen, wird der "Niedersachsenviewer"
auch das meiste in GK3 ausgeben, insbesondere "Zonengrenzgebiete".

Das ist auch gut so, wenn man das ganze Land auf einer Karte zusammen anzeigen will. Sonst hätte die Karte nämlich irgendwo einen "Knick". Dann nimmt man lieber in Kauf, das es an den Rändern größere Verzerrungen gibt.

Ist in NRW genauso. Bei tim-online kann man wählen, ob man die Koordinaten in GK, GK2 oder GK3 angezeogt bekommt. Die Kartenprojektion ändert sich dadurch aber nicht.

Für unser JOSM wäre es natürlich am einfachsten, wenn man dessen Projektion auch auf GK einstellen könnte.
Mit proj4j bin ich da allerdings noch nicht glücklich geworden.
Für die Österreichischen Luftbilder scheint es da ein entsprechendes Plugin zu geben.

Gruß,
ajoessen

ajoessen wrote:

Für unser JOSM wäre es natürlich am einfachsten, wenn man dessen Projektion auch auf GK einstellen könnte.

Mein post nicht gelesen 😉

kellerma wrote:

BREAKING NEWS:

Changeset 4289 in josm:
add Gauß-Krüger projection

added: data/BETA2007.gsb

Juhe smile

Ciao,
Frank

kellerma wrote:

ajoessen wrote:

Für unser JOSM wäre es natürlich am einfachsten, wenn man dessen Projektion auch auf GK einstellen könnte.

Mein post nicht gelesen 😉

kellerma wrote:

BREAKING NEWS:

Changeset 4289 in josm:
add Gauß-Krüger projection

added: data/BETA2007.gsb

Juhe smile

Ciao,
Frank

Ist aber noch nicht in der tested. Da laß ich lieber noch die Finger von.

gruß,
ajoessen

ajoessen wrote:

Ist aber noch nicht in der tested. Da laß ich lieber noch die Finger von.

Die Unterschiede zwischen tested und (benachbarter) latest sind marginal.
Die JOSM-Entwicklung verfolgt nicht den Ansatz eines "stable branches" sondern die eines "rolling releases".

Ob Du jetzt 4279 oder 4304 nimmst, nimmt sich nicht viel.

Ciao,
Frank

kellerma wrote:

ajoessen wrote:

Ist aber noch nicht in der tested. Da laß ich lieber noch die Finger von.

Die Unterschiede zwischen tested und (benachbarter) latest sind marginal.
Die JOSM-Entwicklung verfolgt nicht den Ansatz eines "stable branches" sondern die eines "rolling releases".

Ob Du jetzt 4279 oder 4304 nimmst, nimmt sich nicht viel.

Nachdem mir neulich wegen eines kaputten plugins die tested nicht mehr wollte, durfte ich alle Einstellungen neu vornehmen. Nenee, dann warte ich lieber.

Gruß,
ajoessen

Hi Lübeck,

Lübeck wrote:

Aber nun zum Problem. Die sauber gezeichneten Gebäude haben einen Versatz von ca. 1m - das ist schon ziemlich viel. Ich würde die Bilder vom geoserver als "richtig" ansehen, da hier in weiten Teilen die vorhandenen OSM-Daten mit den Luftbildern schon harmoniert haben.
http://www.lvermgeo.rlp.de/index.php?id=5809

Ich hab' mir nur den "Buxtehuder Park" angesehen:
Sowohl mit JOSM (direkt mit GK-Unterstützung) als auch per lokalen WMS-Server hab' mit nadgrids gut 90 cm Abweichung und mit "Nord-Dtl. 1m Korrektursatz" 1.25 m Abweichung.

Du siehst, dass man schon gut 30 cm zwischen den verschieden Korrektursätze hat (und beide geben "Submeter-Genauigkeiten" an).

Ich denke, dass alles mit kleiner als 1 m "Kaffeesatzleserei" ist, solange man keine Katasterdaten von mehreren Häusern hat.

Ciao,
Frank

PS
Irgendwer hat in diesem thread für Aerowest-Bilder 0,5 m Genauigkeit postuliert, aber ich habe noch nie irgendwo konkrete Angaben von Aerowest gelesen.
Und für gute Lagerichtigkeit sind gute Höhenmodelle vonnöten und von diesen dürften die Landesvermessungsanstalten die besten haben, da sie
z. B. in Bayern seit über 200 Jahren "im Land herummessen" 😉

PPS
Und das die derzeitigen Bing-Bilder (von Geocontent für Dtl.) in diesem Genauigkeitsbereich schon vorgestossen sind, halt ich für eine Gerücht 😉

Hallo,

Danke für die große Arbeit am Plugin und an den Anleitungen. Bin nun dabei, für mich einen WMS für Ingolstadt aufzusetzen.
Local, auf ubuntu hat alles ohne Probleme funktioniert.
Da ich auch einen Server mit debian habe, dachte ich mir, einfach dort das gleiche machen und läuft auch genauso problemlos.
Pakete sind installiert, apache war schon da und geht auch. Nur ich bekomme andauernd eine 404 Meldung von apache, wenn ich versuche den link aufzurufen.
Was kann da los sein, kann irgendwas mit der konfig von apache oder mapserv nicht stimmen?

Gruß Christian

Hi,

es gibt wieder eine kleine Verbesserung bei der JOSM Unterstützung: Statt dem ImportImage Plugin kann nun das PicLayer Plugin (>= 26498) für die Einbindung der Luftbilder genutzt werden. Die Zip Dateien lassen sich direkt im JOSM öffnen, auch mehrere gleichzeitig. Wie vom PicLayer Plugin gewohnt, lassen sich die Luftbilder manuell verschieben und drehen (sollte im Normalfall aber nicht notwendig sein).

Ich denke, damit ist auf JOSM Seite erst mal alles getan, was möglich ist. Es wäre toll, wenn das mit dem WMS Server doch noch klappt. Dieses Runterladen von der Website ist doch etwas mühsam (für Micromapping allerdings ausreichend).

So, jetzt erst mal die ersten Straßenflächen eintragen... :-P

Gruß, Paul

ckol wrote:

Pakete sind installiert, apache war schon da und geht auch. Nur ich bekomme andauernd eine 404 Meldung von apache, wenn ich versuche den link aufzurufen.

Wie kann es denn sonst auch sein 2 webserver auf port 80, das kann nicht gut gehen. fehler behoben, läuft.

Danke an Mondschein fürs wiki!

Jetzt würde mich nur noch ein script für den download der bilder reizen 😄.

Gruß Christian

Tirkon wrote:

Die Frage, die ich mir in dem Zusammenhang stelle, was Luftbilder überhaupt leisten können.

Man sollte es nicht übertreiben.

Ich hab mal zum Vergleich dieselbe Ecke in Josm und in Merkaartor geladen, einmal Aerowest und einmal bing.

Ergebnis:
Merkaator hat 4m Versatz vertikal, Josm 2 Meter Versatz horizontal.

Viel Spaß beim Editwar ;-)

Gruß,
ajoessen

ajoessen wrote:

Ich hab mal zum Vergleich dieselbe Ecke in Josm und in Merkaartor geladen, einmal Aerowest und einmal bing.

Ergebnis: Merkaator hat 4m Versatz vertikal, Josm 2 Meter Versatz horizontal.

Hallo ajoessen

Deswegen macht ein source=* an größeren Objekten (nicht an Punkten) ja durchaus Sinn.
Ich denke die Wahl, ob man eher Aerowest oder Bing vertrauen will, dürfte nicht schwer fallen.

Edbert (EvanE)

kellerma wrote:

Man muss wohl schon in den Submeterbereich reinzommen (also z. b. "0.33 m")
damit man die Koordinatenangabe des Mauszeiger mit Koordinatenangabe des Punktes trifft.

Das war es, was ich mit "bildschirmfüllender Darstellung der Hausecke" auszudrücken versuchte. Ansonsten überstreicht der Cursor in Form der Hand bei Aerowest schon mehrere Meter und kann von daher nicht genau positioniert werden.

EvanE wrote:

Ich denke die Wahl, ob man eher Aerowest oder Bing vertrauen will, dürfte nicht schwer fallen.
Edbert (EvanE)

Mir ist das nicht so klar, würde aber vermuten, dass Du Aerowest meinst.

ajoessen wrote:

Ich hab mal zum Vergleich dieselbe Ecke in Josm und in Merkaartor geladen, einmal Aerowest und einmal bing.
Ergebnis: Merkaator hat 4m Versatz vertikal, Josm 2 Meter Versatz horizontal.

Würdet ihr als Ergebnis der Genauigkeitsdiskussion selbst bei Verwendung von Aerowest bis zu 5 Meter Fehler durch die beteiligten Luftbilder, Werkzeuge und Umrechnungen zwischen den verschiedenen Koordinatensystemen sehen?

Noch eine Frage zur Anleitung auf der Wikiseite:
Dort wird gesagt, man solle Josm auf Mercator Projektion zurückstellen. Was würde denn passieren, wenn man es nicht tut? IMHO wäre es eine nicht sehr intelligente Vorgehensweise von Josm, wenn er nicht in einem zur Datenbank kompatiblen System hochladen würde.

Gruß
Tirkon

ckol wrote:

ckol wrote:

Pakete sind installiert, apache war schon da und geht auch. Nur ich bekomme andauernd eine 404 Meldung von apache, wenn ich versuche den link aufzurufen.

Wie kann es denn sonst auch sein 2 webserver auf port 80, das kann nicht gut gehen. fehler behoben, läuft.

Danke an Mondschein fürs wiki!

Jetzt würde mich nur noch ein script für den download der bilder reizen 😄.

Gruß Christian

Obwohl ich mir selbst und sicher auch die Initiatoren des Aerowest Deals so etwas wünschen würden:

Sofern irgendjemand an scannende Scripte oder bei WMS Servern an öffentliche Server denkt, kann ich nur dringend empfehlen, davon Abstand zu nehmen. Überlasst die Initiative hierzu denjenigen, die die Verhandlungen mit Aerowest führen. Das Webinterface von Aerowest ist so, wie diese den Zugriff gestatten wollen und defensiver Umgang damit ist das Gebot der Stunde. Eine systematische Kopie einer ganzen Kommune würde ich bei der Interpretation des Webinterfaces nicht mehr als defensiv ansehen. Denn wenn hier die Bilder weitergehend genutzt werden, als durch die Verträge abgesichert ist, könnte der Schuss nach hinten losgehen und bringt die Initiatoren in Bedrängnis. Und das ist sicher das Letzte, was hier irgendjemand von uns möchte.

Ich habe das jetzt auch im Wiki vermerkt.

Gruß
Tirkon

Hi,

Tirkon wrote:

Noch eine Frage zur Anleitung auf der Wikiseite:
Dort wird gesagt, man solle Josm auf Mercator Projektion zurückstellen. Was würde denn passieren, wenn man es nicht tut?

Zeihundert Anfragen hier im Forum:
Hilfe! Mein Bing geht nicht!!
😉

Tirkon wrote:

IMHO wäre es eine nicht sehr intelligente Vorgehensweise von Josm, wenn er nicht in einem zur Datenbank kompatiblen System hochladen würde.

Schau' Dir doch mal die "Default-Einstellung" von JOSM an und parallel dazu das "Format" von OSM.

Ciao,
Frank

Tirkon wrote:

Noch eine Frage zur Anleitung auf der Wikiseite:
Dort wird gesagt, man solle Josm auf Mercator Projektion zurückstellen. Was würde denn passieren, wenn man es nicht tut? IMHO wäre es eine nicht sehr intelligente Vorgehensweise von Josm, wenn er nicht in einem zur Datenbank kompatiblen System hochladen würde.

Stellt man Josm auf WGS84, sind Kreise oval und Rechtecke verzerrt. Das geht beim abmalen solange gut, bis man die Werkzeuge "im Kreis anordnen" und "rechtwinklig machen" benutzt. Mittlerweile ist das Umstellen aber nicht mehr notwendig, da das Plugin in WGS84 und Mercator funktioniert; die josm-latest auch in Gauss-Krüger-Projektionen.

Das hat aber nichts mit dem Hochladen zu tun, das erfolgt immer in WGS84 latlon.

Gruß,
ajoessen

bastik wrote:

es gibt wieder eine kleine Verbesserung bei der JOSM Unterstützung: Statt dem ImportImage Plugin kann nun das PicLayer Plugin (>= 26498) für die Einbindung der Luftbilder genutzt werden. Die Zip Dateien lassen sich direkt im JOSM öffnen, auch mehrere gleichzeitig. Wie vom PicLayer Plugin gewohnt, lassen sich die Luftbilder manuell verschieben und drehen (sollte im Normalfall aber nicht notwendig sein).

Erstmal herzlich Dank an Paul (aka BastiK)!
Du programmierst so schnell, dass man gar nicht mit dem wiki-update hinterherkommt 😉

bastik wrote:

Ich denke, damit ist auf JOSM Seite erst mal alles getan, was möglich ist

Vielleicht könnte man das PicLayer-Plugin in JOSM-Core noch integrieren? 🙂

Ciao,
Frank

PS
Wiki ist angepasst 😉

Das Integrieren halte ich für nicht gut...dafür nimmt es in der linke Leiste zu viel Platz ein, der zudem für die AeroWest-Bilder gar nicht gebraucht wird.
Das ist für mich gerade auch ein Vorteil von josm. Jeder fügt sich das hinzu, was er braucht.

ajoessen wrote:

Mittlerweile ist das Umstellen aber nicht mehr notwendig, da das Plugin in WGS84 und Mercator funktioniert; die josm-latest auch in Gauss-Krüger-Projektionen.

Man sollte beim Verwenden der Plugins unbedingt auf Gauß-Krüger umstellen, damit die in JOSM eingebaute BeTA2007-Korrektur durchgeführt wird . Nur so kommt die Genauigkeit der Aerowest-Bilder mit "terrestrisch eingemessenen Vollpasspunkten im amtlichen Koordinatensystem" voll zur Geltung.

Wer lieber bei Merkartor bleiben möchte, sollte Mapserver verwenden.

@bastik: Eine Hinweismeldung bei der Transformationsauswahl wäre für Newcomer sicherlich hilfreich.

DD1GJ wrote:

Man sollte beim Verwenden der Plugins unbedingt auf Gauß-Krüger umstellen, damit die in JOSM eingebaute BeTA2007-Korrektur durchgeführt wird . Nur so kommt die Genauigkeit der Aerowest-Bilder mit "terrestrisch eingemessenen Vollpasspunkten im amtlichen Koordinatensystem" voll zur Geltung.

Wer lieber bei Merkartor bleiben möchte, sollte Mapserver verwenden.

Ich schlage vor, das so ins Wiki zu übernehmen:

Bei Verwendung der Plugins sollte JOSM unbedingt auf die Projektionsmethode Gauß-Krüger umgestellt werden, damit die in JOSM eingebaute BeTA2007-Korrektur durchgeführt wird.
Nur so kommt die Genauigkeit der Aerowest-Bilder mit "terrestrisch eingemessenen Vollpasspunkten im amtlichen Koordinatensystem" zur Anwendung.
Wer lieber die Projektionsmethode Merkartor verwenden möchte, sollte unbedingt MapServer verwenden.

Einverstanden?
Ist das inhaltlich richtig?

Gruß,
Mondschein