Tag Archives: Shiny

Directions of streets in Helsinki

A Shiny app that shows the orientation of the streets of Helsinki by district, and of the whole city. Data comes from Register of public areas in the City of Helsinki.

The whole exercise might seem a little silly (and probably is too) but if anything, it made me realize e.g. how the district of Viikki looks like a galloping horse when you look at its streets from this perspective.

Having done that, I used the Python library OSMnx to plot polar histograms. Here is a notebook where I tell how it went, and why Pasila is not where it should be.

The search after PDO product descriptions

You never know when a small piece of casual information develops to a journey into something a lot bigger. This time, it was a remark by a local cheese seller.

A notebook on how to search protected foodstuff names from the semantic repository of EU publications with SPARQL, and how to find their product description document. Includes a Shiny app to select product links from a small subset.

Streets of Helsinki

Helsinki streets on a map

Walking is fun, and there are always new ways to move forward, literally. Some people (not unlike me) have had this silly idea to walk all the streets of Helsinki, in alphabetical order. Johannes Laitila is one of them, and his blog is a good read (in Finnish). Recently Sanna Hellström, the head of Korkeasaari Zoo and former member of Helsinki City Council, mentioned in Twitter that since last fall, she had started to follow in Johannes’ footsteps.

Sanna’s tweet made me think about the size of her plan.

Spatial data of addresses of Helsinki are available from the city’s WFS API, via e.g. the key data site of Helsinki Region Infoshare. Of course addresses are not quite the same thing as streets but will do. Because addresses can refer to almost anything urban, I filtered them with a list of Official street names, the domain name of which tells something about the pragmatism of my home city; the name translates to Plans for cleaning.

The number of unique address names in my filtered data is 3788. The total sum of the geographical distances of individual addresses is 783 km (486 miles). There are some caveats though. Firstly, not all streets are populated by addresses from start to finish. In my home suburb Kulosaari for example, the two longest streets are Kulosaarentie and Kulosaaren puistotie. However, the former starts as a motorway exit road and meets its first address only after a few hundred meters. The latter is equally without addresses a long stretch from both ends. Secondly, distances are not calculated by the street level, so the meters you walk are bound to be more than what the figure says, except in those rare cases where the street forms a straight line.

Anyway, let’s assume a very rough error rate of 20 km to end up to a convenient total length of 800 km. To put that in perspective, Sodankylä, the venue for the legendary annual Midnight Sun Film Festival in Finnish Lapland, is about 800 km North from Helsinki. Given a modest rate of 5 km walking per day, starting about now, I’d reach Sodankylä in time for the next festival. In Helsinki, were I to walk one or two streets every weekend, the project of Walking Them All would be finished in 15 years.

What does Helsinki look like, street-wise?

The opening state of the interactive web app hkistreets that marks the first and last address on every street, shows how the bulk of them is spread along the North-South axis. Helsinki sits on a tip of a peninsula with a slight bending towards right. This North-Eastern area is fairly new. In 2009, a slice of Sipoo was annexed in Helsinki.

Notice the few markers above the sea. Helsinki occupies 315 islands, and from these, a couple have got an address which reveals that there’s something else on the island than just summer cottages, if anything. Rysäkari for example, the most Southern island, is a former military base, and a future tourist attraction (news in Finnish).

Most of the streets of Helsinki can be walked in 5 minutes if you are in a hurry; over 90% are under 500 m (1640 feet). 6% have only one address which means that they are an obscure lot. Either the street do is short or in fact it is some other place of interest (to be cleaned) like the centrally located square Paasikivenaukio 2 with the 40 ton granite statue of the former President of Finland Juho Kusti Paasikivi. 2% are under 1 km, and 0.9% between 1 and 3 km.

Only two streets in Helsinki are longer than 3 km. Mannerheimintie is a giant, almost 14 km, and known to all, whereas Jollaksentie (5 km) in South-East is a less visited suburban stretch. At the end of it, you are close to the last big unbuilt island of Helsinki, Villinki.

Google Street View does not cover all coordinates in Helsinki, as neat as it would be – sometimes because my coordinates are too far from streets – so popup links will often hit a black screen. Technically, I guess I could scrape all targets beforehand and only serve those that have something to look at, but Google TOS might not like it so I’ll let that idea be.

The R source code is available at Github.

Consuming IFTTTed Twitter favs

‪I consider my Twitter favourites to be mainly bookmarks although endorsements happen too. Liking comes from Instagram and Facebook but because my social media communities do not really overlap, I sometimes want to send digital respect in Twitter too. I’ve tried to unlearn the classic liking in Twitter and instead reply or retweet, but old habits – you know.‬

‪There’s little point in bookmarking if you cannot find your bookmarks afterwards. The official Twitter archive that I unzip to my private website few times a year, does not include favourites, which is a pity. The archive looks nice out of the box, and there is a search facility. ‬

