Seeking input on citygml4j 3.0 about citygml4j HOT 4 CLOSED

I just added a new branch citygml3-devel that provides a first glimpse of the upcoming citygml4j 3.0 with full support for the latest draft of CityGML 3.0. I basically followed my initial wish list as outlined above. These are the major new features and changes:

• Completely revised object model that follows the conceputal model of CityGML 3.0, and also covers the concepts from CityGML 2.0/1.0. DeprecatedProperties objects allow for representing feature properties that have been removed in CityGML 3.0.
• Readers and writers supporting CityGML 3.0, 2.0 and 1.0. So it is super easy, for example, to read a CityGML 1.0 dataset and write it back as CityGML 3.0. Note that not every conversion is lossless though. You might have to add some code to handle features and properties that are not available in the target version. For example:
  • Mapping CityGML 2.0/1.0 features in LoD 0-3 to CityGML 3.0 should work fine and not require any additional code;
  • Mapping CityGML 2.0/1.0 features in LoD4 to CityGML 3.0 cannot be done automatically because there is no LoD4 in CityGML 3.0 anymore;
  • Mapping CityGML 3.0 features to CityGML 2.0/1.0 only works automatically if the features are also available in CityGML 2.0/1.0.

I can think of adding some default strategies for the non-lossless cases.

• An ObjectWalker to visit the objects in your CityGML tree. I merged the different feature and geometry walkers into just one class to simplify the interface.
• ADE interface that allows for supporting ADEs by implementing your own ADE object classes. I simplified the interface at various places, so I hope providing your own ADE extension has become easier.
• Removed JAXB as XML binding framework. I am now using xml-objects, which applies a different approach. Instead of compiling XML schemas into a set of fixed and predefined classes, you register ObjectBuilder and ObjectSerializer for the main XML elements. The builders are invoked during parsing to map the XML elements onto the model objects, and serializers are in charge of marshalling objects back to XML content. There are a lot of advantages:
  • Unlike JAXB, the object classes are completely independent from the builders and serializers. No need for annotating the object classes, and no reflection in the background. You can even use xml-objects to unmarshal into foreign classes.
  • One ObjectBuilder can be used to map different XML elements onto the same target object. This is especially handy when dealing with different namespaces like in CityGML 3.0, 2.0 and 1.0. In the JAXB world, there is always a fixed 1:1 relation between an XML structure and a Java class.
  • Likewise, one ObjectSerializer can be used to marshall the same object class to different XML elements.
  • Both ObjectBuilders and ObjectSerializers can be replaced at runtime to inject your own mapping code.
  • Lightweight

The branch is ready to be used and tested. I plan to add examples for the main use cases like reading and writing CityGML files soon.

Have fun.

from citygml4j.

I just published a first release candidate version of citygml4j 3.0.

from citygml4j.

Merged the citygml3-devel branch into master today. So, closing this issue.

from citygml4j.

Today I released the fourth release candidate of citygml4j 3.0. I guess this was the last candidate before final release. Unless further wishes or discussions pop up here ;-)

from citygml4j.