[GRASS-dev] t*. modules

GRASS GIS GRASS GIS developer
1

Hi,

scripts from `temporal` directory are introducing three new prefixes

* t.
* tr.
* tv.

and probably more in the future. I would suggest to introduce only one
new prefix `t`, so

tr. -> t.rast.
tv. -> t.vect.

What do you think?

Martin

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

2

Hi Martin,
with the temporal extension i introduce new datatypes to grass7:

* space time raster (tr.*) datasets
* space time vector (tv.*) datasets
* space time raster3d (tr3.*) datasets
and in the future
* space time dataset collections (?)

The purpose of the t.* modules is to create, remove, list, support new
datatypes and check the temporal topology. Modules with prefix t.*
support identical functionalities for all new datatypes. In the long
term the list and remove functionality can be integrated into the
general modules, but not support and topology.

So i would like to keep t.*, tr.*, tv.* and tr3.* as prefix to simply
identify the new datatypes, extending the common r.*, v.* and r3.*
prefixes with a "t".

Besides of that, the temporal Python API supports temporal and spatial
extent operations between the new datatypes as well as temporal
topology functionality. Indeed all temporal and spatial informations
(start time, end time, spatial extent, temporal granularity) are
derived from the registered maps, but the idea is to handle these new
objects as new datatypes. So modules expect these datasets as inputs
and outputs.

Expect new complex spatio-temporal analysis modules handling several
different space time datasets. Having "t.rast." as prefix will reduce
the ability to create short meaningful self explaining module names.
IIRC there is a limit by design how many parts a module name can have.

Best regards
Soeren

2011/10/20 Martin Landa <landa.martin@gmail.com>:

Hi,

scripts from `temporal` directory are introducing three new prefixes

* t.
* tr.
* tv.

and probably more in the future. I would suggest to introduce only one
new prefix `t`, so

tr. -> t.rast.
tv. -> t.vect.

What do you think?

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

3

Hi,

2011/10/20 Sören Gebbert <soerengebbert@googlemail.com>:

So i would like to keep t.*, tr.*, tv.* and tr3.* as prefix to simply
identify the new datatypes, extending the common r.*, v.* and r3.*
prefixes with a "t".

historically there are prefixes like g., r., v. or r3. From this point
of view it would be good to keep spatio-temporal functionality under
one prefix. It's just introducing to many new prefix compared to the
number of existing prefixes. Just my personal opinion. I would like to
open discussion to avoid renaming of modules later in the future. We
need to make decision in early stage of development.

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

4

yes, this needs to be discussed.

My first reaction was let us keep just one letter but after thinking about Soeren's argument,
and checking the current names t., tr., tv., as Soeren suggests makes better sense,
especially given that we already have db.* and ps.* commands.

Are there any other suggestions how to handle this?

The best is to look here at the first set of commands
http://trac.osgeo.org/grass/browser/grass/trunk/temporal
For example we have
t.list type=rast
tr.list input=myrasterseries
How would these be handled using a different naming convention?

Helena

On Oct 20, 2011, at 4:38 PM, Martin Landa wrote:

Hi,

2011/10/20 Sören Gebbert <soerengebbert@googlemail.com>:

So i would like to keep t.*, tr.*, tv.* and tr3.* as prefix to simply
identify the new datatypes, extending the common r.*, v.* and r3.*
prefixes with a "t".

historically there are prefixes like g., r., v. or r3. From this point
of view it would be good to keep spatio-temporal functionality under
one prefix. It's just introducing to many new prefix compared to the
number of existing prefixes. Just my personal opinion. I would like to
open discussion to avoid renaming of modules later in the future. We
need to make decision in early stage of development.

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

5

Hi,

2011/10/20 Sören Gebbert <soerengebbert@googlemail.com>:

with the temporal extension i introduce new datatypes to grass7:

* space time raster (tr.*) datasets
* space time vector (tv.*) datasets
* space time raster3d (tr3.*) datasets
and in the future
* space time dataset collections (?)

The purpose of the t.* modules is to create, remove, list, support new
datatypes and check the temporal topology. Modules with prefix t.*
support identical functionalities for all new datatypes. In the long
term the list and remove functionality can be integrated into the
general modules, but not support and topology.

So i would like to keep t.*, tr.*, tv.* and tr3.* as prefix to simply
identify the new datatypes, extending the common r.*, v.* and r3.*
prefixes with a "t".

I would like to open the discussion about this topic again, before
tgis extension will be announced and users will start to use it. I
would suggest to use only *one* prefix (`t.`) for TGIS. To extend
current list of prefixes (r., v., etc) with so many new prefixes which
are related to the one topic (in this case temporal GIS) is not good
idea I think. Moreover it will make user manual less readable [1] -
see t.*, tr.* and so on. I would propose rename eg `tr.` to `t.rast.`,
and so on.

