[GRASS-dev] Creating location from file problem

Markus_Neteler1 · October 20, 2006, 8:46am

Hi,

together with Helena I tried to create new location from a file,
it fails if a datum should be asked:

1. Create new location from a file -
I put the file at:
http://skagit.meas.ncsu.edu/~helena/grasswork/grassbookdat/gdc.zip

When selecting the SHAPE file, the procedure in
lib/init/file_option.tcl
calls g.proj. In this case, it wants to query the user for the
datum, but for that it has to be run in the xterm wrapper which
isn't the case yet.

I tried
diff -u -r1.5 file_option.tcl
--- file_option.tcl 19 Oct 2006 12:03:48 -0000 1.5
+++ file_option.tcl 20 Oct 2006 08:45:28 -0000
@@ -114,8 +114,7 @@
                        if {[file exists $filepath]== 1} {
                                if {[file exists $thelocation ]==0} {
                                        destroy .fileloc;
- exec -- g.proj -c georef=$filepath location=$fileLocation >@stdout 2>@stderr;
- destroy .fileloc
+ exec -- $env(GISBASE)/etc/grass-xterm-wrapper -e g.proj -c georef=$filepath location=$fileLocation;
                                        DialogGen .wrnDlg [G_msg "WARNING: restart GRASS please"] warning \
                                        [G_msg "WARNING: Please restart GRASS in order find the created location in the list (closing it for you now)"] \
                                                0 OK;

but the xterm window only flashes, then closes.

How to do it right?

Markus

Glynn_Clements1 · October 20, 2006, 12:02pm

Markus Neteler wrote:

together with Helena I tried to create new location from a file,
it fails if a datum should be asked:

> 1. Create new location from a file -
> I put the file at:
> http://skagit.meas.ncsu.edu/~helena/grasswork/grassbookdat/gdc.zip

When selecting the SHAPE file, the procedure in
lib/init/file_option.tcl
calls g.proj. In this case, it wants to query the user for the
datum, but for that it has to be run in the xterm wrapper which
isn't the case yet.

I tried
diff -u -r1.5 file_option.tcl
--- file_option.tcl 19 Oct 2006 12:03:48 -0000 1.5
+++ file_option.tcl 20 Oct 2006 08:45:28 -0000
@@ -114,8 +114,7 @@
                        if {[file exists $filepath]== 1} {
                                if {[file exists $thelocation ]==0} {
                                        destroy .fileloc;
- exec -- g.proj -c georef=$filepath location=$fileLocation >@stdout 2>@stderr;
- destroy .fileloc
+ exec -- $env(GISBASE)/etc/grass-xterm-wrapper -e g.proj -c georef=$filepath location=$fileLocation;
                                        DialogGen .wrnDlg [G_msg "WARNING: restart GRASS please"] warning \
                                        [G_msg "WARNING: Please restart GRASS in order find the created location in the list (closing it for you now)"] \
                                                0 OK;

but the xterm window only flashes, then closes.

How to do it right?

1. Any GRASS program run in an xterm needs to use grass-run.sh, e.g.:

exec -- $env(GISBASE)/etc/grass-xterm-wrapper -e $env(GISBASE)/etc/grass-run.sh g.proj ...

You should probably also use "-T g.proj -n g.proj" to set the title
back (otherwise it will be "grass-run.sh", which isn't particularly
informative).

2. Those semicolons shouldn't be there; I don't know if they will have
any adverse effect, but they are unnecessary.

3. The xterm will close as soon as the command completes (whether it
succeeds or fails). You can use the -hold switch to retain the xterm
window after the command completes, but you should only do that for
debugging; having to manually close the xterm window each time would
be annoying in normal use. Alternatively, redirect stdout/stderr to a
file, to catch any error messages.

--
Glynn Clements <glynn@gclements.plus.com>

Markus_Neteler1 · October 20, 2006, 12:36pm

On Fri, Oct 20, 2006 at 01:02:44PM +0100, Glynn Clements wrote:

Markus Neteler wrote:

> together with Helena I tried to create new location from a file,
> it fails if a datum should be asked:
>
> > 1. Create new location from a file -
> > I put the file at:
> > http://skagit.meas.ncsu.edu/~helena/grasswork/grassbookdat/gdc.zip
>
> When selecting the SHAPE file, the procedure in
> lib/init/file_option.tcl
> calls g.proj. In this case, it wants to query the user for the
> datum, but for that it has to be run in the xterm wrapper which
> isn't the case yet.
>
> I tried
> diff -u -r1.5 file_option.tcl
> --- file_option.tcl 19 Oct 2006 12:03:48 -0000 1.5
> +++ file_option.tcl 20 Oct 2006 08:45:28 -0000
> @@ -114,8 +114,7 @@
> if {[file exists $filepath]== 1} {
> if {[file exists $thelocation ]==0} {
> destroy .fileloc;
> - exec -- g.proj -c georef=$filepath location=$fileLocation >@stdout 2>@stderr;
> - destroy .fileloc
> + exec -- $env(GISBASE)/etc/grass-xterm-wrapper -e g.proj -c georef=$filepath location=$fileLocation;
> DialogGen .wrnDlg [G_msg "WARNING: restart GRASS please"] warning \
> [G_msg "WARNING: Please restart GRASS in order find the created location in the list (closing it for you now)"] \
> 0 OK;
>
> but the xterm window only flashes, then closes.
>
> How to do it right?

1. Any GRASS program run in an xterm needs to use grass-run.sh, e.g.:

exec -- $env(GISBASE)/etc/grass-xterm-wrapper -e $env(GISBASE)/etc/grass-run.sh g.proj ...

You should probably also use "-T g.proj -n g.proj" to set the title
back (otherwise it will be "grass-run.sh", which isn't particularly
informative).

2. Those semicolons shouldn't be there; I don't know if they will have
any adverse effect, but they are unnecessary.

3. The xterm will close as soon as the command completes (whether it
succeeds or fails). You can use the -hold switch to retain the xterm
window after the command completes, but you should only do that for
debugging; having to manually close the xterm window each time would
be annoying in normal use. Alternatively, redirect stdout/stderr to a
file, to catch any error messages.

Very nice, it now works and is fixed in 6.3 and 6.2-release branch.

Thanks for the quick help!
Markus

Helena_Mitasova · October 20, 2006, 6:05pm

Here is another problem that we have found for starting a new location and it applies
to g.setproj and the creation of new location from projection values:

when I enter stp (State Plane) for projection it gives an ERROR that says that stp is
not specified in the table (although it is listed and it used to work and in lib/gis/projections it is defined.)

Was this removed? It used to ask for datum and FIPS codes. It is one of the most common projections
in US so it would be good to put it back. It works in GRASS61 from february

Thanks Helena

Markus_Neteler1 · October 21, 2006, 11:47am

Hi,

concerning the State Plane (STP) problem, here the error message:

g.setproj

Please specify projection name
Enter 'list' for the list of available projections
Hit RETURN to cancel request

stp

ERROR: Projection stp is not specified in the table

Using a debugger, I found that (the new)
$GISBASE/etc/proj-parms.table
is analyzed by get_proj_parms() in lib/proj.c. Since STP
isn't listed there, it fails with

if (!proj_parms)
G_fatal_error("Projection %s is not specified in the table", proj_out);

The parameters to query for STP are
- geodetic datum (e.g. nad27)
- State FIPS
- County FIPS for selected state
- State Plane 1927 or 1983
- units (US survey Foot, Int. Foot, meter)

I don't know how to add that in $GISBASE/etc/proj-parms.table
nor if and why STP disappeared from GRASS 6.2/6.3.
The code seems to be in general/g.setproj/get_stp.c .
It seems that it just exits too early in general/g.setproj/main.c .

Markus

On Fri, Oct 20, 2006 at 02:05:23PM -0400, Helena Mitasova wrote:

Here is another problem that we have found for starting a new
location and it applies
to g.setproj and the creation of new location from projection values:

> when I enter stp (State Plane) for projection it gives an ERROR
>that says that stp is
>not specified in the table (although it is listed and it used to
>work and in lib/gis/projections it is defined.)
Was this removed? It used to ask for datum and FIPS codes. It is one
of the most common projections
in US so it would be good to put it back. It works in GRASS61 from
february

Thanks Helena

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

--
Markus Neteler <neteler itc it> http://mpa.itc.it/markus/
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy

Huidae_Cho · October 21, 2006, 6:30pm

This problem occurs also with Lat-Long (LL), so I had to create a new
location with "g.proj -c". When "grass -text" creates a new LL
location, it says that the user needs to run g.setproj to properly use
any projection related modules, but it fails because LL is missing from
proj-parms.table. This is certainly not a good experience for new
users.

Huidae

On Sat, Oct 21, 2006 at 01:47:10PM +0200, Markus Neteler wrote:

Hi,

concerning the State Plane (STP) problem, here the error message:

g.setproj

Please specify projection name
Enter 'list' for the list of available projections
Hit RETURN to cancel request
>stp
ERROR: Projection stp is not specified in the table

Using a debugger, I found that (the new)
$GISBASE/etc/proj-parms.table
is analyzed by get_proj_parms() in lib/proj.c. Since STP
isn't listed there, it fails with

if (!proj_parms)
G_fatal_error("Projection %s is not specified in the table", proj_out);

The parameters to query for STP are
- geodetic datum (e.g. nad27)
- State FIPS
- County FIPS for selected state
- State Plane 1927 or 1983
- units (US survey Foot, Int. Foot, meter)

I don't know how to add that in $GISBASE/etc/proj-parms.table
nor if and why STP disappeared from GRASS 6.2/6.3.
The code seems to be in general/g.setproj/get_stp.c .
It seems that it just exits too early in general/g.setproj/main.c .

Markus

On Fri, Oct 20, 2006 at 02:05:23PM -0400, Helena Mitasova wrote:
> Here is another problem that we have found for starting a new
> location and it applies
> to g.setproj and the creation of new location from projection values:
>
> > when I enter stp (State Plane) for projection it gives an ERROR
> >that says that stp is
> >not specified in the table (although it is listed and it used to
> >work and in lib/gis/projections it is defined.)
> Was this removed? It used to ask for datum and FIPS codes. It is one
> of the most common projections
> in US so it would be good to put it back. It works in GRASS61 from
> february
>
> Thanks Helena
>
>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev

--
Markus Neteler <neteler itc it> http://mpa.itc.it/markus/
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

Markus_Neteler1 · October 22, 2006, 8:26am

Hi,

I *think* that I have fixed it (applied to CVS):

Index: proj-parms.table

RCS file: /grassrepository/grass6/general/g.setproj/proj-parms.table,v
retrieving revision 2.1
diff -u -r2.1 proj-parms.table
--- proj-parms.table 1 Oct 2006 21:18:05 -0000 2.1
+++ proj-parms.table 22 Oct 2006 08:19:18 -0000
@@ -48,6 +48,7 @@
LCC:LAT0=ask,23.0;LAT1=ask,33.0;LAT2=ask,45.0;LON0=ask,-96.0;X0=ask,0.0;Y0=ask,0.0
LEAC:LAT0=ask,55.0;LAT1=ask,0.0;LON0=ask,20.0;SOUTH=ask,nodfl
LEE_OS:LAT0=noask,-10.0;LON0=noask,-165.0
+LL:LAT0=noask,0.0;LON0=noask,0.0
LOXIM:LAT0=ask,0.0;LAT1=ask,45.0;LON0=ask,20.0
LSAT:LAT0=ask,0.0;LON0=ask,20.0;SNUM=ask,1;SPATH=ask,1
MBTFPP:LAT0=ask,0.0;LON0=ask,20.0
@@ -91,6 +92,7 @@
SINU:LAT0=ask,0.0;LON0=ask,20.0
SOMERC:KFACT=noask,1.0;LAT0=noask,46.952405556;LON0=noask,7.4395833333;X0=noask,600000.0;Y0=noask,200000.0
STERE:KFACT=ask,1.0;LAT0=ask,0.0;LATTS=ask,0.0;LON0=ask,20.0
+STP:LAT0=noask,0.0;LON0=noask,0.0
TCC:LAT0=ask,0.0;LON0=ask,20.0
TCEA:KFACT=ask,1.0;LAT0=ask,0.0;LON0=ask,20.0
TISSOT:LAT0=ask,0.0;LAT1=ask,-30.0;LAT2=ask,45.0;LON0=ask,20.0

Please test it (STP and LL).

I have also 'indent'ed main.c of g.setproj. A few compiler warnings are
still there.

Markus

On Sat, Oct 21, 2006 at 01:30:56PM -0500, Huidae Cho wrote:

This problem occurs also with Lat-Long (LL), so I had to create a new
location with "g.proj -c". When "grass -text" creates a new LL
location, it says that the user needs to run g.setproj to properly use
any projection related modules, but it fails because LL is missing from
proj-parms.table. This is certainly not a good experience for new
users.

Huidae

On Sat, Oct 21, 2006 at 01:47:10PM +0200, Markus Neteler wrote:
> Hi,
>
> concerning the State Plane (STP) problem, here the error message:
>
> g.setproj
>
> Please specify projection name
> Enter 'list' for the list of available projections
> Hit RETURN to cancel request
> >stp
> ERROR: Projection stp is not specified in the table
>
> Using a debugger, I found that (the new)
> $GISBASE/etc/proj-parms.table
> is analyzed by get_proj_parms() in lib/proj.c. Since STP
> isn't listed there, it fails with
>
> if (!proj_parms)
> G_fatal_error("Projection %s is not specified in the table", proj_out);
>
> The parameters to query for STP are
> - geodetic datum (e.g. nad27)
> - State FIPS
> - County FIPS for selected state
> - State Plane 1927 or 1983
> - units (US survey Foot, Int. Foot, meter)
>
> I don't know how to add that in $GISBASE/etc/proj-parms.table
> nor if and why STP disappeared from GRASS 6.2/6.3.
> The code seems to be in general/g.setproj/get_stp.c .
> It seems that it just exits too early in general/g.setproj/main.c .
>
> Markus
>
> On Fri, Oct 20, 2006 at 02:05:23PM -0400, Helena Mitasova wrote:
> > Here is another problem that we have found for starting a new
> > location and it applies
> > to g.setproj and the creation of new location from projection values:
> >
> > > when I enter stp (State Plane) for projection it gives an ERROR
> > >that says that stp is
> > >not specified in the table (although it is listed and it used to
> > >work and in lib/gis/projections it is defined.)
> > Was this removed? It used to ask for datum and FIPS codes. It is one
> > of the most common projections
> > in US so it would be good to put it back. It works in GRASS61 from
> > february
> >
> > Thanks Helena
> >
> >
> >
> > _______________________________________________
> > grass-dev mailing list
> > grass-dev@grass.itc.it
> > http://grass.itc.it/mailman/listinfo/grass-dev
>
> --
> Markus Neteler <neteler itc it> http://mpa.itc.it/markus/
> ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
> MPBA - Predictive Models for Biol. & Environ. Data Analysis
> Via Sommarive, 18 - 38050 Povo (Trento), Italy
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

--
Markus Neteler <neteler itc it> http://mpa.itc.it/markus/
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy

H_B · October 23, 2006, 3:13am

Glynn Clements wrote:

1. Any GRASS program run in an xterm needs to use grass-run.sh, e.g.:

..

3. The xterm will close as soon as the command completes (whether it
succeeds or fails). You can use the -hold switch to retain the xterm
window after the command completes, but you should only do that for
debugging; having to manually close the xterm window each time would
be annoying in normal use. Alternatively, redirect stdout/stderr to a
file, to catch any error messages.

grass-run.sh does:

# run command
"$@"

EXIT_VAL=$?
if [ $EXIT_VAL -ne 0 ] ; then
   echo -e "\r"
   echo "ERROR: $1 exited abnormally. Press <enter> to continue."
   read
fi

exit $EXIT_VAL

so it should pause on exit, and the #1 suggestion above should solve
more than one problem.

Hamish

H_B · October 23, 2006, 3:16am

Markus Neteler wrote:

I *think* that I have fixed it (applied to CVS):

Index: proj-parms.table

RCS file: /grassrepository/grass6/general/g.setproj/proj-parms.table,v

..

+LL:LAT0=noask,0.0;LON0=noask,0.0

..

+STP:LAT0=noask,0.0;LON0=noask,0.0

..

Please test it (STP and LL).

I have also 'indent'ed main.c of g.setproj. A few compiler warnings
are still there.

what other ones could be missing? (or another way, why were these two
missed?)

Hamish

Markus_Neteler1 · October 23, 2006, 8:29am

On Mon, Oct 23, 2006 at 04:16:52PM +1300, Hamish wrote:

Markus Neteler wrote:
> I *think* that I have fixed it (applied to CVS):
>
> Index: proj-parms.table
> ===================================================================
> RCS file: /grassrepository/grass6/general/g.setproj/proj-parms.table,v
..
> +LL:LAT0=noask,0.0;LON0=noask,0.0
..
> +STP:LAT0=noask,0.0;LON0=noask,0.0
..
>
> Please test it (STP and LL).
>
> I have also 'indent'ed main.c of g.setproj. A few compiler warnings
> are still there.

what other ones could be missing?

I have compared to the GRASS 5 projection list: missing are
- krovak
- krovakgis
- vitk1

PROJ 4.5.x contains new support for krovak, so this could
be the occasion to re-introduce it in GRASS 6.

(or another way, why were these two missed?)

I dunno - maybe an oversight? Glynn will know more.

Markus

Morten_Hulden2 · October 23, 2006, 1:36pm

Markus Neteler wrote:

On Mon, Oct 23, 2006 at 04:16:52PM +1300, Hamish wrote:

Markus Neteler wrote:

I *think* that I have fixed it (applied to CVS):

Index: proj-parms.table

RCS file: /grassrepository/grass6/general/g.setproj/proj-parms.table,v

..

+LL:LAT0=noask,0.0;LON0=noask,0.0

..

+STP:LAT0=noask,0.0;LON0=noask,0.0

..

Please test it (STP and LL).

I have also 'indent'ed main.c of g.setproj. A few compiler warnings
are still there.

what other ones could be missing?

I have compared to the GRASS 5 projection list: missing are
- krovak
- krovakgis
- vitk1

Since proj 4.4.9 there is also support for alternative parameters for lcc (lcca) and stere (sterea) as separate projections, and for geos, Geostationary Satellite View.

PROJ 4.5.x contains new support for krovak, so this could
be the occasion to re-introduce it in GRASS 6.

(or another way, why were these two missed?)

Historical explanation: g.setproj originally only supported a few projections, (XY), LL, UTM, STP. The setup code for these was different from the projections added later. The old setup code for LL, UTM and STP was retained in order not to mess up working code while experimentally adding support for 118 additional projections supported by proj. Since STP already had working setup code it was not included in geo_init.c, the file containing parameters for the new projections. Thus, when Glynn converted geo_init.c to proj-parms.table he may have overlooked STP.

Morten

Glynn_Clements1 · October 23, 2006, 3:51pm

Markus Neteler wrote:

> > Index: proj-parms.table
> > ===================================================================
> > RCS file: /grassrepository/grass6/general/g.setproj/proj-parms.table,v
> ..
> > +LL:LAT0=noask,0.0;LON0=noask,0.0
> ..
> > +STP:LAT0=noask,0.0;LON0=noask,0.0
> ..
> >
> > Please test it (STP and LL).
> >
> > I have also 'indent'ed main.c of g.setproj. A few compiler warnings
> > are still there.
>
>
> what other ones could be missing?

I have compared to the GRASS 5 projection list: missing are
- krovak
- krovakgis
- vitk1

PROJ 4.5.x contains new support for krovak, so this could
be the occasion to re-introduce it in GRASS 6.

The tables only included the projections which were already handled in
G_geo_init_table() (that was the source for the tables).

> (or another way, why were these two missed?)

I dunno - maybe an oversight? Glynn will know more.

Those didn't occur in G_geo_init_table(), presumably because g.setproj
handled them as special cases. Actually, I'm surprised that UTM is in
there.

--
Glynn Clements <glynn@gclements.plus.com>