Hallo Thomas,
vielen Dank für die Hintergrundinformationen – finde ich sehr interessant. Das Problem wurde mit dem Upgrade auf QGIS 3.16.2 gelöst. Die Variante mit der Ergänzung „,AUTHORITY["EPSG",25833]]“ und dann eingelesen in QGIS 2.18.12 hat ebenfalls funktioniert. Ich wünsche demnächst ein schönes Wochenende. Gruß Maik Von: Thomas B [mailto:[email protected]] Gesendet: Donnerstag, 14. Januar 2021 23:40 An: Schütz SC Cc: Fossgis-Talkliste Betreff: Re: [FOSSGIS-Talk] WG: QGIS erkennt Lagebezug fehlerhaft Hallo Maik, je nachdem wie die prj's beim Auftraggeber entstanden sind kann es schon sein, dass die leicht unterschiedlich sind zu denen, die in alten QGIS-Versionen erstellt wurden. Anfang 2020 wurde in QGIS das prj Format von GDAL auf ESRI WKT umgestellt: Siehe z.B. https://github.com/qgis/QGIS/pull/34252/commits/2239e54384d76bfa6aac370d485af11cebb4f37f ( Änderung: "[processing] Define Layer Projection tool should write .prj files using WKT1 ESRI format, not GDAL ") Dieselbe Problematik mit nahezu identischen prj's gab es auch schon bei 25832 und 3044 , wo QGIS 25832-Layer teilweise auch als 3044 erkannt hat. Vielleicht reicht es schon, wenn der Auftraggeber und du auf 3.16.2 gehen. Wenn ich in meinem QGIS 3.16.2 ein Shapefile mit einer prj-Datei reinlade, deren Inhalt du gepostet hast (prj auftraggeberseitig) erkennt QGIS es ganz normal als 25833. Alternativ könntest du mal testen, ob es was bringt, wenn du in dem prj noch ,AUTHORITY["EPSG",25833]] hinzufügst wie in https://www.geoportal-mv.de/portal/downloads/prj/25833.prj In etwas älteren Versionen von QGIS hätte man sich noch mit dem Erzeugen von qpj-Dateien helfen können, in denen der AUTHORITY-Teil enthalten war aber in aktuellen QGIS-Versionen wurde der qpj-Workaround abgeschafft und diese werden die nicht mehr erzeugt, bzw. beim processing->projektion definieren sogar gelöscht. weil sie in Kombination mit gdal3/proj6 Probleme machen. (Generell ist für das Interpretieren der prj-Datei in den aktuellen QGIS-Versionen auch nicht mehr QGIS selbst zuständig, sondern proj. ) Ich würde sagen schaut mal, ob das Problem beseitigt ist, wenn ihr beide QGIS 3.16.2 einsetzt. Ansonsten könntest du natürlich auch alles was als 3006 erkannt wurde per batch-projektion-definieren als 25832 festlegen. Aber ich schätze das Problem sollte sich legen wenn ihr identische aktuelle Versionen habt. Viele Grüße, Thomas Am Do., 14. Jan. 2021 um 10:08 Uhr schrieb Schütz SC <[email protected]>: Hallo an die GIS-Liste, ich habe das Lagebezugs-Problem (beschrieben in meiner Mail siehe unten) noch nicht lösen können. Inzwischen gibt es aber mehr Informationen. Nochmal das Problem zusammengefasst: - Der Auftraggeber hat die Daten mit QGIS 3.16.1 erstellt. - Sowohl bei den Layereigenschaften als auch bei den Projekteigenschaften ist bei ihm der EPSG-Code 25833 eingestellt. Er exportiert den GIS-Datensatz mit der PRJ (siehe unten). - Ich öffne den GIS-Datensatz mit meinem QGIS 2.18.12. Die Dateien werden mir nun im EPSG-Code: 3006 angezeigt. Obwohl ich in den Projekteigenschaften vorher EPSG-Code: 25833 eingestellt habe. - Beim Vergleich der PRJ-Dateien fällt mir neben einer abweichenden Reihenfolge der PARAMETER nur die Rundung hinter „UNIT“ 16 bzw. 18 Nachkommastellen auf (rot markiert). PRJ-Datei meines Auftraggebers mit QGIS 3.16.1 exportiert, erkannt als SWEREF99 TM, EPSG-Code: 3006 PROJCS["ETRS_1989_UTM_Zone_33N", GEOGCS["GCS_ETRS_1989", DATUM["D_ETRS_1989", SPHEROID["GRS_1980",6378137.0,298.257222101]], PRIMEM["Greenwich",0.0], UNIT["Degree",0.0174532925199433]], PROJECTION["Transverse_Mercator"], PARAMETER["False_Easting",500000.0], PARAMETER["False_Northing",0.0], PARAMETER["Central_Meridian",15.0], PARAMETER["Scale_Factor",0.9996], PARAMETER["Latitude_Of_Origin",0.0], UNIT["Meter",1.0]] PRJ-Datei Standard für ETRS89 UTM33N, EPSG-Code: 25833 ( <http://epsg.io/25833> http://epsg.io/25833) = PRJ-Datei, wenn ich mit QGIS 2.18.12 eine Datei mit dem EPSG-Code exportiere PROJCS["ETRS89_UTM_zone_33N", GEOGCS["GCS_ETRS_1989", DATUM["D_ETRS_1989", SPHEROID["GRS_1980",6378137,298.257222101]], PRIMEM["Greenwich",0], UNIT["Degree",0.017453292519943295]], PROJECTION["Transverse_Mercator"], PARAMETER["latitude_of_origin",0], PARAMETER["central_meridian",15], PARAMETER["scale_factor",0.9996], PARAMETER["false_easting",500000], PARAMETER["false_northing",0], UNIT["Meter",1]] Fragen: 1. Wieso gibt das QGIS 3.16.1 für den EPSG-Code 25833 eine andere PRJ-Datei aus, als mein QGIS 2.18.12 (= PRJ-Datei für diesen EPSG-Code bei <http://epsg.io/25833> http://epsg.io/25833)? 2. Welche Gründe können noch vorliegen? Ich werde mein QGIS heute auf 3.16 upgraden lassen. Ich kann mir aber nicht vorstellen, dass die alte Version für diese Irritation der Grund ist. Danke und Gruß, Maik Von: Schütz SC [mailto:[email protected]] Gesendet: Mittwoch, 6. Januar 2021 13:13 An: '[email protected]' Betreff: QGIS erkennt Lagebezug fehlerhaft Hallo an die Liste, ich habe für die Weiterbearbeitung einige GIS-Datensätze (CPG, DBF, PRJ, SHP, XML, SHX) erhalten. Ziehe ich die Shape-Dateien per Drag-and-drop in das Layerfenster von QGIS, wird die Datei im Lagebezug SWEREF99 TM33 (EPSG-Code: 3006) angezeigt. Eigentlich sollten die Dateien jedoch im Lagebezug ETRS89 UTM 33N (EPSG-Code: 25833) liegen. Ein Vergleich der mitgelieferte PRJ-Datei mit einer „Standard“-PRJ-Datei für den EPSG-Code 25833 (ausgelesen mit QGIS) ergibt neben einer unterschiedlichen Reihenfolge der PARAMETER eigentlich nur einen Unterschied: „….UNIT["Degree",0.0174532925199433]]…“ (mitgelieferte PRJ) und „…UNIT["Degree",0.017453292519943295]]…“ (PRJ von QGIS mit EPSG 25833). Sind die erhaltenen GIS-Daten nun fehlerhaft oder liegt der Fehler bei mir, dass QGIS den Lagebezug falsch erkennt? Ich verwende noch das QGIS 2.18.12 (ein Update auf eine neuere Variante ist in Arbeit). Vielen Dank. Gruß Maik -- .................................................................... FOSSGIS Veranstaltungen https://www.fossgis.de/news/fossgis-events/ FOSSGIS e.V, der Verein zur Förderung von Freier Software aus dem GIS-Bereich und Freier Geodaten! https://www.fossgis.de/ https://twitter.com/fossgis_eV ____________________________________________________________________ FOSSGIS-Talk-Liste mailing list [email protected] https://lists.fossgis.de/mailman/listinfo/fossgis-talk-liste -- .................................................................... FOSSGIS Veranstaltungen https://www.fossgis.de/news/fossgis-events/ FOSSGIS e.V, der Verein zur Förderung von Freier Software aus dem GIS-Bereich und Freier Geodaten! https://www.fossgis.de/ https://twitter.com/fossgis_eV ____________________________________________________________________ FOSSGIS-Talk-Liste mailing list [email protected] https://lists.fossgis.de/mailman/listinfo/fossgis-talk-liste
