Bug report #13251
Qgis can't distinguish between EPSG 32188 and EPSG 2950
Status: | Closed | ||
---|---|---|---|
Priority: | Normal | ||
Assignee: | - | ||
Category: | Projection Support | ||
Affected QGIS version: | master | Regression?: | No |
Operating System: | Easy fix?: | No | |
Pull Request or Patch supplied: | No | Resolution: | end of life |
Crashes QGIS or corrupts data: | No | Copied to github as #: | 21312 |
Description
Qgis can't distinguish between EPSG 32188 and EPSG 2950 when reading prj file (The same problem applies to MapInfo tab files).
It seems that proj4 strings are identical but .prj files are not.
To correct the situation, I have every time copy, paste and rename a file qpj from an other file to have the good projection.
History
#1 Updated by Jukka Rahkonen about 9 years ago
The way to test with GDAL is to use gdalsrsinfo:
gdalsrsinfo epsg:2950 -o proj4
'+proj=tmerc +lat_0=0 +lon_0=-73.5 +k=0.9999 +x_0=304800 +y_0=0 +ellps=GRS80 +to
wgs84=0,0,0,0,0,0,0 +units=m +no_defs '
gdalsrsinfo epsg:32188 -o proj4
'+proj=tmerc +lat_0=0 +lon_0=-73.5 +k=0.9999 +x_0=304800 +y_0=0 +ellps=GRS80 +to
wgs84=0,0,0,0,0,0,0 +units=m +no_defs '
Prj and WKT outputs are different in GEOGCS NAD83 vs. GEOGCS NAD83 (CSRS). You can change the projection code also from layer-properties, but does the change have any effect it the nadgrid file to use is not defined and also available to GDAL and QGIS?
#2 Updated by Marc-André Saia about 9 years ago
Thanks for the information.
Yes, indeed, it is possible to manually correct the files projections by one or other of manipulation as possible. It's like fix something with tape that is not working as it should.
However, it would be perfect if Qgis could open the files with good projection automatically without anyone having to worry about it.
#3 Updated by Jukka Rahkonen about 9 years ago
I do not know these projections at all, but I wonder it your fix by fiddling with the qpj files does really have any effect. The projections are basically the same. The only difference, if I understand it right, is that the one named NAD83 (CSRS) is newer and does not have local distortions which are corrected in the older projection with a nadgrids file. My GDAL 2.0 from gisinternals does not have nadgrid files defined for either of the projections which makes them to be just the same for GDAL.
I tested that ogrinfo finds different projections from your sample files. Then I made a test with gdaltransform:
gdaltransform -s_srs epsg:2950 -t_srs epsg:4326
313658.844100 5026941.160835
-73.3868787673789 45.3823557428898 0
gdaltransform -s_srs epsg:32188 -t_srs epsg:4326
313658.844100, 5026941.160835
-73.3868787673789 45.3823557428898 0
Same coordinates for both 2950 and 32188 which means that if you do not have correct gridshift files and adjusted Proj4 definitions for the projections you can as well use 2950 or 32188 throughout, or a mixture of both, because the end result will still be the same.
Do you have the nadgrid files "tnhpgn.las" for epsg:32188 as documented in http://epsg.io/32188-1733 ? It seems that 2950 does not need gridshift files http://epsg.io/2950.
As I said, I have no experience on these projections and I may be all wrong.
#4 Updated by Marc-André Saia about 9 years ago
- File Nad83_vs_Nad83_scrs.pdf added
Hi,
Although the MTM and MTM Nad83 Nad83 (CSIS) are equivalent for most purposes, they are not identical. The differences affect such digitized cadastral data with high accuracy. The following site provides coordinate offsets between the two systems. See page 4.
https://www.mern.gouv.qc.ca/publications/territoire/outils/scrs.pdf
I don't found "tnhpgn.las" in Gqis software files.
I found "tnhpgn.las" in other sofwares files but they are not readable like a textfile.
#5 Updated by Jukka Rahkonen about 9 years ago
I believe there are two issues. First one it that after reading data in EPSG:2950 and EPSG:32188 they do not distinguish. Another issue is that if you convert data from for example EPSG:4326 into 2950 or 32188 the result will be identical because QGIS/GDAL/Proj4 does not come with the "tnhpgn.las" file or something equivalent. I do not know if the format of that .las file is correct for those.
I do not know how to make custom CRS to utilize nadgrids with QGIS. Reading this ticket and the related ones may give some information #2913. I think that myself, if the accuracy counts, I would select either 2950 or 32188 and convert all my data into that with ogr2ogr. It understands nadgrids in Proj strings.
#6 Updated by Giovanni Manghi about 9 years ago
- Target version deleted (
Version 2.12) - Affected QGIS version changed from 2.10.1 to master
- Assignee deleted (
Giovanni Manghi)
Jukka Rahkonen wrote:
I do not know how to make custom CRS to utilize nadgrids with QGIS. Reading this ticket and the related ones may give some information #2913. I think that myself, if the accuracy counts, I would select either 2950 or 32188 and convert all my data into that with ogr2ogr. It understands nadgrids in Proj strings.
You can create custom CRS in QGIS (that may include nadgrids definition), there is a menu entry in the "settings" menu. This is the easiest way if you just need to get high precision while reprojecting on the fly.
If you have a bunch of data in one CRS and you need to create copies in another CRS and there a nadgrid from that specific transformation, then the easiest way if to add this specific case to this plugin
https://github.com/NaturalGIS/ntv2_transformations
because then you can do batch transformation of many layers in one go.
#7 Updated by Marc-André Saia about 9 years ago
Hi,
Thank you for your solutions.
For now , since the files arrive one by one, the simplest method of correction remains to copy and paste a good QPJ then rename it as the new file received.
The geometry need not be reprojected because it is already in MTM Nad 83.
#8 Updated by Giovanni Manghi over 7 years ago
- Regression? set to No
- Easy fix? set to No
#9 Updated by Giovanni Manghi over 5 years ago
- Resolution set to end of life
- Status changed from Open to Closed
End of life notice: QGIS 2.18 LTR
Source:
http://blog.qgis.org/2019/03/09/end-of-life-notice-qgis-2-18-ltr/