ED50 to TUREF transformation: why old maps shift against new surveys
When an old map does not sit on top of a new GNSS survey, the receiver is often blamed first. Very often the real reason is datum difference and legacy network quality.
Field takeaways
- ED50 still appears in old maps, cadastral data and institutional archives.
- HGM evaluates both grid-based and three-dimensional ED50 to TUREF transformations.
- The published results report about 0.26 m and 0.27 m for grid components, and about 1.1 m for 3D transformation.
- Those numbers do not mean every old sheet will transform cleanly everywhere.
- Keep source, transformation note and control checks with the project.
How ED50 data reveals itself
ED50 data rarely announces itself. The clues are an old sheet name, a legacy municipal drawing, an archived coordinate list, or a comment line in a NetCAD file. Sometimes there is no note at all: you drop the data into a TUREF/TM project and the boundary simply does not sit where it should. The first job then is not transforming — it is understanding the source: metres or degrees, which zone, when the sheet was produced, whether anyone has checked it against a current TUREF point.
There is no single ED50-TUREF shift
Treating the ED50-TUREF difference as one constant easting and northing correction is dangerous. At the scale of Türkiye, the structure of the old geodetic network, the observation dates, the local densifications and the sheet production method all matter. HGM's study compares two approaches — a two-dimensional grid transformation and a three-dimensional datum transformation — and reports precisions around 0.26 m and 0.27 m for the grid components against roughly 1.1 m for the 3D method. The method and the control point distribution drive the quality directly.
The old sheet's own error rides along
The most skipped fact in the field: the transformation carries the sheet's own error with it. Sheet scale, drafting method, digitising quality, the reliability of old control points and post-earthquake movements all feed the result. "I transformed ED50 to TUREF, so it is centimetre-grade now" is not a sentence a surveyor should say. On cadastre, road expropriation, development applications, line boundaries and payment work, test the result against shared control points — if one corner fits and another opens up, the legacy data's local behaviour is the suspect, not the receiver.
The safe workflow
- Write down the source datum, date and production method where known.
- Fix the expected TUREF/TM EPSG code for the project.
- Note the transformation method and where its parameters came from.
- Check the differences on at least two shared control points, preferably more.
- If the result is out of tolerance, do not force the fit — request the institutional transformation or fresh control.
Keeping it honest in the project
Keep the ED50 base and the new TUREF measurements on separate layers, each with source, date, method and control notes, and put the datum and EPSG into every export's filename. When "why is this boundary shifted?" arrives months later, the trail answers 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
Is ED50 still encountered?
Yes, mostly in old sheets, archives and legacy cadastral data.
Can I use one fixed shift?
Not for critical work. Use known transformation information and control points.
What should be recorded?
Source datum, target EPSG, transformation method, control residuals, date and crew.
Technical references
The field guidance in this article is aligned with the technical and official references below.
Related: Transformation report · TUREF, UTM, ITRF selection · Preparing KML for cadastre · MapLab Survey