Scene Importer
The Aerial Omniverse Digital Twin builds on NVIDIA Omniverse. As such, it requires to have the geometry of the scenario under investigation in OpenUSD format. Geospatial information, however, is often available and distributed in other formats. To bridge the gap, the Aerial Omniverse Digital Twin comes with a pipeline to import geospatial data in CityGML format.
The parameters of the scene importer pipeline are:
Parameter |
Required |
Description |
|---|---|---|
--output |
Yes | This argument specifies the URL where the USD scene needs to be saved. |
--logging |
N️o | Set logging verbosity between ```[info |
--epsg_in --epsg_out --utm |
N️o | If set, the pipeline will perform a conversion between input and output coordinate reference systems, as defined by their EPSG codes. Currently, only the transform from geographic coordinate systems (angular units) to projected coordinate systems (linear units) is supported. For example, a transform from EPSG:6697 to EPSG:32654 would be expressed as --epsg_in EPSG:6697 --epsg_out EPSG:32654. In lieu of --epsg_out, a UTM zone is also accepted (e.g. --utm 54). |
--scaling |
N️o | A scaling factor may be necessary if the target EPSG is in units other than meters. This argument can be used to specify the number of centimeters contained in the unit of measurement used in the geospatial data. E.g., 100 for meters (default) and 30.48 for feet. |
--textures |
N️o | If present, colocated with the input files and referenced therein, the textures will be copied to the destination specified by --output. We can use --textures 0 to ensure that this does not occur. |
--textures_out_prefix |
No | Explicitly set the texture directory. |
--flatten |
N️o | If a digital elevation data (DEM) is available, it may be included in the input files argument. If a DEM is not available, all buildings may be adjusted to a flat ground plane using the --flatten argument. |
--adjust_height_threshold |
No | Depending on the data source, there may be a discrepancy between a CityGML building bldg:measuredHeight and its rendered height. Where this is a cause for concern and better geospatial data cannot be obtained, --adjust_height_threshold can be used to ensure that the building footprints are extruded to bld:measuredHeight. |
--mobility_scale |
N️o | This flag defines the maximum size that an edge is allowed to have in the mobility domain mesh generated by the pipeline (default = 400 in target units of measurements, i.e., centimeters). In large scenes, this may be used to improve performance. A warning will be generated in those cases where there are excessive triangles in the resulting mobility mesh. |
Using the PLATEAU open data as reference, a small model of Tokyo can be built as follows.
First, we can run the aodt_gis container using the following command
docker run -it --name aodt-gis --entrypoint /bin/bash nvcr.io/esee5uzbruax/aodt-gis:1.0.0
Once inside the container, update permissions on the aodt_gis folder:
cd src/
chmod 777 aodt_gis
Then, we can use the following commands to run a script to download the CityGML bundle describing Tokyo.
cd src/aodt_gis/samples/input_data
./get_tokyo.sh
Next, we will copy template.usd Users/<User>/assets to a target folder on the Nucleus server, e.g., Users/<User>/plateau and rename the file to sample.usd. This can be done either with Omniverse launcher or using the Content tab in the Aerial Omniverse Digital Twin user interface.
Authenticate to Omniverse from within the container:
export OMNI_USER=<Insert Your Username>
export OMNI_PASS=<Insert Your Password>
With the source data and target USD URL identified, we can then run
cd src/aodt_gis/build
./aodt_gis \
../samples/input_data/13100_tokyo23-ku_2022_citygml_1_2_op/udx/bldg/53393599_bldg_6697_2_op.gml
../samples/input_data/13100_tokyo23-ku_2022_citygml_1_2_op/udx/bldg/53393690_bldg_6697_2_op.gml
../samples/input_data/13100_tokyo23-ku_2022_citygml_1_2_op/udx/bldg/53393589_bldg_6697_2_op.gml
../samples/input_data/13100_tokyo23-ku_2022_citygml_1_2_op/udx/bldg/53393680_bldg_6697_2_op.gml
--output omniverse://<Nucleus Server IP>/Users/<User>/plateau/sample.usd --epsg_in EPSG:6697 --epsg_out EPSG:32654
which will take the 4 tiles described by each GML file and merge them into Users/<User>/plateau/sample.usd. The parameters
--epsg_in EPSG:6697 --epsg_out EPSG:32654
indicate that we are projecting from the source coordinate reference system (EPSG 6697) to the UTM (Universal Transverse Mercator) zone 54N.
Unless otherwise configured, textures will be moved to the destination folder where the generated USD file resides.
To process GIS data from the host machine, we recommend mounting a volume to the aodt_gis container. This is particularly useful with large datasets.
Suppose your data is located in the folder C:/Users/myname/gis_data (Windows) or ./gis_data (Linux) on the host machine. To process this data, start the container as follows:
Windows:
docker run -t -i -v C:/Users/myname/gis_data:/src/aodt_gis/gis_data --entrypoint /bin/bash nvcr.io/esee5uzbruax/aodt-gis:1.0.0
Linux:
docker run -t -i -v ./gis_data:/src/aodt_gis/gis_data --entrypoint /bin/bash nvcr.io/esee5uzbruax/aodt-gis:1.0.0
The GIS data is now accesible inside the container at the location /src/aodt_gis/gis_data. For example, if the Tokyo
PLATEAU data has been downloaded to this location, you can run the following commands to process it:
cd src/aodt_gis/build
./aodt_gis \
../gis_data/13100_tokyo23-ku_2022_citygml_1_2_op/udx/bldg/*.gml
--output omniverse://<Nucleus Server IP>/Users/<User>/plateau/sample.usd --epsg_in EPSG:6697 --epsg_out EPSG:32654
Note the use of the wildcard (*), which will process all CityGML files in the folder.