Flex/Flash/Actionscript, Maps

What I’ve been working on: MapMyPix

universal_mind.jpg

One of the recent projects I have been working on with a team at Universal Mind is the MapMyPix AIR application that allows you to take data from a handheld GPS device and mash that together with pictures from a digital camera and automatically geocode your photos.
128.png

What it does
You drop a GPX file (which is what you get from your GPS device) onto the application and it shows your route. Then you drop a bunch of pictures onto the route and it automatically analyzes your pictures and figures out where along the route they were taken. Now you’ve got a geocoded photo set that you can view on the map and upload to Flickr to share. When the photoset is uploaded to Flickr the geocoded data is uploaded as well, so you can view your photos on a map. You can share the uploaded photoset with other people by sending out a link, or you can embed your mapped photos in a blog post or web page.

mapmypixscreensnapz002.jpg

Who this is for
Primarily this application is for someone who has a handheld GPS device and likes taking pictures on hikes, or ski trips, or other outdoor activities. The application also has broader implications in the business realm where large sets of photos need to be combined with GPS data (scenarios like real estate brokers, insurance investigators, etc come to mind). If you’re a backpacker and you take pictures along a hike and you carry a GPS device, then this app is right up your alley.

If you don’t have a GPS device you can still use the application to geocode and upload your photos. You can manually drag individual photos to set their geo locations. Further enhancements to the application are in the works to make the application more friendly to people without GPS devices, since for this initial release we were really focusing on users who have GPS data.

mapmypixscreensnapz003.jpg

Why this is cool
There are other ways to geocode your pictures. Flickr allows you to geocode pictures that you’ve already uploaded. But the process involves dragging each individual picture onto a location on the map. When you’ve got a hundred pictures from a hike you took this is painful. Not to mention that you’ve got to upload your photos first from your computer, then do all this manual gecoding one by one after the photos are online. Lame.

With MapMyPix we’ve combined the geocoding and uploading process into a smooth interface. Since this is an AIR app you get all the slick mapping capabilities that you can get with a Flex app. And since it’s a desktop application we allow you to simply drag a whole folder full of hundreds of images straight from your computer onto the map and boom, they get geocoded. Sweet.

mapmypixscreensnapz004.jpg

Some technical details
The app is a Flex application using the MapQuest AS3 API. Universal Mind made the MapQuest AS3 API (you can read the businessy sounding case study here). I’ve worked with both the ESRI AS3 API and the MapQuest API. Without making any comparisons I will say that the MapQuest API is great to work with. It’s fast, simple, and does everything I’d expect a map API to do (I’m not trying to kiss ass here, it actually is a very solid API).

The core application is a desktop AIR app. However, we also used almost entirely the same code base to create an online viewer application that is used to display photosets once they’ve been uploaded. After a photoset is uploaded we provide a unique URL and embeddable code that uses a Flex application to display the images on a map for sharing. Since the whole thing is a Flex app it took almost no work to spin off the online viewer after we had made the AIR desktop version.

Where we had issues

  • Time
    We had 3 developers. We thought we had 3 weeks. We had a blank canvas (ie we were able to brainstorm and come up with the ideas behind the app from the ground up). Awesome. We brainstormed like mad and came up with far more ideas than we could implement in 3 weeks. So we identified core functionality and then stuff that we hoped to have time for (got a bunch of that in there) and stuff that we would like to see (got some, but most of that is still waiting for the next version). Then after a week of work it turned out that there had been a mistaken assumption about the deadline and we lost 2 days. That’s like 10% of the total time. So that meant that the last week and a half were kind of a mad rush to accomplish as much as possible. I actually enjoyed this a lot, but it was definitely a bit stressful.
  • AIR suckiness
    This was Flex 3 Beta 1 and that meant we had a completely asynchronous SQLLite implementation. That sucked. Lots of time was spent coming up with ways of doing complex database transactions in an asynchronous environment. That wasn’t my job on this project so my life wasn’t too bad, but if you ever meet John Yanarella ask him how much he likes asynchronous SQLLite work. In addition to the DB stuff, I ran into lots of AIR memory issues. Our app dealt with very large images (multi-megabyte photos) and lots of them. We wanted the user to be able to quickly browse between hi-res images. But it turns out that if you load a few hi-res images in an AIR app one after the other the garbage collector decides to go on strike and you hit memory errors and the app crashes. Great. Adding in the localConnection GC hack fixed this.
  • Timezones! Argh!
    So GPS units save their time in UTC time, which is awesome because that means we don’t have to worry about time zones. If we have a date from a GPS we always know what universal time that means. The problem comes when you add in a camera. Cameras typically store images in JPEG format with EXIF data to store metadata. One field in the EXIF data is the data and time the photo was taken. Cool. But what ISN’T stored in the EXIF data is a friggin timezone to let you know the real time. So we have to make some assumptions about the camera timezone. We allow the user to adjust the UTC offset for their camera (which means which timezone the camera is set for) and then the syncing with the GPS can work as it should. If only the stupid EXIF data told us timezone…

