[GRASS-dev] Re: [GRASS GIS] #784: wx location wizard: fails to set datum

[GRASS GIS]

#784: wx location wizard: fails to set datum
---------------------------------+------------------------------------------
  Reporter:  hamish              |       Owner:  grass-dev at 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>