‪Since late 2013, I have an active IFTTT rule that writes metadata of the favourited tweet to a Google spreadsheet. IFTTT is a nifty concept but oftentimes there are delays and other hickups. ‬

‪My husband and I lunch together several times a week. Instead of emailing, phoning or IM’ing the usual 5 minutes and I’m there bye message, I had this idea of enhanced automation with IFTTT. Whenever I entered the inner circle around our regular meeting point, IFTTT sent me an email announcing Entered the area. This caused a predefined email rule to trigger which forwarded the message to the receiver. Basta! At first this simple digital helper was fun, but as soon as it didn’t deliver, trust started to erode rapidly.

– Where are you? Didn’t you get the message?
– What message?

Sometimes the email came doubled, sometimes it arrived the next day (or never). After few months I had to deactivate the rule.‬

‪With tweets it’s not so critical. In the beginning I checked few times that the spreadsheet do was populated, but then I let it be. From time to time Google (or IFTTT) opens up a new document but fortunately keeps the original file name, just adds a version number.‬

IFTTT rule
IFTTT rule

‪I appreciate Google’s back office services but don’t often use their user interfaces. Besides, my IFTTT’ed archive does not include the tweet status text, so without some preprocessing the archive is useless anyhow. In theory I could get the text by building calls myself to the Twitter API with the Google Query Language, or become a member of the seemingly happy TAGS community. TAGS is a long-lasting and sensible tool by Martin Hawksey. But what would blogging be without the NIH spirit, so here we go.‬

‪Because I have access to a shinyapps.io instance, I made a searchable tweet interface as an R Shiny web app. For that I needed to‬

  • Install googlesheets and twitterR
  • Collect information on my tweet sheets‬, and download all data‬ in them
  • Expand short URLs‬
  • Fetch the Twitter status from the API‬
  • Write a row to the latest sheet to denote where to start next time‬
  • Build the Shiny app‬

The app acts now as a searchable table to my favourite tweets. While at it, I also plotted statistics on timeline.

Here is the app. The R code for gathering all data is in GitHub, likewise the code how I built the app.

Birds on a map

Lintuatlas aka Finnish Breeding Bird Atlas is the flagship of longitudinal observations on avian fauna in Finland. And it’s not just one atlas but many. The first covers years 1974-79, second 1986-89, and third 2006–2010. Since February this year, the data from the first ones are open. Big news, and asks for an experiment on how to make use of the data.

One of the main ideas behind the Atlases is to give a tool for comparison, to visualize possible shifts in the population. I decided to do a simple old-school web app, a snapshot from a given species: select, and see observations plotted on a map.

The hardest part in the data were the coordinates. How to transform the KKJ Uniform Coordinate System values to something that a layman like me finds more familiar, like ETRS89? After a few hours of head-banging, I had to turn to the data provider. Thanks to advice from Mikko Heikkinen, the wizard behind many a nature-related web application in this country – including the Atlas pages – the batch transformation was easy. Excellent service!.

advice on Lintuatlas coordinates

All that was left was few joins between the datasets, and data was ready for an interactive R Shiny application. To reflect the reliability of observations on one particular area (scale from 1 to 4), I used four data classes from the PuBu ColorBrewer scheme to color the circles.

The application is here, and the code for those of you more inclined to R.

Note that the application is on a freemium Basic account of shinyapps.io so I cannot guarantee its availability. There is a monthly 25 500 hour use limit.

Snow in Lapland

Finnish Meteorological Institute (FMI) Open Data API has been with us for over a year already. Like any other specialist data source, it takes some time before a lay person like me is able to get a grasp on it. Now, thanks to the fmi R package by the collaborative effort of Jussi Jousimo and other active contributors, the road ahead is much easier. A significant leap forward came just before New Year, when Joona Lehtomäki submitted a posting on fmi and FMI observation stations to the rOpengov blog.

Unlike many other Finns, I am relatively novice when it comes to Finnish Lapland. I’ve never been there during summertime, for example, and never farther North than the village of Inari. Yet, I count cross-country skiing in Lapland among the best memories of my adulthood years so far; pure fun in the scorchio April sun, but maybe even more memorable under the slowly shifting colors of the polar night.

Snow is of course a central element in skiing. Although warmer temperatures seem to be catching us up here, there has still been plenty of snow in Lapland during the core winter months. But how much, exactly, and when did it rain, when melt?

I followed Joona’s steps, and queried the FMI API of snow depth observations at three weather stations in Lapland, from the beginning of 2012 to the end of 2014: Kilpisjärvi, Saariselkä and Salla. Note that you have to repeat the query year-wise because the API doesn’t want to return all the years in one go.

Being lazy, I used the get_weather_data utility function by Joona as is, meaning I got more data than I needed. Here I filter it down to time and snow measurements, and also change the column name from ‘measurement’ to ‘snow’

