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.

It’s done! We’ve fixed every last detail and the book is off to the printer. It’s been quite a process and it’s lovely to know the book will soon be in the press. Map Scripting 101 will hit shelves in early August.

For those who are curious (and others wondering why this took 18 months), here’s the rough order of things:

1. I write a first draft of a chapter and send it to Tyler Ortman, my editor at No Starch Press
2. I almost certainly make some edits based on Tyler’s feedback
3. Tyler sends the chapter to Derek Fowler for technical review
4. I almost certainly make some edits based on Derek’s feedback
5. Tyler sends the chapter to LeeAnn Pickerell, the copy editor
6. I almost certainly make some edits based on LeeAnn’s feedback
7. I package up the completed chapter, along with all the screenshots and figures and send them to Ansel Staton, No Starch’s production assistant
8. Ansel sends me a PDF of the chapter and it starts to feel real
9. I reply to Ansel and the production team’s questions
10. Tyler sends the nearly-complete book to a proofreader and an indexer
11. I make final changes and add an introduction/acknowledgments

Somewhere in there we chose the title, Tyler arranged for a cover design, the book was officially announced and No Starch worked up some snappy back cover copy.

Thanks all who have followed along! There’s plenty more mapping to happen here, as I’ll be previewing the various sections of the book and sharing the five mashup examples that wrap everything together.

Alternate title: that sure took longer than I thought.

It was a year ago today that I sat down to a blank OpenOffice screen and realized a book is a big project. Despite that, I intended to be done much sooner. And it’s not even done yet. The project continues, with technical review and copy editing happening right now.

I wrote about the writing process on my personal blog and I’m sure I’ll have more to say when the book is truly finished. But for now, thank you for following along. It’s been a fun year and I look forward to a great 2010 of more Map Scripting.

In the craziness of getting married, I managed to miss posting my most exciting book news yet: My initial draft is complete!

I haven’t been this happy since I fixed my webcam:

There’s still plenty to do. Every example will be looked over by a technical reviewer, to ensure that all the code works as expected. I will become good friends with No Starch’s copy editors. Finally, there are a few more mashups and projects I want to add to the book.

But this milestone, it’s not lost on me.

I’ve had my head down writing and I’m seeing the progress. Of the nine chapters currently planned (that number may change), I have written all or most of seven of them. That means I’ve nearly written a book!

Now my plan is to sprint through the bulk of what remains during August, leaving just a few bits to finish up after my wedding.

Several people have asked me when my book will be out. Thank you for your interest! I don’t know–there’s a lot to be done even after my writing is finished. However, I now have a handy form in the sidebar of this site. If you’d like word of when the book is out, visit the main page and fill in your email address. I won’t do anything bad with it, I promise.

I’m totally stoked to have finished the first draft of a really big chapter for the book. Mashup with Data APIs will show at least three example mashups that I think will help beginners learn how to incorporate outside data and create interactive maps.

1. My Weather mashup shows the current conditions across the U.S. and provides the forecast when you click an icon.
2. My Earthquake Mashup shows the earthquakes in the world over the last week, with marker size increasing with the quake’s intensity.
3. My Upcoming mashup shows concerts happening in the next week by location, with filtering by ticket price.

If you’re new to mapping, get a feel for how it works by viewing source. On the other hand, if you’re a JavaScript expert, tell me what you would have done differently. In either case, I’d love to hear feedback!

I’m working on some mashups for a chapter in the book, including a weather map. So, I was checking out Yahoo’s weather API and came across its codes for specific conditions.

Curious, I started cross-referencing the codes to their icons. Most are able to get across the condition visually. A few, such as dust and fog, require text to make sense of what would just be a picture of haze. Actually, haze is its own condition.

Another that also gets textual treatment is hurricane. But instead of tossing the H-word into a graphic of sideways rain, Yahoo’s icon simply says “WINDY.”

Seems like an understatement to me.

The data comes from the Weather Channel, but its icon of the same code has no text. And it looks scarier, much more appropriate for a hurricane.

There’s nothing quite like teaching to help you figure out what you don’t know. I’ve been detailing the basics of mapping–plotting markers and adding click-able message boxes. Through the process, I’ve discovered a few holes in Mapstraction‘s coverage of common API features.

For example, there was no method to programmatically close a marker’s message box. You can open it with openBubble, but closeBubble didn’t exist.

Similarly, panning to a new center point, a feature in most mapping providers, was absent in Mapstraction. It’s a nice-to-have, but it sure is less jarring when switching to a point near your current view.

I was faced with the possibility of either leaving them completely out of the book, or implementing them in provider-specific code. Neither seemed like a good solution. So, I set the book to the side and decided to implement them myself.

I’ve been a programmer for well over a decade and I’ve taken advantage of many an open source project. Never before had I contributed code to one. Lucky for me, there is a loyal group of Mapstraction contributors willing to help out a newbie. My “patches” (calling them such is kind, since I merely pasted code into the discussion list) were quickly accepted and are now part of the code repository. Sweet!

Now it’s back to writing. Chapter three is days away from being complete!