MapCruncher: integrating the world's geographic information.

Full text

Page 1

MapCruncher:
Integrating the World’s Geographic Information

Jeremy Elson, Jon Howell, and John R. Douceur
Microsoft Research Redmond

jelson@microsoft.com

ABSTRACT
Current large-scale interactive web mapping services such as
Virtual Earth and Google Maps use large distributed systems for
delivering data. However, creation and editorial control of their
content is still largely centralized. The Composable Virtual Earth
project’s goal is to allow seamless interoperability of geographic
data from arbitrary, distributed sources.
MapCruncher is a first step in this direction. It lets users easily
create new interactive map data that can be layered on top of
existing imagery such as road maps and aerial photography.
MapCruncher geographically registers and reprojects the user’s
map into a standard coordinate system. It then emits metadata
that makes it easy for anyone on the Internet to find the published
map data and import it. Interactive maps them become
distributed, seamlessly composable building blocks – similar to
images in the early days of the Web.
Categories and Subject Descriptors
H.2.8 [Database Management]: Database Applications – spatial
databases and GIS; D.2.6 [Software Engineering]: Programming
Environments – graphical environments; D.2.12 [Software
Engineering]: Interoperability; G.4 [Mathematical Software].
Keywords
Interactive maps, composition, mashups, geographic coordinate
systems, graphical interactive georeferencing, map projections,
approximate reprojection, decentralized publishing, image tiling.
1. INTRODUCTION
In the relatively short time since the introduction of online
mapping sites like Google Maps [8] and Microsoft Virtual Earth
[16], hundreds of user-created “mashups” have appeared. These
mashups cover a wide diversity of subjects. For example, Seattle
Bus Monster [19] plots public transportation routes in Seattle;
chicagocrime.org [2] highlights dangerous areas of Chicago;
RunwayFinder [18] summarizes weather and airspace surrounding
general aviation airports; housingmaps.com [11] shows real estate
prices. These specialized sites each display the data from their
particular application domain on top of maps and aerial imagery
supplied by Google or Microsoft.
While useful individually, mashups can be far more useful when
integrated with each other. Today, however, mashups are largely
independent. For example, to find cheap real estate in a low-
crime neighborhood, or find the public transportation near a
general-aviation airport, users must visit each mashup individually
and manually integrate the results. The goal of Microsoft
Research’s Composable Virtual Earth (CVE) project is to find
new ways of constructing geographic Web mashups so that they
can seamlessly interoperate.
Existing mashups are implemented largely in imperative code –
JavaScript that runs in the client. This design gives site designers
enormous flexibility, which led to the explosion of creative and
innovative mashups. Well-known standards for describing
geographically-tagged points, lines, and raster graphics had
already existed for many years (e.g., GML [17], GeoRSS [6]);
however, the sudden appearance of the mashups suggests many
applications are not well-served by these standards. The
combination of HTML and JavaScript allowed developers to go
beyond creating layers, to create applications. In other words,
mashup developers are using imperative code to customize exactly
how their application operates, rather than simply creating layers
declaratively whose user interactivity would be limited to “on”
and “off.”
A key design goal of CVE is to offer a mashup framework that is
sufficiently structured to enable composition, yet sufficiently
flexible to admit innovation. This interoperability balancing act is
common in distributed systems design, from domain-specific
frameworks such as the Flux OSKit [4], x-Kernel [15], and
stackable file systems [9], to application-agnostic schemes such as
Placeless active properties [3]. We plan to exploit the
geographical domain constraints to best achieve this balance.
1.1 MapCruncher
As a first step, we created MapCruncher, a tool that allows users
to add custom raster overlays onto the existing road and aerial
imagery provided by Virtual Earth or Google Maps. Overlays are
typically detailed maps, such as a bicycle route map, building
floor plan, or campus map. The resulting web site is an
interactive web map that features both the user’s maps and the
standard imagery. Like the underlying maps, user maps are pre-
rendered into small image tiles at a variety of zoom levels,
allowing the client to efficiently request the portions of a large
virtual image that are needed for display.
MapCruncher first assists in registering the foreign map into the
same (Mercator) coordinate system used by existing online map
sites. Users select correspondence points between their own maps
and existing maps, using road intersections or other recognizable
landmarks. Once enough points are selected, MapCruncher
estimates the transformation from the original map’s coordinate
system into Mercator by finding the best fit coefficients of a
second-degree polynomial; while inexact, the error is typically
small enough not to affect the results. MapCruncher then
reprojects the original map and renders correctly registered and
zoomed image tiles that can be seamlessly integrated with existing
imagery.

