wx location wizard: doesn't show all datum transform opts

[hamish]

Hi,

If I create a new location with the wx loc'n wizard (e.g. proj=nzmg) on the "Specify geodetic datum" page if I choose the nzgd49 datum I only see two options in the lower pane. There should be three: 3-term, 7-term, and NTv2 grid file. I assume the 3-term is the one that's missing but there isn't enough info there for the user to know for sure. (add +proj terms as a second\n description line or tooltip?)

for wgs84 it is worse, you get the full list of transform params but no +towgs84=0,0,0 option.

lib/gis/datum.table ignored?

(also it would be nice if the search tools checked the Code column as well as the long description, and clicking on the magnifying glass icon executed the search)

thanks, Hamish

[cmbarton]

AFAIK, the options list is created from reading the datum.table file. Can you look in this file and see if it actually has the transforms that you need but seem to be missing?

Thanks Michael

[cmbarton]

Correction, the options are read from the datumtransform.table file, datums and their defaults are read from the datum.table file.

There are only 2 transforms for nzgd49 and none for wgs84 in the file.

[hamish]

Replying to cmbarton:

Correction, the options are read from the datumtransform.table file, datums and their defaults are read from the datum.table file.

There are only 2 transforms for nzgd49 and none for wgs84 in the file.

the 7-term and NTv2 transforms for nzgd49 are in the datumtransform.table file; the 3-term transform can be found in the datum.table file.

The WGS84 3-term transform (+towgs84=0,0,0) is also in the datum.table file. The terms found in both those files must be combined for presentation to the user.

Hamish

[hamish]

It is worse,

