Py3DTiles index structures vs Tiler

[EricBoix]

Use case: from py3dTiles to CityTiler

As software end-user I want to generate a tile set out of the following sources of information:

1. some raw geometrical data source (e.g. a set of buildings each of which described as a triangle soup, or some point clouds)
2. some (possibly optional and possibly hierarchical) semantic data
3. some hierarchical (functional) criteria used as ordering principle for building the TileSet hierarchy

Low level building block analysis

Solving the use case requires the following software "building blocks" described below with the natural treatment pipeline order

• Import-Tools that allow to walk on native data structures like

  • LAS (or more general Point Cloud) import library
    • 3DCitydb database importation library

• SRS-Tools : such Spatial Reference System tools can/must be used e.g. in order to remove the Cesium bias towards WGS84 data (and that doesn't seem to allow e.g. Lambert-93 based data)

  • Index-Tools : Data Structures that can be used as geometry based "sorting criteria/algorithms" in order to build the target (3DTiles) hierarchy e.g.
    • Binary Tree e.g. the 1d-tree of JGA's CityTile
    • QuadTree e.g. the Node DS of export.py
    • possibly some Octree (DS) or some kd-tree although the current usage of 3DTiles for cities is inherently 2D+H by nature i.e. a bi-dimensional practice

• 3DTiles: a Data Structure (DS) to be used as target placeholder (and that knows how to serialize itself i.e. can be exported)

From building blocks to components

Given the above list of building blocks, and with separation of concerns design constraint in mind (that in this context translates to "don't pollute/bias 3DTiles with specific end-user data format or tiling strategy") what are their possible aggregation into software components ?

Current decomposition

The current content of Py3DTiles integrates all the blocks:

• 3DTiles (the DS): many of the files held in py3Dtiles/py3dtiles
• Import tools:
  • LAS oriented features are encountered in py3dTiles/points sub-directory
  • Specific database importation (note the the DB structure/table requirements seem implicit)
    • specific WKB file format importation
• Index tools: the Node class within py3Dtiles/export.py
• Tilers:
  • Py3DTiles code: convert.py and/or export.py
  • Alternative sources: JGA's CityTiler/export.py (and its now deprecated ancestor ExtractCityData/extract_city_semantic.py)

Note the already existing bias of the py3DTiles package toward the LAS data structure.

Possible component decomposition : extend current strategy

The idea is to pursue the current integrated strategy while

• pulling aside (separate files) the index tools
• extending it with other import tools (3D-CityDB)
• extending it with SRS tools
• pulling aside (separate sub-directory) the tilers

Pros and cons:

• Pros: all in one python package
• Cons: no separation of concerns, many (exploding number of) dependencies, code biased by py3Dtiles early contributions

Possible component decomposition : separation Tiles/Tiler

• Possible target component architecture i.e. as Python packages
  1. Py3DTiles
     • 3DTiles (the DS)
     • Index-Tools
  2. Py3DTilers
     • Import-Tool
     • SRS tools
     • Tilers (conversion tools)

Pros and cons:

• Pros: there can be as many Py3DTilers components as they are communities, Py3DTiles remains end-user data "agnostic"
• Cons: requires more work in python packaging, harder to use, to diffuse (obfuscates the usage for the user)

[delhomer]

Moved to https://gitlab.com/Oslandia/py3dtiles/-/issues/47