Page 2

Mashups created with MapCruncher do not restrict the
developer’s freedom to write arbitrary JavaScript that customizes
the experience of their end-users, satisfying one of our design
constraints for CVE. However, MapCruncher also emits metadata
about the mashup, such as its geographic bounds, the file naming
scheme for the tiles, and a brief description of the data as entered
by the user. Because this data is semantically meaningful, it
facilitates later discovery and integration of the imagery into other
applications. In addition, much of this data is encoded as
specially constructed strings that enable ordinary web search
engines to find mashups matching geographic criteria. This
combination of composability and discoverability takes us a step
closer to our goal of a system that is capable of more seamless
integration of geographic data on the web.
In the next section, we briefly describe the history of geographic
mashups on the web. In Section 3, we review some of the
difficulties in creating mashups using raster overlays. Section 4
describes approximate reprojection, the central technique used by
MapCruncher to simplify the creation of raster mashups. In
Section 5, we describe how this idea can be used to efficiently
generate a database of image tiles. We review deployment issues
and briefly describe a few sample applications in Section 6.
Finally, we conclude in Section 7 with some thoughts on how
MapCruncher might lead us towards an integrated and
composable Virtual Earth.
2. INTERACTIVE WEB MAPS AND THE
RISE OF MASHUPS
Online mapping services have existed for years. Until recently,
they all had the same general architecture: maps would be custom-
rendered from the underlying data on demand, in response to
users’ viewing requests. The only way to move the viewport was
by clicking discrete buttons (e.g., “north”). The web service
would then render a new custom map in a slightly different
position.
Starting in 2005, Google, Microsoft, Yahoo!, and MapQuest
began to offer a new class of online, interactive maps. These map
services pre-rendered a standard set of map tiles covering the
entire coverage area. A sophisticated JavaScript program running
in the user’s browser dynamically downloads the set of tiles that
cover the user’s desired map viewport. The client positions and
crops those tiles on the screen to produce a map with exactly the
desired size and extent.
Interactive maps have several advantages over their on-demand
predecessors. Perhaps most importantly, user interaction is
significantly more intuitive. Because the final step of assembling
tiles into an image is done on the client, it’s possible to support
fluid panning of a seemingly infinitely-sized image. Pre-rendered
services typically have higher quality images as well; because tiles
are no-longer rendered in realtime, slow enhancements such as
anti-aliased fonts can be used.
Shifting so much of the map’s implementation to the client also
had an unexpected effect. Soon after the release of Google Maps
(the first such public service), web hackers learned to create
Google Maps mashups. A mashup is a combination of maps with
other geographically interesting data, such as those listed in the
Introduction. Geographic mashups gained popularity quickly.
Most major online mapping sites released official APIs that
allowed web developers to create mashups “legally.”
For the most part, geographical mashups so far have consisted of
drawing fairly simple shapes on top of the online maps—for
example, layers of pushpins (houses for sale) or polylines (bus
routes). Largely ignored, however, is the practice of
superimposing an entire image layer onto the underlying imagery.
We speculate that this is because raster overlays are difficult to
construct, as we will explore in the next section.
The difficulty in constructing raster overlays is unfortunate,
because they can be quite useful. Figure 1 shows an example.
The left pane shows the image of the University of California, Los
Angeles as seen in either Google Maps or Microsoft Virtual Earth.
The aerial imagery shows a densely built area, but the street atlas
has no data describing any of the buildings or the campus’
internal roads. However, UCLA publishes a detailed campus
map. The right pane of Figure 1 shows the same area after we
used MapCruncher to generate a raster overlay. The map can be
panned and zoomed, just as was possible before the overlay was
added.
The main contribution of MapCruncher is that it makes a task
accessible to casual users that had typically been the domain of
geographic-information-systems (GIS) professionals.
3. CHALLENGES TO THE CASUAL MAP
MASHER
In this section, we consider the difficulties encountered in taking
an arbitrary map—say, a PDF map of a university campus—and

Figure 1. (left) Base imagery of the UCLA campus (right) UCLA’s campus map superimposed, using MapCruncher

