Skip to main content

track2corridor-geo

CI PyPI Python License

Build an auditable centerline and corridor from ground mobile laser-scanning (MLS) trajectory points.

Here, a noisy track means ordered trajectory coordinates with positional scatter, short side deviations, or gaps around the route actually travelled. It does not mean the complete laser point cloud. track2corridor converts those ordered trajectory points into a buffered footprint, raster skeleton, NetworkX graph, centerline, and fixed-width corridor. It exposes every intermediate geometry and a diagnostics report instead of hiding algorithmic warnings behind a single polygon.

Track points become a footprint, centerline, and corridor

Quick start

python -m pip install track2corridor-geo
track2corridor build track.laz \
  --footprint-width 20 \
  --corridor-width 8 \
  --output corridor.gpkg

CSV input must contain x,y columns and needs an explicit projected CRS:

track2corridor build track.csv --crs EPSG:32637 --output corridor.gpkg

Reproducible example

Generate and process three deterministic trajectory scenarios plus equivalent CSV, LAZ, and GeoPackage inputs:

python examples/run_examples.py
scenario purpose expected diagnostic
mls-s-track positional scatter around a smooth MLS trajectory one connected graph component
disconnected a gap wider than the point footprint two graph components and centerline parts
short-spur a short side deviation from the main route branch-pruning behavior is recorded
format-track identical ordered points in CSV, LAZ, and GeoPackage all readers return the same coordinates

Generated inputs, outputs, and diagnostics are placed under examples/generated/. To run the standard case through the CLI:

track2corridor build examples/generated/mls-s-track.csv \
  --crs EPSG:32637 \
  --time-field sequence \
  --footprint-width 14 \
  --corridor-width 6 \
  --cell-size 1 \
  --min-branch-length 4 \
  --output examples/generated/mls-s-track-cli.gpkg \
  --diagnostics examples/generated/mls-s-track-cli.json

The GeoPackage contains three inspectable layers:

layer meaning
footprint union of point buffers used as raster input
centerline graph edges converted back to line geometry
corridor fixed-width buffer around the derived centerline

The JSON report records input point count, raster dimensions and cell count, skeleton pixels, graph nodes and edges, connected components, pruned nodes, extended endpoints, and centerline part count.

Parameters

option default effect
--footprint-width 20 m width of the buffered point footprint
--corridor-width 8 m final corridor width
--cell-size footprint / 16 raster resolution; smaller is slower
--min-branch-length 10 m removes shorter leaf branches
--extend-endpoints 0 m extends graph leaves before buffering
--max-cells 10,000,000 rejects unexpectedly large rasters

Python API

from track2corridor import CorridorOptions, CorridorResult, build_corridor

result: CorridorResult = build_corridor(
    points,
    "EPSG:32637",
    CorridorOptions(footprint_width=14, corridor_width=6, cell_size=1),
)
print(result.diagnostics.to_dict())

Input behavior

  • LAS/LAZ uses gps_time for stable ordering when that dimension exists.
  • CSV uses source order unless --time-field is supplied.
  • Other vector formats must contain only Point geometries and retain their CRS.
  • An explicit --crs must match embedded CRS metadata; reprojection is never performed automatically.

Limits

  • Coordinates must use a projected CRS with horizontal units in metres.
  • The method derives a skeleton from point buffers; it is not a map-matching or trajectory-inference algorithm.
  • Disconnected point clusters produce multiple centerline components.
  • Dense data, a very small cell size, or a very large extent can create expensive rasters; --max-cells provides a hard safety limit.
  • Results should be visually reviewed when the footprint contains loops, wide junctions, or sparse gaps.

Run track2corridor --help for all options. Exit code 0 means success and 2 means invalid input or a processing failure.

The pre-release and launch checks are listed in docs/release-checklist.md.

Development

python -m pip install -e ".[test]"
python -m ruff check .
python -m ruff format --check .
python -m pytest

Copyright 2026 Alena Nikitina. Licensed under the Apache License 2.0.

Metadata

Release files for track2corridor-geo 0.1.1

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for track2corridor-geo 0.1.1
File Size Uploaded
track2corridor_geo-0.1.1.tar.gz 19.8 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for track2corridor-geo 0.1.1
File Interpreter ABI Platform
track2corridor_geo-0.1.1-py3-none-any.whl Python 3 none any Details

Total release size: 33.3 kB

Release files / track2corridor_geo-0.1.1.tar.gz

Download URL track2corridor_geo-0.1.1.tar.gz
Size 19.8 kB
Tags Source
SHA-256 checksum
How to use checksums
5df32bdd70e18b733e0a0596da6f555465b86232aec2b92a6808ecdfa44bda3f
BLAKE2b-256 checksum
How to use checksums
c9a36c0ce66188897d3726d8d3640d278945ceb04e3fe7963c5a343a63f7a41b
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 1, 2026.

Transparency log

Release files / track2corridor_geo-0.1.1-py3-none-any.whl

Download URL track2corridor_geo-0.1.1-py3-none-any.whl
Size 13.5 kB
Tags Python 3
SHA-256 checksum
How to use checksums
fefd481c13d3e03f45fe134d750e41bf7c727359ce81b8bafd09d583bc54ba8b
BLAKE2b-256 checksum
How to use checksums
898b83494369384f7ff709bb82cd14a580e5157bf59c432b2d054d626d6e0afd
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Oct 1, 2026.

Transparency log

Release history Release notifications | RSS feed

This release

0.1.1 This release

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page