Stereo 70 Exports From CadSense: Give the DXF EPSG:3844, Not the Code Retired in 2008

Disclosure: Zetta360 works with Terra Apps on the development of their products.

Stereo 70 is the planar coordinate system the EPSG registry lists for cadastre, engineering survey and topographic mapping in Romania. This post is about one place that geometry now comes from, CadSense, Terra Apps' web platform for Romanian cadastre and property data. It is also about the one detail of a Stereo 70 file that no export carries for you: the code you give it when you open it.

The short version: when you load a CadSense DXF into QGIS or any tool that asks for a coordinate system, choose EPSG:3844. The other code, EPSG:31700, which Terra Apps' own product summary still prints, was retired by the EPSG registry in 2008.

What CadSense gives a surveyor

CadSense finds a property by any of four identifiers: the cadastral number, the land-book (CF) number, the electronic identifier (IE) or the topographic number. It then shows the property on a satellite or hybrid map over the cadastral network of the account's area. Its AI assistant takes the question in plain words, by text or by voice, and works out which kind of number it was given without being told. It answers the question first and then adds the context: identifiers, the area from the deeds next to the measured area, block and parcel, land use and record class. If a CF has been closed, it says where the property is now.

For a surveyor, the useful end of that chain is the export. From a property's complete sheet, CadSense writes the geometry and the fields you pick (areas, land use, type, address, UAT) in eight formats. The product page lists KML, KMZ, GeoJSON, DXF, ESRI Shapefile, CSV, a printable PDF sheet and a georeferenced GeoPDF. Two of them name their coordinate system on the page. GeoJSON comes in WGS84. The DXF comes in Stereo 70 and is meant for AutoCAD and surveying work. The page also aims the product at exactly this job: cadastral firms exporting properties from across Romania to Stereo 70 DXF, SHP or KML, and surveyors taking the geometry, neighbours and buildings with them before going into the field. The neighbours come in eight directions, and a Nearby view lists the properties around your GPS position.

The rest of this post is about what happens to that DXF next.

Stereo 70 has two EPSG codes, and one of them is deprecated

A DXF stores numbers, not a coordinate system. The software that opens it has to be told what those numbers mean, and in GIS tools that means picking an EPSG code. For Stereo 70 there are two candidates.

EPSG:31700, named Dealul Piscului 1970 / Stereo 70, is the older one. The EPSG registry's own record marks it deprecated as of 24 September 2008 (change 2008.011) and names EPSG:3844, Pulkovo 1942(58) / Stereo70, as its replacement. The reason the registry gives is that the base coordinate system of 31700 does not exist as a separate thing: it is an alias for S-42. The record for 3844 lists its usage in Romania as cadastre, engineering survey and topographic mapping, and gives ANCPI, the Romanian cadastre agency, as its information source. Its last revision is dated 30 April 2024.

Terra Apps' own machine-readable product summary still labels the CadSense DXF as Stereo 70, EPSG:31700, at the time of writing. It is the one to stop using.

Why the code changes nothing in AutoCAD and matters in QGIS

The two definitions describe the same projection. Read side by side on epsg.io, both are an oblique stereographic projection on the Krassowsky 1940 ellipsoid. Both use latitude of origin 46, central meridian 25, scale factor 0.99975, and false easting and false northing of 500,000 metres. A point has the same Stereo 70 coordinates under either code. That is why a surveyor working only in a CAD drawing never notices the difference: nothing moves.

The difference appears the moment the geometry has to meet anything in WGS84. That includes a GeoJSON file, a web map, Google Earth, or the satellite background in your GIS. RFC 7946, which defines GeoJSON, fixes its coordinates as WGS84 longitude and latitude in decimal degrees. So the GeoJSON export CadSense produces and the DXF it produces are, by definition, in two different systems. Bringing them together means a datum transformation, and the EPSG code you chose decides which transformation your software reaches for.

For EPSG:3844, epsg.io lists a default Romania-wide transformation to WGS84 with a stated accuracy of 3.0 metres. Its parameters are taken from the Pulkovo 1942(58) to ETRS89 transformation. For EPSG:31700, the only transformations to WGS84 on offer are themselves deprecated, with stated accuracies of 7.0 and 10.0 metres. One of them carries a remark that its parameters were borrowed on the assumption that Pulkovo 1942 and Dealul Piscului 1970 are the same in Romania.

Two things follow. Pick 31700 and your overlay can sit several metres off, for reasons that have nothing to do with the parcel or with CadSense. And even with 3844, the registry itself puts the generic transformation at 3 metres. Whether that is good enough is a question about the tolerance of your job, not about the file. For a boundary dispute, the drawing should stay in Stereo 70 and never take the round trip through WGS84 at all.

The integration step nobody demos

The assistant that reads a CF number in plain words is the visible part of CadSense. The DXF that lands correctly in a surveyor's drawing is the part that decides whether anyone keeps using it. That is the same gap we wrote about in why enterprise AI doesn't ship: the work that matters is integration with the systems people already run, and here that system is the CAD and GIS stack of a cadastral office. A coordinate system label is a small thing. Getting it wrong is exactly the kind of last-mile defect that makes a working product look unreliable.

Limits worth knowing before you ask for an account

• Accounts are created on request. The product page describes the route: you write to Terra Apps saying who you are (city hall, cadastral firm, surveyor or farmer) and which area you need. They set up the account type and access area and email the credentials, and you choose your own password at first sign-in.
• Each account sees its own area. Access ranges from a single UAT to the whole country, depending on the account type.
• The data comes from the Terra Apps system. The page says it is stored in line with the GDPR. It does not describe the export as a substitute for an official extract from the land book, and neither does this post.
• The SHP export's coordinate system is not stated on the CadSense page. Check the .prj file that comes with it before assuming it matches the DXF.

Before a CadSense export reaches a client

1. Export the same property twice from its complete sheet: once as DXF, once as GeoJSON.
2. In QGIS, load the DXF and set its layer coordinate system to EPSG:3844. Load the GeoJSON as it comes; RFC 7946 already fixes it to WGS84.
3. Compare the two outlines. If they differ by more than the 3 metres the registry gives for the default transformation, stop and find out why before the drawing goes anywhere.
4. Sanity-check the raw DXF numbers. epsg.io gives the projected bounds of Stereo 70 as 116,395 to 1,018,922 metres and 215,587 to 771,891 metres. Coordinates outside those ranges mean the axes or the units were read wrongly on import.
5. Open the .prj of any SHP export and note which EPSG code it declares. If it says 31700, reassign the layer to 3844 before reprojecting.

If any of these checks fails on a real export, the advice above is wrong for that file. Specifically: if a DXF assigned EPSG:3844 sits further from its GeoJSON twin than the same DXF assigned EPSG:31700. We would like to hear about it.

To request a CadSense account, the product page lists office@terra-apps.com.