Hi devs,
according to this ticket [0] Soeren added the -s flag to
t.rast.aggregate and t.rast.aggregate.ds, I would like to extend (I
already started) this flag to all the temporal modules using basename
option. I discovered that -s flag is used in other modules for other
meanings.
In grass70 the only modules with basename and -s are t.rast*.mapcalc
(-s is used also by t.sample). In grass71 several other modules are
using -s.
I would like to standardize the -s for the "start time" and also the
other flags in the temporal modules.
I would like to modify trunk and release the new flags only in the
next major release, what do you think?
[0] https://trac.osgeo.org/grass/ticket/2294
--
ciao
Luca
http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
On 19 February 2016 at 14:31, Luca Delucchi <lucadeluge@gmail.com> wrote:
Hi devs,
Hi again,
according to this ticket [0] Soeren added the -s flag to
t.rast.aggregate and t.rast.aggregate.ds, I would like to extend (I
already started) this flag to all the temporal modules using basename
option. I discovered that -s flag is used in other modules for other
meanings.
In grass70 the only modules with basename and -s are t.rast*.mapcalc
(-s is used also by t.sample). In grass71 several other modules are
using -s.
I would like to standardize the -s for the "start time" and also the
other flags in the temporal modules.
I would like to modify trunk and release the new flags only in the
next major release, what do you think?
[0] https://trac.osgeo.org/grass/ticket/2294
nobody has to suggest a way to follow?
without any comment against tomorrow I'll start to commit changes in trunk
--
ciao
Luca
www.lucadelu.org
On Tue, Feb 23, 2016 at 9:02 AM, Luca Delucchi <lucadeluge@gmail.com> wrote:
On 19 February 2016 at 14:31, Luca Delucchi <lucadeluge@gmail.com> wrote:
> Hi devs,
>
Hi again,
> according to this ticket [0] Soeren added the -s flag to
> t.rast.aggregate and t.rast.aggregate.ds, I would like to extend (I
> already started) this flag to all the temporal modules using basename
> option. I discovered that -s flag is used in other modules for other
> meanings.
> In grass70 the only modules with basename and -s are t.rast*.mapcalc
> (-s is used also by t.sample). In grass71 several other modules are
> using -s.
> I would like to standardize the -s for the "start time" and also the
> other flags in the temporal modules.
>
> I would like to modify trunk and release the new flags only in the
> next major release, what do you think?
>
> [0] https://trac.osgeo.org/grass/ticket/2294
>
nobody has to suggest a way to follow?
without any comment against tomorrow I'll start to commit changes in trunk
Are we releasing 7.1 from current trunk? Any way we can make the changes in
7.1 in a compatible way? If not (in case of t.sample) we might say the
interface is a bug and fix it, I would like to avoid waiting for the
changes till GRASS 8.
Thanks,
Anna
--
ciao
Luca
www.lucadelu.org
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On 23 February 2016 at 15:52, Anna Petrášová <kratochanna@gmail.com> wrote:
Are we releasing 7.1 from current trunk? Any way we can make the changes in
7.1 in a compatible way? If not (in case of t.sample) we might say the
interface is a bug and fix it, I would like to avoid waiting for the changes
till GRASS 8.
t.sample has no basename, so probably we could leave it as now. I also
would like to avoid to wait GRASS 8.
Thanks,
Anna
--
ciao
Luca
www.lucadelu.org
Hi,
the "-s" flag is in use by many temporal modules for different
purposes in grass71.
Only the aggregation modules use "-s" flag to signal the usage of
start time as suffix for basename creation.
We should not change all the modules that make use of the flag "-s"
for column name suppression or spatial topology activation.
I would like to suggest that we do not use a flag for suffix
specification, but instead an option for this purpose. Like "suffix"?
The suffix option will specify which type should be created:
* time with full format (time) 2001-01-01T00:00:00
* time depending on the granularity (gran) 2001 or 2001-01 or 2001-01-01 ...
* numerical suffix with a specific number of digits (num + %05, ...)
"_0001" or "_01"
Parameter for the option suffix: "time","num","gran" and C format
specification like "%05" or "%03" in addition to num.
What do you think?
Best regards
Soeren
2016-02-19 14:31 GMT+01:00 Luca Delucchi <lucadeluge@gmail.com>:
Hi devs,
according to this ticket [0] Soeren added the -s flag to
t.rast.aggregate and t.rast.aggregate.ds, I would like to extend (I
already started) this flag to all the temporal modules using basename
option. I discovered that -s flag is used in other modules for other
meanings.
In grass70 the only modules with basename and -s are t.rast*.mapcalc
(-s is used also by t.sample). In grass71 several other modules are
using -s.
I would like to standardize the -s for the "start time" and also the
other flags in the temporal modules.
I would like to modify trunk and release the new flags only in the
next major release, what do you think?
[0] https://trac.osgeo.org/grass/ticket/2294
--
ciao
Luca
http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On 23 February 2016 at 17:59, Sören Gebbert
<soerengebbert@googlemail.com> wrote:
Hi,
Hi,
the "-s" flag is in use by many temporal modules for different
purposes in grass71.
yes, could we try to simplify this using -s for only one purpose?
Only the aggregation modules use "-s" flag to signal the usage of
start time as suffix for basename creation.
We should not change all the modules that make use of the flag "-s"
for column name suppression or spatial topology activation.
I would like to suggest that we do not use a flag for suffix
specification, but instead an option for this purpose. Like "suffix"?
The suffix option will specify which type should be created:
* time with full format (time) 2001-01-01T00:00:00
* time depending on the granularity (gran) 2001 or 2001-01 or 2001-01-01 ...
* numerical suffix with a specific number of digits (num + %05, ...)
"_0001" or "_01"
Parameter for the option suffix: "time","num","gran" and C format
specification like "%05" or "%03" in addition to num.
What do you think?
make sense for me, I could implement "gran" and "num" during Paris
code sprint and if I have more time try to work also on "time".
Do you think the C format specification should be in other parameter
or inside the "suffix" option?
Best regards
Soeren
--
ciao
Luca
http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
Hi,
2016-02-23 18:50 GMT+01:00 Luca Delucchi <lucadeluge@gmail.com>:
On 23 February 2016 at 17:59, Sören Gebbert
<soerengebbert@googlemail.com> wrote:
Hi,
Hi,
the "-s" flag is in use by many temporal modules for different
purposes in grass71.
yes, could we try to simplify this using -s for only one purpose?
Only the aggregation modules use "-s" flag to signal the usage of
start time as suffix for basename creation.
We should not change all the modules that make use of the flag "-s"
for column name suppression or spatial topology activation.
I would like to suggest that we do not use a flag for suffix
specification, but instead an option for this purpose. Like "suffix"?
The suffix option will specify which type should be created:
* time with full format (time) 2001-01-01T00:00:00
* time depending on the granularity (gran) 2001 or 2001-01 or 2001-01-01 ...
* numerical suffix with a specific number of digits (num + %05, ...)
"_0001" or "_01"
Parameter for the option suffix: "time","num","gran" and C format
specification like "%05" or "%03" in addition to num.
What do you think?
make sense for me, I could implement "gran" and "num" during Paris
code sprint and if I have more time try to work also on "time".
Do you think the C format specification should be in other parameter
or inside the "suffix" option?
I think it should be part of the option.
Option "num" without number of digits uses a default of "%05",
otherwise the user can specify "num%03" for three leading zeros,
"num%07" for seven leading zeroes and so on. The option parser simply
scans for the keyword "num" and expects either a % followed by
several digits or nothing to use the default "%05".
Best regards
Soeren
Best regards
Soeren
--
ciao
Luca
http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
On 23 February 2016 at 17:59, Sören Gebbert
<soerengebbert@googlemail.com> wrote:
Hi,
Hi,
I would like to suggest that we do not use a flag for suffix
specification, but instead an option for this purpose. Like "suffix"?
I started with t.rast.accdetect, mostly working but
The suffix option will specify which type should be created:
* time with full format (time) 2001-01-01T00:00:00
this is not working, it is returning this problem
t.rast.accdetect input=precip_sum@climate_2000_2012 occurrence=B
start='2001-01-01' stop='2008-12-31' cycle='12 months' basename=b
range=1,10 suffix=time
12
Processing cycle 2001-01-01 00:00:00 - 2002-01-01 00:00:00
Traceback (most recent call last):
File "/home/lucadelu/compilati/grass_trunk/dist.x86_64-pc-linux-gnu/scripts/t.rast.accdetect",
line 589, in <module>
main()
File "/home/lucadelu/compilati/grass_trunk/dist.x86_64-pc-linux-gnu/scripts/t.rast.accdetect",
line 317, in main
maximum_strds, dbif)
File "/home/lucadelu/compilati/grass_trunk/dist.x86_64-pc-linux-gnu/scripts/t.rast.accdetect",
line 531, in compute_occurrence
occurrence_map_id = map.build_id(occurrence_map_name, mapset)
File "/home/lucadelu/compilati/grass_trunk/dist.x86_64-pc-linux-gnu/etc/python/grass/temporal/abstract_map_dataset.py",
line 174, in build_id
name, layer = name.split(":")
ValueError: too many values to unpack
maybe should be enouh to change time format using 2001-01-01T00.00.00
or something similar?
--
ciao
Luca
http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
Hi Luca,
thank you for taking care of this. 
Indeed, a colon ":" must be avoided in map names, since the layer of
vector maps are identified this way (time stamped tables).
I think your suggestion of using 2001-01-01T00.00.00 is a good solution.
Best regards
Soeren
2016-02-24 12:25 GMT+01:00 Luca Delucchi <lucadeluge@gmail.com>:
On 23 February 2016 at 17:59, Sören Gebbert
<soerengebbert@googlemail.com> wrote:
Hi,
Hi,
I would like to suggest that we do not use a flag for suffix
specification, but instead an option for this purpose. Like "suffix"?
I started with t.rast.accdetect, mostly working but
The suffix option will specify which type should be created:
* time with full format (time) 2001-01-01T00:00:00
this is not working, it is returning this problem
t.rast.accdetect input=precip_sum@climate_2000_2012 occurrence=B
start='2001-01-01' stop='2008-12-31' cycle='12 months' basename=b
range=1,10 suffix=time
12
Processing cycle 2001-01-01 00:00:00 - 2002-01-01 00:00:00
Traceback (most recent call last):
File "/home/lucadelu/compilati/grass_trunk/dist.x86_64-pc-linux-gnu/scripts/t.rast.accdetect",
line 589, in <module>
main()
File "/home/lucadelu/compilati/grass_trunk/dist.x86_64-pc-linux-gnu/scripts/t.rast.accdetect",
line 317, in main
maximum_strds, dbif)
File "/home/lucadelu/compilati/grass_trunk/dist.x86_64-pc-linux-gnu/scripts/t.rast.accdetect",
line 531, in compute_occurrence
occurrence_map_id = map.build_id(occurrence_map_name, mapset)
File "/home/lucadelu/compilati/grass_trunk/dist.x86_64-pc-linux-gnu/etc/python/grass/temporal/abstract_map_dataset.py",
line 174, in build_id
name, layer = name.split(":")
ValueError: too many values to unpack
maybe should be enouh to change time format using 2001-01-01T00.00.00
or something similar?
--
ciao
Luca
http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
On 24 February 2016 at 13:36, Sören Gebbert
<soerengebbert@googlemail.com> wrote:
Hi Luca,
Hi Soeren,
thank you for taking care of this.
you are welcome, I hope to need it in the near future 
Indeed, a colon ":" must be avoided in map names, since the layer of
vector maps are identified this way (time stamped tables).
I think your suggestion of using 2001-01-01T00.00.00 is a good solution.
got another error
Processing cycle 2001-01-01 00:00:00 - 2002-01-01 00:00:00
b_2001-01-01T00.00.00 = if(2001_01_precip > 1 && 2001_01_precip < 10,
0.0, null())
syntax error, unexpected '-', expecting '('
Parse error
ERRORE: parse error
Traceback (most recent call last):
File "/home/lucadelu/compilati/grass_trunk/dist.x86_64-pc-linux-gnu/scripts/t.rast.accdetect",
line 588, in <module>
main()
File "/home/lucadelu/compilati/grass_trunk/dist.x86_64-pc-linux-gnu/scripts/t.rast.accdetect",
line 316, in main
maximum_strds, dbif)
File "/home/lucadelu/compilati/grass_trunk/dist.x86_64-pc-linux-gnu/scripts/t.rast.accdetect",
line 567, in compute_occurrence
grass.mapcalc(expression, overwrite=True)
File "/home/lucadelu/compilati/grass_trunk/dist.x86_64-pc-linux-gnu/etc/python/grass/script/raster.py",
line 106, in mapcalc
fatal(_("An error occurred while running r.mapcalc"))
File "/home/lucadelu/compilati/grass_trunk/dist.x86_64-pc-linux-gnu/etc/python/grass/script/core.py",
line 644, in fatal
raise ScriptError(msg)
grass.exceptions.ScriptError: Si è verificato un errore durante
l'esecuzione di r.mapcalc
I will replace '-' with '_' in the time suffix
Best regards
Soeren
--
ciao
Luca
www.lucadelu.org
On 23 February 2016 at 17:59, Sören Gebbert
<soerengebbert@googlemail.com> wrote:
Hi,
Hi all,
I would like to suggest that we do not use a flag for suffix
specification, but instead an option for this purpose. Like "suffix"?
The suffix option will specify which type should be created:
* time with full format (time) 2001-01-01T00:00:00
* time depending on the granularity (gran) 2001 or 2001-01 or 2001-01-01 ...
* numerical suffix with a specific number of digits (num + %05, ...)
"_0001" or "_01"
In r67935 added functions in temporal lib
In r67936 added suffix option in the firsts modules (with testsuite
examples), other coming in the next hours/days
Any tests and comments are welcome
Best regards
Soeren
--
ciao
Luca
www.lucadelu.org
On Wed, Feb 24, 2016 at 7:36 AM, Sören Gebbert <soerengebbert@googlemail.com
wrote:
Indeed, a colon ":" must be avoided in map names, since the layer of
vector maps are identified this way (time stamped tables).
I think your suggestion of using 2001-01-01T00.00.00 is a good solution.
Is it really necessary? Where exactly the colon is used? Is it internal?
Isn't ISO-compliant date-time format good enough reason to change it?
On 24 February 2016 at 13:36, Sören Gebbert
<soerengebbert@googlemail.com> wrote:
Hi Luca,
Hi Soeren,
I think your suggestion of using 2001-01-01T00.00.00 is a good solution.
it seems no 
for vector '.' is not SQL compliant
I would like to use '_' instead '.', but I don't know if it is better
to use it only for vector or also for raster, suggestion?
Best regards
Soeren
--
ciao
Luca
www.lucadelu.org
Am 24.02.2016 15:24 schrieb “Vaclav Petras” <wenzeslaus@gmail.com>:
On Wed, Feb 24, 2016 at 7:36 AM, Sören Gebbert <soerengebbert@googlemail.com> wrote:
Indeed, a colon “:” must be avoided in map names, since the layer of
vector maps are identified this way (time stamped tables).
I think your suggestion of using 2001-01-01T00.00.00 is a good solution.
Is it really necessary? Where exactly the colon is used? Is it internal? Isn’t ISO-compliant date-time format good enough reason to change it?
Nope, it isnt. The colon identifies the time stamped layer of a vector map and is part if its id in the temporal database. We surely do not need ISO conform time suffixes for raster and vector names, since they are not SQL compliant.
Best
Sören
Am 24.02.2016 15:35 schrieb “Luca Delucchi” <lucadeluge@gmail.com>:
On 24 February 2016 at 13:36, Sören Gebbert
<soerengebbert@googlemail.com> wrote:
Hi Luca,
Hi Soeren,
I think your suggestion of using 2001-01-01T00.00.00 is a good solution.
it seems no for vector ‘.’ is not SQL compliant
I would like to use ‘_’ instead ‘.’, but I don’t know if it is better
to use it only for vector or also for raster, suggestion?
Lets use only underscores. They are used for the granularity suffix anyway.
Best
Sören
Best regards
Soeren
–
ciao
Luca
www.lucadelu.org
On Wed, Feb 24, 2016 at 9:42 AM, Sören Gebbert <soerengebbert@googlemail.com
wrote:
We surely do not need ISO conform time suffixes for raster and vector
names, since they are not SQL compliant.
Good point. Not having colon in the file name and vector name is actually a
good idea. Underscores are only save separator.
On 24 February 2016 at 15:55, Vaclav Petras <wenzeslaus@gmail.com> wrote:
On Wed, Feb 24, 2016 at 9:42 AM, Sören Gebbert
<soerengebbert@googlemail.com> wrote:
We surely do not need ISO conform time suffixes for raster and vector
names, since they are not SQL compliant.
Good point. Not having colon in the file name and vector name is actually a
good idea. Underscores are only save separator.
Hi guys,
I'm back on this thread because in Paris I worked more on this and I
could summit changes for map algebra and map calc. There are few error
in the testsuite but I don't know where they come from.
could someone test the attached diff and give some feedback?
--
ciao
Luca
http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
(attachments)
temporal_algebra_mapcalc_suffix.diff (24 KB)