Weighing in on Flash Mapping APIs
I remember a time not so long ago, when I was trying to convince a friend of mine that Flash was a perfect solution for his application. He was after all working with a highly visual type of data - maps. His mission for me was to put two items on a map of the United States, and draw a line between them based on lat/long coordinates. At the time, mapping solutions for the web were still very much in their infancy, and this turned out to be a lot harder than I expected. These days however the bigger challenge would be in picking a map solution in the first place.
To be clear, I consider each of the available map offerings that are available to be like tools. While you may develop a familiarity with one over another, there will likely be times when you may be better served by an alternative. Rather than compare options then, I wanted to look at some of the options from a much simpler perspective, one that most web developers consider right up front, download size. With that in mind, I set out to build three similar examples using Google Maps, Yahoo Maps, and MapQuest maps, and see just how they measured up.
This is the latest player to enter the field of Flash map offerings, and it hasn’t gone without notice. While there’s clearly a lot of development that still needs to happen to bring the Flash offering on par with the JavaScript version, there’s already some pretty compelling features. The feature I’ve seen talked about most is a “terrain” view in addition to the traditional map, satellite and hybrid views. In wanting to set a common baseline, I didn’t explore this option, and just went with the basic map view.
package
{
import com.google.maps.LatLng;
import com.google.maps.Map;
import com.google.maps.MapEvent;
import flash.display.Sprite;
import flash.display.StageAlign;
import flash.display.StageScaleMode;
import flash.geom.Point;
public class GoogleMaps extends Sprite
{
public static const GOOGLE_KEY:String = "YOUR_KEY_HERE";
public var map:Map = null;
public function GoogleMaps()
{
stage.scaleMode = StageScaleMode.NO_SCALE;
stage.align = StageAlign.TOP_LEFT;
map = new Map();
map.key = GOOGLE_KEY;
map.addEventListener( MapEvent.MAP_READY, doReady );
addChild( map );
}
public function doReady( event:MapEvent ):void
{
var home:LatLng = new LatLng( 37.3310639, -121.8939944 );
map.setSize( new Point( 200, 200 ) );
map.setCenter( home, 8 );
}
}
}
There isn’t a whole lot of difference in creating a map between the three APIs I explored. You’ll need to instantiate the map, provide a key at some point, and you’ll probably want to set a center point and default zoom level. Sometimes you’ll be able to do this all in the constructor. In other APIs, instantiation is a separate step from setting the key, which is a separate step from setting a center point and default zoom level. The delta on the number of lines of code (as you’ll see) is negligible; at least too negligible to impact overall SWF size.
You can see the Google Map in action, but the SWF itself weighs in at 36 kb. I used Flex Builder and a pure ActionScript 3 approach to each project. What I think is interesting is the load size of the map including the supporting HTML, CSS, JavaScript and, most importantly, the images for the map tiles. It turns out that for Google Maps, this comes in at around 304 kb for a 200 x 2000 pixel space, which is what I used for each example. Any way you slice it then, this is a pretty strong initial offering, with a lot of promise.
Although I don’t want this to turn into a feature review, my one major criticism about Google Maps, Google APIs in general really, is their continued reliance on mapping a key to a specific domain. This means that I had to put the map on a public server to really measure the final weight of a production application. It also means that using using Google Maps in Adobe AIR is a non-starter, as AIR applications don’t have domains - they’re desktop applications. So many Google API goodies that suddenly become useless, ug!
Yahoo Maps generally tends to be the most commonly used by Flash developers. They were early to the game, and generally have good support for Flash overall. For a while, their main landing page for online maps was actually done with Flex 1.5. While they’ve moved their map property to JavaScript these days, they continue to shower the Flash and Flex communities with much love to include component skins and other goodies. Creating a Yahoo Map instance looks pretty much like it does with the Google Maps API.
package
{
import com.yahoo.maps.api.YahooMap;
import com.yahoo.maps.api.YahooMapEvent;
import com.yahoo.maps.api.core.location.LatLon;
import flash.display.Sprite;
import flash.display.StageAlign;
import flash.display.StageScaleMode;
public class YahooMaps extends Sprite
{
public static const YAHOO_ID:String = "YOUR_KEY_HERE";
public var map:YahooMap = null;
public function YahooMaps()
{
stage.scaleMode = StageScaleMode.NO_SCALE;
stage.align = StageAlign.TOP_LEFT;
map = new YahooMap();
map.addEventListener( YahooMapEvent.MAP_INITIALIZE, doInitialize );
map.init( YAHOO_ID, 200, 200 );
addChild( map );
}
public function doInitialize( event:YahooMapEvent ):void
{
var home:LatLon = new LatLon( 37.3310639, -121.8939944 );
map.zoomLevel = 10;
map.centerLatLon = home;
}
}
}
Generally speaking, I don’t have any complaints about the Yahoo Maps API. It does what it needs to and then gets out of the way. The resulting SWF size weighs in at 36 kb, right inline with the Google Maps API. There’s a difference of only a few bytes between the two, and it shows in overall loading as well with a weight of about 305 kb for a 200 x 200 pixel map. If you’re keeping score, that’s a difference of only 5 kb between the two so far. For your viewing pleasure, the Yahoo Maps option is also available for viewing.
Again, in trying to steer clear of a feature review, a negative I found for both the Yahoo and Google offerings was that I often ended up in the JavaScript documentation to get the answers I wanted. Finding the zoom level range as an example, has me crawling both the JavaScript documentation and the JavaScript forums. ActionScript 3 (ECMA-262 Ed. 4) is a pretty big advance from JavaScript (ECMA-262 Ed. 3), so forcing my brain to shift gears for simple properties like zoom, really killed my productivity.
MapQuest has been around for web mapping for as long as there has been web sites that offer maps. When I originally set out to build these examples, MapQuest 5.2.1 was the most current release. My tests were built on that API version, but it should be noted that MapQuest 5.3 was released just weeks ago. I haven’t had a chance to look into the new API, or reproduce the output discussed here, but there are some pretty exciting new features in the 5.3 release, including “globe view”.
package
{
import com.mapquest.PointLL;
import com.mapquest.tilemap.Size;
import com.mapquest.tilemap.TileMap;
import flash.display.Sprite;
import flash.display.StageAlign;
import flash.display.StageScaleMode;
public class MapQuestMaps extends Sprite
{
public static const MAPQUEST_KEY:String = "YOUR_KEY_HERE";
public var map:TileMap = null;
public function MapQuestMaps()
{
var home:PointLL = new PointLL( 37.3310639, -121.8939944 );
stage.scaleMode = StageScaleMode.NO_SCALE;
stage.align = StageAlign.TOP_LEFT;
map = new TileMap( MAPQUEST_KEY, 5, home );
map.setSize( new Size( 200, 200 ) );
addChild( map );
}
}
}
It should jump out at you pretty quickly that the code to create a MapQuest map, and set the center and default zoom, is a little shorter than the Google Maps and Yahoo Maps offerings. What will also jump out at you is the size difference in the SWF itself, weighing in at 80 kb, which is essentially double the size of the other two APIs. It should go without saying then that the result entire page load then is also impacted, coming in at around 354 kb. Why the size difference as compared to the other two APIs?
I went to the source on this and spoke with MapQuest staff directly. After reviewing their comments, and formulating my own opinion, it really comes down to functionality.
Take a look again at the source code for the MapQuest map and then compare it to the other two options. It’s shorter, right? A bit more concise? Yeah, but it doesn’t make that much difference does it? In this little example, no, but in a full application, the subtleties of the API can make all the difference. When exploring the MapQuest documentation (in which ActionScript was always treated as a first class citizen), I found this efficiency in the API to run across all the features. Those features also tended towards classic GIS systems, which makes the MapQuest API really ideal as the programmers map API.
Conclusion
Obviously, as I stated up front, not all APIs are created equal, and they should really be looked at as tools from which you can choose. Google Maps is new, but has compelling features. Yahoo Maps tends to be the standard for Flash, but isn’t without it’s JavaScript tendencies. MapQuest will give you more GIS-oriented features and a cleaner API, but will cost you in overall size.
Personally, the fact that the MapQuest staff would even talk to me, was a big differentiator. I wasn’t treated as just another forum user, but as a valued developer in their ecosystem. In fact, I now know more about their roadmap (more on that in a future post), and they’ve even accepted some optimizations I suggested.
I’ve since gone on to start a larger project with the MapQuest API, but don’t want to discourage you from looking at all the available options yourself. Check out the features and documentation of each of the APIs and make your own call. You can download the source code for these examples to help you get started. That original challenge as laid out by my friend those few years ago, ended in failure. Your mapping features/applications don’t have to now with more options available to the Flash developer than ever before.
July 17th, 2008 at 2:50 am
very interesting post Kevin, even if I’m not using any mapping services in my projects for the moment
Take care,
Cyril
July 18th, 2008 at 2:45 pm
Thanks for the great article!
We know the key system isn’t always fun for developers; hopefully this situation will improve in the future.
Stay tuned as we keep making improvements to the Google Maps API for Flash.
July 27th, 2008 at 11:49 pm
Kevin, how about adding one more review. The ESRI flex components should be added to your list.
August 3rd, 2008 at 10:58 am
Mike, don’t forget the open-source project called ModestMaps. http://modestmaps.com. It combines all the major APIs, into one framework, and allows you to tie your own objects into the other vendors maps.
August 18th, 2008 at 3:50 pm
I just gave a talk covering the same state topic at the San Diego Flash User’s Group. I’ve posted my slides at http://www.sdfug.org. I did cover the ESRI components as well as Modest Maps. The deck is a bit visual, so I am not sure if it translates well without me presenting.
October 18th, 2008 at 6:18 am
Kevin a very interesting article but the download link is dead…
October 21st, 2008 at 4:01 pm
Bruce,
Thanks for the catch! I don’t know where the file went, but I’ve uploaded the content again. The download link should work now.
Thanks again,
Kevin