Mapping Acid Mothers Temple tours with Org, R and Geonames

(This page should work pretty well on its own, but for full details see the raw Org file which includes all the raw data and shows how it’s being passed into code blocks.)

Acid Mothers Temple

I’ve seen Acid Mothers Temple & The Melting Paraiso U.F.O. live more than any other band. Seven or eight years ago I’d never heard of them, but now I own almost twenty of their albums and I’ve seen them six times, once a year since 2014 on their annual North American tours. It’s hard to describe the mesmerizing intensity of their style, but I call it “psychedelic Japanese acid noise.” If you like repetition, blazing guitars, spacey sounds and expert musicianship that builds from simple patterns into walls of noise, then you’ll like this band.

If you have a streaming audio service, look up “Cometary Orbital Drive,” which is their standard closing number. It’s a six-note two-bar riff that they start slow, then gradually speed up, faster and faster. You can see them do it live in this video of their 2016 Toronto concert (which I was at). It starts at 1:19:30, where they jump into it from another song. It starts off slow and peaceful, but turns into an absolute monster. Wait for the moment when Kawabata Makoto breaks free of the riff and goes into overdrive. That’s how to close a concert.

This band works hard. Before the show some of them will be selling stuff at the merch table, and then when the opening band is done they all get up on stage and set up their own equipment, crawling around plugging in pedals or helping the others shift speakers or move drums. There’s a pause while they all confirm they’re ready, then they make an astounding blast of noise to start the show, and then they go into the first song. Ninety minutes later they build the end of “Cometary Orbital Drive” to a wall of noise, then it’s over. And they’re back to the merch table. This year when I saw them as soon as they finished guitarist Jyonson Tsu walked across the stage, jumped down, went behind the table, and starting selling shirts and CDs. Later they would have packed it all up and moved on to the next city. That’s damned hard work.

And when they tour North America they do that every night for six or seven weeks without a break, as the tour shirt shows.

After the April concert, I was looking at the shirt. I wondered: Could I make a map of this?

Open data on t-shirts

Here are the other concert shirts I have.

Lots of lovely useful data on those shirts!

Organizing the data

I’m doing all of this in Org mode, of course, so I began by making two tables. One listed dates and cities from the 2016 and 2018 tours, and the others gave geographic information for the cities (a bit of rudimentary normalization).

First, the tour_data table began with:

date

city

2016-03-13

Mexico City

2016-03-15

Los Angeles

2016-03-16

San Francisco

2016-03-17

Reno

2016-03-18

Portland

2016-03-19

Vancouver

2016-03-20

Victoria

2016-03-21

Bellingham

2016-03-22

Seattle

2016-03-23

Boise

2016-03-24

Salt Lake City

Then cities began with:

city

adminCode1

country

Vancouver

02

CA

Victoria

02

CA

Toronto

08

CA

Windsor

08

CA

Montreal

10

CA

Mexico City

09

MX

Bisbee

AZ

US

Phoenix

AZ

US

Tucson

AZ

US

I’d decided to use Geonames to look up the locations of the cities, and it took a bit of poking around to find out that when you mean “province or state (or whatever it is in some other country)” Geonames uses “adminCode1”. In their features codes list it’s ADM1.

I had a little trouble finding adminCode1 information on the Geonames site, but found a file on my system that had everything I needed.

$ locate admin1Code
/usr/share/libtimezonemap/ui/admin1Codes.txt

I can’t explain why this is called admin1Code and not adminCode1. I wasn’t keeping detailed notes. But anyway, it works.

Setting up R

I got things started in Org my usual way, with a source block that creates a named R session where all the code will be run. This keeps this R environment separate from others—I usually have three or four running at a time.

I knew I’d need the geonames package, so I installed it. I already had an account on the system, and for ease of use I’ll just leave my username here, but you should get your own account. It’s free.

If you need to install any of these libraries, uncomment the relevant line.

First, we’ll check that all cities have full information. If this query returns any cities then their data needs to be added to the cities table. Fix and rerun until the query returns nothing. (If you’re not looking at this in Org you won’t be able to see how the data in the table is being passed to the code block through a variable specified with :var)

