I have fixed the "foots" bug now; see
http://grass.itc.it/pipermail/grass-commit/2007-January/026497.html
I will commit a temporary solution to the GUI freezing problem (changing
g.proj so it won't prompt for the datum info unless you ask it to be
interactive) shortly.
-------------------------------------------- Managed by Request Tracker
Thanks very much Paul. This will ameliorate a problem that is especially
disconcerting to users in that it generate no error messages.
Michael
On 2/2/07 10:23 AM, "Paul Kelly via RT" <grass-bugs@intevation.de> wrote:
I have fixed the "foots" bug now; see
http://grass.itc.it/pipermail/grass-commit/2007-January/026497.html
I will commit a temporary solution to the GUI freezing problem (changing
g.proj so it won't prompt for the datum info unless you ask it to be
interactive) shortly.-------------------------------------------- Managed by Request Tracker
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
Paul Kelly via RT wrote:
I have fixed the "foots" bug now; see
http://grass.itc.it/pipermail/grass-commit/2007-January/026497.html
I will commit a temporary solution to the GUI freezing problem
(changing g.proj so it won't prompt for the datum info unless you ask
it to be interactive) shortly.
Idea:
It would create a new epsg=code[,n] option:
g.proj -c location=newLocation epsg=####
It would exit with EXIT_FAILURE if the datum transform parm is ambiguous.
Here's the cunning part:
"epsg=####,n" would pick param 1,2,3,.. from the list.
"epsg=####,0" would print available options to stdout and exit with an
EXIT_SUCCESS return code. If the EPSG code isn't found, it exits with
EXIT_FAILURE. The output is in CSV or a parsable format a GUI could read
& make into a nice GUI popup. Maybe with a header comment line for humans.
In the GUI:
- user selects create new location with EPSG code $EPSG.
- gui runs "catch `g.proj epsg=$EPSG` > /dev/null"
- If exit code is 0, gui creates new location with:
"g.proj -c location=$LOCATION epsg=$EPSG"
- If exit code is 1, gui runs:
"g.proj epsg=$EPSG,0" then parses the output and creates a new
GUI popup with radiobutton options generated from that. (see d.menu)
(If it fails again, EPSG code is bad)
Once a parm is selected and [Create] is clicked, the popup runs
"g.proj -c location=$LOCATION epsg=$EPSG,$N"
IMO this would be many many times better than forcing a value (you
wouldn't even know better transform parms exist), and isn't a huge
amount to code.
Hamish
I haven't thought through all the implications, but on the face of it this
sounds like a reasonable solution. If implemented, hopefully it would be
able to run without lockup (succeed or fail with warning) with the current
TclTk scripts until the GUI could be re-written for this.
On 2/5/07 12:06 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:
Paul Kelly via RT wrote:
I have fixed the "foots" bug now; see
http://grass.itc.it/pipermail/grass-commit/2007-January/026497.html
I will commit a temporary solution to the GUI freezing problem
(changing g.proj so it won't prompt for the datum info unless you ask
it to be interactive) shortly.Idea:
It would create a new epsg=code[,n] option:
g.proj -c location=newLocation epsg=####
It would exit with EXIT_FAILURE if the datum transform parm is ambiguous.
Here's the cunning part:
"epsg=####,n" would pick param 1,2,3,.. from the list.
"epsg=####,0" would print available options to stdout and exit with an
EXIT_SUCCESS return code. If the EPSG code isn't found, it exits with
EXIT_FAILURE. The output is in CSV or a parsable format a GUI could read
& make into a nice GUI popup. Maybe with a header comment line for humans.In the GUI:
- user selects create new location with EPSG code $EPSG.- gui runs "catch `g.proj epsg=$EPSG` > /dev/null"
- If exit code is 0, gui creates new location with:
"g.proj -c location=$LOCATION epsg=$EPSG"- If exit code is 1, gui runs:
"g.proj epsg=$EPSG,0" then parses the output and creates a new
GUI popup with radiobutton options generated from that. (see d.menu)
(If it fails again, EPSG code is bad)Once a parm is selected and [Create] is clicked, the popup runs
"g.proj -c location=$LOCATION epsg=$EPSG,$N"IMO this would be many many times better than forcing a value (you
wouldn't even know better transform parms exist), and isn't a huge
amount to code.Hamish
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
Hamish wrote:
> Idea:
>
> It would create a new epsg=code[,n] option:
>
> g.proj -c location=newLocation epsg=####
>
> It would exit with EXIT_FAILURE if the datum transform parm is ambiguous.
>
> Here's the cunning part:
>
> "epsg=####,n" would pick param 1,2,3,.. from the list.
>
> "epsg=####,0" would print available options to stdout and exit with an
> EXIT_SUCCESS return code. If the EPSG code isn't found, it exits with
> EXIT_FAILURE. The output is in CSV or a parsable format a GUI could read
> & make into a nice GUI popup. Maybe with a header comment line for humans.
>
> In the GUI:
> - user selects create new location with EPSG code $EPSG.
>
> - gui runs "catch `g.proj epsg=$EPSG` > /dev/null"
>
> - If exit code is 0, gui creates new location with:
> "g.proj -c location=$LOCATION epsg=$EPSG"
>
> - If exit code is 1, gui runs:
> "g.proj epsg=$EPSG,0" then parses the output and creates a new
> GUI popup with radiobutton options generated from that. (see d.menu)
> (If it fails again, EPSG code is bad)
>
> Once a parm is selected and [Create] is clicked, the popup runs
> "g.proj -c location=$LOCATION epsg=$EPSG,$N"
>
>
> IMO this would be many many times better than forcing a value (you
> wouldn't even know better transform parms exist), and isn't a huge
> amount to code.
Michael:
I haven't thought through all the implications, but on the face of it this
sounds like a reasonable solution. If implemented, hopefully it would be
able to run without lockup (succeed or fail with warning) with the current
TclTk scripts until the GUI could be re-written for this.
The whole idea is to made g.proj fully non-interactive and leave that to the
GUI.
I guess instead of epsg=####[,n] the [,n] part should go in a datumtrans=
option as it could apply to georef=,wkt=,proj4= as well.
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
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=####
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
but wouldn't get past parser checks for TYPE_INTEGER and
parm->options="0-100";.
Hamish
On Tue, 6 Feb 2007, Hamish wrote:
Hamish wrote:
Idea:
It would create a new epsg=code[,n] option:
g.proj -c location=newLocation epsg=####
It would exit with EXIT_FAILURE if the datum transform parm is ambiguous.
Here's the cunning part:
"epsg=####,n" would pick param 1,2,3,.. from the list.
"epsg=####,0" would print available options to stdout and exit with an
EXIT_SUCCESS return code. If the EPSG code isn't found, it exits with
EXIT_FAILURE. The output is in CSV or a parsable format a GUI could read
& make into a nice GUI popup. Maybe with a header comment line for humans.In the GUI:
- user selects create new location with EPSG code $EPSG.- gui runs "catch `g.proj epsg=$EPSG` > /dev/null"
- If exit code is 0, gui creates new location with:
"g.proj -c location=$LOCATION epsg=$EPSG"- If exit code is 1, gui runs:
"g.proj epsg=$EPSG,0" then parses the output and creates a new
GUI popup with radiobutton options generated from that. (see d.menu)
(If it fails again, EPSG code is bad)Once a parm is selected and [Create] is clicked, the popup runs
"g.proj -c location=$LOCATION epsg=$EPSG,$N"IMO this would be many many times better than forcing a value (you
wouldn't even know better transform parms exist), and isn't a huge
amount to code.Michael:
I haven't thought through all the implications, but on the face of it this
sounds like a reasonable solution. If implemented, hopefully it would be
able to run without lockup (succeed or fail with warning) with the current
TclTk scripts until the GUI could be re-written for this.The whole idea is to made g.proj fully non-interactive and leave that to the
GUI.I guess instead of epsg=####[,n] the [,n] part should go in a datumtrans=
option as it could apply to georef=,wkt=,proj4= as well.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
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, 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.
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. 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.? 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.
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...
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?
Paul
but wouldn't get past parser checks for TYPE_INTEGER and
parm->options="0-100";.Hamish
_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev
> 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 niceYes 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
Paul Kelly wrote:
> 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=listYes 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, 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.
My guess is from some combination of the CSV/WKT files in
/usr/[local/]share/gdal.
Some of the entries in the EPSG file have explicit +datum= options,
but most don't.
Ultimately, I don't think that replicating the OSR stuff within the
GUI is a viable option; we need a utility that gets this information
from GDAL.
--
Glynn Clements <glynn@gclements.plus.com>
On Wed, 7 Feb 2007, Hamish wrote:
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
No not hard at all. In fact I have just changed it. The original thinking was that since the "default" parameters were unlikely to be optimum it made sense to put them at the end of the list so the user didn't consider them a good default choice. But it isn't that important especially since we've added the more informative comment about being unlikely to be optimum.
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 niceYes 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.
Yes that is very neat, I agree (and have changed the order of the list as mentioned above).
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=
I think I would prefer Helena's solution of adding a flag to g.region to allow it to set the default region. The GUI could then call g.region on the new location (after updating .grassrc) following its creation with g.proj.
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
??
If the way the new datumtrans flag works for g.proj is a success it could probably be done in a very similar way, using library functions in lib/proj/ellipse.c and lib/proj/datum.c to read the system ellipsoid and datum tables. Maybe - I haven't really thought it through. Might get a bit out of hand.
Paul
Paul Kelly wrote:
The original thinking was that since the "default" parameters were
unlikely to be optimum it made sense to put them at the end of the
list so the user didn't consider them a good default choice. But it
isn't that important especially since we've added the more
informative comment about being unlikely to be optimum.
Hmm. Is the default based on logic or is it just picked as the first
listed in the file, or something like that? If it is random we can
keep the code simpler. Keeping the first entry as default means that the
datumtrans= option (and thus GUI) can be skipped in the case there is
only one option.
H:
> It would be nice. I guess another thing missing is region setting
> code to replace E_edit_cellhd(). More g.proj -c options?
P:
I think I would prefer Helena's solution of adding a flag to g.region
to allow it to set the default region. The GUI could then call
g.region on the new location (after updating .grassrc) following its
creation with g.proj.
Yes, that's better.
The new location would have to be created and switched into before
running g.region in PERMANENT, and then the GUI wizard would take you
on to creating a user mapset before switching into that and launching
a new GRASS session.
If the way the new datumtrans flag works for g.proj is a success it
could probably be done in a very similar way, using library functions
in lib/proj/ellipse.c and lib/proj/datum.c to read the system
ellipsoid and datum tables. Maybe - I haven't really thought it
through. Might get a bit out of hand.
Well, we can get the epsg= and datumtrans= options working, and then
worry about those issues- maybe we will learn some along the way.
It may be that g.proj is not the best place to put a top-down chooser
and we'd need a new module "g.newlocation" or something?
Hamish
I have now added new epsg= and datumtrans= options to g.proj in CVS.
The epsg= option to create new location by EPSG code is fully
functional: (it just plugs the code into a PROJ4 format string)
G63> g.proj -c loc=newlocNZTM epsg=2193
Location newlocNZTM created!
If it needs more info WRT datum transform options, it currently goes
interactive as the datumtrans= option to list or select datum transform
parms is not yet functional. Paul, can you try and connect this to
get_datum_transform_by_name() and GPJ_ask_datum_params(), or wherever
the number needs to get to? Mucho gracias.
I guess we can ignore custom transform parms, they can be specified
using the proj4= option.
Hamish
Hamish and Paul,
I've followed this closely and tried to save relevant emails, but it's been
a bit complicated. I've been trying to put aside TclTk and work on the
wx.Python GUI, but this seems important to do in the existing TclTk
interface.
Any chance you could briefly summarize how g.proj now works (or will work)
with these changes so that I can try to update the TclTk interface for this?
Michael
On 2/7/07 9:28 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:
Paul Kelly wrote:
The original thinking was that since the "default" parameters were
unlikely to be optimum it made sense to put them at the end of the
list so the user didn't consider them a good default choice. But it
isn't that important especially since we've added the more
informative comment about being unlikely to be optimum.Hmm. Is the default based on logic or is it just picked as the first
listed in the file, or something like that? If it is random we can
keep the code simpler. Keeping the first entry as default means that the
datumtrans= option (and thus GUI) can be skipped in the case there is
only one option.H:
It would be nice. I guess another thing missing is region setting
code to replace E_edit_cellhd(). More g.proj -c options?P:
I think I would prefer Helena's solution of adding a flag to g.region
to allow it to set the default region. The GUI could then call
g.region on the new location (after updating .grassrc) following its
creation with g.proj.Yes, that's better.
The new location would have to be created and switched into before
running g.region in PERMANENT, and then the GUI wizard would take you
on to creating a user mapset before switching into that and launching
a new GRASS session.If the way the new datumtrans flag works for g.proj is a success it
could probably be done in a very similar way, using library functions
in lib/proj/ellipse.c and lib/proj/datum.c to read the system
ellipsoid and datum tables. Maybe - I haven't really thought it
through. Might get a bit out of hand.Well, we can get the epsg= and datumtrans= options working, and then
worry about those issues- maybe we will learn some along the way.
It may be that g.proj is not the best place to put a top-down chooser
and we'd need a new module "g.newlocation" or something?Hamish
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
Michael Barton wrote:
I've followed this closely and tried to save relevant emails, but it's
been a bit complicated. I've been trying to put aside TclTk and work
on the wx.Python GUI, but this seems important to do in the existing
TclTk interface.Any chance you could briefly summarize how g.proj now works (or will
work) with these changes so that I can try to update the TclTk
interface for this?
The non-interactive datum parm bit isn't ready yet, so no TclTk changes
to worry about right now.
This is ready:
g.proj -c proj4=+init=epsg:$epsg_code location=$epsgLocation
can now be:
g.proj -c epsg=$epsg_code location=$epsgLocation
But you will still get prompted for transform parms if needed.
Once the datumtrans= list + selection option is working there will be
some TclTk'ing required to take advantage of that.
Hamish
Hello Hamish
On Thu, 8 Feb 2007, Hamish wrote:
I have now added new epsg= and datumtrans= options to g.proj in CVS.
The epsg= option to create new location by EPSG code is fully
functional: (it just plugs the code into a PROJ4 format string)G63> g.proj -c loc=newlocNZTM epsg=2193
Location newlocNZTM created!If it needs more info WRT datum transform options, it currently goes
interactive as the datumtrans= option to list or select datum transform
parms is not yet functional. Paul, can you try and connect this to
get_datum_transform_by_name() and GPJ_ask_datum_params(), or wherever
the number needs to get to? Mucho gracias.
I have this working now in my local copy, but just realised a slight flaw with it. Because we are assuming a default of datumtrans=1, there is no way to assume if the user specifically asked for the 1st set of datum transformation parameters, or they are just using the default. Up to now, if the user didn't specifically specify datum transformation parameters, they were not written into the PROJ_INFO, only the datum name. When necessary then (e.g. using one of the re-projection modules), the current default parameters for that datum would be read from the datum.table file and used. So if the default changed (e.g. we discovered it was wrong and updated it) the user wouldn't need to edit their location to take advantage of the update. But if the parameters are written into the PROJ_INFO, then whatever default was in force at the time becomes set in stone.
The logic in a few parts of the GRASS gproj library also uses the presence/absence of specific transformation parameters in the PROJ_INFO as an indicator of how likely any parameters present are to be correct/appropriate for the location.
E.g. when writing an output WKT file, GRASS always puts the datum name in, but only adds TOWGS84 parameters if they were specifically specified in the PROJ_INFO. Again, the logic is that the parameters had been specifically specified so there was a good chance they were correct and there was no harm promulgating them on. But if the user had just accepted the default parameters, then we're not so sure if they're appropriate for the specific area of the data, so just put the datum name in and whoever receives the export data can use their own initiative in choosing appropriate parameters.
With this new functionality however, we are always assuming the user specified datumtrans=xxx, so the parameters are always written in.
I'm not sure what to do about this, whether it's nothing to worry about or not.
Also, I was wondering what format would be appropriate for the GUI-parsable list of datum transformation parameters. In the copy I have I'm just printing to stdout the list that you got by typing list at the old interactive prompt. Are there any existing examples of something similar I wonder.
Paul
Hamish wrote:
> I have now added new epsg= and datumtrans= options to g.proj in CVS.
..
> If it needs more info WRT datum transform options, it currently goes
> interactive as the datumtrans= option to list or select datum
> transform parms is not yet functional. Paul, can you try and connect
> this to get_datum_transform_by_name() and GPJ_ask_datum_params(), or
> wherever the number needs to get to? Mucho gracias.
Paul wrote:
I have this working now in my local copy,
Great.
but just realised a slight flaw with it. Because we are assuming a
default of datumtrans=1, there is no way to assume if the user
specifically asked for the 1st set of datum transformation parameters,
or they are just using the default. Up to now, if the user didn't
specifically specify datum transformation parameters, they were not
written into the PROJ_INFO, only the datum name.
ok, so how about:
datumtrans=-1 # write the list (including a "none" option) and exit
datumtrans=0 # no datum specified
datumtrans=1 # default
datumtrans=2,.. # add'l options
datumtrans=1 remains the default, but if multiple options exist, load
the picker. Or do we always want to open the picker to allow ="none",
even when there is only one option?
So after it gets a EPSG code it creates a new loc'n in two passes. The
first time it runs with datumtrans=-1 to get the list, and the second it
runs with the user specified answer. If the only option is "none" (eg
epsg already specifies +towgs84=, as with NZTM <2193>) it skips the
second pass (GUI picker) and directly creates the loc'n.
When necessary then (e.g. using one of the re-projection modules), the
current default parameters for that datum would be read from the
datum.table file and used. So if the default changed (e.g. we
discovered it was wrong and updated it) the user wouldn't need to edit
their location to take advantage of the update. But if the parameters
are written into the PROJ_INFO, then whatever default was in force at
the time becomes set in stone.
That makes sense. the above datumtrans="none" suggestion would keep that
the same.
I'm not sure what to do about this, whether it's nothing to worry
about or not.
Worrying is good, as downstream effects of this decision will directly
affect the data. (eg WKT .prj export imported into something else)
Also, I was wondering what format would be appropriate for the
GUI-parsable list of datum transformation parameters. In the copy I
have I'm just printing to stdout the list that you got by typing list
at the old interactive prompt. Are there any existing examples of
something similar I wonder.
The GUI needs to be able to transform it into a radio button list
somehow. I guess it could just search for the existing "^---$" text
to separate entries and re-use the existing formatting of the
individual entries. Also it would be nice if it could pre-select the
default option when the GUI picker is opened.
If it must be broken up into fields, "|" doesn't appear in the epsg
file, lib/gis/datum.table, nor lib/gis/datumtransform.table so could be
used as a field separator. It would be nice for the list to be human-
readable if called from the command line. Or is the current output
structured enough to rely on '^---$' and '\n' for that?
Will the default always be what's in "datum.table"? ie the default is
always the 3-term +towgs84=dx,dy,dz parms?
outstanding issue: allow these datumtrans= word aliases?
list => -1
none => 0
default => 1
# bonus:
three_term => a
seven_term => b
Hamish
Hello Hamish
On Mon, 12 Feb 2007, Hamish wrote:
ok, so how about:
datumtrans=-1 # write the list (including a "none" option) and exit
datumtrans=0 # no datum specified
datumtrans=1 # default
datumtrans=2,.. # add'l optionsdatumtrans=1 remains the default, but if multiple options exist, load
the picker. Or do we always want to open the picker to allow ="none",
even when there is only one option?
If there is only one, normally the parameters aren't specifically specifed. If they are for some reason, I've added a "force" flag (-t, for force setting Transformation parameters :/) that can be used to update the parameters even if they are already complete. E.g. you can use
g.proj -ct datumtrans=0 to remove specified parameters from the PROJ_INFO and in future the default will be used. So that was clear thinking on the 0 = unspecified
So after it gets a EPSG code it creates a new loc'n in two passes. The
first time it runs with datumtrans=-1 to get the list, and the second it
runs with the user specified answer. If the only option is "none" (eg
epsg already specifies +towgs84=, as with NZTM <2193>) it skips the
second pass (GUI picker) and directly creates the loc'n.
Yes. With datumtrans=-1 the location will get created straight away if there is only one parameter set to choose from (unless you use the force flag). The GUI could watch the output of g.proj and if it specifed the list then go through it for the second pass.
Also, I was wondering what format would be appropriate for the
GUI-parsable list of datum transformation parameters. In the copy I
have I'm just printing to stdout the list that you got by typing list
at the old interactive prompt. Are there any existing examples of
something similar I wonder.The GUI needs to be able to transform it into a radio button list
somehow. I guess it could just search for the existing "^---$" text
to separate entries and re-use the existing formatting of the
individual entries. Also it would be nice if it could pre-select the
I edited it a little bit to make it hopefully more parser-friendly - one item of info per line and no tabs at the start.
default option when the GUI picker is opened.
If it must be broken up into fields, "|" doesn't appear in the epsg
file, lib/gis/datum.table, nor lib/gis/datumtransform.table so could be
used as a field separator. It would be nice for the list to be human-
readable if called from the command line. Or is the current output
structured enough to rely on '^---$' and '\n' for that?
Yes it's still human readable.
Will the default always be what's in "datum.table"? ie the default is
always the 3-term +towgs84=dx,dy,dz parms?
If there is one, yes. If dx=dy=dz=9999 then the first entry for the datum in datumtransform.table will be the default.
outstanding issue: allow these datumtrans= word aliases?
list => -1
none => 0
default => 1
We could, yes. We are not really gaining a lot to rely on the parser to validate the numbers I think.
# bonus:
three_term => a
seven_term => b
Very hard. It's currently abstracted to be just a "PROJ-4 compatible set of parameters" and doesn't really look at what's inside them anywhere.
Anyway, here's the description of the new functionality from the man page:
If the input co-ordinate system contains a datum name but no transformation parameters, and there is more than one suitable parameter set available (according to the files datum.table and datumtransform.table in ${GISBASE}/etc), g.proj will check the value of the datumtrans option and act according to the following:
-1: List available parameter sets in a GUI-parsable (but also human-readable) format and exit.
0 (default): Continue without specifying parameters - if used when creating a location, other GRASS modules will use the "default" (likely non-optimum) parameters for this datum if necessary in the future.
Any other number less than or equal to the number of parameter sets available for this datum: Choose this parameter set and add it to the co-ordinate system description.
If the module is being used from the command-line through an interactive terminal, the -i flag can be specified to enable interactive selection of the parameter set, and the value of datumtrans (if specified) is ignored.
If the -t flag is specified, the module will attempt to change the datum transformation parameters using one of the above two methods even if a valid parameter set is already specified in the input co-ordinate system.
I may not have time to get back to this for a few days as will be travelling a bit, but might do anyway.
Paul
I'm continuing to follow this discussion and I don't think it will be a huge
problem to wrap this into TclTk. The simplest way for TclTk to parse this is
to simply have each datum transformation be a separate line in text sent to
stdout.
1:dt1 parameters
2:dt2 parameters
3:dt3 parameters
...and so on
The way I'm thinking of doing this is to open a read channel from the
command as follows...
set input [open "|g.proj epsg=$epsgcode epsgloc=$epsgloc datumtrans=-1"]
set dtrans [read $input]
close $input
if {$dtrans==""} {
# I assume that $dtrans=="" if there is only one default parameter
open "|g.proj epsg=$epsgcode epsgloc=$epsgloc datumtrans=0"
else {
# do some kind of selection dialog here where the user
# picks the desired datum transformation from the list in
# dtrans and "set dtsel [integer of user datum trans selection]"
open "|g.proj epsg=$epsgcode epsgloc=$epsgloc datumtrans=$dtsel"
}
Is this what you also have in mind???
Michael
On 2/12/07 10:26 AM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:
Hello Hamish
On Mon, 12 Feb 2007, Hamish wrote:
ok, so how about:
datumtrans=-1 # write the list (including a "none" option) and exit
datumtrans=0 # no datum specified
datumtrans=1 # default
datumtrans=2,.. # add'l optionsdatumtrans=1 remains the default, but if multiple options exist, load
the picker. Or do we always want to open the picker to allow ="none",
even when there is only one option?If there is only one, normally the parameters aren't specifically
specifed. If they are for some reason, I've added a "force" flag (-t, for
force setting Transformation parameters :/) that can be used to update the
parameters even if they are already complete. E.g. you can use
g.proj -ct datumtrans=0 to remove specified parameters from the PROJ_INFO
and in future the default will be used. So that was clear thinking on the
0 = unspecifiedSo after it gets a EPSG code it creates a new loc'n in two passes. The
first time it runs with datumtrans=-1 to get the list, and the second it
runs with the user specified answer. If the only option is "none" (eg
epsg already specifies +towgs84=, as with NZTM <2193>) it skips the
second pass (GUI picker) and directly creates the loc'n.Yes. With datumtrans=-1 the location will get created straight away if
there is only one parameter set to choose from (unless you use the force
flag). The GUI could watch the output of g.proj and if it specifed the
list then go through it for the second pass.Also, I was wondering what format would be appropriate for the
GUI-parsable list of datum transformation parameters. In the copy I
have I'm just printing to stdout the list that you got by typing list
at the old interactive prompt. Are there any existing examples of
something similar I wonder.The GUI needs to be able to transform it into a radio button list
somehow. I guess it could just search for the existing "^---$" text
to separate entries and re-use the existing formatting of the
individual entries. Also it would be nice if it could pre-select theI edited it a little bit to make it hopefully more parser-friendly - one
item of info per line and no tabs at the start.default option when the GUI picker is opened.
If it must be broken up into fields, "|" doesn't appear in the epsg
file, lib/gis/datum.table, nor lib/gis/datumtransform.table so could be
used as a field separator. It would be nice for the list to be human-
readable if called from the command line. Or is the current output
structured enough to rely on '^---$' and '\n' for that?Yes it's still human readable.
Will the default always be what's in "datum.table"? ie the default is
always the 3-term +towgs84=dx,dy,dz parms?If there is one, yes. If dx=dy=dz=9999 then the first entry for the datum
in datumtransform.table will be the default.outstanding issue: allow these datumtrans= word aliases?
list => -1
none => 0
default => 1We could, yes. We are not really gaining a lot to rely on the parser to
validate the numbers I think.# bonus:
three_term => a
seven_term => bVery hard. It's currently abstracted to be just a "PROJ-4 compatible set
of parameters" and doesn't really look at what's inside them anywhere.Anyway, here's the description of the new functionality from the man page:
If the input co-ordinate system contains a datum name but no
transformation parameters, and there is more than one suitable parameter
set available (according to the files datum.table and datumtransform.table
in ${GISBASE}/etc), g.proj will check the value of the datumtrans option
and act according to the following:
-1: List available parameter sets in a GUI-parsable (but also
human-readable) format and exit.
0 (default): Continue without specifying parameters - if used when
creating a location, other GRASS modules will use the "default" (likely
non-optimum) parameters for this datum if necessary in the future.
Any other number less than or equal to the number of parameter sets
available for this datum: Choose this parameter set and add it to the
co-ordinate system description.
If the module is being used from the command-line through an interactive
terminal, the -i flag can be specified to enable interactive selection of
the parameter set, and the value of datumtrans (if specified) is ignored.
If the -t flag is specified, the module will attempt to change the datum
transformation parameters using one of the above two methods even if a
valid parameter set is already specified in the input co-ordinate system.I may not have time to get back to this for a few days as will be
travelling a bit, but might do anyway.Paul
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
On Mon, February 12, 2007 19:28, Michael Barton wrote:
I'm continuing to follow this discussion and I don't think it will be a
huge
problem to wrap this into TclTk. The simplest way for TclTk to parse this
is
to simply have each datum transformation be a separate line in text sent
to
stdout.1:dt1 parameters
2:dt2 parameters
3:dt3 parameters
...and so onThe way I'm thinking of doing this is to open a read channel from the
command as follows...set input [open "|g.proj epsg=$epsgcode epsgloc=$epsgloc datumtrans=-1"]
set dtrans [read $input]
close $input
if {$dtrans==""} {
# I assume that $dtrans=="" if there is only one default parameter
open "|g.proj epsg=$epsgcode epsgloc=$epsgloc datumtrans=0"
This means that if there is only one set of default parameters, these are
not set explicitely in PROJ_INFO. Another option would be to make this
open "|g.proj epsg=$epsgcode epsgloc=$epsgloc datumtrans=1"
to do so.
I don't know what is better. If we want to leave the choice to the user,
the GUI could offer it (maybe in form of a checkbox), or should this be
only for powerusers, and GUI users live with the default=no parameters
solution ?
Moritz
Actually, looking at this, maybe it is more correct to do the following...
# first run g.proj to see if there are more than the default parameters to
# choose from
set input [open "|g.proj epsg=$epsgcode epsgloc=$epsgloc datumtrans=-1"]
set dtrans [read $input]
close $input
if {$dtrans==""} {
# I assume that $dtrans=="" if there is only one default parameter.
# so use the default parameter.
open "|g.proj epsg=$epsgcode epsgloc=$epsgloc datumtrans=1"
else {
# do some kind of selection dialog here where the user
# picks the desired datum transformation from the list in
# dtrans and "set dtsel [integer of user datum trans selection]"
open "|g.proj epsg=$epsgcode epsgloc=$epsgloc datumtrans=$dtsel"
}
On 2/12/07 2:49 PM, "Moritz Lennert" <moritz.lennert@ulb.ac.be> wrote:
On Mon, February 12, 2007 19:28, Michael Barton wrote:
I'm continuing to follow this discussion and I don't think it will be a
huge
problem to wrap this into TclTk. The simplest way for TclTk to parse this
is
to simply have each datum transformation be a separate line in text sent
to
stdout.1:dt1 parameters
2:dt2 parameters
3:dt3 parameters
...and so onThe way I'm thinking of doing this is to open a read channel from the
command as follows...set input [open "|g.proj epsg=$epsgcode epsgloc=$epsgloc datumtrans=-1"]
set dtrans [read $input]
close $input
if {$dtrans==""} {
# I assume that $dtrans=="" if there is only one default parameter
open "|g.proj epsg=$epsgcode epsgloc=$epsgloc datumtrans=0"This means that if there is only one set of default parameters, these are
not set explicitely in PROJ_INFO. Another option would be to make thisopen "|g.proj epsg=$epsgcode epsgloc=$epsgloc datumtrans=1"
to do so.
I don't know what is better. If we want to leave the choice to the user,
the GUI could offer it (maybe in form of a checkbox), or should this be
only for powerusers, and GUI users live with the default=no parameters
solution ?Moritz
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
Hamish:
> datumtrans=1 remains the default, but if multiple options exist,
> load the picker. Or do we always want to open the picker to allow
> ="none", even when there is only one option?
Paul:
If there is only one, normally the parameters aren't specifically
specifed. If they are for some reason, I've added a "force" flag (-t,
for force setting Transformation parameters :/) that can be used to
update the parameters even if they are already complete. E.g. you can
use g.proj -ct datumtrans=0 to remove specified parameters from the
PROJ_INFO and in future the default will be used. So that was clear
thinking on the 0 = unspecified
Ok, the only thing I'd add is that we should remember the proj4=
exists for corner cases. I suppose now we have the minimum simple
AND correct solution? That is the hope anyway.
H:
> So after it gets a EPSG code it creates a new loc'n in two passes.
> The first time it runs with datumtrans=-1 to get the list, and the
> second it runs with the user specified answer. If the only option is
> "none" (eg epsg already specifies +towgs84=, as with NZTM <2193>) it
> skips the second pass (GUI picker) and directly creates the loc'n.
P:
Yes. With datumtrans=-1 the location will get created straight away if
there is only one parameter set to choose from (unless you use the
force flag). The GUI could watch the output of g.proj and if it
specifed the list then go through it for the second pass.
? The -1 "list" option should only list and exit. Not sometimes work,
sometimes not. My hope was that the GUI could see there were no options
and skip the param picker dialoge and move right on to the -c creation
step. ie datumtrans=-1 should ignore -c, otherwise it is trying to be
two orthogonal modes at the same time.
H:
> outstanding issue: allow these datumtrans= word aliases?
> list => -1
> none => 0
> default => 1
P:
We could, yes. We are not really gaining a lot to rely on the parser
to validate the numbers I think.
One of the most important things the parser brings is protection from
buffer overflows from the command line. Obviously GRASS isn't anywhere
near free from that danger, but the parser goes a long way to covering
one wide open flank.
Paul:
Anyway, here's the description of the new functionality from the man
page:If the input co-ordinate system contains a datum name but no
transformation parameters, and there is more than one suitable
parameter set available (according to the files datum.table and
datumtransform.table in ${GISBASE}/etc), g.proj will check the value
of the datumtrans option and act according to the following:
-1: List available parameter sets in a GUI-parsable (but also
human-readable) format and exit.
0 (default): Continue without specifying parameters - if used when
creating a location, other GRASS modules will use the "default"
(likely non-optimum) parameters for this datum if necessary in the
future. Any other number less than or equal to the number of parameter
sets available for this datum: Choose this parameter set and add it
to the co-ordinate system description.
If the module is being used from the command-line through an
interactive terminal, the -i flag can be specified to enable
interactive selection of the parameter set, and the value of
datumtrans (if specified) is ignored. If the -t flag is specified, the
module will attempt to change the datum transformation parameters
using one of the above two methods even if a valid parameter set is
already specified in the input co-ordinate system.
I'm pretty sure I'll be able to digest that all come morning.
I may not have time to get back to this for a few days as will be
travelling a bit, but might do anyway.
looks good so far, enjoy yourself!
minor cosmetics:
G63> g.proj -c loc=tmp_test13v2 epsg=27200 datumtrans=2
A datum name nzgd49 (New_Zealand_Geodetic_Datum_1949) was specified
without transformation parameters.
WARNING: Non-interactive mode: the GRASS default for nzgd49 is
towgs84=54.400,-20.100,183.100.
"A datum name %s (%s) was specified without transformation parameters."
is wrong.
Also, as datumtrans= was set >0, the "Warning: default is:" is just
noise and should be skipped. We don't care what the default is if
we explicitly stated a real parm.
cheers,
Hamish
