almost_geek, girl

GMap_to_static: one-click static maps creation

GMap_to_static is a bookmarklet for creating a static map that looks just like a given dynamic Google Map.

It is useful when you want to embed a Google Map as a ligthweight image, not as a full frame.

Go to dira.ro/code/GMap-to-static to install it and go to github to watch the project.

Here’s how it looks:

Why I wanted it

In order to create a Static Map image, you need the coordinates of all your markers and paths.

I already had a map with a lot of nice colorful markers spread across South America. But there is no tool to export it as a static map, so I was left with manually getting the coordinates of each marker… or writing a tool to get them.

I boldly chose the “write a tool” option.

But it’s not a piece of cake

The good news is that calling window.gApplication.getMap() in a Google Maps page will return the current map.

The bad news is that most of its properties and functions have been minified to cruel one or two-letter identifiers. So, except getBounds, getCenter and some conversion functions, there are no recognizable names in sight.

Enthusiastically digging through the tree of minified JS properties, I found out that the markers are minified too, but only partially. They still have some typical functions, like infoWindow and latlng, exposed fullname.

Quite a handy discovery, but relying on a path like map.Kd.St[0] is not a long-term solution. The path will probably change each time Google Maps is deployed.

Luckily, backtracking was invented for this kind of tasks. So, I’m searching the entire map object tree, looking for properties that “quack” like a marker. Finders, keepers!

Once the secret of markers is exposed, a similar strategy can be applied to paths and shapes. They too quack in a specific way, as they are the only ones having the function getVertex. The difference is that paths have the property name, while shapes don’t. However, shapes are not yet supported by the Static Maps API, so only their contour is rendered in the static image.

Guessing the zoom level

Another property that is minified is the zoom level. Unfortunately, it is just a number, so the quack-based detection does not really work to find it.

I observed that the map’s longitude span (in degrees) and its width (in pixels) are proportional within the same zoom level (thank you rectangular projection!).

When zoom = 3, for example, longitude_span.map_width/ ~= 0.175 for any Google Map.

Even more, for each increment in the zoom level, the longitude span is multiplied by 2.

Therefore, an easy formula can be created to compute the zoom for a map:

zoom = 3 + log2(0.175 * map_width / longitude_span)

Viewport optimization

The size of the static map’s URL is limited to 2048 characters. This means that we should strive not to put unused information in it. :)

This is why I optimized the URL generation by including only the markers and the path segments that are actually visible in the current viewport and left out the others.

Also, the algorithm starts by trying to include as much precision in the coordinates as appropriate for the zoom level, and decreases the precision if the resulting URL is too long.

Limitations

• the map width and height are limited by the Static Maps API to 640
• the URL size is limited to 2048 characters. This basically means that maps with complicated paths (such as those of Directions for long distances) cannot be made static as the URL would be too big.
• the map type for the static map is the default one: roadmap. If you want a different kind of map, you can change the maptype parameter from roadmap to satellite, terrain or hybrid.

Conclusion

GMap_to_static is one of the most challenging and rewarding pet projects I created. Using nice algorithms and playing with logarithms reminds me of the high-school days. And being able to easily generate static maps is wonderful (and addictive, beware!).

Fixed bugs for fun. Rails BugMash

Last weekend I took part in Rails BugMash – a ‘bug squashing’ event organized by RailsBridge.

From the beginning I found some ActiveRecord issues that seemed very interesting. What I learned is that digging through ActiveRecord is a lot easier in concept than through source code. Therefore, I managed to produce only a partial patch. The bright side is that it was a lot easier with tests, so I was more productive on this side.

Even if it didn’t add many points on my scorecard, the “ActiveRecord adventure” was indeed very interesting. Here are some useful tips for ActiveRecord testing:

• recreate the tables after changing the schema: you have to do it yourself if running a single ActiveRecord test
  
• looking for the SQL generated during a test? activerecord/debug.log
• verify if an associated object is loaded? The way to do it depends on the realation type:
• adding an ActiveRecord test? it’s preferred to reuse the existing models rather than create new ones. Even if some models look a bit abused after so much use :), I guess it’s better than having a couple of new models for every patch

I was impressed by the energy and collaboration in the (virtual) room: issue creation, verification, testing & patching seemed to flow from person to person. This meant that I got feedback fast on my contributions, which was great.

Big Kudos to RailsBridge for organizing the event and easing the ‘contributing to Rails learning curve’. It allowed me to use my Ruby & Rails skills to the max, even if it was the first time I contributed.

Back from Euruko 2009

Euruko – the European Ruby conference – was in Barcelona this year. It was a blend of enthusiastic community and interesting talks, in two intense days, facilitated by wonderful organization.

This year, besides language/programming-oriented talks, there was an abundance of presentations about what you can do with ruby in various fields: games programming, image processing, system configuration automation, voip, mobile apps, music.

The lightning talks sessions were very popular – the 5 minutes format (and the terrifying gong sound) was ‘fast & furious’ – and the information overload was appreciated.

foto by Emili Parreño

I had a lightning talk about vimmish – presented what it can do and what I am working on now: generating random vim command strings, based on the grammar.

When I got to the part about parsing the vimmish grammar itself using treetop’s meta-grammar half of the audience was giving me facial hints that I did not explain that well enough (well, I had 5 minutes for all the talk.. :) ). But everyone understood what I meant when I got to the examples – randomly generated metal band names and manager speeches from the crazy italian site polygen.

Some people told me it was the geekiest lightning talk of the first day – not sure whether it was the topic, the fact that I delivered the presentation as a sequence tabs in firefox (don’t ever do that, you’ll mess the ctrl-tab under the merciless spotlights. twice.) or the polygen examples, or their effect combined :).

Next year, Euruko will be in Kraków, Poland – there were more than 20 polish developers this year and they were very enthusiastic about the conference. So, see everybody again next year, in Poland!