[GRASS-dev] [RFC] Glossary: GISDATABASE -> DATASTORE

[tlaronde at polynum.com]

On Mon, Mar 05, 2007 at 12:11:13PM +1300, Hamish wrote:
> Thierry wrote:
> > Glossary proposal for gis "database" naming scheme
> ..
> > Hence I propose to replace GISDATABASE by: DATASTORE.
> 
> DATASTORE is a fine suggestion, the best I've heard so far. See also
> email threads discussing the wording of the start-up mapset-picker menu.

Thanks for the feed-back, Hamish. I will give a look at the thread you
are mentioning.

> [about LOCATION_NAME and LOCATION] 
> 
> In GPL GRASS 6 LOCATION_NAME is still a GIS variable (stored in
> ~/.grassrc6 and not a shell variable*) and viewed/changed with the
> g.gisenv module. LOCATION_NAME is just the name, not the path.
> GISDBASE has the path.
> 
> The shell variable $LOCATION has been abandoned, but a number of scripts
> do this to recreate it:  (due to path of least modification after
> $LOCATION was dropped)
> 
> 
> eval `g.gisenv`
> : ${GISBASE?} ${GISDBASE?} ${LOCATION_NAME?} ${MAPSET?}
> LOCATION="$GISDBASE"/"$LOCATION_NAME"/"$MAPSET"

For now in the published versions of KerGIS this is the same: LOCATION
has been dropped.
What I wanted to say is that, from an user point of view, he enters:

g.gisenv MAPSET=<some_name>

but
g.gisenv LOCATION_NAME=<some_name>

and this is a frequent error to do:

g.gisenv LOCATION=<some_name>

And the user is right: there is a lack of symetry, and if we speak all
along about a "location" (implied in the current DATASTORE), its name
(and not its pathname) shall be set via LOCATION.

Since to add implicit information to the sources, I do a lot of renaming
(so that the organization of the sources, and the consistence of naming
is, to some extent, self-explanatory), I have introduced in kergis
sources the tools/ed directory where I put the correspondence between
old name and new name like this (this works for C sources or scripts).
For example in this case I will create a tools/ed/sh.ed (the format is
: <condition>|<regex>|<replacement>

|GISDBASE|GISDATADIR
|GISDATADIR|GISDATABASE
|GISDATABASE|DATASTORE

[you see in this example that I did not find at first glance the correct
name:
GISDBASE GISDATADIR
	GISDBASE was to close to GISBASE so I wanted a more "at first sight"
	distinct name. But I thought that the data was not really a
	"database"
GISDATADIR GISDATABASE
	Blunder: the data _is_ organized as a database since there are
	dedicated functions (GISLIB) to implement a policy and to organize
	the data.
GISDATABASE DATASTORE
	Yes, databases, but not at the GISDATABASE level: below, at the
	location. And SQL and PostgreSQL other examples finally made the
	distinction more clear.
]

Then I automatically generate an ed(1) script:

g/GISDBASE/s/^GISDBASE$/GISDATADIR/
g/GISDBASE/s/^GISDBASE\([^a-zA-Z0-9_-]\)/GISDATADIR\1/
g/GISDBASE/s/\([^a-zA-Z0-9_-]\)GISDBASE$/\1GISDATADIR/
g/GISDBASE/s/\([^a-zA-Z0-9_-]\)GISDBASE\([^a-zA-Z0-9_-]\)/\1GISDATADIR\2/g
g/GISDATADIR/s/^GISDATADIR$/GISDATABASE/
g/GISDATADIR/s/^GISDATADIR\([^a-zA-Z0-9_-]\)/GISDATABASE\1/
g/GISDATADIR/s/\([^a-zA-Z0-9_-]\)GISDATADIR$/\1GISDATABASE/
g/GISDATADIR/s/\([^a-zA-Z0-9_-]\)GISDATADIR\([^a-zA-Z0-9_-]\)/\1GISDATABASE\2/g
g/GISDATABASE/s/^GISDATABASE$/DATASTORE/
g/GISDATABASE/s/^GISDATABASE\([^a-zA-Z0-9_-]\)/DATASTORE\1/
g/GISDATABASE/s/\([^a-zA-Z0-9_-]\)GISDATABASE$/\1DATASTORE/
g/GISDATABASE/s/\([^a-zA-Z0-9_-]\)GISDATABASE\([^a-zA-Z0-9_-]\)/\1DATASTORE\2/g
w
q

that is applied on files selected. Just to say that "upgrading" is
relatively easy.
[In fact, to upgrade from CERL to KerGIS version d.d.d.d you will have
to apply in order: sh.ed sh-1.0.0.0 ... {last sh.ed with version <
target version}]

> 
> [*] not a shell variable to allow child process (the GUI menus) to
> adjust variables which affect the parent, and thus new non-derivative
> sibling processes. [e.g. switch mapsets without exiting GRASS]

That's another case where I think I will change a name. 

`.grassrc' or `.kergisrc' are misnamed. This is in fact a _session_.
I will go with `.kergis_session'.  The session is precisely what
you are describing.

To come back to the DATASTORE and to a comparison---that is useful for
example in teaching---, the good thing is helping to find good ideas.
In this case, KerGIS shall clearly (I don't know if GPL GRASS has
already made this) implement:

g.dump(8)
g.restore(8)

to dump a location in ascii, and to restore an ascii version of a
location to the binary one. I use a lot CVS to store versions of the
ascii gis files, and it will be a great archival/transfer even testing
and debugging tool (to verify the basic functionnality of a fresh
installation, g.restore spearfish for example).

It is almost straightforward to do a shell script for that. But the
devil is in the details:

1) I would like user kergis (the 'root' superuser of KerGIS) to be able
to dump a whole DATASTORE. But individual permissions on directory might
prevent this (kergis is not system root; sudo(1) may help in this case);

2) Some part of options found in pg_dump and pg_restore would be useful
for CERL GRASS based GIS too, namely to dump in the ascii subdirectory,
or to tar (pax) the files for archival or transfer.

Once we put at light the rules underlying---and naming is one mean to do
that---good suggestions and natural extensions come to mind :) And at
the moment, at least KerGIS (GPL GRASS has perhaps made some progress
already) is poor in administration tools.

Cheers,
-- 
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C