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.