Introduction of spatial and temporal vertical units for raster3d maps and r3.support

[huhabla]

I need to add vertical units support to raster3d maps to distinguish between voxel cubes with 3 spatial dimensions or space-time voxel cubes with two spatial and one temporal dimension. These units may be spatial or temporal, based on unit definitions introduced in gis.h, datetime.h and lib/gis/units.c. This results in several modifications in lib/gis and lib/raster3d and lib/python. The current raster3d header format will change, but backward compatibility is assured. I have attached a patch including the new module "r3.support".

The temporal units and the top-bottom resolution can/will be used as relative time using the datetime library and the temporal GIS library to allow spatio-temporal space-time cube processing.

The module r3.support allows the creation/modification of title, description, history and spatio-temporal units for raster3d maps.

[huhabla]

The vertical units and r3.support patch for grass7

[cmbarton]

From a conceptual perspective, this seems like a reasonable idea. How will this be integrated into g.region, where you currently need to set top, bottom, and resolution parameters for r3d to work correctly?

Michael

[huhabla]

Replying to cmbarton:

From a conceptual perspective, this seems like a reasonable idea. How will this be integrated into g.region, where you currently need to set top, bottom, and resolution parameters for r3d to work correctly?

Michael

g.region must not be modified, as the vertical unit definition is a kind of metadata and can only be set using "r3.support" or in C-code using "Rast3d_set_vertical_unit()". The gis library provides convenient functions to convert spatial units into each other, but there is no general relation between space and time in Newtonian perspective. Hence the automated conversion of temporal units into spatial units and vice versa is impossible. In my implementation the specification of vertical units for voxel maps is optional and does not interfere the region settings. Hence, the user must assure that the top-bottom resolution and depth region settings are set accordingly to his vertical unit definition. Units (data and vertical) are part of the metadata and will help the user to better understand the data and will help specific GRASS modules to exchange unit information in coupled processes.

I will implement modules which will use the vertical unit definition to convert raster time series into space-time voxel maps and vice versa. The granularity of the raster time series, which is in case of the temporal framework a relative time unit measured in years, months, days, hours, minutes or seconds, will be used to set the top-bottom resolution. The bottom value is always set to 0 and the top value results from the multiplication of the top-bottom resolution with the number of granules in the raster time series. The vertical unit is set to the relative time unit of the granularity. r3.timestamp is used to set the start date of the space-time voxel map. When converting a space time voxel map into a raster time series, the start date of the voxel map is used as start date for the bottom raster map, the top-bottom resolution in combination with the vertical unit definition is the interval between the converted raster maps, counting from bottom to the top.

Modules to identify spatio-temporal patterns in space-time voxel maps will also benefit from vertical unit settings as well as spatio-temporal interpolation modules like v.vol.rst.

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

Michael

[huhabla]

Replying to 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.

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.

