Gains:
- Ability to accurately match and explain datum, projection, EPSG code and transformation parameter concepts with AI
- Ability to fully specify the source/target system and parameters when editing coordinate transformation requests with AI
- Ability to test the transformation output with known control points and order control and detect datum shifts
The quietest and most expensive mistakes in map engineering are hidden in coordinate transformations. A number appears correct, the model responds confidently, the output is formatted properly; But since there was an incorrect datum assumption behind it, the result shifted by meters in the field. In this unit, we clarify the concepts of coordinate systems, datum, projection and EPSG, and cover how to correctly construct transformation requests with artificial intelligence and how to precisely verify the output. Rule of thumb: AI proposes or writes the code for the transformation; Acceptance of the result remains with the engineer, with known control points.
Let's clarify the terms. Datum is the mathematical reference surface representing the earth and its positioning; The same physical point is expressed by different numbers in the WGS84, ED50, ITRF or TUREF datum. Projection is a method of turning the round earth into a plane (e.g. UTM, Transverse Mercator); Returns the coordinate in meters instead of degrees. The EPSG code is an entry in the international catalog that identifies a datum+projection combination with a single number (e.g. EPSG:4326 = WGS84 geo; EPSG:5256 = TUREF/TM33). Transform parameters are translation/rotation/scale values applied when moving from one datum to another (e.g. 7-parameter Helmert transform).
Why Is It Vital to Specify Datum?
A coordinate triple (e.g. 39.92, 32.85) by itself does not specify a location; It is incomplete unless it is stated in which datum it is. The same numbers indicate one location in WGS84, a few meters away in ED50. In Türkiye, the difference between ED50 and WGS84/ITRF can sometimes reach meters, depending on the region. So for a transformation request to be meaningful, three things must be given explicitly: the source system, the target system, and the transformation parameters (if necessary).
Just telling the AI "convert this to UTM" leaves it unclear which datum to start from. The model makes an assumption (mostly WGS84) and if that assumption is wrong the result silently slips by. There is no error message or red warning; It's just that the foundation is poured in the wrong place in the field.
Caution: "UTM" by itself is not a CRS. UTM has 60 slices and each slice can match different datums. "UTM Zone 36N / WGS84" (EPSG:32636) and "ED50 / UTM Zone 36N" (EPSG:23036) are different systems. Specify the slice number and datum together.
Step by Step: A Secure Conversion Workflow
- Finalize the source. Which CRS is your data in? Confirm from metadata, project file or corporate standard. If you're not sure, the order of the coordinates gives a clue: whether it's degrees (small numbers) or meters (6 digits).
- Write down the goal and purpose. Where will you go, which EPSG code and why (CAD submission, GIS analysis, title deed)?
- Determine if parameters are required. Projection change within the same datum is parameterless; Transitioning between different datums (e.g. ED50 → TUREF) requires formal conversion parameters.
- Have the AI print the code/step but don't accept it. Model can generate PyProj/QGIS step; You run it and test it with a checkpoint.
- Verify with checkpoint. Put a reference whose coordinates are already known (its value is available in both systems) through the same transformation and compare it with the expected value. Tens of meters difference = wrong datum/parameter.
Three Mini Cases: By the Numbers
Case 1 — Silent datum drift. In a municipality project, although 320 points came from ED50, AI was told to "convert to TM" without specifying the datum. The model assumed TUREF, made the transformation parameterless; The results are a systematic recording of approximately 3-5 m from the actual location. When a single known control point was subjected to the same transformation, a difference of 4 m was observed with the expected value; The error was caught before it spread to the entire data set and the job was repeated with the correct parameters.
Case 2 — Slice confusion. One team unknowingly merged two data sets collected in different slices (TM30 and TM33); The dots shifted hundreds of kilometers on the map. Comparison of rank check and single control point immediately showed that the values to the right did not match. The problem was solved when each set was labeled with its correct slice code and converted to a common CRS.
Case 3 — Radian/degree trap. In a conversion code written in AI, the angle unit was mixed up and the coordinates were processed in radians instead of degrees; The output was completely nonsensical (single digit values to the right). Known checkpoint testing showed the error on the first line; When the unit was corrected, the result fell into place. Lesson: just because the code "works" doesn't mean it's correct.
Weak Prompt / Strong Prompt
Weak prompt:
Convert these coordinates to UTM.[coordinates]
Powerful prompt:
Task: construct the coordinate transformation (I will do the implementation).- Source CRS: EPSG:23036 (ED50 / UTM Zone 36N)- Target CRS: EPSG:5256 (TUREF / TM33)- This is a transition between different datums; specify that a formal transformation parameter is required and write what information is needed.- DO NOT RECOMMEND TRANSFORMATION if there is missing/unclear information, ask first.- For verification: write step by step how to confirm the coordinate with a control point known in both systems.- Specify the expected target right value order (6 digits).Data (anonymous): [point table]
The powerful prompt fixes the source and target with EPSG, reveals the datum transition and parameter needs, requests the verification plan, and gives the rank expectation.
Four Copiable Templates
1) CRS diagnosis prompt:
Identify possible CRS of the following coordinates: look at the order of the numbers (degrees or meters), sign and spacing. Don't say it for sure; List the possible candidates and the distinguishing clue for each. Data: [coordinates]
2) Transformation plan (parameter aware):
To convert between source [EPSG:...] and target [EPSG:...]: (a) determine whether it is within the same datum or between datums, (b) if parameters are required, write what information is needed, (c) list the application steps. Presenting the result "exactly"; verification required.
3) Checkpoint verification setup:
Write step by step the checkpoint method to verify a transformation: which point to choose, where to get its value in two systems, how much difference is acceptable, which difference is the sign of datum error. Context: [CRSs]
4) QC after batch conversion:
Look for anomalies in the following transformation output: out-of-order values, slice boundary violations, systematic offset sign (similar constant difference at all points). List findings and write possible cause (incorrect datum/slice). Output: [transformed coordinates]
Comparison of Coordinate Concepts
concept
What indicates
example
The result if mixed
datum
reference surface
WGS84, ED50, TUREF
Systematic shift of meters
projection
Open to plane
UTM, TM, Lambert
Shape/scale distortion
slice
projection zone
TM30/TM33, Zone 36
Hundreds of kilometers of gliding
EPSG code
Datum+project. package
4326, 5256, 23036
Wrong system selection
Parameter
Transition between datums
7-parameter Helmert
Error in datum migration
Common mistakes
- Requesting conversion without specifying datum. Silent drift if the model's assumption is wrong.
- Saying "UTM" and skipping the slice and datum. Slice confusion causes hundreds of kilometers of slippage.
- Transitioning between datums without parameters. Official parameters are required for transitions such as ED50 → TUREF.
- Confusing degrees/radians or degrees/meters. The level is completely destroyed.
- Not verifying with a checkpoint. The surest way to catch systematic drift is to jump.
- Mistaking the code's operation for accuracy. Code that works without errors may also produce incorrect results.
In summary
Coordinate transformation is incomplete and dangerous unless the source system, target system and, when necessary, transformation parameters are explicitly given. Datum, projection and slice are different things; Jumping over one of them causes a slide of from meters to hundreds of kilometers. AI can construct the transformation, but it is up to the engineer to accept it by passing a control point with a known coordinate through the same transformation and comparing it with the expected value. Rank checking and single checkpointing catch most of these errors in seconds.
Application task
Select a conversion scenario (for example ED50/UTM36 → TUREF/TM33). Write the source and target EPSG codes, determine if this is a transition between datums, and note the need for parameters. Then write a checkpoint verification plan: concretize which point you will get its value from in the two systems, and how much difference you will count as a datum error.
checklist
- [ ] I confirmed the source CRS with the EPSG code.
- [ ] I specified the target CRS with the EPSG code.
- [ ] I checked whether there is a transition between datums and the need for parameters.
- [ ] I specified the slice number and datum together.
- [ ] I rank-checked the output.
- [ ] I confirmed the coordinate with a known control point.
- [ ] I checked if there was a systematic constant difference (shift).
- [ ] I have linked the final acceptance of the conversion to engineer approval.