Martin

[1] http://grass.osgeo.org/grass70/manuals/html70_user/full_index.html
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

6

Ciao,

2012/3/29 Martin Landa <landa.martin@gmail.com>

Hi,

2011/10/20 Sören Gebbert <soerengebbert@googlemail.com>:

with the temporal extension i introduce new datatypes to grass7:

  • space time raster (tr.*) datasets
  • space time vector (tv.*) datasets
  • space time raster3d (tr3.*) datasets
    and in the future
  • space time dataset collections (?)

The purpose of the t.* modules is to create, remove, list, support new
datatypes and check the temporal topology. Modules with prefix t.*
support identical functionalities for all new datatypes. In the long
term the list and remove functionality can be integrated into the
general modules, but not support and topology.

So i would like to keep t., tr., tv.* and tr3.* as prefix to simply
identify the new datatypes, extending the common r., v. and r3.*
prefixes with a “t”.

I would like to open the discussion about this topic again, before
tgis extension will be announced and users will start to use it. I
would suggest to use only one prefix (t.) for TGIS. To extend
current list of prefixes (r., v., etc) with so many new prefixes which
are related to the one topic (in this case temporal GIS) is not good
idea I think. Moreover it will make user manual less readable [1] -
see t., tr. and so on. I would propose rename eg tr. to t.rast.,
and so on.

What about r.t. and v.t. ? It recalls what it’s already done with db, like v.db.
My 2 cents

madi

Martin

[1] http://grass.osgeo.org/grass70/manuals/html70_user/full_index.html

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

–
Ing. Margherita Di Leo, Ph.D.

7

2012/3/29 Martin Landa <landa.martin@gmail.com>:

Hi,

2011/10/20 Sören Gebbert <soerengebbert@googlemail.com>:

with the temporal extension i introduce new datatypes to grass7:

...

The purpose of the t.* modules is to ...

This is the right prefix... while

I would like to open the discussion about this topic again, before
tgis extension will be announced and users will start to use it. I
would suggest to use only *one* prefix (`t.`) for TGIS. To extend
current list of prefixes (r., v., etc) with so many new prefixes which
are related to the one topic (in this case temporal GIS) is not good
idea I think. Moreover it will make user manual less readable [1] -
see t.*, tr.* and so on. I would propose rename eg `tr.` to `t.rast.`,
and so on.

.. I agree with Martin that we currently get a confusing list of new
prefixes which are not in line with the existing naming scheme.

Markus

8

Hi,
The suggested naming scheme sounds reasonable. Following this scheme, modules should named like this?:

t.*:
t.create
t.sample
t.topology
…

t.rast.*:
t.rast.aggregate
t.rast.to.rast3
t.rast.mapcalc
…

t.rast3.*:
t.rast3.mapcalc
t.rast3.extract
t.rast3.list
…

t.vect.*:
t.vect.what.strds
t.vect.observe.strds
t.vect.extract
…

Does this sounds correct and reduces confusion?

Best regards
Soeren

Am 29.03.2012 18:36 schrieb “Markus Neteler” <neteler@osgeo.org>:

2012/3/29 Martin Landa <landa.martin@gmail.com>:

Hi,

2011/10/20 Sören Gebbert <soerengebbert@googlemail.com>:

with the temporal extension i introduce new datatypes to grass7:
…
The purpose of the t.* modules is to …

This is the right prefix… while

I would like to open the discussion about this topic again, before
tgis extension will be announced and users will start to use it. I
would suggest to use only one prefix (t.) for TGIS. To extend
current list of prefixes (r., v., etc) with so many new prefixes which
are related to the one topic (in this case temporal GIS) is not good
idea I think. Moreover it will make user manual less readable [1] -
see t., tr. and so on. I would propose rename eg tr. to t.rast.,
and so on.

… I agree with Martin that we currently get a confusing list of new
prefixes which are not in line with the existing naming scheme.

Markus

9

Hi,

2012/3/29 Sören Gebbert <soerengebbert@googlemail.com>:

[...]

t.rast3.*:
t.rast3.mapcalc
t.rast3.extract
t.rast3.list

probably `rast3d` (based on GIS element name, see eg. `g.mlist`) ?

Martin

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

10

Hi,

[...]

t.rast3.*:
t.rast3.mapcalc
t.rast3.extract
t.rast3.list

probably `rast3d` (based on GIS element name, see eg. `g.mlist`) ?

Ok, convinced.

Soeren

Martin

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