cnreediii
commented
4 years ago How about using the GeoPackage related table standard? This would allow the model to be stored in any compressed format (or any format for that matter) without undo overhead. I also think the related table definition in this case could hold the metadata for a referenced model, such as format, date added, an href, and so forth. A late Friday off the wall thought! Have a good weekend.
vwhisker
The 3D model group is asking the group opinion on the ideas of storing 3D models in geopackage vs in containers such as ZIP. By 3D model, we mean a grouping of: Geometry, textures, material, interior, metadata as well as all LODs of a given model. Those can be in OpenFlight or glTF format.
Option 1- Store in GeoPackage: This remains more consistent with the rest of CDBpackaging. This (could allow) to store point feature with 3D models, preserving location information inside the same package. Without point feature, location is approximate based on tile coverage. This could allow to store all datasets individually (different tables in geopackage), allowing a more selective access to LODs and models components.
Option 2 - Store in ZIP file Potentially having one ZIP for model with its texture and geometry, with a unique name in the tile Main benefit is easier to edit. A simple unzip allow to view/edit/update models where geopackage extract, update and repackage would likely require specialized tools. However, this would not provide location information (from the vector - and we do not want to duplicate this...) However, it would group multiple CDB 1.X datasets together (geometry and texture) which some client want to load selectively. Same for texture were all high res texture are store in ZIP which can be big if you want only the coarse LOD - runtime performance impact....