deegree  

Developers Informations

Style (SLD) editor / deegree web application client framework

WFS improvement

We will have some improvments on the deegree WFS. This mainly targets the offered options for accessing data sources and the way it shall be configured. So we like to simplify the editing of the wfs capabilities file similar to the WMS capabilities. This means most parameters can be left out; they will be set by default values.

The most work have to be done at the data source access configuration itself. Because this will affect a central part of deegree that shouldn't be affected by larger changes in the future we like to discuss our ideas about that on the mailing list.

For this I have attached a document describing our ideas for the data source access configuration incl. an example xml-file. please feel free to send any comment that will help us to imporve the WFS in a way that it matches yours and our requirements.

The basic aim - besides getting data - of the configuration of accessing datasource in deegree is to offer a flexible set of options and mechanisms to establish a facade that hides the concrete details of each datasource behind a set of unique interfaces. These options are shall be controlled by a set of configuration parameters in a datasource's configuration file. We suggest five major sections of configuration parameters:

• definition of the datasource connection: This means connection parameter for database based sources or a URL for a file based datasource. This section also includes the definition of additional security parameters like a list of IP-addresses of hosts that are allowed to access a datasource. The datasource connection definition section must be mandatory.
• Output formatting: This section contains infomation about which output formats will be served by a datasource and what classes are responsible for creating this formats. The last section allowes it to developers to define new output formats by linking new classes into the output creating process without changing the basic deegree code. This output formatting section should be optional. If it is not defined, GML2 and FEATURECOLLECTION will be set as default formats with default responsible classes depending on the data source type.
• Input formatting: This is vice versa to output formatting and will be used for transactional behaviour of a datasource. The idea is that a datasource may accept several formats for inserting, deleting and updating. The incoming data will be transformed to the datasource's internal format. This section also shall be optional. If it isn't defined GML2 and FEATURECOLLECTION will be set as default formats with default responsible classes depending on the data source type.
• Topology definition: In many cases datasources are made of more then one flat table. In these cases tables are usually connected in a Entity-Relationship-Model using Primary- and Foreign-Keys. The current version of the deegree WFS more or less assumes a hierarchical relationship between tables starting at a master table (root) so the relationship can be modelled as a tree. Practice has shown that this assumption isn't generic enough in several cases and we had to create some workarounds to access highly complex database schemas with the deegree WFS. Because of this we thought about a more general starting point for modeling table relations within the deegree WFS. For this we thought that the tables building a featuretype are forming a kind of topology that can be described by a directed graph. Each node in this graph is assigned with a table and each edge is realized by assigned keys of two tables.
  Since a feature type in its basic concept is a hierachical datastructure that must map none hierarchical datastructures to a hierarchical one we must define one starting point (table) in the graph. This starting point shall be called master table. But this doesn't mean that the master table can't be source as well as target of one or more relations. This enables the definition of recurrences within a featuretype. In this case the provider of the datasource must ensure that the data content doesn't lead to a infinite regress ( A -> B -> C -> A -> B …).
• table definition / field mapping: the last section covers the definition of the tables needed for the feature type and the mapping of the tables fields to the feature types properties. The major idea behind this section is that we often need to combine data into a feature type where the original data schema doesn't fit the required feature type schema. So we have to change the data source field names to the required property names and may change the datastructure and the data types too. Also we like to offer the possibility to use functions on the values of the table fields as they may be defined in the underlying database. The definition of alias names for database fields should offer the opportunity to use one database field for more then one feature property (this sounds not very useful because it leads to redundant data storing in a feature, but we had more then one case where it was necessary). The complete mapping section is optional so you are free to use the datastructure and field names as they are.
  Also it might be necessary to create one feature type from tables coming from more then one datasource; e.g. we have a shapefile storing the geometries and several tables in a postgresql database storing their attributes. Because of this we shall be able to reference tables from different datasources. Concluding the aim of this section we can say that we like to offere a very general way to create views on given data sources/-structures without manipulating the data source itself.