# Mercator and polar projections

This post is a more quantitative version of the previous post. Before I said that straight lines on a Mercator projection map correspond to loxodrome spirals on a sphere. This post will make that claim more explicit.

So suppose we plot a straight path from Quito to Jerusalem on a Mercator projection.

The red dot in the lower left corner represents Quito and the next red dot represents Jerusalem.

Mercator projection leaves longitude λ unchanged, but latitude φ is transformed via

φ ↦ log( sec φ + tan φ )

for reasons explained here. We can apply the inverse of the Mercator projection to put the path above on a globe, and when we do, it looks like the following.

The path planned on a Mercator projection map when projected onto the globe becomes a logarithmic spiral in polar projection. The radial direction in the plot above shows the angle down from the North Pole rather than the angle up from the equator.

So if our flight of constant bearing keeps going rather than stopping at Jerusalem, it will spiral quickly toward the North Pole. It appears to stop at pole unless you look carefully. In theory the spiral keeps going and never actually reaches the pole. This is easy to see on the Mercator map because the North Pole is infinitely far away on the vertical axis.

# Straight on a map or straight on a globe?

Straight lines on a globe are not straight on a map, and straight lines on a map are not straight on a globe.

A straight line on a globe is an arc of a great circle, the shortest path between two points. When projected onto a map, a straight path looks curved. Here’s an image I made for a post back in August.

The red lines form a spherical triangle with vertices at Quito, Nairobi, and Jerusalem. The leg from Quito to Nairobi is straight because it follows the equator. And the leg from Nairobi to Jerusalem is straight because it follows a meridian. But the leg from Quito to Jerusalem looks wrong.

If you were flying from Quito to Jerusalem and saw this flight plan, you might ask “Why aren’t we flying straight there, cutting across Africa rather than making a big arc around it? Are we trying to avoid flying over the Sahara?”

But the path from Quito to Jerusalem is straight, on a globe. It’s just not straight on the map. The map is not the territory.

Now let’s look at things from the opposite direction. What do straight lines on a map look like on a globe? By map I mean a Mercator projection. You could take a map and draw a straight line from Quito to Jerusalem, and it would cross every meridian at the same angle. A pilot could fly from Quito to Jerusalem along such a path without ever changing bearing. But the plane would have to turn continuously to stay on such a bearing, because this is not a straight line.

A straight line on a Mercator projection is a spiral on a globe, known as a loxodrome or a rhumb line. If a plane flew on a constant bearing from Quito but few over Jerusalem and kept going, it would spiral toward the North Pole. It would keep circling the earth, crossing the meridian through Jerusalem over and over, each time at a higher latitude. On a polar projection map, the plane’s course would be approximately a logarithmic spiral. The next post goes into this in more detail.

I made the image above using the Mathematica code found here.

Although straight lines the globe are surprising on a map, straight lines on a map are even more surprising on a globe.

# Quirks in Mathematica’s administrative division data for Mexico

If you ask Mathematica for a list of Mexican states via

`    CountryData["Mexico", "RegionNames"]`

you will get a list of strings:

`    "Aguascalientes", "Baja California", ..., "Zacatecas"}`

However, when you try to turn this into a list of objects representing these states via

```    states = Entity["AdministrativeDivision", {#, "Mexico"}] & /@
CountryData["Mexico", "RegionNames"]
```

something strange happens. Some items in the list are turned into useful objects, and some are uninterpreted symbols.

For example, Aguascalientes is recognized as an administrative division, but Baja California is not. It recognizes Oaxaca but not Nuevo Leon. The pattern is that states with a space are not recognized. There is an inconsistency in Mathematica: output names do not always match input names. To create the object representing Baja California, you need to pass in the string `BajaCalifornia` with no space.

`    Entity["AdministrativeDivision", {"BajaCalifornia", "Mexico"}]`

OK, so let’s remove spaces before we try to create a list of geographic objects.

```    names = StringReplace[#, " " -> ""] & /@
CountryData["Mexico", "RegionNames"]```

This mostly works, but it trips up on Mexico City. The output name for the region is Ciudad de México, but Mathematica does not recognize `CiudaddeMéxico` as an administrative division. Mathematica does recognize `MexicoCity` as the name of a city but not as the name of an administrative division.

