Ilwis Objects, Some auxilary concepts

Before understanding how the framework actually works it is important to know some auxilary concepts that are used often when describing the Ilwis-Objects.

The Ilwis Object

Each instantiation of an IlwisObject with a set url and type is a singleton within the system meaning that there always will be only one copy of the object present. If one tries to connect the same type of ilwisobject to the same data source one would get a reference to the already instantiated object. This ensures automatic consistency of data across the system with the down side of needing some extra administration for this. This administration is controlled by the master-catalog. The base identity of the IlwisObject is formed by a

• url, the location the data source.
• a type, identifying the role that that data source has to play for this IlwisObject.

To simplify things, the unique pair is identified by a integer number which is guaranteed to be unique during the run time of this instance of the framework.

URL

In principle an url points to a data source and that data source creates/defines the ilwis-object. But it is not that simple. Take for example a geotif file. A raster file one would assume. And of course this is correct, but it also contains the information for a coordinate-system, a georef and a domain. So basically the tiff has 4 types : raster, coordinatesystem, georef and domain. This means that you can use a geotiff, for example, to construct a coordinatesystem. The raster type is the main type, the rest are called extended types. In the master-catalog they will appear as separate objects. The Urls we use come in two flavors

• raw urls. Basically true urls as they are complete and sufficient urls to locate data-source in the external enviroment
• normalized urls. To present the user with a consistent and location scheme some urls are converted to normalized urls. The system sees its data as a forest of catalogs which might contain other catalogs. The leafs in this forest are the actual data sources. The naming scheme for normalized urls is very similar to naming scheme for files. A hierarchical path with the file at the end. The urls for (data) services are also converted to such a scheme defining catalogs inside the 'container' of the service as the service demands. Note that these normalized urls are purely for internal use. Connecting to the outside still (of course) use the raw url.

e.g. Suppose the raw url is

http://someserver.org/geoserver/wfs?acceptVersions=1.1.0&REQUEST=GetCapabilities&SERVICE=WFS

Inside we find feature types : Landuse, powerlines and wells. Accessing a layer(in side the framework) might use the normalized url http://someserver.org/geoserver/wfs/powerlines

Note that the exact construction of the normalized url is up to the responsible connector as long as it follows the scheme

<scheme>://(<some-catalog>/)+<datasource>

Also note that data-sources that are contain other data-sources are considered to be Catalogs (e.g. hdf file).

Resource

The Resource class is a critical part of the system and is basically the general locator in the system. In a way it is an extended url, an url with properties. IlwisObjects and resources are tightly coupled in the sense that they share the same id (uint64). Another way of looking at a resource is to see it as an IlwisObject “light”. It has enough metadata to create an IlwisObject and through its properties it is descriptive enough to learn the general nature of the object. The resource is the most important component for generating the connector(s) to the Ilwis-Object as determines the type and format of the connector associated with the object.

IlwisData

Apart from in the internals of the connectors one seldom works with a “naked” ilwis-object. The IlwisData class is a template class that hold a (shared) pointer to the object. It provides mainly methods for instantiating an IlwisObject ( the prepare methods) and some casting methods to go from one type to another. It exposes the interface of the IlwisObjects through an overload of the ‘->’ operator. The system provides a number of typedefs to shorten the declaration of the encapsulated IlwisObjects. E.g

typedef IlwisData<Table> ITable;

All the typedef are recognizable by the capital ‘I’ prefix (so IFeatureCoverage, IProjection , ….).

MasterCatalog

The MasterCatalog is a repository were all data-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 explorers to discover which data sources can be found at the location(s). The sources it can recognize are stored as ‘Resource’ in the MasterCatalog. Each explorer 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 In a way the master-catalog is the 'file-system' of the framework. Where the word 'file' need not be taken litteraly in all cases. It determines the logic how things are identified in the system.