We want to be able to create and visualize a 3D Tiles tileset which represents hierarchical relationships between city objects and the evolution of the city in time (i.e. temporal dimension). 3D Tiles has been extended for supporting the hierarchy between city objects and for representing the temporal dimension of cities.
Some work has been done for implementing these two extensions:
These works need to be merged (and eventually adapted/finished) to work together.
This issue implies the realization of the issue #21 .
Repository organization
The target working repository branch structure with the MEPP-Team/py3dtiles fork
|------------- bt_hierarchy (copy of JGA's and adaptation)
|--------- temporal_v2 (current work of VJA)
|
-------------X master
|--------- WIP_hierarchy_and_temporal (ad-hoc blend of bt_hierarchy and temporal_v2)
Advantage: we keep bt_hierarchy separate for PR (and rebase) to Oslandia
Inconvenient: when bt_hierarchy of temporal_v2 progresses we have to "rebuild" (is cherry picking the best tool to do so?). This method might become really messy (and expensive) when conflicts appear...
Implementation constraint: "modularity principle"
"Batch Table Hierarchy" and "Temporal" are 3DTiles extensions. The code realized for this issue should thus follow this extension "philosophy" and thus be thought as modular.
For example the handling of the "Batch Table Hierarchy" within Py3DTiles should first organize the technical means for extensions support and then use the provided modular/extension mechanism to define the batch-table-hierarchy support.
As illustration of this (extension driven) modularity principle, probably that a recommendable importation (python) command for enabling/importing bath-table-hierarchy support should be of the form
import core, extension-batch_table_hierarchy from py3dtiles
[x] when above "batch table hierarchy" support within Py3DTiles is finished PR resulting bt_hierarchy to Oslandia's master
[x] refactor the temporal_v2 branch to follow above mentioned "modularity principle"
[ ] At any working time manually create (with a cherry picking script?) a WIP_hierarchy_and_temporal branch that blends (the commits of) the branches bt_hierarchy and temporal_v2. Use WIP_hierarchy_and_temporal to work on UDV-server-scriptsee below
[ ] develop a new UDV-server-script (based on WIP_hierarchy_and_temporal) that blends the following two processes
the exportation of temporal tile-sets: based on extract_city_data.py, that initializes the process through the creation of a materialized view, combined with Py3DTiles's export_tilesetNote: the target approach/architecture/strategy for producing hierarchical together with temporal tile-sets should be the one of JGA's extract_city_semantic.py (i.e. we use py3DTiles without building a temporary 3DCityView database view
[x] launch an iTowns PR on resulting batch_table_hierarchy branch.
[ ] realize the blending of the above resulting iTowns batch_table_hierarchy adaptations with 3dtiles-temporal branch of VJA' iTowns fork.
Note: depending on the success of the above described ad-hoc merging branch strategy (for having at hand a Py3DTiles branch that gathers both hierarchy and temporal extensions) adopt the same one or find something else.
The problem
We want to be able to create and visualize a 3D Tiles tileset which represents hierarchical relationships between city objects and the evolution of the city in time (i.e. temporal dimension). 3D Tiles has been extended for supporting the hierarchy between city objects and for representing the temporal dimension of cities.
Some work has been done for implementing these two extensions:
These works need to be merged (and eventually adapted/finished) to work together.
This issue implies the realization of the issue #21 .
Repository organization
The target working repository branch structure with the
MEPP-Team/py3dtiles
forkImplementation constraint: "modularity principle"
"Batch Table Hierarchy" and "Temporal" are 3DTiles extensions. The code realized for this issue should thus follow this extension "philosophy" and thus be thought as modular.
For example the handling of the "Batch Table Hierarchy" within Py3DTiles should first organize the technical means for extensions support and then use the provided modular/extension mechanism to define the batch-table-hierarchy support. As illustration of this (extension driven) modularity principle, probably that a recommendable importation (python) command for enabling/importing bath-table-hierarchy support should be of the form
Actions
The back-end side:
bt_hierarchy
to Oslandia's mastertemporal_v2
branch to follow above mentioned "modularity principle"WIP_hierarchy_and_temporal
branch that blends (the commits of) the branchesbt_hierarchy
andtemporal_v2
. Use WIP_hierarchy_and_temporal to work onUDV-server-script
see belowUDV-server-script
(based onWIP_hierarchy_and_temporal
) that blends the following two processessemantic_hierarchy
branch)3DCityView
database viewThe front end side:
batch_table_hierarchy
branch Note: make sure that JGA's iTowns fork is aligned with iTowns'batch_table_hierarchy
branchbatch_table_hierarchy
branch.3dtiles-temporal
branch of VJA' iTowns fork. Note: depending on the success of the above described ad-hoc merging branch strategy (for having at hand a Py3DTiles branch that gathers both hierarchy and temporal extensions) adopt the same one or find something else.