Luftbilder von Aerowest

naja der Unterschied zwischen 500 und 4000 ist ja auch sehr groß. Du musst 500 mit 1000 und 1500 vergleichen. Erst dann macht es Sinn. Natürlich bekommst du bei 4000 viel mehr Fläche, aber bei mir war der Qualitätsverlust zwischen 1324 und 1500 zu sehen. Da habe ich dann größere Dinge nicht probiert.

Mein Erklärungsversuch war nicht hinreichend genau :wink:

Aufgrund der JPEG-Kompression bekommst Du “Artefakte”, die am kleinsten sind, wenn der Masstab am größten ist,
z. B. 1:50 oder 1:75 (was immer auch Aerowest im Bestfall ausliefert)
[Die Unterschiedlichkeit beim größreren/kleineren Ansichtsfenster lass’ ich mal weg, da mein netbook eh’ nur quasi "1 Fenstergröße (maximal) kennt ;)]
Durch diese “Artefakte” ist es aber besser, wenn die Pixelgröße echt kleiner als die z. B. 10 cm ist,
z. B. 2.5 cm “Sub-pixel”.

Den maximalen “Inforamtionsgehalt” kannst Du aber schon bei 1:500 (oder so) entnehmen, da die gegebene Auflösung (10 cm) des "Ur-"Bildes von Aerowest auch bei größeren Masstab
(1:75 oder 1:50) nicht besser wird.

:wink:

Ciao,
Frank

Zumindest rechnet der Betrachter (ohne Java) so.

Seltsam, bei mir (Debian, Firefox 7, kein Java) habe ich diesen Effekt noch nie beobachten können, obwohl ich schon viele Bilder (deutlich über 1000) in unterschiedlichen Maßstäben heruntergeladen und überprüft habe.
Möglicherweise werden zufällig irgendwelche Informationen nicht geladen, wenn der Server überlastet ist und es kommt deshalb zu Fehlern bzw. dem von dir beobachteten Verhalten?

Ja, so habe ich das auch überprüft, allerdings nicht nur mit dem Messinstrument von JOSM, sondern auch mit dem des Aerowest-Betrachters.
Die Ergebnisse waren immer (bis auf wenige Zentimeter) identisch und der von mir errechnete Maßstab stimmte mit der Anzeige überein, deshalb bin ich fest davon überzeugt, dass meine Formel zumindest bei mir stimmt. :slight_smile:

Ich habe nur beobachtet, dass der Java-Betrachter, wenn man das Fenster verkleinert:

  • den Maßstab nicht anpasst

  • das Luftbild nicht skaliert wird, (so dass der ursprüngliche Ausschnitt in das kleiner Fenster passen würde), sondern nur unten und rechts abgeschnitten wird

Das heruntergeladene georef. Bild entspricht dann aber genau diesem verkleinerten (unten und rechts abgeschnitten) Bereich, welche im Java-Betrachter sichtbar ist.

Gruß,
Mondschein

Bei EPSG:3146* wird mit Metern als Maßstab gearbeitet (korrigiert mich, wenn ich da falsch liege). Folglich kann man das mitgelieferte Worldfile mit der Endung *.jgw öffnen und in Zeile 1 die Meter pro Pixel in West/Ost-Richtung und in Zeile 4 in Nord/Süd-Richtung ablesen. Wie schon bemerkt geht durch die Komprimierung noch etwas an Details verloren. Bilder in “Originalauflösung” kann Aerowest nicht liefern, da wir an Orthofotos interessiert sind und auf dem Weg dorthin mehrere Bearbeitungsschritte durchlaufen wurden, die die Auflösung der Originalbilder ändern.

Yep, Meter ist richtig.
Yep, gute Idee, Daten aus *.jgw direkt ablesen (was vermutlich auch ‘gdalinfo’ macht :wink:
Nope. mit "Ur-"Bild meinte ich natürlich nicht das “Bild direkt vom Flieger”, sondern das Orthobild.
Da wir im Header des *.jpg lesen
CREATOR: gd-jpeg v1.0 (using IJG JPEG v62), default quality
also jenes noch vor der “JPEG-Kompression”, möglicherweise ein (unkomprimiertes) (Geo)Tiff

Leute mit Bildverarbeitungserfahrung wissen das sicher viel besser als ich :slight_smile:

GeoTiff wäre natürlich ideal, wird aber vermutlich nicht gehen, damit andere Anbieter nicht einfach diese Quelle absaugen können.

Was mir wichtig wäre, sind Bilder ohne zusätzliche Skalierung. Also so wie sie in der Aerowest- Datenbank sind direkt aus der Aerowest Auflösungspyramide. Dabei hätte man die geringsten Verluste. Denn die Skalierung bedeutet zusätzliche Artefakte, neben den ohnehin vorhandenen Artefakten aus der JPEG-Komprimierung.

Edbert (EvanE)

Ich bin gerade dabei meinen WMS server schneller zu machen, nur mir geht langsam der Speicherplatz aus. Momentan habe ich im data Ordner 16GB (Bilder) drin. Wie viel mehr kostet mich es eine Pyramide aufzubauen?
1GB ist momentan noch frei, reicht wahrscheinlich nicht? Sonst müsste ich mich nach einem neuen V-Server umsehen, der eine größere Platte hat.

16 GB original JPEG-Bilder oder umgewandelt in ein anderes Format?

Ca. 50%, steht aber auch im Wiki.

Sicher nicht.

Gruß,
Mondschein

So, die 14 Tage Testzeitraum sind nominal um,
C-R muesste nun im neuen Glanz erstrahlen :wink:
Aber wahrscheinlich sind die Ruhrgebietler allesamt auf der OpenRheinRhur,
keine Zeit zum Mappen :wink:

hi Frank,

c-r = Castrop.-Rauxel???

wenn ja, hab ich leider was verpasst. War meine Heimatstadt, bevor es mich in den Taunus verschlagen hat.
Ich verfolge diesen Thread nicht ständig. Geht da noch was?

Gruss
Walter

p.s. Castrop-Rauxel ist übrigens die lateinische Übersetzung von Wanne-Eickel :wink:

png, Sie haben Post, Herr Wambacher :wink:

Sehr schön soweit.

Und was sind die Ergebnisse?
Welche Hard- und Software wurde eingesetzt?
Wieviel Bandbreite braucht man?
Warum wurde ein TMS statt ein WMS verwendet?

Wann können wir so einen Server lokal für weitere Städte/Gebiete einrichten?

Edbert (EvanE)

Moin Edbert,

Warum wurde ein TMS statt ein WMS verwendet?
Damit auch Potlatch User (welche keine WMS verwenden können) Nutzen davon haben.

Welche Hard- und Software wurde eingesetzt?
Dir hat doch Oliver schon geantwortet.

Wann können wir so einen Server lokal für weitere Städte/Gebiete einrichten?
Soweit ich Marc (Gehling) aka “mac do” richtig verstanden habe, wird es keinen zentralen Server für ganz Dtl. (bzw. NL) geben.
Die lokalen Communities sollen sich einzeln bei ihm melden.

Don’t shoot the messager :wink:

Das macht Sinn. An Potlatch denke ich als JOSM-Nutzer zu wenig.
In JOSM hat es zudem den Vorteil, dass man den Tile-Cache nutzen kann, was die notwendige Bandbreite reduzieren sollte.

Sorry, Ruhrgebiet-Liste ist nicht ständig auf meinem Radar. Habe es in der Zwischenzeit gefunden.

Für die, die ebenfalls die Ruhrgebiet-Liste nicht (ständig) lesen eine kurze Zusammenfassung:

  • Virtueller Rechner mit 2 CPUs und 1GB RAM
  • MapProxy + Nginx Webserver

In Summe nichts besonderes.

Dann werde ich das bei unserem nächsten Stammtisch anregen.

Auf keinen Fall.
Du scheinst aber mehr Informationen zum Thema zu haben, als manch anderer (mich eingeschlossen).

Edbert (EvanE)

Sind Orginal jpg’s, was sonst :smiley:
Hatte die Ergänzung im Wiki leider nicht gesehen. Läuft jetzt viel schneller, danke.
//Jetzt auf neuem Server mit 80 GB hdd, das sollte wohl erstmal reichen :slight_smile:

Wie sieht das denn genau aus mit dem großen TMS Server?
Bekommt man einen link auf Anfrage, oder braucht jedes Bundesland seinen eigenen “lokalen”?

Gruß ckol

Hallo ckol und herzlich willkommen im Forum

So wie ich die bisherigen Diskussionen im Forum und auf der Mailingliste verstanden habe, soll es keinen zentralen TMS-Server geben. Das soll die Community auf lokaler Ebene, also z.B. für einen Kreis, selber regeln. Ein Ziel dieses Wissenswert-Projektes ist ja auch lokales Knowhow aufzubauen.
Siehe auch die Wiki-Seite http://wiki.openstreetmap.org/wiki/DE:WissensWert/Luftbilder und die zugehörige Diskussionsseite.

Edbert (EvanE)

Also ungefähr 21000 Bilder.
Fleißig. :smiley:

Für alle Orte wird es diesen wahrscheinlich nie geben. :frowning:

Der Testserver liefert nur Bilder für Castrop-Rauxel, das wird dir vermutlich eher weniger helfen, oder?

Gruß,
Mondschein

Danke!

Danke meinem Server der dafür geschuftet hat, die Bilder zu bekommen. (15GB mit 13.000 Bilder)
Bei mir liegt momentan komplett der Kreis-Ingolstadt. Platz hätte ich also noch wenn jemand für sich einen anderen haben möchte…

Gruß ckol

Nicht das ich hier die Spassbremse sein will, aber die Bilder per Skript runtersaugen ist nicht erlaubt.

Sorry, dass ich mich so ungenau ausgedrückt habe. Ich meinte damit , dass ich gerne die heruntergeladenen Bilder von anderen Usern mitaufnehme und zur Verfügung stellen kann.

Gruß ckol