[Qgis-user] Projection of Shapefile export

Wed Mar 23 21:59:49 PDT 2011

That's a bummer. 

Given the developers are in string freeze for 1.7, I don't think a fix for this bit will make it to 1.7. I've asked about the display part, we might have been a bit late there too, but will have to see. 

If the display can't be sorted for 1.7, we've got a work-around now. I'll write it up and stick it on the QGIS wiki so we point others at it as needed. 

As for transfering files, I think it's pulled the names out of the gsb file somewhere. The names seem to relate to what it is internally calling the CRS. So in this case, QGIS (probably via the GSB file) is calling the CRS something different to ARC. This is probably a constrained enough problem that we could point someone who knew what they were doing at it and get somewhere. [1,2] 

As a stop gap, would you be interested in this idea? 
- It looks like there's only 4 headers that are different, and the key variables are the same. 
- If we can work out which are the signifcant changes are, we could try to build a little script to fix them for when you hand them over to a client.[3] 

So that means that there's two options:
1. The long way. It might only be one or two of the headers. If you're interested, attached is a little zip file with all the varitions of these four values I could think of. Testing will be a case of renaming each one at a time and loading up the shape to see if it works. If it is only one or two, then the script will be simpler for me.
2. The short way. We just assume that all four are important and go from there.

If 1. then pull down the zip file and see if something works. Tjem let me know which one was sucessful.
Otherwise, for 2, could you send an example of the AMG84 prj file?
(I'd imagine that you don't have much call for lat longs, but if you do, probably better have examples of their files too.)

In terms of using QGIS with these doctored .prj files, QGIS seems to prefer the .qpj file, so co-existance should be possible. 

-ramon. 

Some random thoughts: 
1. If it is pulling names from the GSB, can the GSB be edited? 
2. I have a hazy recollection of other projections possibly having similar problems. Not sure, have to check.
3. I see why this is vital to you. I was about to say I've not had to hand shp files out yet, but I have - so I'll have to make a phone call and find out what happened.
----- "Brett Adams" <badams at spinifexgeophysics.com.au> wrote: 
> Ramon, 
> Loaded your shape files into ARCGIS. It recognised none of the projections defaulting to WGS84 every time. 
> 
> Attached are a couple of prj files generated by ARCGIS. These look much nicer. 
> 
> With any luck, all these issues will be sorted in the major release of 1.7 due at the end of this month. :-) I'm looking forward to this one. 
> 
> BA 
> 
> 
> 
> On 24/03/2011 6:48 AM, Ramon Andinach wrote: 
> 
> I had a look at them when I was trying to work out why some 
> imported text wasn't correctly reporting its CRS. They look like pretty strange to me, but since I could open the project on a linux and win7 in different computers with identical results I was happy at that.
> 
> It's unlikely I'll get near MI or Arc for quite some time, but I'll > be curious what you see.
> 
> -ramon.
> 
> 
> On 23/03/2011, at 23:38 , Brett Adams wrote: 
> 
> Ramon, 
> I loaded the gsb files as you suggested. The grids now load into the correct position (correct enough for me anyway). Thats a great achievement right there.
> 
> The exported projection files (prj) look a bit odd. The segment DATUM["D_unknown" makes me a little nervous, however as I don't really know what I'm looking at, its hard to judge.  I'll need to see if they are recognised by Mapinfo or Arc. 
> 
> 
> Brett.
> 
> 
> 
> On 23/03/2011 12:58 PM, custard wrote: 
> 
> Brett, 
> 
> If you grab this zip file: http://members.westnet.com.au/ramon_et_al/BrettTest.zip In this zip file is your csv, a bundle of derived shape files, a 1.7 QGIS project (which will probably make 1.6 crash - but the shape files are good) and a folder with a few images.
> 
> The images are from the project, with projection set to MGA94 zone 51, but I have switched between GDA94, ADG66/84, WGS84 and the equivilent zone 51s, with OTF on.
> 
> The images show the points with OTF on and off, and zoomed in.
> 
> Are these close enough for your purposes?
> 
> The folder I gave for standalone should be right, but this method (for reasons I don't understand) doesn't seem to work on 1.6 standalone under WinXP. (I'm hoping it's a 1.6 thing, and not an osgeos/standalone thing)
> 
> -ramon.
> 
> ----- Original Message -----
> From: "Brett Adams" <badams at spinifexgeophysics.com.au> To: qgis-user at lists.osgeo.org , "Ramon Andinach" <custard at westnet.com.au> Sent: Wednesday, 23 March, 2011 8:20:43 AM GMT +08:00 Beijing / Chongqing / Hong Kong / Urumqi
Subject: Re: [Qgis-user]  Projection of Shapefile export

Ramon,
Attached CSV contains grid coordinates in 4 different projections; AGD66, AGD84, GDA94 and WGS84. All zone 51 and 51S

The conversions were calculated using Mapinfo. Conversions can vary up to 1-2m depending on the parameters used so don't be too surprised if you can't replicate these exactly. 

These are the same points attached to Bug Ticket 3099.

Brett

On 22/03/2011 6:37 PM, Ramon Andinach wrote:
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. 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AMG66z51-Brett_prj.zip
Type: application/zip
Size: 5591 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20110324/f37d4cb0/attachment.zip>