deegree3 developer team meeting 2009-04-14
Protocol by: RutgerBezema
Attendees: RutgerBezema, AndreasSchmitz, MarkusSchneider
1. Configuration
Where should the files for the parameters of the central db configuration be stored?
2. GML
Generic GML-Feature parsing is possible, each 'Unknown' type will be presented to the developer in a tree structure. CityGML files can be read and rendert using the deegree3 r3d rendering engine.
3. Geometry
- While parsing geometries it was found, that the axis-order is important, the points methods get[XYZ] will return the first, second, third (if present) axis, which might not be the actual 'expected' axis direction. Developers are encouraged to use the get( int i ) methods instead.
A new CRS type is introduced, it wraps the name of a CoordinateSystem, and does lazy loading, only when transformations are to be done the CRS-Registry is requested to create the real CoordinateSystem. The benefit of this approach is, that the CoordinateSystems which are not known to the CRS-Backend can still be used, if no Transformations between CRS's are to be done. The drawback is ofcourse the late exception handling.
- Creation of these CRS's is done by calling the Constructor, not by using the CRSRegistry.
- First attempts to map complex deegree geometries to simple backend geometries will be started this week. This mapping is necessary to be able to use the geometries of different backends like JTS, Postgis or Oracle without loosing information about the original geometry.
- Persisting the geometries is a topic, which still needs further attention.
4. SVN-Module structure
In the process of restructuring the deegree subsystems the security SVN-Module will be merged into the commons SVN-Module as well. All developers should update their dependencies. The service module now depends on commons solemnly.
5. OSGI Support
The build scripts will be enhanced to create META-INF files which are OSGI compliant, in this context all src/META-INF directories should be moved to the root directory.