In this blog post I want to do the following:
 Briefly explain how this topic came up during my design.
 Point out some interesting tidbits I found about working with “temporal data” or data with a time component in GIS.
How I Found Time
In the current version of my Survey Control GIS Data Model a Survey Control Point is a spatial feature that has associated non-spatial features like a position or coordinates. One of these non-spatial features that is associated with a Survey Control Point in the data model is a Monument. The monument is the physical marker that represents the Survey Control Point. In the data model a Survey Control Point may be represented by more than one monument. (Monuments can be damaged, destroyed, and replaced or reset over the course of time.) However, a Survey Control Point can only be associated with a single Monument at one point in time. In other words, you can’t have two monuments installed on a Survey Control Point at the same time.
I started to think about how the association, or relationship between Survey Control Points and Monuments could be represented. I thought I could include attributes on the Monument feature like Date Installed, Date Destroyed, and Date Reset. After some thought I didn’t really like this idea, because I would end up with Monument features that had valid Date Installed values, but null Date Destroyed and Date Reset values. This isn’t a horrible problem, but usually a large number of attributes that will have null values in an implementation leads me to conclude I need to do a better job normalizing my data model design.
An Article On Time And GIS
It turns out someone wrote a whole book on Time and GIS. (I didn’t buy it. Not yet anyways.) It also turns out that most material available on Time and GIS deals with ESRI products. (No surprise there…)
Still, I found an article online that presented some interesting tidbit on Time and GIS. I want to share them here. The first tidbit deals with the most common approach to managing time in a GIS.
Tidbit One (1):
“If every map represents a temporal snapshot, then the only way in which to study temporal progression is to compare a series of maps; one with the next. Both paper and electronic methods make this simple stacking of time slices possible, but neither truly enable the researcher to model progression through time, whether mapping the change or interpolating values that may be assumed to exist between snapshots. In order to truly manipulate data from the fourth dimension, a different method is required.”
It sounds to me like the typical way to work with time in a GIS is by manipulating time slices. It seems I remember reading about this approach in my book about GML 3.
I didn’t think this approach was really what I needed. It sounded a little too complicated, and didn’t exactly fit my problem with the relationship between Survey Control Point features and Monument features very well. I’ll talk more about that in a minute.
The article identified some other ways GIS try to model temporal data, which includes text, graphics, or temporal symbols added to a map and animations.
Tidbit Two (2):
The second tidbit helped me identify some of the questions I was trying to answer about time and my two (2) features.
Here are some of the questions that were listed in the article:
Where and when did change occur?
What types of change occurred?
What is the rate of this change?
What is the periodicity of this change?
How much did it change?
Tidbit Three (3):
The article also identified some of things we are trying to find and/or understand when we work with temporal data in a GIS:
The existence or absence of temporal patterns.
The identification of trends.
Understanding processes that occur over time.
A Solution Borrowed From Object-Oriented Programming
I often discover solutions to real world business or GIS problems that are based on concepts and techniques I have learned as an object-oriented programmer. (I think this may be one advantage a programmer has over RDBMS folks when it comes to GIS design.)
In this case I realized that what I needed was an abstraction, or simplified model of time for my GIS. (A lot of good object-oriented programming is about finding and modeling abstractions of the real world in your program.) A lot of really great GIS programs work with two-dimensional spatial data even though we really live in a three-dimensional world. What I needed was “two-dimensional time”, or a simple way to represent temporal data in by GIS data model.
I believe a possible solution to this problem can be borrowed from object-oriented programming. The solution is the concept of an “event”. Events are a common GUI or graphical user interface programming element. (For example, when the user clicks on a button this generates an event. The programmer can then write code that responds to this event.)
What I really wanted was to included events in my GIS data model. I needed the following events:
Monument Installed Event
Monument Damaged Event
Monument Destroyed Event
Monument Reset Event
Monument Repaired Event
Now I wasn’t dealing with a lot of null-valued attributes, and I had something more that just a date attribute in the Monument feature.
I still need to do a lot more research and work on this approach. When do you need an event, and when can you just have a feature with a Date and/or Time attribute? What type of tools could work with events? What type of questions could I answer with events? How would geospatial events be defined in a GIS data model.
I’ll post more information on this topic as I work through this challenge on the Survey Control Point GIS Data Model and another data model I am currently working on.
The Sunburned Surveyor