• start wx loc wiz
• some new name for the new loc'n
• proj: nzmg
• datum: nzgd49
• transfrom parms: T53
• Summary page: +dx,+dy,+dz are there (these are the "default" 3-param +towgs84 terms) *AND* the 7-term parms from T53. these are mutually exclusive. :-(

(no way to cut & paste out of the wizard summary beyond screenshots, sorry)

also:

• no way to clear/unselect transform params after clicking the [< Back] button, even if transform parms choice is removed.

• if you cancel the wizard, then again start the loc wiz, enter a new name but on the Choose Method page don't click on anything but [Next >] (leaving default Select Coord Sys selected), you go straight to the (mostly empty) Summary page. Doesn't happen the first time.

Hamish

[cmbarton]

Question. If I run g.proj with datumtrans=-1 for a UTM zone 3 NAD83, I get the following list below. The first 'transformation' is a default non-transform and in the datum.table. The remaining 5 transformations are in the datumtransform.table.

If none of the transforms 2-6 are specified, will transform #1 (the default) be used?

Michael

--- 1 Used in whole nad83 region towgs84=0.000,0.000,0.000 Default 3-Parameter Transformation (May not be optimum for older datums; use this only if no more appropriate options are available.) --- 2 Used in Florida nadgrids=FL Transforms 'Old NAD83' to 'HPGN NAD83' --- 3 Used in Maryland nadgrids=MD Transforms 'Old NAD83' to 'HPGN NAD83' --- 4 Used in Tennessee nadgrids=TN Transforms 'Old NAD83' to 'HPGN NAD83' --- 5 Used in Wisconsin nadgrids=WI Transforms 'Old NAD83' to 'HPGN NAD83' --- 6 Used in Washington - Oregon nadgrids=WO Transforms 'Old NAD83' to 'HPGN NAD83' GRASS 6.5.svn (Spearfish60_test):~ > c

[hamish]

g.proj --help says:

  datumtrans   Index number of datum transform parameters
                "0" for unspecified or "-1" to list and exit

so in this case valid options to pass g.proj for that are 0-6.

 g.proj datumtrans=-1  proj4="+proj=lcc +datum=nad83"

[aside] North American Datum 1983 (nad83) is chronologically very close to 1984, so +towgs84=0,0,0 isn't too surprising (same for any datum post-satellite era), the others (2-6) are all NTv2 grid file transforms (is NAD83 a continental plate-bound datum?).

I see the g.proj -t and -d flags, but not really sure if they help.

here are the valid options I was describing for my neck of the woods:

 g.proj proj4="+proj=nzmg +datum=nzgd49" datumtrans=-1 

If I guess correctly you are looking at parsing the g.proj datumtr=-1 output instead of the datumtransform.table file?

thanks, Hamish

[cmbarton]

Yea. There is already code for this in the epsg select page. I think this is the most reliable way to do the transforms.

Michael

[hamish]

Replying to cmbarton:

Yea. There is already code for this in the epsg select page. I think this is the most reliable way to do the transforms.

I concur Dr. Barton. If a pulldown menu were possible, that would be a lot easier than transcribing some custom "T21" code number.

cheers, Hamish

[cmbarton]

I think I've fixed this in develbranch_6 r39480. This also enhances searches so that all fields are searched. Please test this. I made a location with your New Zealand projection and it asked for the right transforms, but you'll know best if it is getting it right.

If it is OK, I'll backport to trunk and implement in release branch.

Michael

[hamish]

• datum name now makes it to 'g.proj -p', great.

some fine tuning:

• search by code works well. if I search for the "wgs" datum I see a bunch of repeats.

• trying to make a UTM location:

  Traceback (most recent call last):
    File "/home/hamish/dev/grass/svn/grass65/dist.x86_64-unknown-linux-gnu/etc/wxpython/gui_modules/location_wizard.py", line 1573, in OnEnterPage
      self.lproj4string.SetLabel(self.parent.CreateProj4String())
    File "/home/hamish/dev/grass/svn/grass65/dist.x86_64-unknown-linux-gnu/etc/wxpython/gui_modules/location_wizard.py", line 1983, in CreateProj4String
      proj4string = '+proj=%s +zone=%s' % (utm, utmzone)
  NameError: global name 'utm' is not defined
  

this needs to be undone:

@@ -1979,10 +1981,12 @@
             proj4string = '+proj=longlat'
         elif proj == 'utm':
-            proj4string = '+proj=%s +zone=%s' % (proj, utmzone)
+            proj4string = '+proj=%s +zone=%s' % (utm, utmzone)
             if utmhemisphere == 'south':
-                proj4string += ' +south'
+                proj4string += '+south'
         else:
             proj4string = '+proj=%s ' % (proj)

• could it ask for the datum transform before getting to the summary page? the summary page still lists the +dx +dy +dz proj4 terms which will not be used.

• text line for datum transform option # 1 overflows the right edge of the window (..."(May not be optimum for older [chop]")

• "Datums (select to see descriptions)" - nitpicky: It should probably be "Transform Parameters:" not "Datums:".

• could the transform pulldown list be by +proj4 term instead of by number? The number is internals which doesn't need to be exposed. Suggest adding '+' to the start of the proj4 term.

thanks, Hamish

[hamish]

there is still some work to be done I'm afraid.. a g.setproj session should give some guidance.

for other projections it is not asking all it needs to. e.g. LCC, TMerc never asks for lat_0, lon_0, etc.

see general/g.setproj/proj-parms.table for a list of questions which need to be asked (or are hardwired) for a given projection.

(see proj-desc.table to convert those to +proj4 terms)

the wizard should also probably ask what units you want (see proj-units.table)

Hamish

[hamish]

(proj-desc.table, proj-parms.table, and proj-units.table can be found in $etc)

[cmbarton]

This was a kind of quick fix just to see if it is doing the right stuff. I'm glad that it is (except for the bug you noticed above; I was falling asleep). Now I can work on some of the fine tuning.

Michael

[cmbarton]

Replying to hamish:

• datum name now makes it to 'g.proj -p', great.

some fine tuning:

• search by code works well. if I search for the "wgs" datum I see a bunch of repeats.

• trying to make a UTM location:

  Traceback (most recent call last):
    File "/home/hamish/dev/grass/svn/grass65/dist.x86_64-unknown-linux-gnu/etc/wxpython/gui_modules/location_wizard.py", line 1573, in OnEnterPage
      self.lproj4string.SetLabel(self.parent.CreateProj4String())
    File "/home/hamish/dev/grass/svn/grass65/dist.x86_64-unknown-linux-gnu/etc/wxpython/gui_modules/location_wizard.py", line 1983, in CreateProj4String
      proj4string = '+proj=%s +zone=%s' % (utm, utmzone)
  NameError: global name 'utm' is not defined
  

this needs to be undone:

@@ -1979,10 +1981,12 @@
             proj4string = '+proj=longlat'
         elif proj == 'utm':
-            proj4string = '+proj=%s +zone=%s' % (proj, utmzone)
+            proj4string = '+proj=%s +zone=%s' % (utm, utmzone)
             if utmhemisphere == 'south':
-                proj4string += ' +south'
+                proj4string += '+south'
         else:
             proj4string = '+proj=%s ' % (proj)

easily fixed

• could it ask for the datum transform before getting to the summary page? the summary page still lists the +dx +dy +dz proj4 terms which will not be used.

I agree this would be better. It will take some reprogramming of how the wizard works.

• text line for datum transform option # 1 overflows the right edge of the window (..."(May not be optimum for older [chop]")

Long standing problem. There should be horizontal scroll bars. I've never figured out why they don't show up. There are some tricky list formatting issues. I'll see what can be done. You can resize the list columns as a workaround.

• "Datums (select to see descriptions)" - nitpicky: It should probably be "Transform Parameters:" not "Datums:".

Easy

• could the transform pulldown list be by +proj4 term instead of by number? The number is internals which doesn't need to be exposed.

Probably easy to do and it makes sense. I just lifted some existing code. This can be improved.

Suggest adding '+' to the start of the proj4 term.

I don't understand. Could you explain.

Michael

thanks, Hamish

[cmbarton]

Replying to hamish:

there is still some work to be done I'm afraid.. a g.setproj session should give some guidance.

for other projections it is not asking all it needs to. e.g. LCC, TMerc never asks for lat_0, lon_0, etc.

Could you explain?

see general/g.setproj/proj-parms.table for a list of questions which need to be asked (or are hardwired) for a given projection.

I'll take a look. I want to try and fix the prior issues first.

Michael

(see proj-desc.table to convert those to +proj4 terms)

the wizard should also probably ask what units you want (see proj-units.table)

Hamish

[cmbarton]

• could it ask for the datum transform before getting to the summary page? the summary page still lists the +dx +dy +dz proj4 terms which will not be used.

Question, is there any harm in including +dx=0 +dy=0 terms when other information about transforms is also included? The reason is that the proj4 string is being built by accretion of information out of the datums.table and ellipse.table, and then any datum transforms are being included using the datatrans= argument for g.proj.

So does +dx=0, etc. need to be filtered out?

Michael

[cmbarton]

A further question about g.proj.

If I enter g.proj proj4='+proj=utm +zone=12 +datum=nad27' datatrans=-1

I get a list of potential datum transforms to pick from.

If I enter g.proj proj4='+proj=utm +zone=12 +ellps=clark66' datatrans=-1 (or ellipse parameters instead of clark66)

I do not get a list of transforms. Is this because...

1) transforms are not needed if an ellipse is specified 2) there is a bug in g.proj 3) something else also needs to be specified to trigger the list of transforms?

