Posts Tagged ‘api’

A Year On And Yahoo’s Maps API Finally Shuts Down

Nothing on the interwebs is forever. Services start up and either become successful, get acquired or shut down. If they shut down they usually end up in TechCrunch’s deadpool. The same applies for APIs and when they finally go offline, they usually end up in the Programmable Web deadpool.

YDN Maps Shutdown

At around 1.30 PM London time yesterday, the Yahoo! Maps API got added to the Programmable Web deadpool for good. Despite the announcement I wrote about last year that it was being shutdown on September 13, 2011, up until yesterday the API was very much alive and well and still serving up map tiles, markers and polylines via JavaScript.

Yesterday I was running some tests on the latest pre-release version of Mapstraction, which still supported the Yahoo! Maps API and they were running without error all morning. Then they stopped. The API just wasn’t there anymore.

$ wget http://api.maps.yahoo.com/ajaxymap?v=3.8&appid=(redacted)
Resolving api.maps.yahoo.com... 98.139.25.243
Connecting to api.maps.yahoo.com|98.139.25.243|:80... connected.
HTTP request sent, awaiting response... 503 Service Unavailable

A quick look at the API’s home on the web at developer.yahoo.com/maps/ajax/ shows an update to the previous shutting down message, with developers now being redirected to developer.here.net, the home of Nokia’s new Here Maps API.

So whilst the demise of the Yahoo! Maps API in September of last year proved to be somewhat exaggerated, the plug has now been well and truly pulled.

I’ll always have a soft spot for the Yahoo! API; it was the first mapping API I really cut my teeth on and while things change on the interwebs on a daily basis I can’t help but feel sadly nostalgic.

This does mean that the next release of Mapstraction will no longer support the Yahoo! Maps API, though it will support Nokia Maps and Here Maps. My signed copy of Charles Freedman’s Yahoo! Maps Mashups will also continue to remain on my office bookshelf as a memento.

Written and posted from home (51.427051, -0.333344)

Big (Location) Data vs. My (Location) Data

For a pleasant change, the guts of this talk didn’t metamorphose oddly during the writing. Instead, it geolocated. This was originally planned to be my keynote talk at Social-Loco in San Francisco last month. But I wasn’t able to make it to the Bay Area as planned for reasons too complex to go into here. Suffice to say, the slide deck languished unloved on my laptops hard drive, taking up 30 odd MB of storage and not really going anywhere.

Then I got an email from Stuart Mitchell at Geodigital asking me if I’d like to talk at the AGI’s Northern Conference and thus, after a brief bit of editing to remove the conspicuous Silicon Valley references, this talk relocated from San Francisco to Manchester. As per usual, the slide deck plus notes are below.

Read On…

Two WordPress Plugins And The (Missing) Nokia Map

It’s a glaringly obvious oversight but a few month’s back I realised that given what I do for a living, there’s something missing from my blog and that something is a map.

There’s a whole slew of “where am I” style WordPress plugins out there, but after some careful research I decided that none of them did precisely what I wanted, which was to show the last check-in I made on Foursquare, on a map, in the sidebar of my blog.

Those that did come close still didn’t do the key thing I wanted and that was to use the map I work on as part of my day job. Now don’t get me wrong, I’ve got nothing against the maps that I could have used; Google, Bing, Mapquest and OpenStreetMap produce very fine maps and they all have the JavaScript API I’d need to display my last checkin. But none of them used my map and that means a Nokia Map.

So taking what I’d learnt about WordPress plugins during the course of producing 12 versions of the WP Biographia plugin, I rolled up my sleeves (mentally and literally) and started work on what would become WP Quadratum. I seem to have a thing about naming my plugins using a Latin derivation of their name; I have no idea why, but it seems to be better than something along the lines of WP Yet Another Foursquare Checkin Plugin. But I digress.

Several months later, after wrestling with getting a plugin to authenticate with Foursquare via OAuth 2 and learning how to write not only a WordPress plugin but also a WordPress widget, WP Quadratum appeared on the sidebar on my blog. It’s over there right now, towards the top right of your browser screen, unless your reading this on a mobile device, in which case you’ll just have to take my word for it for now.

