If you are searching for how to translate EPSG codes, how to translate coordinate reference systems, how to translate WGS 84 or UTM coordinates, or how to preserve a CRS such as EPSG:4326 across languages, the first rule is that geospatial reference information is structured technical data. Translate the map labels, legends, instructions and explanatory prose; do not casually translate, renumber or reinterpret the coordinate reference system that tells software where the coordinates belong on Earth.
This matters in GIS, surveying, mapping, engineering, construction, utilities, environmental science, transport, property records, remote sensing, navigation, emergency management, digital twins, spatial databases and multilingual web maps. A target document can be fluent and still be geographically wrong if degrees become metres, latitude and longitude are swapped, an EPSG code is changed because the target country uses another grid, a UTM zone loses its hemisphere, or a WKT definition is treated as ordinary text.
This guide explains how to translate geospatial reference information without moving the data. It separates coordinates from the coordinate reference system, a datum from a projection, WGS 84 from Web Mercator, geographic coordinates from projected coordinates, and human-readable CRS names from machine identifiers. It also covers UTM zones, axis order, units, transformations, coordinate epochs, vertical reference, WKT, spatial files, QA and the authoritative EPSG Geodetic Parameter Dataset.
1. Coordinates without a reference system are incomplete information
The pair 1.3521, 103.8198 looks like a location only because a reader silently assumes what the numbers mean. Are they latitude and longitude in degrees? Which datum? Which axis comes first? Are they projected easting and northing values? Without reference information, the numbers are not self-sufficient.
Translation should therefore preserve both the coordinate values and the CRS metadata that gives them meaning. A beautifully translated table with detached coordinates can become less useful than the source because the target reader no longer knows how to place the points correctly.
2. An EPSG code is an identifier, not a phrase to translate
The EPSG Geodetic Parameter Dataset assigns identifiers to coordinate reference systems, coordinate operations and related geodetic objects. A familiar example is EPSG:4326. The number should remain the same across languages because it points to the same registered object.
You may translate the human-facing CRS name or explanatory sentence where appropriate, but the identifier itself remains machine-facing data. Replacing one code with another because the target audience commonly uses a local grid is not translation; it is a coordinate-reference transformation decision.
3. The EPSG Dataset is a maintained authority, not a static code list
The EPSG Geodetic Parameter Dataset is maintained by the Geodesy Subcommittee of the IOGP Geomatics Committee. It contains definitions of coordinate reference systems and transformations that can be global, regional, national or local in application. It is continually maintained rather than frozen forever.
A translation project should therefore verify important CRS identifiers against the current authoritative dataset instead of a copied spreadsheet or old forum post. Deprecated records, revised transformations and newer realizations can matter in precise work.
4. CRS means more than “map projection”
A coordinate reference system combines a coordinate system with a reference frame or datum so numbers can represent positions. Some CRSs are geographic and use angular coordinates. Others are projected and express positions on a plane. Still others address vertical or compound reference.
Translators should avoid reducing every CRS to the target-language equivalent of “projection.” A projection is one part of some projected CRSs, not the whole idea. Precise vocabulary prevents technical readers from inferring the wrong reference model.
5. Geographic and projected coordinates use different kinds of numbers
Geographic CRSs typically express latitude and longitude as angular quantities. Projected CRSs typically use linear coordinates such as metres. A value of 500000 can be a plausible easting and an absurd latitude in degrees.
When translating tables, dashboards or field instructions, preserve the coordinate type and unit. Do not localize a degree symbol into a linear unit or add metres because the target audience is accustomed to a national grid.
6. WGS 84 is not a synonym for every latitude-longitude dataset
WGS 84 is a specific geodetic reference system with multiple realizations and a long operational history. People often use “GPS coordinates” or “lat/long” casually, but professional translation should preserve the stated reference rather than generalize it into a vague geographic label.
If the source says WGS 84, keep that information. If the source only says latitude and longitude, do not invent WGS 84 simply because it seems likely. Geospatial certainty should not exceed the metadata actually supplied.
7. EPSG:4326 and EPSG:3857 are not interchangeable
EPSG:4326 is associated with WGS 84 geographic coordinates. EPSG:3857 is the widely used Web Mercator projected CRS seen in many online maps. Their coordinate values, units and geometric behavior differ.
A translator should never replace one with the other because both appear in web mapping. If a localized map application transforms data for display, the transformation belongs to the GIS layer and should be documented. The translation layer should not silently rewrite CRS identity.
8. Web Mercator is a display convention, not a universal geodetic truth
Web Mercator became common because it works conveniently with tiled web maps. It distorts scale increasingly toward high latitudes and is not suitable for every analytical or surveying purpose. A translated interface that labels every coordinate “Web Mercator” because the basemap uses it can misdescribe the source data.
Keep the source-layer CRS, display CRS and analysis CRS separate. One map can contain data transformed on the fly from several CRSs. The visible basemap does not automatically define the stored coordinates.
9. UTM is a family of zones, not one single coordinate system
The Universal Transverse Mercator system divides much of the world into longitudinal zones. A UTM coordinate is incomplete without its zone and hemisphere or another unambiguous CRS identifier. Easting 500000 can occur in many zones.
Translation should preserve the zone designation exactly and keep it attached to the coordinate values. A target sentence can translate “UTM zone” as terminology, but the actual zone number and hemisphere remain controlled geospatial data.
10. Hemisphere is not optional context in UTM interpretation
Northern and southern UTM representations use conventions that affect northing values. A missing hemisphere can place a point thousands of kilometres away when software makes the wrong assumption.
If the source carries “UTM 48N,” preserve the N. If it uses a full EPSG identifier for the relevant UTM CRS, preserve that code. Do not translate N and S into target-language initials inside a machine field unless the system explicitly defines localized notation.
11. Datum and projection solve different parts of the problem
A datum or reference frame describes how coordinates relate to the Earth. A map projection describes how a curved surface is represented on a plane. A projected CRS combines several elements, including the underlying geodetic reference and projection method.
Translating both as one generic word can hide important distinctions in surveying and engineering documents. Build a glossary that distinguishes datum, reference frame, ellipsoid, projection, coordinate system and CRS.
12. Ellipsoid is not the same thing as datum
An ellipsoid is a mathematical surface used to approximate the Earth’s shape. A geodetic datum or reference frame establishes how coordinates are anchored and realized. Different reference systems can use the same ellipsoid while producing different coordinate meanings.
A translator should preserve this distinction rather than turning every reference to ellipsoid, spheroid and datum into one familiar target-language term. Technical glossaries should define the concepts, not merely pair words.
13. Axis order can be a data contract
People often say “longitude, latitude” in software practice and “latitude, longitude” in ordinary speech. Formal CRS definitions can specify axis names and order, while APIs or file formats can impose their own coordinate ordering conventions.
Do not reorder coordinate columns merely to match the target language’s phrase order. Read the schema. A translation of “latitude/longitude” can change word order naturally in prose, but the machine coordinate sequence must remain what the format expects.
14. Easting and northing are technical roles, not compass decoration
Projected coordinates commonly use easting and northing. These terms refer to coordinate axes in the projected system, not simply to the everyday directions east and north. A value can include false easting or false northing introduced by the projection definition.
Translate the technical terms consistently and preserve the numerical axes. Do not “correct” a large easting because it seems inconsistent with the physical distance east of a local landmark.
15. Coordinate units are part of the CRS meaning
Degrees, metres, feet and other units can occur in geospatial systems. A transformation from one CRS to another can change both the coordinate numbers and the unit. Translation alone should not.
If a target audience prefers another measurement system, provide converted values only through an explicit geospatial or engineering calculation. Preserve the original CRS and source coordinates for traceability.
16. Decimal separators can destroy coordinate parsing
Some locales use a comma as the decimal separator. Spatial file formats and APIs often require a period. Replacing 103.8198 with 103,8198 inside a CSV can also collide with the comma used as a field delimiter.
Keep machine coordinate notation under the file-format specification. Localized human display can use target conventions in a separate layer, but canonical data should remain parseable by the receiving software.
17. Thousands separators do not belong in machine coordinates
A projected easting such as 500000 may be shown to a human as 500,000 in some locales. That comma can be mistaken for a coordinate separator or CSV delimiter. A nonbreaking space can create another hidden parsing problem.
For data exchange, use the required numeric syntax. If a report needs localized formatting, keep the raw value available and make sure copy-paste into GIS software does not introduce grouping characters.
18. Degree-minute-second notation requires structural care
Geographic coordinates can appear as decimal degrees or degrees, minutes and seconds. Symbols, spaces and hemisphere letters carry structure. A language tool that replaces quotation marks or moves letters can make the coordinate ambiguous.
Protect the complete coordinate token. If converting DMS to decimal degrees for the target, treat that as a numerical conversion and verify it independently rather than as typography.
19. Hemisphere letters are machine conventions in many fields
N, S, E and W can look like English-language initials, but they often function as standardized coordinate notation. Replacing them with the target-language initials can break parsers and confuse international users.
A localized explanation can spell out “north” or “west” in the target language. The coordinate field itself should follow the format specified by the source system.
20. A coordinate transformation is not a translation
Changing a point from one CRS to another requires a mathematical coordinate operation. The numbers can change substantially while the physical location remains intended to stay the same. That is fundamentally different from translating a sentence.
If the target workflow requires local-grid coordinates, use approved GIS tools and transformations. Record the source CRS, target CRS and operation. Do not ask a linguist to “translate EPSG:4326 into the local EPSG code” as though one identifier were a bilingual synonym.
21. Transformation choice can affect accuracy
Two CRSs can have more than one possible transformation between them, with different areas of use, accuracies, required grids or time-dependent behavior. A simple code-to-code conversion request can therefore hide important engineering decisions.
Translation should preserve any stated operation name, accuracy and area-of-use notes. If the source does not specify the transformation, do not invent one in the target text.
22. Area of use matters
A CRS or transformation can be designed for a particular country, zone or region. Applying it outside that area may reduce accuracy or become inappropriate. The EPSG Dataset records scope and area information precisely because geodetic objects are not universally interchangeable.
Translate area descriptions for readers, but preserve the registered identifiers. A target-language map produced for another country does not automatically justify changing the CRS of the source dataset.
23. Deprecated EPSG objects are not automatically wrong historical data
The EPSG Dataset can deprecate records when better definitions or replacements become available. A historical project can legitimately contain a deprecated identifier because that was the CRS used at the time.
Translation for archival or evidentiary purposes should preserve the historical code. A new operational system may choose to migrate, but that change belongs in geospatial data governance with an explicit mapping and validation process.
24. Dynamic datums introduce time into coordinate meaning
Modern geodesy can use dynamic reference frames in which coordinates change with tectonic motion. The EPSG data model follows modern ISO 19111 concepts including dynamic datums. In precise work, a coordinate epoch can therefore matter alongside the numerical coordinates.
Do not omit an epoch because it looks like an ordinary date unrelated to position. For high-accuracy surveying or scientific data, the time reference can be part of the geospatial meaning.
25. Coordinate epoch is not survey date, though they can be related
A survey can be observed on one date and coordinates can be expressed at a defined coordinate epoch. Treating every date in a geodetic file as the same kind of date can produce conceptual errors.
Translate labels such as observation date, realization epoch and coordinate epoch precisely. Preserve their values and relationships. This is another example of why vocabulary is part of data integrity.
26. Vertical CRS is separate from horizontal position
A latitude-longitude position does not by itself define elevation. Heights can be ellipsoidal, orthometric or referenced to a local vertical datum. A map can therefore have correct horizontal coordinates and wrong height interpretation.
Translate height, elevation, altitude and depth carefully. Preserve the vertical CRS and units when supplied. Do not convert a vertical datum name into a generic phrase such as “sea level” unless that is technically correct.
27. Geoid and ellipsoidal height are different concepts
GNSS receivers can produce ellipsoidal heights, while many practical elevations are referenced through gravity-related surfaces or national vertical datums. A geoid model can participate in conversion between height types.
Translation should not simplify every height into “altitude.” A wrong target term can lead a technician to compare values that use different reference surfaces.
28. Compound CRSs join horizontal and vertical reference
Some applications need a horizontal CRS and a vertical CRS together. A compound CRS formalizes that combination. A translator should not drop the vertical component because the horizontal code is more familiar.
In metadata tables, preserve every component identifier and translate only descriptive labels. Automated QA should compare the complete compound reference, not just the first EPSG code that appears.
29. WKT is structured geospatial syntax, not prose
Well-Known Text for coordinate reference systems provides a structured representation of CRS and coordinate-operation definitions. OGC publishes the WKT-CRS standard. WKT strings contain keywords, names, parameters, units and identifiers in a formal grammar.
Do not run an entire WKT block through ordinary machine translation. Human-readable name strings may have controlled localization uses, but keywords and structural syntax must remain valid. One changed bracket, comma or keyword can make the definition unreadable by GIS software.
30. PROJ strings and pipeline definitions are code
Geospatial tools may represent CRS or transformations with PROJ syntax and pipeline parameters. Those strings are executable configuration, not natural language. Translating parameter names or decimal punctuation can alter results.
Protect the complete expression and translate the explanation around it. If the pipeline itself must change, treat that as a geospatial engineering change with numerical tests.
31. File metadata can be more important than the visible map
A shapefile, GeoPackage, raster, CAD export or database table may carry CRS metadata separately from the map labels. Translating a legend without preserving the metadata can leave the picture readable while making the dataset unusable.
Inventory metadata before translation. Protect CRS identifiers, units, coordinate order and transformation notes. Human-facing titles and layer descriptions can then be localized safely.
32. Sidecar files should not be treated as disposable
Some geospatial formats use companion files to store projection or coordinate-system information. A translation delivery that copies only the visible data file can accidentally omit the spatial reference.
Preserve the complete dataset package and its filenames unless the format specification allows a controlled rename. Translation is not an excuse to break file associations.
33. Layer names can be translated; stable IDs should not be
A GIS project may have a machine layer ID and a user-visible title. The title can be localized to help the reader. The ID should remain stable if styles, joins, scripts or external systems depend on it.
This mirrors the broader translation principle: human labels are flexible, machine identity is not. Keep the two fields separate so a language change does not break references.
34. Place names are a separate translation problem from coordinates
A map can show a translated or locally preferred place name while the coordinates remain unchanged. Exonyms, endonyms, transliterations and official naming policies belong to cartographic language, not coordinate transformation.
eduKateSG already has a separate geospatial localization owner for maps and place names. This article stays narrowly responsible for CRS, coordinate and geodetic reference identity to avoid cannibalizing that broader localization intent.
35. Map legends and symbology can be localized without moving features
Legend text, classification labels and explanatory notes are language. Their translation should not alter feature geometry or CRS. A road remains on the same path even when its category name changes language.
Separate style resources from spatial data. This lets one geometry dataset support multiple languages without duplicating or transforming coordinates unnecessarily.
36. CSV coordinates need schema-aware handling
A CSV may contain id, latitude, longitude, easting, northing, epsg_code and description. Only the description may need linguistic translation. Automatic spreadsheet localization can change decimal separators, strip signs or reinterpret coordinate values.
Lock coordinate and CRS fields, translate language columns, then rejoin by stable ID. Validate numeric ranges and preserve column order expected by the importing GIS.
37. GeoJSON and APIs have format-specific coordinate rules
Web spatial formats can define coordinate ordering and reference assumptions. Translators should not reorder arrays to match how people say “latitude, longitude.” Array position is machine syntax.
Translate properties intended for users, not geometry coordinates or schema keys. Validate the JSON after localization and render sample features on a map to catch catastrophic coordinate-order errors.
38. Spatial databases need CRS metadata at column level
A database can store geometries with a spatial reference identifier and enforce rules at column or geometry level. Renaming a human-facing table title should not change the spatial reference expected by queries.
Keep database schema and CRS identifiers under engineering control. Translate documentation and interfaces that describe them. Never migrate spatial reference IDs merely to make target-language metadata look more local.
39. CAD and BIM workflows often mix local and global grids
Construction projects may use a local site grid for design and a national or global CRS for survey control. A translated drawing note that drops the distinction can cause coordinates to be applied in the wrong frame.
Preserve grid names, control-point references, scale factors, rotation and transformation instructions. Translate the explanatory language, but keep the numerical transformation parameters under engineering verification.
40. Survey control points are evidence, not decorative map annotations
Control points can have identifiers, coordinates, monument descriptions and quality information. Translating the description is useful; changing the point ID or coordinate values is not.
Use stable keys to keep each translated description attached to the correct control point. Relational integrity matters as much as character-level accuracy.
41. Remote-sensing imagery has its own spatial metadata
Satellite and aerial imagery can include CRS, geotransform, pixel size, acquisition time and sensor metadata. A translated report may discuss these values while the raster itself depends on them for correct placement.
Protect spatial metadata during file processing. Do not assume that translating a companion report is enough if the delivery pipeline also rewrites metadata fields.
42. Machine translation should mask CRS syntax and coordinates
Large language models and translation engines can alter punctuation, decimal separators, capitalization or identifier formatting. That is unacceptable inside WKT, EPSG codes, coordinate tuples or transformation parameters.
Protect those tokens before translation and restore them from the source-controlled data layer. Then compare source and target geospatial token sets automatically.
43. Translation memory can inject coordinates from the wrong feature
Repeated survey sentences such as “Point A is located at…” can produce high translation-memory matches containing an old coordinate. Accepting the whole segment can move the target location while every word remains fluent.
Treat coordinate values and point IDs as variables. Populate them from the current source rather than translation memory. Search the target for coordinate strings that do not occur in the current dataset.
44. Generative AI must not infer a missing EPSG code
If a source shows plausible latitude-longitude values but no CRS, a model may guess WGS 84. If eastings resemble a familiar national grid, it may guess a local EPSG code. Those guesses can be useful hypotheses and are not evidence.
Preserve uncertainty, inspect metadata, ask the data owner or compare known control points. Do not publish a guessed CRS as fact. One incorrect reference system can shift an entire dataset.
45. Automated QA should test geometry in addition to strings
Source-target comparison can detect changed EPSG codes and coordinate tokens, but map rendering adds another valuable check. Plot sample points or layer bounds after localization. A swapped axis or wrong CRS often becomes visually obvious immediately.
For transformations, test known control points and expected tolerances. Geospatial QA should measure position, not only spelling.
46. Worked example: EPSG:4326 versus EPSG:3857
A web application receives WGS 84 geographic coordinates and displays them on a Web Mercator basemap. The user-facing map label is translated into Spanish. The application may transform coordinates for rendering, but the source dataset remains documented as EPSG:4326.
The translation does not rename the source CRS to EPSG:3857 merely because that is what the map canvas uses. Data CRS and display CRS remain distinct.
47. Worked example: UTM zone loss
A survey table lists easting 450000 and northing 151000 in a named UTM CRS. A translated spreadsheet copies the numbers but omits the zone column to save space. The target now contains coordinates that can map to many possible places.
The correct translation preserves zone or the complete CRS identifier. Brevity must never remove the metadata that makes numerical coordinates meaningful.
48. Worked example: decimal comma collision
A French-language CSV export displays 103,8198 as a localized decimal. The same comma is also the field separator, so downstream software splits the coordinate into two columns. The linguistic localization has corrupted the geometry.
The fix is architectural: canonical machine data follows the file specification, while a separate human report can use localized number formatting. Do not make one file serve incompatible parsing and presentation rules.
49. Worked example: axis-order misunderstanding
A source form labels fields “Latitude” then “Longitude.” A developer sees a target-language phrase that naturally mentions longitude first and reorders the JSON array to match. The point moves to another location because the API expected a fixed coordinate order.
Translate labels independently from data structure. Word order in language does not authorize array reordering.
50. Worked example: vertical datum confusion
An engineering report says a platform elevation is 12.4 m in a specified local vertical datum. A translator simplifies this to “12.4 m above sea level.” That sounds natural but can be technically inaccurate because the datum has a specific realization and reference.
Preserve the formal datum name and translate explanatory text around it. Precision in terminology protects precision in engineering.
51. Vocabulary control is part of spatial accuracy
Useful terms include coordinate reference system, datum, reference frame, ellipsoid, projection, geographic CRS, projected CRS, easting, northing, axis, unit, coordinate operation, transformation, area of use, coordinate epoch, vertical datum and geoid.
The protected Vocabulary Learning Hub supports concept precision, while this article remains responsible for geospatial-reference translation. A glossary should define concepts and relationships, not just provide one-word bilingual pairs.
52. Grammar matters in coordinate instructions
“Transform from A to B,” “transform B into A,” “coordinates of points in grid A” and “coordinates transformed using grid A” can encode different roles even though they share the same nouns. A reversed source-target direction can invalidate an entire workflow.
The How English Works ecosystem helps with this language layer: parse which CRS is source, which is target and what operation is being described before translating the sentence.
53. Reference route: the EPSG Geodetic Parameter Dataset
For authoritative EPSG definitions, use the EPSG Geodetic Parameter Dataset. It is maintained by IOGP and follows the modern ISO 19111 geodetic data model. Important projects should verify identifier status, area of use, units and transformations against the current dataset.
Do not treat random online code lists as equivalent to the maintained registry, especially when deprecated objects or high-accuracy transformations are involved.
54. Reference route: OGC WKT for coordinate reference systems
For structured textual CRS definitions, use the OGC Well-Known Text representation of coordinate reference systems. WKT is formal geospatial syntax. It should be handled with standards-aware tools rather than ordinary prose translation.
If a target document needs to explain WKT components, translate the explanation outside the machine string and preserve the parsable definition for software.
55. Connection to the master translation architecture
This specialist owner sits beneath eduKateSG’s Master Art of Translation — Technical Translation System. The master owns specifications, terminology, standards and QA. This page owns a narrower intent: keeping coordinate and CRS meaning stable while geospatial language changes.
It also remains distinct from the existing map and place-name localization owner. Labels can change language; spatial reference must remain traceable.
56. Release checklist
Before release, identify every source CRS; preserve EPSG codes; distinguish geographic and projected coordinates; verify units; protect axis order; retain UTM zone and hemisphere; preserve datum and epoch information; separate horizontal and vertical reference; lock WKT and PROJ syntax; inspect decimal separators; protect coordinate fields from translation memory; compare source-target coordinate tokens; render sample data; and verify transformations against known points or authoritative tools.
Then review the human language: layer names, legends, geodetic terminology, instructions, notes and place labels. Spatial QA and linguistic QA are separate disciplines that meet in the same multilingual product.
57. Final rule: translate the map language, not the Earth beneath it
Good geospatial translation lets people understand a dataset in their own language while every coordinate still refers to the intended place. Preserve the CRS, units, axis meaning, datum, transformation context and numerical evidence. Localize labels and explanations for humans. When a coordinate transformation is genuinely required, perform it as a controlled geospatial operation. Language can move across cultures; the mapped feature should not move across the planet.