Concepts and Workflow (WFS)

Ilwis concepts and those from the OGC WFS world differ. The following describes how the OGC Web service's workflow accessing data matches to the strategy of Ilwis.

WFS GetCapabilities as Ilwis Catalog

The Ilwis kernel hides the access to actual data sources and makes them transparent by addressing each by using a unique URL. This is true for a concrete feature/raster instance but also for a collection of features/rasters.

A WFS provides access to a collection of features categorized as feature types. Therefore the WFS data source is handled as an Ilwis catalog of features. A new WFS catalog can be registered in the Ilwis framework by using the service's capabilities URL, e.g.

http://ogi.state.ok.us/geoserver/wfs?acceptVersions=1.1.0&REQUEST=GetCapabilities&SERVICE=WFS

The WFS catalog provides access to all feature types available within the Capabilities file, each having their own unique URL as well. In fact, the feature type URLs are GetFeature requests, i.e. all feature instances of a specific feature type are loaded into an Ilwis FeatureCoverage.

WFS DescribeFeatureType as Metadata

Ilwis is lazy in instantiating a whole object to obtain maximum of performance when just metadata is of interest. When metadata is loaded WFS's DescribeFeatureType operation is invoked. Within that, an XML schema description of a feature is requested which defines how a feature instance is structured (what kind of geometry and attributes). At that stage a feature resource is prepared and an attribute table will be set along with the geometry type.

Don't expect magic when the parsed XML schema is mapped to internal data model. A feature is expected to have a GML geometry with related attributes. Therefore parsing is limited to flat data structures plus geometry. Here's an example looks like (leaning on the Oklahoma Office WFS).

<xsd:schema elementFormDefault="qualified" targetNamespace="http://ogi.state.ok.us" 
    xmlns:gml="http://www.opengis.net/gml" xmlns:ogi="http://ogi.state.ok.us"  
    xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   <xsd:import namespace="http://www.opengis.net/gml" schemaLocation="http://204.62.18.179:8080/geoserver/schemas/gml/3.1.1/base/gml.xsd"/>
   <xsd:complexType name="quad100Type">
      <xsd:complexContent>
         <xsd:extension base="gml:AbstractFeatureType">
            <xsd:sequence>
               <xsd:element maxOccurs="1" minOccurs="0" name="area" nillable="true" type="xsd:double"/>
               <xsd:element maxOccurs="1" minOccurs="0" name="quad100_id" nillable="true" type="xsd:long"/>
               <xsd:element maxOccurs="1" minOccurs="0" name="qdname" nillable="true" type="xsd:string"/>
               <xsd:element maxOccurs="1" minOccurs="0" name="centlat" nillable="true" type="xsd:double"/>
               <xsd:element maxOccurs="1" minOccurs="0" name="centlong" nillable="true" type="xsd:double"/>
               <xsd:element maxOccurs="1" minOccurs="0" name="the_geom" nillable="true" type="gml:MultiSurfacePropertyType"/>
            </xsd:sequence>
         </xsd:extension>
      </xsd:complexContent>
   </xsd:complexType>
   <xsd:element name="quad100" substitutionGroup="gml:_Feature" type="ogi:quad100Type"/>
</xsd:schema>

The element having name="quad100" is used to reference the described feature type (in this case quad100Type). The gml geometry will be parsed to appropriate geos geometry to fit the internal model.

The schema description above would end in a feature's attribute table with the following columns:

attribute	Domain
area	double
quad100_id	integer
qdname	string
centlat	double
centlong	double

WFS GetFeature as Instance Data

Instances and their attribute values are parsed from a FeatureCollection which is returned by the WFS as GetFeature response. Each collection member will become an item of the resulting FeatureCoverage. Supported geometries are Surface, Ring, LineString, Curve, Point, and their related Multi*s.