Changing `CiudaddeMéxico` to `MexicoCity` in the list of names did not fix the problem. But when I directly edited the list of state objects by replacing the uninterpreted value with the output running

`    Entity["AdministrativeDivision", {"MexicoCity", "Mexico"}]`

by itself everything worked. Then I was able to find a Traveling Salesman tour as in earlier posts (Africa, Americas, Eurasia and Oceania, Canada).

## Traveling Salesman tour of Mexico

The tour is

1. Baja California
2. Baja California Sur
3. Sinaloa
4. Durango
5. Zacatecas
6. Aguascalientes
7. Nayarit
8. Jalisco
9. Colima
10. Michoacán
11. México
12. Mexico City
13. Morelos
14. Guerrero
15. Oaxaca
16. Chiapas
17. Tabasco
18. Campeche
19. Quintana Roo
20. Yucatán
21. Veracruz
22. Puebla
23. Tlaxcala
24. Hidalgo
25. Querétaro
26. Guanajuato
27. San Luis Potosí
28. Tamaulipas
29. Nuevo León
30. Coahuila
31. Chihuahua
32. Sonora

The tour is 8,343 kilometers.

# A traveling salesman tour of Canada

Here is a Traveling Salesman tour of Canada’s provinces and territories created by Mathematica. This is the shortest path connecting the geographic centers of the regions.

Here is a much larger (4.5 MB) PDF file of the same map with higher resolution.

Starting in the northwest, the tour is

1. Yukon
2. Northwest Territories
3. Nunavut
4. Quebec
6. Prince Edward Island
7. Nova Scotia
8. New Brunswick
9. Ontario
10. Manitoba
12. Alberta
13. British Columbia

The tour is 11,070 km.

For more tours like this, see my earlier posts on tours of

This is an SVG image so you can scale it to make it easier to read if you’d like.

# Two-letter vs Three-letter Country Abbreviations

The ISO 3166-1 standard defines three codes for each country: a 2-letter abbreviation, a 3-letter abbreviation, and a 3-digit code.

The 2-letter abbreviations may be familiar because it is very often (but not always [1]) also the country code top-level domain (ccTLD). For example, AU is the ISO abbreviation for Australia, and .au is the ccTLD.

I was curious about the relation between the two-letter and three-letter abbreviations. Sometimes the former is a prefix of the latter, such as US and USA. Sometimes the latter adds a letter in the middle, such as going from CN to CHN. How common are these two patterns?

I wrote a script using the iso3166 Python module to find out.

Turns out that the prefix pattern is most common, and occurs 63% of the time.

The infix pattern is the next most common, occurring 29% of the time.

Suffixes are rare. There are only for instances where the 2-letter name is the last two letters of the 3-letter name: ATF, MYT, SPM, and SGS.

The remaining possibilities are miscellaneous relations, such as IL and ISR for Israel.

Here’s a table of countries and ISO codes in plain text (org-mode) format.

[1] There are four ccTLDs that are not ISO 3166-1 alpha-2 names: uk, su, ac, and eu.

# Finding similar world flags with Mathematica

A week ago I posted some pairs of similar flags on Twitter, and later I found that Mathematica’s `CountryData` database contains flag descriptions. So I thought I’d use the flag descriptions to see which flags Mathematica things are similar.

For example, the `FlagDescription` attribute for Chad in Mathematica is

Three equal vertical bands of blue (hoist side), yellow, and red; similar to the flag of Romania; also similar to the flags of Andorra and Moldova, both of which have a national coat of arms centered in the yellow band; design was based on the flag of France.

I had Mathematica output a list of countries and flag descriptions, then searched the output for the word “similar.” I then made the following groupings based on the output [1].

## Emoji

Each flag has an emoji, so here are the groupings above using emoji icons

• 🇹🇩 🇷🇴
• 🇧🇴 🇬🇭
• 🇨🇴 🇪🇨
• 🇮🇳 🇳🇪
• 🇮🇪 🇨🇮
• 🇸🇻 🇳🇮 🇭🇳
• 🇪🇬 🇮🇶 🇸🇾 🇾🇪
• 🇱🇺 🇳🇱
• 🇦🇩 🇲🇩
• 🇮🇩 🇲🇨

