[Requests] comments on CDB candidate standard

Volker Coors volker.coors at hft-stuttgart.de
Sat May 21 05:52:37 EDT 2016


Please find enclosed our comments on CDB candidate standard

Regards
    Volker

---------------------------------------------------------------------------------------------------------------------------------
PART A


1.     Evaluator:

2.     V. Coors, Fraunhofer IGD / HFT Stuttgart

Volker.coors at hft-stuttgart.de<mailto:Volker.coors at hft-stuttgart.de>



3.     Submission: OGC 15-113: Volume 1: OGC CDB Core Standard: Model and Physical Data Store Structure


PART B


1.     Requirement: general

2.     Implementation Specification Section number: 4 (Data formats)

3.     Criticality: major

4.     Comments/justifications for changes:
The formats for CDB compliant data bases are listed explicitly in the specification (ESRI Shapefile, OpenFlight, ...). Some of them are proprietary. This raises some issues:

-        Are the proposed formats open? The OpenFlight specification, for example, is only partially open and has many reserved/unspecified data fields. Will the proprietary parts be opened by Presagis/CAE if it is part of that standard?

-        There are OGC standards with identical (or wider) scope and application area. Such standards could perfectly replace the proprietary standards in CDB: GML application models could replace 2D Shapefiles, CityGML could replace 3D Shapefiles (in particular, the CityGML concept of implicit geometries can be used for geotypical models), OpenFlight can partially be replaced by CityGML or an extension (ADE) of CityGML, and digital elevation models (Requirement 88) could be represented by GML rectified grids. The use of proprietary standards as part of an OGC standard (if corresponding OGC standards are available) would be a huge step backwards for interoperability.

-        CDB data can also be obtained by using other OGC standards: WFS for vector data, WFS/T for transactions on vector data (sec. 3.2.3), WCS for digital elevation models, WMS for images, CSW for metadata. Why are such standards not used in CDB?



PART B


1.     Requirement: 8, 65, 66, 109, 111

2.     Implementation Specification Section number: 1.7.3, 1.7.4, 3.6.2.1, 5.7.1.1.2

3.     Criticality: major

4.     Comments/justifications for changes:

-        The WGS84 Coordinate Reference System is just one among others. The is no need to make the use of it obligatory - especially as it contradicts Requirement 7, which requires meters as the measurement unit.

-        With that, a standardized way of tiling datasets which do not use WGS84 and in particular a proposal for the file structure for such datasets is required


PART B


1.     Requirement: 11 et seq., 65, 66

2.     Implementation Specification Section number: 2.1.1,  3.6.2.1, 3.6.2.2

3.     Criticality: major

4.     Comments/justifications for changes:

-        The tiling and the size of the tiles have to follow the needs of the dataset. The Level of Detail and the amount of objects varies strongly depending on the purpose of the data. As the tile size of at least one degree may be suitable for flight simulators, it is by far too large for any combat training in any kind of city model

-        With that, a standardized way of tiling other datasets and a proposal for the file structure is required (e.g. for datasets with sizes smaller than 1 degree in square)

-        In general: regular tiles are suited for images and height fields, but have limitations in full 3D data sets (see examples in presentation of Patrick Cozzi at closing plenary at Washington TC meeting)

-



PART B


1.     Requirement: 40

2.     Implementation Specification Section number: 3.3.5

3.     Criticality: normal

4.     Comments/justifications for changes:

-        FACC focuses mainly on military applications. Is the FACC-Code sufficient for describing objects in a civil context as well? A simulation database may be used in driving simulations (taxis, busses, trains...).

-        By the way FACC is not defined in Volume 3: OGC CDB Terms and Definitions




PART B


1.     Requirement: 86/87

2.     Implementation Specification Section number: 5.6

3.     Criticality: normal

4.     Comments/justifications for changes:

-        Concept for other Coordinate Reference Systems required


PART B


1.     Requirement: 60

2.     Implementation Specification Section number: 3.5.2, 4

3.     Criticality: normal

4.     Comments/justifications for changes:

-        Silicon graphics image data format (.rgb) version 1.0, latest release is from 1996 (20 years ago) - is it still maintained? In contrast to other image formats it does not support alpha channel, but alpha channel is quite useful for visualization of trees based on texture maps (Fan geometry in ESRI terms).

-        In general: Material and Texture definitions shall be in line with ISO Standards as X3D (web3D consortium) or Khronos Group standards.

PART B


5.     Requirement: 45

6.     Implementation Specification Section number: 3.4

7.     Criticality: major

8.     Comments/justifications for changes:

-        if OGC standards are used within CDB, the directory structure has to be adapted. Currently the file structure is adapted to Shapefiles (separate files for geometry, textures and materials, semantics is represented by directory / file names). GML / CityGML does not fit into this schema.



PART B


1.     Requirement: general

2.     Implementation Specification Section number: 3.3.8.3

3.     Criticality: normal

4.     Comments/justifications for changes:

-        Is it suitable to focus on a single standard for distributed simulation (DIS)? There are other standards like HLA (High Level Architecture), which is mentioned in the preface and should be supported as well.


PART B


1.     Requirement: 115

2.     Implementation Specification Section number: 5.7.1.2.7.1

3.     Criticality: normal

4.     Comments/justifications for changes:

-        The issues with the representation of attributes would be solved, if GML / CityGML would be used instead of Shapefiles.


PART B


1.     Requirement: 120

2.     Implementation Specification Section number: 5.7.5.2

3.     Criticality: minor

4.     Comments/justifications for changes:

-        Does the CDB include runtime components or is it a dataset/database? Req. 120 gives directions for runtime components.


PART B


1.     Requirement: 2 to 4

2.     Implementation Specification Section number: 1.7 et seq.

3.     Criticality: minor

4.     Comments/justifications for changes:

-        What is the purpose of many of the minimal requirements for hardware and operating systems (2GB address space, memory paging, ...)?


PART B


1.     Requirement: N/A

2.     Implementation Specification Section number: 3.2.3

3.     Criticality: normal

4.     Comments/justifications for changes:

-        The OGC provides the technique of transactional Web Feature Services (WFS/T) for transactions on vector data. If GML is used as data format, transactions should be performed by WFS/T.



PART B

5.     Requirement: 75

6.     Implementation Specification Section number: 5.1.7

7.     Criticality: normal

8.     Comments/justifications for changes:

-          OGC standards provide standardized concepts for representing metadata (in particular for attributes) which should be used.


-----------------------------------------------------------------------------

Prof. Dr. Volker Coors
Studiendekan Informationslogistik
Hochschule für Technik Stuttgart
University of Applied Sciences
Fakultät Vermessung, Informatik, Mathematik Schellingstr. 24
D-70174 Stuttgart

fon: +49 (0)711 8926 2708
     +49 (0)711 8926 2606 (Sekretariat)

fax: +49 (0)711 8926 2556

email: Volker.Coors at hft-stuttgart.de<mailto:Volker.Coors at hft-stuttgart.de>

www.coors-online.de<http://www.coors-online.de>
www.facebook.com/hftstuttgart<http://www.facebook.com/hftstuttgart>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/requests/attachments/20160521/396d3060/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Comments_CDB.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 23413 bytes
Desc: Comments_CDB.docx
URL: <http://lists.opengeospatial.org/pipermail/requests/attachments/20160521/396d3060/attachment-0001.docx>


More information about the Requests mailing list