https://issues.qgis.org/https://issues.qgis.org/favicon.ico2013-08-22T10:22:01ZQGIS Issue TrackingQGIS Application - Bug report #8487: manual CRS being overwritten by QGIShttps://issues.qgis.org/issues/8487?journal_id=442072013-08-22T10:22:01ZJürgen Fischerjef@norbit.de
<ul></ul><p>Is that a custom crs or did you modify srs.db?</p> QGIS Application - Bug report #8487: manual CRS being overwritten by QGIShttps://issues.qgis.org/issues/8487?journal_id=442132013-08-23T00:32:13ZGiovanni Manghigiovanni.manghi@gmail.com
<ul><li><strong>Operating System</strong> deleted (<del><i>ubuntu</i></del>)</li><li><strong>OS version</strong> deleted (<del><i>13.04</i></del>)</li></ul><p>Jürgen Fischer wrote:</p>
<blockquote>
<p>Is that a custom crs or did you modify srs.db?</p>
</blockquote>
<p>it is a custom crs, I tested and qgis does indeed overwrite the crs string.</p> QGIS Application - Bug report #8487: manual CRS being overwritten by QGIShttps://issues.qgis.org/issues/8487?journal_id=442492013-08-26T00:38:50ZFrank Sokolicsokolic@worldonline.co.za
<ul></ul><p>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 <a class="issue tracker-1 status-5 priority-10 priority- closed" href="https://issues.qgis.org/issues/8487" title="manual CRS being overwritten by QGIS (Closed)">#8487</a> goes away. Is this a possible solution to this bug?</p> QGIS Application - Bug report #8487: manual CRS being overwritten by QGIShttps://issues.qgis.org/issues/8487?journal_id=442502013-08-26T00:47:53ZJürgen Fischerjef@norbit.de
<ul></ul><p>Giovanni Manghi wrote:</p>
<blockquote>
<p>it is a custom crs, I tested and qgis does indeed overwrite the crs string.</p>
</blockquote>
<p>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?</p> QGIS Application - Bug report #8487: manual CRS being overwritten by QGIShttps://issues.qgis.org/issues/8487?journal_id=442512013-08-26T00:56:42ZLeyan Ouyang
<ul></ul><p>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.</p>
<p>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 <a href="https://github.com/qgis/Quantum-GIS/blob/master/src/core/qgscoordinatereferencesystem.cpp#L600" class="external">here</a></p>
<p>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 ...</p> QGIS Application - Bug report #8487: manual CRS being overwritten by QGIShttps://issues.qgis.org/issues/8487?journal_id=442542013-08-26T01:40:20ZGiovanni Manghigiovanni.manghi@gmail.com
<ul></ul><p>Jürgen Fischer wrote:</p>
<blockquote>
<p>What exactly happens?</p>
</blockquote>
<p>you create the custom CRS with</p>
<p>+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</p>
<p>then click ok, and when you go edit the same CRS it turns it is</p>
<p>+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</p> QGIS Application - Bug report #8487: manual CRS being overwritten by QGIShttps://issues.qgis.org/issues/8487?journal_id=442562013-08-26T01:52:44ZFrank Sokolicsokolic@worldonline.co.za
<ul></ul><p>Yes, on my system (Ubuntu 13.04, QGIS Master) if I create a custom CRS, e.g:</p>
<p>+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</p>
<p>and then click ok, and then edit the same CRS then +axis=wsu has been added:</p>
<p>+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</p> QGIS Application - Bug report #8487: manual CRS being overwritten by QGIShttps://issues.qgis.org/issues/8487?journal_id=442572013-08-26T02:00:01ZFrank Sokolicsokolic@worldonline.co.za
<ul></ul><p>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.</p> QGIS Application - Bug report #8487: manual CRS being overwritten by QGIShttps://issues.qgis.org/issues/8487?journal_id=442962013-08-27T10:55:37ZHien TRAN-QUANG
<ul></ul><p>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.</p>
<p>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 ?</p> QGIS Application - Bug report #8487: manual CRS being overwritten by QGIShttps://issues.qgis.org/issues/8487?journal_id=443542013-08-29T10:08:50ZHien TRAN-QUANG
<ul></ul><p>I did a pull request [[<a class="external" href="https://github.com/qgis/Quantum-GIS/pull/838">https://github.com/qgis/Quantum-GIS/pull/838</a>]]<br />Now createFromProj4 only checks for same parameters (except +datum)</p> QGIS Application - Bug report #8487: manual CRS being overwritten by QGIShttps://issues.qgis.org/issues/8487?journal_id=443602013-08-29T21:51:51ZRené-Luc ReLucrldhont@3liz.com
<ul><li><strong>Pull Request or Patch supplied</strong> changed from <i>No</i> to <i>Yes</i></li><li><strong>Category</strong> set to <i>Projection Support</i></li><li><strong>Target version</strong> set to <i>Version 2.0.0</i></li><li><strong>Status info</strong> set to <i>Review requested</i></li></ul> QGIS Application - Bug report #8487: manual CRS being overwritten by QGIShttps://issues.qgis.org/issues/8487?journal_id=443922013-09-01T05:46:31ZGavin Fleminggavin@kartoza.com
<ul></ul><p>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.</p>
<p>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.</p>
<p>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):<br />+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.</p>
<p>I changed this to:<br />+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.</p>
<p>In Project properties it now appears as the following and most importantly, it behaves correctly:<br />+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</p>
<p>But if I open Custom CRS again it still shows:<br />+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</p> QGIS Application - Bug report #8487: manual CRS being overwritten by QGIShttps://issues.qgis.org/issues/8487?journal_id=444122013-09-01T21:31:45Zcraigleat -craigleat@foo.bar
<ul></ul><p>Frank Sokolic wrote:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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.</p> QGIS Application - Bug report #8487: manual CRS being overwritten by QGIShttps://issues.qgis.org/issues/8487?journal_id=444162013-09-02T00:00:57ZTim Suttontim@linfiniti.com
<ul></ul><p>There are a complex of issues, here I try to outline a roadmap to address them:</p>
<a name="Incorrect-Proj4-definitions"></a>
<h1 >Incorrect Proj4 definitions<a href="#Incorrect-Proj4-definitions" class="wiki-anchor">¶</a></h1>
<p>/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 <a class="external" href="http://trac.osgeo.org/proj/ticket/18">http://trac.osgeo.org/proj/ticket/18</a>).</p>
<pre>
# 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 <>
# 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 <>
# 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 <>
# 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 <>
# 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 <>
# 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 <>
# 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 <>
# 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 <>
# 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 <>
# 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 <>
# 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 <>
# 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 <>
# 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 <>
# 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 <>
# 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 <>
# 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 <>
# 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 <>
# 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 <>
# 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 <>
# 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 <>
</pre>
<p>Until such time as an upstream fix happens, it would be good to fix these locally in the srs.db</p>
<a name="There-are-no-north-facing-CRS-definitions-for-the-Lo-Hartebeeshoek-and-the-Lo-Cape-CRSs"></a>
<h1 >There are no north facing CRS definitions for the Lo Hartebeeshoek and the Lo Cape CRSs<a href="#There-are-no-north-facing-CRS-definitions-for-the-Lo-Hartebeeshoek-and-the-Lo-Cape-CRSs" class="wiki-anchor">¶</a></h1>
<p>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]).</p>
<p>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: SACRS_NO_<XX> and for Hartebeeshoek projections this: TM_CAPE_NO_<XX> where NO = North Orientated and <xx> is the zone.</p>
<a name="Test-dataset"></a>
<h1 >Test dataset<a href="#Test-dataset" class="wiki-anchor">¶</a></h1>
<p>We should have a test dataset which can be used to verify that the CRS is properly detected. We propose two test datasets:</p>
<ul>
<li>A bounding box for South Africa in EPSG:4326</li>
<li>A simple feature in SACRS_NO_23 which when repropected on the fly to EPSG:4326 intesects with the country bbox above.</li>
</ul>
<a name="EPSG-formalised-definitions"></a>
<h1 >EPSG formalised definitions<a href="#EPSG-formalised-definitions" class="wiki-anchor">¶</a></h1>
<p>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.</p> QGIS Application - Bug report #8487: manual CRS being overwritten by QGIShttps://issues.qgis.org/issues/8487?journal_id=444182013-09-02T00:31:20Zcraigleat -craigleat@foo.bar
<ul></ul><p>Tim,</p>
<p>For your proposed schema did you mean the following, as you appear to have them switched around?<br />Lo Hartebeeshoek94 -> SACRS_NO_<XX><br />Lo Cape -> TM_CAPE_NO_<XX></p> QGIS Application - Bug report #8487: manual CRS being overwritten by QGIShttps://issues.qgis.org/issues/8487?journal_id=444212013-09-02T06:06:13ZGavin Fleminggavin@kartoza.com
<ul><li><strong>File</strong> <a href="/attachments/download/6189/test_4326.csv">test_4326.csv</a><a href="/attachments/6189/test_4326.csv"><img alt="Magnifier" src="/images/magnifier.png" /></a> added</li><li><strong>File</strong> <a href="/attachments/download/6190/test_2050.csv">test_2050.csv</a><a href="/attachments/6190/test_2050.csv"><img alt="Magnifier" src="/images/magnifier.png" /></a> added</li><li><strong>File</strong> <a href="/attachments/download/6191/test_SACRS_NO_23.csv">test_SACRS_NO_23.csv</a><a href="/attachments/6191/test_SACRS_NO_23.csv"><img alt="Magnifier" src="/images/magnifier.png" /></a> added</li></ul><p>@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.</p>
<p>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).</p>
<p>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.</p>
<p>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.</p>
<p>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.</p> QGIS Application - Bug report #8487: manual CRS being overwritten by QGIShttps://issues.qgis.org/issues/8487?journal_id=444222013-09-02T06:16:35ZGavin Fleminggavin@kartoza.com
<ul><li><strong>File</strong> <a href="/attachments/download/6192/test_ZA_BB.csv">test_ZA_BB.csv</a><a href="/attachments/6192/test_ZA_BB.csv"><img alt="Magnifier" src="/images/magnifier.png" /></a> added</li></ul> QGIS Application - Bug report #8487: manual CRS being overwritten by QGIShttps://issues.qgis.org/issues/8487?journal_id=444552013-09-03T03:26:06ZGavin Fleminggavin@kartoza.com
<ul><li><strong>Priority</strong> changed from <i>Severe/Regression</i> to <i>High</i></li></ul><p>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.</p>
<p>Regarding the new north-facing SACRS ('ZANGI') CRS definitions, those are fine as Tim has described.</p> QGIS Application - Bug report #8487: manual CRS being overwritten by QGIShttps://issues.qgis.org/issues/8487?journal_id=444572013-09-03T04:07:13ZGavin Fleminggavin@kartoza.com
<ul><li><strong>Priority</strong> changed from <i>High</i> to <i>Severe/Regression</i></li></ul><p>I mistakenly downgraded this earlier - the original bug this Issue describes is still a blocker until resolved.</p> QGIS Application - Bug report #8487: manual CRS being overwritten by QGIShttps://issues.qgis.org/issues/8487?journal_id=444732013-09-03T14:19:29ZTim Suttontim@linfiniti.com
<ul></ul><p>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</p>
<p><quote><br />INSERT INTO "tbl_ellipsoid" <abbr title="'cape','Clarke 1880 mod.','a=6378249.145','b=6356514.966398753'">VALUES</abbr>;</p>
<p>INSERT INTO "tbl_srs" <abbr title="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">VALUES</abbr>;<br />INSERT INTO "tbl_srs" <abbr title="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">VALUES</abbr>;<br />INSERT INTO "tbl_srs" <abbr title="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">VALUES</abbr>;<br />INSERT INTO "tbl_srs" <abbr title="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">VALUES</abbr>;<br />INSERT INTO "tbl_srs" <abbr title="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">VALUES</abbr>;<br />INSERT INTO "tbl_srs" <abbr title="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">VALUES</abbr>;<br />INSERT INTO "tbl_srs" <abbr title="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">VALUES</abbr>;<br />INSERT INTO "tbl_srs" <abbr title="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">VALUES</abbr>;<br />INSERT INTO "tbl_srs" <abbr title="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">VALUES</abbr>;<br />INSERT INTO "tbl_srs" <abbr title="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">VALUES</abbr>;</p>
<p>INSERT INTO "tbl_srs" <abbr title="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">VALUES</abbr>;<br />INSERT INTO "tbl_srs" <abbr title="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">VALUES</abbr>;<br />INSERT INTO "tbl_srs" <abbr title="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">VALUES</abbr>;<br />INSERT INTO "tbl_srs" <abbr title="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">VALUES</abbr>;<br />INSERT INTO "tbl_srs" <abbr title="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">VALUES</abbr>;<br />INSERT INTO "tbl_srs" <abbr title="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">VALUES</abbr>;<br />INSERT INTO "tbl_srs" <abbr title="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">VALUES</abbr>;<br />INSERT INTO "tbl_srs" <abbr title="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">VALUES</abbr>;<br />INSERT INTO "tbl_srs" <abbr title="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">VALUES</abbr>;<br />INSERT INTO "tbl_srs" <abbr title="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">VALUES</abbr>;<br /></quote></p>
<p>Notes on acronyms used:</p>
<ul>
<li>ZANGI - South Africa National Geospatial Information [Dept]</li>
<li>CPNO<xx> (e.g. CPNO33) - Cape Datum North Oriented on centered longitude 33</li>
<li>HBKNO<xx> (e.g. HBKNO33) - Hartebeeshoek North Oriented on centered longitude 33</li>
<li>NO_<xx> (e.g. NO_15) - North Oriented on longitude 15</li>
</ul> QGIS Application - Bug report #8487: manual CRS being overwritten by QGIShttps://issues.qgis.org/issues/8487?journal_id=444742013-09-03T14:50:18ZTim Suttontim@linfiniti.com
<ul></ul><p><a class="changeset" href="https://issues.qgis.org/projects/qgis/repository/revisions/14f639d568fb5b8aba8b96f70f4b4e71253df0d4" title="Added South African north orientated CRS definitions for #8487">14f639d</a> Adds the above CRS's</p> QGIS Application - Bug report #8487: manual CRS being overwritten by QGIShttps://issues.qgis.org/issues/8487?journal_id=445622013-09-06T10:35:30ZGiovanni Manghigiovanni.manghi@gmail.com
<ul><li><strong>Target version</strong> changed from <i>Version 2.0.0</i> to <i>Future Release - High Priority</i></li></ul> QGIS Application - Bug report #8487: manual CRS being overwritten by QGIShttps://issues.qgis.org/issues/8487?journal_id=451192013-09-29T04:19:34ZGavin Fleminggavin@kartoza.com
<ul></ul><p>bug appears to be fixed in 2.1.0 Master (though the new north-oriented CRS definitions Tim added don't appear yet)</p> QGIS Application - Bug report #8487: manual CRS being overwritten by QGIShttps://issues.qgis.org/issues/8487?journal_id=476292014-01-24T06:04:00ZGiovanni Manghigiovanni.manghi@gmail.com
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Feedback</i></li></ul><p>Gavin Fleming wrote:</p>
<blockquote>
<p>bug appears to be fixed in 2.1.0 Master (though the new north-oriented CRS definitions Tim added don't appear yet)</p>
</blockquote>
<p>can we close this?</p> QGIS Application - Bug report #8487: manual CRS being overwritten by QGIShttps://issues.qgis.org/issues/8487?journal_id=476642014-01-26T00:24:17ZGavin Fleminggavin@kartoza.com
<ul></ul><p>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.</p> QGIS Application - Bug report #8487: manual CRS being overwritten by QGIShttps://issues.qgis.org/issues/8487?journal_id=476652014-01-26T00:28:52ZGiovanni Manghigiovanni.manghi@gmail.com
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Closed</i></li><li><strong>Resolution</strong> set to <i>fixed/implemented</i></li></ul>