[GRASS-dev] text interface for GRASS70

Pierre_Roudier · March 22, 2011, 12:22am

Hi,

I just compiled grass7-svn (revision 45721) on my server, but I can't
initiate any mapset:

pierrer@grass:~$ grass70 -text
Unable to start GRASS. You can:
- Launch GRASS with '-gui' switch (`grass70 -gui`)
- Create manually GISRC file (/home/pierrer/.grass7/rc)
- Launch GRASS with path to the location/mapset as an argument
(`grass70 /path/to/location/mapset`)

It is a remote machine without X, so I can't really use the graphical
way. For the other options, I understand I should have a location +
mapset already on my server (which is not the case).

I could certainly copy one of my local projects on the server bu I was
wondering if that was a bug of the text interface. I understand this
is related to this bug:
http://osgeo-org.1803224.n2.nabble.com/GRASS-7-CLI-startup-td5923640.html

Cheers,

Pierre

--
Scientist
Landcare Research, New Zealand

Glynn_Clements1 · March 22, 2011, 2:38am

Pierre Roudier wrote:

I just compiled grass7-svn (revision 45721) on my server, but I can't
initiate any mapset:

pierrer@grass:~$ grass70 -text
Unable to start GRASS. You can:
- Launch GRASS with '-gui' switch (`grass70 -gui`)
- Create manually GISRC file (/home/pierrer/.grass7/rc)
- Launch GRASS with path to the location/mapset as an argument
(`grass70 /path/to/location/mapset`)

It is a remote machine without X, so I can't really use the graphical
way. For the other options, I understand I should have a location +
mapset already on my server (which is not the case).

I could certainly copy one of my local projects on the server bu I was
wondering if that was a bug of the text interface. I understand this
is related to this bug:
http://osgeo-org.1803224.n2.nabble.com/GRASS-7-CLI-startup-td5923640.html

7.0 doesn't have a curses version of database/location/mapset dialog
(or of anything else; all curses-based functionality has been
removed).

As suggested in the above message, specifying the path to an existing
mapset directory as an argument should work (but probably doesn't get
much testing). The "demolocation" location should be installed under
$GISBASE; you may be able to use that, provided that you own the
PERMANENT mapset. Once you have started GRASS, you can create a new
database/location/mapset with "g.mapset -c ...".

If you don't own the demolocation/PERMANENT directory, you can create
a copy which you do own with e.g. "cp -r ..." and use that.

Ultimately, we really need to add e.g. a "-c" flag to the grass70
script to allow the creation of a new database/location/mapset on
systems where the GUI cannot be used.

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

Pierre_Roudier · March 22, 2011, 2:56am

Thanks for your reply Glynn,

As suggested in the above message, specifying the path to an existing
mapset directory as an argument should work (but probably doesn't get
much testing). The "demolocation" location should be installed under
$GISBASE; you may be able to use that, provided that you own the
PERMANENT mapset.

As root I can open the demolocation mapset:
root@grass:/usr/local/src# grass70
/usr/local/grass-7.0.svn/demolocation/PERMANENT/

However it is impossible to do anything inside it -even create a new
mapset or consult the help:
GRASS 7.0.svn (demolocation):/usr/local/src > g.list rast,vect
ERROR: MAPSET PERMANENT - permission denied

If you don't own the demolocation/PERMANENT directory, you can create
a copy which you do own with e.g. "cp -r ..." and use that.

I tried to copy + chown the demolocation to a single user, but grass
won't start:
root@grass:/usr/local/src# cp -R ../grass-7.0.svn/demolocation/
/home/pierrer/grassdata/
root@grass:/usr/local/src# chown -R pierrer:pierrer
/home/pierrer/grassdata/demolocation/
pierrer@grass:~$ grass70 /home/pierrer/grassdata/demolocation/PERMANENT/
Traceback (most recent call last):
  File "/usr/local/bin/grass70", line 943, in <module>
    grass_intro()
  File "/usr/local/bin/grass70", line 370, in grass_intro
    f = open(path, 'r')
IOError: [Errno 2] No such file or directory:
'/home/pierrer/grassdata/etc/grass_intro'

Ultimately, we really need to add e.g. a "-c" flag to the grass70
script to allow the creation of a new database/location/mapset on
systems where the GUI cannot be used.

That'd be great!

Thanks again,

Pierre

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

--
Scientist
Landcare Research, New Zealand

Glynn_Clements1 · March 22, 2011, 6:18am

Pierre Roudier wrote:

