Why using an indexed scheme instead of a "feature-approach”?

[hugoledoux]

One of the main criticism/discussion-point/question is that CityJSON uses, for the geometries and textures, an "indexed scheme" instead of a "feature-based approach". An indexed scheme means that the coordinates (x,y,z) of the vertices are given in a separate list, and that the geometries refer to the indices of the vertices. In contrast, a feature has all its coordinates listed directly in its geometries (à la GML).

There are obviously pros and cons in having an indexed scheme, and I drafted here below a list as a starting point for discussion. Please contribute.

Cons of indexed scheme

• Streaming/sending of features is more cumbersome as a feature is not 'self-contained'. A large CityJSON file needs to be split into smaller files since the list of vertices can become very large.

• This means that CityJSON files to be pre-processed, and if a subset of the features is selected then the indices need to be updated. It should also be said that splitting a file into a subset, or merging many into one file, is a rather simple operation and is already implemented and fully working, see cjio which can be easily installed on all systems.

• Observe however that for CityGML, if one wants to WFS/stream a dataset, she needs to "pre-process" it too, because many 'generic' properties can be encapsulated into one given feature, eg:

  • resolve+replace XLinks for shared surfaces and other uses
  • deal with Implicit Geometries: find in the file + replace

(CityJSON avoids these by having a global list of Implicit Geometries, and there are no XLinks)

Pros

• More human-readable files. People can compare indices, slightly different numbers with many decimals not so much
• We can use 'topology' in file to do tests (adjacency, shared vertex, incidence, etc)
• Closer to visualisation formats (OBJ, OFF, glTF), as they too use indexed schemes. Can thus be directly translated to efficient representations for graphics APIs (eg IBOs in OpenGL/WebGL).
• Going from index- to feature-based is trivial, the other way around less so.
• More compression in general (based on some tests with CityJSON and that script we get ~1.8X compression with an indexed-scheme, which not neglibeable).
• Textures are local/per-object in CityGML (<appearance> tag), but I see an advantage in listing only once the textures and not repeating the path of the texture for each surface

[clausnagel]

Linked a discussion in the @3DCityDB development team: https://github.com/3dcitydb/importer-exporter/pull/92.