## Related posts

[1] The groupings are based on Mathematica’s output, but I did some editing. Strictly following Mathematica’s descriptions would have been complicated. For example, Mathematica’s description might say A is similar to B, but not say B is similar to A. Or it might cluster four flags together that could better be split into two pairs.

# Graphing Japanese Prefectures

The two previous posts looked at adjacency networks. The first used examples of US states and Texas counties. The second post made suggestions for using these networks in a classroom. This post is a continuation of the previous post using examples from Japan.

Japan is divided into 8 regions and 47 prefectures. Here is a network diagram of the prefectures in the Kanto region showing which regions border each other. (In this post, “border” will be regions share a large enough border that I was able to see the border region on the map I was using. Some regions may share a very small border that I left out.)

This is a good example of why it is convenient in GraphViz to use variable names that are different from labels. I created my graphs using English versions of prefecture names, and checked my work using the English names. Then after debugging my work I changed the label names (but not the connectivity data) to use Japanese names.

To show what this looks like, my GraphViz started out like this

```    graph G {
layout=sfdp
AI [label="Aichi"]
AK [label="Akita"]
AO [label="Aomori"]
...
AO -- AK
AO -- IW
AK -- IW
...
```

and ended up like this

```    graph G {
layout=sfdp
AI [label="愛知県"]
AK [label="秋田県"]
AO [label="青森県"]
...
AO -- AK
AO -- IW
AK -- IW
...
```

Here’s a graph only showing which prefectures border each other within a region.

This image is an SVG, so you can rescale it without losing any resolution. Here’s the same image as a PDF.

Because this network is effectively several small networks, it would be easy to look at a map and figure out which nodes correspond to which prefectures. (It would be even easier if you could read the labels!)

Note that there are two islands—literal islands, as well as figurative islands in the image above—Hokkaido, which is its own region, and Okinawa, which a prefecture in the Kyushu region.

Here’s the graph with all bordering relations, including across regions.

The image above is also an SVG. And here’s the same image as a PDF.

# Classroom exercise with networks

In the previous post I looked at graphs created from representing geographic regions with nodes and connecting nodes with edges if the corresponding regions share a border.

It’s an interesting exercise to recover the geographic regions from the network. For example, take a look at the graph for the continental United States.

It’s easy to identify Alaska in the graph. The node on the left represents Maine because Maine is the only state to border exactly one other state. From there you can bootstrap your way to identifying the rest of the states.

## Math class

This could make a fun classroom exercise in a math class. Students will naturally come up with the idea of the degree of a node, the number of edges that meet that node, because that’s a handy way to solve the puzzle: the only possibilities for a node of degree n are states that border n other states.

This also illustrates that networks preserve topology, not geometry. That is, the connectivity information is retained, but the shape is dramatically different.

## Geography class

Someone asked me on Twitter to make a corresponding graph for Brazil. Mathematica, or at least my version of Mathematica, doesn’t have data on Brazilian states, so I made an adjacency graph using GraphViz.

Labeling the blank nodes is much easier for Brazil than for the US because Brazil has about half as many states, and the topology of the graph gives you more to work with. Three nodes connect to only one other node, for example.

Here the exercise doesn’t involve as much logic, but the geography is less familiar, unless of course you’re more familiar with Brazil than the US. Labeling the graph will require staring at a map of Brazil and you might accidentally learn a little about Brazil.

## GraphViz

The labeled version of the graph above is available here. And here are the GraphViz source files that make the labeled and unlabeled versions.

The layout of a GraphViz file is very simple. The file looks like this:

```    graph G {

layout=sfdp

AC [label="Acre"]
AL [label="Alagoas"]
...
AC -- AM
AC -- RO
...
}
```

There are three parts: a layout, node labels, and connections.

GraphViz has several layout engines, and the `sfdp` one matched what I was looking for in this case. Other layout options lead to overlapping edges that were confusing.

The node names AC, AL, etc. do not appear in the output. They’re just variable names for your convenience. The text inside the label is what appears in the final output. I’ll give an example in the next post in which it’s very convenient for the variables to be different from the labels. The order of the labels doesn’t matter, only which variables are associated with which labels.