Page 3

turning it into an interactive map layer. That is, we’d like to
superimpose our map onto the road and aerial photography
already provided by online mapping sites, such that the two maps
can be viewed together, as in Figure 1.
Map overlays have existed for as long as maps have existed, so it
may seem surprising that a new tool was necessary to accomplish
a seemingly well-known task. In fact, our original intent was not
to create a tool, but to create a mashup using existing tools. In
this section, we describe some of the hurdles we encountered and
how they motivated us to build a new tool to overcome them.
3.1 Reprojection of Unknown Map
Projections
The Earth is round, but maps and the computer screens that
display them are flat. Maps that depict very small extents of the
Earth relative to their level of detail, such as building blueprints,
can make the simplifying assumption that the Earth is as flat as
the map that depicts it. However, maps of larger extent can not
ignore the curvature of the Earth. A cartographer must therefore
select a method to convert the position of points on the three-
dimensional Earth’s surface to the two-dimensional map. The
mathematical functions used for this purpose are called map
projections [20].
One spatial relationship or another is lost whenever the three-
dimensional Earth is projected into a two-dimensional
representation. Consequently, an astonishing variety of map
projections have been invented. Each projection makes different
tradeoffs, typically maintaining high fidelity in some aspect of the
Earth’s representation (e.g., the shape of objects) by giving up
fidelity in some other aspect (e.g., apparent relative sizes of
objects). Cartographers select the best projection based on a
map’s intended use. Most map projections are parameterized, to
enable them to be fine-tuned to the location, size, and aspect ratio
of the extent of the map.
For two maps to be superimposed correctly, as is our goal, they
must both be drawn using the same projection. In the world of
traditional GIS systems, this problem is usually easy to solve.
Most spatial data comes annotated with metadata describing
which projection was used to draw it, along with the projection’s
parameters. This information can be used to perform a
mathematically exact transformation of a map into any other
projection.
For casual mashups, the situation is more difficult. The vast
majority of maps available on the Web have been stripped of the
metadata that describes the map projection. For maps that do
have metadata, it is often in a format that can not be automatically
parsed—for example, a text file describing the projection in
English. Consequently, it is nearly impossible to precisely or
automatically reproject a typical map found on the Web.
This is a problem for a user who wishes to create an overlay.
Most maps are not drawn using the same projection as is used by
the major interactive online map services. Microsoft’s and
Google’s mapping sites, for example, use the Mercator
Projection. (Mercator is used because it is conformal. Conformal
projections do not distort features’ shapes, making it possible to
overlay street maps on undistorted aerial photography.) In
contrast, most other maps are not expected to be used as overlays
for photographs, so instead use one of the many projections that
produce less scale distortion. It is hard to guess exactly which
projection a map uses by inspection because there are so many
projections. For example, the USGS1 produces maps depicting
each of the 50 United States using custom projection parameters
tailored to each state.
Unfortunately, this problem is not well solved by any of the
numerous tools available that aid in the production of map
overlays. After a week or two of tinkering with various test maps,
we concluded the existing tools were all either too simple or too
complex. The simple tools were limited to linear transformations
such as scaling, translation and rotation. Our test maps did not
use the Mercator projection, so the simple tools could not warp
them sufficiently to produce good alignment at all points. The
complex tools could perform arbitrary reprojections, but required
complete specification of the projection, which was unavailable
for our test maps.
MapCruncher addresses this problem using approximate
reprojections. As we will see in Section 4, MapCruncher allows
users to point out correspondences between the two maps, then
estimates how to reproject the user’s map into Mercator without a
model of the source map’s projection. Although less accurate
than an exact reprojection, this design choice fills a useful niche
in between the low- and high-end.
3.2 Management of Large Datasets
The simple, intuitive pan-and-zoom interface provided by online
maps makes it easy to forget that they are providing access to
immense repositories of data. Microsoft’s Virtual Earth platform
has nearly 200 terabytes (1014 bytes) of imagery. While a casual
user is unlikely to ever create such a large dataset, we’ve found
that even modest maps can overwhelm normal desktop image
processing tools.
For example, consider the map of neighborhood bicycle routes
produced by King County, Washington. Two of the authors
commute to work by bicycle, so this map was of particular
interest. We tried to overlay it on several interactive maps
(Google Maps [8], Google Earth [7], and Microsoft Virtual Earth
[16]) using previously existing tools. All of them required that we
provide the overlay as a single rasterized image (e.g. a PNG).
The 2005 edition of the King County bicycle map is a 30”x36”
poster. If rendered at a zoom level large enough that its smallest
features are easily readable, it is a 3-gigapixel image. Despite
considerable effort, we could not find a PDF rendering program
under Windows or Linux capable of producing an output image of
that size. Their failure modes were diverse and often amusing.
Some ran out of RAM (3GB was available). Others filled the disk
with temporary files. Some simply froze the computer.
Even if we had we succeeded in creating such a large image from
our source PDF, other roadblocks would have awaited us. Similar
limitations existed in the tools available both for registration of
the image to a reference map and cutting it into browser-
compatible 256x256 pixel tiles. Our early failure in the seemingly
simple task of creating a bicycle-map overlay was among our
motivations to write MapCruncher.

