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

GRASS GIS trac at osgeo.org
Mon Feb 6 12:35:31 EST 2012


#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 at 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>
GRASS GIS <http://grass.osgeo.org>



More information about the grass-dev mailing list