Feature request #8954
Add towgs84 parameters to some CRS for Portugal
Status: | Closed | ||
---|---|---|---|
Priority: | Normal | ||
Assignee: | - | ||
Category: | Projection Support | ||
Pull Request or Patch supplied: | No | Resolution: | |
Easy fix?: | No | Copied to github as #: | 17618 |
Description
New description:
introduction:
The CRSs with code 102160/102161/102164/102165 (originally from ESRI) are widely used in Portugal (even if now superseded by 3763).
102161 is identical to EPSG 27493
102164/102165 are the same as EPSG 20790/20791 even if the definitions is slightly different.
102160 does not seems to have an equivalent EPSG CRS.
27493/20790/20791 are shipped in QGIS with TOWGS84 parameters, this is very good because they allow to transform/reproject layers with a much needed precision.
The suggestion is to modify the 102160/102161/102164/102165 CRSs by adding the very same TOWGS84 parameters:
for 102160/1
+towgs84=-223.237,110.193,36.649,0,0,0,0
and for 102164/102165
+towgs84=-304.046,-60.576,103.64,0,0,0,0
Old Description:
The following ESRI-based CRSs are lacking DATUM transformation parameters (ToWGS84):
Lisboa_Hayford_Gauss_IGeoE
Lisboa_Hayford_Gauss_IPCC
Datum_73_Hayford_Gauss_IGeoE
Datum_73_Hayford_Gauss_IPCC
The trnasformation parameters for these CRSs can be found, for example, in ArcPAD 7 system files, as the one attached.
History
#1 Updated by Giovanni Manghi almost 11 years ago
- Status changed from Open to Feedback
- Category set to Projection Support
EPSG 27493/20790 use those parameters.
#2 Updated by Antonio Sobral Almeida almost 11 years ago
- Target version set to Version 2.0.0
- Assignee set to Antonio Sobral Almeida
Hello Giovanni
Thanks for your update.
Yes, EPSG 27493 and 20790 uses the DATUM transformation parameters that are lacking on the above mentioned CRS's.
The problem arises when you have shapefiles previously created or edited on ESRI ArcGIS, with projection files (.PRJ) that do not have these CRS’s but, instead, the ESRI-based CRS’s (Lisboa_Hayford_Gauss_IGeoE, Lisboa_Hayford_Gauss_IPCC,
Datum_73_Hayford_Gauss_IGeoE or Datum_73_Hayford_Gauss_IPCC), which are widely used in Portugal.
When QGIS reads these ESRI projection files (and, fortunately, QGIS can read ESRI projection files), QGIS do not find any DATUM transformation parameters, and simply QGIS reproject the shapefile WITHOUT ANY DATUM SHIFT. This makes the reprojected shapefile being ALLWAYS displaced, around 200-300 meters, from the right place, where it should be if there were the transformation parameters.
That simply means that GIS users working with shapefiles created with ESRI GIS, using ESRI-based CRS’s, will have to update the CRS each time a shapefile is loaded in QGIS, simply because QGIS database is not yet corrected!
We sincerely hope that QGIS make this very simple correction to its database, allowing GIS users working in Portugal to move to QGIS, specially to its top-notch 2.0 version!
#3 Updated by Giovanni Manghi almost 11 years ago
Antonio Sobral Almeida wrote:
Hello Giovanni
Thanks for your update.
Yes, EPSG 27493 and 20790 uses the DATUM transformation parameters that are lacking on the above mentioned CRS's.
The problem arises when you have shapefiles previously created or edited on ESRI ArcGIS, with projection files (.PRJ) that do not have these CRS’s but, instead, the ESRI-based CRS’s (Lisboa_Hayford_Gauss_IGeoE, Lisboa_Hayford_Gauss_IPCC,
Datum_73_Hayford_Gauss_IGeoE or Datum_73_Hayford_Gauss_IPCC), which are widely used in Portugal.
When QGIS reads these ESRI projection files (and, fortunately, QGIS can read ESRI projection files), QGIS do not find any DATUM transformation parameters, and simply QGIS reproject the shapefile WITHOUT ANY DATUM SHIFT. This makes the reprojected shapefile being ALLWAYS displaced, around 200-300 meters, from the right place, where it should be if there were the transformation parameters.
That simply means that GIS users working with shapefiles created with ESRI GIS, using ESRI-based CRS’s, will have to update the CRS each time a shapefile is loaded in QGIS, simply because QGIS database is not yet corrected!
We sincerely hope that QGIS make this very simple correction to its database, allowing GIS users working in Portugal to move to QGIS, specially to its top-notch 2.0 version!
Hi Antonio,
yes I know what you mean, "pois" I live and work in Portugal.
Just to let me understand better:
I remember that ESRI sofware was not saving vectors with towgs84 parameters in their Portuguese CRSs definitions (102160/1/4/5).
Are you saying that they do now?
If the answer is "yes" then you may want to consider that if the QGIS definitions will be updated, then all old the vectors that were been given the definitions without the towgs84 parameters will be given (on load) by QGIS an internal code (it starts from 100000), so then there will be a lot of people complaining that their shapes are given a "strange" CRS.
Meanwhile you may want to consider manually giving to your vectors the 20790/27493 and then saving copies in the same CRS.
Feel free to contact me privately: [email protected]
#4 Updated by Antonio Sobral Almeida almost 11 years ago
Hello Giovanni,
No, ESRI projection files do not have ToWGS84 parameters.
This and the fact that the above mentioned ESRI-based projection files are widely used in Portugal, makes any migration intention to QGis rather improbable, due to the reasons stated above.
#5 Updated by Giovanni Manghi almost 11 years ago
Antonio Sobral Almeida wrote:
Hello Giovanni,
No, ESRI projection files do not have ToWGS84 parameters.
This and the fact that the above mentioned ESRI-based projection files are widely used in Portugal, makes any migration intention to QGis rather improbable, due to the reasons stated above.
Hi Antonio,
I would not say that migrating to QGIS in Portugal is "rather improbable", considered the many (many) persons and entities that have happily migrated.
The issue you are raising is easily solved, I just lack the time to answer extensively right now. It is possible that things can be improved but certainly is not a blocker issue.
Write to you soon.
#6 Updated by Antonio Sobral Almeida almost 11 years ago
Hi Giovanni,
I would not say that migrating to QGIS in Portugal is "rather improbable", considered the many (many) persons and entities that have happily migrated.
That is a VERY GOOD reason for QGis developers to correct this bug!
Regards
Antonio
#7 Updated by Giovanni Manghi almost 11 years ago
- Tracker changed from Bug report to Feature request
- Target version changed from Version 2.0.0 to Future Release - High Priority
- Assignee deleted (
Antonio Sobral Almeida) - Status changed from Feedback to Open
- Subject changed from No DATUM transformation parameters in some CRSs for Portugal to Add towgs84 parameters to some CRS for Portugal
#8 Updated by Giovanni Manghi almost 11 years ago
Antonio Sobral Almeida wrote:
Hi Giovanni,
I would not say that migrating to QGIS in Portugal is "rather improbable", considered the many (many) persons and entities that have happily migrated.
That is a VERY GOOD reason for QGis developers to correct this bug!
Regards
Antonio
Dear Antonio,
the suggestion to add the towgs84 parameters to the ESRI CRSs makes sense, anyway this cannot be seen strictly as a bug.
Until the CRS will be modified you can easily workaround the problem in many ways:
+) when adding the vectors manualy change their CRS to the equivalent EPSG code (20790/20791/27493)
+) remove the .prj/qpj files of your layers and configure qgis (in the general options) to give them (on load) a specific CRS (20790/20791/27493)
+) create copies of your layers giving them the EPSG CRSs (20790/20791/27493): it is not necessary to make this operation one by one, you can batch process your layers using the processing toolbox (aka Sextante) and the tools "reproject layer" (for vectors) and "warp" (for rasters).
#9 Updated by Giovanni Manghi over 7 years ago
- Easy fix? set to No
#10 Updated by Nyall Dawson over 5 years ago
- Status changed from Open to Closed
- Description updated (diff)
With QGIS 3.8 and the release of proj 6 library, any remaining projection definition related issues now should be filed with the proj project.