Now Nokia allows free and unauthenticated use of the JavaScript Maps API, but only up to a certain number of transactions over a lifetime. So I also built in support for supplying Nokia’s Location API credentials as well. But then I stopped. Why build custom support for authentication and credentials into a plugin, only to probably have to copy-and-paste the code into another plugin I write that will use the same Maps API? So I digressed again and wrote another plugin, WP Nokia Auth, that handles the Nokia credentials for me, and then made WP Quadratum play nicely with WP Nokia Auth, if it’s installed, active and configured.

It took a while, but v1.0 of both plugins are now up on the WordPress plugin repository and on GitHub as well, for the usual forking, downloading, hacking and poking around. Whether they get the same number of downloads as WP Biographia has (over 7,000 to date) I somewhat doubt, but unless I release these, I’ll never know, so that’s just what I’ve done.

Written and posted from home (51.427051, -0.333344)

Farewell Yahoo! Maps API, Hello Nokia Maps API

Yahoo’s JavaScript and AJAX API was the first mapping API I ever used and it now seems hard to remember when Yahoo’s API offerings were the dominant player, always iterating and innovating. The Yahoo! API set formed and continued to underpin the majority of my online presence. When I wrote about leaving Yahoo! and joining Nokia in May of 2010 I said …

So whilst I’m going to Nokia, I’ll continue to use my core set of Yahoo! products, tools and APIs … YQL, Placemaker, GeoPlanet, WOEIDs, YUI, Flickr and Delicious. Not because I used to work for Yahoo! but because they’re superb products.

… and I meant every word of it. The Yahoo! APIs were stable, powerful and let create web experiences quickly and easily. But now a year later a lot has changed. I still use Flickr on a pretty much daily basis, but Delicious is no longer a Yahoo! property and I transitioned my other web presence from using YQL for RSS feed aggregation to use SimplePie as YQL was frequently down or just not working. The original core set of Yahoo! APIs I use in anger is now just down to Flickr and YUI.

YDN Maps Shutdown

Sadly, this trend is continuing and on September 13th, to badly mangle the quote from Cypher in The Matrix, “buckle up your seatbelts Map scripters, ’cause the Yahoo! Maps API is going bye-bye” and writing …

var map = new YMap(document.getElementById('map'));

… will be a thing of the past. Adam Duvander, author of the excellent Map Scripting 101, has written a eulogy for the Yahoo! Maps API over on Programmable Web, including some pithy quotes from old friend Tyler Bell, whom I worked with when I was part of the Yahoo! Geo Technologies group, which sadly echo my comments on the overall demise of Geo at the company.

Thankfully all is not doom and gloom in the world of mapping APIs and Nokia’s Maps API is firmly in the spotlight to take up the slack left by the addition of the Yahoo! Maps API to the deadpool. And if you’re using Mapstraction with the Yahoo! Maps API, it should be relatively trivial to swap your code over to the Nokia API as Mapstraction now supports Nokia Maps. I may have had a hand in that.

Written and posted from the British Airways Galleries Lounge at London Heathrow Terminal 5 (51.4702, -0.4882)

Mapstraction, Maps and Me

It’s been a while since my last blog post; my day job at Nokia has been taking up almost all of my time and what little time has been left has been spent with my family. But in between day job and family time there’s evenings spent in a hotel room and hours spent on a plane, mainly between London’s Heathrow and Berlin’s Tegel airports. It’s in these periods of time that a combination of my MacBook Pro, running a combo of Apache/MySQL/PHP with MAMP and TextMate has allowed me to rediscover the pleasure of what I used to do for my day job before Yahoo! and before Nokia … and that’s to write code.

As a fully unreconstructed maps nerd, I love the variety and richness of the mapping APIs available on today’s internet. One of the best books on how to use these mapping APIs is the “does just what it says on the label” Map Scripting 101 by Adam DuVander. While the book touches on the power of the APIs from Google, from Yahoo, and from Bing (amongst others) its main focus in on Mapstraction, the JavaScript mapping abstraction library.

Brain Map

As the name suggest, Mapstraction abstracts, or wraps, the differences between the variety of approaches that each JavaScript mapping API uses into a single consistent interface. With Mapstraction, the API methods to create a map, to change the zoom level, to centre the map, to add a marker or push pin to the map are the same, regardless of which underlying mapping API you use.

