[Requests] CDB RFC Response for OGC 15-113 (Part 2)

Gregory Peele ARA/VHD gpeele at ara.com
Fri May 27 10:19:14 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: Other
4. Comments/justifications for changes: Is the target for this version of the CDB standard explicitly aviation simulation? Or is it intended to address the full breadth of interoperable 3D synthetic environments for simulation across ground, underground, urban, sea, undersea, aviation, arctic, space, etc.? Understanding the target domain(s) helps frame how to approach the standard and decide questions of scope and completeness.

PART B

1. Requirement: #2
2. Implementation Specification Section number: 1.7.1.1
3. Criticality: Minor
4. Comments/justifications for changes: Are the filesystem requirements the minimum necessary to represent a minimal CDB? Or do they represent the requirements for representing a CDB that has all possible layers, tiles, and LODs? The latter perspective makes more sense for the specific numeric limits documented so ideally that should be clarified. I'm not sure how points 5 (removable media) and 6 (bootable/non-bootable volume) apply to the CDB standard at all. In many cases, a small area or coarse-resolution CDB could be instantiated without meeting any of the filesystem requirements.

PART B

1. Requirement: #8
2. Implementation Specification Section number: 1.7.3
3. Criticality: Minor
4. Comments/justifications for changes: Is it explicitly stated which vertical datum is in use? I assumed ellipsoid-relative altitude based the reference to EPSG 4979, and various other sections appear to be consistent with that. It might be good to explicitly clarify that all altitudes are ellipsoid-relative rather than geoid-relative to (for example) EGM-96. Altimetry source data that terrain production tools like RUGUD or TerraTools would use to build a CDB is frequently geoid-relative and not performing the vertical datum conversion has been a major source of correlation error between source data and output simulation products in the past.

PART B

1. Requirement: #9
2. Implementation Specification Section number: 1.7.3
3. Criticality: Minor
4. Comments/justifications for changes: How is standardizing the runtime projection of a client device within scope of the CDB standard? Is the intent of this requirement instead to capture that all coordinates in the CDB repository conform to the WGS-84 horizontal datum and plate carree map projection?

PART B

1. Requirement: #101
2. Implementation Specification Section number: 5.6.2.3.1
3. Criticality: Minor
4. Comments/justifications for changes: Is there any provision for representing NODATA pixels where the VSTI imagery content is absent, unknown, or redacted? Or is the expectation that the terrain producer will fill these pixels with geotypical data or a desired sentinel color? Some users in the geo-intelligence domain only wish to see and use data if it is known to be present and geospecific.

PART B

1. Requirement: None
2. Implementation Specification Section number: 5.6.3
3. Criticality: Minor
4. Comments/justifications for changes: I don't see any requirements defining that the number of material raster layers is limited to 256 and the number of mixture layers must be one less than the number of material layers. I feel the text explains the material layers concept pretty well, but this should probably be a requirement if it needs to be enforced. Also, is there a specific reason for the limit of 256 material layers? In practice, I imagine most real data sets would not have nearly so many layers (runtime performance would likely not be so great if you have to mix 256 layers on each material texel sample query) but the rationale for a specific limit should be documented.



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


More information about the Requests mailing list