Thursday, December 13, 2007

Time In GIS (Survey Control Points And Monuments)

I was working on a GIS data model for Survey Control when I stumbled across a topic that I have been curious about in the past: How do you practically model and manipulate data with a time component, or chronological data, in a GIS?

In this blog post I want to do the following:

[1] Briefly explain how this topic came up during my design.

[2] 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?
What changed?


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
Posted on 12:36 PM | Categories:

Free Java

I stumbled upon an interesting article about the "free Java" effort. OpenJUMP is a program written in the Java programming language, and I use it on Linux, so I thought it would be appropriate to post a link to the article:

http://www.linux.com/feature/122586

The Sunburned Surveyor
Posted on 11:40 AM | Categories:

Monday, December 10, 2007

Open Formats, Open Standards, and Geodata Licenses

There has been some interesting discussion about open formats, open standards, and geodtata licensing at the OSGeo the past few weeks. I thought I would take a minute to post some interesting links:

Here is a blog from a lawyer working on open data licensing. This applies to data in general, not specifically geodata, but some of the same principles apply.

http://www.opencontentlawyer.com/open-data/

Here is a web site that contains an interesting description of the difference between open standards and open formats:

http://opendefinition.org/open_format_definition

It says:

An open format is not:


  • Encumbered by patents.

  • Named using a trademark unless that trademark is usably by anyone under appropriately open terms (to define? - a trademark can be used to protect the integrity of a format, but use should not require payment, even for conformance testing)

  • tied to a particular software implementation (ie. it should be practical to have multiple software implementations)


An open format is:


  • Well and completely documented sufficient to implement a safely conformant reader/writer from scratch.

  • Defined in documentation that is freely redistributable (though the document may be under a license that doesn't allow changes to the spec document)

  • Software language independent (no dependencies on language specific components like "python pickling")


Is is desirable that an open format:


  • have an open source reference implementation for reading and writing.
Posted on 12:38 PM | Categories: