A Guide for Developers Traveling Through OpenLayers - 3. Coordinate Systems
A Guide for Developers Traveling Through OpenLayers - 3. Coordinate Systems
In 1986, NASA launched the space shuttle Challenger, but it tragically exploded roughly 73 seconds after launch.
The cause, absurdly enough, was a unit mistake. Even though the international standard is the metric system, the United States and a few other countries used the imperial system as their standard. Under these circumstances, the O-ring, a component specified in metric units on the spacecraft's design drawings, was manufactured using imperial units—and that mistake caused the accident.
On a smaller scale, we can commonly see problems caused by units even back in our school days. If you were a science-track student, you probably have the painful memory of getting a math or science exam question marked wrong—even though the value itself was correct—because you either omitted the unit or wrote the wrong one.
This shows us just how important units are. A single unit can completely change how a value—that is, the meaning of the data—gets interpreted.
Geospatial data has a unit of its own called a coordinate system. There are countless coordinate systems in geospatial information, and if you plug in the wrong one, an entirely different position gets calculated.
In other words, if the coordinate system is entered incorrectly, navigation could point somewhere completely wrong, or a missile could strike an unintended location. That's why the coordinate system is one of the most crucial elements in geospatial information.
Even the coordinates most people think of, like east longitude 127, north latitude 37, are just one of countless coordinate systems. East longitude 127, north latitude 37 is expressed in WGS-84, one of the world geodetic systems commonly used by GPS. As you can see, the values represented differ depending on the characteristics of the coordinate system, and to distinguish between them, they're managed using EPSG codes like EPSG:0000.
The code for the WGS-84 mentioned just now is EPSG:4326.
| EPSG Code | proj argument |
|---|---|
| EPSG:4326 | +proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs |
This kind of system is called a coordinate system, and formally it's referred to as a Projection. A projection consists of an EPSG code and proj arguments.
The EPSG code is the name of the coordinate system, and the proj argument is a formula expressing the coordinate system, starting with +proj=. This proj argument is used both to represent the coordinate system and to convert between coordinate systems.
An SHP's prj file contains this projection information.
Most data providers supply the coordinate system for the geospatial data they offer, so you must always check this before using the data. Occasionally, providers fail to specify the coordinate system, or specify it incorrectly, so be careful.
Coordinates express a current location as a specific value. Since the Earth is roughly a sphere, in order to represent coordinates accurately, we need to define the shape of that sphere.
The Earth is sphere-shaped, but it's not, strictly speaking, a perfect sphere. Well, that's not to say it's flat, either.
It would have been nice if it were a beautiful sphere, but unfortunately, the Earth's shape has quite a few quirks. It's borderline awkward to even call it a sphere. Some people even call it potato-shaped.
In any case, since it's not a perfectly spherical shape, we can't apply sphere formulas directly when calculating coordinates—various corrections are needed.
What defines the Earth's shape while reflecting this reality is called an ellipsoid. As is typical with concepts like this, the ellipsoid used varies by coordinate system, and its characteristics change depending on which ellipsoid is used.
- GRS80: The global ellipsoid standard. Adopted by the International Union of Geodesy and Geophysics.
- WGS84: An ellipsoid defined by the United States for use in developing military GPS.
- GRS80 and WGS84 are nearly identical, with only an extremely small difference of about 0.01mm in the semi-minor axis.
- BESSEL: An ellipsoid defined based on a specific region. It's very accurate within that specific region, but the error grows the farther you get from it. It's mainly used for data intended for use only within a specific area.
- Due to the influence of the Japanese colonial period, South Korea used to use the BESSEL ellipsoid, defined relative to Tokyo, before switching.
If you look into information related to ellipsoids, you'll come across the keyword ITRF-2000. ITRF-2000 isn't a single defined ellipsoid, but rather the name for the world's common ellipsoid. In other words, as of now, it's the same as GRS80.
Before the emergence of the remarkable GPS technology, the BESSEL ellipsoid—which defines an ellipsoid centered on each individual region—was widely used. That's because before GPS technology, there was no means or technology to define an ellipsoid for the entire world.
As mentioned above, Korea, due to the influence of the Japanese colonial period, came to use the BESSEL Tokyo ellipsoid through a national land survey project carried out by Japan.
EPSG:2096 (East), EPSG:2097 (Central), EPSG:2096 (West), and so on fall into this category, and if you look through older geospatial data, you may find these coordinate systems still in use.
Fortunately, the standard has since been switched to a coordinate system based on the GRS80 ellipsoid for the sake of international standardization. EPSG:5180 (West), EPSG:5181 (Central), EPSG:5183 (East), described further below, fall into this category.
Picture a map in your head. Doesn't matter whether it's paper or an app. Think about it—the Earth is a sphere, but a map is flat. Of course, there are globes that faithfully preserve the Earth's shape, but nowadays a globe belongs more to the category of interior decoration than location-finding. I can say with confidence that nobody here is going to peer at a globe to find a location.
That means that in order to create the maps we're familiar with, we need a process that flattens a sphere. Do you remember learning the concept of "unfolding" (net diagrams) back in math class as a kid? Think of it as similar to completely unfolding a milk carton.
In coordinate systems, this process of flattening a sphere is called a projection method.
- TM (Transverse Mercator): a planar coordinate system projected based on the BESSEL ellipsoid
- UTM (Universal TM): a planar coordinate system projected based on the GRS80 (or WGS84) ellipsoid
- UTM-K: since standard UTM is based on the equator, it produces some error relative to Korea. UTM-K corrects for this and is defined to suit Korea.
- The UTM projection is based on the GRS80 ellipsoid, but a few of the UTM-K coordinate systems use the BESSEL ellipsoid instead. The exact reason for this is unknown.
If you look at coordinate systems, you'll notice they're split into Central, East, and so on—this is because the reference points were divided to minimize error.
In the process of defining an ellipsoid and flattening it, in order to minimize the error that arises, a projection reference point is chosen, and the projection is performed relative to that location. South Korea has East, Central, West, and Jeju origin points (there may be more), and each region's coordinate system is projected relative to its region's survey reference point.
Geospatial information provided at the city/county or local government level, rather than the national level, is typically provided based on whichever coordinate system is best optimized for that particular location. For example, Jeju-related data might use the Jeju origin, while data provided by Gangwon Provincial Office might apply the East origin.
Honestly, whether it's an ellipsoid or a projection method doesn't matter all that much. As long as you know which coordinate system your own data uses, you can use it without any issue. That's because regardless of the ellipsoid or projection method, every coordinate system is managed in the form EPSG:0000. Just knowing the EPSG code of the coordinate system you want is enough for basic use, with no problems whatsoever.
Each coordinate system has a matching EPSG code and proj argument. The proj argument is essentially a formula representing that coordinate system, and it's what allows coordinate system conversion operations to be performed. If you understand proj, you can interpret what characteristics a given coordinate system has just by looking at its arguments.
| Parameter | Meaning |
|---|---|
| proj | Projection |
| a | Semi-major axis (the longest radius of the ellipse) |
| b | Semi-minor axis (the shortest radius of the ellipse) |
| lat lon | The coordinate system's reference latitude/longitude |
| x y | The coordinate system's reference xy |
| k | Coordinate system scale factor |
| ellps | Ellipsoid type |
The rough set of parameters is as above, and for lat, lon, x, y, the meaning can shift slightly depending on what suffix follows, as in lat_ts or x_0.
Knowing roughly this much lets you get a vague sense of what a given coordinate system's arguments mean, and for a developer who just wants to use a coordinate system in a simple way, you don't need to know any more than this. Actually, you don't even need to know this much to use it without issue.
There's absolutely no need to memorize every coordinate system or to memorize proj arguments. That said, knowing the coordinate systems you commonly use can make it a lot easier to understand your data.
| EPSG Code | proj argument | Notes |
|---|---|---|
| EPSG:3854 | +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +no_defs | Google Maps, VWorld |
| EPSG:4326 | +proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs | GPS |
Take a look at EPSG:4326, the WGS84 world geodetic system. Its semi-major and semi-minor axes are both 6378137, aiming for a perfectly spherical shape. Fittingly for a GPS-based coordinate system, there's no correction applied to the latitude/longitude or xy values. proj=merc means the Mercator projection was used.
As an aside, EPSG:3857 uses longlat as its projection, which differs from commonly used planar projections like TM and UTM, so distance calculations don't work correctly with it.
In other words, even if you calculate the distance between two points expressed in EPSG:3857, that value doesn't represent the actual real-world distance.
| EPSG Code | proj argument | Notes |
|---|---|---|
| EPSG:5179 | +proj=tmerc +lat_0=38 +lon_0=127.5 +k=0.9996 +x_0=1000000 +y_0=2000000 +ellps=GRS80 +units=m +no_defs | NAVER Map |
| EPSG:5181 | +proj=tmerc +lat_0=38 +lon_0=127 +k=1 +x_0=200000 +y_0=500000 +ellps=GRS80 +units=m +no_defs | KAKAO Map |
| EPSG:5186 | +proj=tmerc +lat_0=38 +lon_0=127 +k=1 +x_0=200000 +y_0=600000 +ellps=GRS80 +units=m +no_defs | Central origin |
There are several other coordinate systems besides these, so just look them up and use them as needed.
You can check information for a wide variety of coordinate systems at EPSG.io, so give it a look.
※ Thanks to everyone who kindly corrected mistakes in this article.
