[GRASS-dev] Re: [GRASS GIS] #1562: Introduction of spatial and temporal vertical units for raster3d maps and r3.support

#1562: Introduction of spatial and temporal vertical units for raster3d maps and
r3.support
--------------------------+-------------------------------------------------
  Reporter: huhabla | Owner: huhabla
      Type: enhancement | Status: closed
  Priority: major | Milestone: 7.0.0
Component: Raster3D | Version: svn-trunk
Resolution: fixed | Keywords: r3.support
  Platform: Unspecified | Cpu: Unspecified
--------------------------+-------------------------------------------------

Comment(by cmbarton):

Replying to [comment:7 huhabla]:
> Replying to [comment:5 cmbarton]:
> > Replying to [comment:4 huhabla]:
> > > Replying to [comment:3 cmbarton]:
> > > > That's fine. It is just to use v.vol.rst and other interpolation
modules, the 3D region must be set appropriately. I've run into this, for
example, when I've done space/time cubes using the current voxel support
with dates that run from 4000 BC to the present (that is, -4000 to +2000
in BC/AD or -6000 to 0 in years BP). Perhaps this kind of support is built
in, but will need to be taken into account.
> > >
> > > The GRASS GIS datetime library implementation supports the BC
option, hence "4000 bc" is a valid time-stamp -> r3.timestamp map=map3d
date="4000 BC" simply works.
> > [[BR]]
> > Good. That's important.
> > [[BR]]
> >
> > >
> > > BUT the temporal GIS framework does not support the BC specifier or
negative years due to the limitations of the Python datetime[1] module
which is used internally. All temporal operations and the conversion of
datetime objects into SQL datetime representations and vice verse, depends
on the Python datetime module. The next limitation is that sqlite[2] and
postgresql[3] (they are used as temporal database backend) do not support
the bc specifier nor negative years.
> > >
> > > Hence, creating raster time series using the temporal GIS framework
with dates before 0001-01-01 is not possible, the conversion of raster
time series into space-time voxel maps and vice verse works only for dates
later 0001-01-01.
> > [[BR]]
> > This is a pretty serious limitation for people who work with temporal
change on a regular basis. Most work in years before present (i.e.,
negative years) or BC/AD (mostly archaeologists, but some natural
scientists too; negative and positive years in this case). Since the
datetime library supports this, could there be some kind of workaround?
Note that in the great majority of cases for the people for which this
would be important, the day and month would be irrelevant in terms of
temporal GIS. That is, we are looking at resolutions of years, decades,
centuries, and millennia rather than months, weeks, days, and hours.
>
> I don't think there is a work around in case of absolute time. There are
alternative implementations of the Python datetime library available which
support the BC definition. But the problems are still the SQL backends. To
store date and time as strings in the database is no option, it will
completely destroy the ability to make temporal queries! To extract a
subset of a time series for example:
> {{{
> tr.extract input=my_raster_time_series where="start_date < '2005-01-01
12:30:00'"
> }}}
> will be impossible.
>
> I would suggest to use only relative time in case of negative years
rather than absolute time. This will work consistently with the temporal
GRASS framework and the GRASS datetime library. All temporal GIS framework
processing modules support relative and absolute time. An example:
>
> {{{
> # Some artificial region settings
> g.region s=0 n=80 w=0 e=120 b=0 t=50 res=10 res3=10 -p3
>
> # Create 6 raster maps with r.mapcalc
> r.mapcalc --o expr="prec_1 = rand(0, 550)"
> r.mapcalc --o expr="prec_2 = rand(0, 450)"
> r.mapcalc --o expr="prec_3 = rand(0, 320)"
> r.mapcalc --o expr="prec_4 = rand(0, 510)"
> r.mapcalc --o expr="prec_5 = rand(0, 300)"
> r.mapcalc --o expr="prec_6 = rand(0, 650)"
>
> # Attach the relative time stamp intervals (flag -i) to the raster maps
> t.time.rel --v -i input=prec_1,prec_2,prec_3,prec_4,prec_5,prec_6
start=-4000 increment=1000 unit=years
>
> # Create a raster time series object called space time raster dataset
> t.create --v --o type=strds temporaltype=relative output=precip_rel1
title="A test" descr="A test"
>
> # Register the raster maps in the space time raster dataset
> tr.register --v input=precip_rel1
maps=prec_1,prec_2,prec_3,prec_4,prec_5,prec_6
>
> # Print some information about the space time raster dataset
> t.info type=strds input=precip_rel1
>
> +-------------------- Space Time Raster Dataset
-----------------------------+
> |
|
> +-------------------- Basic information
-------------------------------------+
> | Id: ........................ precip_rel1@PERMANENT
> | Name: ...................... precip_rel1
> | Mapset: .................... PERMANENT
> | Creator: ................... soeren
> | Creation time: ............. 2012-02-03 10:20:25.941134
> | Temporal type: ............. relative
> | Semantic type:.............. event
> +-------------------- Relative time
-----------------------------------------+
> | Start time:................. -4000
> | End time:................... 2000
> | Relative time unit:......... years
> | Granularity:................ 1000
> | Temporal type of maps:...... interval
> +-------------------- Spatial extent
----------------------------------------+
> | North:...................... 80.0
> | South:...................... 0.0
> | East:.. .................... 120.0
> | West:....................... 0.0
> | Top:........................ 0.0
> | Bottom:..................... 0.0
> +-------------------- Metadata information
----------------------------------+
> | Number of registered maps:.. 6
> | Title:
> | A test
> | Description:
> | A test
> | North-South resolution min:. 10.0
> | North-South resolution max:. 10.0
> | East-west resolution min:... 10.0
> | East-west resolution max:... 10.0
> | Minimum value min:.......... 0.0
> | Minimum value max:.......... 0.0
> | Maximum value min:.......... 296.0
> | Maximum value max:.......... 648.0
> | Raster register table:...... precip_rel1_PERMANENT_raster_register
>
+----------------------------------------------------------------------------+
>
> # Time-stamps are stored in the temporal sqlite or postgresql database
> # and as GRASS datetime metadata in the file system
> # Check the correct setting of the GRASS datetime time-stamps by
> # the temporal GIS framework
> r.timestamp prec_1
> - 4000 years / - 3000 years
> r.timestamp prec_2
> - 3000 years / - 2000 years
> r.timestamp prec_3
> - 2000 years / - 1000 years
> r.timestamp prec_4
> - 1000 years / 0 years
> r.timestamp prec_5
> 0 years / 1000 years
> r.timestamp prec_6
> 1000 years / 2000 years
> }}}
>
> > [[BR]]
> >
> > >
> > > [1] http://docs.python.org/library/datetime.html
> > >
> > > [2] http://www.sqlite.org/lang_datefunc.html
> > >
> > > [3] http://www.postgresql.org/docs/9.0/static/functions-
datetime.html
[[BR]]
[[BR]]

