• Mitchell Bosecke

Introduction to Coordinate Reference Systems for Software Development

Believe it or not, but the world is round and your computer monitor is flat. This is very significant when you're developing software that displays geospatial data onto a two-dimensional screen.

A coordinate reference system (CRS) defines the unit of your data and whether your data is three-dimensional or two-dimensional. Coordinates without a defined system are completely useless.

Geographic coordinate systems are those that represent data on a three-dimensional Earth whereas projected coordinate systems are those that represent the same data but transformed onto a flat plane. One of the largest challenges with geospatial data is that every time you project three-dimensional data onto a two-dimensional surface, you are introducing a certain degree of distortion and you can not escape from this fact.

Projected coordinate systems might encompass the entire world, or they might only encompass a small subset of the world (ex. a country or a province/state). Because they aren't dealing with a sphere, they can choose their own bounds. The smaller the projected coordinate system, the less it distorts the data.

I'll walk you through some of the most common systems that you'll use when developing geospatial applications.

EPSG Identifiers

There are several ways of identifying a coordinate reference system, but the majority of open source tooling (PostGIS, QGIS, GeoServer) use EPSG identifiers. These are predefined identifiers in the format of "EPSG:1234".


This is a projected coordinate system that is used by the majority of web-based maps, including Google Maps and OpenStreetMap. It represents two-dimensional data on a flat surface (your computer screen) and the unit of measurement is meters.

If you are building a web-based map, this is the recommended CRS.


This is a geographic coordinate system that is used by GPS. It represents three-dimensional data on Earth and the unit of measurement is degrees (i.e. latitude and longitude).

The CRS is not projected onto a two-dimensional surface so it doesn't introduce distortion of your data, therefore it's a great system to store raw data. The downsides of storing your data in a geographic CRS is that it could be more computationally expensive to perform complex queries.

Confusingly, if you store your data as EPSG:4326 (i.e. three-dimensional and not projected) and try to view it in QGIS (i.e. on a two-dimensional screen), it will successfully display it without issue. It accomplishes this by secretly projecting the data on-the-fly into a projected CRS called Plate-Carrée. It's important to keep in mind that you're not truly looking at the raw data anymore, but a very close representation. Some people also try to build web-maps using EPSG:4326 but again, they're actually using the Plate-Carrée projection.


UTM coordinate systems are a collection of projected systems that were calculated by vertically slicing up the earth on the lines of longitude. It isn't one single system, it's a collection of them. They are numbered using the lines of longitude, so there is UTM 11 (EPSG:26911), UTM 12 (EPSG:26912), UTM 13, (EPSG:26913), etc. Often, these will be referred to as "UTM Zones". I find a lot of companies and analysts will store their data in a UTM system because their data happens to fall within a single zone. They want the performance of a projected CRS and they can accept the minor distortion. However, this usually bites them in the ass one day when they suddenly have a data point outside of their zone.

I don't recommend storing or displaying data in UTM coordinate systems because they don't future-proof your applications. Just be aware that they exist and are common.

Provincial + State CRS

A lot of provinces/states have their own projected CRS that can be used for data that falls within their political boundaries. It's common for governments to publish datasets using their own CRS. Similar to UTM, the reasoning for storing data in these projected systems is to gain a bit of performance while sacrificing a bit of accuracy.


Adding data into your spatial database requires choosing whether your data is geographic (three-dimensional) or geometric (two-dimensional) and the associated CRS with it.

create table my_spatial_table as (
  id bigserial primary key,
  geographic_data geography(point, 4326), -- EPSG:4326 (recommended)
  geometric_data geometry(point, 26911) -- UTM 11

With geometric data types, you can transform them from one CRS to another:

-- Transforms from the original UTM 11 to EPSG:3857
select st_transform(geometric_data, 3857) from my_spatial_table;


Store your data with a geographic CRS (EPSG:4326) and publish it using a projected CRS (EPSG:3857).

If you want to sacrifice accuracy for performance, I recommended continuing to store your data with EPSG:4326 but also introduce a second column to track it as a projected geometry. That way you can always refer back to the original data when necessary. For the projected column, choose the smallest projection that will encompass all of your data to minimize distortion; often a provincial/state CRS is a good choice here.


Dimetric is a cloud-native infrastructure that allows you to upload your geospatial data using your CRS of choice, and provides sample code to publish a web map in the recommended EPSG:3857 CRS. We focus on developer-friendly APIs and industry-standard best practices.

125 views0 comments

Recent Posts

See All