One of our clients raised an interesting issue the other day – that most of their staff couldn’t see the newly flown aerial imagery we had used to create their disturbance mapping products this year (and for the last few years, in fact).  So we thought we’d couple this need with our regular sprint day format to see what we could do to solve it in a day.

Why?

The background to this sprint was that a fellow colleague of our client mentioned that the level of detail of their imagery was not good.  We were both surprised by this as the imagery was pretty good, so we did a little more digging to find out why this may have been the case.  It turned out that the colleague probably did not have the ability to view the digital imagery and was likely looking at either print outs or screen shots.  Our team knew we could solve the issue by giving our client easy access to their valuable data.  A perfect example for a sprint, a real-world issue with an opportunity to learn some software.

What we did

After fleshing out the requirement of our day long sprint we thought about solutions.  We were quick to realise that a web-service was the way to go, we had the imagery and only needed to serve it out for our client to access.  It turned out that the devil was in the detail, more later, but we were all pleased with the result.

Technically we would need a environment to host a web page and the software to efficiently serve large quantities of imagery to potentially multiple concurrent users.  The web environment was all ready to go, and Andrew had done some research into which software could be used to serve the imagery.  He found that TileMill and Leaflet were worth investigating.  The way I understand it was that we would pre-process the imagery data into a tile service which Leaflet would serve out to the web page, it hangs together like this:

Sprint day came and we drew up a plan of attack for the team who had volunteered.  Data would have to be pre-processed, the HTML page created and then the data served to the web page.  Am I making this sound easy?  I had the fun part of learning to design the layout of the web page with Mel’s help – oh, and keep the team on the tightly scheduled track.  In terms of design we didn’t have time to completely consider the interesting points Andrew found a while back – here’s a summary of this article (How real people use web maps):

1. Single-Topic maps get 3 times the traffic of the traditional Map Portal
2. 60% of map traffic comes directly from search engine requests.
3. Auto-complete drives clean user queries
4. Map Usage is Spiky
5. People Look Up Info on Maps, and Leave
6. People Actually Interact with Balloon Content
7. People Rarely Change Default Map Settings

Again, something to follow up on.

What we got

Let’s see, unfortunately we can’t let you use the live site as it has our clients data on, but this will give you a impression:

There were a few things that we could improve on, but after one day we had achieved the requirement, we had a web page giving easy access to imagery.  There were various software combinations that could have been used, but TileMill and Leaflet were unfamiliar to us so we were able to discuss the pro’s and cons at the end of the day will everyone at the wrap-up presentation.  We were reminded that imagery data is often large and therefore time consuming to move about, especially when copying to our external web host, so we decided to use a sample area of imagery for the Sprint day.

The format of the sprint worked well.  The short time-frame had to be considered and we careful to check that we all understood our scope and communicated with each other frequently to manage any unexpected events.  Some of the technical outcomes were; a better understanding of alternative software to serve imagery; more people now understand or were re-freshed in design and HTML code; and any nice-to-haves were parked.  There are many other benefits to running such short R&D projects besides the obvious one of testing ideas.  Together as a team we made the best use of the resources we had over the short time.  Communication was important to ensure everyone stayed on task and we all knew of any issues that could have required a re-think.  It was rewarding to hear colleagues talking animatedly about future possibilities, Piers fortunately remembered something I forgot, to test the service on a mobile platform.  What happened?

 It worked – well, but not perfectly, that sounds like an extension to this Sprint!

Summary

So, we spent a day of R&D investigating innovative methods to resolve the issue a client had of not being able to access imagery.  The structure of a Sprint day is adaptable and therefore required management and communication to get the job done within scope.  We learnt much from the day including the potential benefits of software and the infrastructure required to support such a service; project management skills for very short run tasks, and the importance of staying on track.  We succeeded in meeting our objective of the day, to enable easy access to imagery, with a few minor tweaks we will share our results with our client.

Very interested to hear your comments – below, tweet, email, phone 045-999-0257, or catch me at ISPRS in Melbourne Aug 23 – 30th.