These questions came up in the CDB User Group Webinar.

Q: When should geo-typical vs geo-specified models by used, or have we lost the 3.1 geo-specified (calling out geo-typical models from the geo-specific style shapefile) technique.

A: The geo-specific and geo-typical shapefile follow the same style. A typical database mixes both based on the need to re-use a model or not. Unique models are geo-specific and multi-instance ones are geo-typical. The split between both allow clients to better predict and optimize performance differently. As such, GT models can often be batch rendered as they are expected to be re-used.

Q: The question was more about the shapefile callout technique than the geometry

A: If you are referring to the fact that in Draft 1 we explored the idea of merging GT features with GS features, then...it was decided not to do this for compatibility reasons. Hence, the capability to associate (“callout”) a GT model to a GS feature didn’t made it into the final release of 3.2. That explains why the GTFeature dataset has been preserved intact as in 3.0.

In CDB 3.0, the GS and GT datasets were treated very different (in the way they were created and interpreted). GS models first appear in the shapefile in the LOD that matches their significant size. There is a nice structure and ordering for a realtime publisher (RTP) to read and find models of an appropriate size. GT models never had any ordering in the spec, so the GT LOD didn't have any relationship to the significant size of the model. Actually, I don't think was ever spelled out that the lower LODs of these shapefiles had to contain just the larger models, so a very large GT model can appear in a relatively high shapefile LOD.

The change in CDB 3.1, to merge GS and GT models, promised an easier way to process these models by size and reduce the amount of shapefile data that a publisher might have to sort through.

I understand the desire to keep backwards compatibility with CDB 3.0, but this was one feature of CDB 3.1 that I was looking forward to seeing and using. Is there any plan for future CDB specifications to handle the GT shapefiles in a better, more predictable way?

Hi Ryan,

The SigSize rule for models to be referenced by a shapefile applies the same way on GS and GT. As such, the shapefile parsing should be the same. That is true in Spec 3.0 and remains true in 3.2.

However, the models are stored differently as GS are tiles but not GT. In Spec 3.2, the GT now have separate files for different LODs. As showed in table 3.2 from spec 3.2, the GT LOD matches the SigSize as well.

The addition of LOD in GT now allows a client to maybe cache all coarser version of all GT models and load finer as needed. Priority based on FACC could be given as well (tree vs buildings etc...).

You can typically load GT the same way as you load GS but could have a larger paging range in GT as you can assume model re-use which reduced the I/O needed to page a tile.

Does this answer the question? Do you agree that the change in 3.2 provides improvement over 3.0 while remaining compatible? Do you see potential improvement which would retain compatibility?

Regards,

Herm

In Spec 3.2, the GT now have separate files for different LODs.

That was always allowed under CDB 3.0 (section 3.1.2.6)

"In the case of OpenFlight models, multiple representations of the same model in different levels of detail may be stored in separate files."

The SigSize rule for models to be referenced by a shapefile applies the same way on GS and GT. As such, the shapefile parsing should be the same. That is true in Spec 3.0 and remains true in 3.2.

I don't believe this is the case. In the 3.0 spec, there is a whole set of rules in section 3.3.2.1 about GS models and how to put them into significant size bins, what shapefile LOD the point feature appears in, and vertex counts in different levels of detail. GT features do not have any discussion about how to represent the point features in the shapefile. This behavior, with GTFeature shapefile points, is a holdover from CDB 2.1

If that is not enough, please look at the examples in the Presagis Customer Portal downloads (Camp Pendleton and Yemen, create with, I believe, with TerraVista). The GTFeature shapefiles are just thinned at lower levels of detail with no regard to significant size. The GSFeature point shapefiles are removed based on the minimum significant size at each lower level of detail.

In CDB 3.2, the equivalent to Table 3-17 in 3.0 appears to be Table 3.1. This table doesn't explicitly reference GS models only, but it doesn't make sense to apply a CDB LOD to a GT model or GT texture. Also, I couldn't find the equivalent rules about GS models requiring a point feature to appear at a certain shapefile LOD. If CDB 3.2 GT features are now organized by significant size, great! But I didn't see anything that requires that change in the spec.

Ryan,

You are correct in your observations on the spec which will lead to an updated spec 3.2 with clarifications. Further investigation confirmed your statement that GT models shapefile (GTFeature) in 3.0 is only governed by the maximum number of points in a tile which drives the required LODs. Contrarily to my original statement, SigSize is not part of the equation in spec 3.0.

The intent in the spec 3.2 was to re-align GT models/features with GS in its usage of LODs and SigSize (new dataset 510 with explicit LODs). However, it did not come out clear in the text at the time of the release. As such, we are proposing the following modifications to make this explicit in the spec:

• Update annex A 1.19 to address both GS and GT models

• Update section 5.7.4 on GTFeatures to refer to the annex on the model insertion rules (same with 5.7.3 on GSFeatures)

• Update the release notes to point to this important change between spec 3.0 and 3.2

Do you believe that additional clarifications are needed to ensure clarity in the spec on this topic?

Regards,

Herm

I think that will do.