<b>3.1.2 GTModel Datasets Directory</b>

Once produced, geo-typical models become unique and are copied by the off-line CDB publisher tool into their corresponding geo-specific tiled directories. These post-processed models are then treated as geo-specific models. Note however that if a model is referenced more than once within the same tile, it should be instantiated only once per tile. Nevertheless, the CDB structure allows the vector sub-datasets, such as point features, to directly address geo-typical models in their source directory. The only purpose of this convention is to provide a hint to the client-devices, when managing their respective internal memory. This is permitted only for models, such as, trees or power line pylons that are repeated many times (typically several hundred of times) in a relatively close area and across many tiles to be cached in client devices memory48

48 For instances, areas over 100 generic trees per square-km, generic power lines or street lights poles modeled on several kilometers should always be referenced in the GTModel datasets.

I strongly disagree with the recommendation to instance any geo-typical model as a geo-specific one unless it is used a very small number of times within a geocell. Following this recommendation scatters an excessive number of model geometry and texture duplicates into the finest geo-specific LOD tiles and forces each texture referenced by these models to use a unique name corresponding to its geographically tiled location. This dramatically increases on-disk database size, is counter to the CDB spirit of near infinite database content, and degrades RTP performance due to inflated I/O requirements at finer LOD levels since these duplicate models and textures are zipped together with other useful non-duplicate data.

It also complicates client device texture load management since there appear to be many unique textures in use where in fact there are many duplicates. This might be solved by using only the TNAM to determine unique texture usage, but I do not believe the specification assures TNAM is unique within the GSModelTexture dataset. Practically, it must be nearly unique within a geocell or file naming collisions might occur at courser texture LOD levels. Nevertheless, this is an RTP and client burden that seems to have no design advantage. Furthermore, I believe it is quite common to create a geo-specific geometry that uses geo-typical textures on parts, if not all, of the model. I believe the 3.1 Geo-Specified proposal should be amended to allow this mixed usage model for similar reasons. The reverse usage pattern is probably rarely useful, however.

2. The declaration of a model as geo-typical provides an important clue to the client-device in the management of its internal memory; geo-typical models should remain cached in memory since they are likely to be used repeatedly across many tiles of the CDB.

If this is the primary reason for the recommendation, then I believe this clue should be provided via an alternate means like an average instance density (per unit area) metric in the model metadata.

3. It is permissible for a client device to use its own internal (presumably more computationally effective) representation of a geo-typical model, if it wishes to reduce its workload further. If the modeler wishes to ensure that the geo-typical model representation stored in the CDB is used by the client-devices, the user is required to copy this model into the geo-specific tiled model dataset.

Likewise, for the reasons stated above, I <b><i>strongly</i></b> disagree with this method to assure that a specific model representation is used. If the need to allow client dependent representations is valid, an alternative means to override that allowable behavior should be specified.

I believe this is a <i>fundamental flaw</i> in the CDB 3.0 specification that will prevent wide spread adoption if it continues to persist in later versions, and I look forward to a discussion to clarify the reasoning for this recommendation.

We are in agreement with you Brian.

If you look in the proposed change for the CDB 3.1 specification we are proposing modification to the Geotypical model (GT) to enable them to be used effectively in a CDB at Run-time.

The modification enables both the sharing of geometry (GT) across a CDB and the sharing of texture across a CDB - for both GT & GS model.

This said, I reread the addendum on the GTModel dataset and the clarfication on why we were doing it was not clear, but the result is as described above.

support/discussions/topics/145

Addendum 3D Model - part 2.

I look forward to your comments on the proposed changes.

This said, I reread the addendum on the GTModel dataset and the clarfication on why we were doing it was not clear, but the result is as described above.

support/discussions/topics/145

Addendum 3D Model - part 2.

I look forward to your comments on the proposed changes.

In that case, I will continue this discussion there shortly, as it is now evident that that is where this topic belongs. Thank you for the response.