For the last couple of months, I've been working on a side project that's heavily reliant on using geographical coordinates.
Before I started working on the project, I thought that all coordinate formats were the same, with Google maps being the standard. However, I shockingly learned that there are hundreds of geospatial systems discovered a whole new world full of pain, abbreviations, unknowns, and more abbreviations.
The reason for so many different standards is quite simple, and has been perfectly summed up byxkcd:
All of the different standards and systems have a different approach to the same problem: how to present the surface of the Earth.
In this post, I'll take a shallow dive into geographic coordinate standards and systems to explain the differences between them and introduce the most popular ones. Then I’ll build on that knowledge to talk about GeoJSON to help you choose the right tools for your project.
Why are there so many coordinate systems, and why do we need them?
There are four main factors to every coordinate system: an ellipsoid model, a horizontal datum, a vertical datum, and units. The differences often depend on the map's purpose — a map for military missions at sea should optimize for different factors than a cadaster.
An Ellipsoid Model
As the Earth is not perfectly spherical, a map needs to create a model of an ellipsoid that approximates the Earth's curvature. Various systems differ based on the shape of this ellipsoid — the radius at the equator and the flatness at the poles are two main variances.
A Horizontal Datum
The coordinates often used to describe the precise latitude and longitude and the horizontal datum is how a coordinate system lays out these two axes. Most horizontal datums define a zero line at the equator to measure north and south (latitudes), and the Greenwich Meridian to measure east and west (longitudes).
A Vertical Datum
The vertical datum is closely related to the ellipsoid's model, as it describes the altitude or elevation of a position. The vertical datum is a surface of zero elevation to which heights of various points are referenced.
Units
In geographic coordinate systems, the units are typically represented in degrees, minutes, and seconds for latitude and longitude (eg. 18° 16′ 31” E and 52° 19′ 21” N) and in meters or feet for for altitude or elevation. The projected systems, on the other hand, use x and y coordinates instead of latitude and longitude (eg. 18,163111 and 52,192129).
The Three Most Common Coordinate Reference Systems
Knowing the standard of the data that you're planning to use is important, as different mapping services operate on different systems that are known as coordinate reference systems (CRS). The three most common systems are WGS84, EPSG:4326, and EPSG:3857. Knowingly, or unknowingly, all web developers will come across these.
WGS84 and EPSG:4326 are geographic CRS. It means that they use latitude and longitude coordinates to specify a location on the surface of the earth. EPSG:3857, on the other hand, is a projected system that uses a flat, two-dimensional plane to represent the Earth's surface and x/y coordinates instead of latitude/longitude in a process called projection.
World Geodetic System 1984 (WGS84)
World Geodetic System 1984 (WGS84) is the most popular CRS. It is used as the default for GPS coordinates, and is widely used in mapping, GIS applications, and for military purposes. WGS84 uses a three-dimensional ellipsoidal model of the Earth, with positions that are defined using latitude, longitude, and altitude coordinates.
WGS84 serves as a base in two widely used projected coordinate reference systems: EPSG:3857 and EPSG:4326, which use different projection methods and have different properties.
EPSG:3857
EPSG:3857, also known as Web Mercator projection, is a projected CRS commonly used for online maps and web mapping applications. It is based on the WGS84 geographic CRS, but uses the Mercator projection to map the Earth's spherical surface onto a flat, two-dimensional plane.
The Web Mercator projection is a variant of the Mercator projection that shows the world as a square, while the typical Mercator projection is cylindrical. This square can be thought of as a pixel, making it useful for web small-scale mapping.
It rose to prominence with the Google Maps adoption in 2005, and its currently used by most web mapping applications, including CARTO, Mapbox, Bing Maps, OpenStreetMap, and Esri. In practice, this means that if you’re making a web map featuring the tiles from services such as Google Maps or Open Street Map, they will be in Spherical Mercator EPSG:3857 and therefore your map has to have the same projection.
If you're working with data that covers a small area and you need to preserve the shape of the features, then EPSG:3857 might be the right choice.
EPSG:4326
EPSG:4326, also known as the WGS84 projection (because it’s based on WGS84’s ellipsoid), is a coordinate system used in Google Earth and GSP systems. It represents Earth as a three-dimensional ellipsoid. As it’s not using the projection, it doesn't have the distortion issues of the Web Mercator. If you're working with data that covers a large area or for which accuracy over small areas is not critical, then EPSG:4326 will typically be an appropriate choice.
WGS84 vs EPSG:3857 vs EPSG:4326
| Type of CRS | Common Use Case | Reason for Popularity | Short Characteristics | |
| WSG84 | Geographic | Provides a standard for Earth's geometric shape and gravity field | The most common standard, intended for global use | It provides a reference ellipsoid (a mathematical model of the Earth's shape) and the location of the origin (the point where the coordinates are set to zero) |
| EPSG:3857 | Projected | Online mapping systems | Good for working with data that covers a small area and when you need to preserve the shape of the features. Doesn’t work well at scale | Uses a mathematical projection to map the Earth's curved surface onto a flat, two-dimensional, square plane |
| EPSG:4326 | Geographic | Standard coordinate system based on WGS84, used in GPS | Good system for mapping applications that require accurate representation of the Earth's surface at large scale or shape | Represents the Earth's surface as a three-dimensional WGS84 ellipsoid |
Converting Between Systems
My side project is focused on the city of Kraków, Poland, where I'm from. For the development, I've been using public information on multiple parcels around the city. This is how I came to learn that countries have their own projected coordinate reference systems! Polish public information follows a different system than, say, Germany; not to mention a system that's unusable by any big map provider. In my case, it uses PUGW-1992.
In order to use PUGW-1992 coordinates, I needed to convert them to WSG84, then use EPSG:3857 with OpenStreetMap. I spent a lot of time trying to figure out the conversion on my own before finally settling for an online converter, and found a way to automate providing the input to some extent.
In mapping projects, this area often contains the most risk or unknowns. My best advice for you, especially if working from an obscure data source, is to invest early in understanding the data standard and checking how difficult it will be to convert into a widely supported and well-documented system. In case of precise maps, check if the conversion will lead to any losses — and if it does, determine whether those losses are acceptable. Also check the community support and do a quick browse to see how much you can learn about that type of data before you commit to it. It might turn out to be unusable or too time-consuming for your purpose.
GeoJSON
Lastly, as a developer learning about web mapping, you will inevitably come across the GeoJSON format, used by both Google Maps and Leaflet.
GeoJSON is a format for encoding a variety of geographic data structures, based on JavaScript Object Notation (JSON). A GeoJSON is essentially a JSON file that contains an array of geographic features, where each feature is represented by a JSON object. Each feature has a "geometry" property that describes the shape of the feature (point, line, polygon, etc.) and a "properties" property that contains the nonspatial attributes of the feature. GeoJSON uses a geographic coordinate reference system, WGS84, and units of decimal degrees.
To see it in practice, go togeojson.io, select an area or point, and inspect the newly created GeoJSON object.
Because GeoJSON uses the WGS84 format, so does the online tool, and that's great news because these coordinates can be used on other platforms that use it — like Google Maps and Leaflet. However, if you go on and put the coordinates into Google Maps or Leaflet, you won’t find yourself in London, but in the Indian Ocean.
It’s all because GeoJSON uses lng-lat notation, while Google Maps and Leaflet use lat-lng. And funnily enough, the community doesn’t seem to see a problem with it.
When I first spotted it, I wrote a small program that swaps the order in the nested coordinates array. It wasn’t hard, but with the tests and deployment, and placing it within my system that was already handling a PUGW-1992 to WSG84 conversion, it did take a bit of time. I wish I could stop myself right there to read more about GeoJSON.
GeoJSON is a very popular format, with good documentation and wide community support. And all I needed to do was call coordsToLatLng() in case of Leaflet, while for Google Maps the loadGeoJson already does the reversing for you. It didn’t feel great to learn it after I’ve already done the work, but I hope I’ll save you some time.
Was It Fun?
So you might be wondering if this project was fun. The “fun” of working with obscure geographical data standards was questionable. I experienced a lot of frustration as nearly every public data source I’ve used provided data in a different format. I wish I thought my product through more when designing it, accounting for the complexity and possibly limiting its scope so that I needed to use fewer data sources. What helped me a lot was learning about these different standards and systems, why they matter, and how they differ. It at least helped me understand why the different sources use different formats, which in turn helped reduce the extreme frustration to medium frustration.
Once I did the conversions and had my data in GeoJSON, working with Google Maps and Leaflet was a bliss and I’d be more than happy to apply my experience from the side-project to some real-life challenges.
