Field Maps

The 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:

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 (MainActivity.java)

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.app.Activity;
import android.app.AlertDialog;
import android.content.DialogInterface;
import android.content.Intent;
public class MainActivity extends Activity {

MyItemizedOverlay myItemizedOverlay = null;
 MyLocationOverlay myLocationOverlay = null;

 private MapController myMapController;

 @Override
 public void onCreate(Bundle savedInstanceState) {
 super.onCreate(savedInstanceState);
 setContentView(R.layout.main);

 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.")
 .setCancelable(false)

//Note 1
 .setIcon(R.drawable.hdpi)
 //

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

builder.create().show();

}
 {
 final MapView mapView = (MapView) findViewById(R.id.mapview);

//Note2

mapView.setBuiltInZoomControls(false);
 mapView.setMultiTouchControls(true);

//

mapView.setUseDataConnection(false);

 myMapController = mapView.getController();
 myMapController.setZoom(15);

 myLocationOverlay = new MyLocationOverlay(this, mapView);
 mapView.getOverlays().add(myLocationOverlay);

myLocationOverlay.runOnFirstFix(new Runnable() {
 public void run() {
 mapView.getController().animateTo(myLocationOverlay.getMyLocation());
 }
 });

 ScaleBarOverlay myScaleBarOverlay = new ScaleBarOverlay(this);
 mapView.getOverlays().add(myScaleBarOverlay);
 }
 }

 @Override
 protected void onResume() {
 // TODO Auto-generated method stub
 super.onResume();
 myLocationOverlay.enableMyLocation();
 myLocationOverlay.enableCompass();
 myLocationOverlay.enableFollowLocation();
 }

 @Override
 protected void onPause() {
 // TODO Auto-generated method stub
 super.onPause();
 myLocationOverlay.disableMyLocation();
 myLocationOverlay.disableCompass();
 myLocationOverlay.disableFollowLocation();
 }

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

 }

 @Override
 public boolean onOptionsItemSelected(MenuItem item)
 {
 super.onOptionsItemSelected(item);
 switch (item.getItemId())
 {
 case R.id.menu_center:
 myLocationOverlay.runOnFirstFix(new Runnable() {
 public void run() {
 final MapView mapView = (MapView) findViewById(R.id.mapview);
 mapView.getController().animateTo(myLocationOverlay.getMyLocation());
 }
 });

break;

 case R.id.menu_quit:
 Intent intent = new Intent(Settings.ACTION_LOCATION_SOURCE_SETTINGS);
 startActivity(intent);
 this.finish();
 }
 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 (MyItemizedOverlay.java)

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;

import android.graphics.Point;
import android.graphics.drawable.Drawable;

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);
 overlayItemList.add(newItem);
 populate();
}

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

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

@Override
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="http://schemas.android.com/apk/res/android"
 xmlns:tools="http://schemas.android.com/tools"
 android:layout_width="match_parent"
 android:layout_height="match_parent"
 tools:context=".MainActivity" >

 <org.osmdroid.views.MapView
android:id="@+id/mapview"
android:layout_width="fill_parent"
android:layout_height="fill_parent"
android:clickable="true"/>

</RelativeLayout>

Also, we need to configure a menu:

Menu (main.xml)

<menu xmlns:android="http://schemas.android.com/apk/res/android" >

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

</menu>

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

Strings (strings.xml)

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

<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>

</resources>

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="http://schemas.android.com/apk/res/android"
 package="com.fieldmap"
 android:versionCode="1"
 android:versionName="1.0" >

<uses-sdk
 android:minSdkVersion="8"
 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" />

<application
 android:allowBackup="true"
 android:icon="@drawable/ic_launcher"
 android:label="@string/app_name"
 android:theme="@style/AppTheme" >
 <activity
 android:name="com.fieldmap.MainActivity"
 android:label="@string/app_name" >
 <intent-filter>
 <action android:name="android.intent.action.MAIN" />

<category android:name="android.intent.category.LAUNCHER" />
 </intent-filter>
 </activity>
 </application>

</manifest>

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).

Enjoy.

TileMill Revisited

As 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 1743.  TileMill 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.]

Enjoy.

Woody, Jack, and Lines in the Sand

In sixty-nine I was twenty-one and I called the road my own
I don’t know when that road turned into the road I’m on

– Jackson Browne

Except in my case it wasn’t ‘69, I was 16, and I’ve never stopped calling the road my own.

