[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 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

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/784#comment:11>
GRASS GIS <http://grass.osgeo.org>