[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 hamish):

 Replying to [comment:27 cmbarton]:
 > > (e.g. NZMG, Lat/Lon's +lat_0,+lon_0 [could that 0,0 for LL
 > > just be removed from proj-parms.table?])
 >
 > No. If it has the wrong number of fields to parse, it won't
 > get parsed.

 I mean is it geodetically appropriate to remove the
 LAT0=noask,0.0;LON0=noask,0.0 params from the proj-parms.table file? That
 would leave the last field empty, but the parsing code should be able to
 continue past an empty string as long as it has the correct number of
 delimiters.


 > >  * Expand boolean from N/Y to No/Yes. e.g. UTM Southern
 > > Hemisphere question the default is "N" which can also be
 > > "North".
 >
 > I understand the point, but 'No' is also a common abbreviation
 > for north in some English dialects.

 Perhaps, but much less so than "N".

 > So I can make the change, but I'm not sure that this helps.
 > IIRC, g.setproj uses y/n.

 g.setproj uses G_yes().

 if in doubt err on the side of spelling stuff out..

 > >  Better yet: figure out how to have it be
 > > 'Hemisphere: North|South'
 >
 > Won't work because PROJ4 doesn't recognize it. I could do a
 > bunch of hard coding of course,

 that was the idea. For the special cases of LL, UTM, and SP hardcoding is
 perfectly acceptable.

 > but the idea is to not have to change the interface if the
 > underlying module and table contents change.

 I think we can trust the format of those will stay pretty stable.

 > >  * For UTM, could 1-60 pulldown list be a constrained value
 > > spinbox instead?
 >
 > Why is a spinbox better than a pulldown where you can quickly
 > get to the number?

 oh just aesthetics. especially on a small screen like a netbook.

 > I could just make it an open text control,

 no thanks,

 > but the choicebox ensures that a legal value is chosen.

 as does the spinbox.


 > >  * Could datum transform list selection popup be integrated
 > > into the wizard [<Back] [Fwd>] pages, or at least be given the
 > > same window height x width? It seems a bit out of place.
 >
 > No. The most reliable way to get this is have g.proj datumtrans=-1
 > spit it out.

 I wasn't meaning chaning the back-end method, I just mean the presentation
 to the user.


 > It comes out as a list of 3-4 lines per transform. I could wrap
 > them all together (i.e., into a paragraph that wraps),

 convert into a table like projection or datum names? (mmmph..)

 > but they seem easier to read in the vertical format.

 I don't mean to have it all as a single line string.

 > > Better yet: could it have a radio button list like the Tcl/Tk
 > > version (try EPSG:27200).
 >
 > Why radiobuttons over the select the list item? This adds even
 > more whitespace to the left of the list item. I'm trying to
 > keep it as compact as possible while still readable. There is
 > quite a bit of text in some of the transform descriptions.

 just aesthetics; I think the tcl/tk one looks nice.
 the number on the first line could be skipped.


 > >  * on the "Specify geodetic datum" page, could the Description
 > > column be made a bit wider by default? it's the long string
 > > and ellipsoid is the short one.
 >
 > The only way is to make it 3rd in the list.

 as you can adjust it by hand, it seems strange there no way to preset
 that..? shrug

 > Not hard to do, but will require rewiring things that look
 > for it in 2nd place.

 the order is correct as-is, the ellipsoid is secondary information.


 > >  * "Choose EPSG code" search is still a bit weird (need to
 > > reload to start a new search)
 >
 > I think I can make it work like the other searches now so that
 > it automatically looks in all fields with a single control.

 thanks.


 Hamish

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