1 The United States Geological Survey (USGS) is the official
mapping agency for the United States.

Page 4

MapCruncher was designed with enormous output images in
mind. As we will describe in Section 5, our tool uses the same
strategy as the large interactive map sites: instead of producing a
single image, MapCruncher renders a large number of small
(256x256) image tiles. This allows browsers to navigate through
large custom overlays just as they do the underlying road maps
and aerial photography: efficiently downloading just the sub-
images they need, on-demand. In contrast, most other overlay
generators that require the user download the entire overlay image
before displaying any of it. This is impractical for our 3-gigapixel
test map.
MapCruncher also handles large source maps gracefully
generating each 256x256 tile individually, directly from just the
portion of the source map that it requires. Again, this is in
contrast to other tile generators that require the entire source map
to be rendered in advance, even though the image may be giga- or
even tera-pixels in size.
3.3 Mashing Without Programming
In the earliest days of the Web, content production was an
engineering discipline. Writing HTML is similar in some ways to
computer programming. Like programming, it is inaccessible to
people who do not happen to be experts in the field – that is,
inaccessible to most people who want to create content. Various
HTML authoring tools quickly appeared, making it easier for non-
experts to write web pages without needing an intimate
understanding of the underlying technology.
The situation today is similar with the creation of mashups, both
geographic and otherwise. They are difficult to create without
first learning JavaScript, HTML, XML, esoteric APIs, map
projections, and geographic coordinate systems. Our first attempt
at creating a bicycle-route mashup was slowed by the requirement
we learn many new disciplines, from web APIs to map projections
to online maps’ coordinate systems and naming schemes.
One of our motivations for writing MapCruncher was to make
geographic mashups accessible to non-experts – including people
who would not have been able to create a mashup without it. As
we will see in Section 6, MapCruncher lets beginners create
point-and-click mashups, while still allowing advanced users to
customize arbitrarily.
4. APPROXIMATE REPROJECTION
In this section, we describe how MapCruncher reprojects (changes
the shape of) and registers (correctly positions) the user’s map
such that it correctly overlays the existing Mercator-projected
maps and aerial photography.
MapCruncher differs from traditional GIS systems, which
generally perform mathematically exact map reprojections. GIS
software usually includes a large library of commonly used
projection families; the user is asked to select the one that was
used to draw the source map. The user must then enter the
numerical parameters that specify the exact projection. The
nature of these parameters depends on the projection.
Unfortunately, as we described in Section 3.1, most maps used by
our target audience have unknown projections. A user who is not
a GIS expert may not know even what a projection is.
Consequently, we designed MapCruncher to estimate the
transformation. First, we ask the user to identify some landmark
that can be found both on the user’s map and also on the Virtual
Earth map or aerial imagery; we call this identification a
“correspondence.” After obtaining several correspondences, we
find the coefficients to a polynomial function that best fits them.
A transformation with a 2nd-degree polynomial can look very
similar to the transformation from many projections into
Mercator.
“But wait!” a GIS professional might insist. “Polynomials may
look similar to the right answer, but to reproject correctly, you
need trigonometry. And asking for user input by pointing out
map landmarks is horribly prone to error!” This is true – and the
users who have spatial data annotated with all the metadata
required to do an exact transformation are likely to use GIS tools,
not MapCruncher. While not exact, we’ve found polynomials
produce excellent results in a wide variety of maps. By analogy,
the existence of AutoCAD does not obviate the value of Microsoft
Paint.
In Section 4.1, we describe the process of gathering enough data
from the user to reproject the user’s map. In Section 4.2, we
describe how MapCruncher uses that input to produce a usable
map overlay.
4.1 Georeferencing
The first step in creating an overlay with MapCruncher is
specifying a number of correspondence points between the user’s
map (the “source map”) and the existing road maps and aerial
photography (the “reference map”). Because the reference maps
are, themselves, already registered to the Earth’s coordinate
system2, each correspondence identifies the real latitude and
longitude of a point on the source map.
MapCruncher provides a simple interface for specifying
correspondence points. The MapCruncher GUI, shown in
Figure 2, has two viewing panes. The source pane displays the
source map, which can be panned and zoomed to arbitrary
locations and zoom levels. The reference pane displays the
reference map, using imagery from Microsoft Virtual Earth. The

