[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:28 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.


 I see. In that case, it would automatically be parsed with no items. I
 think it would work.


 >
 >
 > > >  * 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.

 OK. I'll look into it after getting the backporting done.


 >
 > > >  * 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.

 let me see if I can constrain a spinbox that can be typed in.



 >
 > > 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..)

 A pain because in the transforms list I've looked at, there is a lot of
 variability in what is printed out and how it is formatted. Looks
 difficult to parse accurately.

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

 I left the number only because that is what actually goes into g.proj. I
 agree about the format, but it is only a little ugly. Hard to decide it
 the amount of effort to make a significant difference in how it looks is
 worth the effort.

 Michael

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