Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Projection not recognised from Mapinfo converstion #34471

Closed
untoldstory2 opened this issue Feb 14, 2020 · 8 comments
Closed

Projection not recognised from Mapinfo converstion #34471

untoldstory2 opened this issue Feb 14, 2020 · 8 comments
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Feedback Waiting on the submitter for answers Projections/Transformations Related to coordinate reference systems or coordinate transformation

Comments

@untoldstory2
Copy link

When I try to open a shape file that has been translated from Mapinfo discover the projection isn't recognised. The grid is a local grid. Output.zip is the attached file that i'm trying to open

Output.zip

I'm currently using Qgis version 3.10.2

Additional context

Here are some control points:

Mine X | Mine Y| MGA 94(50) X| MGA 94(50) Y
2453.122|3210.002|563053.406|7431461.771
-1735.225|-853.24|557798.872|7428929.256
5663.648|7386.58|567416.171|7434410.368
12607.859|-1438.839|571218.306|7423848.605
8502.84|2620.24|568605.287|7428993.832
-2500.032|3457.767|558433.331|7433259.449

Here is the Mapinfo .prj file entry:

"Mine to MGA", 3008, 33,7, 117, 0, 0.9996, 500000, 10000000 , 7, 0.949288, -0.315744, 1814394.28, 0.315737, 0.94926, -7228957.16, -100000, -100000, 100000, 100000

@untoldstory2 untoldstory2 added the Bug Either a bug report, or a bug fix. Let's hope for the latter! label Feb 14, 2020
@Asratum
Copy link

Asratum commented Feb 14, 2020

Possibly related: a custom Mercator projection is recognized in 3.10.2 as invalid, but in 3.4.9 is recognized correctly as custom CRS. Even if 3.10.2 calls it invalid, it projects it correctly.
.shp below loads correctly in 3.4.9 and has "invalid projection" in 3.10.2, when I choose Save as... after importing.
Merc_25S_25W.zip

@gioman gioman added the Projections/Transformations Related to coordinate reference systems or coordinate transformation label Feb 14, 2020
@nyalldawson
Copy link
Collaborator

What's the issue here? The projection isn't recognised because it isn't a standard projection.

@nyalldawson nyalldawson added the Feedback Waiting on the submitter for answers label Feb 16, 2020
@Asratum
Copy link

Asratum commented Feb 17, 2020

The issue is that in earlier versions it would be recognized as a user defined CRS and given a 10000n number, and in 3.10.2 it just says it's invalid, not assigning it a CRS ID. Applies to both files uploaded so far.

@nyalldawson
Copy link
Collaborator

Can you test with a nightly 3.10.3 release or master? I don't see the same behavior here.

@Asratum
Copy link

Asratum commented Feb 18, 2020

I tested this with a 3.11.06 release from the weekly downloads (not sure if that's correct?). The problem persists; in addition it seems that a .prj string is not properly recognized - the following .prj files are nearly identical, yet one of the shapefiles gets an unknown CRS.
3.4.9 recognizes both files correctly as UTM32S.
32S_test_lines.zip

@untoldstory2
Copy link
Author

I've developed a script to "brute force" the projection into PROJ4 coordinates -
https://gis.stackexchange.com/questions/352168/define-custom-crs-in-wkt-from-point-and-angle/352197?noredirect=1#comment576972_352197. It's not the solution but if you desperately need the local projection in QGIS from Mapinfo - Save about 4 - 10 points in Mapinfo with both coordinate systems and ti'll find the PROJ4 code.

rouault added a commit to rouault/QGIS that referenced this issue May 27, 2020
The current approach was based on a srsid, that that might be unset for custom
CRS. So store a full QgsCoordinateReferenceSystem object internally and use
that for exchanges with QgsProjectionSelectionWidget

Consequence: we need to deprecate the "long crs()" method, and replace it
by a "QgsCoordinateReferenceSystem crsObject()" one. I'm not particularly
happy with the name but the existing one was not very well named...

Mark also the QgsVectorLayerSaveAsDialog( long srsid, ... ) constructor as
deprecated

Fixes the use case of qgis#34471 (comment)
@rouault
Copy link
Contributor

rouault commented May 27, 2020

Looking at 32S_test_lines.zip from #34471 (comment) , the UTM32S definition that is not identified is the one from UTM32S.prj. When looking at the content of it, one see that the reverse flattening of WGS84 in that file is 298.25722293 whereas the correct value is 298.257223563. That's a relative difference of 2e-9. PROJ uses currently a threshold of 1e-10 relative error to determine if 2 CRS are equivalent, so the non identification is logical.

nyalldawson pushed a commit that referenced this issue May 27, 2020
The current approach was based on a srsid, that that might be unset for custom
CRS. So store a full QgsCoordinateReferenceSystem object internally and use
that for exchanges with QgsProjectionSelectionWidget

Consequence: we need to deprecate the "long crs()" method, and replace it
by a "QgsCoordinateReferenceSystem crsObject()" one. I'm not particularly
happy with the name but the existing one was not very well named...

Mark also the QgsVectorLayerSaveAsDialog( long srsid, ... ) constructor as
deprecated

Fixes the use case of #34471 (comment)
nyalldawson pushed a commit to nyalldawson/QGIS that referenced this issue May 27, 2020
The current approach was based on a srsid, that that might be unset for custom
CRS. So store a full QgsCoordinateReferenceSystem object internally and use
that for exchanges with QgsProjectionSelectionWidget

Consequence: we need to deprecate the "long crs()" method, and replace it
by a "QgsCoordinateReferenceSystem crsObject()" one. I'm not particularly
happy with the name but the existing one was not very well named...

Mark also the QgsVectorLayerSaveAsDialog( long srsid, ... ) constructor as
deprecated

Fixes the use case of qgis#34471 (comment)

(cherry picked from commit 535c253)
@gioman
Copy link
Contributor

gioman commented May 28, 2020

Looking at 32S_test_lines.zip from #34471 (comment) , the UTM32S definition that is not identified is the one from UTM32S.prj. When looking at the content of it, one see that the reverse flattening of WGS84 in that file is 298.25722293 whereas the correct value is 298.257223563. That's a relative difference of 2e-9. PROJ uses currently a threshold of 1e-10 relative error to determine if 2 CRS are equivalent, so the non identification is logical.

case closed then.

@gioman gioman closed this as completed May 28, 2020
nyalldawson pushed a commit that referenced this issue Jun 19, 2020
The current approach was based on a srsid, that that might be unset for custom
CRS. So store a full QgsCoordinateReferenceSystem object internally and use
that for exchanges with QgsProjectionSelectionWidget

Consequence: we need to deprecate the "long crs()" method, and replace it
by a "QgsCoordinateReferenceSystem crsObject()" one. I'm not particularly
happy with the name but the existing one was not very well named...

Mark also the QgsVectorLayerSaveAsDialog( long srsid, ... ) constructor as
deprecated

Fixes the use case of #34471 (comment)

(cherry picked from commit 535c253)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! Feedback Waiting on the submitter for answers Projections/Transformations Related to coordinate reference systems or coordinate transformation
Projects
None yet
Development

No branches or pull requests

5 participants