Last week I talked a bit about what connectors are supposed to do. As mentioned there, their main task was to translate external representations to internal ones. This week I want to focus a bit on the internal representation. After all, that is what people will use when programming with ILWIS-Objects.

The design of the internal representation leans heavily in some ways on the existing implementation; in other ways, it deviates sharply from that. It was/is maybe somewhat surprising that an 18 year old design is still very relevant these days. At a high level, the data structure has not changed that much. We still talk about data layers and coordinate systems, the problem of the data’s semantics still has to be addressed and tables are still tables. What has changed is the nature of the data itself. Where 2D data was sufficient in the past, we now talk about 3D, 4D and even 5D data. We see the size and availability of data sets explode and we see the complexity of relations between data sharply increasing. So the claim is, while the nature of data certainly has changed, the overall structure has not changed as much.

So what is this structure? What is this ILWIS 3 inheritance which we will more or less port to ILWIS-Objects? The backbone of ILWIS 3 was a set of classes that were all derived from a base class called very creatively : IlwisObject. All major points of GIS/RS data organization were mapped onto classes in that organization. Please see a simplified picture of this below.

The reality was a bit more complex, but this was the gist of it. As such, it is not a very surprising picture, but that is of course a bit deceptive. Good design must be simple (remember the KISS principle). All instantiated ILWIS objects were singletons ensuring integrity of the data across an instance of ILWIS.  The reason this model still works today is that some of the choices of relations between classes ensured sufficient flexibility and extensibility. e.g.

• domains ensured that data and information or maybe semantics of data were fairly loosely coupled. By modifying or creating new domains, we could change what data actually meant without changing the data itself
• georefs formed the bridge between pixels and coordinates ensuring that we could translate between them and thus combine different systems.
• maplists were general enough as a concept to handle spatial temporal and multi-spectral data.
• …

A number of these things seem obvious now, but in 1995 this was less so.

The organization says nothing about the nature of the data and that certainly has changed or at least changed in importance. For example, a maplist, which is a stack of raster maps is actually almost identical to a raster-map. Apart from the little detail that it is a rastermap with multiple (indexed) values for each pixel, it is the same. So why not make them the same? This unifies the whole multi-temporal, multi-spectral and regular raster maps world. Operations will work across this “spectrum”.  And yes, of course, you can still access and use the individual bands.

Because the “indexed” dimension is mapped to a domain (after all, indexes do have a meaning), we can extend the meaning of the indexes to, for example, fractional indexes mapping to interpolated “in-between” maps. Did this change the rastermap, the class, itself? Hardly, its main organization is still the same. It still has a georef and a domain. It still is a gridded collections of pixels. What is inside this pixels has changed (well in some cases at least).

There are other modernizations in the classes, e.g. an interesting one is the new organization for vector data (stuff for the next blog), but I feel relatively confident that I can map any external representation to this (adapted) internal one. The new picture is as follows (again, somewhat simplified).

This looks very similar to the 1995 picture.

The next blog will be about the new organization vector data. It will probably be out in two weeks, due to some time off on my part.