A few more pretty pictures:

mapmypixscreensnapz005.jpgmapmypixscreensnapz006.jpg
mapmypixscreensnapz007.jpgmapmypixscreensnapz008.jpg

Links:

And here’s an example of an embedded MapMyPix geocoded photoset that was uploaded using the app:

Related:

  • All of us at Universal Mind who have been hard at work on SpatialKey are incredibly proud to announce that we have begun a private beta program. To really launch this product in style, we've put together this video to give an overview of the SpatialKey system. Even after watching…
    Tags: data, time, work, mind, universal
  • I have recently decided to make the move from an independent subcontractor to a full-time employee with Universal Mind. This is a big decision for me, one that I've been debating for a while now. I'll try to explain my thinking a little. My official job title will be Principal…
    Tags: time, work, flex, working, stuff, mind, universal
  • The most recent issue of ComputerWorld magazine features a cover story called "Can Web 2.0 Save B.I.?" that features a case study on SpatialKey. In the article they interview Chief Jon Greiner of the Ogden Police Department in Utah. Ogden is the first installation of the enterprise version of SpatialKey…
    Tags: data, working, mind, universal
Standard

12 thoughts on “What I’ve been working on: MapMyPix

  1. @shaun – The app compares timestamps of when the photo was taken against the GPS track points (which have timestamps as well). It finds the closest track point, and assuming it’s within an acceptable range in time it places the photo at that point on the map.

  2. esri’s APIs are always a bit quirky but their support for aws flex is actually pretty good so far. esri’s data outside the US is quite a bit better than mapquest’s. they also have a “free” public webservice. neither is as good as google’s–google’s negative is their localization, we’re building a flex app right now with global sample data & while thai users are very happy to see thai language vector maps they’re not so happy to see japanese language ones.

    btw you guys never heard of scalebars or north arrows 😉

    in any case, is this app US-only? i tried dragging a GPX file from my bike riding NE of bangkok & got no joy.

  3. @PaulH – the app shouldn’t be limited to the US only, it should work worldwide, but MapQuest’s service only provides tiles for a limited subset of the world at the moment. I know they just added New Zealand recently, and we’ve tried the app with a data set there (actually, some of the screenshots I posted are showing New Zealand). When you load your GPX file, does it display the route as a red line and just not show the map? If so that means that MapQuest doesn’t yet support that area with their API. It’s a new APi so I think they’re rolling out worldwide support for map tiles as they go.

    I’m also heavily involved right now in a Flex project using ESRI’s API. There are things I like about both APIs, interesting that you would say that neither is as good as googles. From an API standpoint what does google have that the others don’t?

  4. You guys might want to look into using the EXIF embedded JPEG thumbnails that most modern digital cameras use. Kevin Hoyt’s blog has an interesting article on this:

    http://blog.kevinhoyt.org/2007/07/06/exif-thumbnails-and-the-air-bus-tour/
    http://blog.kevinhoyt.org/2005/11/01/actionscript-3-meets-exif-21

    I met him at the Adobe OnAir tour in Boston and was talking strategies with him about building thumbnails from large JPEG files, and he pointed me to the embeded thumbnai stuff.

    I have an Air application that scans a directory of images and makes thumbnails out of them. I haven’t really run into any memory issues. I going through great pains, though, to call dispose on Bitmapdata.dispose, and try to reuse image resources. And since the asyncronous nature of Flex/AIR, I had to go through great pains to link events in a specific order as to only process a single image at a time.

  5. @Todd – we make heavy use of the EXIF thumbnails. All thumbnails shown in the application on the map are the extracted EXIF thumbnails (and if not available we save our own thumbnail). The problem came when we wanted to let people view the full resolution image (which you can do if you select an individual image on the map). Then you can navigate between the other images and view any of those in hi-res mode. It was when were were loading these full size images that we ran into memory problems.

    And we’re doing a similar thing that it sounds like you’re doing to save our own thumbnails if no EXIF thumb is available, which is to set up a queue of image resizing processes and run one after the other, making sure to dispose of bitmapData objects, etc.

  6. Jonas says:

    There are also potential applications for environmental consultant types for vegetation monitoring and surveys, though we are usually using commercial grade units that don’t utilize the .gpx file type. Would be great for municipalities mapping trees, signs, or anything else where knowing the rough location as well as the condition of the object is important, but sub-meter accuracy is not necessary.

    Would be perfect to map the photos on a canoe trip down the Suwanee River in December. You interested or what? Jambo and Terry are making some noise like they might make the trek to Florida. It will be a good time. Let me know.

  7. Pingback: d.c.Holth » Blog Archive » MapMyPix. The best photo geocoder ever.

  8. Pingback: Flex-info.fr : Communauté Flex » Blog Archive » Application GPS - Photos

Comments are closed.