[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

[cmbarton]

Replying to huhabla:

Replying to 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.

Good. That's important.

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.

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.

[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

[mmetz]

Replying to huhabla:

Replying to 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.

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.

[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

In theory, there is some support for BC years in postgresql [1]. About date and time in different database backends, I found not a lot of consistency. Postgresql for example knows as date/time types timestamp, date, time, interval, whereas mysql knows date, time, datetime, timestamp, year. DBF in some versions knows date, but not the dbf driver in shapelib used by OGR and GRASS. Sqlite does not have a dedicated date/time type, but internal date/time manipulation functions. In short, this seems to me a bit of a mess, and I would suggest to store within GRASS date/time as string and use the GRASS datetime library for date/time manipulations. Makes sense?

Markus M

[1] ​http://www.postgresql.org/docs/9.0/static/datatype-datetime.html

[huhabla]

Replying to cmbarton:

Replying to huhabla:

Replying to 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.

Good. That's important.

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.

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

[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

[huhabla]

Replying to mmetz:

Replying to huhabla:

Replying to 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.

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.

[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

In theory, there is some support for BC years in postgresql [1]. About date and time in different database backends, I found not a lot of consistency. Postgresql for example knows as date/time types timestamp, date, time, interval, whereas mysql knows date, time, datetime, timestamp, year. DBF in some versions knows date, but not the dbf driver in shapelib used by OGR and GRASS. Sqlite does not have a dedicated date/time type, but internal date/time manipulation functions. In short, this seems to me a bit of a mess, and I would suggest to store within GRASS date/time as string and use the GRASS datetime library for date/time manipulations. Makes sense?

Strings are no option in case of date/time database storage, see my last response to Michael Barton about this issue. But the GRASS datetime library uses already strings to store the time-stamps in map(layer) specific metadata files. These strings can be directly processed with the GRASS datetime library and can be interpreted by the temporal GIS framework.

I use the SQL DATETIME column type in sqlite and postgresql to store Python datetime objects, as booth support this type and the conversion. I do not use TIMESTAMP in postgresql as this will result in different SQL scripts for each backend to create the temporal GIS database structure ... and that will result in a mess.

Soeren

[huhabla]

Patch has been applied. Many thanks for your comments and the discussion.

Soeren

[hamish]

Replying to comment 9:

Hi,

if you take ownership of a ticket you have to manually add the grass-dev mailing list the cc field, or else no one gets to see this long discussion is happening at all.

I've some minor comments/changes to request which I'll post in the coming days. First and shortest is that we should break the long held two-dot rule (for these modules) and name them like t.r3.*.*. That is much less-bad than introducing many new top level abbreviations for module which essentially have a common root.

thanks, Hamish

[cmbarton]

Replying to huhabla:

Replying to cmbarton:

Replying to huhabla:

Replying to 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.

Good. That's important.

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.

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

[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

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

[huhabla]

Hi Hamish,

Replying to hamish:

Replying to comment 9:

Hi,

if you take ownership of a ticket you have to manually add the grass-dev mailing list the cc field, or else no one gets to see this long discussion is happening at all.

Thanks for the info Hamish, this always confuses me a lot and i think i will never get it right ... .

I've some minor comments/changes to request which I'll post in the coming days. First and shortest is that we should break the long held two-dot rule (for these modules) and name them like t.r3.*.*. That is much less-bad than introducing many new top level abbreviations for module which essentially have a common root.

That's an interesting approach.

If you want i can send you the current state of the promised tutorial (inclusive all errors, misspelled words, uncertainties, ...), so you can get an idea of how the temporal GIS framework will work and what modules are implemented and planed.

I think i need 2 - 3 weeks to finish the tutorial to reflect all recent changes i made in the temporal framework. When its finished i will distribute it to interested developers.

Soeren

thanks, Hamish

[huhabla]

Replying to cmbarton: [snip]

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.

I use the absolute and relative time definition of the GRASS datetime library which is a common concept in temporal GIS: 1) Absolute DateTimes express a single time or date referenced to the Gregorian calendar (e.g. 14 Feb 1995) [1] 2) Relative DateTimes express a difference or length of time (e.g., 201 days 6 hours) [1]

[1] ​http://skagit.meas.ncsu.edu/~helena/gmslab/htdoc/time/index.html

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 temporal GIS framework allows the use of interval time. You can add relative or absolute time intervals to raster, raster3d and vector maps and register them in space time datasets. Hence maps with overlapping time intervals are supported in space time datasets. These intervals may represent the uncertainty? The temporal relations between the registered maps can be computed using t.topology[1]. It is possible to sample space time datasets with each other[2].

[1] ​https://trac.osgeo.org/grass/browser/grass/trunk/temporal/t.topology/test.t.topology.reltime.sh

[2] ​https://trac.osgeo.org/grass/browser/grass/trunk/temporal/t.sample/test.t.sample.sh

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.

I hope that the temporal GIS framework will be very useful indeed.

Sorry for undocumented modules and tests, but i need first to get the temporal GIS paper ready before adding to much information ... .

Soeren