[GRASS-dev] [bug #5454] (grass) projection units incorrectly pluralized

[H_B]

Michael Barton wrote:

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

(it's location= not "epsgloc=")

I have no idea about tcl and little idea about system calls, so I'll
just run through the logic and hope it is easy to translate into tcl.

First pass once the user selects an EPSG code is to find datum transform
parms. -c and location=$name are not needed at this point.

# e.g., an EPSG code with 3 options (and 0 = "none")

G63> g.proj epsg=27200 datumtrans=-1 2> /dev/null
---
1
Used in whole nzgd49 region
towgs84=54.400,-20.100,183.100
Default 3-Parameter Transformation (May not be optimum for older datums; use this only if no more appropriate options are available.)
---
2
Used in New Zealand
nadgrids=nzgd2kgrid0005.gsb
LINZ NZGD49 NTv2 Distortion Model, accuracy 10-30cm
---
3
Used in New Zealand
towgs84=59.47,-5.04,187.44,0.47,-0.1,1.024,-4.5993
Accuracy approx. 4m

The default will always come first.

Each record is 5 lines in stdout,
1 ---
2 #
3 text: where it's used
4 text: proj4 parms
5 text: comment

from general/g.proj/datumtrans.c:

fprintf(stdout, "---\n%d\nUsed in %s\n%s\n%s\n",
  list->count, list->where_used,
  list->params, list->comment);

That's what you have to parse.

Here is what that looks likes if there are no options:
(ie the EPSG code already specified them)

G63> g.proj epsg=2193 datumtrans=-1
G63> echo $?
0

So if the first pass "g.proj epsg=#### datumtrans=-1" exits
successfully, but sends nothing to stdout, you can go straight to:

g.proj -c location=$name epsg=####

and you're done.

If you put in a bad EPSG code you get this:

G63> g.proj epsg=99999 datumtrans=-1
ERROR 6: EPSG PCS/GCS code 99999 not found in EPSG support files. Is this a valid EPSG coordinate system?
ERROR: Can't parse PROJ.4-style parameter string
G63> echo $?
1

which you can pick up from the non-zero exit code.

Back to the case that needs to be parsed:
If there is option text you need to create a dialog window from the
options, as well as a "0: leave unspecified" option at the bottom.
Then once the user has selected something from that,
g.proj -c location=$name epsg=#### datumtrans=$number

and you're done.

make sense?

Hamish

[cmbarton]

Thanks Hamish. This is very helpful. When is this available to write the
wrapper for?

Michael

On 2/13/07 2:42 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:

Michael Barton wrote:

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

(it's location= not "epsgloc=")

I have no idea about tcl and little idea about system calls, so I'll
just run through the logic and hope it is easy to translate into tcl.

First pass once the user selects an EPSG code is to find datum transform
parms. -c and location=$name are not needed at this point.

# e.g., an EPSG code with 3 options (and 0 = "none")

G63> g.proj epsg=27200 datumtrans=-1 2> /dev/null
---
1
Used in whole nzgd49 region
towgs84=54.400,-20.100,183.100
Default 3-Parameter Transformation (May not be optimum for older datums; use
this only if no more appropriate options are available.)
---
2
Used in New Zealand
nadgrids=nzgd2kgrid0005.gsb
LINZ NZGD49 NTv2 Distortion Model, accuracy 10-30cm
---
3
Used in New Zealand
towgs84=59.47,-5.04,187.44,0.47,-0.1,1.024,-4.5993
Accuracy approx. 4m

The default will always come first.

Each record is 5 lines in stdout,
1 ---
2 #
3 text: where it's used
4 text: proj4 parms
5 text: comment

from general/g.proj/datumtrans.c:

fprintf(stdout, "---\n%d\nUsed in %s\n%s\n%s\n",
list->count, list->where_used,
list->params, list->comment);

That's what you have to parse.

Here is what that looks likes if there are no options:
(ie the EPSG code already specified them)

G63> g.proj epsg=2193 datumtrans=-1
G63> echo $?
0

So if the first pass "g.proj epsg=#### datumtrans=-1" exits
successfully, but sends nothing to stdout, you can go straight to:

g.proj -c location=$name epsg=####

and you're done.

If you put in a bad EPSG code you get this:

G63> g.proj epsg=99999 datumtrans=-1
ERROR 6: EPSG PCS/GCS code 99999 not found in EPSG support files. Is this a
valid EPSG coordinate system?
ERROR: Can't parse PROJ.4-style parameter string
G63> echo $?
1

which you can pick up from the non-zero exit code.

Back to the case that needs to be parsed:
If there is option text you need to create a dialog window from the
options, as well as a "0: leave unspecified" option at the bottom.
Then once the user has selected something from that,
g.proj -c location=$name epsg=#### datumtrans=$number

and you're done.

make sense?

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

[H_B]

H:

> First pass once the user selects an EPSG code is to find datum
> transform parms. -c and location=$name are not needed at this point.

..

> from general/g.proj/datumtrans.c:
>
> fprintf(stdout, "---\n%d\nUsed in %s\n%s\n%s\n",
> list->count, list->where_used,
> list->params, list->comment);
>
> That's what you have to parse.

Michael wrote:

Thanks Hamish. This is very helpful. When is this available to write
the wrapper for?

Now. Paul put it in CVS yesterday.

Hamish

[cmbarton]

Trying to rebuild with current cvs version now. If successful, I can see
what I can do with this over the next few days. I also need to do some
things with wx.Python too.

Michael

On 2/13/07 4:43 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:

H:

First pass once the user selects an EPSG code is to find datum
transform parms. -c and location=$name are not needed at this point.

..

from general/g.proj/datumtrans.c:

fprintf(stdout, "---\n%d\nUsed in %s\n%s\n%s\n",
list->count, list->where_used,
list->params, list->comment);

That's what you have to parse.

Michael wrote:

Thanks Hamish. This is very helpful. When is this available to write
the wrapper for?

Now. Paul put it in CVS yesterday.

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

[Paul_Kelly]

On Tue, 13 Feb 2007, Hamish wrote:

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.

Well the way it is is consistent with how it worked before. If the datum information was complete, g.proj did what you told it, if not it prompted for more info. Now if you use the -i flag you can still get this old behaviour, or if you specify datumtrans=xxx

I can see logic in datumtrans=-1 always listing even if there is just one option, but I still think the current way is better as it is most consistent with pre-existing behaviour... If you want it to always list anyway you can use the -t "force transformation selection" flag?

Not sure what's best really

Paul

[H_B]

Hamish wrote:
>> 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.

Paul:

Well the way it is is consistent with how it worked before. If the
datum information was complete, g.proj did what you told it, if not
it prompted for more info. Now if you use the -i flag you can still
get this old behaviour, or if you specify datumtrans=xxx

I can see logic in datumtrans=-1 always listing even if there is just
one option, but I still think the current way is better as it is most
consistent with pre-existing behaviour... If you want it to always
list anyway you can use the -t "force transformation selection" flag?

Not sure what's best really

As we didn't have datumtrans= before, we really would just be preserving
the awkward style of how it functioned, not exact usage. Adding the new
options is an oportunity to smooth out any anomalies in the process...
?

I'm still trying to come to grips with how the result of -t differs
from datumtrans=0 ("none"). ie why datumtrans=0 doesn't imply -t.
That also touches on why datumtr=0 should be the default and not =1?
Sorry if that makes no sense. Is there a case where EPSG defines
datum parms and datumtransform.table defines more?

example?

Hamish

[Paul_Kelly]

Hello Hamish
Been thinking a bit more about this. (Sorry for my silence on most stuff; have had really sporadic internet access for the last week...)

On Tue, 13 Feb 2007, Hamish wrote:

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.

My thinking in implementing the datumtrans and -i options has to be to do it as generally as possible, i.e. not with the case of creating a new location (from the GUI or otherwise) specifically in mind.

The way it is programmed now is that the value of datumtrans is checked if and only if the input co-ordinate system contains partial/ambiguous datum information (unless -t flag is used). If (datumtrans == -1) was always to be checked in any case, then if the input projection doesn't contain any datum info at all the behaviour would technically be undefined IMO. Would that have to be programmed in as a special case? I think the current behaviour is logical, though agree it is questionable and that it's possible I could come to look at differently and change my mind.

[...]

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.

This comes from the library function. I haven't touched it at all and it needs tidied up. Probably remove the interactive flag as Glynn has suggested. Or even allow it to accept a number to indicate which datum parameters to use directly. That might be useful actually. r.in.gdal and v.in.ogr also use the library function so their behaviour needs to be considered too.

Paul