The objective of the ILWIS NG 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 (probably 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. This is an interesting area of exploration.

• 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 there) 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.

The diagram illustrates some of the roles Ilwis NG might take when deployed. It is clear that not all these roles will be realized (at first, if at all).

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.

The envisaged structure and placement of component(types)

• Data-sources. This block represents sets of components that link to specific types of data sources. They are independent of each other and are loosely coupled to the system. Functional they must do a translation of external data representation to internal data representation to ensure a common view on the data internally.
• Toolboxes. Connectivity to services/processing. Similar to the previous block this represents the mapping of external representation of processing into an internal (usable) one. The processing remains of course in the original source but by creating a general representation of it, other components may have access to it in a transparent way.
• Connectos. Translation layer that maps external representation of data/services to an internal one and vice versa.
• Framework. This is a set of components that provides the command and control for the Ilwis framework. Functionally it maps requests for processing to the relevant components. It maintains a catalog of available processing functionality to be able to do this. It also maps requests for data to the correct connector(see later) to access the (native) data container. It maintains a catalog of available data containers. Provides a lookup for which data/processing source(s) are known to the system. The data interface of the fundamental data types (spatial/tables etc..) that core of ILWIS uses.
• Connectivity to programming languages. The core of ILWIS NG is programmed in C++. But this is a rather technical language and not suitable for programmers that are used to scripting environments. ILWIS NG will expose a C – interface that can be used to build a bridge between other programming environments. The first bridge to be build is towards Python.
• Client(s). Exposes functionality/ data accessible through the framework to the end user. As UI’s are often not trivial to create, the framework will provide a set of building blocks to facilitate this ( of course strictly separated from the rest).

The Ilwis-objects framework plays a central role in this picture. The framework has basically three parts

• The Ilwis-objects ( see ILWIS Objects overview)
• The MasterCatalog
• The Connector concepts

The MasterCatalog is a repository were all data/processing-sources ilwis has ‘seen’ are registered. A data source is anything that can be translated into an IlwisObject. Ilwis scans folders, queries remote sources through its catalog connectors to discover which data sources can be found at the location. The sources it can recognize are stored as ‘Resource’ in the MasterCatalog. Each connector has its own way of doing this ( a file is different from a WMS layer but they end up as Resource in the MasterCatalog). The MasterCatalog is stored as a database and thus can be queried as such. The role of the mastercatalog is create a common enviroment with respect how data can be located so that actual location and external format is irrelevant. The programmer uses resources as found in the mastercatalog, not as on disk or on the net.

The gateway for data and operations into (and out of) the system are the connectors. Connectors do the translation from external representation of data/operations to the internal one and vice versa. With the data we identify two types of connectors that all connect to a different aspect of the data.

• Source connectors. These connect to the actual data, the source data. The result of this connection is an Ilwis-Object.
• Operation connectors. They translate the call into an external processing source into an internal one.

The diagram below shows hows this should play together