[GRASS-dev] t.register without input stds

GRASS GRASS developer
1

Hi devs,

I just discovered that t.register could run without a defined input stds?
Does this behavior make sense? (for me not)

--
ciao
Luca

www.lucadelu.org

2

Hola Lu,

Yes, that was a discussion in the user list until a couple of days ago. Check this thread: https://lists.osgeo.org/pipermail/grass-user/2017-February/076022.html
I sent a diff with an explanation for t.register manual page and Soeren said he would apply it this weekend with some other modifications.

baci,
vero

···

2017-03-02 10:43 GMT+01:00 Luca Delucchi <lucadeluge@gmail.com>:

Hi devs,

I just discovered that t.register could run without a defined input stds?
Does this behavior make sense? (for me not)

–
ciao
Luca

www.lucadelu.org

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

3

On 2 March 2017 at 11:15, Veronica Andreo <veroandreo@gmail.com> wrote:

Hola Lu,

Hey,

Yes, that was a discussion in the user list until a couple of days ago.
Check this thread:
https://lists.osgeo.org/pipermail/grass-user/2017-February/076022.html
I sent a diff with an explanation for t.register manual page and Soeren said
he would apply it this weekend with some other modifications.

thanks for pointing me to the thread, so if the behavior is correct I
think we need to have several modules to register maps:
- t.register.maps used to register maps in temporal framework
- t.register.strds register maps in a strds
- t.register.stvds register maps in a stvds
- t.register.str3ds register maps in a str3ds

what do you think? Is this solution to much complicated for final users?

baci,
vero

--
ciao
Luca

www.lucadelu.org

4

Hi there,

Mmm, dunno honestly… I prefer the present form, but might be because I’m used to it already…

I would say that a good documentation of the behaviour of t.register using input or not is the most important, and that’s on its way… otherwise, if you have t.register.maps and t.register.stxds as suggested, it might become even more confusing for users… should they then always have to use both modules? And on top of that, it seems to me quite repetitive to have 4 modules to do what only one is able to do just by changing 2 options (i.e.: input and type). But that’s my opinion only :stuck_out_tongue:

Baci,
Vero

···

El 2 mar. 2017 3:08 p. m., “Luca Delucchi” <lucadeluge@gmail.com> escribió:

On 2 March 2017 at 11:15, Veronica Andreo <veroandreo@gmail.com> wrote:

Hola Lu,

Hey,

Yes, that was a discussion in the user list until a couple of days ago.
Check this thread:
https://lists.osgeo.org/pipermail/grass-user/2017-February/076022.html
I sent a diff with an explanation for t.register manual page and Soeren said
he would apply it this weekend with some other modifications.

thanks for pointing me to the thread, so if the behavior is correct I
think we need to have several modules to register maps:

  • t.register.maps used to register maps in temporal framework
  • t.register.strds register maps in a strds
  • t.register.stvds register maps in a stvds
  • t.register.str3ds register maps in a str3ds

what do you think? Is this solution to much complicated for final users?

5

Hello,

I think splitting the module in 4 different one is overkill and could
be more confusing.
My question is: Is there a use case for registering maps without
registering them in a STDS? Is it possible to use them without having
them registered in a STDS?

Regards,
Laurent

2017-03-02 10:45 GMT-06:00 Veronica Andreo <veroandreo@gmail.com>:

Hi there,

El 2 mar. 2017 3:08 p. m., "Luca Delucchi" <lucadeluge@gmail.com> escribió:

On 2 March 2017 at 11:15, Veronica Andreo <veroandreo@gmail.com> wrote:
> Hola Lu,
>

Hey,

> Yes, that was a discussion in the user list until a couple of days ago.
> Check this thread:
> https://lists.osgeo.org/pipermail/grass-user/2017-February/076022.html
> I sent a diff with an explanation for t.register manual page and Soeren
> said
> he would apply it this weekend with some other modifications.
>

thanks for pointing me to the thread, so if the behavior is correct I
think we need to have several modules to register maps:
- t.register.maps used to register maps in temporal framework
- t.register.strds register maps in a strds
- t.register.stvds register maps in a stvds
- t.register.str3ds register maps in a str3ds

