[Requests] Comments 08-007 City Geography Markup Language

Frank.Steggink at bentley.com Frank.Steggink at bentley.com
Wed Mar 19 16:37:50 EDT 2008


PART A


1. Evaluator:
   Frank Steggink
   Bentley Systems, Inc.
   3645, boul. Ste-Anne
   Québec, Qc.
   G1E 3L1
   Canada
   frank.steggink at bentley.com  

2. Submission: 08-007 City Geography Markup Language


I've added a couple of editorial comments in the Word document describing the CityGML implementation specification. I'll send them on request. This e-mail will become too long if I would have to describe every comment minutiously. Unfortunately, I didn't have the time to reread the entire specification.


PART B


1. Requirement: (comment) The text describes that the _same object_ in different LOD may be combined and integrated. How do you know when two objects are "the same object". Should they share a geographical location, or is this based on the feature identifier? Should the properties creationDate and terminationDate be taken into account?

2. Implementation Specification Section number: 6.2, text "Furthermore, two CityGML data sets containing the same object in different LOD may be combined and integrated."

3. Criticality: Minor

4. Comments/justifications for changes: Some explanation woudl be nice, but this part can also be omitted.



1. Requirement: (question) Can full support be claimed if the TexturedSurface module, which is deprecated, isn't supported?

2. Implementation Specification Section number: 7, at the very end

3. Criticality: Minor

4. Comments/justifications for changes: n/a



1. Requirement: (clarification) What property? _CityObject does not contain any information about appearances, but it has a _GenericApplicationProperty¬OfCityObject which is replaced by AppearancePropertyType.

2. Implementation Specification Section number: 7.1, Appearance module in Tab. 4, text "Therefore, the abstract base class _CityObject defined within the core module is extended by an additional property."

3. Criticality: Minor

4. Comments/justifications for changes: There is no such property, see #1.



1. Requirement: (editorial) The abstract class gml:_Solid  does not have "interior" or "exterior" assoications with gml:Surface, but they should be put on the concrete class gml:Solid.

2. Implementation Specification Section number: 8.1, Fig 8 (UML diagram of geometry model)

3. Criticality: Editorial

4. Comments/justifications for changes: correction



1. Requirement: (enhancement) Is gml:PolygonPatch disallowed as well? It is the parent of gml:Triangle and gml:Rectangle (although this is not yet the case in GML 3.1.1, but corrected in GML 3.2.1).

2. Implementation Specification Section number: 8.1, Fig 8 (UML diagram of geometry model)

3. Criticality: Minor

4. Comments/justifications for changes: This way, the composition of gml:Surface is needlessly limited to rectangles and triangels, especially since gml:Polygon is supported, so it is not an extra burden to implement.



1. Requirement: (comment) I think it is better to use gml:OrientableCurve/-Surface when the orientation is _meaningful_, even when it is positive. Although there is a default orientation in GML 3.1.1 it doesn't necessarily mean anything special.

2. Implementation Specification Section number: 8.1, OrientableSurface (below Fig 9), text "Thus, an OrientableSurface only has to be used, if the orientation of a given GML geometry has to be reversed."

3. Criticality: Minor

4. Comments/justifications for changes: n/a



1. Requirement: (editorial) Remove word "characteristic" in text "characteristic contour characteristics".

2. Implementation Specification Section number: 8.1, TriangulatedSurface (below previous comment), text "In addition, break lines and stop lines define contour characteristics of the terrain."

3. Criticality: Editorial

4. Comments/justifications for changes: A "contour characteristic" is by definition "characteristic". Avoid duplication.



1. Requirement: (comment) If this is true, it is better to add some Schematron rules to the schema, similar to gml:_strictAssociation. That way, this restriction will also be clear from the schema, but it can only be validated by a validator which understands Schematron.

2. Implementation Specification Section number: 8.2.3, header ReferentialIntegrity, text "Either the contained element or the reference must be given, but neither both or none."

3. Criticality: Minor

4. Comments/justifications for changes: n/a



1. Requirement: (comment) The inheritance refers to the the gml:metadata and gml:name properties, and not any actual metadata content or names.

2. Implementation Specification Section number: 10.1, text "thus it inherits metadata (e.g. information about the lineage, quality aspects, accuracy) and names from Feature and its super classes."

3. Criticality: Minor

4. Comments/justifications for changes: It is implied here that actual metadata is inherited from somewhere (a container feature?) as well. Same for name property.



1. Requirement: (editorial) The XML Schema definitions don't completely follow the Lexical conventions, described in section 7.4.2 of GML 3.1.1. Names of abstract types should start with the prefix "Abstract", and names of abstract elements should start with an underscore.
Examples:
* The type "_CityObjectType" should be renamed to "AbstractCityObjectType".
* The type "_AbstractBuildingType" should be simply "AbstractBuildingType".
* The type "_VegetationObjectType" should be renamed to "AbstractVegetatoinObjectType".
For more cases, see the Word document. The element definitions seem to be OK.

2. Implementation Specification Section number: All XSD's, Annex A, plus various XSD snippets in the specification.

3. Criticality: Major / Editorial

4. Comments/justifications for changes: See #1



1. Requirement: (editorial) There are a few occurrences where the german translation of certain terms is given.

2. Implementation Specification Section number: Some XSD's, Annex A, plus various XSD snippets in the specification.

3. Criticality: Editorial

4. Comments/justifications for changes: There is no need for these specific translations.



1. Requirement: (editorial) The abbreviation "LOD" is still "LoD" in most places in the schemas.

2. Implementation Specification Section number: Some XSD's, Annex A, plus various XSD snippets in the specification.

3. Criticality: Editorial

4. Comments/justifications for changes: Consistency.



1. Requirement: (editorial) There are a couple of instances where the facets "minLength" and "maxLength" are used, where they have the same value. They can be replaced by the facet "length". See for example TransformationMatrix4x4Type. The facets in the xs:restriction can be replaced by <xs:length value="16"/>.

2. Implementation Specification Section number: Some XSD's, Annex A, plus various XSD snippets in the specification.

3. Criticality: Editorial

4. Comments/justifications for changes: Simplification.



1. Requirement: (correction) Change text to "As CityObjectGroup itself is a CityObject, it may also be contained by another group".

2. Implementation Specification Section number: Annex A.5, text "As CityObjectGroup itself is a CityObject, it may also contain groups."

3. Criticality: Editorial

4. Comments/justifications for changes: The proposed change seems to be more logical to me. The old text is true, but the new text explains this situation a bit better.



1. Requirement: (comment) This test will already be done by test 1.4. Is there any approach other than schema validation suitable for this method?

2. Implementation Specification Section number: Annex B, test case 1.1.

3. Criticality: Minor

4. Comments/justifications for changes: Remove text if redundant.



1. Requirement: (comment) Test cases 1.2 and 1.3 are not necessary when approach 2 is chosen (CityGML profile is specified by its own file, see section 7.2). Test case 1.3 will also be checked automatically by test 1.4.

2. Implementation Specification Section number: Annex B, test cases 1.2 and 1.3.

3. Criticality: Minor

4. Comments/justifications for changes: Some more clarification?



1. Requirement: (proposal) How about a new test for approach 2 in section 7.2? Test if the schema is a valid CityGML profile.

2. Implementation Specification Section number: Annex B, section 1.

3. Criticality: Minor

4. Comments/justifications for changes: There is no test which checks if a given XML schema is a valid profile. But what consitutes a valid profile? Any combination of modules is allowed. But section 7.2 describes certain constraints, like "The targetNamespace of the profile's schema shall differ from the namespaces of the imported CityGML modules."




More information about the Requests mailing list