cesiumgs / cdb-to-3dtiles Goto Github PK

Convert CDB to 3D Tiles

License: Apache License 2.0

CMake 1.01% C++ 98.80% Shell 0.12% Dockerfile 0.08%

cdb-to-3dtiles's Introduction

CDB to 3D Tiles

Convert Open Geospatial Consortium (OGC) CDB datasets to 3D Tiles OGC Community Standard for efficient streaming and rendering across multiple platforms and devices.

Converted tilesets faithfully match the level of detail and precision of the source CDB, with support for most common CDB layers and their associated feature attributes. See Features for a full list of supported datasets and Performance for performance comparisons.

3D Tiles is designed for efficient runtime visualization and analytics. The pipeline preserves feature attributes from CDB, enabling runtime querying, styling, and analytics to gain deeper insights into the data.

View of downtown San Diego with terrain, imagery, clamped building models, instanced trees, and Coronado Bridge in the distance, loaded as 3D Tiles in CesiumJS. See the live demo here.

🚀 Getting Started

See Getting Started for installation, build, and usage instructions.

📗 License

Apache 2.0. CDB to 3D Tiles is free for both commercial and non-commercial use. See LICENSE.md for more details.

The San Diego CDB end-user license agreement can be found here.

✨ Contributions

Pull requests are appreciated. Please use the same Contributor License Agreement (CLA) used for CesiumJS.

📋 Features

The following CDB features are supported:

Feature checklist

Dataset	CDB Name	Supported
Primary Elevation	`001_Elevation`	✔️
Primary Imagery	`004_Imagery`	✔️
Road Network	`201_RoadNetwork`	✔️
Rail Road Network	`202_RailRoadNetwork`	✔️
Power Line Network	`203_PowerLineNetwork`	✔️
Hydrography Network	`204_HydrographyNetwork`	✔️
Geotypical models	`101_GTFeature`, `500_GTModelGeometry`, `501_GTModelTexture`	✔️
Geospecific models	`100_GSFeature`, `300_GSModelGeometry`, `301_GSModelTexture`	✔️
Moving models	`600_MModelGeometry`, `601_GSModelTexture`	❌
Min Max Elevation	`002_MinMaxElevation` `003_MaxCulture`	❌
Geopolitical Boundaries	`102_GeoPolitical`	❌
Vector Materials	`200_VectorMaterial`	❌
Raster Materials	`005_RMTexture`, `006_RMDescriptor`	❌
Navigation	`400_NavData`, `401_Navigation`	❌
Bathymetry		❌
Seasonal Imagery		❌

Additional capabilities

Capability	Supported
Preserve instance and class attributes for models and vector layers	✔️
Preserve geometry and texture quality with command line options for controlling mesh decimation	✔️
Clamp models to the primary elevation dataset	✔️
Clamp vector layers to the primary elevation dataset	❌

Roadmap

Windows support
Performance improvements
Automatic upload to Cesium ion
Support more CDB datasets
Clamp vector layers
Output 3D Tiles Next (for interoperability with One World Terrain Well-Formed Format)

If you would like to provide feedback or accelerate the product roadmap for features you would like to see included, please contact Shehzan Mohammed.

CDB versions

All versions of CDB are supported. CDB 3.0 and CDB OGC 1.2 (draft) have been tested most during development.

🏁 Performance

Performance numbers for San Diego CDB measured on a Dell XPS 15 7590

Dataset	Time Elapsed	CDB Size	3D Tiles Size
Elevation and Imagery	38 minutes	20.3 GB	17.1 GB
Road Network	2 seconds	166.8 MB	121.3 MB
Hydrography Network	0.2 seconds	605 kB	533.4 kB
GTModel	0.8 seconds	221.2 MB	3.2 MB
GSModel	9 minutes	7.6 GB	1.8 GB
Total	47 minutes	28.3 GB	19.0 GB

Getting Started

Prerequisites

Linux (Windows support coming soon)
C++ compiler that supports C++17 (tested on GCC 9.3.0)
CMake version 3.15 or higher
GDAL version 3.0.4 or higher
OpenGL (needed by OpenSceneGraph)

To install GDAL 3.0.4 on Debian-based systems:

sudo add-apt-repository ppa:ubuntugis/ppa && sudo apt-get update
sudo apt-get update
sudo apt-get install libgdal-dev

To install OpenGL on Debian-based headless systems:

sudo apt-get install libgl1-mesa-dev

Installing

Clone the repo with:

git clone --recurse-submodules [email protected]:CesiumGS/cdb-to-3dtiles.git

If --recurse-submodules is omitted, run the following command to update submodules:

git submodule update --init --recursive

Building

The converter can be built on the command-line with CMake (given that you satisfy all prerequisites):

cmake -B Build -S .
cmake --build Build --config Release -j 4

The executable can be found in the directory Build/CLI/CDBConverter

Usage

Usage:

  CDBConverter [OPTION...]

  -i, --input arg               CDB directory
  -o, --output arg              3D Tiles output directory
      --combine arg             Combine converted datasets into one tileset.
                                Each dataset format is
                                {DatasetName}_{ComponentSelector1}_{ComponentSelector2}. Repeat this
                                option to group different dataset into
                                different tilesets.E.g:
                                --combine=Elevation_1_1,GSModels_1_1 --combine=GTModels_2_1,GTModels_1_1
                                will combine Elevation_1_1 and GSModels_1_1 into
                                one tileset. GTModels_2_1 and GTModels_1_1
                                will be combined into a different tileset
                                (default: Elevation_1_1,GSModels_1_1,GTModels_2_1,GTModels_1_1)
      --elevation-normal        Generate elevation normal
      --elevation-lod           Generate elevation and imagery based on
                                elevation LOD only
      --elevation-decimate-error arg
                                Set target error when decimating elevation
                                mesh. Target error is normalized to 0..1 (0.01
                                means the simplifier maintains the error to be
                                below 1% of the mesh extents) (default: 0.01)
      --elevation-threshold-indices arg
                                Set target percent of indices when decimating
                                elevation mesh (default: 0.3)
  -h, --help                    Print usage

Example

The following command converts San Diego CDB to 3D Tiles:

./Build/CLI/CDBConverter -i CDB_san_diego_v4.1 -o San_Diego

Unit Tests

To run unit tests, run the following command:

./Build/Tests/Tests

Docker

You can use Docker to simplify setting up the environment for building and testing. You must install Docker Engine CE For Ubuntu to do so.

The converter can be built with:

./Docker/build-container.sh
./Docker/build-cdb-to-3dtiles.sh

The executable can be found in the directory Build/CLI/CDBConverter

Run units tests with the following command:

./Docker/run-tests.sh

3D Tiles Structure

The converter generates multiple 3D Tilesets from the input CDB:

Primary Elevation and Primary Imagery are combined into a single tileset
Geotypical models are combined into a single tileset
Geospecific models are combined into a single tileset
Vector datasets are written as separate tilesets:
- Road Network
- Rail Road Network
- Power Line Network
- Hydrography Network

The generated tilesets will be placed in a GeoCell directory similar to how the CDB is organized. For example, the generated tilesets for San Diego will be placed in the San_Diego/Tiles/N32/W118 directory.

A CDB tile can store different geometries depending on its component selectors. For example, a Hydrography Network tile can have lineal and polygon features within the same tile, which are differentiated by their second respective component selector in the file name. For this reason, a tileset.json will be placed in the directory name that make up of the two component selectors, {Component Selector 1}_{Component Selector 2}. For example:

The lineal tileset of the Hydrography Network dataset will be placed in HydrographyNetwork/2_3 directory
The polygon tileset of the Hydrography Network dataset will be placed in HydrographyNetwork/2_5 directory

Below is the output directory of the converted San Diego 3D Tiles:

Releases

We release as often as needed. CDB To 3D Tiles strictly follows semver.

