<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body ><div><div></div><div>Thanks</div><div><br></div><div><br></div><div><div>Regards, </div><div><br></div>MD Manyama<div>CEO</div><div>Phala Geo-Spatial Solutions</div><div>Cell: 084 710 8815</div></div></div><br><br><br>-------- Original message --------<br>From: Gavin Fleming <gavin@afrispatial.co.za> <br>Date: 17/04/2014 23:19 (GMT+02:00) <br>To: africa@lists.osgeo.org <br>Subject: Re: [OSGeo Africa] QGIS and projection names <br> <br><br>Hi Hanlie / Magriet<br><br>On 17/04/2014 14:03, Hanlie Pretorius wrote:<br>> I created a shapefile in QGIS and selected South African CRS:<br>> HBK_NO_23 as my CRS.<br>><br>> When I open the file in QGIS, the metadata for the projection reads:<br>><br>> USER:100001 - * Generated CRS (+proj=tmerc +lat_0=0 +lon_0=23 +k=1<br>> +x_0=0 +y_0=0 +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs)<br>><br>> Furthermore, this 'user specified' CRS now exists in my list of<br>> projections. I find this rather annoying because I end up with a<br>> growing list of identical projection definitions.<br>QGIS will add a user specified definition whenever you open a file with <br>a definition that doesn't match one in the QGIS CRS database. HBK_NO_23 <br>has '+axis=enu' which won't make a difference but is just not a close <br>enough match. Although if you created it in QGIS I imagine it should be <br>writing the +axis=enu out in the projection file. If this isn't behaving <br>as you'd expect I suggest you create an issue at http://hub.qgis.org/.<br>><br>> The .prj file reads:<br>><br>> PROJCS["Transverse_Mercator",GEOGCS["GCS_WGS_1984",DATUM["D_unknown",SPHEROID["WGS84",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",23],PARAMETER["scale_factor",1],PARAMETER["false_easting",0],PARAMETER["false_northing",0],UNIT["Meter",1]]<br>><br>> and the .qpj file reads:<br>><br>> PROJCS["unnamed",GEOGCS["WGS<br>> 84",DATUM["unknown",SPHEROID["WGS84",6378137,298.257223563],TOWGS84[0,0,0,0,0,0,0]],PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",23],PARAMETER["scale_factor",1],PARAMETER["false_easting",0],PARAMETER["false_northing",0],UNIT["Meter",1]]<br>The definition of "degree" in the .prj and .qpj is different in your two <br>examples above. This should not be the case! It looks like this calls <br>for another issue in http://hub.qgis.org/ if they were both generated by <br>QGIS. I've just tested it and indeed QGIS is writing different degree <br>values in the qpj and prj files. afaik QGIS will then read the qpj in <br>future when you open that file, while other software will open the prj <br>file.<br>><br>> I'm just wondering if all these different CRS specifications may be<br>> causing problems when using the shapefile with other programs, such as<br>> ArcGIS. I am having problems with shapefiles looking correct in QGIS<br>> but shifted in ArcGIS. The shift is about 70 meters in the x direction<br>> and 255 meters in the y direction.<br>The definitions themselves are just different ways of saying the same <br>thing in WKT. I'm sure the error is coming in because of that difference <br>in "degree" value between the prj and qpj files.<br>><br>> I found this web page (http://www.georeference.org/forum/t115330)<br>> saying that the difference between WGS84 and Hartbeeshoek 1994) is<br>> approximately 0.2 m and 0.3 m in Lo y and x coordinates respectively.<br>I don't know where that comes from and I have never seen any reference <br>that there is a shift between WGS84 and Hartebeesthoek94. The proj4 <br>definition of Hartebeesthoek is 'towgs84=0,0,0,0,0,0,0' which means that <br>there's no transformation, i.e. coordinates on those datums are the same.<br>><br>> I see in ArcGIS the transformation reads dx=0, dy=0, dz=0. So if the<br>> two datums are identical for most purposes, what else could be causing<br>> a shift in positions between the two programs?<br>same comments as above.<br>><br>Gavin<br><br><br>-- <br><br>Gavin Fleming<br>http://afrispatial.co.za<br>t: 0218630660<br>c: 0845965680<br>f: 0866164820<br><br>_______________________________________________<br>Africa mailing list<br>Africa@lists.osgeo.org<br>You can UNSUBSCRIBE at http://lists.osgeo.org/mailman/listinfo/africa<br></body>