what do you think? Is this solution to much complicated for final users?

Mmm, dunno honestly... I prefer the present form, but might be because I'm
used to it already...

I would say that a good documentation of the behaviour of t.register using
input or not is the most important, and that's on its way... otherwise, if
you have t.register.maps and t.register.stxds as suggested, it might become
even more confusing for users... should they then always have to use both
modules? And on top of that, it seems to me quite repetitive to have 4
modules to do what only one is able to do just by changing 2 options (i.e.:
input and type). But that's my opinion only :stuck_out_tongue:

Baci,
Vero

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

6

On 2 March 2017 at 18:11, Laurent C. <lrntct@gmail.com> wrote:

Hello,

Hi,

I think splitting the module in 4 different one is overkill and could
be more confusing.
My question is: Is there a use case for registering maps without
registering them in a STDS? Is it possible to use them without having
them registered in a STDS?

My same questions...

Regards,
Laurent

--
ciao
Luca

www.lucadelu.org

7

2017-03-02 18:11 GMT+01:00 Laurent C. <lrntct@gmail.com>:

Hello,

I think splitting the module in 4 different one is overkill and could
be more confusing.

If we start to split t.register based on STDS or map types, then we
must also consider to split the modules t.list, t.remove, t.sample,
t.create, t.merge, t.info, t.topology, t.snap, t.shift, t.rename,
t.support ... . Which will be even more confusing.

My question is: Is there a use case for registering maps without
registering them in a STDS? Is it possible to use them without having
them registered in a STDS?

If you attach a timestamps to a map in GRASS, then you register the
map in the temporal database. Hence the use case is attaching
timestamps to maps using t.register which makes the usage of
r/r3/v.timestamp modules obsolete. You don't need a STDS to attach
timestamps to maps. You can use t.list to list and search for all maps
that have a timestamp without bothering about STDS relations.

Best regards
Soeren

Regards,
Laurent

2017-03-02 10:45 GMT-06:00 Veronica Andreo <veroandreo@gmail.com>:

Hi there,

El 2 mar. 2017 3:08 p. m., "Luca Delucchi" <lucadeluge@gmail.com> escribió:

On 2 March 2017 at 11:15, Veronica Andreo <veroandreo@gmail.com> wrote:
> Hola Lu,
>

Hey,

> Yes, that was a discussion in the user list until a couple of days ago.
> Check this thread:
> https://lists.osgeo.org/pipermail/grass-user/2017-February/076022.html
> I sent a diff with an explanation for t.register manual page and Soeren
> said
> he would apply it this weekend with some other modifications.
>

thanks for pointing me to the thread, so if the behavior is correct I
think we need to have several modules to register maps:
- t.register.maps used to register maps in temporal framework
- t.register.strds register maps in a strds
- t.register.stvds register maps in a stvds
- t.register.str3ds register maps in a str3ds

what do you think? Is this solution to much complicated for final users?

Mmm, dunno honestly... I prefer the present form, but might be because I'm
used to it already...

I would say that a good documentation of the behaviour of t.register using
input or not is the most important, and that's on its way... otherwise, if
you have t.register.maps and t.register.stxds as suggested, it might become
even more confusing for users... should they then always have to use both
modules? And on top of that, it seems to me quite repetitive to have 4
modules to do what only one is able to do just by changing 2 options (i.e.:
input and type). But that's my opinion only :stuck_out_tongue:

Baci,
Vero

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

8

2017-03-02 10:43 GMT+01:00 Luca Delucchi <lucadeluge@gmail.com>:

Hi devs,

I just discovered that t.register could run without a defined input stds?
Does this behavior make sense? (for me not)

On Thu, Mar 2, 2017 at 11:15 AM, Veronica Andreo <veroandreo@gmail.com> wrote:

Hola Lu,

Yes, that was a discussion in the user list until a couple of days ago.
Check this thread:
https://lists.osgeo.org/pipermail/grass-user/2017-February/076022.html
I sent a diff with an explanation for t.register manual page and Soeren said
he would apply it this weekend with some other modifications.

