[GRASS-dev] t.register without input stds

Sören Gebbert soerengebbert at googlemail.com
Thu Mar 2 12:53:58 PST 2017


2017-03-02 18:11 GMT+01:00 Laurent C. <lrntct at 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 at gmail.com>:
>> Hi there,
>>
>> El 2 mar. 2017 3:08 p. m., "Luca Delucchi" <lucadeluge at gmail.com> escribió:
>>>
>>> On 2 March 2017 at 11:15, Veronica Andreo <veroandreo at 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 :P
>>
>> Baci,
>> Vero
>>
>>
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-dev
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev


More information about the grass-dev mailing list