Problem mit Rastern und Koordinatensystemen

Hallo zusammen,

folgendes Problem:
Lade ich DGK Blätter, denen kein Koordinatensystem zugewiesen ist, in einen Datenrahmen wird das Dokument enorm langsam. Wenn ich dem Datenrahmen sein Koordinatensystem 'entziehe' wird das Dokument wieder schnell. :-(

Wenn ich jetzt versuche, den DGK-Blättern (tif, CCITT4 komprimiert) ein Koordinatensystem zuzuweisen, werden diese zerstört, ich kann sie weder in IrfanView, noch in Photoshop, geschweige denn ArcGIS öffnen.

Hat jemand ähnliche Erfahrung gemacht, oder funktioniert es bei jemandem nachweislich?

Ich benutze ArcGIS 9.2 SP3 mit deutschem Supplement, unter SP2 hatte ich das gleiche Problem.

Gruß
Jens
auch wenn es nicht die feine Art ist, zu schieben...

Kann denn noch nicht mal jemand sagen, er hätte das Problem nicht?

Mein Hauptproblem ist, dass DGKs (vermutlich auch andere 2-Ton-Raster) z.T. durch das Zuweisen eines Koordinatensystems zerstört werden.

Das Problem mit dem Koordinatensystem im Datenrahmen muss doch theoretisch noch jemand haben. Wenn das unbekannt ist, würde ich mich auch über jede Rückmeldung freuen, denn das grenzt die Fehlersuche ein.

Gruß
Jens
Hallo Jens,

ich habe keine DGK5 ohne Koordinatensystem. Die haben bei mir alle eine tfw Datei.

Sorry.

Gruß
Andreas
Hallo Jens,

haben Deine DGK5 Blätter wirklich kein Koordinatensystem, oder erkennt ArcView u.U. die Informationen des Headers nicht richtig.
Bei uns gab nämlich hierbei Probleme.
Bis das dieses Problem behoben war, habe ich mir einen 'Sekundärdatenbestand' erstellt, indem ich die Tiffs in IrfanView geöffnet habe und sie dann als Tiff wieder abgespeichert habe.
Hierbei verlieren sie die Info des Headers. Danach habe ich mir für jedes DGK5 Blatt eine passende TFW Datei erstellt.
Danach gab es keine Probleme mehr beim Einladen, ArcView in diesem Fall auf die Info aus den Tfw Dateien zurückgreift.

Beispiel TFW für Blatt 480724gs:

0.317510716
0
0
-0.317510716
2568000.000
5668000.000

Gruß
Andreas
Hallo,

endlich Antworten! ;-)

Zum Verständnis: Die Blätter sind alle georeferenziert. Entweder GeoTiffs oder per tfw.

Dies bedeutet aber noch nicht, dass Ihnen ein Koordinatensystem zugewiesen ist. Wenn ich mit Daten aus den Niederlanden (RDH) in DHDN Zone2 arbeiten will, müssen diese ja projiziert werden, also muss ich ihnen ein Koordinatensystem zuweisen. Da fangen die oben beschriebenen Probleme an.

Gruß
Jens
Nachfrage:

Stellt Ihr in den Eigenschaften des Datenrahmens ein Koordinatensystem ein?

Jens
Ja sicher,
und zwar das für das Gebiet in dem ich arbeiten möchte.

Bei uns Germany_Zone_3

Allerdings liegen die DGK´s auch in dieser Zone.
Aber ich habe ja auch keine Probleme.

Viel Erfolg

Andreas
Wenn Du Dir die Eigenschaften eines DGK-Blattes ansiehst, ist unter Quelle ein Raumbezug eingetragen? Und was steht bei Rasterinformationen zur Komprimierung?

Gruß
Jens
Hallo,

also ich würde mal versuchen, mit einem Bildbearbeitungsprogramm (z.B. IrfanView) per Batch die Komprimierung auf LZW zu ändern (Vorsicht: bei GeoTiffs geht die Referenzierung verloren - versuchs erstmal mit einem TIFF mit TFW). Tritt das Problem dann immer noch auf?

Nochmal zum Verständnis (@Andreas Wolf etc.):
Die Einstellung eines Koordinatensystems im Datenrahmen ist immer dann (und nur dann!) notwendig, wenn man Daten aus verschiedenen Projektionen zusammen darstellen will. Im Datenrahmen sollte man nur was einstellen, wenn man das braucht. Ansonsten kann's damit immer wieder mal Probleme geben.
Das Koordinatensystem hat nichts mit der Referenzierung (TFW) zu tun!

Ich persönlich mag diese on-the-fly-Projizierung nicht so gerne, weil man schnell den Überblick verliert, welche Daten nun wie referenziert sind. Ich projiziere die Daten lieber vorher per Toolbox alle in das selbe System.

Also nochmal @Jens:
Ich glaube, es hat was mit der Komprimierung zu tun.
Den Eindruck des Problems mit der Komprimierung habe ich auch, s.o. Leider bin ich nicht sicher, dass es nur bei CCITT4 vorkommt.

Da wir viel im Grenzraum D/NL/B arbeiten, sind die Raumbezüge leider wichtig.

Nebenher habe ich die Attributdomänen von GDB zu schätzen gelernt und gleichzeitig festgestellt, dass ArcGIS teilweise ein destruktives Verhalten mit shapes an den Tag legt. Folglich arbeite ich z.T. mit Datenbanken und da geht nix ohne Raumbezug.

Gruß
Jens
@Wolfgang,
Vielen Dank für den Hinweis, das war mir so noch nicht bewußt.

@Jens
Ich habe die DGK eigentlich immer in einer GDB. Nun habe ich mir eine DGK 5 in ArcMap dazugeladen, einen Raumbezug habe ich nicht (keine .prj Datei). Die Komprimierung ist bei mir auch CCITT Group 4.
Unterm Strich habe ich den Eindruck, dass mein Problem den meisten Usern unbekannt ist, da sie auf die Raumbezüge prinzipiell verzichten. Auch das ist eine Erkenntnis.

Der Gebrauch von Raumbezügen in ArcGIS ist anscheinend prinzipiell nicht zu empfehlen. :-(

Also steigen wir auf MapInfo um. ;-)

Gruß
Jens
Oop. keine Ahnung, wie ich dieses double posting hingezaubert habe. s.u.
Anders als GeoTiffs speichern ECWs auch das Koordinatensystem und nicht nur pixel-Größe und Offset. Vielleicht sind die eine Alternative für Dich (ab 9.2).
Die Langsamkeit bei der on-the-fly Projektion von Rastern ist aber - wie Wolfgang empfiehlt - nur dadurch zu umgehen, dass Du Dich in einem Projekt auf nur ein Koordinatensystem festlegts und Daten ggf. umprojezierst. Und ab dann bist Du alle Probleme los.
ECWs kann ich aber nicht 'für lau' erstellen.

Leider wird ArcGIS nicht erst bei 'on-the-fly' langsam, sondern schon, wenn ich einen in einen Datenrahmen mit Raumbezug Raster einlade, die keinen Raumbezug haben.
Ich schon :-). Über die FWTools/GDAL_Translate müssten kleinere Dateien auch ins ECW-Format zu wandeln sein. Na ja, etwas Wiggelei ist das schon, wenn man keine programmierte Lösung anstebt.
Von Orthogonal nach z.B. GK xyz ist auch eine Projektion, oder?
Von Orthogonal nach z.B. GK xyz ist auch eine Projektion, oder?

So habe ich es noch nicht betrachtet.

Gruß
Jens