2 Specifically, the “WGS84” datum.
source map
crosshairs
reference map
crosshairs
Figure 2. Establishing a correspondence between a source
map and the reference map

Page 5

reference map can be panned and zoomed independently of the
source map.
The user employs the two panes to find a location on the source
map and a location on the reference map that visually correspond
to each other. Any landmark that appears in both maps can be
used as a correspondence. For example, in Figure 2, we are
registering a building floor plan to Virtual Earth’s aerial
photograph of the same building. In this example, the corners of
the buildings are readily visible in both views and make excellent
references for a correspondence. For some source maps, it may be
more convenient to use Virtual Earth’s road-map view instead of
aerial photography. Street intersections make excellent
correspondences for many maps.
Each pane includes crosshairs that identify the center of the pane.
The user indicates a location by panning the image until a feature
is under the crosshairs. Once the same feature is under the
crosshairs in both panes, the user clicks a button labeled “Add
Point”. This process is repeated until there are enough
correspondences. In practice, between two and twenty are
required, depending on the source map.
We discovered that in maps that cover a large geographic extent,
establishing 20 correspondences can be time-consuming. To
speed the process, MapCruncher can helpfully guess the spot on
the reference map that corresponds to an arbitrary source map
point. As soon as the first two correspondences are defined, the
user can “lock” the views of the source and reference maps
together. When one locked map is panned or zoomed, the other
follows suit.
With just two or three points, the lock is based on a poor
approximation, but it is usually good enough that it greatly assists
the user in establishing additional correspondences. Using locked
views, the user can zoom rapidly to a new location in the source
map, and the reference map follows along. Often, only a little
nudging of the (unlocked) reference map is required to find the
exact matching point. Thus, the third and following
correspondences in a mashup become much less tedious to define.
As each new point is added, the reprojection approximation
improves.
4.1.1 Error display
Sometimes, the user accidentally establishes a correspondence
between points on the source and reference maps that do not
actually correspond. A common instance is an “off-by-one-block”
error (see Figure 3).

The reprojection process will dutifully attempt to distort the
source map to satisfy the erroneous correspondence. However, if
the reprojection is overconstrained and there are enough correct
correspondences, the result will mostly respect the majority.
MapCruncher uses the distance between the reprojected point and
the user-placed point to find outliers. It computes the magnitude
of disagreement for each correspondence, sorts by decreasing
disagreement, and presents the list to the user (see Figure 4).
The observed amount of disagreement provides the user with a
quick suggestion of which points might have been placed
incorrectly. The user can then revisit the top few “suspicious”
correspondences to ensure they’re in the right place.
As an additional aid to the user, MapCruncher plots a vector from
where the user placed a correspondence point towards where the
majority suggests the point should have been placed (see
Figure 5). In this case, the correct source map position (left side)
corresponding to the marked reference map position (right side) is
one block south of the point selected by the user. The
disagreement vector points south, suggesting “perhaps the point
belongs somewhere down there.”
4.2 Reprojection
After the user has created correspondences, the next step is to
generalize them, relating the entire source map to global
coordinates. Mathematically, we need to produce a function that
captures the relationship between image coordinates on the source
map and image coordinates of the Mercator-projected reference
map.

Figure 4. Correspondences sorted by disagreement
Figure 3. Establishing a correspondence between a source
map and the reference map

Figure 5. Disagreement vector points toward likely correct
location.