"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

Deegree 3 Evaluation

Overview

Evaluation of deegree 3 has been done in order to find out its suitability for possible inclusion in the Spatial Information Services Stack (SISS) as an alternative to GeoServer WFS service. Its suitability has been assessed on existing use cases and datasets that are currently being served via GeoServer WFS. The goal was to achieve the same GML output for EarthResourceML feature types in conformance with AuScope EarthResourceML 1.1 Profile. Backend database modifications were allowed to suit deegree-specific mapping techniques and patterns.

Environment

  • Java 1.6
  • Apache Tomcat 6.0.32
  • deegree 3.1 (Fahrenheit)
    • deegree-webservices-3.1.1.war

  • GSWA dataset
    • Original MS SQL Server 2008 database has been manually converted into PostGIS
Further on this page referring to "current" version means deegree 3.1.1.

Limitations

Note that following limitations that have been present in version in review aren't necessarily by design and will probably be eliminated in future versions.

Database connectivity

  PostGIS MS SQL Server Oracle Others
Supported by design DONE DONE DONE ALERT!
Implemented DONE ALERT! ALERT! ALERT!

"Supported by design" means that deegree clearly has an intention to support these databases in the future and corresponding options are present on the web user interface. However, any attempt to use those results in "SQL dialect is not implemented for selected data source" exception.

GML mapping issues

Mapping of gml:* properties

An attempt to map er:Commodity/gml:name attribute in relational mapping mode of SQLFeatureStore fails silently (no messages in the log file) and returns a non-wellformed XML response:

<?xml version='1.0' encoding='UTF-8'?> 
<ows:ExceptionReport xmlns:ows="http://www.opengis.net/ows" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/ows http://schemas.opengis.net/ows/1.0.0/owsExceptionReport.xsd" version="1.0.0">
   <ows:Exception exceptionCode="NoApplicableCode"> 
    <ows:ExceptionText>not available</ows:ExceptionText> 
  </ows:Exception> 
</ows:ExceptionReport><?xml version='1.0' encoding='UTF-8'?> 
<gml:FeatureCollection xmlns:gml="http://www.opengis.net/gml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/gml http://schemas.opengis.net/gml/3.1.1/base/gml.xsd urn:cgi:xmlns:GGIC:EarthResource:1.1 http://localhost:8080/deegree/services?SERVICE=WFS&amp;VERSION=1.1.0&amp;REQUEST=DescribeFeatureType&amp;OUTPUTFORMAT=text%2Fxml%3B+subtype%3Dgml%2F3.1.1&amp;TYPENAME=er:Commodity&amp;NAMESPACE=xmlns(er=urn%3Acgi%3Axmlns%3AGGIC%3AEarthResource%3A1.1)">
   <gml:featureMember> 
    <er:Commodity xmlns:er="urn:cgi:xmlns:GGIC:EarthResource:1.1" gml:id="er.commodity.S0071856.121">
       <gml:name 

The reason is explained on http://osgeo-org.1560.n6.nabble.com/Problem-mapping-feature-type-with-Deegree-3-1-and-Oracle-td4168381.html and logged as a bug in http://tracker.deegree.org/deegree-services/ticket/297

GetFeature request by ID

Trying to retrieve feature by ID throws an exception:

<?xml version='1.0' encoding='UTF-8'?> 
<ows:ExceptionReport xmlns:ows="http://www.opengis.net/ows" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/ows http://schemas.opengis.net/ows/1.0.0/owsExceptionReport.xsd" version="1.0.0">
   <ows:Exception exceptionCode="NoApplicableCode"> 
    <ows:ExceptionText>Error performing query by id filter (relational mode): null</ows:ExceptionText>
   </ows:Exception> 
</ows:ExceptionReport><?xml version='1.0' encoding='UTF-8'?> 
<gml:FeatureCollection xmlns:gml="http://www.opengis.net/gml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/gml http://schemas.opengis.net/gml/3.1.1/base/gml.xsd urn:cgi:xmlns:CGI:GeoSciML:2.0 http://localhost:8080/deegree/services?SERVICE=WFS&amp;VERSION=1.1.0&amp;REQUEST=DescribeFeatureType&amp;OUTPUTFORMAT=text%2Fxml%3B+subtype%3Dgml%2F3.1.1&amp;TYPENAME=gsml:GeologicStructure,gsml:DuctileShearStructure,gsml:Joint,gsml:GeologicRelation,om:Observation,sa:Specimen,gsml:FoldSystem,gsml:Layering,gsml:Borehole,sa:SamplingFeature,gsml:GeologicFeature,er:NonMetallicOccurrence,er:MiningActivity,er:MineralOccurrence,gsml:NonDirectionalStructure,er:MiningFeature,er:EarthResource,gsml:BoundaryRelationship,sa:LocatedSpecimen,sa:SpatiallyExtensiveSamplingFeature,gsml:Fold,sa:SurveyProcedure,gsml:Lineation,gsml:Foliation,gsml:BoreholeCollar,sa:SamplingFeatureCollection,gsml:Fault,gsml:GeologicFeatureRelation,gsml:TraceFossil,gsml:GeologicEvent,gsml:DisplacementEvent,gsml:Contact,sa:SamplingSolid,gsml:ShearDisplacementStructure,er:MiningFeatureOccurrence,er:Commodity,gsml:MappedInterval,om:ObservationCollection,gsml:Fracture,sa:SamplingSurface,gsml:MappedFeature,sa:SamplingPoint,gsml:FaultSystem,gsml:GSML,gsml:FossilMold,er:Mine,gsml:GeologicUnit,er:Product,sa:SamplingCurve&amp;NAMESPACE=xmlns(gsml=urn%3Acgi%3Axmlns%3ACGI%3AGeoSciML%3A2.0,sa=http%3A%2F%2Fwww.opengis.net%2Fsampling%2F1.0,om=http%3A%2F%2Fwww.opengis.net%2Fom%2F1.0,er=urn%3Acgi%3Axmlns%3AGGIC%3AEarthResource%3A1.1,)"

