Problem with datums - Githubissues

cgi2099 commented 4 years ago

I upgraded from 3.8.2 to 3.10.1. The Oklahoma Datums 102724, 102725, 32024, & 32025 are not getting converted correctly in 3.10.1 works great in 3.8.2, I had to downgrade back

luipir commented 4 years ago

@cgi2099 on windows I suppose! is it correct?

cgi2099 commented 4 years ago

Yes sorry, I am on Windows 10 1909

luipir commented 4 years ago

any procedure, steps to follow and/or dataset to have evidence of the conversion error?

cgi2099 commented 4 years ago

I am not sure how to troubleshoot the problem, I can provide my project file. Basically what is wrong is when I open the old project file from 3.8.2 in 3.10.1 it creates a user defined datum 100000. When I export my shapefiles or an Aerial and bring it into CAD with the world file, they are way off.

If I try to recreate the project from scratch, I still cannot get Aerial's or Shapefiles to convert to any of those datums so I can bring them into CAD

Parcels and Aerials.zip

nyalldawson commented 4 years ago

This should be fixed in 3.10.2

cgi2099 commented 4 years ago

@nyalldawson thank you so much :)!!

gioman commented 4 years ago

@cgi2099 can you test QGIS master and see if it works for you?

cgi2099 commented 4 years ago

@gioman Yes, I will install it now

cgi2099 commented 4 years ago

@gioman is there a standalone install for master, the installer keeps giving me an extraction error

gioman commented 4 years ago

@gioman is there a standalone install for master, the installer keeps giving me an extraction error

@cgi2099 https://qgis.org/downloads/weekly/?C=M;O=D

cgi2099 commented 4 years ago

@gioman thank you!

I installed the latest weekly and I am having the same problem, it generates a User Defined CRS for some reason, here it is:

Generated CRS (+proj=lcc +lat_0=35 +lon_0=-98 +lat_1=35.5666666666667 +lat_2=36.7666666666667 +x_0=600000 +y_0=0 +ellps=GRS80 +towgs84=0.9956,-1.9013,-0.5215,-0.025915,-0.009426,-0.011599,0.00062 +units=us-ft +no_defs) WKT BOUNDCRS[ SOURCECRS[ PROJCRS["unknown", BASEGEODCRS["unknown", DATUM["Unknown based on GRS80 ellipsoid", ELLIPSOID["GRS 1980",6378137,298.257222101, LENGTHUNIT["metre",1], ID["EPSG",7019]]], PRIMEM["Greenwich",0, ANGLEUNIT["degree",0.0174532925199433], ID["EPSG",8901]]], CONVERSION["unknown", METHOD["Lambert Conic Conformal (2SP)", ID["EPSG",9802]], PARAMETER["Latitude of false origin",35, ANGLEUNIT["degree",0.0174532925199433], ID["EPSG",8821]], PARAMETER["Longitude of false origin",-98, ANGLEUNIT["degree",0.0174532925199433], ID["EPSG",8822]], PARAMETER["Latitude of 1st standard parallel",35.5666666666667, ANGLEUNIT["degree",0.0174532925199433], ID["EPSG",8823]], PARAMETER["Latitude of 2nd standard parallel",36.7666666666667, ANGLEUNIT["degree",0.0174532925199433], ID["EPSG",8824]], PARAMETER["Easting at false origin",1968500, LENGTHUNIT["US survey foot",0.304800609601219], ID["EPSG",8826]], PARAMETER["Northing at false origin",0, LENGTHUNIT["US survey foot",0.304800609601219], ID["EPSG",8827]]], CS[Cartesian,2], AXIS["(E)",east, ORDER[1], LENGTHUNIT["US survey foot",0.304800609601219, ID["EPSG",9003]]], AXIS["(N)",north, ORDER[2], LENGTHUNIT["US survey foot",0.304800609601219, ID["EPSG",9003]]]]], TARGETCRS[ GEODCRS["WGS 84", DATUM["World Geodetic System 1984", ELLIPSOID["WGS 84",6378137,298.257223563, LENGTHUNIT["metre",1]]], PRIMEM["Greenwich",0, ANGLEUNIT["degree",0.0174532925199433]], CS[ellipsoidal,2], AXIS["latitude",north, ORDER[1], ANGLEUNIT["degree",0.0174532925199433]], AXIS["longitude",east, ORDER[2], ANGLEUNIT["degree",0.0174532925199433]], ID["EPSG",4326]]], ABRIDGEDTRANSFORMATION["Transformation from unknown to WGS84", METHOD["Position Vector transformation (geog2D domain)", ID["EPSG",9606]], PARAMETER["X-axis translation",0.9956, ID["EPSG",8605]], PARAMETER["Y-axis translation",-1.9013, ID["EPSG",8606]], PARAMETER["Z-axis translation",-0.5215, ID["EPSG",8607]], PARAMETER["X-axis rotation",-0.025915, ID["EPSG",8608]], PARAMETER["Y-axis rotation",-0.009426, ID["EPSG",8609]], PARAMETER["Z-axis rotation",-0.011599, ID["EPSG",8610]], PARAMETER["Scale difference",1.00000000062, ID["EPSG",8611]]]] Proj4 +proj=lcc +lat_0=35 +lon_0=-98 +lat_1=35.5666666666667 +lat_2=36.7666666666667 +x_0=600000 +y_0=0 +ellps=GRS80 +towgs84=0.9956,-1.9013,-0.5215,-0.025915,-0.009426,-0.011599,0.00062 +units=us-ft +no_defs Extent Extent not known

guenterhack commented 4 years ago

