[GRASS-dev] t.register without input stds

Laurent C. lrntct at gmail.com
Thu Mar 2 09:11:35 PST 2017


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 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


More information about the grass-dev mailing list