Last week in this series we looked at geocoding, read about that here. This week we are looking at the opposite process - reverse geocoding. Reverse geocoding gathers information about the location using the longitude and latitude values. Sometimes this can be very precise (as in down to the house number) and other times more vague (just the country).
Same as the geocoding blog, I will be using OSM (Open Street Map) and the photon package in R. Last week I mentioned that the package has two functions, we looked at geocode in the last blog, to reverse the process the function is 'reverse'. The structure of the function is:
reverse(x, y, server = NULL)
where x is longitude, y is latitude, and the server defaults to photon public API.
The output of the reverse function has multiple fields (in image below). The first two columns (x and y) are the longitude and latitude values used in the function, name gives the name of the location which is sometimes the street or the name of the building or facility. The osm_key and osm_value describes what the location is - for example amenity is a key and school is a value that is in the amenity category. The 'lon' and 'lat' columns return the longitude and latitude of the location described, this is usually just slightly different to your input values.
For the purpose of this blog, I will use a dataset from Kaggle on meteorite landings which details the location (latitude and longitude), mass, composition, and fall year of meteorites that have struck our planet. Though there have been more than 45,000 meteorites hitting Earth so for this example of reverse geocoding I will focus only on locations in the UK (down to 26 rows).
Each meteorite has a name - which is indicative of their location, it is generally a specific area but does not mention the country or more general location. The data (below) is great if you happen to know where Aachen (for example) is in the world. Using the longitude and latitude in the data, it is possible to reverse geocode for the country and state (or equivalent).
Since the country is not mentioned in the data, I used an extract filter in Tableau Desktop to the keep only the latitude and longitude values that fall within the UK (taking the outer most longitudes and latitudes). This leaves us 26 out of 45,716 meteorite landings to reverse geocode in Tableau.
I started by plotting the map in Tableau (above), I put the names of the meteorites on detail (we need this so that the calculation works per row of data).
Now I can write the R script to retrieve these values in a calculated field (below). I use the SCRIPT_STR function in Tableau, the first line uses the reverse function where '.arg1' and '.arg2' are the longitude and latitude values, respectively. From the resulting data frame I extracted the city, state, and country and assigned them to their respective names. The code for the locations means that if there is no value in that field then instead of printing 'NA' it will print nothing, but if it has a location then it will print the location. The final line of the R script concatenates the fields together so that the location is formatted 'city, state, country'.
I want to bring this into the tooltip on the map so that there is not too much text on the map, but just to check for data quality I can duplicate my map as a cross-tab to see if all of the locations were found. Doing this, I found that one of the locations have not been reverse geocoded. This is easily fixed for just one point, I can go onto Google maps, type in the coordinates and input the location manually in Tableau as a calculated field.
The calculation below applies the location (from Google Maps) to the point named Bovedy, and then all other points will be the locations gained from reverse.
This completes the reverse geocoding of the meteor landings in the UK and the snippet into geocoding in R. Next week we will look at an R package that deals with RFM analysis.
If you would like to find out more or want bespoke training on using R in Tableau please contact us.