#784: wx location wizard: fails to set datum
---------------------------------+------------------------------------------
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: closed
Priority: major | Milestone: 6.4.0
Component: Projections/Datums | Version: svn-develbranch6
Resolution: fixed | Keywords:
Platform: Linux | Cpu: x86-64
---------------------------------+------------------------------------------
Comment (by cmbarton):
Replying to [comment:11 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
--
Ticket URL: <http://trac.osgeo.org/grass/ticket/784#comment:12>
GRASS GIS <http://grass.osgeo.org>