Did it get applied?

Since I stumbled over the same issue and spend a lot of time debugging
for nothing :slight_smile: I now understood with off-list help from Soeren that
t.register comes with two modes:

- Mode 1: assigning timestamps to maps only
- Mode 2: registering maps in the space time dataset

I think that the best would be to print these two messages
respectively when invoking t.register without or with "input="
parameter. Like r.sun does...

Markus

9

Hi,

Yes, it was applied in 70728 [1]. If not clear enough, please enhance.

Yes, that would help. But actually, mode 2, as you call it, does both: assigns timestamps and registers maps in the input space time dataset.

Vero

[1] https://trac.osgeo.org/grass/changeset/70728

···

El 23 abr. 2017 11:39 p.m., “Markus Neteler” <neteler@osgeo.org> escribió:

2017-03-02 10:43 GMT+01:00 Luca Delucchi <lucadeluge@gmail.com>:

Hi devs,

I just discovered that t.register could run without a defined input stds?
Does this behavior make sense? (for me not)

On Thu, Mar 2, 2017 at 11:15 AM, Veronica Andreo <veroandreo@gmail.com> wrote:

Hola Lu,

Yes, that was a discussion in the user list until a couple of days ago.
Check this thread:
https://lists.osgeo.org/pipermail/grass-user/2017-February/076022.html
I sent a diff with an explanation for t.register manual page and Soeren said
he would apply it this weekend with some other modifications.

Did it get applied?

Since I stumbled over the same issue and spend a lot of time debugging
for nothing :slight_smile: I now understood with off-list help from Soeren that
t.register comes with two modes:

  • Mode 1: assigning timestamps to maps only
  • Mode 2: registering maps in the space time dataset

I think that the best would be to print these two messages
respectively when invoking t.register without or with “input=”
parameter. Like r.sun does…

10

On Sun, Apr 23, 2017 at 11:53 PM, Veronica Andreo <veroandreo@gmail.com> wrote:

El 23 abr. 2017 11:39 p.m., "Markus Neteler" <neteler@osgeo.org> escribió:

On Thu, Mar 2, 2017 at 11:15 AM, Veronica Andreo <veroandreo@gmail.com>

2017-03-02 10:43 GMT+01:00 Luca Delucchi <lucadeluge@gmail.com>:

Hi devs,

I just discovered that t.register could run without a defined input stds?
Does this behavior make sense? (for me not)

Yes, that was a discussion in the user list until a couple of days ago.
Check this thread:
https://lists.osgeo.org/pipermail/grass-user/2017-February/076022.html
I sent a diff with an explanation for t.register manual page and Soeren
said
he would apply it this weekend with some other modifications.

Did it get applied?

Yes, it was applied in 70728 [1]. If not clear enough, please enhance.

Ok - I suggest to extend the module description which currently is

" t.register - Registers raster, vector and raster3d maps in a space
time datasets. "

as it does not reflect (for me) that a it also operates without input stds.
Ideas?

Since I stumbled over the same issue and spend a lot of time debugging
for nothing :slight_smile: I now understood with off-list help from Soeren that
t.register comes with two modes:

- Mode 1: assigning timestamps to maps only
- Mode 2: registering maps in the space time dataset

I think that the best would be to print these two messages
respectively when invoking t.register without or with "input="
parameter. Like r.sun does...

Yes, that would help. But actually, mode 2, as you call it, does both:
assigns timestamps and registers maps in the input space time dataset.

That's true, indeed they are not two distinct modes but 2 includes 1.

For the manual, I suggest to clarify the first two sentences which are
the key to understand what t.register does:

# currently
"The module t.register is designed to register raster, 3D raster and
vector maps in the temporal database and in specific space time
datasets. This module must be used to assign time stamps to raster, 3D
raster and vector maps."

# suggestion
"The module t.register either only assigns timestamps to raster, 3D
raster and vector maps or additionally also registers them in the
temporal database within specific space time datasets."

