It has been a long time ago since I wrote a blog entry. But I feel it is time to restart the ILWIS blog. Why? you may ask. Well mostly because there are interesting things happening. ILWIS 3.8.5 is around the corner. This is mostely a bug-fix release, but in a big way. ILWIS 3.8, let’s be honest about that, had too many bugs. Though 3.8 offered some very nice extras and more performance for visualization, it also introduces some nasty bugs. It’s the price you pay for working without a safety net of somebody who does Q&A (programmers are notoriusly bad at that).

Fortunately our management understood that and freed some extra resources (read in this case time) to fix that. The result is ILWIS 3.8.5. We fixed most of the nasty, unpredictable bugs. Re-enabled some (but not all) of the functionality that was missing from 3.8.4. Most likely there will be an ILWIS 3.8.6, which finish the 3.8 line for Ilwis. After that  we will switch completely to something we call Ilwis-objects.

Ilwis-objects is a completely new development of the Ilwis software. Due to technical limitations of ILWIS 3 and due to the fact that the core of the software is getting quite old (ILWIS 3 is 15 years old, 20 even, as it evolved from ILWIS 2), it was time to plan ahead. We had a number of requirements.

• It should be multiplatform. ILWIS was created on a windows platform. Though windows is still a dominant platform there are other options. Mac and Linux, but also the mobile world. This is technically impossible in the code base of ILWIS 3 as it very strongly tied to windows.
• It should be agnostic with respect to the physical format of data. We all know the wonderful world of import and exports. That is something we wanted to avoid in ilwis-objects. It should consider all (within realistic limits) formats as “native”.
• It should be agnostic with respect to the location of data. This is basically already implied by the previous requirement. Local data, database, service. It shouldn’t matter. It is the data that matters not its location.
• It should be agnostic with respect to its processing sources. With this I mean that it should be able to integrate other processing sources in such a way that users of ilwis don’t notice if it is an ilwis native processing or “foreign” processing. Note that this also holds true for services.
• Ilwis should be deployable in multiple roles. ILWIS 3 is of course a desktop program and that is fine. Desktop clients are useful. But we also want Ilwis to run as a server side process for processing and rendering services. We also want Ilwis to function as a library, to intergrate within other enviroments.
• The (internal) data structures should better reflect the current way of how GIS and RS data is offered and organized.
• It should be easier for other programmers to attach their own functionality to Ilwis and participate in the development of Ilwis. ILWIS 3 was never designed with open source in mind. It became open source later in its life cycle and it shows. Though the internals of ILWIS 3 are quite flexible they are also at times very complex. No problem if you have worked for years in that framework, a serious problem for all newcommers.
• ILWIS 3 doesn’t support unicode. This makes translations to same languages difficult.

With this list of requirements and the need to continue the ILWIS 3 line (for the time being) we started ilwis-objects 18 months ago. So what did we achieve in that time?

• The core of the Ilwis-objects framework is created, runs and is more or less done (apart from some debugging).
• We created an Ilwis-objects to Python bridge. This enables us to access Ilwis functionality (e.g. mapcalc) from python and also to use python as the scripting language of Ilwis.
• Using the technology of the Python bridge we created in the context of a Google Summer of Code project a similar java bridge. So ilwis-objects functionality can be used in java.
• The core of a desktop client for Iliws-objects, Ilwis4, has been created.

So what is missing? Still quite a lot. Sure mapcalc works and some of the applications have been ported, but the bulk needs to be done. Will we port everything? Probably not. Ilwis-objects is very well suited for integrating “foreign” libraries in a transparent manner, so as long as I can find similar functionality in other libraries I’ll use it. I already integrated libraries like opencv and the gnu scientific libraries. Others like orfeo, cgal and R are on the list. Note that all these kind of integrations (also true for the data formats) are in a plugin structure. So all things are optional.
Fortunately we get more working capacity at the end of this month since extra people will (temporarily) join the team. As it now stands, we hope to get a first release towards next summer.

In this blog, I want to report about the progress in this process and show what Ilwis4 is capable of. I will push an entry every one or two weeks until the release. As a little preview to where we are at the moment; here is one of the views on Ilwis4.