resource

A lightweight, format and location independent, representation of datasets, catalogs and processing in the Ilwis system

Design Rationale

The Ilwis NG system is said to be independent of data format and location of data/processing. Still internally we need to work with “something” that represents the data. We need to be able to mingle different sources without the notion what the origin of that source is. A url itself is not sufficient as a data-source might represent several Ilwis-objects. The resource combines information sufficient for a creating a full object while still being sufficient more ligthweight.

Description

In Ilwis a Resource is a unique definition of data or processing that can be translated into a single IlwisObject or Catalog. For example the location to a shape file or a query on a certain database. A Resource is identified by a unique combination of location (an url) and type. Often a single data source can be mapped to several resources. E.g a GeoTiff can be mapped to a GridCoverage obviously but it can also be mapped to a CoordinateSystem as the data for a full definition of the CoordinateSystem is also part of the GeoTiff file. Resources can be sub divided into three categories: data objects, operation objects and catalogs. The data objects can be seen as “Ilwis objects light” and the catalogs are the containers for these data objects. Containers are defined as queries on the MasterCatalog).

Resources expose the following properties

• URL describing the location of the data source. URL’s may contain fragments to pinpoint internal resources inside a compound source (the ‘#’ notation of urls). A resource contains two urls
  • 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 for all types of data-sources. 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. In many cases (e.g. file-based resources) raw-urls and normalized url's are identical.
• The type of the data defined by this resource.
• The container location of the resource. For files this is often simply a location in the hierarchical file system but for services or remote data this may well be the base url from which the service is called.
• Its spatial location/ bounding box. Not relevant for all data types but invaluable for others.
• Creation and modification times.
• Supporting objects (by reference). An object can only be understood in its relation to other objects. A raster without its georeference or domain offers significant less information
• A resource has a unique runtime id that is shared by the Ilwis object or catalog object it represents.
• A name. A string that can be used as reference to the object. Expressions use the name to select a resource. Names need not be system unique, though they need to be unique in the context they are used (e.g. A name in a expression must be unique in the context were the expression is valid, it isn’t necessarily unique in the context of the MasterCatalog).

Resources represent Ilwis-objects and they share the unique-id that identifies them. Knowing the resource amounts to also knowing the instantiated object(if present).

Usage

The essence of a resource is that it is a unique combination of url and type so :

Resource mycountries("file:///d:/data/countries.shp", itFEATURE);
Resource boundaries("http://myserver/wfs/BoundaryLayer","http://myserver/wfs?REQUEST=GetFeature&VERSION=1.1.0&typename=BoundaryLayer", itFEATURE);

The first version creates a resource were normalized url and raw url are identical; the second one whith different urls. There is third variant. It creates a resource based on a code value. Code are defined in internal system of Ilwis and based on predefined information it can create a full Ilwis-Object. Examples are :

Resource numbers("code=value", itDOMAIN);
Resource csy("code=epsg:2805", itCOORDSYSTEM);
Resource csy("code=proj4:lcc +lat_1=42.68333333333333 +lat_2=41.71666666666667 +lat_0=41 +lon_0=-71.5 +x_0=200000 +y_0=750000 +ellps=GRS80 +units=m +no_defs", itCOORDSYSTEM);

Which code systems there are is explained elsewhere in the documentation.

Apart from the url(s)/type combination, resources have a certain set of fixed properties and a set of variable properties. The fixed properties are mentioned earlier in this text. The variable properties can be anything. They are stored as ket/value (qvariant) pairs in the resource and usually give information about the extended type of the resource. e.g. Suppose we have a resource of a rastercoverage

quint64 georefid= myraster["georeference"].toULongLong();
IGeoReference grf = mastercatalog()->get(georefid);

would be sufficient to create the full georeference.