... ideas for better wording are welcome.

Markus

Vero

[1] https://trac.osgeo.org/grass/changeset/70728

11

Hello,

···

[…]

Did it get applied?

Yes, it was applied in 70728 [1]. If not clear enough, please enhance.

Ok - I suggest to extend the module description which currently is

" t.register - Registers raster, vector and raster3d maps in a space
time datasets. "

as it does not reflect (for me) that a it also operates without input stds.
Ideas?

mmm… what about:

" t.register - Assigns timestamps and registers raster, vector and raster3d maps in a space time dataset. "

?

Since I stumbled over the same issue and spend a lot of time debugging
for nothing :slight_smile: I now understood with off-list help from Soeren that
t.register comes with two modes:

  • Mode 1: assigning timestamps to maps only
  • Mode 2: registering maps in the space time dataset

I think that the best would be to print these two messages
respectively when invoking t.register without or with “input=”
parameter. Like r.sun does…

Yes, that would help. But actually, mode 2, as you call it, does both:
assigns timestamps and registers maps in the input space time dataset.

That’s true, indeed they are not two distinct modes but 2 includes 1.

but the idea of printing messages saying what is being done if input is used/not used, it is still valid, no? I think it might be educational (?)… dunno if that’s the best word…

For the manual, I suggest to clarify the first two sentences which are
the key to understand what t.register does:

currently

“The module t.register is designed to register raster, 3D raster and
vector maps in the temporal database and in specific space time
datasets. This module must be used to assign time stamps to raster, 3D
raster and vector maps.”

suggestion

“The module t.register either only assigns timestamps to raster, 3D
raster and vector maps or additionally also registers them in the
temporal database within specific space time datasets.”

… ideas for better wording are welcome.

maybe clearer like this:

“The module t.register either only assigns timestamps to raster, 3D raster and vector maps in the temporal database or additionally, also registers them within specific space time datasets.”

I can send a diff for both changes if you agree

best,

Vero

12

Hi,

On Sun, Apr 23, 2017 at 11:53 PM, Veronica Andreo <veroandreo@gmail.com> wrote:

Hi,

El 23 abr. 2017 11:39 p.m., "Markus Neteler" <neteler@osgeo.org> escribió:

2017-03-02 10:43 GMT+01:00 Luca Delucchi <lucadeluge@gmail.com>:

Hi devs,

I just discovered that t.register could run without a defined input stds?
Does this behavior make sense? (for me not)

On Thu, Mar 2, 2017 at 11:15 AM, Veronica Andreo <veroandreo@gmail.com>
wrote:

Hola Lu,

Yes, that was a discussion in the user list until a couple of days ago.
Check this thread:
https://lists.osgeo.org/pipermail/grass-user/2017-February/076022.html
I sent a diff with an explanation for t.register manual page and Soeren
said
he would apply it this weekend with some other modifications.

Did it get applied?

Yes, it was applied in 70728 [1]. If not clear enough, please enhance.

ok I finally got it: I was reading the 7.2 docs which is the production version.
It was lacking the backport of your improvements :frowning:
Done now in r70949.

Markus

13

On Mon, Apr 24, 2017 at 8:34 AM, Veronica Andreo <veroandreo@gmail.com> wrote:
...

mmm... what about:

" t.register - Assigns timestamps and registers raster, vector and raster3d
maps in a space time dataset. "

Yes, nice.

...

but the idea of printing messages saying what is being done if input is
used/not used, it is still valid, no?

For me yes! But I would not know where to add it in the code.

I think it might be *educational* (?)... dunno if that's the best word...

+1

For the manual, I suggest to clarify the first two sentences which are
the key to understand what t.register does:

...

maybe clearer like this:

"The module t.register either only assigns timestamps to raster, 3D raster
and vector maps in the temporal database or additionally, also registers
them within specific space time datasets."

I can send a diff for both changes if you agree

Thanks, received and applied in r70950 (relbr72) and r70951 (trunk).

So, we would still need a proposal for two new messages mentioned above.

best,
Markus