Survey File Format Compatibility Matrix: DWG to GeoJSON
📲 Web-App
📖 Guide-Book
Click Any Cell to See What Survives a DWG, DXF, SHP, LandXML, GeoJSON, KML or GeoTIFF Conversion
7
File Formats Compared
42
Conversion Paths Mapped
5
Full-Fidelity Paths
24
Need a Tool or Extra Step
DWGVector
No universal CRS tag
Proprietary Autodesk binary. Full 2D/3D geometry, layers, blocks, styling, dimensions. Hard to parse outside licensed tools.
DXFVector
No CRS field at all
Open ASCII/binary interchange twin of DWG. Geometry, layers, blocks, text. No raster support of any kind.
SHPVector
CRS carried in a .prj file
Multi-file: .shp + .dbf + .shx + optional .prj. One geometry type per file, roughly 2GB practical ceiling.
LandXMLVector
CRS via a CoordinateSystem tag
Purpose-built for surfaces, TINs, alignments, parcels and survey points, at full precision, with named attributes.
GeoJSONVector
WGS84 assumed by default
JSON geometry plus arbitrary properties. No native styling standard. Native to Leaflet, Mapbox and most web maps.
KMLVector
Always WGS84, lon,lat order
Names, descriptions and basic styling. KMZ is simply a zipped KML with optional embedded resources, nothing lost.
GeoTIFFRaster
CRS plus affine transform embedded
Pixel grid for DEMs, orthomosaics and satellite imagery. Not a vector format at all.
| FROM ↓ / TO → | DWG | DXF | SHP | LandXML | GeoJSON | KML | GeoTIFF |
|---|---|---|---|---|---|---|---|
| DWG | Same format | FullSame family, near lossless DWG and DXF share the same underlying data model. Saving a DWG as DXF inside Autodesk-licensed software keeps geometry, layers, blocks, text, dimensions and styling intact. This is the standard first move before any DWG drawing enters a GIS workflow. | ManualSave as DXF first There is no direct DWG to Shapefile path. The practical route is DWG to DXF inside Autodesk software, then DXF to SHP using GIS software. Blocks, dimensions and DWG layer styling do not survive; only geometry and whatever fields get manually mapped into the DBF table make it through. | ManualNeeds Civil 3D or Carlson Exporting LandXML from a DWG drawing is a feature of specific civil software such as Civil 3D or Carlson, not a generic file conversion. Outside those tools there is no automatic path, and even inside them only recognised civil objects such as surfaces, alignments and points export correctly. | ManualRoute through DXF, then SHP DWG has no direct GeoJSON writer. The practical path goes DWG to DXF, then DXF or SHP to GeoJSON. Blocks and dimensions have no GeoJSON equivalent and are dropped; only basic point, line and polygon geometry survives the trip, along with any attributes attached manually along the way. | ManualDXF step, then reproject Reaching KML from DWG needs an intermediate DXF export and, critically, reprojection: DWG drawings are almost always drawn in a local or projected grid measured in metres, while KML requires WGS84 longitude and latitude in degrees. Skipping that reprojection step is the fastest way to place a boundary in the wrong place entirely. | ManualRasterise the drawing GeoTIFF is raster and DWG is pure vector, so there is no conversion here in the usual sense, only rasterising the drawing into a georeferenced image. Every line, block and text entity becomes a fixed pixel pattern with no coordinate precision left to query afterward. |
| DXF | FullOpen and save in Autodesk tools DXF and DWG share the same entity model, so opening a DXF file and saving it as DWG inside Autodesk software preserves geometry, layers, blocks and text without loss. This mirrors the DWG to DXF path in reverse and is just as reliable. | Same format | PartialSplit by geometry type DXF geometry converts cleanly, but a Shapefile can only hold one geometry type per file, so a DXF mixing points, lines and polygons across different layers has to be split into separate shapefiles. DXF layer names and colours are not automatic DBF fields; they need manual mapping to become real attributes. | ManualNo surfaces or alignments in DXF DXF has no concept of a TIN surface, a civil alignment, or a named survey point the way LandXML does. Reaching LandXML means specialised civil software rebuilding those objects from raw DXF lines and points, not a straightforward format conversion. | Geometry OnlyGeometry only, CRS unverified Point, line and polyline entities convert into GeoJSON geometry directly. DXF carries no real attribute table and no coordinate reference system field at all, so beyond bare shape, there is little to bring across, and whoever converts still has to confirm separately whether the X and Y values are actually WGS84 degrees. | Geometry OnlyGeometry only, verify coordinates Geometry maps across without trouble, but DXF layer colours and linetypes have no reliable KML equivalent and DXF has no real attribute table to carry over either. Because DXF's total lack of a CRS field means the numbers could be anything, the coordinates need checking against plausible longitude and latitude ranges before the KML output can be trusted. | ManualRasterisation, not conversion Turning DXF vector entities into a GeoTIFF means rendering the drawing onto a georeferenced raster grid, an entirely different operation from parsing group codes. There is no attribute or precision gain from doing this, only a flat reference image. |
| SHP | ManualRoute through DXF Shapefiles have no native DWG writer. The usual path is GIS software exporting DXF from the SHP geometry, then opening that DXF inside Autodesk software. DBF attribute fields are left behind unless someone manually turns them into DXF text labels or extended entity data. | Geometry OnlyGeometry only, DBF dropped Point, line and polygon geometry from the .shp file converts directly into DXF entities. The strong .dbf attribute table that makes Shapefiles useful for GIS work has no equivalent slot in DXF; those fields are dropped unless someone manually writes them out as DXF text labels next to each feature. | Same format | ManualPoints only, with a dedicated tool A Shapefile is generic GIS vector data, while LandXML is a purpose-built schema for surfaces, alignments and survey points. A simple point Shapefile can become LandXML survey points with a dedicated conversion tool, but there is no automatic, universal path for line or polygon shapefiles. | FullStandard, well supported This is one of the most common and dependable GIS conversions available. Geometry plus every .dbf attribute field maps into GeoJSON feature properties, and a valid .prj file lets reprojection to WGS84 happen automatically instead of being guessed at. | Full.prj drives correct reprojection Geometry and DBF attribute fields both carry across into KML placemarks and their ExtendedData fields, and a valid .prj file lets coordinates reproject correctly to the WGS84 longitude and latitude that KML requires. Shapefiles carry no native symbology to begin with, so KML's default styling applies unless it is set manually afterward. | ManualNeeds interpolation Turning shapefile point, line or polygon data into a GeoTIFF, for example gridding elevation points into a DEM, requires an interpolation method to fill the raster cells between features. That is a modelling decision, not a format conversion, and the result depends heavily on which interpolation method gets chosen. |
| LandXML | ManualNative import, civil tools only Civil software such as Civil 3D or Carlson can import LandXML directly and rebuild surfaces, alignments and points as native DWG objects. Outside that specific software category there is no generic LandXML to DWG path, and general-purpose CAD tools will not recognise the civil schema at all. | PartialSurfaces and alignments flatten Survey points and parcel boundaries convert into DXF points and polylines reasonably well. A TIN surface or a curve-defined alignment has to be flattened into plain line geometry first, which strips out the triangulation and the station-based design intent that made it a surface or alignment inside LandXML. | PartialPoints fine, surfaces do not fit Survey points and parcels convert into point and polygon shapefiles with their attribute fields intact. Surfaces and alignments have no direct shapefile equivalent; a TIN surface would need to become contour lines or a separate raster DEM, and an alignment reduces to a plain polyline once its station and curve data is discarded. | Same format | PartialNamed points survive, TINs do not Survey points and parcel boundaries carry their named attributes into GeoJSON properties cleanly. Surfaces and alignments have no native GeoJSON representation; a TIN has to be broken down into individual triangle polygons or a contour line set, a lossy approximation of the original surface definition. | PartialGood for viewing, not precision Survey points and parcels display well in Google Earth once reprojected to WGS84, with names carried into placemark labels. Surfaces and alignments need converting into simple lines or polygons first, fine for a quick visual check but well short of the precision a civil engineer relies on in the original LandXML surface. | ManualTIN to grid is a real rebuild A LandXML TIN surface is genuinely the best starting point in this whole matrix for producing a DEM, but it still needs gridding the triangulated surface onto a regular raster, a real interpolation step rather than a straight copy. Points, alignments and parcels have even less direct relationship to raster cells and need that same gridding step first. |
| GeoJSON | ManualRoute through DXF GeoJSON has no direct DWG writer, so the practical route is GeoJSON to DXF, then DXF to DWG inside Autodesk software. JSON property values have no attribute-table home in DWG and typically need manual placement as text labels if they need to appear on the drawing. | Geometry OnlyGeometry only, JSON dropped Point, LineString and Polygon geometry writes into DXF entities directly. DXF has no attribute table at all, so every JSON property on the GeoJSON feature is dropped unless someone manually writes it out as a DXF text label next to the geometry. | PartialSplit by type, fields truncate Geometry and JSON properties both convert, but a Shapefile allows only one geometry type per file, so a FeatureCollection mixing points and polygons has to be split into separate shapefiles. DBF field names are also limited to 10 characters, so longer JSON property keys get truncated or renamed. | ManualNo civil schema in plain JSON GeoJSON properties are arbitrary JSON key value pairs with no built-in concept of a survey point code, a TIN surface, or an alignment station. Producing valid LandXML from GeoJSON means manually mapping properties into the correct civil schema elements, a data modelling task rather than an automatic conversion. | Same format | FullNatural fit, same lon,lat order GeoJSON and KML both order coordinates as longitude, then latitude, so there is no coordinate swap risk between these two formats the way there is with most others. JSON properties map cleanly into KML ExtendedData fields, and since GeoJSON never had a styling standard to begin with, nothing is lost on that front either. | ManualRasterisation needed GeoJSON features have to be rendered or interpolated onto a raster grid to become a GeoTIFF, a rasterisation or gridding operation rather than a conversion of existing data. Point features used for elevation would need spatial interpolation to fill the space between them. |
| KML | ManualRoute through DXF, then reproject KML has no direct DWG path; the practical route is KML to DXF, then DXF to DWG inside Autodesk software. Because KML coordinates are always WGS84 degrees and most CAD drawings use a local or projected grid in metres, a reprojection step is needed before the data is usable for engineering work. | Geometry OnlyGeometry plus a label only Point, LineString and Polygon geometry writes into DXF entities cleanly. KML's icon, line and polygon styling has no DXF equivalent and is dropped; a placemark name can survive as a plain DXF text label near the geometry, but that is a label, not a real attribute, and DXF gains no CRS tag either way. | PartialSplit by type, no room for style Placemark names and descriptions convert into DBF attribute fields without much trouble, but a Shapefile holds only one geometry type per file, so a KML mixing points, lines and polygons has to be split. KML's icon and line styling has no DBF field to live in and is not preserved. | ManualNo survey schema in KML KML placemarks carry a name and a description, not the coded survey point, alignment or surface information LandXML expects. Getting from KML to a valid LandXML file means manually re-encoding each placemark into the correct schema element, a data modelling task rather than an automatic conversion. | PartialAttributes fine, style dropped Geometry and the placemark name and description transfer into GeoJSON properties without difficulty, since both formats already share the longitude, latitude coordinate order. GeoJSON has no styling standard, so KML's icon, line and polygon style settings are simply left behind unless someone recreates them manually as non-standard custom properties. | Same format | ManualGroundOverlay drapes, not vectors A raster image can be draped over a location using a KML GroundOverlay, and it works the other way too, but that only displays an existing picture inside a bounding box; it does not turn KML vector geometry into raster pixel data. Real feature vectorisation would be needed to go the other direction. |
| GeoTIFF | ManualDigitise features by hand Getting vector CAD entities out of a GeoTIFF means tracing features from the pixel data, commonly called heads-up digitising, or running an automated vectorisation tool. This is feature extraction, not a format conversion, and the resulting DWG geometry is only as accurate as the tracing. | ManualContour extraction needed A GeoTIFF DEM has to go through a contouring algorithm before it produces meaningful DXF line work, generating contour polylines at chosen elevation intervals from the pixel grid. An orthomosaic GeoTIFF needs manual or automated digitising of visible features instead, since raw pixel values encode no feature boundaries at all. | ManualVectorise or contour first Shapefile geometry has to be pulled out of the raster through contouring for elevation data, or through digitising and classification for imagery. GIS software can automate parts of this, but it remains a feature extraction process with real judgement calls involved, not a lossless format swap. | ManualGrid to TIN rebuild Building a LandXML surface from a GeoTIFF DEM means converting the regular pixel grid into a triangulated network, a genuine data restructuring exercise rather than a copy. The resulting TIN is an approximation of the original grid, with point density and triangulation choices affecting the final surface accuracy. | ManualExtract vector features first Vector features have to be extracted from the raster before GeoJSON is even possible, through contouring, classification or digitising. Once that extraction step is done, writing the resulting shapes as GeoJSON is straightforward; the real difficulty is entirely in creating the vector data in the first place. | ManualGroundOverlay only, not real vectors A GeoTIFF can be wrapped inside a KML GroundOverlay so the image displays correctly in Google Earth using its own embedded georeferencing, a genuinely useful and common technique. It is still only displaying the original raster; the pixel data has not become KML vector geometry at any point. | Same format |
Full Geometry, attributes and styling all survive.
Geometry Only Shape survives, attributes and styling do not.
Partial Some specific, named piece of data is lost.
Manual / Needs Tool No direct 1:1 path, an intermediate format or external tool is required.
Select a cell
Click any cell in the matrix above, or focus it with Tab and press Enter, to see exactly what survives and what is lost for that specific conversion.
Two traps hide inside this matrix. First, GeoTIFF is raster, not vector, so nothing in the other six formats becomes a GeoTIFF, or comes from one, through a normal conversion; it always needs a rasterisation or vectorisation step. Second, DXF stores no coordinate reference system field at all, unlike SHP, LandXML and GeoTIFF, which can each carry one, so a DXF handed between two software packages is only ever as correctly placed as the assumption both sides make about its coordinates.
Field Engineering Insight
KML and GeoJSON both write coordinates longitude first, then latitude, so a well-built converter between the two never needs a coordinate swap. DXF has no such courtesy: it has no coordinate field label at all, just an X and a Y, and whether that X is a longitude, a UTM easting, or a local site grid value is a decision someone made outside the file and never wrote down.
Why Check a Survey File Format Compatibility Matrix Before You Convert
A survey file format compatibility matrix earns its place in the workflow the day someone hands you a GeoTIFF DEM and expects a DXF back by evening, or a DWG boundary that needs to become a Shapefile for a district GIS submission. Checking the path before opening any conversion tool saves the rework of discovering, an hour in, that half the data never had anywhere to go.
The line most people trip over is raster versus vector. A GeoTIFF DEM looks like ordinary survey data on screen, so it is tempting to convert it into a DXF the same way you would a KML file. It cannot be done that way: a GeoTIFF is a grid of pixel values with an embedded coordinate transform, and pulling vector lines out of it means contouring or digitising, not a quick export.
What the Survey File Format Compatibility Matrix Misses: DXF's CRS Gap
The second trap is quieter and more common. DXF carries no coordinate reference system field at all, unlike SHP, GeoTIFF and LandXML, each of which can store one. Every DXF a surveyor opens is really a bet that whoever wrote it used the same grid. That gap causes more misplaced boundary points than any other formatting issue our GIS solutions team sees on handover files, which is why format checks belong inside a proper GIS dashboard workflow, not a one-off desktop conversion.