Guelph Lake Conservation Area – Part 1

Posted on July 4, 2016 by James McCarthy

A couple of weeks ago I had the chance to go out to Guelph Lake Conservation Area with a group of students who were creating sample plots to count instances of milkweed. They were doing this as part of a fourth year GIS project course. They had done the analysis ahead of time to determine the right number of plots and they went into the field armed with stakes and GPS units. My role was to show them how to use the GPS units to go find the locations of their plots.

They had a list of their plot locations as a printed table, and so the first thing I asked them was what order the points on the paper were in. I could tell by the lack of answers and the looks on their faces that they had not put any thought into ordering the points to minimize their walking distance. Instead they had to go through the points in the sequence they were listed on the paper. This resulted in the following walking path:

no-order

Total distance traveled to get all 33 sites: 2,634 m.

I thought this made a good teachable moment, especially given the hot sunny conditions we faced all day, so I decided I could illustrate that by generating an optimal path to the 33 sites.

To do this I used ArcGIS and Network Analyst. Through a series of steps I generated a network dataset that included a path from each plot to every other plot: network-dataset

Then ran a simple Route task, resulting in the following optimized route:

ordered

Total distance traveled on this route: 969 m, almost 1/3 of the path above. The lesson here, plan your field work!

There’s more data to come from this study as we did lots of GNSS testing while out in the field. I’m looking forward to diving into that data a bit more to see what we came up with.

inspecTile

Posted on April 5, 2016April 5, 2016 by James McCarthy

inspecTile was born out of a need to perform side-by-side comparisons of tilesets generated with Mapnik.

inspecTile

I have been using this tool internally for a while now, but I thought it was time to promote it a bit because others may find it as useful as we have. The way it works is simple. You load a tileset into each frame, and then when you pan or zoom one map, the other map moves accordingly. This makes it easy to do things like compare tilesets before and after changes, and compare different cartographic alternatives.

What you need are two tileset URLs in the form expected by a Leaflet TileLayer. Something like:

http://{s}.somedomain.com/blabla/{z}/{x}/{y}.png

The directories hosting the tiles must be web accessible. Then it’s just a matter of zooming and panning to compare your tilesets.

I’m hoping to add new features in the future, including:

More methodical tile comparisons, such as stepping through each tile individually at each zoom level.
Better (or any) documentation.
Embedding of the tileset URLs and current center point and zoom level in the application’s URL so that comparisons can be shared. That way if you need to show a specific view of one or both tilesets you can simply copy the current URL and send it to anyone and they will see what you see.

Feel free to play with it and let me know what you think!

Map Comparison

Posted on July 29, 2015 by James McCarthy

Lately I’ve found myself with the need to compare tilesets generated from Mapnik for our campus map project. We are generating our tilesets by pulling data from OpenStreetMap, loading those data into a PostGIS database, and running mapnik with a couple of stylesheets we’ve put a lot of work into. The workflow is good for us because we end up with something that’s relatively automated.

One manual intervention step that we currently have is the need to compare the old and new tiles when we generate a new tileset. Suppose a new building comes online on our campus and we put that building into OpenStreetMap, pull the data into our DB, and generate new tiles. Since OSM is collaboratively edited by anyone on the web there is always the potential that something on our campus has been changed other than the new building we’re interested in. The trouble, of course, is finding those changes.

One approach is to look at the differences in the data before generating tiles and determining if anything is relevant, and there are tools to do that. There are also ways to find all of the edits since I specific date (I think), and there are tools to handle that case as well. When we get to the point of having more automatic updating of the data we use to render our tiles we’ll probably need to investigate that.

What I wanted, though, was a simple way to look at two tilesets side by side and compare them visually by browsing through them. I found myself doing this by having one version of the tileset attached to one instance of our map in one Git repository, and another attached to another instance of the repository. Since we load our tile URLs from config files that are outside of the code base all we need to do is edit the config files and we’re in business. However this left me with the need to open two windows, split them across my monitor, and move and pan them in tandem. In other words I would zoom the one on the left, then zoom the one on the right, pan the one on the left, pan the one on the right, etc. After doing that a few times I sketched out the first draft of a UI for a tool that would handle this for me. I would give it two tile URLs and they would be loaded into two Leaflet maps. I would then tie the zoom and pan animations together and voila, an easier way to compare tilesets visually.

I put together the first draft of this tool in about forty minutes tonight and have the basics ready to go. I’ll iterate on this over the next few weeks and hopefully will have something to publish shortly!

On Being “The Goose Guy”

Posted on June 27, 2014June 27, 2014 by James McCarthy

