EricBoix
commented
3 years ago Some remarks
The chemistry valley data processing container that you point is alas unfinished work...
Under the hood, there is a computational pipeline that as indicated by the Dockefile uses a python+docker based pipeline to realize the computations. As poorly documented for the static case (i.e. the non temporal version) the pipeline is a simplification of the diagram standing at the head of that PythonCallingDocker page and boils down to the Chemistry Valley (entrypoint.sh) pipeline.
If what you need is a loaded up 3dCityDB database, it should suffice to consider the first part of that pipeline, and stop at line 8 of that script.
Related info
Note that the manual way of things (that should be avoided because it is not reproducible), for the Chemistry Valley (that is the upstream information that led to the chemistry valley data processing container) is documented in the associated DEMO. This manual instruction set indirectly documents the importance of the demo_configuration.py configuration file which explains this Dockerfile line.
Possible hints
- Have the author of the Dockerized pipeline fix the current limitations, or have the Chemistry Valley product owner fix them or even better fix them yourself.
- Transpose the result to fit your needs (i.e. provide your ad-hoc patch file)
There is a need to propose a docker that allows to automatically fill a 3DCityDB with borough name to fetch in OpenData GrandLyon.
It should be very similar to the Chemistry Valley