One of the goals with Ilwis-objects was to update our data structures. The IWLIS 3 design is servicable, but these days things like multi spectral data, spatial temporal data sets, multi-dimensional feature sets are more common than when ILWIS 3 was designed. Not only the data structures for the data sources needed an upgrade, but also the supporting objects like domains and representations.

So what has changed? Well, the maplist for rasters is gone and each raster can be a stack of raster bands by default. An “old” ILWIS 3 map now translates to a raster coverage with one band. The “old” maplist is now a regular raster coverage with a number of bands. All applications (at least where it makes sense) now work on all the bands, so the old MapListApplic crutch is no longer needed. You can still access the single bands of a raster when needed.

The “z” direction, the stack, not a real z, has a domain to conveniently access each band or interpolations of it. The domain can be anything. From the default “count” (so positive integers), to time domains or thematical domains or numeric domains, or ….. The idea is that you request a band of 2009-11-8T12:00 without needing to resolve the time to some index. Note that in between bands,  bands that do not exist (directly) in the stack, will be interpolated according to the z-interpolation model attached to the raster coverage. This has performance consequences.

While the change to rasters is fairly straight forward. Maplist, due to the way the properties were setup, already implied the behaviour described above. Vector data has seen a more radical change. Three important changes are as follows.

1. The former seperation in different layers/maps between points, segments and polygons is gone. A vector map, or feature coverage as it is now called, contains features. Each feature has a geometry which contains the spatial data. This geometry can be point, multi-point, line, multi-line, polygon, multi-polygon. As a result, features with mixed geometry types are possible in a layer. Of course the old “point” map (for example) is still possible. It is just a feature layer with only one type of geometry.
2. Feature coverages don’t have attribute tables. Features have attributes. Apart from a geometry, each feature also has a set of attributes. In practice, this functions very similar to an attribute table, but it severs that hard link between the often artificial domain of an old style vector map and its attributes. Remember the domain “unique-id”, which served no purpose apart from glue? That is gone. Each feature knows its attributes. No glue needed.
3. Features can contain features. Huh? What does this mean? It is, in way, similar to bands of raster coverage, but takes it one step further. Suppose you track the path of an iceberg. Let’s assume for the moment it doesn’t disolve into smaller icebergs. During the whole track, the identity of the iceberg remains the same. I could of course make a track where each measured position of the iceberg is a new feature with a new postion, shape and time stamp. In Ilwis-objects, I can also make one iceberg with sub-features over all the time instances. The “z” direction is a time direction. We could even track it if the iceberg split up, because we simply add new features to the instance where the splitting occured.

Another example is a map of a country. We could represent that as a simple polygon feature with some attributes. But how do we attach the provinces in that country to this polygon? In Ilwis-objects we simply attach sub-features, which describe the provinces, to the polygon. We can continue this process of course. The provinces can be subdived into counties and these again in to municipalities, etc. Basically, we are creating a whole tree of feature sub-divisions. Complicated? Yes it can be. To be honest I have yet to make a decent user interface for this. Fortunately, the base situation, no sub-features, is identical to the way most people see a vector map. So, no worries, most of the feature coverage use is the old fashioned, simple way.

Other changes occured in the domain part. Due to some internal changes in how numbers are handled, Ilwis-objects is much less constrained in value ranges. Basically, all numerical ranges can be easily swapped/converted. Sure there might be side effects, but they are predictable. If you change from a floating point range to an integer range and then back again you have lost the fractional part. This is understandable. There is no longer any difficulty in changing the value range.

Domains can have parent/child relations. This means that a parent domain enforces some rules on the child domain. Its purpose is to create “sub” domains that are compatible with the parent domain. For example. Suppose I have a thematic domain (the former class domain) with 40 items. In a certain coverage, I need only 10 of them. The rest are superflous. So I the child domain contains the 10 items and the parent domain contains all items. Not only are the names now consistent over both domains, but on a deeper level, the domains can be compared to each other. The (child) domain knows that the items in both domains are the same. In ILWIS 3, we could not compare class domains with each other. As such, maps with the same class names but different domains were totally different even if they were semantically the same. Ilwis-objects solves this by the parent-child relation, creating a semantic link.

These are just a few changes we have made when updating our data structures to a more flexible, future-proof model.