[Requests] CDB RFC Response for OGC 15-113

Gregory Peele ARA/VHD gpeele at ara.com
Thu May 26 23:30:43 EDT 2016


PART A

1. Evaluator: Gregory Peele, Jr. / Applied Research Associates, Inc.

2. 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: General
3. Criticality: Major
4. Comments/justifications for changes: Is it theoretically possible to instantiate a compliant CDB without using the current format encodings? I don't believe so - Section 4 appears to assert that all current encodings are normative. It mostly defers to the Best Practices documents to specify the Shapefile and OpenFlight encoding requirements. GeoTIFF and JPEG-2000 encodings remain core requirements. That makes sense if the objection to the others is purely about lack of open standards. Those raster choices force specific performance tradeoffs on CDB runtime clients though - JPEG-2000 is very CPU intensive in exchange for its compression level, and heightmap compression is an interestingly complicated discussion. Also, there are still requirements in this document that explicitly reference the encodings, for example #63. I know that backward compatibility with fielded systems is a goal for those who make or use said systems (less so competing vendors, I'm sure) and that addressing the general format question is a priority for CDB 2.0, so I appreciate the difficulty of reconciling the tension between short-term vs. long-term goals. That said, I have to ask why the Shapefile and OpenFlight encodings are Best Practices if they are mandatory to conform to the standard - as I read it, if you do not use these encodings, there is no conformant way to implement vector or model layers.

PART B

1. Requirement: General
2. Implementation Specification Section number: General
3. Criticality: Major
4. Comments/justifications for changes: There does not appear to be a standard way to add or extend the available layers other than modifying the standard itself. All extensions of CDB must use the Extension mechanism which is completely freeform and unstructured. Being able to define new layers in a structured way by analogy to existing standard layers would improve the likelihood of interoperability of extensions and ease integration of them into future standard versions. This would probably require metadata to describe the current layers in terms of encoding, content, and role to pull off.

PART B

1. Requirement: #3
2. Implementation Specification Section number: 1.7.1.2
3. Criticality: Minor
4. Comments/justifications for changes: What is the basis for the minimum OS requirements? Mobile and constrained devices may not necessarily meet all of these requirements. It would be possible, for example, to use a compliant CDB repository on a 16-bit processor lacking hardware IEEE 754 FPU support, with less than 2 GB address space, without network communication or virtual memory. It wouldn't be very pleasant to program or use, but it could be made to work for specific use cases. So I'm unclear how these requirements apply to a file repository standard.

PART B

1. Requirement: #4
2. Implementation Specification Section number: 1.7.1.4
3. Criticality: Minor
4. Comments/justifications for changes: What are the basis for the minimum memory representation requirements? It would be theoretically possible, for example, to use a compliant CDB repository on hardware that lacked any of the listed capabilities and software-emulated every integer and floating point type without virtual memory support. Mobile and constrained devices may not meet every requirement point, though this is becoming rarer. A pure 64-bit system that lacked 32-bit addressing mode would not meet the requirement on technicality, though that's just being pedantic. I am unclear why these requirements apply to CDB as a file repository at all.

PART B

1. Requirement: #8, 10, 13, 14, 65, 66, 67
2. Implementation Specification Section number: 1.7.2, 3.6.2
3. Criticality: Major
4. Comments/justifications for changes: The strict requirements for the WGS-84 horizontal datum and vertical datum, plate carrée map projection, and specific tile and LOD layout present a variety of limitations that I'm sure have already extensively been discussed in the SWG. To present a few that have come up in my actual simulation experience: it would be difficult, for example, to instantiate a compliant CDB of any planetary body other than Earth, ruling out space exploration domain despite its similarities to the aviation domain. The tile scheme is also not well suited for polar simulation due to the singularities it induces. I'm aware that generalized tiling is an open discussion across multiple SWGs so I won't belabor the point.

PART B

1. Requirement: #15
2. Implementation Specification Section number: 2.1.5
3. Criticality: Minor
4. Comments/justifications for changes: If I interpret this correctly, it is not possible to omit intermediate LODs - for example, to have data for LOD 0 and LOD 6, but omit LODs 1-5. If correct, this would not be ideal for ground combat simulation and gaming use cases, where typically LOD 5-7 would be used for first-person views and LOD 0-1 might be appropriate for a map level view, but the intermediate LODs are not always useful to the client despite requiring disk space and terrain generation time. If I am misunderstanding the requirement, clarification on what is meant by "complete" would be helpful.

PART B

1. Requirement: #38
2. Implementation Specification Section number: 3.2.5
3. Criticality: Major
4. Comments/justifications for changes: I understand why the current versioning mechanism is not very efficient, but the version limit numbers seem arbitrary at first glance. Is there a specific rationale for these values? This restriction eliminates CDB from consideration for the iterative incremental update use case. Scaling to arbitrary revision counts and finer-grained revisioning should be a long-term goal.

PART B

1. Requirement: #40
2. Implementation Specification Section number: 3.3.5
3. Criticality: Major
4. Comments/justifications for changes: What happens if a geospecific model spans multiple tiles? It is stored in all tiles duplicated? Is it clipped to tile boundaries? Does the anchor point determine which tile it lands in, and if so how is it determined that it intersects the other tiles? This situation comes up a lot in applying AI behaviors to ground combat, particularly for geospecific building and tunnel models. If this is covered by any other section, I missed it.

PART B

1. Requirement: #90
2. Implementation Specification Section number: 5.6.1.4.1
3. Criticality: Editorial
4. Comments/justifications for changes: The requirement misspells "Mesh Type" as "Mest Type"

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/requests/attachments/20160527/f1a9c0c3/attachment-0001.html>


More information about the Requests mailing list