Well, I couldn’t really get this to work. Oh, it worked fine if all the circumstances were right, but for what I wanted it to do, the plugin’s not yet ready. After running a few tests with the MTGoogleMaps plugin, I’ve determined two main problems.
The first problem is with getting the plugin code to render properly when some text (such as an address) is inserted somewhere in the blog post. My thinking is that if I want to show a map, I’ll put in an address, and a map will render somewhere in the posting. If I don’t put an address in, there is no map (and there is no big blank space where a map would render). So I was trying to find a way to place it within the <MTEntryIfExtended> tags. The problem is getting around the Catch-22 of Movable Type — that the <MTEntryIfExtended> tag relies on the existence on the <MTEntryMore> string, which only exists if something is placed in the extended entry field. The MTGoogleMaps plugin dynamically looks in a field (i.e. in the extended field) for an address, so it would be using the contents of the <MTEntryMore> to help it render the map. At one point, all my posts were trying to render a map, but only one had anything that could be dynamically generated by the plugin.
If I don’t put anything in the extended field, then no problem.
So I tried hardcoding the address into the MTGoogleMaps code, and using “foo” in the extended entry field. This worked fine for a quick functionality test, and I figured I could work out the details later, as long as the plugin worked as expected.
Which brings me to the second big problem in functionality, and it was a little bit of a problem with the MTGoogleMaps code, and more than a little to do with the way it translates addresses into coordinates. MTGoogleMaps uses Geocoder.us to translate the addresses into map coordinates. It does this via an RPC post to Geocoder’s website, but their database is a little sketchy, and doesn’t have many large American cities in it. For example, the sample address provided with the MTGoogleMaps works fine:
http://rpc.geocoder.us/service/rest?address=123 Main St. New York, NY 10001
But it won’t render any Canadian addresses — making the whole thing useless for us bloggers north of the border. In fact, instead of a map, I get a big blank spot on my page, and this showing up in my page source:
map.centerAndZoom(new GPoint(/var/www/htdocs/blogzucker/index.html, ), 4);
Canadian cities are one thing, but it needs to be able to at least render US cities properly. Sure, Main St. New York is fine, but some addresses in San Francisco won’t render any better than Canadian ones. I just get a “couldn’t find this address! sorry” message from the Geocoder.us website.
Which is where the MTGoogleMaps code is hitting a wall. It’s not responding very gracefully to the literal text string of “couldn’t find this address! sorry”.
I thought for a second that I might be able to use Geocoder.ca instead, but it uses an entirely different syntax in its API, and doesn’t even return a string value when you send a call — you just get their main page with the address form pre-populated. The other geocoding sites all use their own syntax, so unless I’m going to rewrite the way the plugin parses responses and sends queries, I can call it quits for now.
I sent my feedback to Nick, the plugin’s author, and he’s adding in some simple error checking that will catch any “couldn’t find this address! sorry” errors from Geocoder.us. He’s also going to check out some international geocoding searches, but I don’t expect Canada to be on the top of anyone’s list.
It will be neat if I can get this to work with my main blog. My plan was to put maps in whenever I’m posting from away, sort of a travel blog with maps.