Update the project version number in CMakeLists.txt
Proofread CHANGES.md and make any required updates
Make sure all unit tests pass
Commit and push the above changes to main
Create a git tag for the version and push it:
- git tag -a 0.1.0 -m "0.1.0 release"
- git push origin 0.1.0

Featured Demo

Live Demo of San Diego terrain, imagery, and models. Click individual models or vector features to see their metadata.

cdb-to-3dtiles's People

Contributors

Stargazers

Watchers

cdb-to-3dtiles's Issues

CDB conversion output errors

Issue seeing: Undesirable output from CDB to 3DTiles after using converter.
Background:
CDB created via Terra Vista
Input data used: DTED1 and JPG2000 image
CDB-to-3DTiles Converter Used on CDB dataset.
When opening the tileset.json in image generator, seeing quiet a bit of flickering (LOD's fighting maybe), elevation gapping "slits in terrain", gridded artifacts on terrain (almost seems like the underlying squares from the DTED are splitting into the overlaying imagery causing a grid pattern to appear on 3D Terrain.

Am I possibly not including something in the converter that I should be to avoid some of these errors or are there any steps/tests I can attempt to try and fix one issue at a time?

I've attempted running the converter with the different arguments posted in the --help portion, but seem to continue getting the same issues.

Thanks for any assistance.

Convert GSModel to tile

Clean up the code that converting GSModel to tile and clamp those models to the underlying terrain

CDBConverter does not compile

Hi,

i have followed the Getting Start below in a clean Ubuntu 20.10 machine:
https://github.com/CesiumGS/cdb-to-3dtiles#getting-started

When i try to compile i have several errors such as:


[ 99%] Building CXX object CDBTo3DTiles/CMakeFiles/CDBTo3DTiles.dir/src/CDBGeoCell.cpp.o
In file included from /home/diginext/CDB_To_3DTiles/cdb-to-3dtiles/CDBTo3DTiles/src/CDBGeoCell.h:3,
                 from /home/diginext/CDB_To_3DTiles/cdb-to-3dtiles/CDBTo3DTiles/src/CDBGeoCell.cpp:1:
/home/diginext/CDB_To_3DTiles/cdb-to-3dtiles/CDBTo3DTiles/include/Utility.h:15:13: error: ‘string’ in namespace ‘std’ does not name a type
   15 | inline std::string toStringWithZeroPadding(size_t numOfZeroes, T num)
      |             ^~~~~~

and:



[ 99%] Building CXX object CDBTo3DTiles/CMakeFiles/CDBTo3DTiles.dir/src/CDBTile.cpp.o
/home/diginext/CDB_To_3DTiles/cdb-to-3dtiles/CDBTo3DTiles/src/CDBGeoCell.cpp: In member function ‘std::string CDBTo3DTiles::CDBGeoCell::getLongitudeDirectoryName() const’:
/home/diginext/CDB_To_3DTiles/cdb-to-3dtiles/CDBTo3DTiles/src/CDBGeoCell.cpp:95:22: error: ‘toStringWithZeroPadding’ was not declared in this scope
   95 |         return "W" + toStringWithZeroPadding(3, -m_longitude);
      |                      ^~~~~~~~~~~~~~~~~~~~~~~

How to fix this ?
Is there a prebuild version somewhere ?

Regards,

Possible issue with path separators

There has been an issue report, indicating that the output of cdb-to-3dtiles cannot be loaded in CesiumJS. According to the thread at https://community.cesium.com/t/error-on-b3dm-from-3dtiles/31944/5 , CesiumJS could not load a file that was named like Textures\example.jpeg, and it had to be fixed somewhere here in CDBTo3DTiles.cpp.

(I assume that a std::filesystem::path will be converted into the platform-specific string, which may include a \ on windows - but for a URI, it should always be a /)

Generate tighter bounding region for tile

The minimum height and maximum height of the regions in the tileset JSON files all seem to be 0.0. The bounding region is implicitly to be the region of the quadtree. However, it is still too large compared to tile content. Some work for this is done in the branch https://github.com/CesiumGS/cdb-to-3dtiles/tree/tight-bound-box

Rename Math.h

This is going to cause a lot of build issues on Windows, as Visual Studio is case insensitive with headers. Perhaps MathHelpers.h or MathLib.h

San_Diego example is not complet

Hi,

A texture seems to be in a wrong folder:

./Build/CLI/CDBConverter -i CDB_san_diego_v4.1 -o San_Diego

= > Can't find texture (2) D:/textures/tree.rgb

Make Dockerfile and build instructions for Docker build container

Requirements so far:

gdal v3.0.4
OpenSceneGraph v3.4.0
libpng
libjpeg
zlib

@lilleyse @baothientran If there is anything else let's put it down here

Elevation layer and imagery layer should have the same LOD

Elevation layer and imagery layer can have different LOD in CDB. However, when converting to tile, they should have the same LOD since imagery is used as texture for elevation

Add logging and progress reporting

The converter should have these logging and progressing reporting capabilities

Print warnings and errors
Print info about the source data and output tileset: number of tiles, number of buildings, etc
Print time to process each dataset (e.g. terrain/imagery, GSModel, GTModel, vector layers)
Show percentage complete

Whatever logging system we use, it should be compatible with Cesium ion and modeled after the tilers

EXT_feature_metadata buffers are not 8-byte aligned

This pertains specifically to #58

I ran into this issue with a cdb-to-3dtiles-next tileset, it seems like sometimes the metadata buffers aren't 8-byte aligned (as the extension spec prescribes). I briefly looked through the cdb-to-3dtiles code and I didn't catch any 8-byte alignment of the metadata buffers, so that seemed to confirm my understanding.

Again I looked only briefly at the code here; the issue may be a bad implementation on my end or a misunderstanding of the spec even, feel free to close this if that is the case!

@sanjeetsuhag

Add LICENSE.md

Add a LICENSE.md file like CesiumJS's LICENSE.md.

This file will include the license for cdb-to-3dtiles - Apache 2.0 - and a list of third party library licenses.

Setup CI

For each commit CI should build the project and run unit tests, and eventually do linting and other things.

Use Cesium Native for core geospatial math

CDB to 3D Tiles should include Cesium Native for its core geospatial classes like Ellipsoid and BoundingRegion rather than having clones here.

See https://github.com/CesiumGS/cesium-native/tree/master/CesiumGeospatial

Tile availability and content availability are written to separate buffers

{
  "bufferViews": [
    {
      "buffer": 0,
      "byteLength": 683,
      "byteOffset": 0
    },
    {
      "buffer": 1,
      "byteLength": 683,
      "byteOffset": 0
    }
  ],
  "buffers": [
    {
      "byteLength": 688
    },
    {
      "byteLength": 688,
      "uri": "../availability/7_0_0.bin"
    }
  ],
  "childSubtreeAvailability": {
    "constant": 0
  },
  "contentAvailability": {
    "bufferView": 1
  },
  "tileAvailability": {
    "bufferView": 0
  }
}

The tiler is writing the tileAvailability and contentAvailability to separate buffers even when they have identical data - as they most often will, with CDB datasets.

Segmentation fault (core dumped)

Centos8.3
gcc/g++ 10.1.0
[root@localhost CDB]# ./CDBConverter -h
Convert CDB to 3D Tiles
Usage:
CDBConverter [OPTION...]

-i, --input arg CDB directory
-o, --output arg 3D Tiles output directory
--combine arg Combine converted datasets into one tileset.
Each dataset format is
{DatasetName}{ComponentSelector1}{ComponentSelector2}. Repeat this
option to group different dataset into
different tilesets. E.g:
--combine=Elevation_1_1,GSModels_1_1 --combine=GTModels_2_1,GTModels_1_1
will combine Elevation_1_1 and GSModels_1_1
into one tileset. GTModels_2_1 and GTModels_1_1
will be combined into a different tileset
(default:
Elevation_1_1,GSModels_1_1,GTModels_2_1,GTModels_1_1)
--elevation-normal Generate elevation normal
--elevation-lod Generate elevation and imagery based on
elevation LOD only
--elevation-decimate-error arg
Set target error when decimating elevation
mesh. Target error is normalized to 0..1 (0.01
means the simplifier maintains the error to be
below 1% of the mesh extents) (default: 0.01)
--elevation-threshold-indices arg
Set target percent of indices when decimating
elevation mesh (default: 0.3)
-h, --help Print usage

Segmentation fault (core dumped)

Convert GTModel to tiles

Implement conversion from GTModel to tiles and clamp them into the underlying terrain

Seperate Elevation and Imagery in the --combine option

The relationship between elevation and imagery is a little unclear. I think elevation and imagery should both be supplied in --combine if you want to combine them into the same tileset. Someone may want to convert elevation without the imagery. However, the converter would need to print an error if imagery is converted and elevation is not.

Update README links once `3d-tiles-next` branch is merged

in the 3d-tiles-next README there's a link to a live demo of the GSModels dataset. Once this branch is merged, that demo link (and perhaps other links) need to be updated.

CC @lilleyse

Process all substrates in Composite Material Tables

From the OGC CDB Core Standard: Model and Physical Data Store Structure, Page 53:

2.5.2.2 Composite Material Tables (CMT)

Composite Material Tables provide the means by which Composite Materials can be defined.
Each entry within a Composite Material Table defines a structured arrangement of basic
materials or of aggregates (i.e., a Composite Material). Each Composite Material entry is
assigned a Composite Material Index (and an optional name). CDB datasets can then make use
of the index value in order to select Composite Materials.

There are several Composite Material Tables spread across the CDB hierarchy. Note however
that all Composite Material Tables follow a common XML notation that describes each
Composite Material into its primary substrate, surface and secondary substrate components.
Composite Materials Tables can take various forms, either as distinct XML files or embedded
XML code within a file.

The XML encoding is as follows:

Currently, this pipeline only supports processing and storing the Primary Substrate. When data is made available that has Composite Materials with the Surface and Secondary Substrate(s), we should add support for processing those properties. It should be trivial to add to the pipeline. These properties, along with the Thickness property for each substrate, should be optional in EXT_feature_metadata.

Texture coordinates get generated for elevation mesh even when imagery doesn't exist

During testing of #33 I removed the imagery directory from the San Diego CDB and noticed that texture coordinates were still being generated in the elevation glTFs.

{
  "accessors": [
    {
      "bufferView": 0,
      "componentType": 5125,
      "count": 471084,
      "type": "SCALAR"
    },
    {
      "bufferView": 1,
      "componentType": 5126,
      "count": 79075,
      "max": [
        1713.0170656796545,
        1533.5914149750024,
        1483.8258464434184
      ],
      "min": [
        -1713.0170656801201,
        -1533.5914149750024,
        -1483.8258464434184
      ],
      "type": "VEC3"
    },
    {
      "bufferView": 2,
      "componentType": 5126,
      "count": 79075,
      "type": "VEC2"
    }
  ],
  "asset": {
    "version": "2.0"
  },
  "bufferViews": [
    {
      "buffer": 0,
      "byteLength": 1884336,
      "target": 34963
    },
    {
      "buffer": 0,
      "byteLength": 948900,
      "byteOffset": 1884336,
      "target": 34962
    },
    {
      "buffer": 0,
      "byteLength": 632600,
      "byteOffset": 2833236,
      "target": 34962
    }
  ],
  "buffers": [
    {
      "byteLength": 3465836
    }
  ],
  "meshes": [
    {
      "primitives": [
        {
          "attributes": {
            "POSITION": 1,
            "TEXCOORD_0": 2
          },
          "indices": 0,
          "mode": 4
        }
      ]
    }
  ],
  "nodes": [
    {
      "children": [
        1
      ],
      "matrix": [
        1.0,
        0.0,
        0.0,
        0.0,
        0.0,
        0.0,
        -1.0,
        0.0,
        0.0,
        1.0,
        0.0,
        0.0,
        0.0,
        0.0,
        0.0,
        1.0
      ]
    },
    {
      "mesh": 0,
      "translation": [
        -2453392.5088799754,
        -4773145.2354162345,
        3435070.9613821013
      ]
    }
  ],
  "scenes": [
    {
      "nodes": [
        0
      ]
    }
  ]
}

Make executable more portable

There's a couple things we should eventually fix to make the CDBConverter executable more portable.

The docker built executable uses GLIBC_2.29 which only works on newer distros. Do we need to downgrade to C++11?
GDAL is not statically linked so it needs to be installed on the user's system
OpenGL is required through OpenSceneGraph and also needs to be installed on the user's system. Is it safe to statically link OpenGL system libraries?

ldd of the docker built executable:

    linux-vdso.so.1 (0x00007ffef390a000)
    libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 (0x00007f1f934a8000)
    libjpeg.so.8 => /lib/x86_64-linux-gnu/libjpeg.so.8 (0x00007f1f93423000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f1f9341d000)
    libGL.so.1 => /lib/x86_64-linux-gnu/libGL.so.1 (0x00007f1f93395000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f1f93372000)
    libgdal.so.26 => /lib/libgdal.so.26 (0x00007f1f91feb000)
    libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f1f91e08000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1f91cb9000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f1f91c9e000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1f91aac000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f1f91a90000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f1f93b1f000)
    libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f1f919d8000)
    libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 (0x00007f1f919a2000)
    libarmadillo.so.9 => /lib/libarmadillo.so.9 (0x00007f1f9198f000)
    libpoppler.so.97 => /lib/x86_64-linux-gnu/libpoppler.so.97 (0x00007f1f9164a000)
    libjson-c.so.4 => /lib/x86_64-linux-gnu/libjson-c.so.4 (0x00007f1f91638000)
    libfreexl.so.1 => /lib/x86_64-linux-gnu/libfreexl.so.1 (0x00007f1f9162d000)
    libqhull.so.7 => /lib/x86_64-linux-gnu/libqhull.so.7 (0x00007f1f913d3000)
    libgeos_c.so.1 => /lib/x86_64-linux-gnu/libgeos_c.so.1 (0x00007f1f9138e000)
    libwebp.so.6 => /lib/x86_64-linux-gnu/libwebp.so.6 (0x00007f1f91125000)
    libepsilon.so.1 => /lib/x86_64-linux-gnu/libepsilon.so.1 (0x00007f1f9110b000)
    libodbc.so.2 => /lib/x86_64-linux-gnu/libodbc.so.2 (0x00007f1f91099000)
    libodbcinst.so.2 => /lib/x86_64-linux-gnu/libodbcinst.so.2 (0x00007f1f91081000)
    libkmlbase.so.1 => /lib/x86_64-linux-gnu/libkmlbase.so.1 (0x00007f1f91064000)
    libkmldom.so.1 => /lib/x86_64-linux-gnu/libkmldom.so.1 (0x00007f1f90fc1000)
    libkmlengine.so.1 => /lib/x86_64-linux-gnu/libkmlengine.so.1 (0x00007f1f90f87000)
    libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f1f90f59000)
    libxerces-c-3.2.so => /lib/x86_64-linux-gnu/libxerces-c-3.2.so (0x00007f1f90bc6000)
    libopenjp2.so.7 => /lib/x86_64-linux-gnu/libopenjp2.so.7 (0x00007f1f90b70000)
    libnetcdf.so.15 => /lib/x86_64-linux-gnu/libnetcdf.so.15 (0x00007f1f90a4b000)
    libhdf5_serial.so.103 => /lib/x86_64-linux-gnu/libhdf5_serial.so.103 (0x00007f1f906cc000)
    libmfhdfalt.so.0 => /lib/libmfhdfalt.so.0 (0x00007f1f906a2000)
    libdfalt.so.0 => /lib/libdfalt.so.0 (0x00007f1f905fd000)
    libogdi.so.4.1 => /lib/libogdi.so.4.1 (0x00007f1f905e1000)
    libgif.so.7 => /lib/x86_64-linux-gnu/libgif.so.7 (0x00007f1f905d6000)
    libCharLS.so.2 => /lib/x86_64-linux-gnu/libCharLS.so.2 (0x00007f1f90587000)
    libgeotiff.so.5 => /lib/x86_64-linux-gnu/libgeotiff.so.5 (0x00007f1f90550000)
    libtiff.so.5 => /lib/x86_64-linux-gnu/libtiff.so.5 (0x00007f1f904cf000)
    libcfitsio.so.8 => /lib/x86_64-linux-gnu/libcfitsio.so.8 (0x00007f1f901d0000)
    libpq.so.5 => /lib/x86_64-linux-gnu/libpq.so.5 (0x00007f1f90180000)
    libproj.so.15 => /lib/x86_64-linux-gnu/libproj.so.15 (0x00007f1f8fe91000)
    libdapclient.so.6 => /lib/x86_64-linux-gnu/libdapclient.so.6 (0x00007f1f8fe49000)
    libdap.so.25 => /lib/x86_64-linux-gnu/libdap.so.25 (0x00007f1f8fca9000)
    libspatialite.so.7 => /lib/x86_64-linux-gnu/libspatialite.so.7 (0x00007f1f8f71a000)
    libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f1f8f6a7000)
    libcurl-gnutls.so.4 => /lib/x86_64-linux-gnu/libcurl-gnutls.so.4 (0x00007f1f8f618000)
    libfyba.so.0 => /lib/x86_64-linux-gnu/libfyba.so.0 (0x00007f1f8f5c0000)
    libxml2.so.2 => /lib/x86_64-linux-gnu/libxml2.so.2 (0x00007f1f8f406000)
    libmysqlclient.so.21 => /lib/x86_64-linux-gnu/libmysqlclient.so.21 (0x00007f1f8ed0f000)
    libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f1f8ea39000)
    libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007f1f8e8fc000)
    libblas.so.3 => /lib/x86_64-linux-gnu/libblas.so.3 (0x00007f1f8e88f000)
    liblapack.so.3 => /lib/x86_64-linux-gnu/liblapack.so.3 (0x00007f1f8e1eb000)
    libarpack.so.2 => /lib/x86_64-linux-gnu/libarpack.so.2 (0x00007f1f8e1a1000)
    libsuperlu.so.5 => /lib/x86_64-linux-gnu/libsuperlu.so.5 (0x00007f1f8e131000)
    libfreetype.so.6 => /lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f1f8e072000)
    libfontconfig.so.1 => /lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f1f8e02b000)
    liblcms2.so.2 => /lib/x86_64-linux-gnu/liblcms2.so.2 (0x00007f1f8dfd0000)
    libnss3.so => /lib/x86_64-linux-gnu/libnss3.so (0x00007f1f8de81000)
    libsmime3.so => /lib/x86_64-linux-gnu/libsmime3.so (0x00007f1f8de4f000)
    libnspr4.so => /lib/x86_64-linux-gnu/libnspr4.so (0x00007f1f8de0f000)
    libgeos-3.8.0.so => /lib/x86_64-linux-gnu/libgeos-3.8.0.so (0x00007f1f8dc46000)
    libltdl.so.7 => /lib/x86_64-linux-gnu/libltdl.so.7 (0x00007f1f8dc3b000)
    libminizip.so.1 => /lib/x86_64-linux-gnu/libminizip.so.1 (0x00007f1f8da30000)
    liburiparser.so.1 => /lib/x86_64-linux-gnu/liburiparser.so.1 (0x00007f1f8da0f000)
    libicuuc.so.66 => /lib/x86_64-linux-gnu/libicuuc.so.66 (0x00007f1f8d829000)
    libhdf5_serial_hl.so.100 => /lib/x86_64-linux-gnu/libhdf5_serial_hl.so.100 (0x00007f1f8d802000)
    libsz.so.2 => /lib/x86_64-linux-gnu/libsz.so.2 (0x00007f1f8d7fd000)
    libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f1f8d754000)
    liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f1f8d729000)
    libjbig.so.0 => /lib/x86_64-linux-gnu/libjbig.so.0 (0x00007f1f8d51b000)
    libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f1f8d508000)
    libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f1f8d475000)
    libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f1f8d428000)
    libldap_r-2.4.so.2 => /lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007f1f8d3d2000)
    libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007f1f8d2a7000)
    libnghttp2.so.14 => /lib/x86_64-linux-gnu/libnghttp2.so.14 (0x00007f1f8d27e000)
    libidn2.so.0 => /lib/x86_64-linux-gnu/libidn2.so.0 (0x00007f1f8d25d000)
    librtmp.so.1 => /lib/x86_64-linux-gnu/librtmp.so.1 (0x00007f1f8d23d000)
    libssh.so.4 => /lib/x86_64-linux-gnu/libssh.so.4 (0x00007f1f8d1cf000)
    libpsl.so.5 => /lib/x86_64-linux-gnu/libpsl.so.5 (0x00007f1f8d1ba000)
    libnettle.so.7 => /lib/x86_64-linux-gnu/libnettle.so.7 (0x00007f1f8d180000)
    libgnutls.so.30 => /lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007f1f8cfaa000)
    liblber-2.4.so.2 => /lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007f1f8cf99000)
    libbrotlidec.so.1 => /lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x00007f1f8cf8b000)
    libfyut.so.0 => /lib/x86_64-linux-gnu/libfyut.so.0 (0x00007f1f8cf7f000)
    libfygm.so.0 => /lib/x86_64-linux-gnu/libfygm.so.0 (0x00007f1f8cf74000)
    libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f1f8cf58000)
    libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f1f8cf2e000)
    libgfortran.so.5 => /lib/x86_64-linux-gnu/libgfortran.so.5 (0x00007f1f8cc66000)
    libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f1f8cc5d000)
    libnssutil3.so => /lib/x86_64-linux-gnu/libnssutil3.so (0x00007f1f8cc28000)
    libplc4.so => /lib/x86_64-linux-gnu/libplc4.so (0x00007f1f8cc21000)
    libplds4.so => /lib/x86_64-linux-gnu/libplds4.so (0x00007f1f8cc1c000)
    libicudata.so.66 => /lib/x86_64-linux-gnu/libicudata.so.66 (0x00007f1f8b15b000)
    libaec.so.0 => /lib/x86_64-linux-gnu/libaec.so.0 (0x00007f1f8b152000)
    libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f1f8b073000)
    libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f1f8b042000)
    libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f1f8b03b000)
    libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f1f8b02c000)
    libsasl2.so.2 => /lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f1f8b00f000)
    libgssapi.so.3 => /lib/x86_64-linux-gnu/libgssapi.so.3 (0x00007f1f8afca000)
    libunistring.so.2 => /lib/x86_64-linux-gnu/libunistring.so.2 (0x00007f1f8ae46000)
    libhogweed.so.5 => /lib/x86_64-linux-gnu/libhogweed.so.5 (0x00007f1f8ae0e000)
    libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f1f8ad8a000)
    libp11-kit.so.0 => /lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f1f8ac54000)
    libtasn1.so.6 => /lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007f1f8ac3e000)
    libbrotlicommon.so.1 => /lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x00007f1f8ac19000)
    libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007f1f8ac13000)
    libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f1f8ac0b000)
    libquadmath.so.0 => /lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007f1f8abc1000)
    libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f1f8abba000)
    libheimntlm.so.0 => /lib/x86_64-linux-gnu/libheimntlm.so.0 (0x00007f1f8abac000)
    libkrb5.so.26 => /lib/x86_64-linux-gnu/libkrb5.so.26 (0x00007f1f8ab19000)
    libasn1.so.8 => /lib/x86_64-linux-gnu/libasn1.so.8 (0x00007f1f8aa72000)
    libhcrypto.so.4 => /lib/x86_64-linux-gnu/libhcrypto.so.4 (0x00007f1f8aa3a000)
    libroken.so.18 => /lib/x86_64-linux-gnu/libroken.so.18 (0x00007f1f8aa21000)
    libffi.so.7 => /lib/x86_64-linux-gnu/libffi.so.7 (0x00007f1f8aa15000)
    libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f1f8a9f9000)
    libwind.so.0 => /lib/x86_64-linux-gnu/libwind.so.0 (0x00007f1f8a9cf000)
    libheimbase.so.1 => /lib/x86_64-linux-gnu/libheimbase.so.1 (0x00007f1f8a9bd000)
    libhx509.so.5 => /lib/x86_64-linux-gnu/libhx509.so.5 (0x00007f1f8a96f000)
    libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f1f8a934000)

