This article contains example files, processes, and instructions. It is intended as a reference and complement to the WFSRI 3.5 User Guide.

Specifying the Feature Table Definition XML

The sample Feature Table Definition schemas referenced in the following examples can all be found in the $WFSRI_INSTALL/data/xml/mapping directory.

  1. Specify the root element, a Feature Schema. For example, from lightningFlash.xml:
     

    <nnew:FeatureSchema xmlns:nnew=http://www.faa.gov/wfs/admin/1.1
      xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
      xmlns:xlink=http://www.w3.org/1999/xlink
      xsi:schemaLocation="http://www.faa.gov/wfs/admin/1.1
        ../../../../../../wfsri-bindings/schemas/gov/faa/wfs/admin/
        1.1.0/featureTableDefinition.xsd">

  2. For each Feature Table to be created in the database, specify the table’s metadata. All examples are taken from lightningFlash.xml unless otherwise indicated.
     

    <nnew:FeatureTable>

    1. Specify whether the table definition depends on a Base Table Definition XML. For example, from runwayAssignment.xml:
       

      <nnew:FeatureTable xlink:href="/xml/parsing/runwayBase.xml">

    2. Specify the schema name. This should be identical to the Producer’s username. The string value is limited to uppercased alpha and numeric characters, and the underscore (_).
       

      <nnew:schemaName>MITP</nnew:schemaName>

    3. Specify the table name. This is the name to use in the Oracle database. This element is optional. If it were omitted, the name defaults to the value of the XSD name, in uppercased letters. If it were included, the string value is limited to uppercased alpha and numeric characters and the underscore (_).
       

      <nnew:tableName>LIGHTNINGFLASH</nnew:tableName>

       
      Given this example, because Feature Type in the XSD is named “lightningFlash,” <nnew:tableName> could be omitted, and the table name would remain “LIGHTNINGFLASH.”
       
    4. Specify the XSD name. This is the name of the Feature Type element as it appears in the Feature Type XSD and as it will appear in Feature Type XML instances. The string value may not be empty, and may not exceed 27 characters.
       

      <nnew:xsdName>LightningFlash</nnew:xsdName>

    5. Specify the XSD namespace URI(s). These are the namespace prefix and URI pairs as they appear in the Feature Type XSD and as they will appear in Feature Type XML instances. The string value may not be empty.
       

      <nnew:xsdNamespaceURI>nnew='http://www.faa.gov/wfs/admin/1.1'
        gml='http://www.opengis.net/gml'</nnew:xsdNamespaceURI>

       
      Ensure that each namespace prefix used in the XSD Names of the Feature Table Columns is defined in this value. Delimit the pairs using a single space.
       
    6. Specify the URN that identifies the spatial reference system in use.
       

      <nnew:srsName>urn:ogc:def:crs:EPSG::4326</nnew:srsName>

    7. Specify the dimensionality of the spatial reference system identified in the <nnew:srsName> element.
       

      <nnew:srsDimension>2</nnew:srsDimension>

    8. Specify the values to be used by the Oracle database when creating spatial indexes for the Feature Table. Note that this element is optional; if omitted, default values will be used.
        

      <nnew:SrsIndexes>
  <nnew:IndexXDimension>
    <nnew:min>-180</nnew:min>
    <nnew:max>180</nnew:max>
    <nnew:tolerance>0.05</nnew:tolerance>
  </nnew:IndexXDimension>
  <nnew:IndexYDimension>
    <nnew:min>-90</nnew:min>
    <nnew:max>90</nnew:max>
    <nnew:tolerance>0.05</nnew:tolerance>
  </nnew:IndexYDimension>
  <nnew:IndexZDimension>
    <nnew:min>0</nnew:min>
    <nnew:max>300</nnew:max>
    <nnew:tolerance>0.05</nnew:tolerance>
  </nnew:IndexZDimension>
</nnew:SrsIndexes>

       
      The X and Y dimensions must be specified for a 2D spatial reference system. 3D spatial reference systems require the additional X dimension. For each dimension, a lower and upper bound must be specified, along with a tolerance value.
       
      • Values in the X dimension must be between -180 and 180, inclusive.
      • Values in the Y dimension must be between -90 and 90, inclusive.
      • Tolerance values must be greater than or qual to 0.05 (5 centimeters).
         
    9. Specify the values to be used by the Oracle database when creating partitions for the Feature Table. The example below stores lightningFlash data in partitions for fifteen days, with timePosition ranges two hours long (i.e., 00:00 - 02:00, 02:01 - 04:00, etc.):
        

      <nnew:PartitionPolicy>
  <nnew:key>TIMEPOSITION</nnew:key>
  <nnew:duration>PT2H</nnew:duration>
  <nnew:retention>P15D</nnew:retention>