See, when I was in High School, I read Kerouac and Kesey, I read about Woody Guthrie and really listened to his music, and I – along with a bunch of my friends – succumbed to the siren song calling us to stand on the highway with our thumbs out.  A month later I returned dirtier, stronger and better than I had ever been.  I came away from the experience with a better understanding of the road, of the United States of America and – most important – a real understanding of freedom.  Travelling just for it’s own sake (and in a fashion that leaves you at the mercy of fate) – with no money, no real destination and no discrete itinerary – entails a level of freedom that the average person doesn’t really understand.  Reading Kerouac and listening to Woody can net you a glimpse, but you’ll never know the reality of it until you experience it firsthand.

A large part of that freedom is ownership.  When you develop such an intimate relationship with the road, you begin to understand the communal – no, universal – aspect of the road.  The road that – in effect – belongs to everyone.  The road that actually deserves capital letters and will hereafter be given them.  The Road that exists outside of boundaries and municipal spheres of influence (even while passing through them).

This is The Road that OpenStreetMap is about.  The Road that belongs to each and every one of us.  This is why Woody Guthrie would love OSM (although I’m pretty sure Kesey wouldn’t understand it and Kerouac wouldn’t give a rat’s ass about it).  Because a central aspect of OSM is about returning ownership of The Road to us, the people.  You know – the Great Unwashed.

And it is ours, you know.  And not just because we paid for it.

Lately, I’ve been thinking a lot about ownership and how we (the collective, all-inclusive ‘we’) fit into it.  And how ownership differs from possession.  This train of thought started with this discussion.  This post added fuel to the flames.  Now we’re down to the stew my brain has made of it.  You might want to look away.

So the question that bubbles to the surface of my brain stew is:  Do lines in the sand (i.e., political boundaries and/or parcel data) have a place in OSM?

My immediate reaction is to say “no”.  For technical and philosophical reasons.  On a technical level, these are not the sort of data that the average person on the ground is able to provide.  I can easily take my GPS out into the world and accurately record streets, buildings, rivers, railways, bus-stops, parks, bathrooms, pubs, and trees.  These are all concrete physical features that any one of us can locate on the surface of the Earth and record.  More importantly, they’re features that anyone else can check.  Or double-check.  And this – in case you haven’t noticed – is the strength of OSM.  It’s self-correcting.

But we can’t do this with the lines in the sand.  Where – exactly – is the border of your town?  Can you stand on it and take a waypoint?  Sometimes you can.  Most roads have convenient signs telling you when you’re leaving one political sphere of influence and entering into another.  Here in New England, there are often monuments of one sort or another at pertinent locations to mark the dividing line betwixt one town and another.  And these are certainly locations that can be marked – as points.  If you’re not willing to walk the entire border, however, you shouldn’t draw the line in the sand.  Sometimes you can’t just connect the dots.  Actually, most of the time you can’t.

Of course, we often have the option of downloading border data from various (presumably authoritative) governmental sources.  But then we run into the question of whether we have the right to upload that data to OSM.  Personally, I don’t think the payoff is worth the expenditure of neurons necessary to figure it out.  Especially because the ‘authorities’ don’t always agree:

A quick comparison of the counties of western Massachusetts.  The green background with black outlines was provided by the USGS.  The semi-transparent grey foreground with white outlines was provided by MassGIS.  Note the differences.  For the record, the data provided by MassGIS is vastly superior to that provided by the USGS.  Trust me.

Parcel data is even worse.  Frankly, I don’t know why anyone would want to include parcel data on any map, but then I’ve had a lot of experience with it and therefore I am cognizant of its uselessness.  Parcel maps are more for bean counting than anything else.  Their primary purpose is to delineate taxation and therefore they tend to conform to a “close is good” standard.  They don’t need to be accurate – tax collectors are quite happy to round up.  Take it from a guy who has had occasion to check a large number of parcel maps against the truth on the ground – they are grossly inaccurate (in these parts, it used to be thought that the ground trumped the map and/or the deed.  I’ve seen many maps that have ‘corrected’ acreages on them.  These days, though, the thinking tends in the other direction.  After all – what you paid for is what the paper says you paid for).

On a purely philosophical level, I feel as though lines in the sand have no place in OSM.  Lines in the sand are all about possession.  They are someone’s way of saying “This land is my land.  It’s not your land”.  In my far from humble opinion, this is pretty much the polar opposite of what OSM is about.  OSM is about taking ownership back from the line-drawers and the so-called authorities.  It’s a declaration that the map belongs to us – all of us – and we’d kind of like it to be an accurate map.  If it’s all the same to you.

But then, Kate had an excellent point (she does that, and is almost never annoying about it):  people tend to want to know where they are.  While I agree that this is, indeed, the case, I don’t think borders need to be a part of the picture.  When people go from Town A to Town B, they like to know where they are when they are actually inside the town proper.  But I question whether the average person cares when they cross over the border between Town A and Town B (except, of course, for the 3-year-old in my back seat who always wants to know.  Lucky for him, the driver’s seat is occupied by a daddy with a very accurate personal GPS in his head).  And while I think there is a place in the world for some borders (as I said before, we need some way to determine who’s responsible for plowing the roads and collecting the garbage), I doubt whether that place is on a ‘People’s Map’ like OSM.

