Bug report #10990
Inconsistency in the re-projection between ED50 (epsg23031) and ETrS89 (25831)
| Status: | Closed | ||
|---|---|---|---|
| Priority: | Normal | ||
| Assignee: | - | ||
| Category: | Projection Support | ||
| Affected QGIS version: | 2.0.1 | Regression?: | No |
| Operating System: | Easy fix?: | No | |
| Pull Request or Patch supplied: | No | Resolution: | invalid |
| Crashes QGIS or corrupts data: | No | Copied to github as #: | 19333 |
Description
I've found an inconsistency in the re-projection between
ED50 (epsg23031) and ETRS89 (25831) both in UTM31N
ed50.jpeg
https://dl.dropboxusercontent.com/u/3180464/ed50.jpeg
shows a project, image and vector layer all in epsg23031
erts89.jpeg
https://dl.dropboxusercontent.com/u/3180464/etrs89.jpeg
shows a project and image in epsg25831 and the vector layer in epsg23031
In both cases, reprojection on the fly is activated.
A reprojected version (to epsg25831) of the vector layer is
exactly coincident with the display of the vector layer in etrs89.jpeg
images correspond to WMS layer ortoi5m in
http://geoserveis.icc.cat/icc_mapesbase/wms/service?
where the appropriate CRS is automatically selected.
Vector layer:
https://dl.dropboxusercontent.com/u/3180464/ALGCPTetraED50zv2.zip
Any explanation to this behavior?
Thanks
History
#1
Updated by Giovanni Manghi over 10 years ago
- Affected QGIS version changed from 2.4.0 to 2.0.1
- Status changed from Open to Feedback
- Priority changed from High to Normal
I'm not expert of Span CRSs, but isn't expected a small error when reprojecting between those two CRSs (unless using more precise methods, like datum tranformation grids)?
#2
Updated by alobo - over 10 years ago
I would not qualify the error as "small" in these days
of uav imagery and sub-metric gps coordinates, but the
fact is that using
http://www.icc.cat/cat/Home-ICC/Geodesia/Recursos/Calculadora#
I get a systematic difference of 2m vs. the conversion
made by QGIS. I agree this is probably not a bug but
a limitation of the method used by Qgis, but let's wait
to see if any expert can enlighten us further.
In case we conclude this is not a bug but a limitation,
somewhere in the manual (also in the panel, besides the "on the fly"
notice?) the user should be warned of this possible error when
converting among datums.
#3
Updated by Da Silva over 10 years ago
There is a pull request https://github.com/qgis/QGIS/pull/1506 waiting to be merged that can help solve your problem. It allows to recall the datum transformation dialog to change the a layer's coordinate transform. If you choose tfm 1633 you get a result similar to ed50.jpg.
The problem is that in actual state we don´t have information about area_of_use from srs.db so a lot of tfm's are not valid.
#4
Updated by Giovanni Manghi over 10 years ago
Da Silva wrote:
There is a pull request https://github.com/qgis/QGIS/pull/1506 waiting to be merged that can help solve your problem. It allows to recall the datum transformation dialog to change the a layer's coordinate transform. If you choose tfm 1633 you get a result similar to ed50.jpg.
The problem is that in actual state we don´t have information about area_of_use from srs.db so a lot of tfm's are not valid.
more in general:
datum transformations are not error free. In QGIS precision depends on how CRSs are defined in Proj, so if there is a (relatively) small problem such in this case it is likely that depends on how CRSs are defined there. An example I know better: in Portugal the transformation from Datum Lisboa and ETRS89 can lead to huge errors if using Datum Lisboa as defined by ESRI. If using Datum Lisboa as defined in proj the error is just a few tens of cm. But if using NTV2 grids (that can be used in QGIS) then the precision is measurable in mm. Official services like
http://www.icc.cat/cat/Home-ICC/Geodesia/Recursos/Calculadora
are likely to use the most precise way to do Datum transform, NTV2 grids, so the difference should be explained.
#5
Updated by Giovanni Manghi about 10 years ago
- Resolution set to invalid
- Status changed from Feedback to Closed
closing for lack of feedback, please reopen if necessary.