I tried to copy + chown the demolocation to a single user, but grass
won't start:
root@grass:/usr/local/src# cp -R ../grass-7.0.svn/demolocation/
/home/pierrer/grassdata/
root@grass:/usr/local/src# chown -R pierrer:pierrer
/home/pierrer/grassdata/demolocation/
pierrer@grass:~$ grass70 /home/pierrer/grassdata/demolocation/PERMANENT/
Traceback (most recent call last):
  File "/usr/local/bin/grass70", line 943, in <module>
    grass_intro()
  File "/usr/local/bin/grass70", line 370, in grass_intro
    f = open(path, 'r')
IOError: [Errno 2] No such file or directory:
'/home/pierrer/grassdata/etc/grass_intro'

This indicates that "gisbase" is set to /home/pierrer/grassdata, which
is probably incorrect. The grass70 script uses the GISBASE environment
variable if it is set (in general, it shouldn't be), otherwise it uses
a value which is hard-coded into the grass70 script itself (line 37;
the actual value is set during "make install").

The value should be the top-level directory of the GRASS installation.

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

neteler · March 22, 2011, 8:22am

On Tue, Mar 22, 2011 at 3:38 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:

Pierre Roudier wrote:

I just compiled grass7-svn (revision 45721) on my server, but I can't
initiate any mapset:

pierrer@grass:~$ grass70 -text
Unable to start GRASS. You can:
- Launch GRASS with '-gui' switch (`grass70 -gui`)
- Create manually GISRC file (/home/pierrer/.grass7/rc)
- Launch GRASS with path to the location/mapset as an argument
(`grass70 /path/to/location/mapset`)

It is a remote machine without X, so I can't really use the graphical
way. For the other options, I understand I should have a location +
mapset already on my server (which is not the case).

I could certainly copy one of my local projects on the server bu I was
wondering if that was a bug of the text interface. I understand this
is related to this bug:
http://osgeo-org.1803224.n2.nabble.com/GRASS-7-CLI-startup-td5923640.html

7.0 doesn't have a curses version of database/location/mapset dialog
(or of anything else; all curses-based functionality has been
removed).

As suggested in the above message, specifying the path to an existing
mapset directory as an argument should work (but probably doesn't get
much testing). The "demolocation" location should be installed under
$GISBASE; you may be able to use that, provided that you own the
PERMANENT mapset. Once you have started GRASS, you can create a new
database/location/mapset with "g.mapset -c ...".

If you don't own the demolocation/PERMANENT directory, you can create
a copy which you do own with e.g. "cp -r ..." and use that.

Ultimately, we really need to add e.g. a "-c" flag to the grass70
script to allow the creation of a new database/location/mapset on
systems where the GUI cannot be used.

Here an older posting which may be useful:

On Thu, Jul 30, 2009 at 8:13 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:

Without the GUI, you currently have to create a new location manually,
e.g.:

olddbase=`g.gisenv get=GISDBASE`
g.gisenv set=GISDBASE=/path/to/database
g.proj -c location=newlocation ...
g.gisenv set=GISDBASE=$olddbase
g.mapset -c gisdbase=/path/to/database location=newlocation mapset=newmapset
g.mapset gisdbase=/path/to/database location=newlocation mapset=newmapset
g.region -d

Note that GRASS 7 includes a dummy location at $GISDBASE/demolocation;
this can be used to get into GRASS, provided that you're the owner of
the GRASS installation (probably root).

For developers:

1. init.{sh,py} need an option to create a new database/location/mapset
without using the GUI.

2. g.proj should have a database= option so that -c can create a new
database along with the location.

3. g.mapset complains if the current database/location/mapset aren't
valid; it should probably be changed to use G_no_gisinit() to handle
this.

See in Addons also "grass_create_location.sh" for this:
http://trac.osgeo.org/grass/browser/grass-addons/general/grass_create_location

(it should better be a Python script, consider above a proof
of concept)

Markus

martinl · March 22, 2011, 2:16pm

Hi,

2011/3/22 Markus Neteler <neteler@osgeo.org>:

See in Addons also "grass_create_location.sh" for this:
http://trac.osgeo.org/grass/browser/grass-addons/general/grass_create_location

(it should better be a Python script, consider above a proof
of concept)

at least we could use grass.create_location() [1] for unprojected
locations, for the rest is needed running GRASS session (`g.proj`).

Martin

[1] http://grass.osgeo.org/programming7/namespacepython_1_1core.html#a0e55b38e9bb8c7b104e8884f26dc618a

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

martinl · March 22, 2011, 2:45pm

Hi,

2011/3/22 Martin Landa <landa.martin@gmail.com>:

at least we could use grass.create_location() [1] for unprojected
locations, for the rest is needed running GRASS session (`g.proj`).

Martin

[1] http://grass.osgeo.org/programming7/namespacepython_1_1core.html#a0e55b38e9bb8c7b104e8884f26dc618a

please try out r45726

$ grass70 -c /home/martin/grassdata/test1

g.proj -p

XY location (unprojected)

$ grass70 -c ~/lakes.shp /home/martin/grassdata/test1

g.proj -p

-PROJ_INFO-------------------------------------------------
name : Lambert Conformal Conic
proj : lcc
datum : nad83
ellps : grs80
lat_1 : 36.16666666666666
lat_2 : 34.33333333333334
lat_0 : 33.75
lon_0 : -79
x_0 : 609601.22
y_0 : 0
no_defs : defined
-PROJ_UNITS------------------------------------------------
unit : Meter
units : Meters
meters : 1

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

martinl · March 22, 2011, 3:00pm

Hi,

2011/3/22 Martin Landa <landa.martin@gmail.com>:

please try out r45726

$ grass70 -c /home/martin/grassdata/test1

g.proj -p

XY location (unprojected)

$ grass70 -c ~/lakes.shp /home/martin/grassdata/test1

in r45727 you can also create new location based on EPSG

$ grass70 -c EPSG:4326 /home/martin/grassdata/test1

g.proj -p

-PROJ_INFO-------------------------------------------------
name : Lat/Lon
proj : ll
datum : wgs84
ellps : wgs84
no_defs : defined
-PROJ_UNITS------------------------------------------------
unit : degree
units : degrees
meters : 1.0

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

Hamish · March 22, 2011, 10:31pm

Martin wrote:

> please try out r45726

thanks,

> $ grass70 -c /home/martin/grassdata/test1
> g.proj -p
> XY location (unprojected)

create XY by default? I'm not so sure about that. I'd think it
much better to exit with an error if location type could not be
determined.

> $ grass70 -c ~/lakes.shp /home/martin/grassdata/test1

in r45727 you can also create new location based on EPSG

$ grass70 -c EPSG:4326 /home/martin/grassdata/test1

re. -c, in GRASS 6 we have been using the -c command line flag
to create a new mapset if it doesn't exist. Using the same
flag contextually to create a new location too would be confusing
and bug prone. We should split mapset/location creation into
two separate flags.

fwiw, I would be rather happy to see g.setproj reenabled in trunk
for these situations. Also, to (re)provide hierarchical state
plane selection which is not available elsewhere.

AFAICT the module and G_ask_datum_name(), G_ask_proj_name(),
G_get_ellipsoid_parameters(), etc. do not use the Vask library
or curses, just a bunch of G_system()s which would need checking.
Only the welcome screen front-end and region bounds were using
the curses stuff AFAIR, but that's east enough to replace.

?

cheers,
Hamish

ps- re. r45719 "winGRASS: include some gdal plugins", can you
confirm that these plugins are license compatible? (may have been
left out on purpose)

Hamish · March 22, 2011, 10:41pm

Martin wrote:

> > $ grass70 -c /home/martin/grassdata/test1
> > g.proj -p
> > XY location (unprojected)

Hamish:

create XY by default? I'm not so sure about that. I'd think
it much better to exit with an error if location type could
not be determined.

maybe I am confusing that... in the above example the XY location
already existed and you were just making a new mapset, yes?

Hamish

Glynn_Clements1 · March 23, 2011, 4:43am

Hamish wrote:

> > $ grass70 -c /home/martin/grassdata/test1
> > g.proj -p
> > XY location (unprojected)

create XY by default? I'm not so sure about that. I'd think it
much better to exit with an error if location type could not be
determined.

The most important thing is to create /something/ so that you can
actually get into GRASS. Once you've done that, you can change the
projection or create a new location with g.proj. But first you have to
get to the point that g.proj works.

> > $ grass70 -c ~/lakes.shp /home/martin/grassdata/test1
>
> in r45727 you can also create new location based on EPSG
>
> $ grass70 -c EPSG:4326 /home/martin/grassdata/test1

re. -c, in GRASS 6 we have been using the -c command line flag
to create a new mapset if it doesn't exist. Using the same
flag contextually to create a new location too would be confusing
and bug prone. We should split mapset/location creation into
two separate flags.

The argument is a complete path, so the logical approach would be to
check how much of that path already exists, i.e.:

  if the complete path exists:
      mapset already exists; no need to create anything
  else if the path minus the last element exists:
      location exists; create new mapset
  else if the path minus the last two elements exists:
      database exists; create new location and mapset
  else
      none of it exists; create new database, location and mapset

fwiw, I would be rather happy to see g.setproj reenabled in trunk
for these situations. Also, to (re)provide hierarchical state
plane selection which is not available elsewhere.

I would be rather less than happy. g.setproj is inherently interactive
and non-scriptable; and the code is an absolute mess.

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

Pierre_Roudier · March 23, 2011, 4:48am

Hi Martin and others, and thanks very much for your answers,

Your solution is working well Martin, however for some reason I have
to be root to start grass successfuly.

pierrer@grass:~$ grass70 -c /home/pierrer/grassdata/test2
Traceback (most recent call last):
  File "/usr/local/bin/grass70", line 961, in <module>
    grass_intro()
  File "/usr/local/bin/grass70", line 370, in grass_intro
    f = open(path, 'r')
IOError: [Errno 2] No such file or directory:
'/home/pierrer/grassdata/etc/grass_intro'

Pierre

2011/3/23 Martin Landa <landa.martin@gmail.com>:

Hi,

2011/3/22 Martin Landa <landa.martin@gmail.com>:

at least we could use grass.create_location() [1] for unprojected
locations, for the rest is needed running GRASS session (`g.proj`).

Martin

[1] http://grass.osgeo.org/programming7/namespacepython_1_1core.html#a0e55b38e9bb8c7b104e8884f26dc618a

please try out r45726

$ grass70 -c /home/martin/grassdata/test1

g.proj -p

XY location (unprojected)

$ grass70 -c ~/lakes.shp /home/martin/grassdata/test1

g.proj -p

-PROJ_INFO-------------------------------------------------
name : Lambert Conformal Conic
proj : lcc
datum : nad83
ellps : grs80
lat_1 : 36.16666666666666
lat_2 : 34.33333333333334
lat_0 : 33.75
lon_0 : -79
x_0 : 609601.22
y_0 : 0
no_defs : defined
-PROJ_UNITS------------------------------------------------
unit : Meter
units : Meters
meters : 1

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Scientist
Landcare Research, New Zealand

martinl · March 23, 2011, 9:28am

Hi,

2011/3/22 Hamish <hamish_b@yahoo.com>:

> $ grass70 -c /home/martin/grassdata/test1
> g.proj -p
> XY location (unprojected)

create XY by default? I'm not so sure about that. I'd think it
much better to exit with an error if location type could not be
determined.

unprojected location is created when no parameters (file, epgs) is
given. It's not "by default".

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

martinl · March 23, 2011, 9:31am

Hi,

2011/3/22 Hamish <hamish_b@yahoo.com>:

ps- re. r45719 "winGRASS: include some gdal plugins", can you
confirm that these plugins are license compatible? (may have been
left out on purpose)

currently it's gdal-ecw and gdal-mrsid. Anyway within winGRASS
installer we are providing other osgeo4w packages, python, etc.

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

martinl · March 23, 2011, 9:34am

2011/3/22 Hamish <hamish_b@yahoo.com>:

Martin wrote:

> > $ grass70 -c /home/martin/grassdata/test1
> > g.proj -p
> > XY location (unprojected)

Hamish:

create XY by default? I'm not so sure about that. I'd think
it much better to exit with an error if location type could
not be determined.

maybe I am confusing that... in the above example the XY location
already existed and you were just making a new mapset, yes?

no, it will create new unprojected location. Current behaviour of -c flag:

* if location doesn't exists it will created new location
** if no extra parameter is added (geofile or EPSG:code) unprojected
location is created
* if location exists, it will create new mapset

I think it's quite clear behaviour and we don't need any extra flag.

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

martinl · March 23, 2011, 9:44am

Hi,

2011/3/23 Glynn Clements <glynn@gclements.plus.com>:

> > $ grass70 -c /home/martin/grassdata/test1
> > g.proj -p
> > XY location (unprojected)

create XY by default? I'm not so sure about that. I'd think it
much better to exit with an error if location type could not be
determined.

The most important thing is to create /something/ so that you can
actually get into GRASS. Once you've done that, you can change the
projection or create a new location with g.proj. But first you have to
get to the point that g.proj works.

Agreed.

> > $ grass70 -c ~/lakes.shp /home/martin/grassdata/test1
>
> in r45727 you can also create new location based on EPSG
>
> $ grass70 -c EPSG:4326 /home/martin/grassdata/test1

re. -c, in GRASS 6 we have been using the -c command line flag
to create a new mapset if it doesn't exist. Using the same
flag contextually to create a new location too would be confusing
and bug prone. We should split mapset/location creation into
two separate flags.

The argument is a complete path, so the logical approach would be to
check how much of that path already exists, i.e.:

should be working like this

   if the complete path exists:
       mapset already exists; no need to create anything

$ grass70 -c /home/martin/grassdata/nc_spm_08/user1/
works

   else if the path minus the last element exists:
       location exists; create new mapset

$ grass70 -c /home/martin/grassdata/nc_spm_08/user2
works

   else if the path minus the last two elements exists:
       database exists; create new location and mapset

current behaviour

grass70 -c /home/martin/grassdata/test01/user

creates location 'user' in dbase '/home/martin/grassdata/test01'

I am not sure at this point, to change this behaviour you would need
to define always the mapset, e.g.

grass70 -c /home/martin/grassdata/test01/PERMANENT

which is annoying.

   else
       none of it exists; create new database, location and mapset

$ grass70 -c /home/martin/grassdata/nc_spm_08/user1/
works.

[...]

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

martinl · March 23, 2011, 9:52am

Hi,

2011/3/23 Pierre Roudier <pierre.roudier@gmail.com>:

pierrer@grass:~$ grass70 -c /home/pierrer/grassdata/test2
Traceback (most recent call last):
File "/usr/local/bin/grass70", line 961, in <module>
grass_intro()
File "/usr/local/bin/grass70", line 370, in grass_intro
f = open(path, 'r')
IOError: [Errno 2] No such file or directory:
'/home/pierrer/grassdata/etc/grass_intro'

you are probably overriding GISBASE variable.

What gives

$ echo $GISBASE

before you start GRASS? It should be empty.

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

Hamish · March 23, 2011, 8:39pm

Hamish:

> ps- re. r45719 "winGRASS: include some gdal plugins", can you
> confirm that these plugins are license compatible? (may have
> been left out on purpose)

Martin:

currently it's gdal-ecw and gdal-mrsid.

AFAIU those are supplied as plugins and not built into the main
GDAL exactly because they are incompatible with the GPL and may
not be shipped with the likes of GRASS.

End users are free to add in them as they like, but then they
too lose the right to redistribute the combined work to others.

Similarly, people who want to redistribute a GPL-free GDAL can
leave out the GRASS plugin. (reimplemented from scratch as LGPL
one day..)

see http://trac.osgeo.org/gdal/wiki/rfc34_license_policy

Anyway within winGRASS installer we are providing other osgeo4w
packages, python, etc.

irrelevant- python (etc) are GPL compatible, and other things
supplied in parrallel by the main osgeo4w installer (AFAIK),
but not used by/with GRASS, fall under the OS exemption.

cheers,
Hamish

Pierre_Roudier · March 23, 2011, 9:29pm

Hi Martin,

you are probably overriding GISBASE variable.

What gives

$ echo $GISBASE

Indeed:

pierrer@grass:~$ echo $GISBASE
/home/pierrer/grassdata/

So I turned it back to void:
pierrer@grass:~$ export GISBASE=""
pierrer@grass:~$ echo $GISBASE

But unfortunately the problem remains the same:

pierrer@grass:~$ grass70
Traceback (most recent call last):
  File "/usr/local/bin/grass70", line 961, in <module>
    grass_intro()
  File "/usr/local/bin/grass70", line 370, in grass_intro
    f = open(path, 'r')
IOError: [Errno 2] No such file or directory: './etc/grass_intro'

However I do have a GISBASE envvar in root:
root@grass:/usr/local/src/grass_trunk# echo $GISBASE
/usr/local/grass-7.0.svn/

Here I can launch grass and initiate a location using the -c flag.
However, if I turn it to void, I can't launcg grass anymore:
root@grass:/usr/local/src/grass_trunk# export GISBASE=""
root@grass:/usr/local/src/grass_trunk# echo $GISBASE

root@grass:/usr/local/src/grass_trunk# grass70
Cleaning up temporary files...
Traceback (most recent call last):
  File "/usr/local/bin/grass70", line 963, in <module>
    clean_temp()
  File "/usr/local/bin/grass70", line 818, in clean_temp
    call([gfile("etc", "clean_temp")], stdout = nul, stderr = nul)
  File "/usr/local/bin/grass70", line 112, in call
    return subprocess.call(cmd, **kwargs)
  File "/usr/lib/python2.6/subprocess.py", line 470, in call
    return Popen(*popenargs, **kwargs).wait()
  File "/usr/lib/python2.6/subprocess.py", line 623, in __init__
    errread, errwrite)
  File "/usr/lib/python2.6/subprocess.py", line 1141, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory

martinl · March 23, 2011, 9:42pm

Hi,

2011/3/23 Pierre Roudier <pierre.roudier@gmail.com>:

pierrer@grass:~$ export GISBASE=""

unset GISBASE

Martin

--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa