LandXML format: civil engineering exchange since 1999 — OSM road export to alignment XML

2026-04-2813 min read

civilaeclandxmlalignmentsurveyingautocad-civil-3d

Export formats: LANDXML

LandXML is an open XML vocabulary for exchanging civil engineering and surveying data, born in 1999 as the AEC industry's response to closed-binary CAD formats. When the LandXML.org consortium gathered Autodesk, Bentley, Trimble, Leica Geosystems, Caice (later Bentley) and dozens of smaller vendors, the goal was simple: give road engineers, surveyors, and utility designers a vendor-neutral format that carries a highway alignment (<Alignment>), a digital terrain model (<Surface>), cadastral parcels (<Parcel>), and survey points (<CgPoint>) between AutoCAD Civil 3D, Bentley OpenRoads, Trimble Business Center, and dozens of other tools without semantic loss. Twenty-five years later, LandXML 1.2 (2008) remains the de facto civil engineering exchange standard — despite no new versions and gradual displacement by IFC 4.3 in infrastructure BIM. On osm2cdr.ru the LandXML exporter pulls road centerlines from PostGIS, simplifies them through ST_SimplifyPreserveTopology, and emits valid XML with <Alignment> horizontal geometry ready for direct import into Civil 3D.

Map generation of Novosibirsk city center

History: 1999 consortium and the 2008 freeze

LandXML's story starts in the late 1990s, when the AEC industry (Architecture, Engineering, Construction) hit a real problem: every vendor stored civil data in its own binary format — Autodesk in Land Desktop, Bentley in InRoads, Trimble in Survey Controller, Leica in SurveyOffice. Passing a road alignment between those systems meant ASCII point coordinate dumps, losing all the semantics: where the tangent is, where the clothoid spiral transition lives, where the circular curve sits, where the vertical profile changes.

In 1999 Nathan Crews of Autodesk launched LandXML.org as an independent consortium with three principal participants: Autodesk, Bentley Systems, and Trimble Navigation. Leica Geosystems, Caice Software (acquired by Bentley in 2003), Carlson Software, Topcon, and Eagle Point joined quickly. The first LandXML 1.0 spec shipped in December 2000. It was a pure XML schema — vendor-neutral, human-readable, extensible.

The next eight years saw active development: LandXML 1.1 (December 2002), LandXML 1.2 (December 2008). Version 1.2 locked in the full civil entity set: <Alignment>, <Profile>, <Surface> (TIN), <Parcel>, <Roadway>, <Survey>, <PipeNetwork>, <Project>, <CoordinateSystem>. After 2008 the consortium effectively stopped publishing new versions — funding dried up, vendors moved to their own extensions. The LandXML.org domain formally existed into the early 2010s, then was handed to Bentley for spec stewardship.

Despite the "frozen" status, LandXML 1.2 remains the de facto standard. Every major 2025 civil tool reads and writes LandXML 1.2: AutoCAD Civil 3D (native), Bentley OpenRoads Designer, Trimble Business Center, Leica Infinity, 12d Model, Carlson Survey, Topcon Magnet Tools. Russian IndorCAD, Robur, Topomatic, CREDO support LandXML too for exchange with foreign contractors.

What's inside the XML file

A LandXML file is plain XML with namespace http://www.landxml.org/schema/LandXML-1.2. The root <LandXML> element carries a mandatory <Project> header with metadata (name, date, author), an <Application> element naming the source program (e.g., AutoCAD Civil 3D 2024), and <Units> with base measurement units (meters or feet, degrees or grads).

Then come the semantic blocks:

<Alignments> — a collection of horizontal alignments. Each <Alignment> has a name, station start, length, and a set of geometric elements: <Line> (tangent), <Curve> (circular curve with radius, length, center), <Spiral> (clothoid transition with totalY, totalX, theta). Every element knows its Point of Intersection — the coordinates where it meets neighbors. For roads this is critical: a correct clothoid description between tangent and circular curve defines safe driving speed.

<Profile> — vertical profile of an alignment. Describes elevation change along the station. Contains <ProfAlign> with PVI (Point of Vertical Intersection) points and <ParaCurve> (parabolic vertical curve) for smooth grade transitions.

<Surfaces> — digital terrain models (DTM/DEM). Each <Surface> stores a TIN as <P> (points with XYZ) and <F> (triangular faces referencing point indices). For large terrain this may be hundreds of thousands of triangles — the text XML grows heavy (tens of megabytes) but remains git-diffable.

<Parcels> — cadastral boundaries. Each <Parcel> is a closed polygon with metadata (state, owner, area, parcel number). Used for cadastral exchange between surveyors and land registry engineers.

<Survey> — survey data. Contains <CgPoints> (Cartesian Geometric Points) with XYZ coordinates and description (PointName, Description, Code), <Observation> blocks with raw total station / GNSS RTK data (angles, distances, GPS vectors). This is the raw fieldwork level — what a surveyor dumps from the controller into the office.

<PipeNetworks> — utility networks (water, sewer, stormwater). Each network is a set of <Struct> (manholes) and <Pipe> (pipes) with diameters, slopes, invert elevations.

Map generation of Berlin city center

LandXML vs IFC vs DWG vs DGN

Four formats intersect in civil engineering space, and it's important to grasp the roles:

LandXML — XML exchange for horizontal infrastructure: road alignments, water pipe profiles, DTMs, survey data, cadastre. Vendor-neutral, semantic, open. Not meant for final project storage — only for transfer between vendors.
IFC — letter-based BIM standard. Since IFC 4.3 (2020) extended to infrastructure: IfcRoad, IfcRail, IfcBridge, IfcRoadPart. Gradually displacing LandXML in new tenders but requires significantly more vendor work for full support.
DWG — native Autodesk binary, used inside Civil 3D for production work. LandXML is "export from DWG to send outside."
DGN — native Bentley binary, analogous to DWG for the Bentley ecosystem. OpenRoads stores projects in DGN, uses LandXML for exchange.

Simple rule: within one vendor — native binary (DWG/DGN). Between different vendors — LandXML (legacy/civil) or IFC 4.3 (new BIM). OSM context for civil is clearly LandXML, because we need road/parcel geometry, not the full Civil 3D toolset.

Who needs LandXML

Road designers are the primary audience. When contractor A designs an alignment in AutoCAD Civil 3D and contractor B reviews it in Bentley OpenRoads, the exchange goes through LandXML. All horizontal curves, vertical profiles, typical cross-sections transfer correctly. Without LandXML you'd be batch-exporting centerline coordinates at 1-meter intervals and reconstructing clothoids on the receiving side.

Surveyors use LandXML to push raw fieldwork from Trimble Business Center / Leica Infinity to the design office. The total station / GNSS receiver controller writes data in its own format (JobXML on Trimble, .gsi/.dbx on Leica), the office software converts to LandXML for designers.

Cadastral engineers — LandXML's <Parcel> block fits the cadastral workflow well: parcel boundary, area, owner ID, parcel number. In Russia it's less common (Rosreestr uses its own XML), but for international projects LandXML works.

Civil BIM — for highway and railway projects LandXML is still "standard handoff" with older tenders and legacy systems. New 2023+ projects often require IFC 4.3, but LandXML is accepted as parallel.

OSM cartographers and civil engineers — our case. When you need to drop OSM streets as context into a Civil 3D project, native DWG import gives lines but not alignments. LandXML lets you import street centerlines as <Alignment> objects, ready for design work over them.

LandXML-reading software

AutoCAD Civil 3D. Paid, ~2545 USD/year (or ~225 USD/month), Windows. Native LandXML support — Toolspace → Survey → Import LandXML for survey data, Insert → LandXML for alignments/surfaces. The reference in the Autodesk ecosystem. autodesk.com/products/civil-3d

Bentley OpenRoads Designer. Paid (subscription ~3 200 USD/year), Windows. Native LandXML import/export via File → Import → LandXML. MicroStation as the base engine. Used by major design firms (Mott MacDonald, AECOM, Jacobs). bentley.com/software/openroads-designer

Trimble Business Center (TBC). Paid (~5 000 USD one-time or modular), Windows. Office software for processing Trimble controller data. Imports LandXML alignments as design surfaces for stake-out.

Leica Infinity. Paid (~2 500 USD/year), Windows. Leica Geosystems' TBC analog. Imports/exports LandXML for survey-to-design exchange.

12d Model. Paid (~6 000-10 000 USD), Windows. Australian civil design software dominant in AU/NZ. Native LandXML including road models and stormwater networks. 12d.com

Carlson Survey / Civil. Paid (~3 500 USD), Windows. AutoCAD Civil 3D alternative for US surveyors and civil engineers. Full LandXML support.

Topcon Magnet Tools. Paid, Windows. Topcon's office software for survey data processing. LandXML import/export in the standard license.

ArcGIS LandXML Toolbox. Free Esri add-in for ArcGIS Pro. Imports LandXML alignments/surfaces into ArcGIS as feature classes.

QGIS. Free. Through GDAL/OGR no native LandXML support (no driver). Workaround — FME conversion (paid) or manual XSLT transformation LandXML → GeoJSON.

IndorCAD / Robur / Topomatic / CREDO. Russian civil software. All support LandXML 1.2 for exchange with AutoCAD Civil 3D. Used in Rosavtodor and regional road agency projects.

Map generation of Yaroslavl city center

Strengths and weaknesses

Strengths. Open XML — readable in any text editor, diffable in git, parseable by any XML engine. Vendor-neutral — supported by every major civil vendor. Semantically rich — describes horizontal/vertical alignments with proper clothoid spirals, not just polylines. Includes survey data (CgPoints) with full observation history. Extensible — vendors can add <Feature> blocks with custom data without breaking the base schema. Free — no royalties / SDK fees.

Weaknesses. Frozen since 2008 — no new versions, no support for modern requirements (BIM coordination, GIS integration, 3D city models — all in IFC 4.3 and CityGML). Verbose — XML overhead is noticeable, a 100 000-point TIN file may weigh 50+ MB against 5 MB in binary DGN. Semantic gap — doesn't describe road pavement structure (asphalt layers), bridge details, road furniture (signs, markings). Vendor variations — despite the standard, each vendor writes LandXML slightly differently (especially in <Feature> custom blocks), leading to round-trip losses. Gradual IFC 4.3 displacement — new tenders increasingly require IFC.

Russian context: Rosavtodor and design institutes

In Russia LandXML is used in Rosavtodor highway projects for data exchange between the general designer and subcontractors. A typical pipeline: the general designer works in AutoCAD Civil 3D or IndorCAD, exports the alignment as LandXML, hands off to surveyors (CREDO, Topomatic) to verify terrain fit. Surveyors return LandXML with updated survey data — <CgPoint> blocks from the total station.

In cadastre LandXML is less common — Rosreestr uses its own XML format with the .xml extension but a different schema (the v05/v06 land plot format). However for international projects and work with foreign contractors LandXML remains the standard.

Supported in all leading Russian civil tools: IndorCAD (roads), Robur (earthworks), Topomatic Robur (total station), CREDO Roads, KOMPAS-3D (via plugin). This makes LandXML a pragmatic choice for projects where side A works in Autodesk and side B in Russian software.

Pipeline in OSM2CDR

Our landxml_exporter.py solves a specific problem: pull street centerlines from OSM PostGIS and serialize them as LandXML <Alignment> blocks ready for Civil 3D import.

Step 1: PostGIS road extract. SQL query on planet_osm_line filtered by highway IN ('motorway', 'trunk', 'primary', 'secondary', 'tertiary', 'residential', 'service'). WKB geometries pulled directly through ST_AsBinary to minimize overhead.

Step 2: Topology simplification. ST_SimplifyPreserveTopology(geom, 1.0) reduces lines with a 1-meter tolerance preserving topology (no self-intersections). Critical for LandXML: "dirty" geometry with 10cm zigzags breaks Civil 3D alignment import.

Step 3: Linestring → Alignment. For every street build an <Alignment> element. Simplest case — all segments as <Line> (tangents). Optionally — curve detection through angular-change analysis between segments (if 3+ consecutive segments form an arc with equal radius → collapse into <Curve>). Spirals not generated (no clothoid parameter data in OSM).

Step 4: CRS projection. Coordinates project from EPSG:4326 (WGS84 lon/lat) into a local metric CRS — UTM, Russian MSK, or US State Plane per user choice. LandXML works in Cartesian XY, not geographic lon/lat.

Step 5: XML serialization. Python xml.etree.ElementTree with proper namespace http://www.landxml.org/schema/LandXML-1.2. No GDAL — there's no LandXML driver, everything is custom via etree. Pretty-printing for readability.

Step 6: Optional Surface. If <Surface> (DTM) is requested, take a DEM (SRTM 1-arcsec or ASTER GDEM v3) for the bbox, generate a TIN through Delaunay triangulation, serialize as <P> (points) + <F> (faces). This is optional — most civil engineers bring their own rectangular survey grid for terrain, not SRTM.

Step 7: Validation. The produced XML validates against the LandXML 1.2 XSD schema through lxml.etree.XMLSchema. Structural errors cause export failure with a clear message rather than quietly emitting a broken XML.

Pitfalls

Vendor variations. AutoCAD Civil 3D, Bentley OpenRoads, and Trimble Business Center all read LandXML 1.2, but each interprets <Feature> custom blocks a bit differently. On first import check that all expected alignments appear in the target program — vendor-specific attributes sometimes drop.

No clothoids in OSM. OpenStreetMap stores roads as plain LineStrings with no clothoid spiral parameter data. Our exporter emits only <Line> segments — production civil projects need alignment redesign with proper transition curves in Civil 3D.

Coordinate system. LandXML requires Cartesian XY, not geographic lon/lat. Always pick a local metric CRS (UTM, MSK zone, State Plane). Default WGS84 lon/lat gives trash in Civil 3D after import.

File size. Verbose XML can grow large: a 10 000-segment alignment is 5 MB XML. For a full city the export can hit 50-100 MB. That's normal for LandXML — even AutoCAD Civil 3D projects often export 100+ MB LandXML files.

No road geometry details. LandXML describes the center-line trace but not the cross-section (carriageway width, shoulders, sidewalks). For details, also export <Roadway> blocks with typical sections or share the DWG with full geometry.

IFC 4.3 migration. If your client demands modern BIM workflow, consider IFC 4.3 (IfcRoad/IfcRail extensions) instead of LandXML. For legacy and stable production — LandXML stays the reliable pick.

FAQ

How is LandXML different from IFC? LandXML is XML exchange for horizontal infrastructure (roads, water pipes, surveys, parcels), born in 1999 from a specialist consortium. IFC is a letter-based BIM standard for buildings, extended in 4.3 (2020) to infrastructure. LandXML is simpler but "frozen" since 2008. IFC is more powerful but requires more work.

Which LandXML version do you write? LandXML 1.2 — the only relevant version, supported by every civil tool since 2008. Earlier 1.0/1.1 formally work, but 1.2 is the standard.

Can I open LandXML in QGIS? Not natively — GDAL/OGR has no LandXML driver. Workaround: FME conversion (paid) or manual XSLT transformation LandXML → GeoJSON. Direct path — open in any civil software (AutoCAD Civil 3D, Bentley OpenRoads).

Can I use this export for a production civil project? No — it's OSM-based context, not geodetically-verified survey. Use it as a basemap for design: street geometry transfers correctly but without cross-sections, without precise planar registration, without transition clothoids. Production design still demands fresh survey and redesign in Civil 3D / OpenRoads.

Why limited curve support? OSM contains no road geometry metadata (radius, clothoid parameters) — only plain LineStrings. Accurate curve recovery needs total-station survey, not OSM data. We serialize geometry as-is through <Line> segments.

Sources

LandXML 1.2 Schema — landxml.org/schema/LandXML-1.2
Wikipedia, LandXML — en.wikipedia.org/wiki/LandXML
Autodesk Civil 3D LandXML — help.autodesk.com/view/CIV3D
Bentley OpenRoads LandXML — docs.bentley.com
Trimble Business Center docs — trimble.com
buildingSMART IFC 4.3 Infrastructure — technical.buildingsmart.org/standards/ifc/ifc-4-3