deegree3 developer team meeting 2010-04-20
Protocol by: MarkusSchneider
1. Offical tweets from deegree
Official tweets from deegree can be found at http://twitter.com/deegree_org. Besides other deegree-related information, it is intended to have a tweet for every developer meeting protocol that has been put online. This means that every developer who writes a meeting protocol is supposed to send an email to firstname.lastname@example.org to inform our twitter administrator about the availability and location of the new protocol.
2. GML application schema binding tool
In order to facilitate the working with CityGML in the toolchain of the WPVS, RutgerBezema started implementing a binding framework for GML feature types. Basically, this tool will be able to read an arbitrary GML application schema (e.g. CityGML, GeoSciML, XPlanGML, ... ) and generate one Java class for each contained feature type. Each generated class implements both the Feature and FeatureType interfaces of the feature API. This allows a programmer to work with features / feature types in a typesafe manner, while still having all possibilities at hand that are implemented for generic features in deegree 3, e.g. GML parsing / writing.
3. Authentication support / AuthIE results
As one result of taking part in the AuthIE project, progress has been made on authentication modules for deegree 3 services. Currently, HttpBasicAuthentication and SOAP Authentication are implemented, but the general architecture allows for more authentication methods to be added easily. Details can be found on the deegree3/SecuritySubsystemDocumentation page.
4. WPVS toolchain
A tool for georeferencing buildings is in the works. The basic idea is to have a GUI that displays a map of the surface area in question. The user can then interactively define the position and orientation of the building in 2D coordinate space. In the next step, the user will be able to set the z-value of the building.
5. CSW progress
For the GetRecordById operation, the CSW now generates an exception report in case a non-existent id is queried. Also, the developer documentation of the inner workings of the RecordSubsystem (which is the persistence layer of the CSW) has been started.
6. CRS progress
A bug in the CRS API has been fixed. This bug was triggered by transformations from 3D compound coordinate systems to the same underlying (2D) geographic coordinate system, but with switched axes. Also, the WKT parser for coordinate systems has been refactored and JUnit-tests have been added.
7. Build system
Our build server now has more swap memory, which means that the integration tests in the deegree-test module are no longer cancelled. All CITE tests from the SOS 1.0.0, WCS 1.0.0, WFS, 1.0.0, WMS 1.1.1, WMS 1.3.0 suites are passed successfully for deegree3 which means that these services could get certified to be OGC compliant right away.
8. Client progress / OpenLayers4JSF
Progress has been made in the development of the new generation of the deegree web client. The choice of JSF as technology seems to be working out nicely, an OpenLayers-based map view is already usable and even allows configuration of layers that are directly backed by a database. For integrating OpenLayers, OpenLayers4JSF is used, which provides a JSF-component for OpenLayers. Also, the beloved generic client has seen an adaptation to JSF. All results can currently be found in the deegree 3 services console module in the contrib folder of the deegree 3 SVN.
9. New commit templates coming
As new commit templates for deegree 3 are required (and requested by PSC), here's a first collection of ideas. A very simple and pragmatic approach should be used which must support generating release notes more easily and puts only a minimal burden to the committers. Ideas:
- Clearly separate between commit information that's relevant for the release notes and other.
- One template for bug fixes
- One template for new features
- Free text (no template) for all other commits -- the purpose of the text only relevant for developers.