Mapstraction allowed you to use the mapping APIs from Google, Yahoo, Bing, Cloudmade, GeoCommons, Cartocuidad, Yandex and MapQuest. But not Nokia’s Ovi Maps API, which was released in February 2011. This is where my local Apache installation, TextMate and the aforementioned hotel room and flight time comes back into the story. Cue a frantic crash course to reacquaint myself with JavaScript, some trial and error, some swearing and some background reading to convert my slightly outdated knowledge of CVS into how to use git and Mapstraction now supports the Ovi Maps API. No, really. It’s on github right now.

There’s a demo of some of the major features of both Mapstraction and the Ovi Maps API over at maps.vicchi.org and, in the spirit of social coding, the source for that is on github as well.

I’m not suggesting for one moment that if the current geo day job falls through I can happily pick up a replacement role coding JavaScript, or coding anything for that matter, but it’s oddly reassuring that I still have the vague ability to continue the profession of coding software that earnt me a living for almost 25 years.

Photo Credits: Infidelic on Flickr.
Written and posted from home (51.427051, -0.333344)

Service Suspended On The London Underground (API)

If you build it they will come. Or to put it another way, sometimes demand outstrips supply. After the phenomenal success of the Transport For London Tube API, the London Datastore blog sadly notes:

Owing to overwhelming demand by apps that use the service, the London Underground feed has had to be temporarily suspended. We hope to restore the service as soon as possible but this may take some days. We will keep everyone informed of progress towards a resolution.

In the meantime, if you want to see how it does looks when the API is up and running there’s a video clip of Matthew Somerville’s recent Science Day hack visualisation over on my Flickr photo and video stream.

No Victoria line service after 2000 tonight

Photo Credits: Martin Deutch on Flickr.
Written and posted from Berlin Tegel Airport (52.5545447, 13.2899969)

Latitude Inconsistitude

In the midst of yesterday’s I/O event, Google announced the launch of the long rumoured API for their Latitude location sharing platform; there’s ample coverage and commentary on ReadWriteWeb and on TechCrunch and that’s just fine because that’s not what I want to write about.

When it was launched in early 2009, Latitude was the receipt of some fairly harsh press from the informed tech media and from the uninformed traditional media and I argued for some latitude in the discussions on, err, Latitude.

Latitude kept on getting compared to Yahoo’s Fire Eagle and the main gripes seemed to be:

  1. Latitude is a consumer application built into Google Maps, not a platform
  2. Latitude doesn’t have an API
  3. Latitide’s privacy model is opt-in but all or nothing

So now Latitude has an API and everyone’s happy. Right?

Unofficial Google Latitude T-Shirt

Wrong. The previous gripes have been done away with and replaced with three more gripes.

  1. Latitude needs to run in the background and so will either drain battery life or won’t run in the background on an iPhone at all.
  2. Latitude now has granular privacy controls but these are on the back-end so Google will know your location prior to federating it to location consumers via the API.
  3. Latitude needs a Google account to use.

There’s a lot of inconsistency here.

  1. Latitude, as part of Google Maps, already runs in the background on handsets that support that. The iPhone doesn’t, yet, but that’s an iPhone OS issue not a Latitude issue. Short battery life is a feature of almost all smartphone class handsets, Latitude or not.
  2. Latitude gains granular privacy controls but they’re on the back-end so this is a bad thing. Fire Eagle has granular privacy controls and they’re on the back-end but this has never been a source of complaint.
  3. Latitude needs a Google account to use. Correction. Latitude has always needed a Google account to use, so this is a bad thing. Fire Eagle has always needed a Yahoo! Id to use, and yet this is something not seen as a contentious issue.

One of the criticisms that was levelled at Fire Eagle was lack of a definitive consumer application at launch; a not unfair criticism. Latitude’s taken the inverse approach, launching with a consumer application and then opening up an API almost a year later.

Time will tell which of these two location sharing platforms will dominate or whether they will be usurped by another unseen contender.

Photo Credits: moleitau on Flickr.
Written and posted from the Yahoo! London office (51.5141985, -0.1292006)