[GRASS-dev] g.rp

[Hamish]

> > Hamish wrote:
> >>> Idea:
> > The whole idea is to made g.proj fully non-interactive and leave
> > that to the GUI.
..
> > This would print a GUI parsable list of options: (or error if bad
> > epsg code) g.proj epsg=#### datumtrans=0
> > or
> > g.proj epsg=#### datumtrans=list

Paul:
> Yes it's starting to make more sense now when you put it like that. 
> Although as Glynn said maybe the GUI should be reading the
> datumtransform tables itself,

I would think it better to pass that through a g.* module.
* It's cleaner to abstract it/consolidate it out of the GUI.
* The epsg file the GUI is using might not exactly match the version
  GRASS is using. (eg --with-proj-share= only is for GUI startup)

> although again it has no way of telling from the EPSG code what the
> associated datum is. Even I am not sure how it does it. Some magic
> inside the OGR library I think.

FWIW, NZ Map Grid's entry reads as follows:

# NZGD49 / New Zealand Map Grid
<27200> +proj=nzmg +lat_0=-41 +lon_0=173 +x_0=2510000 +y_0=6023150
+ellps=intl +datum=nzgd49 +units=m +no_defs  <>

That says nothing about how to convert to the nzgd49 datum. We give
three options: 7 parm, 3 parm, or NTv2 distortion grid.
Nothing in the EPSG file using the NZ 1949 datum does:

/usr/share/proj$ grep nzgd49 epsg | grep '+towgs84='
/usr/share/proj$ 


> I still worry a little that it depends too much on the existing
> structure of support for datum transform parameters within GRASS.
> Michael made an interesting point that perhaps the EPSG database
> contains some sets of paramters.

Not in the NZ case anyway...

> But even if it does, we can't guarantee that they're correct or
> complete or best. The whole point of the EPSG database is (from it's
> name) petroleum survey, I presume. Which means it would be more likely
> to include datum paramters useful for oilfield areas etc.?

IIRC from the past Frank/Gerald/Clifford posts on the proj4 mailing
list, the list is maintained for the benefit of people drilling holes in
the ground. The horizontal distance error incurred by differing datum
transform parms is probably only academic to that crowd, and updated
to more "correct" values as a service to the rest of us. Similar to
projections originally developed by military sources only being accurate
enough to direct artillery fire, where errors of less than a meter
aren't important.

> I don't know if it does contain paramters, nor how to extract them. I
> would guess though that it doesn't use PROJ.4 syntax, nor contain New
> Zealand Map Grid tables or Canadian NTv2 tables etc. the way GRASS
> does.

IIUC, every now and then Frank pulls the database and runs some scripts
to convert EPSG DB format (wkt??) to PROJ4 format and create the various
/usr/share/proj/epsg files. The script is obviously pretty good, but
it isn't totally foolproof and IIUC has some hardcoded "fixes" built in.
Then Markus does some magic and updates grass6/lib/proj/ellipsoid.csv,
gcs.csv, gdal_datum.csv, projop_wparm.csv, unit_of_measure.csv,
stateplane.csv from Frank's new PROJ4 CVS version.
 
> I think a solution acceptable to everyone is gradually forming over
> time.  This is what I hoped would happen!
> 
> > if there is only one item on the list the GUI would automatically
> > run with that, "datumtrans=1" would be the default answer:
> >  g.proj -c loc=newLoc epsg=####
> 
> Actually the function GPJ_get_default_datum_params_by_name() in 
> lib/proj/datum.c returns a "default", which for various reasons is 
> actually the last in the list...

As long as there is some hinting, we can make the rest happen in code.
It shouldn't be too hard to reindex the list. (he says not having looked
at the code :)

> > If multiple options the GUI would create a dialog from the list,
> > then create the new location with:
> > g.proj -c loc=newLoc epsg=#### datumtrans=2
> > or
> > g.proj -c loc=newLoc epsg=#### datumtrans=conus   # ???
> >
> > Not sure if it should take text "list,conus,etc".
> > Probably that is unneeded pain. Aliasing "list" to "0" would be nice
> 
> Yes I see where you're coming from, I think. If the first item in the
> list was the default anyway this would work out nicely. Maybe
> omitting the datumtrans option could mean use the default instead of
> datumtrans=1?

Well my idea was put the default first and when combined with
->answer="1" it happens automatically. I'd prefer to use the parser to
pick the default answer rather than it happen somewhere inside the black
box, but it guess it doesn't have to.

My main goal was that the default parm should be the default option,
regardless of order. The easiest way to have that happen is to call it
"1" and have parm->answer="1" in the option's parser def'n, after making
sure the default parm comes first.

> I think a solution acceptable to everyone is gradually forming over
> time. This is what I hoped would happen!

It would be nice. I guess another thing missing is region setting
code to replace E_edit_cellhd(). More g.proj -c options?
 region=n,s,e,w
 nsres=
 ewres=

Also we need to have a replacement GUI top-down location creation method
(pick type, then projection, then datum), vs the bottom-up EPSG code way.

Maybe a g.listproj module that would give existing type, SP, proj lists
from lib fns in a CSV or other GUI parsable format?
e.g. this would call a non-paged version of lib/gis/get_projname.c:
g.listproj type=projections
 or
g.listproj type=state_plane
 ??

I have no idea how to handle the more complicated stuff like setting
custom ellipsoids in g.setproj.


Hamish