Map sheets, grids and field data delivery: why old references should not be removed
Modern map tools show continuous data, but sheet names, grid references and source codes still matter for traceability.
Field takeaways
- TUCBS treats sheet subdivision and geographic grids as part of data organization.
- Legacy sheet names, source codes and scale information should not be discarded.
- Sheet information helps when archive data and modern survey data are combined.
- DXF, KML, GeoJSON and CSV deliveries can carry sheet references as attributes or notes.
- Good layers and notes preserve source memory.
Why sheet names still matter
Most crews now see their data as a seamless map on a phone or tablet. But archive data, cadastral history, institutional deliveries and transformation checks still lean on sheet references. An old sheet name tells you which production environment the data came from and which scale and grid logic it was kept in. A line's coordinates can be transformed and re-exported endlessly; delete the source sheet note and the data loses its history — and on ED50-era work, the sheet and grid information is a serious clue when checking a transformation.
The TUCBS grid framework
The TUCBS Coordinate Reference Systems and Geographic Grid Systems document treats sheet subdivision as part of the national data order, covering production and naming from 1/250000 down through 1/100000, 1/50000, 1/25000 and larger scales. This does not mean opening a sheet index for every mobile measurement — it means that when the source carries sheet information, you do not throw it away. Keep it in a layer name, a description, a CSV column or the delivery note.
Carrying sheet information in modern formats
- DXF — a layer name, text note or block attribute; the CAD team sees it instantly.
- KML/KMZ — the placemark description; useful in Google Earth sharing.
- GeoJSON — a property field; right for GIS and web-map teams.
- CSV — dedicated "sheet", "source" and "scale" columns; the cleanest method for point lists.
The three-question delivery check
Before handing data over, ask: is the coordinate in the right place, has the source information survived, and can the person opening the file tell which data is old and which is new? Three simple questions that save hours on any job mixing archive and fresh survey.
Source memory in MapLab Survey
Keep the old sheet boundary, the new RTK measurements, the transformation control points and the delivery line on separate layers, and attach source notes to points and lines — they keep their value after export. Professional delivery is usually not about measuring a little more; it is about explaining what you measured a little better.
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
Is sheet information always required?
Not always, but it is valuable for archive and transformation work.
Where can it be stored?
In layers, notes, KML descriptions, GeoJSON properties or CSV columns.
What is the best field habit?
Keep old source data, new survey data and control points in separate layers.
Technical references
The field guidance in this article is aligned with the technical and official references below.
Related: TUCBS CRS · Transformation report · Exporting field data to CAD/GIS · MapLab Survey