PC World Australia
interviews Liam Speden, product manager for MapGuide about Autodesk's recent acquistion of CS-Map from Mentor Software and its decision to turn that code over to the Open Source Geospatial Foundation. Some of the more interesting comments from Speden:
- coordinate systems will soon include time (huh?)
- a common set of code will enhance compatibility and thus improve quality and reliability in mobile services
- the code can enhance things like Geonames (I'm not sure the questioner knows that that is)
- it's good MapGuide Open Source and MapGuide Enterprise will use the same code down the road
- it offers more than Proj-4 (the existing widely used open source projection library)
- donation to be finalized by end of the year
- not one, but two mentions of The Urban Forest Map in San Francisco (there's got to be another user out there to profile!)
I am aware of time in metadata and time modeled in GIS products. I am not aware of how it'd be handled in projection engines and thus coordinate systems. Perhaps you can explain Mr. Speden's comment: "In the future coordinate systems will incorporate additional factors such as time..."
Adena
Time is relative to coordinate space. It is inherent within the grid, yet it's never really been included as a standard within the coordinate system. To have time tie-in to all things, whether data, images, metadata, text, RSS, GeoRSS, KML, GML, Models, Collada, blah blah, yada -- adds a distinct value and range of possibilities for use.
Currently, time is considered more of an additional layer on top of what exists. By including time within the coordinate system itself -- you eliminate the need for extra information, and eliminate error as the time associated with location can be calculated more accurately -- more precisely. That creates a wide range of possible uses.
Imagine, that if you reproject your UTM satellite image to Mercator, Adena. Why would time not reproject with those pixels as well? Time is indeed relative to pixels on the map, afterall.
As an example.:
Imagine you have raw data from a sensor. Now, you want to calibrate this image in the most accurate way possible. The sensor has already given you some sense of time and space, so that you can more accurately process the image -- but what if... What if you can calibrate each pixel to time?
Okay, so now you've calibrate an x/y coordinate pixel with a certain time. You have azimuth information, angle, position, sun-angle, everything is relative to time and distance and speed and all these things that factor in.
By calibrating the pixel to time, you have a constant which creates the most complete of possibilities for processing any image from a sensor. You can now probably find ways to fully automate tasks in production ware that you were previously unable to do -- you can probably extend your methodologies in how you calculate, and what kinds of informations you can even pull-out of the image.
In 1988 when CS-MAP was invented, nobody really knew where anything was with enough precision to care about the “era” or the “epoch”.
The explosion of applications that can make use of time has created a demand for time to become a parameter (i.e. part of the coordinate system) rather than an attribute (i.e. a part of the description) of the event. The ubiquity of location-based services and navigation systems means that people are much more “spatially aware” than even 5 years ago, and are thus much more comfortable with geo-tagging things not only as to location but as to when.
The “new stuff”, i.e. CS-MAP rewritten in C++ (aka CS_MAP++, Cartomatix) was four dimensional from the start. The fourth coordinate, referred to as “era”, is the time at which the specific object was at the indicated location. These times are expressed in years and fractions thereof. Thus, 12:00 midnight on January 1, 2007 would be given as a real number 2007.00000. July 1, 2007 would be something like 2007.500.
There are very few transformations which now how to deal with time, but they do exist. One is implemented in Cartomatix. Eventually, most all spatial data repositories will need to record not only where and object is, but when it was there.
I was thinking how this would apply to a vector layer, like soils. Let’s say, one of the attributes needed was the time/date of when the information was created. Why would I store multiple times/dates within the same data set at the coordinate level instead of the feature level? As far as I know, a person can't select features based on a certain time in a single data set from a coordinate file.
Or this more suitable for raster data sets? If so, again, why not store the time/date with each pixel? The way some sensors collects data(like pushbroom), each pixel row is technically a different time. So is the difference in time not wide enough to worry about? That’s why it makes no difference where the time/date is stored in a raster data set? Or is it simiply the sensor can't encode the time/date at each pixel as it goes along?
Maybe the time/date should be stored at both levels. I don't know enough about incorporating time in data sets at the coordinate level. Hence the questions.
KoS