Is there a solution?  I think so, and I think Andy hit upon it pretty soundly in the post linked to above:  labels.  With absolutely no lines whatsoever, people have no difficulty identifying points and areas if a map is sprinkled with labels of judicious size and font.  If you doubt me on this one, just look at this map:

If a couple Hobbits can find their way from the Brandywine river to the bowels of Mount Doom without borders, I think maybe OSM can do without them, as well.

The Process

Update:  Just got an email from Barb (Drew’s wife) with details of the upcoming publication of Drew’s book, Red Ink:  Native Americans Picking up the Pen in the Colonial Period.  Feel free to buy it as soon as you can.

 

At this stage in my life, making a map has become very much like writing or driving – it’s something I largely don’t think about.  These are all tasks that I usually just sit down and do.  Only rarely do I actually have to think about the process involved in what I am doing.  Recently, though, I made a couple of maps that I really thought about, beginning to end.

An old friend (Drew) stopped by for a visit a short while ago (by ‘old friend’ I mean one of those few who has been a good friend through thick and thin since high school and still seems magically blind to my faults).  He asked me to put together maps for a book he’s authored that’s heading for publication.  I assented, of course.  Hell – I would have done so even if we hadn’t been drinking.

Anyway, I anticipated questions about the maps, so I spent a lot of time thinking about the choices I was making and why I was making them.  The questions never materialized (I should have realized that someone who’s been a friend this long would know enough to just get out of my way and let me do what I do), but anticipating them forced me to articulate my creative process in a fashion I haven’t experienced in years.  I thought I’d share it with you all.

Disclaimer:  As a Map Dork, I am almost completely self-taught.  Those of you who have actually taken classes and/or earned degrees in this stuff may find this to be painfully obvious or stupidly off base.  My only response to this is:  “Hey – it works for me.”

As you may have guessed, I spend a lot of my time looking at maps.  All sorts of maps.  These days, I see a lot of ugly maps.  And you know what, kids?  Ugly maps don’t work.  Allow me to explain.

A map is a document.  Like any other document, the point of a map is to convey information to an audience (the audience being whoever is looking at it).  In order for this to occur, the audience actually has to look at the map long enough to absorb whatever information the map is intended to convey.  Since the overwhelming majority of humanity does not particularly enjoy looking at ugly things, chances are an ugly map will fail in its purpose.

Part of the problem (I’m sad to say) is the advent of geographic information systems (GIS).  GIS has taught us that maps are, in fact, collections of data.  While it is a good thing to know this Basic Truth, sometimes it leads to the erroneous conclusion that the map is about the data, rather than the other way around.  When this occurs, bad maps happen.  In an army hygiene film sort of way (“Men – don’t let this happen to you!”), allow me to demonstrate:

This hideous monstrosity is not something I cooked up just to make a point.  It’s a detail of a real map a company actually paid a GIS firm to produce.  It’s so damn ugly it’s almost beautiful.

Simple is good.  I cannot stress that enough.

I’m not entirely clear on the details of Drew’s book (I haven’t read it yet), but I know it has a lot to do with 17th- and 18th-century New England, specifically in regard to English settlements and Native ‘Praying Towns’ therein.  I know this because he needed me to produce maps that depicted these things (a lot of e-commerce has bounced back and forth between here and Texas as of late.  That’s right – Texas.  Poor Drew and his family are Liberals In Exile).

Luckily, the sort of maps Drew wanted are the sort I like to make.  Maps of landscapes.  Coming to GIS through archaeology and history, I’m particularly drawn to maps that depict things as they are (or were) on the ground.  It may (but probably won’t) surprise you to know that maps do not always depict a physical landscape.  This is as it should be – not all maps are trying to convey physical information (such as maps of the internet or mind maps), while others only loosely refer to actual geography (like the annoying red/blue maps we Americans are stuffed into every four years or the iconic London Tube map).  Personally, I’m most comfortable when dealing with the actual face of the planet.

Drew wanted maps of two specific landscapes: one of the Boston/Cape Cod/Rhode Island area (Map 1) and one of the eastern New York/western Massachusetts and Connecticut area (Map 2).  The only restrictions being that the maps needed to be black and white (greyscale, technically), and they had to be easily readable at a size typical of a scholarly work (let’s say 8” x 6”).  I approached them the same way I approach any area I want to map.  I first looked for the Big Reality.

