"On our dynamic Earth, continents don’t sit still. They slowly move around the planet, stretching oceans andlifting mountain ranges. [...] Over time, things add up. And it’s beginning to impact the accuracy of geospatial data."
A long time ago when there was still printed documentation, the Understanding Map Projections book had a foldout table in the back. The table listed all the map projections and had information about various properties and characteristics.
Bojan Šavrič Bojan Savric undertook to update and modernize the table including changing the categories and adding new projections. We hope you like the new style! It will easily fit on a 8.5"x14" or 11"x17" page if you want to print it out. Here's the 11x17 version on my office door:
It's complete through ArcGIS Pro 2.5 and ArcGIS 10.8. We're adding 3 new projections to those releases: Adams square II, Tobler cylindrical I, and Tobler cylindrical II.
In 2008,the National Geodetic Survey (NGS) announced in its 10-year plan the replacement of the country’s two national datums: North American Datum of 1983 (NAD 83), the geometric datum used mainly for horizontal positions, and the North American Vertical Datum of 1988 (NAVD 88), the vertical datum used for determining orthometric heights (elevations).
“We are leaving behind forever the idea of static, unchanging spatial reference systems. This has been well-known in the geodetic community for some time."...read more about this activity below...
NGS has been very proactive in publishing information on the planned changes, and has had several summits to directly communicate with stakeholders and invite feedback. This year’s is on May 6-7 in Silver Spring, Maryland.
Last year there was a special industry partner summit. We’ve had someone at all of these geospatial summits, and have met many of the NGS personnel who are involved in the effort.
We are also attending or watching the NGS webinars related to this subject to make sure that we’re on top of the situation.
NGS has stated that they will release beta versions of data, transformations, etc. ahead of the 2022 date. So far there hasn’t been anything that Esri can test. We plan to incorporate any new coordinate system definitions (geodetic, projected, and vertical) as they’re released officially. If NGS releases beta versions, we plan to check that we do not see any issues and that they can be used in the software.
We have occasionally pre-empted an official release of transformation grid files or coordinate systems because supposedly the names and other information have been finalized and put the objects into a current software release. Then the names are changed and we end up having to change/delete/add the existing definitions. Because there are a lot of customers using US data, we want to be very careful adding these new coordinate systems and transformations for the 2022 modernization.
There has been an increase in queries regarding the import of coordinate values from spreadsheets into ArcGIS Desktop and ArcGIS Pro. With that in mind, find a checklist that hopefully will encourage, when dealing with this type of data, the understanding of coordinate values, their implications of how they are managed and the relationship to coordinate reference systems in ArcGIS software.
Check coordinates are in the order you expect (e.g. Lat/Long or Long/Lat or X, Y; Y, X and W, E; -X, -Y etc)
Check there are no NULLs or other errors
Check for NULLS, text not number, unrealistic precision, outliers…
Confirm the coordinates make sense (e.g. if you are working with Arctic DMS coordinates a negative latitude value should be a red flag for you)
Check you know the units
Latitude and Longitude are angles therefore = Geographic Coordinate System
XY coordinates (e.g. meters) are linear measurements therefore = Projected Coordinate System
Convert the data you have into a workable format (e.g. DMS to DD = D + (m/60) + (s/3600) with additional formulae including the consideration of negation per hemisphere)
Check you know the correct coordinate reference system
Find a reference for the data that explicitly says the CRS
If you can't find one then beare in mind the following:
Commonly but not always, global datasets are in WGS84 (possibly because GPS utilises WGS84)
Typically but not always, linear units will be in a UTM projection
If you really do not know the correct CRS
Try not to guess – there’s a lot of CRS out there
Go back to source they might know but didn’t include the relevant information in the data
Based on the coordinate values try to place the data in a region/country and look for the most relevant CRS for that region
If you had to make an educated guess say so in any metadata so no one is fooled and makes an important decision on the information later
Loading data to a map (ArcGIS Pro or ArcMap)
Make sure Map Document data frame for ArcMap is blank (in ArcGIS Pro map properties the default is Web Mercator Auxiliary Sphere)
Assign the correct CRS to Map Document/Map
Add data to Map Document/Map
Check against base map and data where location is known
This blog has not accounted for additional items like transformations but it should act as a checklist of things to look out for when bringing data in from a spreadsheet.
Let’s say the latest version of ArcMap includes the definition of your country’s latest coordinate system and you would like to use it in your version of ArcMap. For that you need to export the new definition and import the coordinate system to your software. In this post, I demonstrate how you can perform this operation using the example of GDA2020 VicGrid (EPSG::7899) coordinate system used in Australia.
To export the GDA2020 VicGrid definition from the latest ArcMap, go to “Data Frame Properties” and select the “Coordinate System” tab. Browse or search for the definition you would like to export. Right click on the definition and select the “Save As…” option. Save the .prj file to a desired location. The .prj file stores a well-known text (WKT) string definition of the coordinate system. You can view it in any text editor.
In your older version of ArcMap, return to “Data Frame Properties” window and “Coordinate System” tab. There select the “Add Coordinate System” button, and select the “Import…” option. Browse to the location where you stored the exported .prj file and add it to the system.
Once you do this, the system will add the definition into your “Favorites” folder and will stay there until you remove it. If this does not happen, you can add the coordinate system to Favorites yourself by right-clicking on the coordinate system and selecting the “Add To Favorites” option.
In our particular example, GDA2020 VicGrid definition also includes the definition of a new geographic coordinate system, GDA2020 (EPSG::7844). Because this geographic coordinate system is not defined in the older version of ArcMap, there is no available transformation that would allow you to transform your data from any coordinate system to GDA2020. Without an available transformation, you will not be able to line up your data properly. Therefore you need to create a custom geographic transformation.
The WKT of GDA2020_Vicgrid is shown below. The GDA2020 definition is embedded and shown in bold text.
EPSG Geodetic Parameter Dataset (epsg-registry.org) is a structured dataset of coordinate reference systems and coordinate transformations. There we can look for transformations that we can use to connect the GDA2020 coordinate reference system with other existing coordinate system in the software. For lists of the available transformations, methods, and areas of use in the latest ArcMap, see this geographic_transformations.pdf file. Let’s use an example of GDA94 to GDA2020 (1) transformation identified with the EPSG:: 8048 code.
First, we add the geographic coordinate system GDA2020 to the older version of ArcMap using the same workflow introduced above. Next, we browse to a tool for creating a custom geographic transformation. It is available in ArcToolbox, under “Data Management Tools” and “Projections and Transformations.”
In the tool’s interface, you type the name of your custom geographic transformation. For “Input Geographic Coordinate System” you browse to Geocentric Datum of Australia 1994 (EPSG::4283) already available in your software and you select GDA2020 from your “Favorites” folder for the “Output Geographic Coordinate System.” Next, you specify the method and all required transformation parameters. Note that parameter values differ from the ones provided by EPSG. The reason for this are different units required for the parameters. EPSG-provided parameters are in millimeters, milliarc-seconds and parts per billion, while the “Create Custom Geographic Transformation” tool takes meters, arc-seconds and parts per million (ppm).
Once you add the new coordinate system definitions and create a custom transformation, you will be able to perform the same coordinate operations as you would normally do. Your new custom transformation will be used together with other existing transformations.
Galileo is Europe’s Global Satellite Navigation System (GNSS), providing users with improved positioning and timing information.
The project has been running since the launch of the first operational Galileo satellites GSAT0101 and GSAT0102 in October 2011. The latest Full Operational Capability (FOC) satellites were launch in December 2017 and there are currently 22 satellites in orbit.
The number suffix is, in fact, a date. It refers to the currently used standard equinox (and epoch) which isJ2000.0.
The prefix "J" indicates that it is aJulian epoch and the number refers to January 1, 2000, 12:00Terrestrial Time. There have been other standard equinoxes (and epoch) where the previous version was B1950.0, with the prefix "B" indicating it was a Besselian epoch. Julian equinoxes and epochs have been used for every equinox since 1984.
Why do we need to use a fixed date and time?
In a phrase, J2000 is needed due to the precession of the equinoxes.
Forming part of the Milankovitch theory of long term climate change the precession of the equinoxes refers to the observable phenomena of the rotation of the celestial sphere. A cycle which spans a period of (approximately) 25,920 years, over which time the constellations appear to slowly rotate around the earth, taking turns at rising behind the rising sun on the vernal equinox.
Precessional movement of Earth (right). Earth rotates (white arrows) once a day around its rotational axis (red); this axis itself rotates slowly (white circle), completing a rotation in approximately 26,000 years
What are the effects of the Precession of Equinoxes on reference systems?
If the position of the celestial poles and equators are changing on the celestial sphere, then the celestial coordinates of objects, which are defined by the reference of the celestial equator and celestial poles, are also constantly changing and since the location of the equinox changes with time, coordinate systems that are defined by the vernal equinox must have a date associated with them.
This specified year is called the Equinox (not epoch). Currently, we use Equinox J2000.0
The main epochs in common use are: – B1950.0 - the equinox and mean equator of 1949 Dec 31st 22:09 UT. – J2000.0 - the equinox and mean equator of 2000 Jan 1st 12:00 UT
The B1950 and J2000 reference frames are defined by the mean orientation of the Earth’s equator and ecliptic at the beginning of the years 1950 and 2000.
There is an interesting but perhaps little-used folder of *.prj files called “Solar System”. As someone interested in geodesy and its application it is particularly intriguing how scientists have constructed coordinate reference systems for planetary bodies other than the Earth.
First off let’s have a look at the details found in ArcGIS Desktop for "Geographic Coordinate Systems" of solar system objects. ArcGIS does not have any projected coordinate reference systems for the other planets and moons. Therefore you'll have to make a custom projection if you want to build upon the geographic coordinate system.
However, the folder contains coordinate reference systems for all the major objects found in the Solar System including all the planets, Jupiter's Moons and many others.
Let's start with the Moon
Apart from Earth, the Moon is arguably the astronomical body with the longest applied study of coordinate systems due to its long history of observation compared to other bodies. Interestingly, a standard Lunar Coordinate System was only agreed upon in 2006 for the Lunar Reconnaissance Orbiter mission and in 2008 a Lunar Geodesy and Cartography Working Group was created to maintain the current reference system.
Lunar coordinates, also known as Selenocentric coordinates, act in a similar way to those on Earth using the same nomenclature for geodetic longitude and latitude on Earth. As on Earth, latitude measures the distance north or south of an equator defined to be approximately 90° from the rotation axis, while longitude is measured east and west from an arbitrarily chosen central meridian.
On the Moon, the origin of the coordinate system passes through the point that is most nearly, on average, pointed towards the centre of the Earth. The "on average" part of the definition of the origin is because of precession, the change in the axis of rotation with respect to a reference plane.
From the first image, it can be seen that the Moon is regarded as a perfect sphere (both semimajor and semiminor axis are the same value: 1737400.00 m).
Before we explore further there are two definitions that are important to know when working with planetary bodies:
Planetocentric coordinates (for the Moon selenocentric) - are expressed as coordinates with the origin at the center of mass of the body. The coordinates refer to the equatorial plane of the body concerned and are commonly used within calculations of celestial mechanics.
Planetographic coordinates (for the Moon selenographic) - are used for observations of the surface features of those planets whose figures are not truly spherical, but oblate. They are referred to the mean surface of the planet, and are the coordinates actually determined by observation.
The Moon uses selenocentric coordinates where Latitude is the angle between a line extending from the origin to the planetary equator and a vector to the point of interest. Longitude is the angle between this vector and the plane of the Prime Meridian measured in an eastern direction. Radius is the distance from the Moon’s center of mass to the point of interest. The radius of the Moon is defined as 1,737.4 km
Lunar Fixed Reference System
However, there are really two reference systems for the Moon and it has to do with the two definitions above. However, ArcGIS Desktop 10.3 only shows a selenocentric coordinate system. The principal difference between the following reference systems is how the Moon's axes are treated.
Mean Earth - Polar System a selenocentric system
The Mean Earth/Polar Axis reference system defines the z-axis as the mean rotational pole. The Prime Meridian (0˚ Longitude) is defined by the "mean Earth direction" (the point on the lunar surface designated as the origin, this happens to be close to the Oppolzer A crater, below). This system is used in operations for planning, observational targeting, geographic identification of lunar landforms, and inter-mission communications.
Principal Axis System a selenographic system
This system can be thought of as a body-fixed rotating coordinate system. The Moon principal axes are used but due to the Moon's rotating characteristics, tidally locked to the Earth, this system and the Mean Earth/Polar Axis System do not align. However, they can be aligned through a transformation method bringing the error down to approximately 1Km. The Principal Axis System is used for studies including gravity field survey and lunar laser ranging.
Key information and positioning of the Moon can be explored further using HORIZONS by JPL.
Vincenty's Formulae are two methods named after Thaddeus Vincenty a Polish-American geodesist who lived during the 20th Century. During his career, he devised his formulae as well as contributing to major projects such as the NAD 83 where he introduced three-dimensional Earth-centered coordinates. Vincenty's formulae were published in 1975 and it can be downloaded and read here.
The formulae were developed for calculating geodesic distances between a pair of latitude/longitude points on an ellipsoidal model of the Earth (an oblate sphere). This ellipsoidal geometry is the next step, and perhaps, more appropriate geometry to use when modeling the Earth from working with a sphere using the Haversine Formula see https://community.esri.com/groups/coordinate-reference-systems/blog/2017/10/05/haversine-formula?sr=.... Unlike the Haversine method for calculating distance on a sphere, these formulae are an iterative method and assume the Earth is an ellipsoid.
However, even though Vincenty's formulae are quoted as being accurate to within 0.5 mm distance or 0.000015″ of bearing; the Haversine formulas are accurate to approximately 0.3%, which maybe be good enough for your project. Further consideration should be given to the datum being used, for example, WGS-84 is defined to be accurate to ±1m, perhaps negating the 0.5mm distance accuracy quoted for these formulae!
The formulae published by Thaddeus Vincenty include a direct and an inverse method where:
The Direct Method computes the location of a point that is a given distance and azimuth from another point
The Inverse Method computes the geographical distance and azimuth between two given points.
As mentioned above the formulae are iterative processes meaning that a sequence of equations is calculated where the output is reentered into the same sequence of equations. The aim is to minimise the output value after a set number of iterations.
For example, the Inverse Method outputs λ after assigning several constants including the length of the semi-major axis, length of the semi-minor axis, flattening, latitude coordinates, reduced latitudes, etc. The aim of the method is to minimise the value of the output λ (i.e. when the results converge to a desired degree of accuracy):
When the difference between the current value of λ and the value of λ from the previous iteration is less than the convergence tolerance then the final stage of the Inverse Method can be executed:
It is worth noting that this iterative solution to the inverse problem fails to converge or converges slowly for nearly antipodal points. This issue was discussed and alternative methods proposed in future papers by Vincenty (e.g. Vincenty 1975b).
The code for these formulae is available in Python from the PyGeodesy GitHub project or from Nathanrooy.github.io. Using PyGeodesy, the user can implement the Vincenty methods and change the ellipsoid for example in the below (taken from PyGeodesy GitHub project):
#Change the ellipsoid model used by the Vincenty formulae as follows: from pygeodesy import Datums from pygeodesy.ellipsoidalVincenty import LatLon p = LatLon(0,0, datum=Datums.OSGB36) #or by converting to anothor datum: p = p.convertDatum(Datums.OSGB36)