Store materials metadata in 3DTILES_metadata

Right now, the base materials are stored in the glTF files using EXT_feature_metadata. We should include the information up top in 3DTILES_metadata, so, just like CDB, the base material information is available at the top level.

Compilation Error

Errors after running:

cmake --build Build --config Release -j 4

In file included from /mnt/c/Users/Documents/cesium/cdb-to-3dtiles/CDBTo3DTiles/src/CDBTile.h:5,
                 from /mnt/c/Users/Documents/cesium/cdb-to-3dtiles/CDBTo3DTiles/src/CDBAttributes.h:3,
                 from /mnt/c/Users/Documents/cesium/cdb-to-3dtiles/CDBTo3DTiles/src/TileFormatIO.h:3,
                 from /mnt/c/Users/Documents/cesium/cdb-to-3dtiles/CDBTo3DTiles/src/TileFormatIO.cpp:1:
/mnt/c/Users/Documents/cesium/cdb-to-3dtiles/CDBTo3DTiles/src/CDBGeoCell.h:30:17: error: ‘optional’ in namespace ‘std’ does not name a template type
   30 |     static std::optional<int> parseLatFromFilename(const std::string &filename);

Multiple errors follow after that first error.
Help Me!

error 1 / error 2

ran
cmake -B Build -S .
installed all the DEP's and got past the errors and warnings but the
cmake --build Build --config Release -j 4
ends in...

