search

opengeospatial / OGC-ISG-Sprint-Sep-2020

3 stars 5 forks source link

Seeking help on Automatic Updates on CDB data #9

Open 82siha1mpg opened 3 years ago

82siha1mpg commented 3 years ago

We have successfully conducted live updates on San Diego dataset (CityGML to 3D Tiles). The methodology is implemented for "delete" and "add" objects to the existing 3D Tile dataset. I am sharing the screenshots of the results we have achieved so far. But the issue is I am not able to do CDB to 3D Tiles conversions which is required in our live update methodology to trigger updates (add/delete). If anybody can help us in CDB to 3D Tiles conversion , it will be great?

Results of Live Updates:

image

image

image

image

jeffharrison commented 3 years ago

This is great progress. If there are any additional details on how the objects are 'added' and 'deleted' to and from the existing 3D Tile dataset we would welcome them...

Thanks and Regards, Jeff

jerstlouis commented 3 years ago

@jeffharrison one approach which I discussed with @82siha1mpg yesterday would be to use OGC API - Features transactions extension to add or remove objects. e.g. POSTing a GeoJSON point feature referencing a model to http://maps.ecere.com/ogcapi/collections/SanDiegoCDB:Buildings/items to add a new building.

In addition, a new 3D model to reference could be POSTed to a models end-points e.g. https://maps.ecere.com/ogcapi/collections/SanDiegoCDB:Buildings/models/ (as either an OpenFlight, or glTF, or COLLADA, or 3DS, or E3D, etc.). This is something we also use in the Tiles API approach to reference 3D models -- example model at https://maps.ecere.com/ogcapi/collections/SanDiegoCDB:Buildings/models/1476625110.glb.

Then the corresponding 3D Tiles tileset at http://maps.ecere.com/ogcapi/collections/SanDiegoCDB:Buildings/3DTiles/tileset.json is automatically updated to reflect this.

A ChangeSets API could also be used to request only the tiles affected between 2 particular checkpoints. Or if the server maintains the history, one could ask for the data at a specific point.

For terrain, OGC API - Coverage transactions (or something like the Images API to work on multi-scene coverages) could be used to update elevation data as well in a similar manner.

We are going to discuss this more today with the Steinbeis team, and may do some experiments towards this.

jeffharrison commented 3 years ago

@jerstlouis Thanks. These sound like great methods to explore, and the capability is very much needed.

Best Regards, Jeff

82siha1mpg commented 3 years ago

Thanks @jerstlouis. The idea you proposed sounds very good. Something I would really look into. I would be glad to share the idea @jeffharrison, thanks for asking. So here the idea is, Server receives the changes (can be either Put/Post request) to receive the new model data which in my case is CityGML yet. On receiving the change request (add/delete), it traverses the existing tile tree structure. In case of delete: methodology is to identify the "unique building id" within the B3dm files of existing dataset and update the b3dm file. Similarly to add a new object existing tile tree structure will be traversed to identify where in the tree the new object will fit, which then will be added to the b3dm.

The following image shows the overall concept:

image

Thanks :)