2017_10_09_ _Building_server_revolution - VCityTeam/UD-SV GitHub Wiki

Reference pictures for this meeting:

• Diagram of this need
• Diagram of this design note

Currently the Building-Server code is in repository BS-V1 (first version).

This code will evolve for the following reasons:

• easier to deploy (no need for a server)

• simplify the architecture: BS-V1 will become two different repositories

  • BS-Py3DTiles that basically is the simplification of BS-V1 in order to placed back Py3DTiles as a module to demonstrate how to build a tile-sets for a simple application. The required simplification concerns using only files for storage (as opposed to DB). Note that dynamic aspects (adding a building or removing a building) won't be ported (will be lost).
  • BS-V2 (evolution de BS-V1) that will re-use only the Py3DTiles layer and provide advanced features while remaining based on the usage of a DB. Note that the processDB part will end up in a separate repository.

• EBO: what repository should VJA follow ? BD-Py3DTiles or BS-V2 ? (think of blending the features of BS-V2 with VJA's temporality)

  • JGA: VJA has a PostGIS server (as build with 3DCityDB). 3DUse (the server par) that will has services offering functionalities like:
    • build-3DTiles without temporality: extract the geometries to a file, and simply call BS-Py3DTiles
    • build-3DTiles with temporality: same process but add temporality by forking BS-Py3DTiles to a BS-Py3DTiles-temporal. This fork is required because Py3Dtiles is not temporality aware.
  • VJA: could we adapt the migration for BDSV1 to BS-Py3DTiles in order to minimize code replication with BS-Py3DTiles-temporal ?
    • JGA: yes
  • VJA: dynamic aspects (adding a building or removing a building) that were already dealt with in BDSV1 will be lost if we use BS-Py3DTiles.
    • JGA: indeed. But is this really a required feature for FabPat.
  • VJA: what about building attributes ?
    • JGA: this can a separate service offered by 3DUSE that can interrogate the original DB with the building ID.

• JGA-VJA: there is no hope to reunite (merge) BS-Py3DTiles-temporal and BDVS2 because

  • JGA: it would require to rewrite the algorithm of scene personalization. Besides all the algorithm assumes that all buildings are constantly present (as opposed to some building present only at some times). For example it would be hard to use the geometry generalization of building (simplify it's representation, e.g. with different LOD, at rendering time) when some building are not present at some historical periods.

• EBO: how to factorize code between Py3DTiles-temporal and BS-Py3DTiles-temporal ?

  • VJA:
    • ProcessDB would need to be broken down in sub-functions. This would require JGA expertise and validation. For example processDB will need extra-arguments to deal with time (b
    • CreateGraph will change but Create_3D-tiles won't.
    • GetTileSet.Json doesn't need changes
    • GetTiles.b3Dm a priori doesn't need to change (expect that the temporal will be in the semantic part). When the JS client recieves data is analyses the tags and adapts its behavior accordingly (which will require ITowns server)

• JGA: concerning the evolution/introduction of temporality in 3Dtiles, VJA should follow what happens in Cesium

• VJA/JGA: VJA should use the MEPP-Team for of Py3DTiles that JGA will share for porting BSV1 so that there is only a single fork.
• JGA: they are some independent ongoing modifications (refactoring) of Py3DTiles that shouldn't impact VJA's work expect for call renames (WKB to B3Dm will be added). Gltf "techniques" will disappear but this will simplify work.