As a workaround, GetGmlObject request seems to work correctly for some feature IDs and fails for others: But anyway this workaround would be incompatible with the AuScope Discovery Portal.

Exposure of unmapped feature types in GetCapabilities statement

Another weird thing about deegree 3 is that it exposes all feature types it sees in GML application schemas even if there's no mapping provided for those types. This might confuse client applications as they will "think" these types are available and all attempts to query those types will fail.

Here's a comments on this by Markus Schneider from http://osgeo-org.1560.n6.nabble.com/Problem-mapping-feature-type-with-Deegree-3-1-and-Oracle-td4168381.html:
Personally, I don't find it too useful to restrict the announced feature 
types if the DescribeFeatureType request has to return the full 
application schema anyway. I think it's most consistent if the listed 
feature types match the served application schema. 

You have to consider that the whole configuration concept works by 
extracting the feature type declarations from the GML application 
schema. Therefore, you always have the option of eliminating the feature 
types you don't want by modifiying the GML schema. 

"Modifiying the GML schema" workaround doesn't sound like a good idea as GML application schemas are normally externally governed artefacts and end users aren't supposed to modify/tweak them to make software working.

Need to check what OGC specification says on whether you need to expose all the feature types or not.

Encoding multi-valued properties "inline"

Having trouble encoding er:MineralOccurrence/er:commodityDescription property inline, where MineralOccurrence-to-Commodity relationship is 0..*

In GeoServer configuration er:MineralOccurrence feature type has an unique identifier (uri) and each commodity record has source_uri field pointing to its parent er:MineralOccurrence feature. During encoding of er:MineralOccurrence feature types it retrieves all commodities pointing to the current er:MineralOccurrence.

It seems that in deegree it is required that er:MineralOccurrence is pointing to commodity feature by ID used in FIDMapping, which is unique, effectively making the mapping cardinality 0..1

Here's an extract from http://osgeo-org.1560.n6.nabble.com/Problem-mapping-feature-type-with-Deegree-3-1-and-Oracle-td4168381.html:

So, deegree knows that the "specification" property of FeatureType 
"MappedFeature" always contains features of type "GeologicFeature" and 
that the FeatureTypeMapping for "GeologicFeature" applies. 

Your "Feature" mapping element just defines how deegree looks up a 
GeologicFeature instance when creating a MappedFeature instance from the 
DB: 

1. <Join table="TRIT_SDO.GEOL_UNIT" fromColumns="UNIT_ID" 
toColumns="UNITCLASSIFIER_ID"/> 

Note that it's required that the table attribute (=TRIT_SDO.GEOL_UNIT) 
is identical to the table attribute in the FeatureTypeMapping of 
"GeologicFeature" (you could also put "?" and let deegree determine it 
automatically). 

The join defines the relation TRIT_SDO.MAP_FEATURE.UNIT_ID = 
TRIT_SDO.GEOL_UNIT.UNITCLASSIFIER_ID (I assume TRIT_SDO.MAP_FEATURE to 
be the table for MappedFeature). Note: the column in toColumns must be 
the same column as in the FIDMapping of "GeologicFeature". 

This definition would be enough for the cases when: 

- You don't require external hrefs (e.g. xlink:href="http://...) to be 
stored in your db 
- The value feature type for a feature-valued property is unique

Advantages (or positive stuff about deegree)

  • Configuration is a lot more intuitive and straightforward with just a few simple constructs:

<Primitive path="gsml:purpose" mapping="'instance'"/>
<Complex path="er:dimension">
   <Complex path="er:EarthResourceDimension">
      <Complex path="er:depth">
         <Complex path="gsml:CGI_NumericValue">
            <Complex path="gsml:principalValue">
               <Primitive path="." mapping="depth"/>
               <Primitive path="@uom" mapping="'urn:ogc:def:uom:UCUM::m'"/>
            </Complex>
         </Complex>
      </Complex>
      <Complex path="er:length">
         <Complex path="gsml:CGI_NumericValue">
            <Complex path="gsml:principalValue">
               <Primitive path="." mapping="length"/>
               <Primitive path="@uom" mapping="'urn:ogc:def:uom:UCUM::m'"/>
            </Complex>
         </Complex>
      </Complex>
      <Complex path="er:width">
         <Complex path="gsml:CGI_NumericValue">
            <Complex path="gsml:principalValue">
               <Primitive path="." mapping="width"/>
               <Primitive path="@uom" mapping="'urn:ogc:def:uom:UCUM::m'"/>
            </Complex>
         </Complex>
      </Complex>
   </Complex>
</Complex>

  • There's no need to use denormalized views in the backend.
  • Configuring simple features is as easy as in GeoServer - pick a table/view in the database and voilą, it's all done!

Performance considerations

WFS service performance has not been assessed according to the standard EarthResourceML WFS testing procedure as it was not possible to achieve the same level of GML output conformance. Needs to be reassessed in future if required using newer versions of deegree.

-- PavelGolodoniuc - 12 Apr 2012
Topic revision: r3 - 13 Apr 2012, PavelGolodoniuc
 

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).