Geolocating the cities

We can’t make a map without knowing exactly where the cities are, so we need to geolocate them using Geonames and the geonames package.

For this I used purrr so I didn’t have to write a big loop. I haven’t used it before aside from copying and pasting a line to load in a bunch of CSV files at once, and it took me a while to realize I had to select columns of data for it to operate on. Then, also based on copying and pasting and editing other people’s code, and with a little helper function, I had one line of R that would run through all the cities (with country) and look up their longitude and latitude. map2dfr takes two lists as input and returns a data frame, which I add to cities.

Now, match up the tour data with the cities so everything is all in one tibble, amt.

amt <- tour_data %>% left_join(cities, by = "city")
head(amt)

date

city

adminCode1

country

lng

lat

2016-03-13

Mexico City

09

MX

-99.12766

19.42847

2016-03-15

Los Angeles

CA

US

-118.24368

34.05223

2016-03-16

San Francisco

CA

US

-122.41942

37.77493

2016-03-17

Reno

NV

US

-119.8138

39.52963

2016-03-18

Portland

OR

US

-122.67621

45.52345

2016-03-19

Vancouver

02

CA

-123.11934

49.24966

Now we have everything we need to make a map.

What kind of map?

Making Maps with R by Eric C. Anderson was very helpful in getting started with this, and later I read Kieran Healy’s Data Visualization: A Practical Introduction, which is excellent and also covers maps. I needed to install the maps library, which ggplot2 could use to make things easier with the map_data() function. Then I tried making a map of all of North America.

That looks pretty much right, to my unAmerican eyes, but it’s affected by how I size the image, and that’s not right. I want it fixed and accurate. For that, coord_map() does the job. By default it uses the Mercator projection.

Aha! It works! The Canadian gigs fit in because they’re below the 49th parallel (or so close to it that they fit in the padding, in Vancouver’s case), but the Mexico city show is quite far south. Since there’s just the one that we know of, let’s exclude it for now and maybe add it back later. Something looks strange about the lines inside the US, so let’s colour them by year, which we’ll do with lubridate.

Something’s not right. There’s a big jump from the southwest up to North Dakota or somewhere up there, which wouldn’t happen, and a jump from the east coast to the west and back. The colour says it’s happening with 2018, so let’s just look at that and also label the cities so it’s easier to tell where the problems are.

Clearly the Bisbee I’ve got isn’t the right one. It’s supposed to be Arizona, between El Paso and Phoenix. And that Richmond on the west coast should be Richmond VA in the east. Just looking up the cities by name isn’t enough. We need to use the adminCode1 when we look up the locations so we can fix the state.

Instead of figuring out how to make purrr work with three variables, I thought it would probably work to drop country but use adminCode1, which mean just changing a couple of variable names. It’s worth a try to save the time.

It worked! Much better! Using geom_text means the cities where they played twice are darker, which is a helpful unexpected side-effect while we’re working, but for the final image we’ll want it tidier, which we can do by plotting cities uniquely.

With the new data we need to recheck the cities information to make sure no new cities are missing. This code block needs to be rerun until it returns nothing. (As before, the tour data is being passed in to the Org source block through a variable setting only visible in the Org file.)

The general shapes of the tours are much clearer now. San Francisco, Portland, up to Vancouver, down to Salt Lake City and Denver, over to Minneapolis, then Chicago, Detroit, up to Toronto, over to the east cost of the US and a lot of gigs along there, then down to Atlanta, New Orleans, Texas, and across to southern California.

Let’s tidy up those city names. Some cities are visited on every tour. Which ones?

Lengthening tours

With all that data, we can ignore the locations and just look at dates to show how the tours are getting longer. The date thing I do here changes the year of every date to 2017, so that when the dates are mapped only the month and day will be used. I’ve found this is a nice trick to use when comparing years. There are probably better ways to do this, but it works.

Comparing just the first and latest tours makes that even more obvious, and if we join the cities with lines (making a parallel plot, or something like it) it’s easier to see where new cities have been added and when city order has changed. San Diego stands out because once it was the first stop and once it was the last.