gmake[2]: *** [Tests/CMakeFiles/Tests.dir/build.make:262: Tests/Tests] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:2600: Tests/CMakeFiles/Tests.dir/all] Error 2
gmake: *** [Makefile:160: all] Error 2

full output attached

log.txt

Evaluate the decimation CLI flags

Improve CLI flags:

--elevation-decimate-error. What units are these? Meters? CDB data is always meters right? Is it possible to "un-normalize" the option so that the units are meters?

--elevation-threshold-indices not sure if this option should be included. --elevation-decimate-error is a more concrete option to most users.

Add public API for the CDBTo3DTiles library

Add a public API for the CDBTo3DTiles library so that it can be used in other projects. This would include documentation.

Convert imagery to tiles

Cleanup the code that converts imagery to tile

CDBConverter does not recognise Latitude with prefixing 0.

Minor issue, I think..

OGC CDB 1.0 specifications states that the latitude directory starts with N or S, followed by 2 digits. So a latitude of 1 degree N is N01. CDBConverter ignores such a directory. Renaming it to N1 works, but contravenes the CDB specs.

Set geometric error to be 0 for leaf tile

Chose which layers are included in the 3D Tiles output

This CLI option would allow a user to choose which layers in the CDB they'd like to include in the 3D Tiles output.