Every location has the Big Reality.  It is the single enormity that pervades life in a specific location.  The Big Reality is often a geographic feature of some sort (a volcano, a river, a mountain range, a desert, an ocean), but oft-times is of a different nature (making paper, the hostile neighbor to the south, winter, tourism, growing corn, jazz).  Every place has the Big Reality, though (some have more than one).  It is huge, and it affects almost all aspects of life, but usually not overwhelmingly so.  Generally the Big Reality runs in the background, as it were.

Living in close proximity to both areas (as well as having gotten a degree in history from a New England university) made determining the Big Realties for both maps a cakewalk.  For Map 1, the ocean.  Map 2, the mountains.

The problem with the Big Reality is that it can be rather tricky to map (this is especially true if the Big Reality is less tangible than a geographical feature).  It needs to be pervasive but not overwhelming.  Unmistakably present, but not hitting you over the head with its presence.  In a word, the Big Reality should be the background.  In Map 1, this was achieved with a simple drop shadow.  In Map 2 with a slight bump.  It pays to spend a lot of time thinking about a map before you begin to actually produce it.

Both maps needed clear distinctions between British settlements and Native ones.  The looming pitfall here was the lure to overdo it.  We often underestimate the human brain’s ability to notice subtle differences.  For Drew’s maps, I made the distinctions through slightly different symbology and separate fonts.

Which brings me to another point I cannot stress enough:  choose your fonts with care.

For these maps, I used two fonts – one for the English settlements and one for the Native settlements.  For the English settlements I chose a font I use often: Souvenir.  Souvenir has a few things going for it – it’s clean, it’s easy to read and (important for these maps) it has serifs.  In this case Souvenir has an added bonus that caused me to use it for the titles and other miscellany.  It is a font used regularly by the U.S. Geological Survey on their quadrangle maps.  Because of this, when many Americans see this font they automatically think ‘map’.  Also, it serves to lend a certain air of legitimacy to a map, which never hurts.

The second font I used to label Native settlements and spheres of influence.  To make a clear distinction from the British settlements, I wanted a font without serifs (sans-serif).  I also wanted a font that was more organic/natural looking.

A quick aside – many white people have funny ideas about Native American peoples (or any other aboriginal group, for that matter).  There is this tendency to think of them as Tolkein’s Wood Elves – living in an idyllic state, completely in tune with the natural world around them, at peace with all living things.

Crap.  This way of thinking presumes the existence of the ‘Noble Savage’, which is, in fact, a myth.  The truth is that Native Americans were and are human beings, and you know perfectly well that humans tend to be annoying, stupid and downright mean.  Put another way, there is absolutely nothing, then or now, stopping any particular Native from being an asshole.  In fact, if you compiled a list of the meanest people in human history, the Mohawks would clock in pretty high on it.

However, the simple truth is that most Native groups at the time lived considerably ‘greener’ lives than their European contemporaries.  Even more important – they did so by design.  In general, Native American peoples did not view the natural world as something that needed to be beaten into submission.

What I was really looking for was a font that would appear more as a part of the landscape than stamped over it.  Something rounder and smoother.  There are a ridiculous number of fonts to choose from, but my decision became easy when I stumbled across a font called Pigiarniq.  It’s a font adopted by the Government of Nunavut that allows for all of their spoken languages to be represented uniformly.  This isn’t the only Native font out there, but it’s the only one I’ve seen that includes English characters.

Yes – pretty much any clean, sans-serif font would have gotten the job done.  But using Pigiarniq has style.  Don’t underestimate it.

Giving the Native labels a ‘natural’ feel was enhanced on Map 2 due to the added bump.  By adding the labels before applying the bump, it gives the labels a subtle appearance of being ‘draped’ over the landscape, as opposed to the British labels which were applied flat after the fact.

At the end of the day, I have to say I’m pretty happy with the way these maps turned out.  Drew is very happy, which is even more important.  Here’s a detail from each:

 

Appendix: The nuts and bolts (for any of you who care):

The data used for these maps came mostly from just a few sources – MassGIS, USGS and Google Earth (because I am who I am, I endeavored to place the English settlements in as historically accurate a manner as possible.  The easiest way to do this was to locate the town hall, town common, or original church.  Searching for a town hall, though, often gets you directed to a structure that was built in the 1990s.  I got around this by using Street View in Google Earth to get a look at the building in question.  In New England, it’s a pretty simple matter to identify the structure that’s three or four centuries old [I told you I found a use for Street View, Bill]).  Other data came out of Drew’s brain, based on extensive research.  I filled in a gap or two myself.  The projection used was NAD83 Stateplane.  Software used was QuantumGIS, Bryce and Photoshop.  No British or Native American settlements were harmed in the making of these maps.