Extensions to the CTDB Format to Support Joint Experimentation

1
Extensions to the CTDB Format to Support Joint
Experimentation

• Dale D. Miller, Kent Cauble, David Bakeman, Mark
  Torpey, Bill Helfinstine
• Lockheed Martin Information Systems
• Andy Ceranowicz
• Alion Science and Technology

2
What is CTDB?

• Compact Terrain Database
• Developed in early 1990s for ModSAF
• Compactness important for caching
• SAF systems make frequent queries of terrain
• Physical features per patch
• terrain
• buildings
• Abstract features (quadtree)
• Linear topology
• roads
• Application queries data via CTDB API in libctdb
• Currently in use by JSAF, OTB, JWARS

3
Evolution of CTDB

• Mostly driven by DARPA STOW program
• Format 2 new types of microterrain
• Format 3 network topology and abstract features
• Format 4 TINs with topology
• Format 5 Global Coordinate System (GCS)
• Format 6 Multi-elevation surfaces (MES)
• Format 7 Enhanced MES routing, attributes on
  terrain elements

4
Whats Wrong with CTDB?

• 01S-SIW-101 Urban Human Simulation Environments
  in CTDB by Pigora, Graniela and Reece, addresses
  a number of limitations in CTDB
• particularly with respect to high density urban
  areas and MES structures
• Specifics
• Feature attribution
• Abstract features vertex limit (65536 vertices)
• Limit on number of physical features per patch
• Patch limited to 256 entries in soil table
• Geometric resolution (12.3 cm on 4 km patch)
• Physical features clipped to patches
• Fixed patch size per CTDB limits multi-resolution
• SIMNET soil type constrains mobility modeling
• GCS overlap requirements limit mix-n-match

5
USJFCOM Joint Experimentation Directorate (J9)

• Transformation laboratory for the Department of
  Defense
• develops, explores, tests, and validates
  21st-century warfighting concepts
• Utilizes JSAF / CTDB as a core federate
• Developing Distributed Continuous Experimentation
  Environment (DCEE)
• Joint Urban Operations
• Require extremely high resolution representations
  with cluttered urban environment
• Dense forested regions
• Large geographic extents

6
CTDB Workshop

• CTDB / JSAF specialists met in June, 2002
• Mark Torpey, Bill Helfinstine, David Bakeman,
  Kent Cauble, Andy Ceranowicz, Steven Prager,
  Glenn Goodman, Steve Haes, Dale Miller, Richard
  Schaffer and Mike Longtin
• Expanded charter to improve other environmental
  aspects of JSAF and did not limit considerations
  to CTDB format alone
• Prioritized recommendations for near, mid and
  long term improvements

7
Cache Mechanism for Large Databases

• JSAF uses OS to memory map terrain
• Logical addresses must exist for the entire
  virtual memory object
• The Intel 32-bit address space effectively
  limited size of terrain to 2 GB
• Added LRU caching layer
• Dynamically maps and unmaps geotiles of terrain
  from the process address space

8
GCS Extensions

• Implemented true GCS
• Center of the geotile is now the origin
• Previously, origin was southwest corner
• Benefit significant reduction in opening and
  caching terrain information

• Enhanced JSAF to operate on a terrain database
  spanning the International Date Line
• Minimized CTDB overlap at abuting geotile
  boundaries

9
Multiple Thin Levels for Map Display

• World Thin database
• Low resolution CTDB of the World
• Fast drawing when zooming out

10
Buildings in Dense Urban Areas

• Portions of STOW Southwest Asia built from
  112,500 scale City Graphics
• J9 response too clean, not enough clutter
• Examined VERTS databases
• Very dense, but small geographic extents

11
Dense Urban Areas

• Needed dense urban CTDB to investigate
  representational issues and JSAF performance
• Houston GIS data
• Geospecific building footprints
• Transportation and hydrography
• 650,000 buildings

12
Volume Feature Limitations

• The roof represented by the roofline must be
  flat.
• The footprint of the roofline must be convex.
• Each roofline is limited to less than 16
  vertices.
• To the JSAF intervisibility software, roofs are
  transparent from above.
• There is no attribution information.
• There is no way to represent balconies, eaves, or
  other protruding components

MES structures eliminate some of these
limitations, but introduce new ones
13
Raster Buildings from GIS Technology

• Each raster cell would contain
• Building height
• PAT index
• Unique ID
• 5 m raster cell 48 MB for 10 X 10 km
• Houston GIS data proved 1 m raster or smaller
  required
• 9.6 GB to represent Houston with 1 m raster

14
5 m Raster of Houston Buildings
15
Multi-Resolution Approach

• Buildings as
• Point Features
• Area Features
• Polygonal geometry

Each building instance must have all three
16
Houston, TX

• GIS data building footprints for 650,000
  buildings
• Represented in CTDB as Volumes
• 65 MB
• Ongoing research
• Efficiency of map drawing
• Intervisibility
• Vehicle movement

17
(No Transcript)
18
(No Transcript)
19
Future CTDB Enhancements

• Cheaper point-in-abstract test using
  multi-resolution representation of abstract
  features
• Bounding boxes
• Raster grids
• Cutting up large abstracts
• Initial experiments indicatepotential for 1 to 2
  ordersof magnitude efficiencyimprovement
• More flexible patch mechanismwith higher
  resolution representation of coordinates
• Virtual patches
• Variable patch sizes

20
Future Enhancements (cont.)

• Organize linear topology spatially
• Linear and abstract features for caves and
  tunnels
• Damaging multi-level microterrain bridges
• General PAT improvements
• Replace SIMNET soil type with JSIMS Surface
  Trafficability Group
• Add a PAT index to all CTDB features
• Eliminate restriction of 256 PAT entries per
  patch
• Reengineer representation and behaviors for
  building interiors
• Enhance JSAF to operate on a TDB spanning the
  poles

21
Conclusions

• CTDB is alive and well
• Readily extensible to meet higher resolution
  requirements
• JUO, building interiors
• More complex geometry
• Rich attribution