Overview: The Next Generation ILWIS

Jump to: navigation, search
Main Page Arrow.png Overview Arrow.png The Next Generation ILWIS
System Overview What is new in ILWIS Drag and drop highlights Python extension
An overview
Some of the roles for developing ILWIS NG

The objective of the Next Generation (NG) ILWIS is to create a framework that allows a seamless integration between heterogeneous data sources and processing sources. The framework will allow us to create applications that are largely independent of the format/nature of the underlying data containers or processing sources. Particularly we are thinking about:

  • Scripting environment for accessing and manipulating GIS data containers in a more “database” like way (such as anchored in Python).
  • Desktop environment for integrating remote and local sources of data and processing
  • Geo - Processing engine in a web server environment. Exploration of P2P, distributed processing.

The secondary objective is to create a UI toolbox to facilitate an easy way to create a user interface for applications using ILWIS NG. Since the advent of mobile devices the concepts of UI design has seen a lot of movement after being fairly static for the last 10 years.


The diagram above, illustrates some of the roles used to deployed the ILWIS NG. It is clear that not all these roles will be realized (at first, if at all). The brief text bellow give more details of these roles:

  • Processing server; A role for ILWIS will be as a processing server for computational intensive tasks. ILWIS has then the task for scheduling and executing the algorithm(s). If the algorithms allows it, the algorithm will be scheduled over multiple cores and potential multiple machines. The processing server is of course accessible from both desktop and browser environments. This is typically a case were data sources will be somewhat heterogeneous as standardization is progressing but certainly not Omni present. In this context one could also look at GPU integration (OpenCL, as prime platform) though this platform dependent (NVDIA). The processing server is able to run in real time modus of offline modus.
  • Desktop application; The traditional role of ILWIS is of course the desktop application. At the moment this is generating the most revenue (projects) and it is expected that this will continue for the next years. Apart from pure functionality (connectivity to local/remote data and algorithms) a client must also have a well-designed user interface. In this respect ILWIS NG desktop could play a useful role(due to its connectivity) in opening up FOSS projects that have limited user interface.
  • Scripting & programming; ILWIS must also be able to play the role of programmatic tool-box to expose its functionality to other programming environments like Python and Java(both client as server side). In this role one can see ILWIS offering its own functionality as well as (through) ILWIS access to other (external) processing that doesn’t offer an easy to use interface by itself.
  • Mobile; The impact of mobile devices will continue to grow in the coming years. With this comes the need to be able to get data and processing from sources based in the cloud. ILWIS NG must be prepared for this. In this case one could think of tailored apps for specific problem domains. It is possible to deploy ILWIS NG based apps on all major mobile platforms as they all accept C++ as native language.
Possible scenarios
  1. ILWIS runs in the container of an application server and its functionality is requested as service by outside clients. The protocol(s) supported by Ilwis are dependent on which set of connectors(see later, the sets may vary as they follow a plug-in model) this ILWIS Core supports. A reasonable choice as first implementation is a WPS connector to access processing facilities. Note that there are many heavy duty processing libraries that can only be accessed locally ( e.g. ossim, orfeo). ILWIS can, in this scenario, be the enabler to lift this functionality to the internet.
  2. Ilwis runs as component/client on a mobile device and is able to connect to the internet for additional services/data. In this case one could think of tailored applications for field work which might need some background data from a remote source or for data collection.
  3. E.g. (real case), we once wrote an application(non Ilwis) for a pda to estimate in the field (a.o.) bio-masses of trees. One of the error preventing methods involved comparing current data with previous data which had to be stored per lot. It would have been much easier if there was some remote source of historical data that could be accessed.
  4. Ilwis exposes its (ILWIS)interface (probably c-interface, though python (written in c++) also accepts pure c++, and can be used as additional language module in other languages.
  5. Ilwis accesses local data-sets as native. The current version(3.8) of Ilwis is able to this in a way but its implementation is due to the complex doc/view structure of MFC clunky and difficult to extend.
  6. The traditional Ilwis desktop client
  7. Ilwis as a desktop client accesses remote data sources

Note that this only illustrates some of the scenarios, more scenarios could be drawn to illustrate additional roles. The basic requirements we learn from this Connectivity is the key word

  • At a resource (data/operation) level
  • At programmatic level ( to other languages)
  • At client level ( to the user)

There is no fundamental difference between local and remote data/services. The existing differences are at a protocol level and thus must be hidden for the use of software.