We’ve heard how the cyberinfrastructure handles temporal and spatial data separately, but must be developed in such a manner that allows for users/researchers to utilize both sets of variables when interacting with a GISystem. Now Gail Langran and Nicholas Chrisman provide an interesting overview of the topological similarities between time and space, and how best to design a GIS system which can accurately display temporal elements.
I find the authors’ notions of time and its important elements to be a overly simple in a way that helps to lend credence to their subject. In particular, they characterize cartographic time as “punctuated by ‘events,’ or changes” (4). Furthermore, they do a nice job contrasting GIS algorithms based on questions concerning space (what are its neighbors? what are its boundaries? what encloses it? what does it enclose?) with the similar questions one might ask for time (what was the previous state or version? what has changed? what is the periodicity of change? what trends are evident) (7). Such examples help to define this paper not just as a discussion of temporal data, but also of temporal data based closely to its application in geographic space. Such an added dimension can be incredibly important when we begin to think about all of the geographic phenomenon that occur over differing timelines. It’s also an element we should try to remember more in our own research efforts.
I do wonder about the distinction the authors draw between real world time and database time. Since many GIS databases are headed toward real time, streaming data – as was pointed out in previous lectures – why make this distinction? Perhaps I’m not technically inclined enough to understand the importance of the difference in programming or maybe it’s just a matter of how the system might store information. Anyone have thoughts on why real time data can’t be used in a manner that equates it to database time?
–ClimateNYC
The current practice is acquire data and amend/edit it as necessary later on. Keeping track of both world and database time makes later revisions transparent and acknowledges uncertainty about that specific entity at that specific time stamp. Also helps when you are mixing various data sources after they’ve been acquired for your own applications.