This example seems to do what I would need a temporal GIS to do. It
suggests that handling negative numbers is not a problem. So perhaps we
are talking past each other somewhat.

A calendar date (e.g., 6 February 2012) is in fact a relative date
calculated from an arbitrary moment in the past. However, I suppose that
program date functions treat this differently than what you are calling
"relative dates". For most prehistoric/deep time analyses--archaeological
and paleoenvironmental--the kind of relative date that you show above
should serve fine.

In fact, while these are written as a text string (e.g., AD 1235 or 3150
+/- 200 cal BC), using them in a temporal GIS would be much easier if they
were just transformed into numbers (e.g., +1235 and -3150).

This example brings up another issue that may be worth thinking about at
some point. Many age estimates in the deep past are expressed with some
kind of error range (often a mean +/- 1SD or 2SD). Often readers
(including archaeologists) just focus on the mean. But actually, a
calibrated radiocarbon date of 3150 +/- 200 cal BC means that the dated
material has a 65% chance of falling between 3350-2950 BC. This can be
very important when comparing different events. It would be worth thinking
about how to express such uncertainty or at least date ranges rather than
a single date in a temporal GIS so that comparisons between events with
overlapping ranges would be considered as contemporaneous (or even better
contemporaneous within some probability).

The thing is, the concept of actually implementing a production-level
temporal GIS is very exciting and offers a the potential for new kinds of
analyses that have never before been possible.

Michael

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/1562#comment:11&gt;
GRASS GIS <http://grass.osgeo.org>