<p>I have covered nearly everything about GeoRSS, but not exactly everything. I promise, someday I’ll be posting about something else, but for today, we’ll have to delve deep into the mess that is geolocation.</p>
<h3>Coordinate systems</h3>
<p>If I ask you to give me something that will precisely point at some place, any place in the world, including the middle of the ocean, you’re likely to give me so-called <em>GPS coordinates</em>. Those actually are <ahref="https://en.wikipedia.org/wiki/World_Geodetic_System#WGS_84"target="_blank">WGS 84</a> coordinates. They represent a location on Earth, assuming the Earth is a perfect ellipsoid (a sphere, but slightly squished at the poles), whose center is the planet’s center of mass. But there are a lot of other ways to produce coordinates. Even now that GPS coordinates are ubiquitous, many other systems are still in use, for historic reasons, due to technological constraints, or for an increased precision.</p>
<p>Let’s start with a simple one. How do you represent coordinates in three dimensions? We did see earlier that GeoRSS has <code><georss:elev></code> to set the elevation in meters, but what if you are trying to represent a line that is sloped? For example, you are making your own Strava and want to show that you went up and down a hill. Your track won’t be perfectly at sea level, it will have an altitude that changes with each point. You need some way to include the altitude along with the latitude and longitude. In a geospatial database, the typical GPS coordinate system in use is numbered <ahref="https://epsg.io/4326"target="_blank">EPSG:4326</a>; store this number next to your coordinates and the database knows you are speaking in WGS 84. But if you want to add a third coordinate for altitudes, you will have to use a different version of the system numbered <ahref="https://epsg.io/4979"target="_blank">EPSG:4979</a>. It’s the same as GPS, but there’s a third axis for a height, starting from the ellipsoid defined by WGS 84, and measured in meters.</p>
<h3>Going beyond Earth</h3>
<p>Let’s go further. With all the hype around a bunch of space agencies trying to build a moon space station and two moon bases and sending rovers and all, we have to start thinking about an equivalent of GPS for other planets, and a way to refer to places on any planet. Fortunately, space agencies have had this problem a long time ago, and they have their solutions.</p>
<p>If you define your own geographic coordinate system, you can make your own ellipsoid to describe the shape of the planet, set the origin point (the 0° north 0° east point), and define how altitudes are expressed if you want to have a third dimension. On top of that, you can define a projection to flatten your planet, but that’s a whole another can of worms and I won’t deal with that here. You could define a coordinate system for the moon, with an ellipsoid that has the size and shape of the Moon, centered on the Moon’s center of mass, and define wherever you want your origin point to be. And you can do the same thing for basically anything, assuming you can somehow trick geospatial databases into bending a spheroid hard enough to fit your needs.</p>
<p>And that’s what the <abbrtitle="International Astronomical Union">IAU</abbr> did. Those are the same people who said Pluto isn’t a planet, so I don’t know if you can really trust them, but I haven’t seen any other coordinate system for other planets that was in widespread use within the space industry. There are lots of <ahref="https://spatialreference.org/ref/iau2000/"target="_blank">coordinate systems and projections for planets and moons</a>, including some for Earth because we clearly needed more. For the Moon, you’ll have to use <ahref="https://spatialreference.org/ref/iau2000/30100/"target="_blank">IAU2000:30100</a>, aka <em>Moon 2000</em>. This doesn’t mean the Moon is <abbrtitle="Year 2000">Y2K</abbr>-ready, it just means this was adopted by the IAU in 2000. Moon 2000 is defined in a geospatial database like so:</p>
<figure>
<pre>GEOGCS["Moon 2000",
DATUM["D_Moon_2000",
SPHEROID["Moon_2000_IAU_IAG", 1737400.0, 0.0]],
PRIMEM["Greenwich", 0],
UNIT["Decimal_Degree", 0.0174532925199433]]</pre>
<figcaption>
<ahref="https://en.wikipedia.org/wiki/Well-known_text_representation_of_coordinate_reference_systems"target="_blank">Well-Known Text</a> representation of the Moon 2000 coordinate system
</figcaption>
</figure>
<p>The <code>PRIMEM</code> specifies the primary meridian, at 0°; it is called <em>Greenwich</em> even though it definitely doesn’t exist on the Moon, because nobody cares about its name. We also don’t specify anywhere what the actual location of the origin point is, because databases don’t care about that either. The <code>UNIT</code> specifies that we are using decimal degrees for coordinates, with the long number being the multiplier to convert degrees to radians. Those are almost always present in most coordinate systems.</p>
<p>What matters for the Moon is the <code>SPHEROID</code>, with its two parameters, the semi-major axis and the inverse flattening. A spheroid is just another name for an ellipsoid.</p>
<p>In a sphere, the semi-major axis is the radius. In an ellipsoid, that would be the largest radius, as opposed to the semi-minor axis. The inverse flattening defines how hard you should <em>squish</em> the sphere to get an ellipsoid, so it allows calculating the semi-minor axis. Here, we have <code>1737400</code> as the semi-major axis, which matches the radius of the Moon in meters, and <code>0</code> as the inverse flattening, meaning this is a perfect sphere.</p>
<p>Remember how I mentioned in a previous post that <abbrtitle="Geography Markup Language">GML</abbr> is designed to represent anything about geospatial data? You can check out the <ahref="https://spatialreference.org/ref/iau2000/30100/gml/"target="_blank">GML representation of Moon 2000</a> if you wish to be spooked.</p>
<h3>From the Moon to WGS 84</h3>
<p>So let’s say we have some Moon 2000 coordinates, for example <ahref="https://en.wikipedia.org/wiki/Tranquility_Base"target="_blank">Tranquility Base</a>, at <ahref="https://geohack.toolforge.org/geohack.php?pagename=Tranquility_Base&params=00_41_15_N_23_26_00_E_globe:moon_type:landmark"target="_blank">0.6875°, 23.433333°</a>. How do you put that into GeoRSS?</p>
<p>Since databases don’t care one bit whether what you are doing makes any sense, you could convert directly from Moon 2000 to WGS 84. That would make the database assume that your coordinates are just on a very weirdly-shaped Earth. Since coordinates are in degrees, the size of the Earth doesn’t matter, and the coordinates will remain unchanged after this conversion; maybe with some slight changes to account for the differently-shaped ellipsoid. You are now in <ahref="https://geohack.toolforge.org/geohack.php?pagename=Tranquility_Base&params=00_41_15_N_23_26_00_E_globe:earth_type:landmark"target="_blank">some weird place in Democratic Republic of the Congo</a>.</p>
<p>To do the proper conversion, you will need to do some trigonometry. Your Moon 2000 coordinates and the Moon 2000 spheroid are related to the center of mass of the Moon. WGS 84 is the same for Earth. Knowing the distance between the Earth and the Moon’s centers of masses, and knowing <ahref="https://astronomy.stackexchange.com/a/30434"target="_blank">the position of the Moon on the Earth’s surface</a> at a given date and time, it should be possible to get the offset in degrees to add to the latitude and longitude to said position to get the position of your target on Earth, as well as the altitude from Earth.</p>
<figcaption>Schematic representation of the geometric shenanigans to get WGS 84 coordinates for Tranquility Base</figcaption>
</figure>
<p>That’s a mess, and you can do something easier than that: just make it someone else’s problem. GeoRSS GML lets you set a different coordinate system using the <code>srsName</code> attribute. And if you are using any amount of dimensions other than two, you can use <code>srsDimension</code> as well.</p>
<h3>Examples</h3>
<p>Here is an example of one of the telescopes of the <abbrtitle="Very Large Telescope">VLT</abbr>, the same that I mentioned in my post about circles in GeoRSS, but using a third dimension in its coordinates instead of the <code><georss:elev></code> tag:</p>
<figcaption>Getting a third dimension in GeoRSS GML</figcaption>
</figure>
<p>To specify that I am using <ahref="https://epsg.io/4979"target="_blank">EPSG:4979</a>, I am using the <code>srsName</code> attribute with a <abbrtitle="Uniform Resource Name">URN</abbr>, specifically an <ahref="https://www.ogc.org/about-ogc/policies/ogc-urn-policy/"target="_blank"><abbrtitle="Open Geospatial Consortium">OGC</abbr> URN</a>, which defined that <code>def:crs:</code> defines a coordinate reference system. <code>EPSG</code> says the authority defining this system is the <abbrtitle="European Petroleum Survey Group">EPSG</abbr>, <code>9.0</code> is the version number of their <ahref="https://en.wikipedia.org/wiki/EPSG_Geodetic_Parameter_Dataset"target="_blank">Geodetic Parameter database</a>, and <code>4979</code> is the identifier of the system within that database.</p>
<p>I am also using <code>srsDimension</code>, which allows specifying how many dimensions the coordinate system has. While this could be guessed from the coordinate system, this allows feed parsers and validators to know that they should expect coordinates of this amount of dimensions without having to know about coordinate systems, which can simplify implementations. Perhaps you can just send the <code>srsName</code> verbatim to some other software library specialized in coordinate systems.</p>
<p>And here is Tranquility Base! Since the <code>IAU2000</code> coordinate systems and projections do not have a <abbrtitle="Uniform Resource Name">URN</abbr>, I am instead using a <abbrtitle="Uniform Resource Locator">URL</abbr> to the GML definition of the coordinate system I want.</p>
<figcaption>Pointing at Tranquility Base in GeoRSS GML</figcaption>
</figure>
<h3>Reference</h3>
<dl>
<dt><code><dfn>srsName</dfn></code></dt>
<dd>
<p>The spatial reference system used for this geometry. This should be either a <abbrtitle="Uniform Resource Name">URN</abbr> for a common system, for example <code>urn:ogc:def:crs:EPSG:<version>:<identifier></code>, where <code><version></code> is the version number of the <abbrtitle="European Petroleum Survey Group">EPSG</abbr> database of spatial reference systems, and <code><identifier></code> is the number of the system. For <code>EPSG:4979</code>, you could use <code>urn:ogc:def:crs:EPSG:9.0:4979</code>. For an <abbrtitle="Spatial Reference System">SRS</abbr> that does not have a URN, or has a custom definition, you can use a <abbrtitle="Uniform Resource Locator">URL</abbr> that points to the definition of this SRS in GML. For <code>IAU2000:30100</code>, you could use <code>https://spatialreference.org/ref/iau2000/30100/gml/</code>.</p>
<p>The <ahref="https://validator.w3.org/feed/"target="_blank">W3C Feed Validation Service</a> allows this attribute, but does not perform any validation on its value.</p>
</dd>
<dt><code><dfn>srsDimension</dfn></code></dt>
<dd>
<p>The number of dimensions of this spatial reference system. Since the default is the 2-dimensional WGS 84 (EPSG:4326), you will always need to set <code>srsName</code> along with this. This is always implied by the system you are using, but this makes it easier to validate your data since a GeoRSS validator does not have to know how the <abbrtitle="Spatial Reference System">SRS</abbr> defined, or understand the concept of SRS, to be able to tell if you put the right amount of coordinates in your data.</p>
<p>You can set both of these attributes on <code><gml:Point></code>, <code><gml:LineString></code>, <code><gml:LinearRing></code>, <code><gml:Envelope></code>, <code><gml:Polygon></code> or <code><gml:CircleByCenterPoint></code>. You can also set these directly on <code><gml:pos></code> and <code><gml:posList></code>, but the <ahref="https://schemas.opengis.net/georss/1.0/schema-1.1/gmlgeorss.xsd"target="_blank"><abbrtitle="XML Schema Definition">XSD</abbr> for the GeoRSS GML Application Profile</a> says that <cite>"It is expected that this attribute will be specified at the direct position level only in rare cases"</cite>.</p>
<p>While the <ahref="https://validator.w3.org/feed/"target="_blank">W3C Feed Validation Service</a> supports this attribute, it only validates that it is a valid positive integer, not that it matches the specified <abbrtitle="Spatial Reference System">SRS</abbr>, or that the coordinates specified in the geometries match this attribute. It also does not allow this attribute on <code><gml:pos></code> or <code><gml:posList></code>.</p>