One of the goals of 3.8 was to improve the handling of spatial temporal data. Now the spatial part in ILWIS was of course ok, but the temporal part? In fact, besides some artificial  constructs, ILWIS had no knowledge of time. This makes the handling of data in the temporal domain much harder. So I designed a new Domain : Time.

Domain Time is meant to handle all things related to dates, hourse, seconds etc… It is a derivative of domain Value and at all places were domain Value can be used, domain Time can also be used. This is also true for MapCalc and TabCalc. So it quite possible to add two times together in MapCalc (and also do some operations that make less sense, dividing for example), or deduct times.

Internally Time is based on the astronomical definition of the Julian day (see also http://en.wikipedia.org/wiki/Julian_day). You won’t notice this on the “outside”, as a user, all dates will be represented in a standard format (see below). The Julian day is a day counting system with its zero point in January first, 4713 BC, Greenwich Noon. From that day (noon) all time are calculated. So today (2011-10-17) is  2455851 in Julian days (you can add fractionals to express hours, minutes, seconds). Though this representation is of course not very helpfull for us normal humans and thus is hidden in the user interface, it has one implication that is important ( in MapCalc and TabCalc), the unit of measurement is the day.

The second standard Domain Time is based upon is ISO-8601 ( see also http://en.wikipedia.org/wiki/Iso_time). This is the representation of time followed by the software and also the way ILWIS expects times to be entered. World wide and particular in software, the handling of date/time is very variable with respect to representation. Different calendars, different time standards, different languages makes it all quite messy. To simplify this for both the user and myself as implementor I use only one standard : ISO-8601. All times must be represented in that format and no other. Maybe a bit restrictive but I feel that extra flexibility makes the whole system less transparent. Also the notions of Periods and Durations is comming from that standard. If at any place I don’t support the standard, it’s a bug. So I don’t support times like Mon 17/7/2009 or 15-3-2004. They should be 2009-7-17 and 2005-3-15  or some ISO variants of this. ISO has some extra variations like 20090717 and such that are also acceptable. Read the linked wikepedia page for a more complete description.

So how do we make a DomainTime? The Create Domain form has been adapted

A new item is in the form with which to define the period for which a domain time is valid. In this case it is valid from 2001 the 15th of april 7 hour in the morning up until 31th of december in 2012. All times outside this period get an undefined value. There is also a default time domain (system) that runs from the beginning of the universe until its end (whenever that will be), should be sufficient.

In the program itself it looks like

Time also (as expected) resurfaces with animations. There is there a tab “real time progress” in which you can indicated which column (DomainTime of course) of the attribute table of a maplist is to be used in the animation as time progress. But wait, “attribute table of the maplist”?. MapLists don’t have attribute tables! Well actually, in 3.8 both MapLists and ObjectCollections may have attribute tables. The link between the table and the list is simply the index number of the map.

In the first tab you select the column to be used and define which period every second should be traversed. So in this case : 14 days, 7 hourse is “unit” per second. The animations add this period to an internal timer every second and switch to a new frame when the time defined for that frame (as per attribute column) is passed. The second tab show the progress through time ( and yes there is still a bug there 🙂 ). Animations can also be synchr0nized using “real” time though some more testing would be neede there.

How do you create time columns? The obvious answer would be “by hand”, and this works of course. But when you have a maplist of 156 bands you won’t get very happy with that. Fortunately, often RS data comes with long, unwieldly names where the time information is somewhere in the 200 character long name. I have added an operation “Create Time Column” that parses the information out of that name. Due to the many different ways this information is recorded in the name the user has to indicate where the “parts” are to be found but that is rather trivial. The operation form looks like

If no time information is available, you are out luck. I can’t do magic.

Now the defintion of time is very new to ILWIS. Older stuff may not always support it or display it as a number (it is, after all, a domain value). I think I have nailed down most places (e.g. tables) but ILWIS is rather big, so it always possible that I missed a place.

I feel that the addition of this Domain is important. Time becomes increasingle important when studying dynamic datasets and with this addition a better modelling becomes possible.