wx location wizard: fails to set datum

[hamish]

Hi,

if I make a new location using the wx location wizard (say utm zone 41 south with WGS84 datum) the datum fails to be set.

g.region -p says

datum:      ** unknown (default: WGS84) **

and g.proj -p only shows an ellps value.

thanks, Hamish

[cmbarton]

Any chance this could be a g.proj problem with southern hemisphere data?

Michael

[hamish]

Replying to cmbarton:

Any chance this could be a g.proj problem with southern hemisphere data?

Nope; I tried making other non-UTM and UTM-north locations and see the same thing.

The loc'n wizard shows the expanded terms for the selected datum in the Summary page PROJ.4 definition line (+a=, +rf=), but not the +datum= part. hmmph, there is more wrong there (duplication); continued in #785. These seem to be linked.

Hamish

[cmbarton]

This should be fixed by r39554. This is connected with issues reported in #784. So I 'm closing this. Any further issues should be continued in 784.

Michael

[hamish]

(make that #785)

[hamish]

this serious bug remains unfixed.

AFAIR it was working last week for a short time.

Hamish

[cmbarton]

The GUI creates a location using g.proj -c. So if a datum does not get set, it is a problem with g.proj AFAICT. This is indeed serious and needs fixing. I'm changing it from wxGUI to projections/datums in the hopes of getting it fixed.

Michael

[hamish]

does the +datum= term make it into the proj4string which is given to g.proj -c?

Hamish

[hamish]

Replying to hamish:

does the +datum= term make it into the proj4string which is given to g.proj -c?

It does not make it into the proj4string shown on the summary page.

Hamish

[cmbarton]

Yes. The +datum= term does make it into the proj4 string. However, when I do a g.proj -j to get the string used on the summary page, it is no longer there. I was assuming that it's parameters were being substituted by g.proj for the datum, but perhaps something is happening to the datum parameter in g.proj.

Michael

[cmbarton]

I was wrong. This was a problem in the location wizard. It looked like the datum (and ellipse was making it into the proj4 string, but it was not. This is now fixed in develbranch_6 r39576 and backported to trunk.

Michael

[hamish]

ok, thanks. Datum/ellips is back for NZMG/NZGD49.

I notice it does not let you pick datums S-42, SAD69, and Sasia, the Next button stays greyed out. Presumably because they have upper case letters. Also (for me at least) those 3 appear at the top of the list, not in alphabetical order.

I also notice that +ellps= is leading to some other weirdness:

create a UTM projection with the sam69 datum (South American 1969)

PROJ_INFO ends up with:

ellps: australian

but no "datum:". and g.region -p comes up with:

datum:      ** unknown (default: WGS84) **

(note the terms for both S.A. and Aust. are the same in the ellipse.table file)

hmmmn, proj -le groups them:

  aust_SA a=6378160.0      rf=298.25        Australian Natl & S. Amer. 1969

so names were expanded because GRASS knows more named datums/ellipsoids than +proj terms do, but it is a lossy process in that the named datum/ellipsoid is lost in favour of its constituent terms. And so GRASS didn't see a datum line in the PROJ_INFO file and complained that one wasn't set. (I guess the g.region logic could be improved too, but maybe it has a point)

I am unsure of the implications for proj4 versions > 4.5.0 where datum terms must now be defined on both sides of the reprojection (I assume expanded version will be ok), and of the g.region -p "datum not defined, assuming WGS84" effects when non-WGS84-like datum terms are present, even if a name isn't.

If only for metadata purposes the non-matching datum and ellipsoid names should be preserved if possible.

So now I'm wondering if we do have to fall back to writing the PROJ_INFO file manually after all, instead of using g.proj -c. (AFAICS we have all the info we need to do that by the time we get to the summary page)

At this point I'm starting to spin in circles due to ignorance so I'll need to take a little time to study the python code to be able to provide you with more useful feedback.

One last aesthetic request though, could the summary page break up the

Projection: $proj_name, $datum name

into two lines, with the datum (or ellipsoid) put on the second

Datum: 

line? (change to Ellipsoid if datum was not given)

---

a semi-related (& perhaps dubious) enhancement to the PROJ_INFO construct is to think about adding a new "epsg: " line to preserve that for export meta-data and WMSs.

Hamish

[cmbarton]

Replying to hamish:

ok, thanks. Datum/ellips is back for NZMG/NZGD49.

I notice it does not let you pick datums S-42, SAD69, and Sasia, the Next button stays greyed out. Presumably because they have upper case letters. Also (for me at least) those 3 appear at the top of the list, not in alphabetical order.

I also notice that +ellps= is leading to some other weirdness:

create a UTM projection with the sam69 datum (South American 1969)

PROJ_INFO ends up with:

ellps: australian

but no "datum:". and g.region -p comes up with:

datum:      ** unknown (default: WGS84) **

(note the terms for both S.A. and Aust. are the same in the ellipse.table file)

hmmmn, proj -le groups them:

  aust_SA a=6378160.0      rf=298.25        Australian Natl & S. Amer. 1969

so names were expanded because GRASS knows more named datums/ellipsoids than +proj terms do, but it is a lossy process in that the named datum/ellipsoid is lost in favour of its constituent terms. And so GRASS didn't see a datum line in the PROJ_INFO file and complained that one wasn't set. (I guess the g.region logic could be improved too, but maybe it has a point)

Here is what goes into a proj4 string that is run through g.proj for this.

+proj=utm +zone=30 +ellps=sam69 +a6378160.000 +rf=298.25 +datum=sam69 +dx=-57 +dy=1 +dz=-41 +no_defs

(Ignore the projection and zone. I just put in something to get a string.) Note that both the +ellps AND +datum parameters are set.

What location_wizard.py is doing here is:

0) Start building a proj4 string from the projection (+proj=proj) and any projection parameters.

1) Look up the datum in a python dictionary created from datum.table (this is why SAD etc are at the top of the list). It it's in the dictionary, assign it to the datum variable, assign any non-0 parameters to a list of datum parameters.

