[Qgis-user] Projection of Shapefile export

[Ramon Andinach]

On 21/03/2011, at 19:51 , Ramon Andinach wrote:

> 
> On 21/03/2011, at 10:21 , Brett Adams wrote:
> 
>> I thought this problem merely related to the failure of Australian projections. Projection data doesn't exist, therefore can't be exported with the shape file.
>> 
>> If the points are imported as WGS84 / UTMz51S, then export the shape file, the projection file contains the relevant information. Its all good.
>> 
>> So if the projection issue is fixed, shape files will then export with the required projection information.
>> 
>> 
>> As far as I can see, there is no bug here. If anyone can show otherwise, we need to record the bug and create a ticket (if it doesn't exist already)
> 
> The little bit of information I had before, I just tacked on to the end of your existing ticket.
> 
> I was going to put a bit of my spare time during this week into trying to replicate Roland's solution firstly on my home linux machine and then see if I could make that approach work on windows at work.
> 
> From my recollection last time I was trying Ken's solution and a few others like just defining a CRS and couldn't quite get there.
> 
> Let you know what eventuates.

Short version:
I'm fairly sure that QGIS 1.7 is approximately 2 (fairly large) files away from being able to handle AGD points.

The files are here: 
http://www.icsm.gov.au/icsm/gda/gdatm/national66.zip
and here:
http://www.icsm.gov.au/icsm/gda/gdatm/national84.zip

and these equate to the missing datum shift files.

In 1.7 as at this afternoon, you need to download them, unzip them rename them to agd66.gsb or agd84.gsb and copy them to:
/usr/share/proj  - for linux users
C:/OSGeo4W/share/proj - for OSGeo windows installs

and that means it should be something like
C:/Program Files/Quantum version/share/proj
for standalone versions (sorry forgot to check before going home - will check in the morning).

Paolo, I know string freeze is tomorrow, but is there any chance that these two files could be included in 1.7? 
They should be under a CC by Atrrib (Australian variant). 
(I can ring up GA tomorrow and confirm if needed. Do any of the Australians on the list know who might be the right person to ask? Just to save me stumbling around in the dark a bit.)

Brett, I also had a problem with QGIS remembering CRS but I'll put that in a different thread. If you had any test files that you wanted me to check, I'd be happy to do so.

-ramon.


The long version is below.
None of this is new - mostly it's that I'm slow to understand.

In this message, Ken Norris points to the relevent distortion files:
http://lists.osgeo.org/pipermail/qgis-user/2010-September/009731.html

Roland Hill picked up on this and modified the srs.db file and produced these messages:
http://www.mail-archive.com/qgis-user@lists.osgeo.org/msg07365.html and
http://www.mail-archive.com/qgis-user@lists.osgeo.org/msg07379.html

At least in the first message he used the following parameters to update the srs.db.
For AGD84:
'+ellps=aust_SA', '+a=6378160 +rf=298.250000000055 +towgs84=-117.763,-51.51,139.061,-0.292,-0.443,-0.277,-0.191
and for AGD66:
'+ellps=aust_SA', '+a=6378160 +rf=298.250000000055 +towgs84=-129.193,-41.212,130.73,-0.246,-0.374,-0.329,-2.955

Then placed the agd84 and agd66.gsb files into /usr/share/proj.

In attempting to replicate Roland I noticed that in 1.7 AGD84 is defined as ESPG:4203 and in Proj.4 format _projlonglat +elips=aust-SA +towards84=-117.763,-51.51,139.061,-0.443,-0.277,-0.191 +nadgrids=agd.gsb +wktext=no_defs which to me looked a lot like Roland's definition (please don't ask me to translate - I can't).

So I added in the two .gsb files and tested using this test set: http://members.westnet.com.au/ramon_et_al/SinglePoint2.zip

This contains a single point in my main area of operations, recorded originally in MGA94z51 using a Garmin GPS76. I've then converted the point into GDA94 using GA's online converter, and into AGD66, AGD84 (and relevant UTM equivilants) using GA's agd-gda94.xls block calculations (see the included ASinglePoint.ods for calculations).

From the spreadsheet I've loaded the point in each different projection (ASinglePoint.qgs).

OTF works, and the points in that project cluster within a 1.1mx0.6m area. I would suspect that most of that error is probably more a reflection of the rough methods I used to convert them.