3D models (GS) - Unique names

[PresagisHermann]

CDB 1.X GS models are currently split into tiles and have a model name that must be unique in the tile. Finding the correct file for a model is done by composing the tile name of the vector (NS/EW/LOD) with the model name. As such model name have to be unique in the tile. Between tile, the models are unique because they are composed of the tile name which is unique.

As the 3D model group is suggesting to group all LODs of a model into a single package, we are now face a larger challenge to find unique name of models to be referenced as the tile is no longer an index ( as a model can appear in the coarsest tile which is half the planet).

Do you agree that we need unique names for models and its components (textures etc...)? Do we have to use GUIDs (fairly long!) to ensure unique names or can you propose other ideas?

[ryanfranz]

A couple of questions:

• If the structure allows, can we get rid of the model name limitations? I know that is an artifact of using shapefiles, but GeoPackage should be more flexible with longer names.
• If a model uses only textures that are referenced by that model (photo-realistic and not generic), can we package those textures together along with the model, and not have to worry about texture name collisions? (like a namespace or hierarchy or URI) Or would that cause problems with less sophisticated systems out there?

GUIDs sound interesting to prevent name collisions, especially when merging different areas together. I'm not sure it's much different than a name lookup in a zip file today with a long model/texture name now, and if a GeoPackage has indexed that column it should be a faster binary search space. And storing the mapping of the GUID back to the original name would be helpful for editing purposes.

[jerstlouis]

@PresagisHermann

In the GeoPackage, for points-referenced models (not the single glTF directly being a type of GeoPackage tile like imagery / vector), I was picturing a table of models which simply has id, name, media-type, and a glTF (or OpenFlight) blob.

For CDB geospecific models, the model name in that column could simply follow a naming scheme which always includes the tile (level, row, column) for which that particular model is defined, so you can still get the uniqueness from that level / row / column.

Alternatively, the 3D models extensions could have separate columns for level / row / column of where the model occurs, but this introduces the dependency on also specifying a TileMatrixSet etc., rather than simply being a generic table of models. I'm hoping this is not CDB-specific so that a generic GeoPackage viewer could support this 3D models extension without supporting CDB specifically.

[UnclePoole]

Another way of constructing (almost) unique names is hashing - do a checksum of the model content and the file size in bytes, that combining those two should generate a unique name, if not particularly human readable. This has the advantage of being deterministic and reproducible for a particular model input.

In practice a model table at whatever level you care about that just enforces a uniqueness constraint on names is probably easier and more useful, so that the models end up with human readable names. This also removes any limitations on model name length or content.

I don't see any reason why model base filenames should need to be globally unique though - the full relative path inside the CDB is the piece that model loaders will use.

The checksum and such may still be useful for detecting and merging (or not) duplicates though and fast matches based on content not just name.

[UnclePoole]

As for embedded textures, glTF defines a way to do that but it's not particularly efficient for runtime use - as I understand it the options are uncompressed binary RGB in a buffer referenced by an accessor, or an embedded Base-64 encoded text representation of a PNG or JPEG. Conceptually it could be done though and I agree if the textures are logically unique to the model that they should be packaged with it.

[ryanfranz]

@UnclePoole

I don't see any reason why model base filenames should need to be globally unique though - the full relative path inside the CDB is the piece that model loaders will use.

The current CDB does not save relative paths, just enough information to reconstruct the CDB filename, from which we can generate the directory path (relative from the root CDB folder). For GeoTypical models, the models must have unique names (technically, a unique combination of model name and FACC code), since these are global and can be used anywhere within a CDB. For GeoSpecific models, they are local to a (usually) geocell tile. You technically could have a two models with the same model name in a tile, but you have to be very careful that the lower LODs of the model geometry are always in separate zip file containers so they don't clobber each other.

The problem here comes in trying to create a tiling that covers larger areas of the world. It makes the uniqueness of model names a harder problem when a tile covers an eighth of the world. If the models are stored on disk, a relative path could suffice in place of a unique name. But if the models are stored in a GeoPackage (applies to zip files too), that name still needs to be found in a table, and uniqueness (or a layer of indirect addressing via something unique, like a GUID) is still important.

[cnreediii]

@UnclePoole - WRT texture encoding, I3S supports JPEG and PNG, as well as compressed texture formats S3TC and ETC2. Fairly flexible. If we do increase metadata offerings in CDB-X, perhaps metadata on how textures are encoded would be useful. Maybe good for a SWG discussion at some point.