You are currently browsing the tag archive for the ‘GIS’ tag.

Greenfield 2In our last outing we put together a simple map.  Having reached this point, the wise cartographer asks itself (when discussing cartographers I default to non-specific, non-human pronouns):  “Am I done?  Does this map suffice?”

Actually, the answer to this question should have been determined before we even started.  One of my favorite professors used to say “Begin every project with a proposal.  It’s the easiest and best way to know when you’re done.”

Anyway, if the map you’ve already made suits your purposes, congratulations.  There is no reason for you to continue reading this, so by all means go back to whatever your favorite activity happens to be.  I promise I won’t take it personally.  If, however, you need a less simple map – or if you’re just like me (any map worth making is worth making pretty) – then please read on.

The plan here is to avail ourselves of some of QGIS’s advanced stylizing techniques to apply a variety of better looking symbology to the map.  We will work in an order the reverse of that which we used last time (top down as opposed to bottom up) because this neatly follows a least-to-most complicated trajectory (with one exception).


Our general goal here is to construct a believable illusion of three dimensions.  We aren’t going to try to achieve true 3D (or – more accurately – 2.5D), instead we’ll just use a few tricks to fool the eye.  In the case of the structures layer we’ll just apply a simple drop shadow.  Double-click on the ‘Structures’ layer to open the Properties window.  Click on ‘Style’ in the left-hand sidebar if it isn’t highlighted already.  Select a lighter color for the polygons (I used a grey: #707070), then check the ‘Draw effects’ box in the main area of the window.  Click on the small star that resultantly turned yellow to open up the Draw effects window.  Check the ‘Drop Shadow’ box on the left, change the Offset to 4 Map Units, change the Blur Radius to 1, and change the Blend Mode to Normal.  Click ‘Okay’ a couple of times and watch the map redraw itself.



Roads come in various shapes and sizes.  There are many different attributes of this layer we could use to symbolize our roads, but I think the wisest (read: easiest) way to go is to symbolize them by relative size.  If you right-click on the Title of the ‘Roads’ layer (in the Layers Panel), a menu appears.  Click on ‘Open Attribute’ and a window opens showing you the database that’s attached to the layer (most layers have them).  Feel free to have a look around, and don’t worry if much of it looks like gibberish.  The first column of the attribute table is called ‘Class’ and it is the one we will be using to symbolize the layer.  The road classes are single-digit codes ranging from 1 to 6 (scroll down the MassGIS ‘Roads’ page for an explanation of the classes).  The short explanation is the smaller numbers represent bigger roads and vice versa.  We want to symbolize thicker lines for larger roads, so we’ll just have to tweak it a bit.  Double-click on the ‘Roads’ layer to open the Properties window and change the line style from ‘Single Symbol’ to ‘Graduated’.  Click on the ‘ε’ symbol to the far right of the ‘Column’ selector to open up the Expression Dialog window.  Enter 10-“CLASS” for the expression and click ‘okay’.  Change the Method to ‘Size’ and input a range of 4 to 16.  Bump the Classes up to 6 and change the Mode to ‘Quantile (Equal Count)’.  Click on the word ‘Change’ in the Symbol selector to open up the Symbol Selector window.  Select your line, change the Pen Width to 0.46 Map Units and set the Cap Style to ‘Round’.  Add another line, move it down in the hierarchy, then change its Pen Width to 0.86 Map Units, change its color to grey (#707070) and set its Cap Style to ‘Round’ as well.  Check the Draw Effects box and click on the yellow star.  Select ‘Outer Glow’, change the Spread to 3 Map Units, set the Transparency to 0 and change the color to the same grey as the line itself.  Click ‘okay’ a couple of times and watch the roads redraw themselves.

Almost there.  If you zoom in to get a closer look at the roads you will find that they look funny.  This is because each road is made up of a series of small, straight lines connected together into longer lines that more accurately represent the less-than-straight reality of roads.  Each of these small lines are drawing individually, which makes random grey lines cross over our roads in annoyingly large numbers.  Don’t worry.  We can fix this.

Reopen the Layer Properties window to get back to the layer Styles.  Click on the button labeled ‘Advanced’ and select ‘Symbol Levels’ to open the Symbol Levels dialog.  You will see two columns, Layer 0 and Layer 1.  Everything in the Layer 0 column should say ‘0’ and everything in the Layer 1 column should say ‘1’.  Check the ‘Enable Symbol Levels’ box.  This tells QGIS to draw everything in Column 0 first, then go back and draw everything in Column 1.  Click ‘okay’ twice and watch the roads fix themselves.



This layer is the exception.  It just needs a little tweaking to make it look differently than lines painted on.  Darken the color a bit (I used #007ac9) and add an Outer Glow:  Spread of 2 Map Units, Blur Radius 3, 50% Transparency, color #46f3f7.



When maps are made in 2.5D they are most commonly “lit” from the upper left corner.  I don’t know where this convention came from, but it is so strongly ingrained in us that when maps are “lit” from the bottom they look backwards to us (mountains look like valleys and valleys look like mountains).  Knowing this, we can take advantage of it to make objects on our maps look ‘3D’, either in a positive or negative fashion.  For our bodies of water we’ll go for a negative, making them appear to be cut into the ground surface rather than just sitting upon it.  We do this by applying a highlight to the lower right-hand side and a shadow on the upper left-hand side.

But first we’ll have to specify which polygons we want show and which ones we’d like to hide.  When we look at the MassGIS web page for the dataset we’re using, we see two separate columns in the attribute table that describe the water features.  The first is called WETCODE, and it separates the features into 28 distinct categories.  These categories are also conveniently detailed in another column of the attribute table (IT_VALDESC).  For our purposes, though, this is far more detail than we need.  Instead, we’ll use another, similar column called POLY_CODE, which serves much the same purpose but with only 11 categories.  For our symbology we’ll want to show any features that delineate open water (we’ll include marshland in this group) and hide any other features.  We’ll do this by using Rules Based styling.

Open the layer style and change it from Single Symbol to Rule-based.  Double-click the existing rule (No label) to open the Rule properties dialog.  Click on the Expression button (…) to the right of the ‘Filter’ bar to open the Expression String Builder.  We will want to separate the open water features, which are those with POLY_CODEs of 1,2,6,9 and 10 (for this map we could skip 9 and 10, but we will include them in the name of thoroughness.  Sloppy work is habit forming).  To do this we will build the somewhat awkward expression POLY_CODE=1 OR POLY_CODE=2 OR POLY_CODE=6 OR POLY_CODE=9 OR POLY_CODE=10.  Then we add two additional Simple Fill layers to our symbol, which we will style in order from the top down.  The first we color with the same color we used for Streams (#007ac9), turn off the outline and add an Inner Glow:  20 Map Unit Spread and a darker color (#005b93).  The next is the shadow layer, which we color with a darker shade (#005488), turn off the outline and offset negative 8 X and 8 Y Map Units.  Finally we do the highlight layer, which we color lightly (#70b5d7) and offset positive 8 X and 8 Y Map Units.  Finally, we make the entire layer semi-transparent (a setting of 25 works well).



For our contours we’re going to want two discrete thicknesses (or ‘weights’) of lines.  A heavier line (called an Index) occurring periodically and a lighter line (called an Interval) occurring everywhere in between.  Because our data will make it easy to do so, our Index lines will occur every 30 meters (if you look at the attribute table you will see a column called ELEV_M.  This is the elevation of each line in meters, and the interval of the lines is 3 meters.  So every 30 meters we get a line that’s a nice round figure – 60, 90, 120, etc).  Since we have hills instead of mountains here in New England, 30 meter Indices are workable without being too crowded.

Before we start, though, we should make our lives easier by combining the two contour layers we’ve been using.  Because we opened zipped files, we cannot edit either of the layers as they are, so we first must convert one of them to a shapefile (a format that has more than its share of issues.  But it works so we’ll just run with it).  Right-click on the Greenfield Contours file and select ‘Save As’.  Choose the appropriate co-ordinate system, browse to the folder you want to save it in (creating said folder if necessary.  I used Maps→Data→Greenfield→Vector→Contours and called the file Greater Greenfield Contours).  Then zoom to the extent of the Montague Contours layer (by right-clicking on it) and select the entirety of it with the Select Features tool.  Copy the features to the clipboard and return to the previous zoom using the Zoom Last button.  Select the Greater Greenfield Contours layer, toggle editing on, paste the features onto it, then save the changes and toggle editing off.  Then clean up by deselecting all features and removing both the Greenfield Contours and Montague Contours layers (by right-clicking them).

Now open the Layer Properties window for Greater Greenfield Contours.  Change the style from Single Symbol to Rules-based.  Double-click the undefined rule and label it ‘Index’.  Open the Expression String Builder and build the expression: floor( “ELEV_M”/10)=( “ELEV_M”/10).  Change the color of the line to #665640, set the Pen Width to 3 Map Units, then open the Draw Effects dialog.  Give it an Inner Glow (2 Map Unit Spread, 3 Blur Radius, 0% Transparency, color #f8a05c) and an Outer Glow (4 Map Unit Spread, 3 Blur Radius, 0% Transparency, color also #f8a05c).

Add a second rule labeled ‘Interval’.  For this one build the following very similar but significantly different expression:  floor( “ELEV_M”/10)<>( “ELEV_M”/10).  Change the color to #665640 and set the Pen Width to 1.25 Map Units.  Give the line an Inner Glow (0.75 Map Unit Spread, 3 Blur Radius, 50% Transparency, color#f8a05c) and an Outer Glow (4 Map Unit Spread, 3 Blur Radius, 50% Transparency, color #f8a50c).  “Okay” your way out of all the dialogs and watch the map redraw itself.



And there we are.  We took our basic map and made it pretty.  Nice work.  It should be noted that not all of this symbology works well at all zoom levels.  If you zoom into and out of various areas of the map you will see what I’m referring to.  Creating symbology that works well for various zoom levels is its own art form and is beyond the scope of this post.  My intent here is only to introduce you to a small sample of the vast styling power of QGIS.  Please continue to explore further on your own.  You won’t regret it.


GreenfieldSo you heard about this GIS thing and you thought to yourself that it might be kind of cool to be able to make your own maps.  But then you looked at the software and decided that it’s rather more dense and complicated and esoteric than you’d like, so you decided that maybe you’d pass on making your own maps and instead just use whatever you could find on the Internet.

Fair enough, but the truth is that making your own maps really isn’t very hard.  Sure, the software may be a little dense and complicated and esoteric, but so is most every word processor on the market.  But this doesn’t stop any of us from firing up Word and using it to write a letter.  The same goes for email.  How many of you can claim to know more than 2% of the full capabilities of Gmail?  I know I can’t.

GIS software can indeed perform a great many complex and wondrous scientific operations, but a working knowledge of them is not a prerequisite for using the software.  With a little bit of knowledge and the right data, pretty much anyone can make a respectable map.

Which is what we’re going to do.  Relax – I’ll walk you through the process.  It probably won’t hurt at all.

The first order of business is to secure the software we’ll be using.  There are a bunch of good options out there, but for today’s exercise we’ll be using QGIS, because it’s solid and dependable, but also because it’s my personal favorite.  Head on over to their download page and download and install whatever version of the latest release is appropriate for your system (I’ll be using 2.12.3 throughout).  I have chosen the latest release over the LTS (long term support) version because it includes a variety of new features that are well worth having.  Besides – if you decide to stick with this GIS thing you’ll be updating your software on a regular basis.

Once you have installed QGIS, fire it up.  Right off the bat there are a couple things we’ll want to do.  The first is to simply rearrange the UI to suit our purposes.  The UI is completely customizable (and easily so – just click on things and move them around), so it’s a simple matter to arrange things to better suit our own habits.  In time you’ll determine the setup that best suits you – in the meantime I’ll show you the setup that suits me (out of the box, at least).  The next thing we want to do is change the CRS of our project.  When we first fire up QGIS it defaults to EPSG 4326 (also known as WGS 84).  Maps are projected, necessarily so because when mapping we are representing a three-dimensional object (Earth) two-dimensionally.  Therefore we must project a map in order to draw it.  Projecting is inescapably imperfect, therefore every map distorts something in some way.  We use a CRS (co-ordinate reference system) to project a map.  WGS 84 is intended for maps of a global scale, but our map will be on a local scale (in Massachusetts).  Therefore we’ll change the CRS  to a projection that distorts less on our more focused scale.  For this map we’ll use EPSG 26986, NAD 83/Massachusetts Mainland (Meters).  If you want to know more about projections and co-ordinate systems, a great resource can be found here.



Now we need data.  For this map our task will be easy (but don’t get used to it.  Finding appropriate data is usually the hardest part of GIS), as Massachusetts has a wonderful State GIS agency called (you guessed it) MassGIS.  We’re only going to use six datasets for our map, which really isn’t much as these projects go.  It’s still data, though, and it needs to be managed, so let’s talk about that for a minute.

GIS is driven by data.  As such, practitioners tend to amass enormous amounts of data.  Data that must be organized.  Maps are made out of data, and a failure to properly wrangle said data can be crippling.  Where did I put that data from 6 months ago?  Which one of the 14 folders called “Project X” did I put it into?  Or is it somewhere else?  It’s a road dataset, so did I put it in the huge folder called “Roads”?

I didn’t just make these questions up.  They are questions I have actually had to ask myself at earlier, less organized points in my career.  Trust me.  Properly managing data is the single most important part of modern GIS.  As an added bonus, well organized data is easier to back up.  The value of this cannot be overstated.

This is how I do it.  I start with one master folder called simply “Maps” (in Windows you can make this folder a distinct Library.  I strongly advise doing so).  This folder is where I keep everything – data, projects – everything.  The advantage of this is that I simply have to back up my “Maps” folder and I can sleep soundly at night.  The disadvantage is that my “Maps” folder can get pretty damn large (and I don’t even work with Big Data.  If I did I think I would have to store it elsewhere).  Inside my “Maps” folder are two other folders:  “Data” and “Projects”.  My “Projects” folder contains a myriad of folders (usually one per project), as well as a separate folder called “Saves”.  This is where I keep all the ‘Saves’ of projects, whichever software I happen to be using.  This way all my software defaults to the correct location whenever I ask it to open a project.

The “Data” folder gets considerably more complicated.  And personal.  Its contents are more individualized and dependent upon the work most often performed and the types of data needed to do so.  In my case, I work most often (almost exclusively) in Massachusetts.  Because of this, MassGIS is my go-to source for data.  So it just makes sense for me to organize my data in a manner similar to the method MassGIS uses to organize their data.  Much of their data is organized by town, and I follow suit.  My “Data” folder slowly fills with folders named for towns in Massachusetts.  Inside each town’s folder I further separate the data into folders for vector data (points, lines, polygons) and raster data (images, digital elevation models).  MassGIS organizes some of its data differently, and for this data I include separate folders, appropriately labeled.  For instance, I have a folder called “Statewide” for those datasets that encompass the entirety of Massachusetts.

For this project we will be using two statewide datasets and four town datasets (three from one town, one from another).  Start here to get them.

Again, the choices you make will be your own.  I’m just describing how I do it.

First, I scroll down the MassGIS download page until I reach the section titled ‘Transportation’ under the ‘Infrastructure’ heading in the ‘Vector Data’ section.  There I click on ‘Mass DOT Roads’, then ‘Download these layers’.  I then scroll down to ‘Greenfield’ (in the left-hand column) and click on the filename ( to initiate the download.  I download the file to Maps→Data→Greenfield→Vector→Roads.  I click my way back to the main download page, then in the next section (‘Other Facilities and Structures’) I download ‘Building Structures (2D, from 2011-2014 Ortho Imagery)’  in a similar fashion ( to Maps→Data→Greenfield→Vector→Structures).  Then, under the ‘Physical Resources’ heading, I download ‘Contours (1:5,000)’ from ‘Elevation and Derived Products’ (while I’m there, I also download this file for the next town over: Montague).  Lastly, I move on to ‘Inland Water Features’ and download ‘MassDEP Wetlands (1:12,000)’.  This one is Statewide, and it is divided into two layers, a polygon layer ( and a line layer (, both of which I download to Maps→Data→Statewide→Vector→Hydro.

Now that we have our data we can start building a map.  Our first order of business will be to navigate to our ‘Maps’ folder in QGIS’s Browser panel and then add it to our favorites (right-click on it).  This will greatly facilitate our future mapping endeavors.  Then lets add in our two contour datasets (all you have to do is double-click on them in the Browser Panel – QGIS can read a zip file) and symbolize them (by double-clicking on their names in the Layers panel).



Maps are built in layers, and the order of our layers should roughly mimic the world we are attempting to depict.  So our next order of business should be to add and symbolize our two hydro (water) layers.  For some reason, they come from MassGIS double-zipped, but all that costs us is an extra mouse click.



Next, lets zoom into a more focused area of interest, then add our road and structures layers, symbolizing them as we go.



Lastly, lets rename our layers in the table of contents as something more human-readable (just right-click on them individually) and then save our project.



So now we’ve made a map.  What do you say we put it onto a piece of paper so it can actually be a useful thing?

Click on File→New Print Composer.  Once open, I first change the paper size to the one my printer spits out (ANSI A: Letter).  Then I use the ‘Add New Map’ button to add a map to the composition by clicking and dragging corner to corner.  Then I click on the ‘Item Properties’ tab and change the scale of the map to 1:24,000.  This is because we here in Massachusetts still backwardly use feet and inches, so if I make the scale 1:24,000 on my printed map one inch will equal 2,000 feet.  This makes my paper map a useful and easy-to-use tool in the real world.  Those of you fortunate enough to live in the modern world can do the same thing with the metric system, just with easier math.

Once the scale is set, I change my project from a picture into a map by adding a scalebar, North arrow and title.



Switch back to your map window and save the project.  Congratulations!  You made a map.  Feel free to print it out and use it in the real world.

Now, in all truth and in the interest of full disclosure, we’ve barely scratched the surface of the cartographic capabilities of QGIS.  And we haven’t touched upon its processing or analytical capabilities at all.

But that’s okay, because we did accomplish what we set out to do – we made a custom map from scratch.  A map that we can print out for use in the world (alternately, we could export it as an image for use in a document or on a web page).  And it wasn’t terribly difficult, which is the point I set out to make.

Baby steps.


CatamountSo my friend Drew is writing another book.  The last time he did so he asked me to produce some maps for him, a process I detailed previously, and which we plan to repeat (roughly).  This time, Drew’s book is about an individual, who happens to have been born close to where I live.

Being the kind of person he is, Drew has decided to set foot upon all the places most significant in his subject’s life.  Naturally, his birthplace fit’s into this category, so I applied myself to determining where, precisely, said event actually occurred.

Drew already had some pretty good ideas about this, having narrowed the search down not just to a small Massachusetts village but to a particular mountain within said village (coincidentally a mountain I had had occasion to map several years ago, so I already knew my way around rather well).

To narrow our search even further, Drew gave me a copy of a map he had found in a manuscript buried in the local library:

Stacy Map

On the surface, it looked to be a workable map, so I converted it into a format I could work with and set about georeferencing it with QGIS.

The result was less than pleasing.  When it came down to it, I was not working with a map so much as I was trying to georeference a rough sketch.  With a capital “R”.  Under normal circumstances, this is where the process ends, and I simply produce a wildly inaccurate result with a pile of disclaimers attached to it.  But this was for an old friend, which is considerable coin.  Besides – I had some spare time with no pressing projects.

So I turned to one of my favorite mappers, Fredrick W. Beers.  There are Beers maps for everything within a sizeable radius of here and, being an archaeologist and historian, I have had to consult them on numerous occasions.  I can personally vouch for their accuracy whenever they depict objects that are still on (or under) the ground.

The mountain in question – Catamount Hill – is located in the town of Colrain Massachusetts, so I acquired the Beers map which includes said village and hill, which I then clipped to just the area of interest:


Unfortunately, the Beers map doesn’t show any of the landmarks that specifically interest Drew, but it does show a half dozen or so that are also on the aforementioned sketch map (the Stacy map), so I figured I could use the Beers map as a stepping stone.

The first order of business was to georeference the clip of the Beers map.  I have found that GIS software is only reasonably good at warping images, so I usually begin this process by helping them along with a little Photoshop chicanery.  As you can see, the Beers map shows a decent amount of local roads, and I have found through experience that most roads in New England haven’t moved much in centuries.  So I opened up QGIS and used a current local road shapefile to make a template image:


I then opened the template image in Photoshop, made the background transparent, and loaded the clipped Beers map underneath it.  Using Photoshop’s image transforming tools, I manipulated the Beers clip until it approximated the template image.  The result I saved for use in georeferencing:


Note that neither the Beers map nor the Stacy map had any real reason to use any sort of projection whatsoever, so I used Stateplane for the template (and for the rest of the georeferencing process, as well).

I then loaded the tweaked Beers map into QGIS and georeferenced it to the same road file I had used to make the template.  Once that was done, I created a point file of all the landmarks on the Beers map that I planned to use to georeference the Stacy map.  Then I added every other feature on the Beers map because I’m me.

I knew the roads on the Stacy map were out of kilter, so I decided to just ignore them altogether.  I loaded the map as an unprojected and unreferenced raster into QGIS and created a point file of all the features depicted on the map.  I named them all in a column in the table for use in labeling.  I then created a raster image of the labeled feature points, which I then georeferenced to the previously referenced Beers map, using the common features as control points.  I used this final, fairly accurate replica of the Stacy map to create a new point file of all the features in the Catamount Hill vicinity, numbered, typed and labeled in the table accordingly:


Finally – since I wanted to be able to use all of this to locate features on the ground – I reprojected everything and packed it into TileMill, which I used to create tiles for use with an app in my phone (similar to one I wrote about previously, only updated for use with a later OS).

Next week Drew and I plan to go out and put all this to the test.  Part of my plan is to locate a feature that intrigues me just because of its name:  Aunt Dinah’s Stairway.  I’m dying to know what it actually is.  Unfortunately, locating it will entail traveling to a place called Catamount Hill and hiking past landmarks called Bears’ Den and Black Snake Swamp.

Wish me luck.


Field MapThe overwhelming majority of my professional choices have been heavily impacted by my love of the outdoors.  I am at my happiest in remote locations, far from the presence of other humans.  This has led to fields like forestry and archaeology and even GIS.  But when it comes to GIS, I’m more of a Field Operative than anything else.  By that, I mean I am more likely to find myself out in the field gathering and/or verifying data than I am to be at a computer manipulating data gathered or created by someone else.  Because of this, field maps have always figured prominently in my tool kit.

For a long time, paper maps more than sufficed (still do in a pinch), mainly because they were the only show in town and therefore had to.  Truth is I still don’t go into the field without a paper map and compass, if only because their batteries never wear out and the only GPS fix they require is the one in my head.

More recently, I expanded my tool kit to include some sort of hand-held unit, usually a Garmin.  It wasn’t long before I figured out how to plug my own custom maps into these devices (although I cannot now remember the software I used to do so), neatly laying the information I needed over the pre-existing base maps built in to the devices.

Then smartphones came along.  At first glance you’d think such devices would be tailor-made for my purposes, but it turned out to be otherwise.  Like much of our world, smartphone apps are driven by the market, and a ridiculously high percentage of smartphone users have absolutely no use whatsoever for custom field maps (they do, however, really need to know where the closest cup of coffee is).

So I set out to write my own.  It turned out to be much easier than I had envisioned.

Beside the ability to use my own maps, the next biggest requirement I had was the ability to work offline.  There isn’t much connectivity in the kinds of places where I need field maps, so I needed the ability to store the maps in the device.  Google Maps allows for local caching (for later offline use), but I’m an archaeologist.  I need a field map that looks less like this:

Google Map

And more like this:


Not surprisingly, Google Play is not overflowing with apps along these lines.  I can’t imagine they’d be big sellers.

Which left me with only one recourse.  What follows is how it went.  This will not be a comprehensive app-writing tutorial.  I simply intend to tell you – in general terms – how I wrote this app, and I will include all the necessary code in case you’re inclined to construct your own.  If you know nothing about app development but want to learn, there are numerous resources available all over the Internet.  Google is your friend.

I use Eclipse when I write apps, which is simply a matter of personal preference.  I mention this only because it means that my description of the process will necessarily be specific to my personal development environment, so if you want to play along you might have to adapt things a bit if your personal preferences differ.

Our target end result is a simple map app with minimal bells and whistles.  I didn’t want to clutter the code too terribly, so wherever I felt a need to explain something, I placed a marker comment saying “Note 1” or similar.  I will address these notes in the body of this post.  Let’s get to it, shall we?

First, you’ll have to create a new Android app.  Call it whatever you want.  I called mine “FieldMap” for obvious reasons.  Before we can start plugging code in, though, we have to import a couple of libraries and add them to our build path.  These libraries are OSMDroid (available here.  I used osmdroid-android-3.0.8.jar) and SLF4J Android (available here.  I used slf4j-android-1.5.8.jar).  Import both of these into your “libs” folder, then right-click on each of them in turn and click on ‘Build Path’ –‘Add to Build Path’.

From here, it’s just a question of plugging the necessary code into the appropriate places.  You should, of course, feel free to alter any or all of it to suit your needs.

Main Activity (

package com.fieldmap;

import org.osmdroid.views.MapController;
import org.osmdroid.views.MapView;
import org.osmdroid.views.overlay.MyLocationOverlay;
import org.osmdroid.views.overlay.ScaleBarOverlay;
import android.location.LocationManager;
import android.os.Bundle;
import android.provider.Settings;
import android.view.Menu;
import android.view.MenuInflater;
import android.view.MenuItem;
import android.content.DialogInterface;
import android.content.Intent;
public class MainActivity extends Activity {

MyItemizedOverlay myItemizedOverlay = null;
 MyLocationOverlay myLocationOverlay = null;

 private MapController myMapController;

 public void onCreate(Bundle savedInstanceState) {

 LocationManager service = (LocationManager) getSystemService(LOCATION_SERVICE);
 boolean enabled = service.isProviderEnabled(LocationManager.GPS_PROVIDER);

 if (!enabled) {

AlertDialog.Builder builder = new AlertDialog.Builder(this);
 builder.setTitle("GPS Disabled")
 .setMessage("You forgot to turn on the GPS.")

//Note 1

.setPositiveButton("Fix It", new DialogInterface.OnClickListener() {
 public void onClick(DialogInterface dialog, int id) {
 Intent intent = new Intent(Settings.ACTION_LOCATION_SOURCE_SETTINGS);
 .setNegativeButton("Quit", new DialogInterface.OnClickListener() {
 public void onClick(DialogInterface dialog, int id) {


 final MapView mapView = (MapView) findViewById(;





 myMapController = mapView.getController();

 myLocationOverlay = new MyLocationOverlay(this, mapView);

myLocationOverlay.runOnFirstFix(new Runnable() {
 public void run() {

 ScaleBarOverlay myScaleBarOverlay = new ScaleBarOverlay(this);

 protected void onResume() {
 // TODO Auto-generated method stub

 protected void onPause() {
 // TODO Auto-generated method stub

 public boolean onCreateOptionsMenu(Menu menu) {
 MenuInflater inflater = getMenuInflater();
 inflater.inflate(, menu);
 return true;


 public boolean onOptionsItemSelected(MenuItem item)
 switch (item.getItemId())
 myLocationOverlay.runOnFirstFix(new Runnable() {
 public void run() {
 final MapView mapView = (MapView) findViewById(;


 Intent intent = new Intent(Settings.ACTION_LOCATION_SOURCE_SETTINGS);
 return true;

Note 1:  I include icons in my apps as a matter of form.  It is, however, completely unnecessary.  Whether you include one is up to you.

Note 2:  OSMDroid has built-in zoom controls.  Since pretty much every single device that’s capable of running this app has a touch screen (and it’s safe to assume the person holding the device knows how to use it), I don’t see any reason to clutter up screen real estate with ‘+’ and ‘-’ buttons.  If you would prefer it otherwise, it should be fairly obvious how to bring this about.

The Main Activity calls for an Itemized Overlay to house our compass and scalebar (necessary components of any map).  This particular class doesn’t already exist in the Android SDK, so we’ll have to create it ourselves.  Create the Class inside your package (under ‘src’).

My Itemized Overlay (

package com.fieldmap;

import java.util.ArrayList;
import org.osmdroid.ResourceProxy;
import org.osmdroid.api.IMapView;
import org.osmdroid.util.GeoPoint;
import org.osmdroid.views.overlay.ItemizedOverlay;
import org.osmdroid.views.overlay.OverlayItem;


public class MyItemizedOverlay extends ItemizedOverlay<OverlayItem> {

private ArrayList<OverlayItem> overlayItemList = new ArrayList<OverlayItem>();

public MyItemizedOverlay(Drawable pDefaultMarker,
 ResourceProxy pResourceProxy) {
 super(pDefaultMarker, pResourceProxy);
 // TODO Auto-generated constructor stub

public void addItem(GeoPoint p, String title, String snippet){
 OverlayItem newItem = new OverlayItem(title, snippet, p);

public boolean onSnapToItem(int arg0, int arg1, Point arg2, IMapView arg3) {
 // TODO Auto-generated method stub
 return false;

protected OverlayItem createItem(int arg0) {
 // TODO Auto-generated method stub
 return overlayItemList.get(arg0);

public int size() {
 // TODO Auto-generated method stub
 return overlayItemList.size();


And that pretty much concludes the heavy lifting.  Now all we have to do is tweak a few things.  The drawable folders can be completely ignored if you’re so inclined.  They will already contain launcher icons provided automatically by Eclipse (unless you chose to replace them with your own), and the folders need no other attention unless you want to include your own graphics (see Note 1 above).  We will need to address the layout, as follows:

Layout (main.xml)

<RelativeLayout xmlns:android=""
 tools:context=".MainActivity" >



Also, we need to configure a menu:

Menu (main.xml)

<menu xmlns:android="" >

 <item android:id="@+id/menu_center"
 android:title="@string/menu_center" />
 <item android:id="@+id/menu_quit"
 android:title="@string/menu_quit" />


And we also need to give some values to our strings (under ‘values’):

Strings (strings.xml)

<?xml version="1.0" encoding="utf-8"?>

<string name="app_name">Field Map</string>
<string name="action_settings">Settings</string>
<string name="menu_center">Center Map</string>
<string name="menu_quit">Quit</string>


Lastly, we have to alter the Manifest.  Eclipse will automatically target the latest Android API, but doing so produces a minor clash with OSMDroid.  This issue arises when we overlay the compass and scalebar.  In order to work around the issue, we simply have to tell the app to use an older API.  It’s a simple matter of changing the target SDK to ‘11’.

Manifest (AndroidManifest.xml)

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android=""
 android:versionName="1.0" >

 android:targetSdkVersion="11" />

 <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
 <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
 <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />

 android:theme="@style/AppTheme" >
 android:label="@string/app_name" >
 <action android:name="android.intent.action.MAIN" />

<category android:name="android.intent.category.LAUNCHER" />


At this point you have a functioning map app, although it currently lacks a map.  In fact, if you changed one line of the Main Activity (just after Note 2) from “mapView.setUseDataConnection(false);” to “mapView.setUseDataConnection(true);”, you would have a fine app that pulls map data from OpenStreetMap (you could even pull your map tiles from other sources, like MapQuest).  However, our original intent was to use this app offline, so we now have to give ourselves some local map data, for which we will turn to one of my favorite tools, TileMill.  I won’t go into the mechanics of map production using TileMill – there’s plenty of good resources over at MapBox.

Once you’ve made your map, it’ll be time to get it into the app.  My initial searches on the subject eventually led to this post, which led me to believe such a thing was possible.  It looked as though it may be a little tricky, but I assumed I could beat my head against it long enough to figure out how to make it happen.

This turned out not to be the case.  In truth, it turned out to be rather simple.  In fact, I’d go so far as to call it stupid simple.  It goes like this:

Connect your device as a hard drive to the computer housing the map you exported from TileMill (the .mbtiles file).  On your Android device, navigate to the SD card (/mnt/sdcard).  Create a folder on the SD card called “osmdroid” (without the quotes).  Place the .mbtiles file in the osmdroid folder.

And you’re done.  The app will now see and play nicely with your TileMill-generated map.  See?  I told you it was stupid simple.

But wait – there’s more.  And it gets even better.  Let’s say you need detailed maps of two different and geographically divergent areas in one day.  The logical conclusion is that you’d have to create a large map encompassing both areas.  While this would indeed suffice, the resulting map would likely be far larger than you’d like to stuff into a mobile device.  So it’s a good thing you don’t have to.  If you instead make two separate maps of the different areas, the app will automatically use the one closest to your geographic location when you start the app.  It will not, however, switch between maps as you travel between them (it stays on the one you started with).  This is easily corrected by stopping and restarting the app (besides – just use Google Maps if you need help getting from A to B).

A couple notes on the app itself:  Android does not allow for programmatically starting a device’s GPS (for security reasons).  Because of this, the app checks to see if it’s on at startup.  If the GPS isn’t enabled, the app offers to take you to Location Services to turn it on.  Also, if you exit through the app (Menu-Quit), it automatically takes you back to Location Services to remind you to turn the GPS off (it’s a serious battery hog).  The other button on the menu centers the map on your current location (in case you lose your way while looking around).



PoppleAs a diehard lover of old maps, I have been especially excited by Map Dorkia’s recent rediscovery of the charm of bygone cartography.  I came to GIS via history and archaeology, so my generalized love of maps stems from an earlier, more specific love of old maps.  I think this also accounts for the fact that while maps come in many shapes, I am most fond of the ones that depict an actual physical landscape.  So I was thrilled a short while ago when Kartograph arrived on the scene (skillfully showcasing a stunning map of Italy), and I was equally happy when MapBox debuted AJ Ashton’s “Pirate Map”.

While both these maps are quite beautiful and therefore just plain nice to look at, they seem to be laboring under the misconception that beauty was the only strong point of old cartography.  Because of this, they are missing an important point (in my opinion the most important point) of old maps.

This shortcoming was perfectly illuminated by my wife when she entered my office just after I encountered the aforementioned Kartograph map of Italy.

“What’s that?”  she asked.

“A very pretty map,” I answered.

“It is pretty,” my wife agreed.  “But there isn’t very much information on it, is there?”

As usual (although don’t tell her I said so) my wife was exactly correct.  The map sure is pretty, but it conveys very little information (the same can be said of the “Pirate Map”).  As I’ve said before, the whole point of a map is to convey information.  Beauty can certainly serve as part of the means toward this end, but we should be careful to remember that it is not the end in and of itself.

Take a look at this map, created in 1733 by Henry Popple (click on the link or the image to see the whole map at the Rumsey Collection):


As easy to read as it is easy to look at, isn’t it?  Anyone have any trouble figuring out where the forests are?  The mountains?  Delightfully easy to tell the difference between large cities and small towns, isn’t it?  The only issue I can find with this map of any sort is that it’s a bit overcrowded in the label department.  This, however, is simply a shortcoming of the medium, one which we can easily overcome.  More on this in a bit.

Modern maps, on the other hand, tend to be much less easy to read.  Often, features like forests are depicted with colored blobs, the explanation of which are necessarily supplied in a legend of some sort (clearly, if we’re lucky.  If we’re not lucky, we may be wasting our time trying to differentiate between the green blobs that are forests and the blobs of a slightly different shade of green which are parks).  While techniques such as this do (technically) suffice, they are rather inelegant.  I have long felt (and often remarked) that every entry in a legend represents a failure on the part of the cartographer.

The ideal solution lies in a mixture of modern data and tools coupled with classical cartographic techniques.  Why represent a forest as a green blob instead of populating it with trees?  The capability certainly exists – it’s easy enough to convert a forest polygon into a teeming mass of randomly placed points.  Points which can then be represented graphically as trees.

But then we run into the problem of numbers.  A forest measuring in acres (or even square miles) can take a lot of points to fill.  This means a boat-load of tiny little pictures of trees that need to be drawn.  The problem isn’t so bad if we’re just producing a static map – then it’s just my machine that has to do all the work, and it only has to do it once.  But what if we want to serve this up as a web map?  Then we’re talking about rendering insane numbers of little trees at both ends of the exchange.  A ridiculous expenditure of resources under the best of circumstances.

Until TileMill came along, that is.  I’ve talked about TileMill before, and it’s long past time I revisited the subject.  When last we discussed it, TileMill only ran in Apple and Linux machines, and it was no small task to get it up and running (and it tended to be a little buggy at that).  Now it’s a simple matter of searching the Ubuntu repositories (for Linux) or just downloading an installer (for Windows).  I assume it’s equally as simple to set up TileMill for OS X.  And today the bugs are few and far between (and tend to be squashed with great alacrity and enthusiasm).

Using TileMill, we can take current data and old cartographic techniques and join them into an accurate, attractive and (above all) easy to read basemap:


Do click on the map and check out the fully functional version.  Please be aware that I created this map simply as a proof of concept, so there are a few limitations:  1) The map is running on a crappy little server on the floor in my office, and it’s being hosted on a stupid little web page my ISP provides free of charge.  So please don’t hit it too hard [Update:  After posting this last night, I was contacted by Eric from MapBox (thanks, Bill).  Eric offered me a sweet deal for MapBox hosting, and by sweet I’m referring to another word with a double ‘ee’ (no – not ‘beer’).  While I believe in the abilities of my little server, I am also not stupid.  So I happily took Eric up on his offer.  The upshot of this is that the map is now being served by MapBox and therefore you should all feel free to kick the crap out of it].  2) Even though I largely confined the map to geographic features, we’re still talking enormous amounts of data here.  Because of this, I restricted the map to 7 levels of zoom and a geographic area that represents roughly the central third of Massachusetts.  And we’re still talking an MBTiles file that takes up well over a gigabyte.  3) I am certain there are numerous errors on the map.  If I had been making this map for a client rather than as an experiment I would have spent more time seeking them out and removing them.  4) I did not (nor do I now) give a crap about the page surrounding the map.  I simply slapped together a fast and dirty container for the map itself, literally in less time than it has taken me to write this sentence.  If you have any criticisms regarding it, know that I am completely and blissfully indifferent toward them.

While I am less than completely pleased with the end result, I am quite happy with what the result represents.  I don’t feel the techniques I employed are terribly far removed from those employed by Popple and his contemporaries (although I did freely use some colors, I could have achieved much the same effect in greyscale), and in the cases where I diverged I’m sure they would have approved (since I have the luxury of scale and zoom control, my ability to comprehensively label a map without overcrowding it would probably make Popple green with envy).  Mostly, I’m pleased by the fact that the map is almost completely self-explanatory.  In fact, the only explanations of any kind on the map are the labels, all of which are simply placenames.

All things considered, I think I’ll put this project in the ‘win’ column.

Notes:  There are a few changes I would make to the map if I were producing it “for real”.  Besides the aforementioned data cleansing, the most important of these would be the labels.  For this project, I baked the labels directly into the tiles, simply because I felt the map needed some sort of labels.  Ideally, though, the basemap wouldn’t contain any labels at all.  Instead, I would apply all labels over the basemap, well after the fact (I’ve heard that CartoDB plans to eventually allow home-brewed MBTiles to serve as basemaps on their platform.  I can’t think of a better scenario for serving up my nefarious schemes).  And I would most certainly include more labels than are currently present on the map (streets, for example).

The “trees” on the map are placed randomly within the confines of forest polygons.  If the polygon data differentiated between deciduous, coniferous and mixed stands, it would be a simple matter for the graphics to represent them accurately.

Nuts And Bolts:  The data I used for this map came mostly from MassGIS.  I also availed myself of some data from USGS and OpenStreetMap.  The data was tweaked and altered and arranged and (in some cases) soundly beaten using Quantum GIS and ArcGIS Desktop.  Graphics were produced and/or altered using Photoshop and Inkscape.  The font used for the labels is called Essays 1743TileMill was (of course) used to bake the tiles.  TileStream is serving the tiles from my hapless little server (it was a bit of a bear to get TileStream up and running.  These instructions by Nathaniel Kelso finally got me where I needed to be).  If I were going to serve up maps like this “for real”, I would avail myself of MapBox hosting rather than using my own server. [Update 2:  I unforgivably forgot to mention Leaflet, which played a major role in the speed with which I was able to deploy my map on a web page.  Since switching the map over to MapBox hosting, Wax has also played a part in the process.]


Map Ninja

There was a time when the road to Map Ninja-hood was long and perilous.  It entailed arduous journeys to spend years studying with monks in temples on Tibetan mountaintops.  Advancement came through fierce, deadly battles against Map Ninjas who ranked above you, precariously fought in windswept mountain passes or on rickety suspension bridges over precipitous chasms.

Or maybe you just had to be able to map temples on Tibetan mountaintops, windswept mountain passes and precipitous chasms.  But it was still pretty tough.  It used to take some serious hard work and dedication to become a Map Ninja.  These days, though, it’s pretty much a walk in the park.  As I discovered this morning.

This morning, my buddy Jake and I went out into the woods to map some property he owns.  We had done so once before (something like eight years ago).  Since then, one of Jake’s neighbors had had a survey done that disagreed with what we thought about their shared boundary.  Today we went out to see who was right (as it turns out, they were).

The last time we did this, I went prepared with a compass, maps, and a Garmin.  We spent an entire day gathering data.  I then spent hours (possibly even days) squeezing the data out of the Garmin and turning it into something I could use to draw a pretty map.  Today, it went like this:

The equipment I used was much the same.  A compass and maps (items I always bring into the woods with me).  Instead of a Garmin, though, this time I just took along my smartphone, which runs the Android operating system.  I installed two apps into my phone in preparation for today’s festivities.

The first one is called GPS Status and Toolbox.  It’s a very nice little nuts-and-bolts kind of GPS utility (and it also has a donation-ware version that I strongly recommend).  It tells you a ton of stuff about your location and status, includes a compass, and even has a level bubble to help you keep your device perpendicular to the planet when you’re taking a bearing.  It doesn’t allow you to store waypoints, but it does allow you to share your current location.  The second app makes this amount to the same thing as waypoint storage.

The second app is Evernote.  If you’re not familiar with Evernote, you should take steps to correct this.  It has been one of the world’s most useful utilities for years, and taking it along in your pocket makes it virtually indispensible.

Armed thus, we set out for adventure (I also tracked our progress with My Tracks, just because I could).  It was a beautiful day to be out on a mountaintop, and the data acquisition process turned out to be deliriously simple.  I started GPS Status and Toolbox running at the outset.  Any time I wanted to save a location, I simply shared it via Evernote (adding any necessary notes to myself in the process).  Since we were miles away from any form of connectivity, Evernote stored the data locally (i.e., in my phone).

Three hours later, Jake and I climbed into his truck and headed back to my house, armed with our newly acquired data (as well as a bonus slew of geo-located photographs).

This is where it goes from deliriously simple to insanely easy.  When we get back to the house, my phone connects to my wireless network.  Immediately, Evernote syncs from my phone to their servers, which in turn immediately syncs with my computer.  So by the time I walk upstairs and into my office, my computer already knows all the data I gathered in the field (if I had had connectivity while in the field, my computer would have received the data virtually as I recorded it).  I then sit down at my desk and open Evernote.  Each note I recorded in the field contains the latitude and longitude of where I was standing when I recorded it but – thanks to GPS Status and Toolbox – the notes also contain links to the exact locations marked on Google Maps.

So I open a browser and sign in to Google.  Then I go to Google Maps and create a new map under ‘My Places’ called “Jake’s Land”.  Then I click on each link stored in Evernote in turn, adding each one to “Jake’s Land” from within Google Maps.  Inside of five minutes, I have a new saved map containing markers at every point I marked while in the field.

From there it’s a simple matter to export the map as a KML (if you don’t know how to do this, it goes like this:  click on the ‘Link’ icon [the one to the right of the ‘Print’ icon].  A window will open with a link to your map already highlighted.  Copy it and paste it into the location bar of a new browser tab or window.  Add ”&output=kml” [without quotes] to the end of it and hit ‘enter’).

And now I have a KML including all the waypoints I chose to record during our outing.   Since we’re dealing with a property boundary here, there is an obvious desire to connect the dots.  There are a variety of methods to employ toward bringing this about.  For the uninitiated, there is the simple expedient of Google EarthGoogle Earth has line and polygon drawing tools built into it, so it’s a quick and easy matter to open our KML file and draw lines connecting our waypoints.  If we prefer, we can draw the entire plot of land as a polygon.

Depending on our mapping needs, we could be done at this point.  We gathered our data, drew our map, and now we have what could be considered a finished product already packed into a portable and easily shareable format (KML allows for a great deal more ‘finishing’ if we so desired).  We could send our KML attached to an email, and any recipient could open it up in Google Earth (or even Google Maps in a browser) and play with it to their heart’s content.  And there are many other applications out there that can read KML (in fact, KML is based on XML.  If you change the name of your file from ‘myfile.kml’ to ‘myfile.xml’, Excel can open it).

There are a slew of GIS applications that can read and manipulate KML files and – being the Map Dork that I am – I will use one or more of them to trick out our gathered data and produce a final map for Jake.  But the fact is that within a half hour of my arrival home I was easily able to produce a passable map.  Given another hour (and using just a little basic knowledge of KML and HTML) I could have attached a decent amount of bells and whistles to it.  And all without dipping into any of the deeper mysteries of Map Ninjutsu.

Not exactly a pitched battle on a rickety suspension bridge, but hey – I’m getting a little old for that kind of thing anyway.


  • RT @DavidCornDC: Democracy dies in the darkness. It also dies if journalists pay more attention to tone than substance. 1 hour ago

Blog Stats

  • 24,022 hits


March 2017
« Jul