Accepts as Future Work Rejects with Reasons RFC submission is a comment or question with no call for Candidate Standard modification Tracking Number: RFC 007-B04 Evaluator Submission Document Requirement Type Section Number Criticality Bernard Leclerc, Senior Technical Specialist, CAE, Montreal, Canada 16-009r1 T2DModel Tree Structure 6.2.2 Editorial RFC Comment as submitted by Evaluator OGC CDB SWG Response / Comment / Modifications / Reasons Discussed in SWG meeting; approved by unanimous consent The last sentence of the section is “Each layer has an optional LOD node followed by a fixed hierarchy of regular OpenFlight Object, Face, and Mesh nodes.” It is suggested to remove two words, fixed and regular, to simplify the sentence; especially if the above proposed changes are accepted. The resulting sentence would then be “Each layer has an optional LOD node followed by a hierarchy of OpenFlight Object, Face, and Mesh nodes.” [Document attached by Bernard to the RFC comment submission has been uploaded to the OGC CDB SWG files here: https://portal.opengeospatial.org/files/?artifact_id=68803] SWG RFC Resolution Categories X Accepts Accepts with Modifications Accepts as Future Work Rejects with Reasons RFC submission is a comment or question with no call for Candidate Standard modification Tracking Number: RFC 008-B01 Evaluator Submission Document Requirement Type Section Number Criticality David Graham, CAE Inc. Volume 9: schemas metadata/schemas Minor
SWG RFC Resolution Categories Accepts Accepts with Modifications Accepts as Future Work Rejects with Reasons X RFC submission is a comment or question with no call for Candidate Standard modification Tracking Number: RFC 011-B06 Evaluator Submission Document Requirement Type Section Number Criticality Gregory Peele, Jr. / Applied Research Associates, Inc. Volume 1 15 2.1.5 RFC Comment as submitted by Evaluator OGC CDB SWG Response / Comment / Modifications / Reasons 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 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. Yes, you are correct. CDB is meant to work across a range of systems and simulators, and as such needs to support more than one use case. Greg’s email comment: *(Partially resolved) The comment sheet explains that I understood correctly, so that’s good. Can the language for Requirement 15 be expanded to explain what “complete” means? Also, aside from compatibility with the existing implementations, is this a requirement that can be dropped in this version or the next version? The evaluator interprets requirement 15 correctly; all tiles from the finest LOD provided by the modeler to the coarsest CDB LOD (i.e. LOD -10) must be provided. SWG RFC Resolution Categories X Accepts Accepts with Modifications Accepts as Future Work Rejects with Reasons RFC submission is a comment or question with no call for Candidate Standard modification Tracking Number: RFC 011-B07 Evaluator Submission Document Requirement Type Section Number Criticality Gregory Peele, Jr. / Applied Research Associates, Inc. Volume 1 38 3.2.5 Major
This comment is part of the Industry recommended ‘Update 1 to CDB V3.2’.. This package of recommendations is available in its original version on the OGC portal here: SWG RFC Resolution Categories X Accepts Accepts with Modifications Accepts as Future Work Rejects with Reasons RFC submission is a comment or question with no call for Candidate Standard modification Tracking Number: RFC 012-B07 Evaluator Submission Document Requirement Type Section Number Criticality David Graham, CAE Inc. Addition of new Airliner Codes 287-297 Minor RFC Comment as submitted by Evaluator OGC CDB SWG Response / Comment / Modifications / Reasons 287 CJR Caverton Helicopters 288 KZR Air Astana 289 ROU Air Canada Rouge 290 DWT Darwin Airline 291 UTA UTair Aviation 292 AZN Amaszonas 293 FDB Flydubai 294 UZB Uzbekistan Airways 295 PGT Pegasus Airlines 296 ABY Air Arabia 297 AXB Air India Express This comment is part of the Industry recommended ‘Update 1 to CDB V3.2’.. This package of recommendations is available in its original version on the OGC portal here:
SWG RFC Resolution Categories Accepts Accepts with Modifications Accepts as Future Work Rejects with Reasons X RFC submission is a comment or question with no call for Candidate Standard modification Tracking Number: RFC 013-B05 Evaluator Submission Document Requirement Type Section Number Criticality Gregory Peele, Jr. / Applied Research Associates, Inc. Volume 1 101 5.6.2.3.1 Minor RFC Comment as submitted by Evaluator OGC CDB SWG Response / Comment / Modifications / Reasons Is 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. There is no NODATA value for Jpeg2000. The VSTI imagery has to have some data there. Marking areas as geospecific vs something else would be future work using metadata to describe the characteristics of the CDB. Greg’s email response: (Informational) Just curious. I assume the answer is no. Something to consider for next version. SWG RFC Resolution Categories