ich bin ziemlich neu was Mapservices angeht und versuche mich noch ein wenig zu orientieren. Ich vermute ganz stark, dass folgende Probleme eher allgemeiner Natur sind, obwohl andere Software eingesetzt wird und ihr mir trotzdem helfen könntet.
Vorgeschichte:
Wir planen eine HTML Applikation, die an einen eigenen Mapservice gekoppelt ist. Es existiert ein Prototyp mit einem GeoServer (Version 2.0) und zwei Demokarten (GeoTIF) die aufwändig händisch zusammengebastelt und georeferenziert (WGS 84) wurden. Die Kollegen, die den Server aufgesetzt, die Karten georeferenziert und den Prototypen programmiert haben sind leider nicht mehr da (sonst hätte ich sie natürlich längst gefragt).
Da das Projekt ein wenig in die Jahre gekommen ist wird es nun unter anderem von mir weiter entwickelt. Ich hab einen neuen GeoServer (Version 2.1.4) aufgesetzt und mehrere offizielle Karten bekommen. Da ich noch nicht genau weiß wie ich den GeoServer dazu bringe über JavaScript Karten auszuspucken, gucke ich mir die Karten aktuell mit dem integrierten OpenLayers in der Vorschau an. In der Layer-Vorschau funktioniert alles… es ist sehr langsam aber ich kann alle Karten sehen.
Mein neuer GeoServer kann mit dem vorhandenen HTML Prototypen keine Karten liefern (Error 404 für jede Kachel), obwohl ich im JavaScript die IP-Adresse für den GeoServer WMS angepasst habe. Somit müsst ich noch herausfinden wie ich den GeoServer richtig konfiguriere…
Fakten:
Dem GeoServer habe ich eine integrierte GeoWebCache Installation verpasst.
Die zwei Demo-Karten kann ich in den RAM laden (seeding) und über die GeoWebCache Demo-Seite angucken. Die offiziellen Karten kann ich nur in der Layer-Vorschau sehen, jedoch nicht aus dem GeoWebCache heraus. Der Bildschirm bleibt weiß und ich sehe lediglich die OpenLayers Steuerelemente oben links am Bildschirmrand. Woran könnte das liegen?
Das Referenzsystem konnte vom GeoServer nicht erkannt werden (und GDALinfo sagt mir:
Driver: GTiff/GeoTiff
Files: xxxx.tif
xxxx.tfw
Size is XXXX, XXXX
Coordinate System is `'
Origin = 3524000.000000000000000,5688000.000000000000000)
Pixel Size = (0.XXXXXXXXXXXXXXX,-0.XXXXXXXXXXXXXXX)
Meta Data:
TIFFTAG_SOFTWARE=XXXXXXX
TIFFTAG_XRESOLUTION=1
TIFFTAG_YRESOLUTION=1
TIFFTAG_RESOLUTIONUNIT=1 (unitless)
Image Structure Metadata:
INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left ...
...
Center ...
Band 1 Block= ...
Overviews: 1024x1024
Band 2 Block= ...
Overviews: 1024x1024
Band 3 Block= ...
Overviews: 1024x1024
Somit habe ich mit gdal_translate jede Karte einzeln nach WGS 84 konvertiert (
). Die Karten konnte ich im GeoServer anlegen und erfolgreich publizieren. Wie gesagt, in der Layer-Vorschau sehe ich alle Karten über OpenLayers!
Mit QGIS hab ich zwar noch nicht gearbeitet und müsste das auch erstmal lernen, hab aber mal eine der Karten geladen und die Koordinaten von einem Gebäude mit einer der Demo-Karten verglichen. Dabei fällt auf, dass die Koordinaten sehr merkwürdig aussehen und ich das passende Referenzsystem nicht finden kann. Beispiel einer Koordinate: 3534819.3 5686994.8 Was kann das für ein Referenzsystem sein???
Eingesetzte Software:
GeoServer: 2.1.4
Installiert: auf Remote Server im lokalen Netzwerk
GeoWebCache: 1.3-RC3
Installed: auf dem selben Server wie GeoServer
Apache Tomcat: 7.0.30
Java JDK: 1.7.0_07
OS: Ubuntu Server 12.04 - x64
Konfiguration ist ziemlich default, da das sowieso erstmal eine Entwicklungs-Umgebung ist.
Gauß-Krüger kommt hin, falls Dein Gebäude am Königsplatz in Kassel liegt (1. Ziffer: Zone 3 also um den 9. Längengrad; 534819 heisst 34.819km rechts vom Mittelmeridian; 5600km nördlich vom Äquator). Ansonsten kann ich leider nichts dazu sagen, keine Ahnung von GeoServer…
Hallo,
als Alternative käme theoretisch ETRS89 UTM-Zone 33 in Frage, dann wäre der Punkt aber in Polen, was sicher unwahrscheinlich ist.
Was man aber sicher beachten muß: bei der Verwendung von Gauss-Krüger-Daten in Zusammenhang mit WGS84 muß der Datumsübergang beachtet werden, beiden liegen unterschiedliche geographische Systeme zugrunde. Beim QGis erledigt das die Funktion ‘OnTheFly’-KBS-Transformation aktivieren, beim ArcGis ist die netzbasierte Methode NTv2 die Beste. Passieren bei der Transformation Fehler bekommt der Export einen Lagefehler (Norost <–> Südwest) von ca. 100-200m, je nachdem, wo man ist.
Das ist auch der Grund warum ich dafür plädiere, möglichst schnell auf Gauss-Krüger zu verzichten und ETRS89 bzw. WGS84 zu verwenden, zumal die stattlichen Stellen such nach und nach auf ETRS89 wechseln. Eine Verwendung von Gauss-Krüger ist für mich nicht mehr zeitgemäß.
Diese OnTheFly-Transfomation ist zudem Performance-fressend. Die gemeinsame Verwendung von Gauss-Krüger und ETRS89 bzw. WGS84 fehlerträchtig.
Soweit dazu. Zum Geo-Server kann ich auch nichts sagen.
Ach ja, Ergänzung: in der *.tfw-Datei (World-File) stehen auch die Parameter der jeweiligen gleichnamigen tif-Datei. Diese tfw-Datei kann mit einem normalen Test-editor geöffnet und gelesen werden. Im Zweifel helfen die darin stehenden Agaben zur Identifizierung des Koordinatensystems.
Hilfreich ist auch der im QGis 1.8 enthaltene GIS-Browser, mit dem man sich auch Koordinatensystem und die Metadaten anschauen kann.
Du hast den Volltreffer gelandet super! Die Koordinate gehört zum Königsplatz in Kassel. Ich habe eben gerade mal über den Online Javascript converter http://www.orchids.de/florkart/skripte/GeoTrans.htm die Koordinaten vom Gauß-Krüger und WGS84 verglichen und es passt. Somit ist für mich Gauß-Krüger eindeutig und zweifelsfrei identifiziert. Danke für den Hinweis!
@steckenkundler:
Auch an dich noch ein Danke für deine Info’s und deine Mühe! WGS84 war für das Projekt geplant, die Karten kamen nun leider mit Gauß-Krüger. Somit müsst ich mich jetzt erstmal um eine möglichst verlustfreie Konvertierung kümmern. In den World-files stehen gerade einmal eine Hand voll Zeilen mit denen ich nicht wirklich viel anfangen kann, da es sich nur um Koordinaten bzw. Pixelgrößen handelt… (glaube ich). Wie gesagt, ich bin noch nicht tief genug in der Materie drin und muss mir das Wissen noch erarbeiten. Wenn ich das richtig verstanden habe ist die “OnTheFly”-KBS-Transformation live? Die Performance ist für das Projekt fast genauso wichtig wie die Verfügbarkeit des gesamten Systems. Somit werde ich mit Sicherheit nicht drum herum kommen alle Karten händisch zu konvertieren (wenn das möglich ist).
edit:
Ich habe nun alle Karten über ein script konvertiert. Die Konvertierung erfolgte über folgenden Befehl:
Dadurch ist auch das Problem mit dem GeoServer behoben. Die Karten können nun ohne Probleme in den RAM geseeded werden und sind sofort greifbar. Leider habe ich nicht damit gerechnet, dass die Karten verzerrt werden und die fehlende Fläche mit Schwarz aufgefüllt wird. Für das Projekt ist das leider inakzeptabel.
Kenne mich auch nicht mit GeoServer aus, allerdings wurde hier im Forum recht viel mit Aerowest-Luftbildern gearbeitet. Diese Bilder konnten als kleine Ausschnitte in epsg:3146x heruntergeladen werden und entweder direkt in JOSM oder über MapServer/TileCache eingebunden wurden. Letzteres würde einmal umgewandelte Tiles lokal cachen und könnte auch direkt in OpenLayers eingebunden werden (ohne schwarzen Trauerrand).
Ansonsten fällt mir noch der folgende Thread ein: http://forum.openstreetmap.org/viewtopic.php?id=13575
Da wird zunächst mit gdal_merge ein großes .tif erzeugt, das man ggfs. anschließend noch konvertieren könnte (falls das File nicht zu groß ist?).
Vielleicht klappt das auch mit einem virtual dataset (.vrt), auf dem man gdalwarp anwendet? Damit kenne mich mich nun gar nicht mehr aus.
super! Die Koordinate gehört zum Königsplatz in Kassel. Ich habe eben gerade mal über den Online Javascript converter