Map Scripting

This is part of a series looking at all 10 chapters of Map Scripting 101.

Geocoding, converting addresses and city names into coordinates to place on the map, is such an important part of mapping, it’s hard to believe Google Maps launched without the feature. Now there are many geocoding services available, both within mapping APIs and from additional services, both free and paid. There’s also a greater need for reverse geocoders, which take a point on the map and return something human readable, like an address.

The book covers four types of geocoders:

1. Forward geocoding in JavaScript
2. Forward geocoding server-side
3. Reverse geocoding in JavaScript
4. Reverse geocoding server-side

Reverse geocoders are becoming more popular because of mobile browsers. While in the past we almost always received our users’ locations from an address they type in, now we’re often receiving it directly, such as with the iPhone geolocation code, a standard that works across many browsers (including many desktop browsers). Coordinates help make coding easier, but sometimes you need to share with users where you think they are. Users don’t understand latitude/longitude, but they do understand addresses.

In addition to geocoding services, the book covers postal code databases. It is common for sites in the U.S. to request the user’s zip code, which is faster to type and less invasive than a full address. You can pass that off to a geocoding service to convert a code to, usually, the center of the postal code area. Or, you can install a postal code database yourself and not have to worry about building on top of another service, at least for postal code queries, which are fairly easy to identify.

This is part of a series looking at all 10 chapters of Map Scripting 101.

Adding markers to a map is so central that I considered including it in chapter 1. However, because it’s such an important topic, it really deserved its own chapter. In addition to adding basic markers, I covered the way Mapstraction lets you customize your icon and do other cool things that aren’t included in standard mapping APIs.

In my talks about mapping at conferences, I tell developers that using a custom icon is by far the easiest thing you can do to make your map stand out from all the other mashups. And there’s really no reason not to do it in Mapstraction, as it’s just one more line, as I showed in the custom marker icons post.

Once you have a map full of markers, Mapstraction has a couple pretty cool features to deal with them. In another line of code you can automatically center and zoom the map so that all of them appear. And Mapstraction also lets you add any data you want to each marker, then filter upon that data.

As the title of the chapter suggests, it also covers message boxes, the little windows that pop up from markers to provide additional information. You can learn all about message boxes, filtering and everything else in this chapter by downloading chapter two for free from the publisher’s website.

This is part of a series looking at all 10 chapters of Map Scripting 101.

The first chapter aims to get you started mapping quickly. It introduces a few concepts, like latitude/longitude, then gets right into creating maps and adding controls to them.

Among the most important projects in the entire book is my introduction of Mapstraction. I’ve written about Mapstraction quite a bit on this blog before, including one of the first posts. The open source library is the heart of almost every example in Map Scripting 101.

Mapstraction lets you write your code once and not worry much about changes to other providers. It helps provide an open interface to maps on the web, as I discussed in How Open Should Mapping APIs Be at Where 2.0 in 2009:

Like any good first chapter, Mapping Basics sets the foundation for the next nine chapters.

You’re in Portland, but you have a friend in Spokane that you’d like to see. Nobody feels like driving the whole way, but you’re both up to half the trip. Now, how do you determine where to meet? Meet in the Middle finds that midpoint and then searches Yelp for coffee. Yes, Hermiston is a long way to go for coffee.

» Try out the Meet in the Middle Mashup

Of all the examples in the book, I might have been most excited to include this one. It builds upon the Walker Tracker example where I found a point a certain distance along a route. And it works pretty well for both long distances and trips across town.

Want to search for something other than coffee? The code is simple enough that you could probably figure out how to make that change without even looking in my book. (But just in case you need a hint, it’s on page 285).

Every morning my father gets the newspaper and checks the weather map on the back page. Never mind that the paper was printed late the night before and that the weather forecast is even older. With the weather mashup in the book, I wanted to make it interactive and as updated as Yahoo Weather can make it.

» Try out the Weather Mashup

I pre-selected 11 cities that I felt were geographically representative, but it’s really easy to add more. The current conditions determine the icon that is placed over the city. When the icon is clicked, the map zooms in to show the forecast.

