[GRASS-dev] text interface for GRASS70

[Glynn Clements]

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 at gclements.plus.com>