The first paragraph in the COMPATIBILITY ISSUES section of the LOD Organization of GTModels 3.1 addendum states:
Version 3.0 of the specification did not allow client-devices to directly access the contents of the GTModel dataset. However, the CDB tools were required to convert each instantiation of a geo-typical model into a corresponding geo-specific model.
Although this can be justified by the quoted 3.0 specification excerpt from 3.1.2 GTModel Datasets Directory:
On the other hand, the storage organization of geo-specific models is treated in a manner consistent with Tiled datasets (see Section 3.1.4, Tiled Datasets Directory). 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.
it is also refuted by the statements that follow from the same paragraph and section. As an example::
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.47 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 memory4
as such, I believe that this addendum statement is at the very least, too strong and confusingly incorrect. In our eyes, it appears to be trying to rewrite what the 3.0 specification actually states (possibly due to what was implemented on the ASTARS program and/or in the Terra Vista tools?). We firmly believe that the GTModel dataset is and was usable in the 3.0 version of the CDB specification as originally written.
