Scene Importer#
The Aerial Omniverse Digital Twin is built on NVIDIA Omniverse. As such, it requires scene geometries to be in OpenUSD format. Geospatial information, however, is often available and distributed in other formats. To bridge the gap, the Aerial Omniverse Digital Twin offers a pipeline to import geospatial data from CityGML format as well as OpenStreetMap OSM.
Import via AODT UI#
One way of running the GIS processing tools is through the AODT UI. To set up your container for this use case, the GIS container must have a data folder mounted at the container location /src/aodt_gis/data. The channel listener script must also be running.
Container setup#
As first thing, we need to log into the nvcr.io container registry using the $oauthtoken username and the NGC API Key:
docker login nvcr.io
Username: $oauthtoken
Password: <NGC_CLI_API_KEY>
More information about NGC_CLI_API_KEY can be found at NGC - User’s Guide.
Next, we run the container and mount <local data>, which is the local folder where the source data is stored:
docker run --rm -it -v <local data>:/src/aodt_gis/data --pull=always nvcr.io/esee5uzbruax/aodt-gis:1.2.0 /bin/bash
Now that we are inside the container, we start up the channel listener using:
cd /src/aodt_gis/aodt_py/aodt_ui_gis
python3 channel_listener.py --nucleus <Nucleus server IP> --broadcast <unique broadcast channel name here>
The broadcast channel listed here will be the same one used in the UI GIS tab. The container is now ready to connect to the UI.
AODT UI setup#
Connecting to a GIS worker#
Once the GIS container is set up on the host machine, you are now able to attach a worker from the UI. The worker allows the UI to trigger GIS jobs in the host machine, and for the GIS container to communicate progress and data back to the UI. Attaching the worker takes place in the GIS Channel Configuration section.
The Server path is the URL for the Omniverse Nucleus server. The Broadcast Channel Name is the name of the private channel that will be created between the UI and the GIS worker. Once established, the UI and GIS worker will communicate exclusively on this channel. The server path and broadcast channel name should be the same ones used to start up the channel listener in the GIS container.
Note: The Broadcast Channel Name must be different from the EM worker broadcast channel name. The connection will not be allowed otherwise. This is to avoid interference when an EM worker and a GIS worker is attached at the same time.
Once set, click Attach Worker to attach to an available GIS worker.
Once the server is validated and a worker is attached successfully, a confirmation window should appear:
If there are no workers available, the connection cannot be established, or the server is invalid, an error window will appear. In that case, check the server connection, validity, and that the channel listener is running on the GIS container.
Starting GIS Processing from the UI#
Once a worker is attached, we are able to trigger GML or OSM jobs. The progress bar below will communicate the status and progress of each job. Only one job can be run at once. Any logs generated by the UI or the GIS container will be in the Console tab of the UI with the Info filter enabled. Below are more details on how to start processing for each job type.
OpenStreetMap (OSM)#
An explanation of the parameters available through the graphical interface can be found in the latter sections of this document.
Assuming a worker is attached, once parameters are set, we can click the Start OSM Processing button. The progress bar below will reflect progress from the GIS container, along with status logs.
When the job completes successfully, the status will read Completed successfully, and the USD file will be in the path specified in the Output stage field. The console will contain additional information regarding the job generated by the attached worker. If the job fails, the status will read Failed (check console for more info). The console will contain more information about why the job failed.
CityGML#
An explanation of the parameters available through the graphical interface can be found in the previous section of this document.
Assuming a worker is attached, once the parameters are set, we can click the Start GML Processing button to produce the scene we want to analyze. The progress bar below will reflect progress of the GIS container in generating the scene, along with status logs.
When the job completes successfully, the status will read Completed successfully, and the USD file will be in the path specified in the Output stage field. If the job fails, the status will read Failed (check console for more info) and the console will contain more information.
Import via command line interface (CLI)#
We may also use the CityGML and OSM import tools using the CLI directly. To do so, as in other setup steps, we boot up the container by running
docker run --rm -it -v <local_path>:/src/aodt_gis/data --pull=always nvcr.io/esee5uzbruax/aodt-gis:1.1.0 /bin/bash
where <local_data> is the folder where the GIS data is contained.
CityGML Import#
The GML import script can be accessed directly at
cd /src/aodt_gis/aodt_py/aodt_ui_gis
python3 gis_jobs/gml_job.py
and it has following parameters:
Parameter |
Required |
Description |
|---|---|---|
|
Yes |
This argument specifies the URL/s of the source data. |
|
Yes |
This argument specifies the URL where the USD scene needs to be saved. |
|
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 |
|
N️o |
Specifies whether or not procedurally-generated indoor spaces are to be created. |
|
N️o |
Creates rougher cuts in the mobility mesh, ie not as tight to the footprint geometry. May be used in particularly complicated or large scenes. |
For example, suppose we would like to import a portion of Tokyo from PLATEAU.
First, run a script to download the Tokyo CityGML bundle to our data folder. Note, this may take some time.
cp /src/aodt_gis/samples/get_tokyo.bash /src/aodt_gis/data
sh /src/aodt_gis/samples/get_tokyo.bash
rm -r /src/aodt_gis/data/get_tokyo.bash
Next, we can run the command
python3 gml_job.py -i /src/aodt_gis/data/13100_tokyo23-ku_2022_citygml_1_2_op/udx/bldg/53393599_bldg_6697_2_op.gml -ei 6697 -eo 32654 -o /src/aodt_gis/data/tokyo_small.usd
The parameters
-ei 6697 -eo 32654
indicate that we are projecting from the source coordinate reference system (EPSG 6697) to the UTM (Universal Transverse Mercator) zone 54N.
Indoor spaces will be procedurally generated unless the following parameter is passed:
--disable_interiors True
Indoor spaces are created based on the building footprint per floor.
OpenStreetMap (OSM) import#
The OSM import script can be accessed directly at
cd /src/aodt_gis/aodt_py/aodt_ui_gis/
python3 gis_jobs/osm_job.py
and it has the following parameters:
Parameter |
Required |
Description |
|---|---|---|
|
Yes |
This argument specifies the URL where the USD scene needs to be saved. |
|
Yes |
This argument specifies the bounding box of the area of interest in decimal degrees and in the following order |
|
No |
Specifies whether or not procedurally-generated indoor spaces are to be created. |
For example, to import a map of the area around the University of Texas - Austin, we would run the following command:
python3 gis_jobs/osm_job.py -o /src/aodt_gis/data/ut_austin.usd -c -97.74384 30.27690 -97.72444 30.29416
Legacy CLI#
To access the CLI tool from previous releases, you may use the following commands or refer to prior version documentation. Please note that maps generated with the legacy pipeline will not support the generation of procedural indoor spaces.
For GML import,
python3 gis_jobs/legacy_gml_job.py --in_gmls /src/aodt_gis/data/13100_tokyo23-ku_2022_citygml_1_2_op/13100_tokyo23-ku_2022_citygml_1_2_op/udx/dem/533936_dem_6697_op.gml /src/aodt_gis/data/13100_tokyo23-ku_2022_citygml_1_2_op/13100_tokyo23-ku_2022_citygml_1_2_op/udx/dem/533935_dem_6697_op.gml /src/aodt_gis/data/13100_tokyo23-ku_2022_citygml_1_2_op/13100_tokyo23-ku_2022_citygml_1_2_op/udx/bldg/53393599_bldg_6697_2_op.gml /src/aodt_gis/data/13100_tokyo23-ku_2022_citygml_1_2_op/13100_tokyo23-ku_2022_citygml_1_2_op/udx/bldg/53393690_bldg_6697_2_op.gml /src/aodt_gis/data/13100_tokyo23-ku_2022_citygml_1_2_op/13100_tokyo23-ku_2022_citygml_1_2_op/udx/bldg/53393589_bldg_6697_2_op.gml /src/aodt_gis/data/13100_tokyo23-ku_2022_citygml_1_2_op/13100_tokyo23-ku_2022_citygml_1_2_op/udx/bldg/53393680_bldg_6697_2_op.gml -o /src/aodt_gis/data/tokyo_small_legacy.usd -ei EPSG:6697 -eo EPSG:32654 -s 100
And for OSM,
python3 osm_job.py -c -97.74384 30.27690 -97.72444 30.29416 -o /src/aodt_gis/data/ut_austin_legacy.usd
Sample maps#
Map name |
Source Data |
Description |
Textures |
Indoor |
|---|---|---|---|---|
|
OSM |
OSM import for the coordinates |
N |
Y |
|
A section of Kyoto defined by the following tiles. Includes DEM and procedural interiors. |
N |
Y |
|
|
Same as kyoto.usd, but without the DEM files. Demonstrates that a flat plane will be placed if no DEM is present. |
N |
Y |
|
|
A smaller and lighter map of Kyoto defined by the tile |
N |
Y |
|
|
Legacy Kyoto map covering the same region as ````kyoto.usd```. It does not contain procedural indoor spaces, but does include textures. |
Y |
N |
|
|
A portion of Tokyo with LOD4 features, defined by the tile |
N |
N |
|
|
A section of Tokyo defined by the following tiles. Includes DEM and procedural interiors. |
N |
Y |
|
|
Same as tokyo.usd, but without the DEM files. Demonstrates that a flat plane will be placed if no DEM is present. |
N |
Y |
|
|
This argument specifies the bounding box of the area of interest in decimal degrees and in the following order |
N |
Y |
|
|
Legacy Tokyo map covering the same region as |
Y |
N |
|
|
Zurich map defined by the tile |
N |
N |
|
|
This map was derived from a photogrammetry model using Blender and Omniverse. It contains layers for simulation (clean and under the |
Y |
N |