Though fairly simple, it’s a fun one. And a great first step into connecting to other services to make even better maps.

One of my favorite features in Mapstraction, the open source library that lets you write map code once, is filtering. With the feature, you can add data to any marker, then filter based on that data later. In the book, my concert mashup example filters based on price, using data from the Upcoming API.

» Try out the Concerts Mashup

Because concert prices aren’t always simple (i.e., sliding scales of $5-10), there was a little server-side data slicing that had to happen. But the part where non-matching markers disappear quickly is all Mapstraction.

I cover it in-depth in the book, of course, but to get started now, view the source of this basic filtering example.

During the time I wrote the book, Twitter launched its geocoded tweets feature. Now any message can have a location associated with it. That’s pretty cool and I knew I’d need to find room for it in the book. So, I added a Twitter Mashup.

» Try out the Twitter Mashup

It’s less straight-forward than the earthquake mashup, which takes in data, styles it and outputs. Here, you need to do some filtering for whether each tweet is actually geocoded. Why? Because Twitter returns all tweets near the location you specify using any means it can–including the user’s city as listed in their profile.

Additionally, my Twitter mashup uses a geocoder to search for a location and defaults the map view to your city (assuming it can find your location based on your IP address). Then the search radius is shown with circle overlays.

The U.S. Geological Survey (USGS) provides excellent data on earthquakes around the world. And, since they make it available as GeoRSS, it’s a popular example for maps. So, it was a natural to include in my book, as one of the five example mashups in the final chapter.

» Try out the Earthquakes Mashup

Rather than simply overlay the GeoRSS, I chose to provide icons that helped visualize an earthquake’s magnitude. And, since some parts of the world have more seismic activity than others, I provided a means to snap zoom to the hotspot zones.

If you’re looking to recreate this mashup, you’ll want these image files to make it happen:

Perhaps you’ve seen those maps with geographic regions shaded particular colors? That’s called a Choropleth map and you can create one for U.S. states using simple polygons in Mapstraction.

In order to create these shapes, you need the latitude/longitude points that make them up. For some states, that means many points. It takes a lot of work to collect the data, but Rakshith of MapMash has saved us all work.

You can download the state boundaries XML, or see one of the two JavaScript-ready versions below.

First, this follows the simple Four Corners Example from the book, with a variable for each state.

var alaska = [new mxn.LatLonPoint(70.0187, -141.0205),
new mxn.LatLonPoint(70.1292, -141.7291),
... new mxn.LatLonPoint(70.0187, -141.0205)];
var alabama = [new mxn.LatLonPoint(35.0041, -88.1955),
new mxn.LatLonPoint(34.9918, -85.6068), ...
» Simple JavaScript version

A more advanced version uses an object to hold the state name as a key and the collection of points as the value.

var statesobj = {"Alaska": [new mxn.LatLonPoint(70.0187, -141.0205),
new mxn.LatLonPoint(70.1292, -141.7291),
... new mxn.LatLonPoint(70.0187, -141.0205)],
"Alabama": [new mxn.LatLonPoint(35.0041, -88.1955),
new mxn.LatLonPoint(34.9918, -85.6068), ...
» JavaScript object version

Let’s say you have a lovely graphic of an area, like a downtown district or a park. It’s a flat, top-down view, like most maps. But it doesn’t quite match up with the streets or other features of a mapping API’s imagery. Before you can overlay your image, you’ll need to georeference it.

The process is also called rubber sheeting, because you are essentially stretching and manipulating your graphic so that every point of your graphic meets up with the appropriate geographic coordinates.

In the book I use Central Park as an example. I uploaded a graphic from a park brochure to a site called GeoWarper. Then I referenced parts of the graphic with other identifiable areas in an OpenStreetMap version of the same area. GeoWarper then spits out a georeferenced version of the graphic.

Want to try it out yourself? The original graphic is included above. You can start your own, or use mine. If you just want to see it completed, the warped graphic is also above and the Central Park map is in my examples section.