Improve WMS performance when using SQLFeatureStore based on complex GML application schemas

[deegree-ci]

WMS performance when using SQLFeatureStore based on complex GML application schema requires improvements. Taken from feedback https://github.com/deegree/deegree3/wiki/UserMeeting_20190314_FOSSGIS (authored by @tfr42).

[tfr42]

We are seeking community feedback on which approach the performance tuning should be focused:

• improving generated SQL DDL scripts and schemas (including database views, indexes)
• improving generated SQL SELECT statements executed during runtime when retrieving data from the database
• improved rendering of complex geometries with non trivial styles
• improved rendering of many geometries within the requested area of a GetMap request
• improved rendering of aggregated layers (several sub-layers are merged into a single)

Base for measurements is the execution time of WMS GetMap request. Resource consumption of CPU and memory has not to be optimized.

[tfr42]

We've got funding for a first analysis and improvement of deegree's WMS performance. Users are kindly ask to provide configurations and examples.

[tfr42]

With deegree 3.4.20 new options have been added to the deegree CLI aka GML tools (see PR #1229 and updated documentation in https://download.deegree.org/documentation/current/html/#deegree-gml-tools). Using the option referenceDatacan highly reduce the complexity of an deegree SQLFeatureStore configuration and thus results in better performance of deegree WMS using this feature store.