2017_06_29_ _3DCityDB_iTowns_adapter - VCityTeam/UD-SV GitHub Wiki

Attendees: EBO, VJA

Server Workflow

After discussion with JGA, the actual workflow goes:

  • First step: Tiles preparation and computation of their bounding boxes

    • Running building-server-processdb.py fetches the geometries from the database, assign geometries to the tiles (the number of geometries assigned to the tiles depends on the value of featurespertile in conf/building.yml .

    • JGA's database model before running the script is:

    • After running the script:

    • Updated version of the database:

Adapt building server to fetch data from 3DCityDB and to visualize it in iTowns

This is the "Plan A" referred here.

Open Questions:

  • Why do we have to define the extent in conf/building.yml. Why not do it directly in the code on the server ?
  • Where is located the semantic hierarchy in 3DCityDB ?

Discoveries:

  • BoundarySurfaces are grouped in one table named thematic_surface

Reached point after first session

  • We group the geometries by semantic objects at the lowest levels of the semantic hierarchy of the data. (as opposed to JGA's way to grouping it by building). --> Arguments to come...
  • We send and id with each group of geometry, allowing to be able to retrieve additional information in the database when there is an interaction with it (client-side).
  • For a usecase that goes like: As an historian I want to annotate a part of wall. If the lowest level in the semantic hierarchy is the wall, then we only have an id corresponding to the wall client-side (i.e. we lost the polygon subdivisision originally present in the database). In this case, the client will ask the server for all the geometries of this wall which will be displayed. Then, the user can annotate the wall alongside these polygons. To store the annoation in the database, a new table can for instance be created and containing the id of the annotated geometries and the annotation.

Session of the 5th of July

  • We want to attach the id of each geometry (polygons in the database) which is in surface_geometry table of the database when encoding the tiles into 3dtiles format. This might be done using b3dm (gltf is for geometries while b3dm is for metadata and gltf is encapsulated in b3dm).
  • We must think of extending the API of building-server which is actually located in building/server/database.py in order to increase its modularity and to add more queries based on the semantic informations present in the database (such as getBuildings, getBgrides, getRoofs, etc.)
  • Contributions are for now made to this branch or to this one. We must choose!
⚠️ **GitHub.com Fallback** ⚠️