[FOSSGIS-Talk] WG: QGIS erkennt Lagebezug fehlerhaft

Thomas B rdbath.regiodata at gmail.com
Do Jan 14 23:40:00 CET 2021


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 <maik.schuetz at sc-ing.de
>:

> 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:maik.schuetz at sc-ing.de]
> Gesendet: Mittwoch, 6. Januar 2021 13:13
> An: 'fossgis-talk-liste at fossgis.de'
> 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
> FOSSGIS-Talk-Liste at fossgis.de
> https://lists.fossgis.de/mailman/listinfo/fossgis-talk-liste
>


Mehr Informationen über die Mailingliste FOSSGIS-Talk-Liste