There are a couple use cases for this:

If two elevation datasets are present, chose just one of them (e.g primary elevantion and bathymetry)
Export vector layers separately from terrain/imagery/building layers
let client select the component selector for each layer to combine

Provide utility to let client combine multiple converted tilesets together

Currently each dataset is converted into a separate tileset. We should provide a utility to let client combine them together into a single global tileset

GT models converting Segmention fault(core dumped)

Hello,
I'm running the converter on a virtual machine using Ubunto on VirtualBox ,
every time the converter starts to convert the GTModel layer it crash with the error Segmentation fault (core dumped).
did someone had this issue and solved this?
Thanks .

glTF validation errors in Yemen dataset

Assets with errors:
	/home/slilley/Desktop/CDB_yemen_new_all/Tiles/N12/E045/GSModels/1_1/N12E045_D300_S001_T001_L8_U198_R11.gltf
	/home/slilley/Desktop/CDB_yemen_new_all/Tiles/N12/E045/GSModels/1_1/N12E045_D300_S001_T001_LC3_U0_R0.gltf
	/home/slilley/Desktop/CDB_yemen_new_all/Tiles/N12/E045/GSModels/1_1/N12E045_D300_S001_T001_LC5_U0_R0.gltf
	/home/slilley/Desktop/CDB_yemen_new_all/Tiles/N12/E045/GSModels/1_1/N12E045_D300_S001_T001_L7_U99_R6.gltf
	/home/slilley/Desktop/CDB_yemen_new_all/Tiles/N12/E045/GSModels/1_1/N12E045_D300_S001_T001_LC4_U0_R0.gltf
	/home/slilley/Desktop/CDB_yemen_new_all/Tiles/N12/E045/GSModels/1_1/N12E045_D300_S001_T001_L5_U26_R1.gltf
	/home/slilley/Desktop/CDB_yemen_new_all/Tiles/N12/E045/GSModels/1_1/N12E045_D300_S001_T001_L6_U53_R2.gltf
	/home/slilley/Desktop/CDB_yemen_new_all/Tiles/N12/E045/GSModels/1_1/N12E045_D300_S001_T001_L5_U26_R0.gltf
	/home/slilley/Desktop/CDB_yemen_new_all/Tiles/N12/E045/GSModels/1_1/N12E045_D300_S001_T001_L8_U199_R12.gltf
	/home/slilley/Desktop/CDB_yemen_new_all/Tiles/N12/E045/GSModels/1_1/N12E045_D300_S001_T001_L8_U200_R12.gltf
	/home/slilley/Desktop/CDB_yemen_new_all/Tiles/N12/E045/GSModels/1_1/N12E045_D300_S001_T001_L8_U199_R11.gltf
	/home/slilley/Desktop/CDB_yemen_new_all/Tiles/N12/E045/GSModels/1_1/N12E045_D300_S001_T001_L6_U50_R2.gltf
	/home/slilley/Desktop/CDB_yemen_new_all/Tiles/N12/E045/GSModels/1_1/N12E045_D300_S001_T001_L8_U199_R10.gltf
	/home/slilley/Desktop/CDB_yemen_new_all/Tiles/N12/E045/GSModels/1_1/N12E045_D300_S001_T001_L6_U50_R3.gltf
	/home/slilley/Desktop/CDB_yemen_new_all/Tiles/N12/E045/GSModels/1_1/N12E045_D300_S001_T001_LC2_U0_R0.gltf
	/home/slilley/Desktop/CDB_yemen_new_all/Tiles/N12/E045/GSModels/1_1/N12E045_D300_S001_T001_L6_U52_R2.gltf
	/home/slilley/Desktop/CDB_yemen_new_all/Tiles/N12/E045/GSModels/1_1/N12E045_D300_S001_T001_L7_U100_R5.gltf
	/home/slilley/Desktop/CDB_yemen_new_all/Tiles/N12/E045/GSModels/1_1/N12E045_D300_S001_T001_L5_U25_R1.gltf
	/home/slilley/Desktop/CDB_yemen_new_all/Tiles/N12/E045/GSModels/1_1/N12E045_D300_S001_T001_L6_U49_R2.gltf
	/home/slilley/Desktop/CDB_yemen_new_all/Tiles/N12/E045/GSModels/1_1/N12E045_D300_S001_T001_L7_U99_R5.gltf
	/home/slilley/Desktop/CDB_yemen_new_all/Tiles/N12/E045/GSModels/1_1/N12E045_D300_S001_T001_L6_U49_R3.gltf
	/home/slilley/Desktop/CDB_yemen_new_all/Tiles/N12/E045/GSModels/1_1/N12E045_D300_S001_T001_L4_U13_R0.gltf
	/home/slilley/Desktop/CDB_yemen_new_all/Tiles/N12/E045/GSModels/1_1/N12E045_D300_S001_T001_LC1_U0_R0.gltf
	/home/slilley/Desktop/CDB_yemen_new_all/Tiles/N12/E045/GSModels/1_1/N12E045_D300_S001_T001_L5_U24_R1.gltf
	/home/slilley/Desktop/CDB_yemen_new_all/Tiles/N12/E045/GSModels/1_1/N12E045_D300_S001_T001_L4_U12_R0.gltf
	/home/slilley/Desktop/CDB_yemen_new_all/Tiles/N12/E045/GSModels/1_1/N12E045_D300_S001_T001_L3_U6_R0.gltf
	/home/slilley/Desktop/CDB_yemen_new_all/Tiles/N12/E045/GSModels/1_1/N12E045_D300_S001_T001_L0_U0_R0.gltf
	/home/slilley/Desktop/CDB_yemen_new_all/Tiles/N12/E045/GSModels/1_1/N12E045_D300_S001_T001_L2_U3_R0.gltf
	/home/slilley/Desktop/CDB_yemen_new_all/Tiles/N12/E045/GSModels/1_1/N12E045_D300_S001_T001_L1_U1_R0.gltf

