AODT 1.5.1: prepare_map fails with KeyError: 'tiledusd_mode' in aodt-gis-runtime:1.5.1

Accelerated Computing Aerial Forum
1

prepare_map fails during USD generation with a KeyError on a config key the client cannot set.

Repo at commit 3cc464a. Images aodt-sim-runtime:1.5.1 and aodt-gis-runtime:1.5.1 from the published manifest.

Stock example, small bounding box:

python examples/example_prepare_map.py \
  --s3_endpoint http://minio:9000 \
  --s3_access_key minioadmin --s3_secret_key minioadmin \
  --output_folder_key kochi_test/test_osm.usd \
  --min_lon 76.2823 --min_lat 9.9462 \
  --max_lon 76.2923 --max_lat 9.9562

Fails after about 15 seconds:

ApplicationError: RuntimeError: USD generation failed: 'tiledusd_mode'
  -> ApplicationError: KeyError: 'tiledusd_mode'

tiledusd_mode does not appear in client/protos/service.proto, and it is not in the parameter table on the Scene Generation docs page. There is no client side way to supply it. I also ran the same job with every optional parameter set explicitly instead of left as None (cesium3dtiles_b3dm=True, draco=True, gzip=True, chunk_size=50000, veg_instanced=True, rough=True, disable_interiors=False). Identical failure.

This looks like a mismatch between the published client proto and what the GIS runtime expects. Is there a patch tag for the GIS image, or a config override that populates the key?

Ruling out the documented causes. The box is about 1.2 km², well under the 25 km² practical limit and the 100 km² cap. MinIO is reachable and writable: the same stack wrote six Parquet setup tables to s3://aerial-data/ and registered them in the Nessie Iceberg catalog in the same session. The GIS worker connects to Temporal and polls gis-prepare-map normally, and the OSM fetch completes. Only USD generation fails.

Environment: Ubuntu 22.04 container, x86_64, Docker Compose v2, worker stack from worker/docker-compose.yml with the default MinIO, Nessie and Temporal services.

2

@aditya.chaudhuri1 We are aware of this issue. Please standby for guidance.

3

Thanks. For anyone hitting this in the meantime: I got a custom scene in by converting a 1.4.x-era USD stage rather than generating a new one. Three changes were needed — asim:crs, asim:center_lat and asim:center_lon authored on /World (the docstring in aodt/mobility/utils.py says /World/ground_plane, but world_prim.py reads them from /World), geometry reparented under a /World/tile_0 Xform so _get_bldg_and_terrain_prims_per_window picks it up, and scenario coordinates matching the scene. Loads cleanly: 13,896 buildings, 5.86M triangles.

Worth flagging the stale docstring separately if that’s useful.

4

@aditya.chaudhuri1 We have released a patch to the GIS container: http://nvcr.io/nvidia/aerial/aodt-gis-runtime:1.5.1-1. Pull the patch.yaml and restart the container. Do the following:

  1. Stop all the containers
  2. cd worker
  3. git fetch origin
  4. git restore --source=origin/main – ./patch.yaml
  5. Restart the containers.

This should fix the issue.

5

@kpasad1 Confirmed fixed with aodt-gis-runtime:1.5.1-1. The same bbox that failed with the tiledusd_mode KeyError now completes prepare_map in ~23 s and writes the full map package (master.usd + tiles, map.osm, vegetation, viz tilesets) to MinIO. Verified the generated stage opens cleanly, and the tile carries real geometry.

Two notes for anyone else applying the patch:

  1. patch.yaml is consumed by ./worker/up.sh. If you start the stack with docker compose directly and a hand-written worker/.env (we do, on a GCP node where up.sh’s EC2 metadata probe misfires), the patch won’t apply on its own — set GIS_IMAGE=nvcr.io/nvidia/aerial/aodt-gis-runtime:1.5.1-1 in worker/.env yourself.

  2. The --s3_endpoint passed to example_prepare_map.py is used within the gis-worker container, so http://localhost:9000 fails during the upload step with EndpointConnectionError. Use the compose service name: http://minio:9000.

Thanks for the quick turnaround on this.