Finally, the lines with variables separated by dashes are the connection data. Here we’re telling GraphViz to connect node AC to nodes AM and RO. The order of these lines doesn’t matter.

## Related posts

Suppose you want to color a map with no two bordering regions having the same color. If this is a map on a plane, you can do this using only four colors, but maybe you’d like to use more.

You can reduce the problem to coloring the nodes in a graph. Each node corresponds to a region, and there is an edge between two nodes if and only if their corresponding regions share a border.

Here is a sort of topologists’s or graph theorist’s view of the continental United States.

This was created using the following sample code from the Mathematica documentation.

```    RelationGraph[MemberQ[#2["BorderingStates"], #1] &,
EntityList[
```

You can recognize Maine in the graph because it’s the only state that only borders one other state. Alaska is also easy to locate. Exercise for the reader: mentally add Hawaii to the graph.

The analogous graph for Texas counties took much longer to draw: there are 49 continental US states but 254 Texas counties.

This was created with the following code.

```    RelationGraph[MemberQ[#2["BorderingCounties"], #1] &,
```

You can find El Paso county in the top left; it only borders one county just as Maine only borders one state.

# Shortest tours of Eurasia and Oceania

This is the final post in a series of three posts about shortest tours, solutions to the so-called traveling salesmen problem.

The first was a tour of Africa. Actually two tours, one for the continent and one for islands. See this post for the Mathematica code used to create the tours.

The second was about the Americas: one tour for the North American continent, one for islands, and one for South America.

This post will look at Eurasia and Oceania. As before, I limit the tours to sovereign states, though there are disputes over which regions are independent nations. I first tried to do separate tours of Europe and Asia, but this would require arbitrarily categorizing some countries as European or Asian. The distinction between Asia and Oceania is a little fuzzy too, but not as complicated.

## Oceania

Here’s a map of the tour of Oceania.

Here’s the order of the tour:

1. Australia
2. East Timor
3. Indonesia
4. Palau
5. Papua New Guinea
6. Micronesia
7. Marshall Islands
8. Nauru
9. Solomon Islands
10. Vanuatu
11. Fiji
12. Tuvalu
13. Kiribati
14. Samoa
15. Tonga
16. New Zealand

The total length of the tour is 28,528 kilometers or 17,727 miles.

## Eurasia

Here’s a map of the the Eurasian tour.

Here’s the order of the tour:

1. Iceland
2. Norway
3. Sweden
4. Finland
5. Estonia
6. Latvia
7. Lithuania
8. Belarus
9. Poland
10. Czech Republic
11. Slovakia
12. Hungary
13. Romania
14. Moldova
15. Ukraine
16. Georgia
17. Armenia
18. Azerbaijan
19. Turkmenistan
20. Uzbekistan
21. Afghanistan
22. Pakistan
23. Tajikistan
24. Kyrgyzstan
25. Kazakhstan
26. Russia
27. Mongolia
28. China
29. North Korea
30. South Korea
31. Japan
32. Taiwan
33. Philippines
34. East Timor
35. Indonesia
36. Brunei
37. Malaysia
38. Singapore
39. Cambodia
40. Vietnam
41. Laos
42. Thailand
43. Myanmar
45. Bhutan
46. Nepal
47. India
48. Sri Lanka
49. Maldives
50. Yemen
51. Oman
52. United Arab Emirates
53. Qatar
54. Bahrain
55. Saudi Arabia
56. Kuwait
57. Iran
58. Iraq
59. Syria
60. Lebanon
61. Jordan
62. Israel
63. Cyprus
64. Turkey
65. Bulgaria
66. North Macedonia
67. Serbia
68. Bosnia and Herzegovina
69. Montenegro
70. Albania
71. Greece
72. Malta
73. Italy
74. San Marino
75. Croatia
76. Slovenia
77. Austria
78. Liechtenstein
79. Switzerland
80. Monaco
81. Andorra
82. Spain
83. Portugal
84. France
85. Belgium
86. Luxembourg
87. Germany
88. Netherlands
89. Denmark
90. United Kingdom
91. Algeria

The total length of the tour is 61,783 kilometers or 38,390 miles.