[GRASS-dev] Re: [GRASS GIS] #785: wx location wizard: doesn't show all datum transform opts

[GRASS GIS]

#785: wx location wizard: doesn't show all datum transform opts
-----------------------+----------------------------------------------------
  Reporter:  hamish    |       Owner:  grass-dev at lists.osgeo.org
      Type:  defect    |      Status:  new                      
  Priority:  critical  |   Milestone:  6.4.0                    
 Component:  wxGUI     |     Version:  svn-develbranch6         
Resolution:            |    Keywords:  location wizard          
  Platform:  Linux     |         Cpu:  x86-64                   
-----------------------+----------------------------------------------------
Comment (by cmbarton):

 Replying to [comment:20 hamish]:

 Thanks very much for the quick testing and reply.

 > The new datum transform GUI is a solid step forward. Can it be
 integrated as a page of the wizard instead of a popup? (radio buttons?)

 Not easily. This is what we had before and it was problematic. The most
 reliable way to get the proper transform options, AFAIK, is to run g.proj
 .... datatrans=-1. If transforms are needed, it will return them as a text
 string (i.e., that is parsed to produce the current popup). But if
 transforms are not needed it will not return anything.

 >
 > Unfortuanetly the terms in the wizard Summary page do not reflect the
 selection you make, and once the location is created the datum stuff
 doesn't make it to the PROJ_INFO file again.

 This is doable using g.proj but requires some rewiring of how the summary
 page is created.

 >
 > For datum -> WGS84 there is no popup. Even though there is only one
 choice, in an old discussion we decided to show the list anyway so the
 user knew what was going on. It's just an [Ok] confirmation, so no big
 hassle for the user to step past.


 See above. Because of g.proj behavior, this is not possible without going
 back to parsing the transform tables--that got us into trouble in the
 first place.

 >
 > .
 >
 > The proj_desc.table will have to be manually dealt with, but let's get
 the datum stuff sorted out first. (lessons learned, etc)
 > In effect we (well, for now you anyway) are rewriting g.setproj using
 Python instead of C.
 > Glynn(?) did a nice job extracting those tables which should make things
 much easier.
 >
 > if you look at any of the tmerc projections in the EPSG file you will
 see some of the terms which are used to define it. The user should be able
 to recreate anything there via the prompts.

 I don't remember seeing these prompts in the old g.setproj. But maybe I
 just never tried to create projections that were sufficiently exotic. I'll
 run g.setproj with some different projections and see what happens.

 If I create a location with a LCC, an NAD83 datum, and the proper
 transforms is it wrong? Or is it just that you can get somewhat different
 projections that might better meet particular needs by also specifying
 other parameters?

 If it creates a geodetically '''incorrect''' location, this is very
 serious. If adding more parameters simply adds greater flexibility in
 projection creation, we have a little more breathing room to work out a
 way to incorporate these and present them to the user in a reasonable way.

 Michael

 >
 >
 > thanks & sorry I can't give you more coding help right now,
 > Hamish

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