Two years ago the Student Success Office at the University of Waterloo launched their GooseWatch program, aimed at getting students and other members of the campus community to report goose nest locations so they could be put on a map and communicated to the campus. For those that are unaware, UWaterloo is well known for having a large population of Canada Geese. The geese are a minor inconvenience in day-to-day campus life, but around nesting season they can get aggressive and protective. The GooseWatch map they created showed people where nest locations were reported on campus and also shared some tips of how to handle an encounter with an aggressive goose. A few days after that map showed up, myself and my colleagues in the Mapping, Analysis, and Design department looked at the static map and thought it could be more interactive. We’ve been dabbling with campus data and building campus mapping applications for a few years and one of the common themes we encounter is people wanting to do wayfinding on campus. The lack of a quality routing dataset had always been a hindrance, but we had recently acquired some campus path data through our connections at Esri Canada and MappedIn. Around the same time, the University’s Open Data API began hosting the submitted nest locations which made it easy for us to drop them on a map rather than having to digitize them by hand from the static image. Using those two datasets, in the span of an afternoon we had a demo version of what we called the “Goose Avoider” up and running. It’s function was to take a start and end point and find a route on the campus path network that didn’t come within some predetermined distance of goose nests. Someone in our department quickly had the idea to make the distance customizable, so we added what we affectionately named the “fear slider”. It let you set how afraid of geese you were, and the higher you set the fear level the further it would route you away from nests. The tool queried an ArcGIS Network Dataset we had published with the path data, the University’s Open Data API, and was built using Esri’s JavaScript API. We had a few main motivations for building the tool:

Promote the University’s Open Data API and show the University that putting as much data as possible into it is really useful for developers. This campus has a plethora of talented programmers and designers, so the more data we make available to them the more creative applications we will see. Getting data opened has often been a struggle, so I’ll take any opportunity I can to show the benefit to doing so.
Create a demo application that uses the stack of tools we teach most often in GIS project courses.
Provide a handy tool for the campus community, having a little fun in the process.

When we finally promoted the tool about a week after we started it we were pleasantly surprised at the uptake. We assumed people would get a kick out of it, and indeed it did: The Faculty of Environment (where our department is housed) wrote a story about it and put in on their front page. Some geospatial blogs like AnyGeo wrote stories about it. It was mentioned in the Macleans OnCampus blog. Twitter reaction was awesome to see, and apparently it was even mentioned on the local CTV news as part of a story on the goose population on campus. I say apparently because I didn’t actually see it, I only heard through word-of-mouth. I was asked to demonstrate the application at a booth at the 2013 GO Open Data conference, and I also delivered a lightning talk on the experience. From the launch on April 19, 2013 to May 9th, 2013 we had 2,506 requests for safe routes. All in all it was a fun experience and while we had thoughts about other things we could do with the application nesting season is only a few weeks and so we put it aside once the hype died down. Fast forward ten months and I received an email from the Student Success Office looking to join forces to create a single application that combined their crowdsourcing efforts with our ability to build interactive mapping applications. After a month or so of design and development work we were ready to launch GooseWatch 14. The Student Success Office does an awesome job of engaging students on our campus, giving them both timely useful information and fun distractions (and lots in between), and they saw this as a bit of both so it was a natural fit. Because we actually had some time to prepare this year we were able to create a new application from the ground up that not only encompassed the routing functionality we had built last year, but also gave users the ability to snap a picture and send in nest locations they found around campus and have them show up on the map. We built an administrator interface that allowed the SSO to approve and reject pictures and nest locations for a bit of quality control, and went live in late March/early April. We were sitting on the finished application waiting for nesting season to begin which took a while because we had a particularly long winter here in Waterloo. The response was once again excellent, especially with the promotional skills of the SSO behind us. Beyond the internal response which had eclipsed last year’s, we also had media inquiries. I did a radio interview with Craig Norris for CBC KW’s The Morning Edition, and just yesterday spoke to Tim Alamenciak of the Toronto Star and was quoted for his story on controlling Canada Goose populations. As mentioned in Tim’s story we had dozens of nest and picture submissions and thousands of visitors to the new Goose Watch site during this nesting season. All of this attention on a fun little app has lead me to realize that some people think I am somehow qualified to discuss goose behaviour, which I am most certainly not. I believe the interviewers I linked to in this post quickly figured that out while talking to me and smartly focused on the tool I was building rather than the goose behaviour angle. The truth is that I have no secret strategies for avoiding them or dealing with them, and I have no education on the subject. I’m a geomatics geek that likes maps and gets a kick out of building applications that people can use. I think spatial information is incredibly powerful in people’s day-to-day lives and any chance I get to showcase that is one I’ll have fun with. That does not make me any sort of expert on the subject, however. I spent my undergrad writing code, doing spatial analysis, and staring at rocks, minerals, and fossils. I still do two of those things every day, you can probably guess which one has dropped off of the radar (though I still think rocks are cool). As I’ve mentioned to people I know, this thing took on a life of its own and was a fun exercise in how to manage a project from conception to development to production to promotion, something I’ve never really experienced before. Being part of that entire life cycle as a developer is something you don’t get to do every day.