2017_03_22_ _Simplify_building server_Py3DTile architecture

The current situation is that they are two concurrent architectures:

1. building-server + Py3dTiles: a REST based architecture with just-in-time 3DTiles tile-set creation (format conversion) using pre-computed tiles
2. file-server + Py3dTiles : a file based (server through http) architecture using a pre-computed 3DTiles tile-set

Research useful features provided by the building-server architecture:

• the ability to personalize the scene from the client (specify the criteria of the tile-set construction)
• provide the user/researcher with illustrations of the possible criteria (to illustrate the pro-and-cons of each criteria)
• provides a technical base for research (efficiency, reaching the desired display) on the field of the available criteria
• provide optimized/specific criteria dedicated to specific domains (urbanist, historian...)

In order to achieve this goal, on needs to:

• take the building server code
• strip it down to the REST API GetTileSet (currently GetCity), and GetTile (currently GetGeometry)
• integrate/robustify the code that enables the server side of scene-user-customization
• integrate the client side of the scene-user-customization within iTowns or UDV
• possibly adapt Py3Dtiles for the above to work
• provide associated documentation (architecture, user, developer and technical documentations)

Notes:

• Maybe envision to use the sub-model considered by CityJSON (by opposition to the full CityGML