[GRASS-dev] Temporal framework: Proper way to register new maps from a python module?

[Laurent C.]

Hi Sören,

Thank you for your answer. I've made some tests with the second option
and it seems to works well. It looks like I don't need to use
.update() or .insert() before registering the RasterDataset list in
the DB. Could you please confirm that it is unnecessary?

Regards,
Laurent


2015-10-09 22:45 GMT+01:00 Sören Gebbert <soerengebbert at googlemail.com>:
> Hi Laurent,
> please do not use the legacy r.timestamp module to set the time stamp
> for maps. The feature to use time stamps set by r.timestamp was only
> implemented, to migrate from old grass locations with time stamped
> maps to the temporal framework approach more easily. I am not sure if
> this works well with relative time.
>
> The easiest way is to generate a text file with name, start time and
> end time. If you insist to avoid using text files, then generate a
> list of RasterDataset[1] objects, set the time for these objects
> (set_absolute_time() or set_relative_time()) and use
> register_map_object_list() [2] to register them in a space time raster
> dataset.
>
> [1] https://grass.osgeo.org/grass70/manuals/libpython/temporal.html#temporal.space_time_datasets.RasterDataset
> [2] https://grass.osgeo.org/grass70/manuals/libpython/temporal.html#temporal.register.register_map_object_list
>
> Best regards
> Soeren
>
> 2015-10-09 17:13 GMT+02:00 Laurent C. <lrntct at gmail.com>:
>> Hello,
>>
>> I'm writing a module that generates raster maps and register them in
>> newly created strds.
>> The temporal type of the generated strds depends on the entry values
>> of the module.
>> I've seen in the documentation that
>> register_maps_in_space_time_dataset() can read the timestamp from the
>> GRASS raster, so my module is currently doing the following:
>>  - writes maps
>>  - assign timestamp, either absolute or relative with r.timestamp
>>  - at the end, register all the generated maps from a list using
>> register_maps_in_space_time_dataset()
>>
>> But I end up with the following error with relative time:
>> File "/home/lo/Programación/t_sim_flood/gis.py", line 286, in
>> register_maps_in_strds
>>     strds_id, maps=map_lst_str, unit='seconds')
>>   File "/usr/lib/grass71/etc/python/grass/temporal/register.py", line
>> 289, in register_maps_in_space_time_dataset
>>     statement += map.insert(dbif=dbif, execute=False)
>>   File "/usr/lib/grass71/etc/python/grass/temporal/abstract_map_dataset.py",
>> line 273, in insert
>>     self.write_timestamp_to_grass()
>>   File "/usr/lib/grass71/etc/python/grass/temporal/space_time_datasets.py",
>> line 242, in write_timestamp_to_grass
>>     self._convert_timestamp())
>>   File "/usr/lib/grass71/etc/python/grass/temporal/abstract_map_dataset.py",
>> line 124, in _convert_timestamp
>>     start = datetime_to_grass_datetime_string(start_time)
>>   File "/usr/lib/grass71/etc/python/grass/temporal/datetime_math.py",
>> line 817, in datetime_to_grass_datetime_string
>>     if dt.tzinfo is not None:
>> AttributeError: 'NoneType' object has no attribute 'tzinfo'
>>
>> The grass timestamp are well written and are visible with r.info.
>> If I give a start=0 to register_maps_in_space_time_dataset(), all the
>> maps are registered in the strds without generating errors, but they
>> all starts and ends at 0:
>>  +-------------------- Relative time -----------------------------------------+
>>  | Start time:................. 0
>>  | End time:................... 0
>>  | Relative time unit:......... seconds
>>  | Granularity:................ 0
>>  | Temporal type of maps:...... point
>>  +-------------------- Spatial extent ----------------------------------------+
>>
>> And the raster timestamps are overwritten.
>> I haven't tried yet with absolute type.
>> How should I proceed? Is there a way to avoid generating a temporary
>> text file to feed register_maps_in_space_time_dataset()?
>>
>> Regards,
>> Laurent
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev