TUCBS coordinate reference systems: EPSG, grids and a common delivery language
The TUCBS CRS document is not only for GIS specialists. It gives survey crews, contractors and data teams a shared language for datum, EPSG and grid information.
Field takeaways
- TUCBS defines CRS using datum, ellipsoid, unit and EPSG-like attributes.
- Horizontal CRS, vertical datum and grid information should be checked separately.
- An EPSG code reduces ambiguity in delivery files.
- Grid and sheet information matters in institutional data exchange.
- Carry CRS and EPSG notes with MapLab Survey exports.
What TUCBS standardises
The TUCBS Coordinate Reference Systems and Geographic Grid Systems document exists so that geospatial data in Türkiye speaks one technical language. When one institution's data is opened at another, the answers to "which datum, which unit, which EPSG?" should sit next to the file. The data model treats the CRS name, unit, datum, ellipsoid and EPSG code as one package — a correct delivery is not just a line in the right place, but a line whose production can be read.
Why an EPSG code beats a filename
"turef" in a filename is a good clue and not enough. TUREF / TM30, TM33 and TM36 are separate records — EPSG:5254, 5255 and 5256 respectively in TUCBS. Writing the code into the delivery note stops the recipient from guessing. A practical filename looks like "parcel_check_turef_tm33_epsg5255_2026-06-14.dxf": not a legal document by itself, but it sharply reduces the odds of the file being opened in the wrong zone.
Horizontal and vertical are separate checks
Correct E and N values do not make the Z automatically correct. On the vertical side TUCBS handles TUDKA99 and Helmert orthometric heights separately, and the ellipsoidal height a GNSS receiver reports is not the orthometric level used on site. So "TUREF / TM33" alone is not a complete delivery note — if levels are involved, the height reference is stated too. On channel gradients, road profiles, foundation levels, cut-and-fill and drainage, that distinction turns directly into field decisions.
Why grid and sheet information still matters
Modern apps show a seamless map, but institutional data, sheet archives, scaled outputs and grid-based transformations still speak in sheet subdivisions. The TUCBS geographic grid approach classifies data consistently across levels and sections. For a field crew the meaning is simple: do not delete the source sheet name, grid reference or institutional code — in a retrospective check they can be as valuable as the coordinates themselves.
The delivery-note habit
When creating a project in MapLab Survey, write the horizontal system, any transformation, the layer names and descriptions properly; add column notes to CSV exports, layer names to DXF deliveries, and source-and-date notes to KML/KMZ. Good data is not merely measured data — it is data someone else can use without misunderstanding it.
Try these steps on your own phone.
MapLab Survey handles RTK/GNSS point capture, drawing, area and volume calculations and coordinate conversion, then exports to DXF, KML/KMZ, GeoJSON, Shapefile, GeoPackage, NCZ or CSV. Capture, calculation and export work offline. Live NTRIP corrections and online basemaps need a connection.
Frequently asked questions
Why does TUCBS matter in the field?
It helps crews deliver CRS, datum, units, grid and elevation information consistently.
Is writing TUREF enough?
No. Add the zone and EPSG code.
What should exports include?
Source, date, EPSG, units and layer definitions.
Technical references
The field guidance in this article is aligned with the technical and official references below.
Related: Sheet and grid delivery · TUREF, UTM, ITRF selection · GNSS Z and elevation · MapLab Survey