2) Look up the associated ellipse in the same dictionary (from datum.table) and assign it to the ellipse variable.

3) Look up the parameters associated with the ellipse in the dictionary created from ellipse.table and put them into a list of ellipse parameters.

4) For any non-empty values, add +ellps=ellipsevar +[ellipse param]=paramval to the growing proj4string variable.

5) For any non-empty values, do the same thing for datum and datum parameters (i.e., +datum=datumvar +[datum param]=paramval)

This all happens in LocationWizard.CreateProj4String.

I am unsure of the implications for proj4 versions > 4.5.0 where datum terms must now be defined on both sides of the reprojection (I assume expanded version will be ok), and of the g.region -p "datum not defined, assuming WGS84" effects when non-WGS84-like datum terms are present, even if a name isn't.

If only for metadata purposes the non-matching datum and ellipsoid names should be preserved if possible.

So now I'm wondering if we do have to fall back to writing the PROJ_INFO file manually after all, instead of using g.proj -c. (AFAICS we have all the info we need to do that by the time we get to the summary page)

At this point I'm starting to spin in circles due to ignorance so I'll need to take a little time to study the python code to be able to provide you with more useful feedback.

OK. Thanks much for taking the time to help with this.

One last aesthetic request though, could the summary page break up the

Projection: $proj_name, $datum name

into two lines, with the datum (or ellipsoid) put on the second

Datum: 

line? (change to Ellipsoid if datum was not given)

Let me look into it.

---

a semi-related (& perhaps dubious) enhancement to the PROJ_INFO construct is to think about adding a new "epsg: " line to preserve that for export meta-data and WMSs.

I'm not sure what you are asking here.

Michael

[cmbarton]

Replying to cmbarton:

Replying to hamish:

ok, thanks. Datum/ellips is back for NZMG/NZGD49.

I notice it does not let you pick datums S-42, SAD69, and Sasia, the Next button stays greyed out. Presumably because they have upper case letters. Also (for me at least) those 3 appear at the top of the list, not in alphabetical order.

Fixed in develbranch_6 (r39584) and trunk (r39583).