Michael

[hamish]

This was a kind of quick fix just to see if it is doing the right stuff.

yup

• trying to make a UTM location:

{{ Traceback (most recent call last):

fixed in devbr6

Suggest adding '+' to the start of the proj4 term.

I don't understand. Could you explain.

currently line 2 in the transform descr looks like "towgs84=...." or "nadgrids=..." more familiar would be "+towgs84=..." or "+nadgrids=..."

there is still some work to be done I'm afraid.. a g.setproj session should give some guidance. for other projections it is not asking all it needs to. e.g. LCC, TMerc never asks for lat_0, lon_0, etc.

Could you explain?

e.g. for transverse Mercator projection you need to set up the central meridian (lon_0) for the projection and false eastings (x_0) and false northings (y_0). Currently the wizard doesn't ask you these essential terms and leaves them unset.

what needs to be asked, their types, and default values can be found in the $GISBASE/etc/proj-parms.table file(s).

I'll take a look. I want to try and fix the prior issues first.

ok, one thing at a time..

Question, is there any harm in including +dx=0 +dy=0 terms when other information about transforms is also included?

probably, even if we get away with it today, in the future it could cause problems. The 3-term +towgs84=dx,dy,dz so having +dx,+dy,+dz as well just makes it a matter of programmer's chance as to which is used. also for others in datum.table there is dx=99999, which will probably mean something to g.proj.

The reason is that the proj4 string is being built by accretion of information out of the datums.table and ellipse.table, and then any datum transforms are being included using the datatrans= argument for g.proj.

So does +dx=0, etc. need to be filtered out?

yes, I think it does.

If I enter g.proj proj4='+proj=utm +zone=12 +datum=nad27' datatrans=-1 I get a list of potential datum transforms to pick from. If I enter g.proj proj4='+proj=utm +zone=12 +ellps=clark66' datatrans=-1 (or ellipse parameters instead of clark66) I do not get a list of transforms. Is this because...

1) transforms are not needed if an ellipse is specified

yes. these are datum transform opts. no datum, no transform.

a datum (in grass) consists of an ellipsoid (shape of the Earth) and some notion about where there center of that spheroid sits in space (ie where is the center of the planet, what to call 0,0,0). The +towgs84 params or grid file gives the translational (and for 7-term, rotational) differences relative to WGS84's axes-anchor position.

I don't think this affects GRASS (except for m.proj), but see also ​http://trac.osgeo.org/proj/wiki/FAQ#WhydoIgetdifferentresultswith4.5.0and4.6.0

see also "proj -le" and "proj -ld"

Hamish

[cmbarton]

I've committed some more enhancements/fixes to datum transforms in r39492. Please test and see if they hold up.

I'm not sure what to do about the stuff in the proj_desc.table and proj_parms.table. Is any of this built into PROJ4 nowadays? Or does it all have to be set manually still?

In any case, I'll need to look into this further to see how these tables are parsed.

Michael

[hamish]

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

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.

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.

.

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.

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

[cmbarton]

Replying to 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

[cmbarton]

Hmmm.

May have spoken too soon about the summary page. I don't see a way for it to reflect the data transform information. See below. GRASS 6.5.svn (Spearfish60_test):~ > g.proj proj4='+proj=utm +zone=12 +datum=nad27' -j +proj=utm +no_defs +zone=12 +a=6378206.4 +rf=294.9786982 +towgs84=-22.000,157.000,176.000 +to_meter=1

GRASS 6.5.svn (Spearfish60_test):~ > g.proj proj4='+proj=utm +zone=12 +datum=nad27' datumtrans=2 -j +proj=utm +no_defs +zone=12 +a=6378206.4 +rf=294.9786982 +nadgrids=/Applications/Grass/GRASS-6.5.app/Contents/MacOS/etc/nad/conus +to_meter=1

[hamish]

Replying to hamish:

Can it be integrated as a page of the wizard instead of a popup? (radio buttons?)

Replying to cmbarton:

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.

I'm just talking about the parsing and cosmetics of a GUI; the underlying code would still use datumtrans=-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.

right, this returns nothing:

g.proj proj4='+proj=utm +zone=12 +datum=wgs84' datumtrans=-1

and yet in g.setproj(.c) it asks you to confirm. Shrug, it's an issue for g.proj & there are more important priorities right now.

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.

also note the "datum stuff doesn't make it to the PROJ_INFO file again" comment. (ie end result does not have datum set)

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.

try setting tmerc as the projection.

If I create a location with a LCC, an NAD83 datum, and the proper transforms is it wrong?

in so far as it is incomplete. it may(?) default to center on 0 lat, 0 lon, but no guarantees and that's probably not what you want anyway.

Or is it just that you can get somewhat different projections that might better meet particular needs by also specifying other parameters?

as an analogy the projection class is like a class of lens. For some "brand name" ones the values are hard coded, but for many others you also have to define optical parameters of it. It's not enough just to say "bifocals". And then you also have to specify where on the globe your magnifying glass will look at/center on. (the datum is unrelated and says what shape that globe is and where it floats in space)

If it creates a geodetically incorrect location, this is very serious.

This is the case, in so far as the defaults have a 99% chance of not being what the user wants and right now there is no way of changing them.

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.

to make a truly awful car analogy: it's like a car without a steering wheel. You can technically still drive it but it probably won't go where you want it to.

Hamish

[hamish]

Replying to cmbarton:

Hmmm.

May have spoken too soon about the summary page. I don't see a way for it to reflect the data transform information. See below.

GRASS 6.5.svn (Spearfish60_test):~ > g.proj proj4='+proj=utm +zone=12 +datum=nad27' -j

...

+towgs84=-22.000,157.000,176.000

GRASS 6.5.svn (Spearfish60_test):~ > g.proj proj4='+proj=utm +zone=12 +datum=nad27' datumtrans=2 -j

...

+nadgrids=/Applications/Grass/GRASS-6.5.app/Contents/MacOS/etc/nad/conus

??, in the second case the datum transform is defined to be # 2, and the default 3-term +towgs84 transform parameter is correctly replaced by the Continental US grid file. What's the problem?

Hamish

[cmbarton]

I think I've got this all fixed now. r39554 is a major enhancement and fix. All projection parameters now selectable by user. Summary page shows g.proj output after passing PROJ4 parameters or EPSG code through it (i.e., what will show up in GRASS in the new location with g.proj -j). Note that this is different from the PROJ4 parameters used to create the location. Selecting a State Plane projection will bring up a warning box instructing user to use EPSG or custom PROJ4 string. Also fixed a number of minor and a few major bugs.

Please test and let me know if it does the trick (or if there are any hidden bugs that I missed). If all is well, we can close this ticket and port this to trunk and release_branch.

Michael

[hamish]

just trying it out.. almost there.

• for hardcoded "noask" values could the text boxes be greyed out? (e.g. NZMG, Lat/Lon's +lat_0,+lon_0 [could that 0,0 for LL just be removed from proj-parms.table?])

• "datum :" does not get set in resulting PROJ_INFO file (#784) if selecting terms manually. This was fixed for a short time last week & then broke again a few days ago. (try running g.region -p) Creation using EPSG code works.

• Expand boolean from N/Y to No/Yes. e.g. UTM Southern Hemisphere question the default is "N" which can also be "North". Better yet: figure out how to have it be 'Hemisphere: North|South'

• For UTM, could 1-60 pulldown list be a constrained value spinbox instead?

• 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. Better yet: could it have a radio button list like the Tcl/Tk version (try EPSG:27200). Also same as the Tcl version it should have a "continue without" option as well.

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

• "Choose EPSG code" search is still a bit weird (need to reload to start a new search)

thanks, Hamish

[cmbarton]

Replying to hamish:

just trying it out.. almost there.

Thanks for testing so quickly.

• for hardcoded "noask" values could the text boxes be greyed out?
  

Yes. Easy

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

• "datum :" does not get set in resulting PROJ_INFO file (#784) if selecting terms manually. This was fixed for a short time last week & then broke again a few days ago. (try running g.region -p) Creation using EPSG code works.
  

This is a g.proj issue

• 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. So I can make the change, but I'm not sure that this helps. IIRC, g.setproj uses y/n.

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, but the idea is to not have to change the interface if the underlying module and table contents change.

• 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? I could just make it an open text control, but the choicebox ensures that a legal value is chosen.

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

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), but they seem easier to read in the vertical format. If most people like the paragraph format, it is easy enough to do.

Style wise, it matches similar kinds of list controls in the wizard.

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.

Also same as the Tcl version it should have a "continue without" option as well.

Good point, we need a default "0" transformation. Easy enough to do.

• 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. Not hard to do, but will require rewiring things that look for it in 2nd place.

• "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

Glad it's getting closer.

Michael

[hamish]

Replying to 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

[cmbarton]

r39568 addresses some of the interface issues raised above. Parameters that are not editable are greyed out. A "0" no transforms selection added to datum transforms list. Datum description in 3rd place so that it has more room in the list presented to the user. EPSG searching is simplified to work like other searches: searching searches all fields automatically; entering nothing and pressing return brings back the entire list.

Since all this is working reasonably well and the remaining issues are interface ones rather than creating bad locations, I will backport this to trunk and try to merge it into release branch.

I'll leave this open because there are still a few interface questions and there is the datum problem in #784.

Michael

[cmbarton]

Replying to hamish:

Replying to 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

[hamish]

is it possible to make the default option transform option 1 not 0?

[cmbarton]

Replying to hamish:

is it possible to make the default option transform option 1 not 0?

Fixed in develbranch_6 (r39584) and trunk (r39583).

Michael

[cmbarton]

UTM Zone entry is now a SpinCtrl with entry constrained to 0-60. Boolean parameter entries changed to Yes/No (from Y/N). Develbranch_6 r39591 and Trunk r39592.

Michael

[cmbarton]

In releasebranch_6_4 r39600, I updated RB with all the fixes and enhancements of develbranch_6 r39480, r39492, r39554, r39568, r39576, r39584, and r39591. These could not be backported because the code was so far out of sync between develbranch_6 and releasebranch. Now the location wizard works correctly in 6.4 too. If any further fixes are needed, backporting with modification should easier now I hope.

Perhaps we can now close this or change it to enhancements (I hope).

Michael

[cmbarton]

I haven't heard any issues come up since all the fixing. So I'm changing this to fixed.

[hamish]

I've retested the bullet points of Oct 18th, they have all been successfully addressed. The location creation wizard now officially rocks.

(as long as you already know your county's correct state plane code, otherwise you have to run the old text based Q&A. that's a todo for another ticket :)

reopening bug for this:

• UTM spinbox: only lets you choose zone 0! (also, there is no zone 0, it starts at 1) ​http://www.dmap.co.uk/utmworld.htm

• weirdness: I see "final proj4 string" in its own popup window both before and after the final summary page. probably just left over debugging code.. (set by choosing from lists, ​proj:nzmg datum:nzgd49, datum terms:any) that "final proj4 string" isn't necessarily what you chose (eg no datum still shows +towgs84=), but in spite of that the location does end up with the correct terms, so ... ?

• also weird, if I choose no datum transform opts, 'g.proj -j' will invent them at the terminal prompt. shrug. (not a wxgui bug, PROJ_INFO is fine)

• perhaps OTT but to emphasize the point: consider adding a second layer of "ok, but are you really sure? type in the phrase 'Yes, I am.'___" when you choose to delete an entire location or even mapset containing data. It's way too easy to mindlessly click the wrong button after a long day of field work.

thanks, Hamish

[cmbarton]

Thanks much for testing this. Once finals grading is over (or if I need to take a break from grading), I should be able to knock out the 2 remaining issues in short order.

Michael

[cmbarton]

This is kind of weird. I just checked in the code I updated and recompiled tonight. The spin control works fine on my Mac. It starts at 30 (midway between 1 and 60) and easily spins both ways.

You were right about debugging code in 6.5 and 7. I removed it. It was not there in 6.4. Can you update and check this? See if the spin control is still stuck? I think I'm using very basic and generic controls here.

Thanks Michael

[hamish]

Replying to cmbarton:

This is kind of weird. I just checked in the code I updated and recompiled tonight. The spin control works fine on my Mac. It starts at 30 (midway between 1 and 60) and easily spins both ways.

...

Can you update and check this? See if the spin control is still stuck? I think I'm using very basic and generic controls here.

yup, still stuck. I just updated the min utm zone so now it is stuck at 1 not zero.

I added a debug message, val.isdigit() is failing L730 hence the reset and it not allowing me to go on. I tried to print 'val' to the terminal but it came back empty (?)

Hamish

[cmbarton]

I'm guessing that your platform implementation of SpinCtrl is not working as it is supposed to. Could you 1) find out the version of wxPython you have and 2) tell me what platform this is stuck on?

I'm guessing that some alternate code--perhaps old-style syntax--will solve this. The easiest thing will be for me to try an alternative and send you a code snippet to insert and try in your binary. It will only be 2-3 lines.

Michael

[hamish]

Replying to cmbarton:

I'm guessing that your platform implementation of SpinCtrl is not working as it is supposed to. Could you 1) find out the version of wxPython you have

$ dpkg -l | grep wx
ii  libwxbase2.6-0                               2.6.3.2.2-3+lenny1         wxBase library (runtime) - non-GUI support classes of wxWidgets 
ii  libwxbase2.8-0                               2.8.7.1-1.1+lenny1         wxBase library (runtime) - non-GUI support classes of wxWidgets 
ii  libwxbase2.8-dev                             2.8.7.1-1.1+lenny1         wxBase library (development) - non-GUI support classes of wxWidg
ii  libwxgtk2.6-0                                2.6.3.2.2-3+lenny1         wxWidgets Cross-platform C++ GUI toolkit (GTK+ runtime)
ii  libwxgtk2.8-0                                2.8.7.1-1.1+lenny1         wxWidgets Cross-platform C++ GUI toolkit (GTK+ runtime)
ii  libwxgtk2.8-dev                              2.8.7.1-1.1+lenny1         wxWidgets Cross-platform C++ GUI toolkit (GTK+ development)
ii  python-wxgtk2.8                              2.8.7.1-1.1+lenny1         wxWidgets Cross-platform C++ GUI toolkit (wxPython binding)
ii  python-wxversion                             2.6.3.2.2-3+lenny1         wxWidgets Cross-platform C++ GUI toolkit (wxPython version selec
ii  wx2.8-headers

an unrelated error message which just popped up shows:

File "/usr/lib/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_controls.py"

and 2) tell me what platform this is stuck on?

Stable Debian/GNU/Linux (Lenny) on AMD64.

(as such I wouldn't worry about the extra 2.6 libs there)

I'm guessing that some alternate code--perhaps old-style syntax--will solve this. The easiest thing will be for me to try an alternative and send you a code snippet to insert and try in your binary. It will only be 2-3 lines.

sure, happy to.

Hamish