The most common errors are related to RWID or APID pointing to empty buffer views (presumably because these features don't have this metadata). An easy fix would be to exclude these from the property table, but then these properties would need to be marked optional.

            {
                "code": "VALUE_NOT_IN_RANGE",
                "message": "Value 0 is out of range.",
                "severity": 0,
                "pointer": "/bufferViews/722/byteLength"
            },
            {
                "code": "BUFFER_VIEW_TOO_LONG",
                "message": "BufferView does not fit buffer (0) byteLength (2072760).",
                "severity": 0,
                "pointer": "/bufferViews/722/byteOffset"
            },

N12E045_D300_S001_T001_L4_U13_R0.gltf has NaN normals:

            {
                "code": "ACCESSOR_INVALID_FLOAT",
                "message": "Accessor element at index 0 is NaN.",
                "severity": 0,
                "pointer": "/accessors/118"
            },
            {
                "code": "ACCESSOR_INVALID_FLOAT",
                "message": "Accessor element at index 1 is NaN.",
                "severity": 0,
                "pointer": "/accessors/118"
            },

N12E045_D300_S001_T001_L6_U52_R1.glb has no meshes

{
    "asset":
    {
        "version": "2.0"
    },
    "bufferViews":
    [
        {
            "buffer": 0,
            "byteLength": 0
        },
        {
            "buffer": 0,
            "byteLength": 0
        },
        {
            "buffer": 0,
            "byteLength": 0
        },
        {
            "buffer": 0,
            "byteLength": 0
        },
        {
            "buffer": 0,
            "byteLength": 0
        },
        {
            "buffer": 0,
            "byteLength": 0
        },
        {
            "buffer": 0,
            "byteLength": 0
        },
        {
            "buffer": 0,
            "byteLength": 0
        },
        {
            "buffer": 0,
            "byteLength": 0
        },
        {
            "buffer": 0,
            "byteLength": 0
        },
        {
            "buffer": 0,
            "byteLength": 0
        },
        {
            "buffer": 0,
            "byteLength": 0
        },
        {
            "buffer": 0,
            "byteLength": 0
        },
        {
            "buffer": 0,
            "byteLength": 0
        },
        {
            "buffer": 0,
            "byteLength": 0
        },
        {
            "buffer": 0,
            "byteLength": 0
        },
        {
            "buffer": 0,
            "byteLength": 0
        },
        {
            "buffer": 0,
            "byteLength": 0
        },
        {
            "buffer": 0,
            "byteLength": 4
        },
        {
            "buffer": 0,
            "byteLength": 0,
            "byteOffset": 4
        },
        {
            "buffer": 0,
            "byteLength": 4,
            "byteOffset": 4
        },
        {
            "buffer": 0,
            "byteLength": 0,
            "byteOffset": 8
        },
        {
            "buffer": 0,
            "byteLength": 4,
            "byteOffset": 8
        },
        {
            "buffer": 0,
            "byteLength": 0,
            "byteOffset": 12
        },
        {
            "buffer": 0,
            "byteLength": 4,
            "byteOffset": 12
        },
        {
            "buffer": 0,
            "byteLength": 0,
            "byteOffset": 16
        },
        {
            "buffer": 0,
            "byteLength": 4,
            "byteOffset": 16
        },
        {
            "buffer": 0,
            "byteLength": 0,
            "byteOffset": 20
        }
    ],
    "buffers":
    [
        {
            "byteLength": 20
        }
    ],
    "extensions":
    {
        "EXT_feature_metadata":
        {
            "featureTables":
            {
                "CDBFeatureTable":
                {
                    "class": "CDBClass",
                    "count": 0,
                    "elementCount": 0,
                    "properties":
                    {
                        "AHGT":
                        {
                            "bufferView": 19,
                            "stringOffsetBufferView": 18
                        },
                        "AO1":
                        {
                            "bufferView": 0
                        },
                        "APID":
                        {
                            "bufferView": 21,
                            "stringOffsetBufferView": 20
                        },
                        "BBH":
                        {
                            "bufferView": 1
                        },
                        "BBL":
                        {
                            "bufferView": 2
                        },
                        "BBW":
                        {
                            "bufferView": 3
                        },
                        "BSR":
                        {
                            "bufferView": 4
                        },
                        "CMIX":
                        {
                            "bufferView": 6
                        },
                        "FACC":
                        {
                            "bufferView": 23,
                            "stringOffsetBufferView": 22
                        },
                        "FSC":
                        {
                            "bufferView": 7
                        },
                        "HGT":
                        {
                            "bufferView": 5
                        },
                        "MLOD":
                        {
                            "bufferView": 8
                        },
                        "MODL":
                        {
                            "bufferView": 25,
                            "stringOffsetBufferView": 24
                        },
                        "NIS":
                        {
                            "bufferView": 9
                        },
                        "NIX":
                        {
                            "bufferView": 10
                        },
                        "NNL":
                        {
                            "bufferView": 11
                        },
                        "NTC":
                        {
                            "bufferView": 12
                        },
                        "NTX":
                        {
                            "bufferView": 13
                        },
                        "NVT":
                        {
                            "bufferView": 14
                        },
                        "RTAI":
                        {
                            "bufferView": 15
                        },
                        "RWID":
                        {
                            "bufferView": 27,
                            "stringOffsetBufferView": 26
                        },
                        "SSC":
                        {
                            "bufferView": 16
                        },
                        "SSR":
                        {
                            "bufferView": 17
                        }
                    }
                }
            },
            "schema":
            {
                "classes":
                {
                    "CDBClass":
                    {
                        "properties":
                        {
                            "AHGT":
                            {
                                "description": "Indicates how to interpret the Z component of a vertex. If AHGT is true, the feature is positioned to the value specified by the Z component (Absolute Terrain Altitude), irrelevant of the terrain elevation dataset. If AHGT is false or not present, the feature is positioned to the value specified by the underlying terrain offset by the Z component value. Refer to section 5.6.1.1, ShapeFile Type Usage and Conventions for more details. AHGT can be present only in datasets using PointZ, PolylineZ, PolygonZ and MultiPointZ Shape types. AHGT should not be present for all other Shape types or must be ignored otherwise. Refer to Appendix A – \"How to Interpret the AHGT, HGT, BSR, BBH, and Z Attributes\" for additional usage guidelines. NOTE: It is recommended that the AHGT flag be set to false because it facilitates the creation of CDB datasets that are independent of each others. When the Z coordinate (altitude) of a feature is relative to the ground, the terrain elevation dataset can be updated without the need to recompute the altitude of the feature. CAUTION: When the AHGT flag is set to true, the feature will be at a fixed WGS-84 elevation independently of the terrain LOD selected by the client-device. As a result, there is no guarantee that the feature (and its modeled representation) will remain above the terrain skin across all terrain LODs. RECOMMENDATION: Limit the use of AHGT=TRUE to data whose source is inherently absolute. Such source data include geodetic marks or survey marks that provide a known position in terms of latitude, longitude, and altitude. Good examples of such markers are boundary markers between countries.",
                                "name": "Absolute Height Flag",
                                "type": "STRING"
                            },
                            "AO1":
                            {
                                "description": "The angular distance measured from true north (0 deg) clockwise to the major (Y) axis of the feature. If the feature is square, the axis 0 through 89.999 deg shall be recorded. If the feature is circular, 360.000 deg shall be recorded. Recommended Usage. CDB readers should default to a value of 0.000 if AO1 is missing. Applicable to Point, Light Point, Moving Model Location and Figure Point features. When used in conjunction with the PowerLine dataset, AO1 corresponds to the orientation of the Y-axis of the modeled pylon. The modeled pylon should be oriented (in its local Cartesian space) so that the wires nominally attach along the Y-axis.",
                                "name": "Angle of Orientation",
                                "type": "FLOAT64"
                            },
                            "APID":
                            {
                                "description": "A unique alphanumeric identifier that points to a record in the NavData Airport or Heliport dataset (i.e., a link to the Airport or the Heliport description in the NavData dataset). This ID is the value of the field Ident of the Airport or Heliport dataset. Note that all of the lights located in list-organized datasets that are associated with the operation of an airport (including runway lights and lighting systems) are required to reference an airport or heliport in the NavData dataset. All man-made features associated with an airport or heliport must be assigned an APID attribute; the APID attribute is not required for features unrelated to airports or heliports. Usage Note: Recommended for all Airport Light Points and airport-related i2DModels (such as runway/taxiway/apron surfaces, and markings). Failure to appropriately tag airport culture with APID attribute will result in reduced control of airport-related culture by simulator. Optional for Location Points, Environmental Light Points, and Moving Model Location features that fall within the confines of an airport and for which control of the feature is desirable.",
                                "name": "AirPort ID",
                                "type": "STRING"
                            },
                            "BBH":
                            {
                                "description": "The Height/Width/Length of the Bounding Box of the 3D model associated with a point feature. It is the dimension of the box centered at the model origin and that bounds the portion of the model above its XY plane, including the envelopes of all articulated parts. BBH refers to height of the box above the XY plane of the model, BBW refers to the width of the box along the X-axis, and BBL refers to the length of the box along the Y-axis. Note that for 3D models used as cultural features, the XY plane of the model corresponds to its ground reference plane. The value of BBH, BBW and BBL should be accounted for by client-devices (in combination with other information) to determine the appropriate distance at which the model should be paged-in, rendered or processed. BBH, BBW and BBL are usually generated through database authoring tool automation. Optional on features for which a MODL has been assigned. When missing, CDB readers should default BBH to the value of BSR, and BBW and BBL to twice the value of BSR. The dimension of the bounding box is intrinsic to the model and identical for all LOD representations.",
                                "name": "Bounding Box Height",
                                "type": "FLOAT64"
                            },
                            "BBL":
                            {
                                "description": "The length of a feature.",
                                "name": "Bounding Box Length",
                                "type": "FLOAT64"
                            },
                            "BBW":
                            {
                                "description": "The width of a feature.",
                                "name": "Bounding Box Width",
                                "type": "FLOAT64"
                            },
                            "BSR":
                            {
                                "description": "The radius of a feature. In the case where a feature references an associated 3D model, it is the radius of the hemisphere centered at the model origin and that bounds the portion of the model above its XY plane, including the envelopes of all articulated parts. Note that for 3D models used as cultural features, the XY plane of the model corresponds to its ground reference plane. The value of BSR should be accounted for by client-devices (in combination with other information) to determine the appropriate distance at which the model should be paged-in, rendered or processed. When the feature does not reference a 3D model, BSR is the radius of the abstract point representing the feature (e.g., a city). ",
                                "name": "Bounding Sphere Radius",
                                "type": "FLOAT64"
                            },
                            "CMIX":
                            {
                                "description": "Index into the Composite Material Table is used to determine the Base Materials composition of the associated feature.",
                                "name": "Composite Material Index",
                                "type": "INT32"
                            },
                            "FACC":
                            {
                                "description": "",
                                "name": "",
                                "type": "STRING"
                            },
                            "FSC":
                            {
                                "description": "This code, in conjunction with the FACC is used to distinguish and categorize features within a dataset.",
                                "name": "Feature Classification Code",
                                "type": "INT32"
                            },
                            "HGT":
                            {
                                "description": "Distance measured from the lowest point of the base at ground (non-floating objects) or water level (floating objects downhill side/downstream side) to the tallest point of the feature above the surface. Recorded values are positive numbers. In the case of roads and railroads, HGT corresponds to the elevation of the road/railroad wrt terrain in its immediate vicinity.",
                                "name": "Height above surface level",
                                "type": "FLOAT64"
                            },
                            "MLOD":
                            {
                                "description": "The level of detail of the 3D model associated with the point feature. When used in conjunction with MODL, the MLOD attribute indicates the LOD where the corresponding MODL is found. In this case, the value of MLOD can never be larger than the LOD of the Vector Tile-LOD that contains it. When used in the context of Airport and Environmental Light Point features, the value of MLOD, if present, indicates that this light point also exist in a 3D model found at the specified LOD. In such case, the value of MLOD is not constrained and can indicate any LOD.",
                                "name": "Model Level Of Detail",
                                "type": "INT32"
                            },
                            "MODL":
                            {
                                "description": "\tA string reference, the model name, which stands for the modeled geometry of a feature; in the case of buildings, this includes both its external shell and modeled interior. Usage Note: Needed for Point features, Road Figure Point features, Railroad Figure Point features, Pipeline Figure Point features and Hydrography Figure Point features that are modeled as OpenFlight or as RCS (Shape). MODL can also be used with Road Lineal features, Railroad Lineal features, Pipeline Lineal features and Hydrography Lineal and Areal features. Note that it is not permitted to specify a value for MODL simultaneously with a value for MMDC.",
                                "name": "Model Name",
                                "type": "STRING"
                            },
                            "NIS":
                            {
                                "description": "Number of instances found in the 3D model associated with the cultural point feature.",
                                "name": "Number of Instances",
                                "type": "INT32"
                            },
                            "NIX":
                            {
                                "description": "Number of indices found in the 3D model associated with the cultural point feature.",
                                "name": "Number of Indices",
                                "type": "INT32"
                            },
                            "NNL":
                            {
                                "description": "Number of normal vectors found in the 3D model associated with the cultural point feature.",
                                "name": "Number of Normals",
                                "type": "INT32"
                            },
                            "NTC":
                            {
                                "description": "Number of texture coordinates found in the 3D model associated with the cultural point feature.",
                                "name": "Number of Texture Coordinates",
                                "type": "INT32"
                            },
                            "NTX":
                            {
                                "description": "Number of texels found in the 3D model associated with the cultural point feature.",
                                "name": "Number of Texels",
                                "type": "INT32"
                            },
                            "NVT":
                            {
                                "description": "Number of vertices of the 3D model associated with a point feature.",
                                "name": "Number of Vertices",
                                "type": "INT32"
                            },
                            "RTAI":
                            {
                                "description": "Provides the Relative TActical Importance of moving models or cultural features relative to other features for the purpose of client-device scene/load management. A value of 100% corresponds to the highest importance; a value of 0% corresponds to the lowest importance. When confronted with otherwise identical objects that differ only wrt to their RelativeTActical Importance, client-devices should always discard features with lower importance before those of higher importance in the course of performing their scene / load management function. As a result, a value of zero gives complete freedom to client-devices to discard the feature as soon as the load of the client-device is exceeded. The effectiveness of scene / load management functions can be severely hampered if large quantities of features are assigned the same Relative TActical Importance by the modeler. In effect, if all models are assigned the same value, the client-devices have no means to distinguish tactically important objects from each other. Assigning a value of 1% to all objects is equivalent to assigning them all a value of 99%. Ideally, the assignment of tactical importance to features should be in accordance to a histogram similar to the one shown here. The shape of the curve is not critical, however the proportion of models tagged with a high importance compared to those with low importance is critical in achieving effective scene/load management schemes. It is illustrated here to show that few models should have an importance of 100 with progressively more models with lower importance. The assignment of the RTAI to each feature lends itself to database tools automation. For instance, RTAI could be based on a look-up function which factors the feature’s type (FACC or MMDC). The value of Relative TActical Importance should be accounted for by client-devices (in combination with other information) to determine the appropriate distance at which the model should be rendered or processed. Relative TActical Importance is mandatory. It has no default value.",
                                "name": "Relative Tactical Importance",
                                "type": "INT32"
                            },
                            "RWID":
                            {
                                "description": "An alphanumeric identifier that, combined with the APID, points to a unique record in the NavData Runway or Helipad dataset (i.e., a link to the Runway or Helipad description in the NavData dataset). This ID is the value of the field Ident of the Runway or Helipad dataset. Note that all of the lights and other features located in list-organized datasets that are associated with the operation of a runway or helipad are required to reference a runway or helipad in the NavData dataset; the RWID attribute is not required for features unrelated to a runway or helipad. Usage Note: Recommended for all Airport Light Points features. Failure to appropriately tag airport culture with RWID attribute will result in reduced control of runway-related (or helipad) culture by simulator. Optional for Point/Lineal/Areal features, Location Points Features, Environmental Light Point features, and Moving Model Location features that are associated with a runway and for which control of the feature is desirable.",
                                "name": "Runway ID",
                                "type": "STRING"
                            },
                            "SSC":
                            {
                                "description": "Describes the Geometric form, appearance, or configuration of the feature.",
                                "name": "Structure Shape Category",
                                "type": "INT32"
                            },
                            "SSR":
                            {
                                "description": "Describes the roof shape.",
                                "name": "Structure Shape of Roof",
                                "type": "INT32"
                            }
                        }
                    }
                }
            }
        }
    },
    "extensionsUsed":
    [
        "EXT_feature_metadata"
    ],
    "nodes":
    [
        {
            "matrix":
            [
                1.0,
                0.0,
                0.0,
                0.0,
                0.0,
                0.0,
                -1.0,
                0.0,
                0.0,
                1.0,
                0.0,
                0.0,
                0.0,
                0.0,
                0.0,
                1.0
            ]
        }
    ],
    "scenes":
    [
        {
            "nodes":
            [
                0
            ]
        }
    ]
}

Out of core

All tiles are stored in memory in a tileset object before being written to JSON. This is not feasible for geocells that go down to level 23 (potentially terrabytes).

Instead, making the b3dms and gltfs should be separate from writing the tileset jsons. This can be multithreaded.

After the content files are written, availability buffers for subtrees can be written to disk. A process would parse the b3dms and know which buffer to write to. All the buffers aren't kept in memory but rather opened and written to one at a time in this way.

Use conan for third party libraries

We're starting to move over to Conan for C++ third party library management to simplify the build system. cesium-native has started the process: CesiumGS/cesium-native#261

This may also help us get Windows builds working CC #17

CDB to 3D Tiles should stable OpenSceneGraph version

Currently the converter are using the OSG in their master branch. However, we should test it with stable branch to see if there are any regression error. @mramato tried to build the converter but encountered the error:

In file included from /var/app/CDBTo3DTiles/src/CDB.h:5,
                 from /var/app/CDBTo3DTiles/src/CDBTileset.cpp:2:
/var/app/CDBTo3DTiles/src/CDBModels.h:124:10: error: ‘void CDBTo3DTiles::CDBModel3DResult::apply(osg::Geometry&)’ marked ‘override’, but does not override
     void apply(osg::Geometry &geometry) override;
          ^~~~~

Multithreading

Process CDB tiles in parallel. Not too much synchronization should be required.

Convert Vector layer to tile

Currently, line and polygon for CDB are stored in the ESRI shapefile. We should implement a generic conversion for those type and automatically convert any CDB vector dataset that has those geometry to tile

[root@localhost cdb-to-3dtiles]# cmake --build Build --config Release -j 4

../CDBTo3DTiles/libCDBTo3DTiles.a(CDBTo3DTiles.cpp.o):CDBTo3DTiles.cpp:(.text.ZNSt6vectorINSt10filesystem7__cxx114pathESaIS2_EE17_M_realloc_insertIJRS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT[ZNSt6vectorINSt10filesystem7__cxx114pathESaIS2_EE17_M_realloc_insertIJRS2_EEEvN9__gnu_cxx17__normal_iteratorIPS2_S4_EEDpOT]+0x254): more undefined references to std::filesystem::__cxx11::path::_M_split_cmpts()' follow //usr/local/lib/libproj.so.19: undefined reference to std::__cxx11::basic_ostringstream<char, std::char_traits, std::allocator >::basic_ostringstream()@GLIBCXX_3.4.26'
collect2: error: ld returned 1 exit status
gmake[2]: *** [Tests/CMakeFiles/Tests.dir/build.make:262: Tests/Tests] Error 1
gmake[1]: *** [CMakeFiles/Makefile2:2600: Tests/CMakeFiles/Tests.dir/all] Error 2
gmake: *** [Makefile:160: all] Error 2

Re-evaluate the build instructions and how to install third party libraries

Using vcpkg to install third party library is convenient for prototyping. But in my best knowledge, it doesn't support versioning, which can break the project in the future when the library introduces breaking changes. We need to find a proper way to install them.

Cover elevation crack between adjacent tiles

Currently, the implementation only duplicates the data on the edge of the elevation to cover the crack, but it is not good. There are two ways to solve it currently:

Add skirts around the tile
Query the adjacent tile and do the interpolation

3D Tiles Next improvements

Brainstorming some improvements that 3D Tiles Next might bring to CDB to 3D Tiles

Implicit tiling within each geocell
Separate metadata into an external file with EXT_feature_metadata
Per-texel metadata to enable CDB Raster Materials
Optional properties with default values
Layers - all CDB layers can go in the same tileset with the same tiling scheme. Conflicting layers like primary elevation and bathymetry could be toggled by the client
Better solution for vector tiles
Raster layers (maybe)
A glTF terrain extension could include the edge indices of the geometry and let a client render skirts. CC #15
Need to export glTF with instancing extension EXT_mesh_gpu_instancing

Tinygltf add unsupported wrapR in the gltf sampler

Tinygltf currently adds wrapR to the json. Do we have any way to remove it?

Vector data not clamped to elevation

If you combine elevation and vector datasets (like road network), there is some z fighting between the vector and elevation, and sometimes elevation completely covers the vectors. Solution would be to clamp vector data to elevation if there is elevation data.

Calculate GeometricError for the converted tile

The converter should error out if you use a component selector that doesn't exist

E.g. --combine Elevation_1_5 should print an error message

The --combine option only checks the dataset to be valid. The component selector check is to see if it is a number and ignore if it doesn't exist. We should error out upfront to let client know if the CS doesn't exist
Update the dataset table in the README to indicate which dataset and component selectors are supported

The converter crashes on exit when using static linking OpenSceneGraph

The converter works correctly with GSModel and produces the correct tileset.json. However, it will seg fault when exiting the program. This only happens in the release build. The command line to produce the error:

./CDBConverter -i CDB_san_diego_Lite -o San-Diego

CDB_san_diego_Lite example only contains the GSFeature and GSModelGeometry in the Tiles directory. I've removed all other datasets for easier to debug

Support window build

Currently the converter is failed to build on window, especially for OpenSceneGraph