Check that DTS Engine is installed and reachable.

Call this first. Reports the Engine version, which executables are present, and the bundled GDAL. Every other tool fails if this one does.

List the publish pipelines, their flags, and whether each is verified.

verified: true means the pipeline has been confirmed by a successful real run. Unverified pipelines have correct flag names transcribed from the decompiled GUI shell, but their required input combinations are unconfirmed — expect to iterate on error codes.

Explain a DTS Engine exit code using the table Engine ships.

Bands: io (0-19), lod (100-119), terrain (200-249), resource (300-309), crs (400-409), vtpk (500-509), dem_opt (600+).

ok reports whether the lookup succeeded. Whether the code means success is indicates_success — do not conflate the two.

Check a flag set against a pipeline spec without running anything.

Cheap pre-flight: catches missing required flags and typos locally, so a malformed publish costs no Engine time.

Run a DTS Engine publish pipeline and report artifacts.

flags takes any of Engine's 93 flags without the leading dash, e.g. {"roadShp": "roads.shp", "domPath": "dom.tif", "demPath": "dem.tif"}.

The verified workflow is pipeline="road", which drapes vector features onto terrain. It needs a PROJECTED shapefile (geographic coordinates fail with 203/209/215) plus a DOM raster; domPath is mandatory despite looking optional.

Success yields a .3dt tile plus DataInfor.txt. On failure, read error.band and log — the UDP log usually carries a more specific message than the exit code. Use dts_explain_error for any code.

Set strict=False to pass experimental flags the spec does not list.

For OSGB use dts_publish_osgb instead: that format needs two sequential processes and this tool would only run the first.

Publish oblique-photogrammetry OSGB data, running both required stages.

OSGB publishing is two sequential Engine processes: tiling, then the LOD pyramid. Stopping after the first leaves an incomplete dataset, so both are run and reported here. ok is true only if both stages succeed.

Write an .aconf job file, the input for Engine's -jsonPath mode.

data_type is one of Terrain, Osgb, MAX, BIM, LAS, Material, Vector, Sea, Skeletal, DTOModeData. Field names are the C# property names Engine expects (e.g. RoadShpPath, OutputPath) — call dts_job_types to list the known ones.

Note: job-file mode is transcribed from the decompiled shell but has not been verified end-to-end. Prefer dts_publish for production work.

List .aconf job data types and the fields transcribed for each.

A null fields means that type's schema has not been transcribed from the decompiled shell, so its fields are not validated rather than guessed at.