Google Web Mercator: an ambiguous coordinate system

    On October 1, 2014, the US National Geospatial Intelligence Agency ( NGA ) published a report criticizing the Web Mercator coordinate system used in a variety of web-based map services. Attached is a detailed explanation of the problem and recommendations for NGA partners. The document received a great response, but not all articles based on this report were distinguished by their accuracy and literacy. This applies, for example, to articles on the GIS Association website, which, due to gross errors in terminology, can be considered illiterate. Since web service developers are faced with this coordinate system most often, I think it makes sense to sort out the problem.

    What are you talking about?

    To begin with, a couple of definitions, without which some details cannot be clear. It is important to understand that Web Mercator is a coordinate system, and not just a projection, although its name resembles the Mercator projection known to many. It is this terminological discrepancy that misleads the readers of the article on the GIS Association website. The difference between the projection and the coordinate system is that the projection is only the way in which the complex shape of the model of the Earth’s figure unfolds on the plane, while the coordinate system also includes the mathematical definition of a model (ellipsoid or spheroid) that approximates a complex figure of the Earth.

    Red indicates that only applies to projection

    In this illustration, red indicates what applies only to the projection mechanism (in this case, cylindrical). To the coordinate system, in general, everything that is depicted here applies.

    In turn, it is this very approximating model of the surface (the dotted sphere in the figure above, on which the coordinates λ, φ are determined ) that is the source of the problem, which will be discussed later.

    History

    I can’t say for sure who was the first and when it all occurred to me. But, as far as I know, the first major project that began to use the Web Mercator coordinate system was the Google Maps service, and this happened in 2005. The developers then faced the task of simplifying the calculations necessary for working with cartographic data, and the most obvious thing that could be done was to use a sphere instead of an ellipsoid in the coordinate system. It is interesting that Gerard Mercator himself most likely proceeded from the same geometric representations, creating his own way of projecting maps onto a plane, because only Newton, who lived a little later, proposed the hypothesis that the Earth, due to centrifugal force, has the shape of an ellipsoid of revolution , not a ball. Thus, Google developers, in a sense, returned to the sixteenth century.

    This is not the first time that criticism of this approach has been heard in professional circles. Since 2005, the European Petroleum Survey Group (EPSG), a standardization company in the field of coordinate systems and holding a registry of their identifiers - EPSG codes - has refused to assign its own official code to the Web Mercator system, citing its obvious geometric imperfection. Therefore, on the network you can find links to this system through unofficial codes: EPSG: 900913, EPSG: 102113 and others. However, in 2008, this organization had to surrender and assign a code, as the popularity of the system grew, and it had to be somehow unambiguously designated so as not to give rise to even greater anarchy. The first attempt to define the system was not entirely successful, but in the end it was assigned the official SRID EPSG: 3857.

    Algebra

    Since projections are a subject of study of mathematics, I will start with formulas, and then I will give them a graphic illustration. Strictly speaking, it is not even necessary to have good trigonometry to understand the difference between the implementation of coordinate systems based on the Mercator projection, a sphere in one case and an ellipsoid in another. The formulas vary markedly in appearance.
    The projection of the Mercator of the ellipsoid onto the plane is defined as follows:

    x = a × λ
    y = a × ln [tan (π / 4 + φ / 2) × ((1-e × sinφ) / (1 + e × sinφ)) ^ ( e / 2)]


    where:
    x and y are the rectangular coordinates,
    λ is the longitude on the ellipsoid in radians,
    φ is the latitude on the ellipsoid in radians,
    a is the semimajor axis of the ellipsoid,
    e- the value of the eccentricity of the ellipsoid (relations of the major and minor semi-axes).

    If a sphere is used instead of an ellipsoid, as it happens in the Web Mercator coordinate system, everything becomes much simpler, since the formula for the ordinates (Y axis) degenerates, giving the following:

    x = a × λ
    y = a × ln [tan (π / 4 + φ / 2)]


    Agree, it looks much simpler and shorter, which is what Google developers sought. This allows you to quite noticeably reduce the number of mathematical operations when working with cartographic materials in client and server applications.

    Geometry and Cartography

    Even if you don’t go into the formulas at all, simple illustrations demonstrate the essence of the problem quite well. First, I will explain that the principle of constructing the Mercator projection is that any point on the surface of an ellipsoid or spheroid is projected onto a cylinder inside which this ellipsoid is placed so that their vertical axes coincide and the surfaces either touch along one line (the most common case), or intersected in two. (See illustration above). Further, the conditional projection rays exit the center of the ellipsoid, intersect its surface at point P and fall on the surface of the cylinder at point P ', where the corresponding point of the Earth’s surface is transferred. It is easy to imagine that if the real surface of the Earth was first projected not onto an ellipsoid rather close to its shape, but onto an idealized sphere, then when projected onto the cylinder the points of the sphere, the same starting points of the Earth’s surface will be at a different distance from the line equator along the vertical axis than in the case of an ellipsoid.

    I’ll try to illustrate the scale of the disaster. Take the satellite image in natural colors of the Central Federal District of Russia in the NASA EOSDIS archive taken by MODIS Aqua with a resolution of 250 meters per pixel on September 21, 2014 (this day, because it was clear, it will be more beautiful) will be our background.

    Next, using Overpass Turbo request, we will unload the administrative boundaries of the Moscow Region in the GeoJSON format from the OpenStreetMap database. Request Code:


    Now, using the Global Mapper, we transform the data of the boundaries of the Moscow region from a geographical projection to the projection of the Mercator ellipsoid WGS84. And then, to simulate the situation when the coordinate system is not recognized correctly, copy the resulting data and manually change the definition of the coordinate system to Web Mercator. In reality, the opposite situation is more likely possible: data in Web Mercator can be mistaken for data in WGS84 / Mercator (this is more than possible because Web Mercator has a bunch of names, some of which have “WGS84”), but from In our imitation, it will differ only in the direction of the shift. Download the resulting data into the Global Mapper, overlay the grid with a step of 100 kilometers and see what happened.

    The boundaries of the Moscow region, combined with a deliberately incorrect interpretation of the coordinate system

    The green outline on the map is where you want it, and the red one is shifted. The magnitude of this shift is 19.6 kilometers. This does not mean that such an error exists in all map services using this coordinate system, not at all. But it will manifest itself if you take the data in this system and try to combine with other data without its correct accounting. In this case, an incorrect inverse transformation to geographical coordinates will be applied to it, which will lead to an error.

    Navigation

    Some map projections have special properties that are critical for solving navigation problems. The Mercator projection is one of them, because it is widely used to create marine and air navigation maps. This is possible due to such a geometric property of this projection as conformity. In this case, it means that the shape of objects of a sufficiently large size is saved on this map, since the values ​​of the angles between the lines are saved. For navigation, this means that looking at the map, you can calculate the direction to the desired point relative to the meridian (directions to the geographic north) and, moving in this direction along the magnetic compass or at a constant angle to the line to the North Star, find yourself in the right place. This path is called the “ Loxodrome.”And is not the shortest path between two points on the Earth’s surface, and modern navigation devices allow you to calculate the path along the“ orthodrome ”- the really shortest line, but you don’t refuse the Mercator projection, because the map made in it makes it possible to use in an emergency Navigational aids to navigate without relying on a GPS receiver and other electronics.

    And here the Web Mercator coordinate system is deceiving. Although it is based on the Mercator projection, the use of a sphere with a constant radius, as the ultimate simplification of the Earth’s surface model, deprives it of conformity. This means that moving with a constant heading angle, measured on such a map, you will not be able to get to the desired point due to distortion of the angles in this coordinate system. It would seem that this is not so important for web services, because no one in their mind will pave the way for them in an emergency. However, the variety of web services is great, and it is impossible to guarantee that one of the developers does not bother to consider any directions in this projection. When calculating in this projection, the error can accumulate very much. Plus, tools like CAC are now very popular. Planet,

    The magnitude of the problem in this case is also quite easy to measure. Take the same picture for the background, the same data on the position of the administrative border of the Moscow region. Now we need three lines: the orthodrome (the shortest taking into account the curvature of the Earth) and two loxodromes built in the Mercator / WGS84 and Web Mercator systems. We will build these lines between the southernmost point in Serebryanoprudsky district of the region, not far from the settlement with the funny name Mochily and the northernmost - in Taldomsky district.

    We will build an orthodrome. Now we measure its length (it turned out a little less than three hundred and seven kilometers) and the initial angle relative to the meridian. Next is the most interesting. We re-project the workspace into the Mercator projection and construct a line from the same starting point in this projection, setting the measured angle and length of 307 kilometers, without looking where it will go to the other end. We repeat the same thing, but in the coordinate system Web Mercator. Two loxodromes are ready. For clarity, we still find the center point on the orthodrome, dividing it in half and putting a marker in this place. We reprogram the workspace in the UTM 37N WGS84 to achieve minimal distortion of angles, proportions and other properties of the map.

    General view of the built orthodromes and two loxodrome

    On such a scale, almost nothing can be made out - all lines practically merge. But let's take a closer look at the center of the lines, having previously included the grid with a step of 100 meters.

    discrepancy between the orthodromes and the loxodrome half way from start to finish

    The green line with the black dot on the map is the orthodrome. Yellow is a loxodrome built in Mercator / WGS84, red is a loxodrome in Web Mercator. As expected, the loxodromes moved away from the orthodrome because they are not the shortest distances and are relatively arcs with respect to the direct orthodrome. Thoroughly gone - more than 500 meters. But where did they bring us?

    The discrepancy between the Loxodrome built in Web Mercator and the rest of the lines

    The yellow loxodrome, built in the projection of the Mercator ellipsoid WGS84, describing the correct arc, “magically” returned to the desired point. This means that in this projection you can get to the desired point, knowing the initial heading angle and moving all the time at this angle to the direction to the geographical north. But it didn’t work out with red - it missed more than a hundred and a half meters. One and a half hundred on three hundred thousand meters of a way. Four hundredths of a percent. Is it a lot or a little? This is enough not to be considered conformal and not used for calculations where it is important.

    Names, appearances, passwords

    The problem with determining that the Web Mercator coordinate system is being used is not invented. Because of her, let's say, “anarchist” past, she has so many names that it is simply impossible to list. However, I will try to demonstrate how terrible everything is, listing only some of the known names and codes of this coordinate system:
    Web Mercator, Google Web Mercator, Spherical Mercator, WGS 84 Web Mercator, WGS 84 / Pseudo-Mercator (though the “pseudo” is not just Mercator, but WGS84) , WGS84 Web Mercator (Auxiliary Sphere), Popular Visualization CRS / Mercator, WGS84 / Simple Mercator.

    EPSG: 900913, EPSG: 3785, EPSG: 3857, EPSG: 102113, ESPG: 102100, EPSG: 41001.

    This is how this system looks in the PROJ.4 format :
    +proj=merc +lon_0=0 +k=1 +x_0=0 +y_0=0 +a=6378137 +b=6378137 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
    Here you should pay attention to the equal values ​​of the dimensions of the semiaxes of the ellipsoid a and b . Their equality means the use of the sphere. If this is an “honest” projection of the Mercator of the ellipsoid WGS84, it is also EPSG: 3395 , in the PROJ.4 format it is defined like this:
    +proj=merc +lon_0=0 +k=1 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84 +units=m +no_defs

    Another unpleasant situation is the existence of definitions of this coordinate system in the Well-known Text (WKT) format, in which the definition itself in WKT almost coincides with the definition for an “honest” coordinate system using the WGS84 ellipsoid, that is, there is a line there SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"], but then either a declaration redefining this line is found PARAMETER["semi_minor",6378137.0], or a hellish construction in generalEXTENSION["PROJ4","+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 +wktext +no_defs"],AUTHORITY["EPSG","3857"]. The problem with such definitions (coming in the form of a PRJ file with some data) is that no one guarantees you that the software with which you will open this data will understand what exactly they want from it in such a contradictory definition as the first option. And the introduction of a line in PROJ.4 format, which contradicts everything that is written in WKT, into the definition is generally a subtle perversion, since it is not known who generally supports this. It turns out that in the best case, the program will give an error about the unreadable content of the definition of the coordinate system, and in the worst, it will try to interpret this vinaigrette, ignoring the incomprehensible, which will lead to the fact that the data in Web Mercator will be read as data in the “honest” WGS84 / Mercator.

    Logic of the situation

    I'm not trying to prove here that the Web Mercator coordinate system is worthless. Good, of course. And exactly the same conclusion (except for issues where compliance with US military standards is important) can be found in the NGA report. It is simply important to understand the difference between coordinate systems and their capabilities. It’s important to understand that Web Mercator is used almost everywhere: Google, OpenStreetMap, Bing, Yahoo and countless other services. It is also embedded in the Slippy Map Tiles format , which stores many tile raster data sources. It is so popular that not everyone who uses it thinks about how exactly it works. But sometimes it’s worth thinking, especially if the planned service should perform functions that are more complicated than simply displaying a picture with a map.

    A few interesting facts, instead of the conclusion,

    the NGA Agency, with the report of which began a new round of this story, before the advent of services such as NASA World Wind, Google Maps, Yandex.Maps and others, was the only source of relatively high resolution satellite images available (10 meters per pixel) , black and white image) to the territory of Russia, which could be downloaded for free through the NIMA Raster Roam service (then the NGA was also called NIMA - National Imagery and Mapping Agency). These images were part of a reconnaissance program carried out by satellites since the fifties, and fell into the declassification program in 1995.

    The Yandex.Maps service does not use the Web Mercator coordinate system, it uses an honest Mercator projection of the ellipsoid WGS84, code EPSG: 3395. I do not know what this is connected from the beginning, but it would be very interesting to hear the comments of Yandex employees, which are present here in Habré in considerable numbers.

    Local map services of the Scandinavian countries often do not use the Mercator projection at all, preferring the coordinate systems that are accepted in these countries, for example, the Norwegian state service Norge i Bilder uses three projection zones UTM and datum EUREF89 . This is due to the fact that in the northern latitudes the Mercator projection gives too strong scale deformations.

    Also popular now: