The core of each GIS is of course built around the spatial data (duh). So how we access that data (on a programming level) should be of prime importance when designing Ilwis-Objects. Some people would argue that the organization of data is of prime importance but I don’t agree with that. Organization should be a technical derivative of how I want to access my data. I don’t care if there is a database behind my interfaces or a file based system or a service or…. I just want to do things with my data. Organization is important, but only insofar it serves the interfaces.
So what do I require of my interfaces?
- They must be simple! ( remember KISS). This is probably the hardest point. Paradoxical as it may seem but it is far easier to develop a complex set of interfaces than to develop a simple one. Complexity breeds complexity and thus grows at a very fast pace.
- Things that are the same should be the same. This is a cryptic point as it states something obvious. Still, I seldom see a very rigorous implementation of this in the software I am familiar with. E.g. is a (Ilwis3) maplist the same as a rastermap were only the nature of the pixel value is different ( a array instead of a single value)? Arguably yes, so why are there different classes? It gets more interesting with vector maps. Is a point different from a polygon or are two spatial different points always different things? I will investigate this one further down below
- Natural integration within the C++ STL style of programming. The STL is a core library of C++ that (among other things) abstracts algorithms from data types. The reason why this is important is that it generalizes and simplifies the way how we can write algorithms tremendously. For example I rewrote the resample algorithm from over 150 lines of code to 8 lines of code.
