Week Beginning 19th September 2016

I returned to work on Monday after being off sick on Friday last week.  I spent most of this week working for the SCOSYA project, further developing the atlas interface and the API.  On Monday I met with Jennifer Smith and Gary Thoms to discuss the interface and the outcomes from Gary’s meeting with the other project Co-I’s in York the week before.  We agreed that we would continue to use individual data points on the atlas for now and will investigate heatmaps at a later point.  Also that for now I will focus on the ‘expert interface’ and we will begin to look at the ‘public interface’ on the New Year.  One feature that Gary wanted to make use of fairly quickly was getting the API to spit out a CSV in addition to just JSON formatted data so he could use the data in Excel.  I managed to update the API to add in such a feature this week.  I wasn’t entirely sure how I would add the data selection type to the URL that gets sent to the API, but decided it made sense for this to be the first element that appears in the URL, before the ‘endpoint’.  I updated the API to include this extra information, added in the PHP code necessary to output a CSV file with column headings in the first row, and updated the atlas so that the data requests it sends to the API includes the data type.  I then updated the atlas interface to add a nice ‘download CSV’ button.  Now no matter what data the atlas is showing, a simple press of the ‘download’ button gives you the data in Excel, which I think is rather nice.

The biggest update I made as a result of the meeting was to completely overhaul the way limits on the data were handled.  Previously there were one set of limits for all attributes, even if multiple attributes were selected.  These limits let you set one age group and one rating level (see the screenshot in my 29th August post).  But the project team wanted limits to be applied per selected attribute, and for these to be a little more extensive.

So for each selected attribute the user needs to be able to select an age limit (all, 18-25 or 65+), select the minimum number of people at each location that rated the attribute (1-4 for ‘all’ age groups or ‘1-2’ for the others) and then select which rating levels they want to focus on (e.g. only ratings 4-5).  This took a fair amount of time to get working, both in terms of the user interface for the atlas and completely reworking the API to take all these new arguments.

After a lot of work I had an updated version of the user interface that worked as intended, and I hid the limit options away in a drop-down so you have to open them up if you’re really wanting to mess with the defaults.  Updates to the API were pretty far-reaching, but all appears to be working as intended, which is a relief.  You can see a screenshot of the interface with the new limits below:

scosya-leaflet-3

I also updated the ‘attribute’ table in the database and the content management system to incorporate a new ‘description’ field that will eventually be displayed somewhere in the atlas (although I’m not sure where as adding a ‘tooltip’ to a specific option in a select box seems to be somewhat tricky and the interface is already getting pretty cluttered.)

I also reworked the markers that I use in the atlas.  The reason for the change is I’m going to have ‘locations’ marked as squares and ‘attribute rating data’ marked as circles.  So on the ‘attribute’ map where there is no data for a particular attribute at a location this will still be marked on the map as a grey square.  However, I ran into a bit of an issue with using square markers on the atlas.  The circles I was using were a special sort of marker called a ‘circleMarker’, which have a fixed radius irrespective of zoom level.  Unfortunately, there is no such equivalent for other shapes.  To add a square marker to the map I need to set lat/lng boundaries for the square, meaning the size of the square changes when the zoom level changes (because the square refers to a particular area of the map).

This means when zoomed very far out the squares are tiny and when zoomed vary far in the squares are massive.  This made things rather confusing if you were zoomed in on the ‘location’ maps and then you switched to an ‘attribute’ map as the markers changed from huge squares to very small and exact circles.

What I’ve done to alleviate this is to revert to using ‘circle’ markers rather than ‘circleMarker’ markers.  I was using these in the first versions of the atlas and as with squares, their size is based on geographical data, meaning they change size based on the zoom level.  I’ve set the radius of the circle to be 2000 metres, which makes them legible when zoomed out and also makes them about the same size as the squares at all zoom levels.  I quite like that these markers give a less ‘exact’ position on the map when zoomed in, as we’re not supposed to be dealing with exact locations.  However, for some areas (e.g. the three Dundee markers) there is rather a lot of overlap and when zoomed out it is rather difficult to make out the different colours of the markers so we may have to revert to using circleMarkers instead.  If I do this and abandon squares we could maybe just have a hollow ring for a location with no data and a grey circle for places with data that doesn’t meet the criteria.

I also updated the API to include an index page that gets displayed if no endpoints are passed to it.  This lists the available endpoints and give some examples of their usage.  I think it works pretty well.  I still have a bunch of things on my ‘To Do’ list for the project that I’ll continue with next week.

Other than SCOSYA duties, I spent a few hours this week in an email conversation with Carolyn Jess-Cooke about a proposal she is putting together and then writing a first draft of a Technical Plan for her.  I’ve sent this off to her so I’ll just need to see if further tweaks are required.  I also spent some time reading through the documentation for Jane Stuart-Smith’s proposal and I participated in a meeting with Matt and Arts IT support about technical costs for the project.  We discussed servers, virtualisation and things like that.  I think we’ve got a clearer idea of what might be required now.