I'm not sure whether this is a related issue. I am using the official shapefiles from the Austrian statistics bureau a lot and QGIS is handling them in an inconsistent manner. Example File: https://data.statistik.gv.at/data/OGDEXT_GEM_1_STATISTIK_AUSTRIA_20200101.zip

I start a new project in QGIS. I use an xyz Tilemap of OSM as a basemap. Then I open the Statistik Austria file in 3.10.2 on Windows (10 and 7), and it is placed a tiny bit off to the northwest.

If I open the same file on 3.8 Zanzibar on Ubuntu Bionic, I get a prompt with a datum transformation from EPSG:31287 to EPSG:3857 / EPSG Transformation Code 1618, Source CRS: MGI, Destination CRS: WGS 84. I hit OK. And the borders are placed where they ought to be.

On 3.10.2 on Ubuntu Bionic I am also not prompted for CRS transformation and the result is the same as on Windows.

Frankly, I'm not sure whether this is a bug with the Statistik Austria files or in QGIS, but as the trial with Zanzibar shows there used to be a very good way to handle this, so I've thought I'd better report this behaviour.

Being still very much a n00b, I'd be grateful for tips for workarounds.

gioman commented 4 years ago

@guenterhack on 3.10.2 and master (on Windows) the linked layer CRS is not recognized exactly as EPSG:31287 so the transformation dialog does not pop up and it gets placed in a slightly wrong position. No issues on 3.14.15. Temporary solution: open the vector properties and change manually its CRS to EPSG:31287. @nyalldawson

guenterhack commented 4 years ago

@gioman Thank you very much for your swift reply and your help! Manually assigning EPSG:31287 did the job and I was able to choose the correct transformation from the dialog.

nyalldawson commented 4 years ago

@guenterhack There's no qgis issue. The PRJ file from the included data file differs from the definition of EPSG:31287.

PRJ file:

PROJCS["MGI / Austria Lambert", GEOGCS["MGI", DATUM["Militar-Geographische Institut", SPHEROID["Bessel 1841", 6377397.155, 299.1528128, AUTHORITY["EPSG","7004"]], TOWGS84[601.705, 84.263, 485.227, 4.7354, -1.3145, -5.393, -2.3887], AUTHORITY["EPSG","6312"]], PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]], UNIT["degree", 0.017453292519943295], AXIS["Geodetic longitude", EAST], AXIS["Geodetic latitude", NORTH], AUTHORITY["EPSG","4312"]], PROJECTION["Lambert_Conformal_Conic_2SP", AUTHORITY["EPSG","9802"]], PARAMETER["central_meridian", 13.333333333333336], PARAMETER["latitude_of_origin", 47.5], PARAMETER["standard_parallel_1", 48.99999999999999], PARAMETER["false_easting", 400000.0], PARAMETER["false_northing", 400000.0], PARAMETER["scale_factor", 1.0], PARAMETER["standard_parallel_2", 46.0], UNIT["m", 1.0], AXIS["Easting", EAST], AXIS["Northing", NORTH], AUTHORITY["EPSG","31287"]]

EPSG:31287 definition:

PROJCS["MGI_Austria_Lambert",GEOGCS["GCS_MGI",DATUM["D_MGI",SPHEROID["Bessel_1841",6377397.155,299.1528128]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Lambert_Conformal_Conic"],PARAMETER["False_Easting",400000.0],PARAMETER["False_Northing",400000.0],PARAMETER["Central_Meridian",13.3333333333333],PARAMETER["Standard_Parallel_1",49.0],PARAMETER["Standard_Parallel_2",46.0],PARAMETER["Latitude_Of_Origin",47.5],UNIT["Meter",1.0]]

Note the differences -- e.g. "PARAMETER["standard_parallel_1", 48.99999999999999]" vs "PARAMETER["Standard_Parallel_1",49.0]" and "UNIT["degree", 0.017453292519943295]" vs "UNIT["Degree",0.0174532925199433]]"

Using the tools from the proj library (which QGIS uses to interpret CRSes), projinfo reports:

"Warning: Coordinate system of GeographicCRS in the WKT definition is different from the one of the authority. Unsetting the identifier to avoid confusion"

So basically PROJ/QGIS has no choice but to treat the CRS as a non-standard one, and accordingly it can't determine the list of possible coordinate operations to show to users.

cgi2099 commented 4 years ago

Nyall Dawson,

@guenterhackhttps://github.com/guenterhack issues are not related to the original issue I posted. My problems are still occurring

Get Outlook for Androidhttps://aka.ms/ghei36

From: Nyall Dawson notifications@github.com Sent: Monday, January 27, 2020, 7:02 PM To: qgis/QGIS Cc: cgi2099; Mention Subject: Re: [qgis/QGIS] Problem with datums (#33789)

Closed #33789https://github.com/qgis/QGIS/issues/33789.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/qgis/QGIS/issues/33789?email_source=notifications&email_token=AOBYKU4A7LQG2A7ZKNPJ7E3Q7572ZA5CNFSM4KGUCNJ2YY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOWHNWO6Y#event-2983946107, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AOBYKU7RX27J52QKIHVNAZDQ7572ZANCNFSM4KGUCNJQ.

nyalldawson commented 4 years ago

@cgi2099 can you provide a self-contained sample project? The one you attached earlier links to a bunch of local data and https://wwwgisp.rrc.texas.gov/ (which just times out for me)

cgi2099 commented 4 years ago

@nyalldawson it will be sometime tomorrow before I can get a new data set for you. Most of my data are linked from wms services or rest services

nyalldawson commented 4 years ago

@cgi2099 how'd you go -- got a project incoming?

nyalldawson commented 4 years ago

Closed due to lack of feedback

qgis / QGIS

Problem with datums #33789