snow.Salla.2014 <- salla.2014 %>%
  filter(variable == "snow") %>%
  mutate(snow = measurement) %>%
  select(time, snow)

and then combine all data rows of one station:

snow.Salla <- rbind(snow.Salla.2012, snow.Salla.2013, snow.Salla.2014)

One of the many interesting new R package suites out there is htmlwidgets. For my experiment of representing time-series and weather stations on a map, dygraphs and leaflet looked particularly useful.

Last time I was in Lapland was in mid-December 2014, in Inari, Saariselkä. BTW, over 40 cm of snow! During some trips I left Endomondo on to gather data about tracks, speed etc. I have to point out that I'm not into fitness gadgets as such, but it's nice to experiment with them. Endomondo is a popular app in its genre. Among other things it lets you export data in a standard GPX format, which is a friendly gesture.

For the sake of testing how to add GeoJSON to a leaflet map, I needed to convert the GPX files to GeoJSON. This turned out to be easy with the ogr2ogr command line tool that comes with the GDAL library, used by the fmi R package too. Here I convert the skiing ("hiihto") route of Dec 14th:

ogr2ogr -f "GeoJSON" hiihto1214.geojson hiihto1214.gpx tracks

One of the many aspects I like about dygraphs is how it lets you zoom into the graph. You can try it yourself in my shiny web application titled (a bit too grandiously I'm afraid) Snow Depth 2012-2014. Double-clicking resets. To demonstrate what one can do with the various options that the R shiny package provides, and how you can bind a value to a dygraphs event - pick a day from the calendar, and notice how it is drawn as a vertical line onto the graph.

The tiny, blue spot on the map denotes my skiing routes in Saariselkä. You have to zoom all the way in to see them properly.

The shiny application R code is here.

Edit 11.1: Winter and snow do not follow calendar years, so added data from the first leg of the 2012 winter period.

Mapping red-listed rainforest tree species

Rainforest Foundation Norway keeps a red list of tree species. Where do these trees grow?

One of the R packages developed by rOpenSci is rgbif. It’s a handy wrapper to the Global Biodiversity Information Facility API. With geolocation data returned by the query, you can plot points on the world map.

Let’s start with the list. Instead of using R all the way through, I scraped the HTML table rows with the Google Chrome extension Scraper, and saved data as a spreadsheet on Google Drive. This is the way Scraper works.

As I mentioned in my job blog the other day, one of the many good tutorials out there on using Scraper, is by Jens Finnäs.

Data needs some pruning in this exercise. What you need for the GBIF query, is basically just the Latin names. To make things somewhat simpler, I’ll take only the first one mentioned along each species; many have several.

Here is the R code for pruning, and for querying GBIF. The script saves the return data by the tree status, and in two file sets: R data, and GeoJSON. The first ones are used as input for a Shiny web application, where they will be plotted both as an interactive gvisGeoChart by googleVis, and as a static map with the (only slightly modified) gbifmap function from rgbif. The GeoJSON files will be rendered straight from a GitHub Gist. All of this just to demonstrate (foremost to myself!) that there are many ways to plot and serve maps, and that they all have different pros and cons depending on the amount and type of data. The challenge here is that there will be multiple data points on the same geolocation, and the number of different species is rather big too.

Next, the web application. Here is the R code for it, and this is the app itself. The maps served by GitHub: Critically_Endangered, Endangered, Vulnerable, Near_Threatened and Other.

The status Other is named by me. It refers to those rows in the original Foundation table, where no exact two-character status was given.

On the googleVis map, both the size and color of the points reflect the amount of occurrences on that particular location. This is of course repetitive, but I haven’t yet find a better solution. Optimally, the color would tell something else, maybe the species. Yet, the tooltip has this information already, so there you are. Note that the country name in the tooltip comes from a yet another scraped file, originating to Wikipedia. Initially, I had in mind fetching the name by querying the acronym against the DBpedia Linked Data, but reverted to scraping. The magnifying glass is a nifty tool of course, but IMHO doesn’t add much on the informative side.

The static map gives a quick overview of all species and their location. This works OK when the number is relatively small. However, the more variety there is, the harder it is to discern between different colors. Transparency (alpha) does the best it can to show that indeed there are multiple points on the same spot. With my expanded color palette however, the colors became so elusively light that I was forced to reduce transparency. Although you can customize the gbifmap function, with my limited skills I didn’t succeed in passing my own alpha value, so I modified the function accordingly. Note to self: find out the best practise of how this kind of modification should be done.

The GeoJSON maps were a positive surprise. Out of the Gist box, the JavaScript code produces nicely detailed maps, and in hot spots points are clustered. Marker symbols and colors could of course be different across species. Here, I simply use one red park2 marker in all.