</nnew:PartitionPolicy>

      • Within the <nnew:key> element, specify the Feature Table column you wish to use to define the partitions. This column needs to be of the dateTime datatype.
      • Within the <nnew:duration> element, specify the duration of a partition in hours. The duration is limited to a maximum of 24 hours – one full day.
      • Within the <nnew:retention> element, specify the retention time of a partition, in days. For example, to specify one full year, input a retention value of P356D, for 356 days.
         
  3. For each element or attribute in the FeatureType type to be extracted as a database table column, specify the metadata for the Feature Table Column. All examples are taken from lightningFlash.xml.
     

    <nnew:FeatureTableColumn>

    1. Specify the column name. This is the name to use in the database. The string value is limited to uppercased alpha and numeric characters and the underscore (_).
       

      <nnew:columnName>STRENGTH</nnew:columnName>

    2. Specify the column datatype. This is used to indicate whather this FeatureType type element or attribute is a spatial entity (“Spatial”). The default value is that it is not (“Other”). As such, its value may be an empty string. For example, for the “STRENGTH” column:
       

      <nnew:columnDatatype/>

       
      For the “GEOMETRY” column:
       

      <nnew:columnDatatype>Spatial</nnew:columnDatatype>

    3. Specify the XSD name. This an XPath path expression, relative to the Feature Type tag (in this example, <nnew:LightningFlash>), to the FeatureType type element or attribute as it appears in the Feature Type XSD and as it will appear in Feature Type XML instances. The string value may not be empty.
       

      <nnew:xsdName>nawx:strength</nnew:xsdName>
      <nnew:xsdName>nawx:geometry</nnew:xsdName>
      <nnew:xsdName>naws:strength@uom</nnew:xsdName>

    4. Specify whether this is an XSD attribute (“true”). The default value is that it is not (“false”). As such, its value may be an empty string. For example, for the “STRENGTH” column:
       

      <nnew:xsdAttribute/>

       
      For the “UOM” column:
       

      <nnew:xsdAttribute>true</nnew:xsdAttribute>

    5. Specify the XSD datatype. This is the XML schema datatype of the FeatureType type element or attribute as it appears in the Feature Type XSD. The string value may not be empty.
       

      <nnew:xsdDatatype>string</nnew:xsdDatatype>

  4. If the Feature Table Definition depends on a Base Table Definiton XML, specify that XML.
     
    1. Specify the root element, a Base Table. For example, from src/test/resources/xml/parsing/runwayBase.xml in your WFSRI-Template folder:
       

      <nnew:BaseTable xmlns:nnew=http://www.faa.gov/wfs/admin/1.1
        xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
        xsi:schemaLocation="http://www.faa.gov/wfs/admin/1.1
          ../../../../../../wfsri-bindings/schemas/gov/faa/wfs/admin/
          1.1.0/baseTableDefinition.xsd">

    2. Specify whether this table definition depends on another Base Table Definition XML. For example, from src/test/resources/xml/parsing/runwayBaseTest.xml in your WFSRI-Template folder:
       

      <nnew:BaseTable xmlns:nnew=http://www.faa.gov/wfs/admin/1.1
        xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
        xmlns:xlink="http://www.w3.org/1999/xlink"
        xsi:schemaLocation="http://www.faa.gov/wfs/admin/1.1
          ../../../../../../wfsri-bindings/schemas/gov/faa/wfs/admin/
          1.1.0/baseTableDefinition.xsd"
        xlink:href="/xml/parsing/test.xml">

    3. For each element or attribute in the Base type to be extracted as a database table column, specify the metadata for the Feature Table Column. See Step 3, above.

Example Feature Type Description XML File

When programmatically registering a new FeatureType, you must pass in a series of properties further defining the FeatureType. One of these properties is a pointer to a Capabilities file, a small file containing the response that the Web Feature Server should make when it receives a GetCapabilities query. A GetCapabilities response file should something like this:

<?xml version="1.0" ?>
<wfs:FeatureType xmlns:wfs="http://www.opengis.net/wfs">
    <Name xmlns:tfdm="http://www.faa.gov/tfdm/1.0">
      tfdm:TfdmFlightStatusFeature</Name>
    <Title>TFDMFLIGHTSTATUSFEATURE</Title>
    <SRS>SDO:4326</SRS>
</wfs:FeatureType>

Example Feature Type Registration Properties File

When programmatically registering a new FeatureType, you must pass in a series of properties further defining the FeatureType. Together, these properties can be encased in a Properties file, like the one below:

Error rendering macro 'table'

Illegal group reference

Example GetCapabilities Response File #1

An example of a response to a GetCapabilities request in which all sections were asked for:

Example GetCapabilities Response File #2

An example of a response to a GetCapabilities request in which only the FeatureTypeList section was asked for:

Example Transaction-Insert Request XML File

When inserting a new Feature into a Feature Table using the generic SOAP client, you must pass in an XML file, similar to the one below. Additional examples can be found in the $WFSRI_INSTALL/data/xml/transaction-insert directory:

Example GetFeature Request XML File

When querying a Feature's data using the generic SOAP client, you must pass in an XML file, similar to the one below. Additional examples can be found in the $WFSRI_INSTALL/data/xml/get-feature directory:

Example Subscribe Request File

When programmatically subscribing to a FeatureType, you must pass in an XML file defining the subscription, the operation, and the filter, like the one below:

Example Subscribe Response File

When programmatically subscribing to a FeatureType, you will receive an XML file in response, like the one below:

Example PauseSubscription Request and Response Files

When pausing an existing subscription, you must pass the WFSRI an XML file like the one below:

You will receive a short XML file in response, like the one below:

Example ResumeSubscription Request and Response Files

When resuming a paused subscription, you must pass the WFSRI an XML file like the one below:

You will receive a short XML file in response, like the one below:

Example RenewSubscription Request and Response Files

When renewing a subscription that is about to expire, or giving a new expiration time to a subscription without one, you must pass the WFSRI an XML file like the one below:

You will receive a short XML file in response, like the one below:

Example Unsubscribe Request and Response Files

To Unsubscribe from an existing subscription, you must pass the WFSRI an XML file like the one below:

You will receive a short XML file in response, like the one below:

Last Guide Revision:
June 30, 2011
  • No labels
Unknown macro: {center}

© 2006-2010 University Corporation for Atmospheric Research (UCAR) and Massachusetts Institute of Technology Lincoln Laboratory (MIT/LL). Contact [Dan Tennant] with inquiries.