Closed qgib closed 5 years ago
Author Name: Jürgen Fischer (@jef-n)
Is that a custom crs or did you modify srs.db?
Author Name: Giovanni Manghi (@gioman)
Jürgen Fischer wrote:
Is that a custom crs or did you modify srs.db?
it is a custom crs, I tested and qgis does indeed overwrite the crs string.
Author Name: Frank Sokolic (Frank Sokolic)
I've been able to solve this bug on my system (Ubuntu 13.04, QGIS master): If I open /usr/share/qgis/reources/srs.db using spatialite and then edit the relevant rows in the tbl_srs table to remove +axis=wsu then Bug #17252 goes away. Is this a possible solution to this bug?
Author Name: Jürgen Fischer (@jef-n)
Giovanni Manghi wrote:
it is a custom crs, I tested and qgis does indeed overwrite the crs string.
What exactly happens? I suppose it's not assigning the user CRS to the layer, when loading the shape file and assigns the "standard" crs instead. But it doesn't modify (overwrite) the existing user CRS and manually assigning the user crs works as expected. Right?
Author Name: Leyan Ouyang (Leyan Ouyang)
It is due to the changes I made in the custom CRS handling. Previously, it was all manual, then I changed it to make use of QgsCoordinateReferenceSystem. When creating a custom CRS, a QgsCoordinateReferenceSystem is created using createFromProj4, then is saved. The second string is the result of toProj4 on this CRS. To clarify, the custom CRS is not saved as expected, the modified version is saved instead. Manually changing would not help, but modifying the database can allow to replace with the correct value.
However, createFromProj4 is trying too hard to match to an existing CRS: it will match with an existing CRS, even if this CRS has additional parameters. It is even documented "here":https://github.com/qgis/Quantum-GIS/blob/master/src/core/qgscoordinatereferencesystem.cpp#L600
I think the clean way would be to make smaller utility class to manage CRS (check validity, convert between representations), separated from QgsCoordinateReferenceSystem which tries very hard to fit to existing CRS. However, I was very close to the feature freeze when I submitted this, and couldn't make the changes. I was not very happy with this matching to existing CRS, as it can rearrange some parameters, but I did not think it would make some custom CRS unusable ...
Author Name: Giovanni Manghi (@gioman)
Jürgen Fischer wrote:
What exactly happens?
you create the custom CRS with
+proj=tmerc +lat_0=0 +lon_0=21 +k=1 +x_0=0 +y_0=0 +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
then click ok, and when you go edit the same CRS it turns it is
+proj=tmerc +lat_0=0 +lon_0=21 +k=1 +x_0=0 +y_0=0 +axis=wsu +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
Author Name: Frank Sokolic (Frank Sokolic)
Yes, on my system (Ubuntu 13.04, QGIS Master) if I create a custom CRS, e.g:
+proj=tmerc +lat_0=0 +lon_0=31 +k=1 +x_0=0 +y_0=0 +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
and then click ok, and then edit the same CRS then +axis=wsu has been added:
+proj=tmerc +lat_0=0 +lon_0=31 +k=1 +x_0=0 +y_0=0 +axis=wsu +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
Author Name: Frank Sokolic (Frank Sokolic)
For me, the issue is that the proj4 definitions in SRS.db for these South African CRSs are not correct and shouldn't contain the +axis=wsu parameter as GIS users in South Africa (and Namibia and Lesotho) don't use south-facing coordinates. If the +axis=wsu parameter was removed from the relevant entries in SRS.db then southern African GIS users wouldn't have to use custom CRSs at all.
Author Name: Hien TRAN-QUANG (Hien TRAN-QUANG)
From what Leyan said, it seems that the error occurs when the custom CRS has too few parameters, compared to the found ones in the srs.db.
Shouldn't it only match the exact same number of parameters (apart maybe from +datum?) and not try to find a corresponding one, as it is contradictory to the purpose of a custom crs ?
Author Name: Hien TRAN-QUANG (Hien TRAN-QUANG)
I did a pull request [[https://github.com/qgis/Quantum-GIS/pull/838]] Now createFromProj4 only checks for same parameters (except +datum)
Author Name: René-Luc ReLuc (@rldhont)
Author Name: Gavin Fleming (@gubuntu)
I found a simpler solution though it wasn't easily apparent. It you specify +axis=enu explicitly (the normal north-oriented axes) in the Custom CRS dialog when creating a new custom CRS then QGIS accepts the definition you provide. It does not show the +axis=enu switch in the resulting definition but does implement it and does not override it with +axis=wsu. This does seem to be a good approach, i.e. to force explicit definition of axis orientation, but does need to be documented somewhere. I am accustomed to not specifying axis orientation but am quite happy to specify it explicitly from now on. If that is the case then +axis=enu should perhaps remain in the CRS definition.
If I edit an existing custom CRS that I had tried to change to north facing when I created it, but where +axis=wsu was forcefully inserted by the bug, the change becomes effective and can be seen in Project Properties but does not show in the Custom CRS dialog.
e.g. to make a north-facing version of EPSG:22287 I edited the CRS I had created (follow the +axis flag in these definitions): +proj=tmerc +lat_0=0 +lon_0=27 +k=1 +x_0=0 +y_0=0 +axis=wsu +a=6378249.145 +b=6356514.966398753 +towgs84=-136,-108,-292,0,0,0,0 +units=m +no_defs.
I changed this to: +proj=tmerc +lat_0=0 +lon_0=27 +k=1 +x_0=0 +y_0=0 +axis=enu +a=6378249.145 +b=6356514.966398753 +towgs84=-136,-108,-292,0,0,0,0 +units=m +no_defs.
In Project properties it now appears as the following and most importantly, it behaves correctly: +proj=tmerc +lat_0=0 +lon_0=27 +k=1 +x_0=0 +y_0=0 +a=6378249.145 +b=6356514.966398753 +towgs84=-136,-108,-292,0,0,0,0 +units=m +no_defs
But if I open Custom CRS again it still shows: +proj=tmerc +lat_0=0 +lon_0=27 +k=1 +x_0=0 +y_0=0 +axis=wsu +a=6378249.145 +b=6356514.966398753 +towgs84=-136,-108,-292,0,0,0,0 +units=m +no_defs
Author Name: craigleat - (craigleat -)
Frank Sokolic wrote:
For me, the issue is that the proj4 definitions in SRS.db for these South African CRSs are not correct and shouldn't contain the +axis=wsu parameter as GIS users in South Africa (and Namibia and Lesotho) don't use south-facing coordinates. If the +axis=wsu parameter was removed from the relevant entries in SRS.db then southern African GIS users wouldn't have to use custom CRSs at all.
I believe the definitions are correct and it would be improper to alter a standard definition to suit a historical non-standard practice. GIS users have traditionally worked with negative values but this situation only arose because existing software was unable to implement south facing coordinates. Civil Engineers on the other hand have been correctly using TMSO for years via local software products. If you wish to use TMNO this should be viable by creating a custom CRS.
Author Name: Tim Sutton (Tim Sutton)
There are a complex of issues, here I try to outline a roadmap to address them:
/usr/share/proj/epsg lists Cape data with the with the easting/northing order switched. In other words in all of theses +axis=wsu
needs to become +axis=swu
. There is alread a ticket (filed in proj4 for this http://trac.osgeo.org/proj/ticket/18).
1. Cape / Lo15
<22275> +proj=tmerc +lat_0=0 +lon_0=15 +k=1 +x_0=0 +y_0=0 +axis=wsu +a=6378249.145 +b=6356514.966398753 +towgs84=-136,-108,-292,0,0,0,0 +units=m +no_defs <>
1. Cape / Lo17
<22277> +proj=tmerc +lat_0=0 +lon_0=17 +k=1 +x_0=0 +y_0=0 +axis=wsu +a=6378249.145 +b=6356514.966398753 +towgs84=-136,-108,-292,0,0,0,0 +units=m +no_defs <>
1. Cape / Lo19
<22279> +proj=tmerc +lat_0=0 +lon_0=19 +k=1 +x_0=0 +y_0=0 +axis=wsu +a=6378249.145 +b=6356514.966398753 +towgs84=-136,-108,-292,0,0,0,0 +units=m +no_defs <>
1. Cape / Lo21
<22281> +proj=tmerc +lat_0=0 +lon_0=21 +k=1 +x_0=0 +y_0=0 +axis=wsu +a=6378249.145 +b=6356514.966398753 +towgs84=-136,-108,-292,0,0,0,0 +units=m +no_defs <>
1. Cape / Lo23
<22283> +proj=tmerc +lat_0=0 +lon_0=23 +k=1 +x_0=0 +y_0=0 +axis=wsu +a=6378249.145 +b=6356514.966398753 +towgs84=-136,-108,-292,0,0,0,0 +units=m +no_defs <>
1. Cape / Lo25
<22285> +proj=tmerc +lat_0=0 +lon_0=25 +k=1 +x_0=0 +y_0=0 +axis=wsu +a=6378249.145 +b=6356514.966398753 +towgs84=-136,-108,-292,0,0,0,0 +units=m +no_defs <>
1. Cape / Lo27
<22287> +proj=tmerc +lat_0=0 +lon_0=27 +k=1 +x_0=0 +y_0=0 +axis=wsu +a=6378249.145 +b=6356514.966398753 +towgs84=-136,-108,-292,0,0,0,0 +units=m +no_defs <>
1. Cape / Lo29
<22289> +proj=tmerc +lat_0=0 +lon_0=29 +k=1 +x_0=0 +y_0=0 +axis=wsu +a=6378249.145 +b=6356514.966398753 +towgs84=-136,-108,-292,0,0,0,0 +units=m +no_defs <>
1. Cape / Lo31
<22291> +proj=tmerc +lat_0=0 +lon_0=31 +k=1 +x_0=0 +y_0=0 +axis=wsu +a=6378249.145 +b=6356514.966398753 +towgs84=-136,-108,-292,0,0,0,0 +units=m +no_defs <>
1. Cape / Lo33
<22293> +proj=tmerc +lat_0=0 +lon_0=33 +k=1 +x_0=0 +y_0=0 +axis=wsu +a=6378249.145 +b=6356514.966398753 +towgs84=-136,-108,-292,0,0,0,0 +units=m +no_defs <>
1. Hartebeesthoek94 / Lo15
<2046> +proj=tmerc +lat_0=0 +lon_0=15 +k=1 +x_0=0 +y_0=0 +axis=wsu +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs <>
1. Hartebeesthoek94 / Lo17
<2047> +proj=tmerc +lat_0=0 +lon_0=17 +k=1 +x_0=0 +y_0=0 +axis=wsu +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs <>
1. Hartebeesthoek94 / Lo19
<2048> +proj=tmerc +lat_0=0 +lon_0=19 +k=1 +x_0=0 +y_0=0 +axis=wsu +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs <>
1. Hartebeesthoek94 / Lo21
<2049> +proj=tmerc +lat_0=0 +lon_0=21 +k=1 +x_0=0 +y_0=0 +axis=wsu +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs <>
1. Hartebeesthoek94 / Lo23
<2050> +proj=tmerc +lat_0=0 +lon_0=23 +k=1 +x_0=0 +y_0=0 +axis=wsu +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs <>
1. Hartebeesthoek94 / Lo25
<2051> +proj=tmerc +lat_0=0 +lon_0=25 +k=1 +x_0=0 +y_0=0 +axis=wsu +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs <>
1. Hartebeesthoek94 / Lo27
<2052> +proj=tmerc +lat_0=0 +lon_0=27 +k=1 +x_0=0 +y_0=0 +axis=wsu +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs <>
1. Hartebeesthoek94 / Lo29
<2053> +proj=tmerc +lat_0=0 +lon_0=29 +k=1 +x_0=0 +y_0=0 +axis=wsu +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs <>
1. Hartebeesthoek94 / Lo31
<2054> +proj=tmerc +lat_0=0 +lon_0=31 +k=1 +x_0=0 +y_0=0 +axis=wsu +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs <>
1. Hartebeesthoek94 / Lo33
<2055> +proj=tmerc +lat_0=0 +lon_0=33 +k=1 +x_0=0 +y_0=0 +axis=wsu +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs <>
Until such time as an upstream fix happens, it would be good to fix these locally in the srs.db
There is currently not a ticket with EPSG to add these so for the interim it is suggested that they are added to the QGIS srsr.db with auth_name 'ZANGI' (South Africa National Geospatial Information [department]).
In these cases all of the above definitions would be duplicated but with +axis=enu (which is the default but we should set it explictly). We suggest the following schema for the auth_id we would use for 'Lo projections this: SACRSNO
We should have a test dataset which can be used to verify that the CRS is properly detected. We propose two test datasets:
In the longer term, we should have EPSG definitions defined for the above SACRS and TM_CAPE crs's and then remove the locally added definitions so that they are automatically added from EPSG.
Author Name: craigleat - (craigleat -)
Tim,
For your proposed schema did you mean the following, as you appear to have them switched around?
Lo Hartebeeshoek94 -> SACRSNO
Author Name: Gavin Fleming (@gubuntu)
@craigleat: no, Tim is correct - we are proposing a new set of north-facing (or NO=north-oriented) definitions in addition to the existing set of south-facing (SO) definitions, such that each existing 'LO' code has a north-facing equivalent.
I attach here some test files to use. Each has the same triangle polygon in longlat (test_4326), SACRS_23 or "lo23/Hartebeesthoek"(test_2050) and SACRS_NO_23 or "lo23/Hartebeesthoek north-facing" (test_SACRS_NO_23).
These can be tested manually by loading with the delimited text loader and specifying the appropriate CRS and enabling on the fly CRS transformation. When all is working, all three polygons should coincide in the middle of South Africa.
When the bug that this ticket refers to is fixed and a new definition has been created, then test_SACRS_NO_23 should overlay 4326.
When the +axis flag in the existing definition has been changed from +axis=wsu to +axis=swu then test_SACRS_NO_23 should overlay 4326.
Author Name: Gavin Fleming (@gubuntu)
Author Name: Gavin Fleming (@gubuntu)
Let's hang five on Tim's "Incorrect project definitions" above. Technically they are correct according to the EPSG but the jury is out on which one of swu or wsu is the predominant axis order in practice in South Africa. Perhaps we should leave them as is and tell users they must conform with EPSG convention, until we can confirm otherwise. If we confirm in due course that swu is the local convention, then we should make the change.
Regarding the new north-facing SACRS ('ZANGI') CRS definitions, those are fine as Tim has described.
Author Name: Gavin Fleming (@gubuntu)
I mistakenly downgraded this earlier - the original bug this Issue describes is still a blocker until resolved.
Author Name: Tim Sutton (Tim Sutton)
Further to this, I have will insert the following CRS definitions into the srs.db. Due to the last minute nature of this commit, any corrections to these will need to be made in future release of QGIS 2.x
INSERT INTO "tbl_ellipsoid" VALUES('cape','Clarke 1880 mod.','a=6378249.145','b=6356514.966398753'); INSERT INTO "tbl_srs" VALUES(26814,'South African CRS : CAPE_NO_15','tmerc','CAPE','+proj=tmerc +lat_0=0 +lon_0=15 +k=1 +x_0=0 +y_0=0 +axis=enu +a=6378249.145 +b=6356514.966398753 +towgs84=-136,-108,-292,0,0,0,0 +units=m +no_defs',320002135,'ZANGI','ZANGI:CPNO15',0,0,1); INSERT INTO "tbl_srs" VALUES(26815,'South African CRS : CAPE_NO_17','tmerc','CAPE','+proj=tmerc +lat_0=0 +lon_0=17 +k=1 +x_0=0 +y_0=0 +axis=enu +a=6378249.145 +b=6356514.966398753 +towgs84=-136,-108,-292,0,0,0,0 +units=m +no_defs',320002136,'ZANGI','ZANGI:CPNO17',0,0,1); INSERT INTO "tbl_srs" VALUES(26816,'South African CRS : CAPE_NO_19','tmerc','CAPE','+proj=tmerc +lat_0=0 +lon_0=19 +k=1 +x_0=0 +y_0=0 +axis=enu +a=6378249.145 +b=6356514.966398753 +towgs84=-136,-108,-292,0,0,0,0 +units=m +no_defs',320002137,'ZANGI','ZANGI:CPNO19',0,0,1); INSERT INTO "tbl_srs" VALUES(26817,'South African CRS : CAPE_NO_21','tmerc','CAPE','+proj=tmerc +lat_0=0 +lon_0=21 +k=1 +x_0=0 +y_0=0 +axis=enu +a=6378249.145 +b=6356514.966398753 +towgs84=-136,-108,-292,0,0,0,0 +units=m +no_defs',320002138,'ZANGI','ZANGI:CPNO21',0,0,1); INSERT INTO "tbl_srs" VALUES(26818,'South African CRS : CAPE_NO_23','tmerc','CAPE','+proj=tmerc +lat_0=0 +lon_0=23 +k=1 +x_0=0 +y_0=0 +axis=enu +a=6378249.145 +b=6356514.966398753 +towgs84=-136,-108,-292,0,0,0,0 +units=m +no_defs',320002139,'ZANGI','ZANGI:CPNO23',0,0,1); INSERT INTO "tbl_srs" VALUES(26819,'South African CRS : CAPE_NO_25','tmerc','CAPE','+proj=tmerc +lat_0=0 +lon_0=25 +k=1 +x_0=0 +y_0=0 +axis=enu +a=6378249.145 +b=6356514.966398753 +towgs84=-136,-108,-292,0,0,0,0 +units=m +no_defs',320002140,'ZANGI','ZANGI:CPNO25',0,0,1); INSERT INTO "tbl_srs" VALUES(26820,'South African CRS : CAPE_NO_27','tmerc','CAPE','+proj=tmerc +lat_0=0 +lon_0=27 +k=1 +x_0=0 +y_0=0 +axis=enu +a=6378249.145 +b=6356514.966398753 +towgs84=-136,-108,-292,0,0,0,0 +units=m +no_defs',320002141,'ZANGI','ZANGI:CPNO27',0,0,1); INSERT INTO "tbl_srs" VALUES(26821,'South African CRS : CAPE_NO_29','tmerc','CAPE','+proj=tmerc +lat_0=0 +lon_0=29 +k=1 +x_0=0 +y_0=0 +axis=enu +a=6378249.145 +b=6356514.966398753 +towgs84=-136,-108,-292,0,0,0,0 +units=m +no_defs',320002142,'ZANGI','ZANGI:CPNO29',0,0,1); INSERT INTO "tbl_srs" VALUES(26822,'South African CRS : CAPE_NO_31','tmerc','CAPE','+proj=tmerc +lat_0=0 +lon_0=31 +k=1 +x_0=0 +y_0=0 +axis=enu +a=6378249.145 +b=6356514.966398753 +towgs84=-136,-108,-292,0,0,0,0 +units=m +no_defs',320002143,'ZANGI','ZANGI:CPNO31',0,0,1); INSERT INTO "tbl_srs" VALUES(26823,'South African CRS : CAPE_NO_33','tmerc','CAPE','+proj=tmerc +lat_0=0 +lon_0=33 +k=1 +x_0=0 +y_0=0 +axis=enu +a=6378249.145 +b=6356514.966398753 +towgs84=-136,-108,-292,0,0,0,0 +units=m +no_defs',320002144,'ZANGI','ZANGI:CPNO33',0,0,1); INSERT INTO "tbl_srs" VALUES(26824,'South African CRS : HBK_NO_15','tmerc','WGS84','+proj=tmerc +lat_0=0 +lon_0=15 +k=1 +x_0=0 +y_0=0 +axis=enu +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs',320002145,'ZANGI','ZANGI:HBKNO15',0,0,1); INSERT INTO "tbl_srs" VALUES(26825,'South African CRS : HBK_NO_17','tmerc','WGS84','+proj=tmerc +lat_0=0 +lon_0=17 +k=1 +x_0=0 +y_0=0 +axis=enu +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs',320002146,'ZANGI','ZANGI:HBKNO17',0,0,1); INSERT INTO "tbl_srs" VALUES(26826,'South African CRS : HBK_NO_19','tmerc','WGS84','+proj=tmerc +lat_0=0 +lon_0=19 +k=1 +x_0=0 +y_0=0 +axis=enu +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs',320002147,'ZANGI','ZANGI:HBKNO19',0,0,1); INSERT INTO "tbl_srs" VALUES(26827,'South African CRS : HBK_NO_21','tmerc','WGS84','+proj=tmerc +lat_0=0 +lon_0=21 +k=1 +x_0=0 +y_0=0 +axis=enu +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs',320002148,'ZANGI','ZANGI:HBKNO21',0,0,1); INSERT INTO "tbl_srs" VALUES(26828,'South African CRS : HBK_NO_23','tmerc','WGS84','+proj=tmerc +lat_0=0 +lon_0=23 +k=1 +x_0=0 +y_0=0 +axis=enu +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs',320002149,'ZANGI','ZANGI:HBKNO23',0,0,1); INSERT INTO "tbl_srs" VALUES(26829,'South African CRS : HBK_NO_25','tmerc','WGS84','+proj=tmerc +lat_0=0 +lon_0=25 +k=1 +x_0=0 +y_0=0 +axis=enu +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs',320002150,'ZANGI','ZANGI:HBKNO25',0,0,1); INSERT INTO "tbl_srs" VALUES(26830,'South African CRS : HBK_NO_27','tmerc','WGS84','+proj=tmerc +lat_0=0 +lon_0=27 +k=1 +x_0=0 +y_0=0 +axis=enu +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs',320002151,'ZANGI','ZANGI:HBKNO27',0,0,1); INSERT INTO "tbl_srs" VALUES(26831,'South African CRS : HBK_NO_29','tmerc','WGS84','+proj=tmerc +lat_0=0 +lon_0=29 +k=1 +x_0=0 +y_0=0 +axis=enu +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs',320002152,'ZANGI','ZANGI:HBKNO29',0,0,1); INSERT INTO "tbl_srs" VALUES(26832,'South African CRS : HBK_NO_31','tmerc','WGS84','+proj=tmerc +lat_0=0 +lon_0=31 +k=1 +x_0=0 +y_0=0 +axis=enu +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs',320002153,'ZANGI','ZANGI:HBKNO31',0,0,1); INSERT INTO "tbl_srs" VALUES(26833,'South African CRS : HBK_NO_33','tmerc','WGS84','+proj=tmerc +lat_0=0 +lon_0=33 +k=1 +x_0=0 +y_0=0 +axis=enu +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs',320002154,'ZANGI','ZANGI:HBKNO33',0,0,1);
Notes on acronyms used:
Author Name: Tim Sutton (Tim Sutton)
14f639d Adds the above CRS's
Author Name: Giovanni Manghi (@gioman)
Author Name: Gavin Fleming (@gubuntu)
bug appears to be fixed in 2.1.0 Master (though the new north-oriented CRS definitions Tim added don't appear yet)
Author Name: Giovanni Manghi (@gioman)
Gavin Fleming wrote:
bug appears to be fixed in 2.1.0 Master (though the new north-oriented CRS definitions Tim added don't appear yet)
can we close this?
Author Name: Gavin Fleming (@gubuntu)
Yes you can close it, thanks all. The original issue as well as the related issues brought up in the discussion are all fixed in master.
Author Name: Giovanni Manghi (@gioman)
Author Name: Gavin Fleming (@gubuntu) Original Redmine Issue: 8487 Affected QGIS version: master Redmine category:projection_support
The new series of EPSG codes for South Africa (Hartebeesthoek/LO) with +axis=wsu might be correct for land survey data in South Africa, which is 'south-facing', but it is NOT correct for the way GIS is practised in South Africa, where conventionally-oriented coordinates are used.
QGIS is now forcefully overriding my manual CRS definitions so I cannot work in our local projections any more.
I define a CRS as such: @+proj=tmerc +lat_0=0 +lon_0=21 +k=1 +x_0=0 +y_0=0 +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs@, which QGIS 1.8 and even 1.9 till recently obeyed. Now QGIS replaces this with @+proj=tmerc +lat_0=0 +lon_0=21 +k=1 +x_0=0 +y_0=0 +axis=wsu +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs@ (note the added @+axis=wsu@) which is completely unusable since no GIS data in South Africa has 'south-facing' coordinates. The map is flipped upside down and back to front and I have no way of correcting it.
QGIS is apparently detecting that my definition is similar to EPSG:2049 and imposing the EPSG:2049 definition on my own.