Envisaged structure and placement of component(types) in ILWIS NG
The figure on the right shows an envisaged structure and placement of component(types) in ILWIS NG.
The ILWIS NG structure includes number of blocks as the following:
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