Yahoo! Maps APIs, aka ‘grr, argh!’

I have a love/hate relationship with Yahoo!’s mapping API. It’s lovely that Yahoo! believes, unlike Google and other mapping providers, that their satellite data is a suitable base layer to use for derivation of vectors. This openness really is good to see — they win big points from me in this regard. (Google, on the other hand, is happy to have you give them data against their satellite imagery, but letting you actually have it back is against the Terms of Service.)

However, the Yahoo! Maps AJAX API has never gotten much love. I think that a preference for flash has always existed in the Yahoo! world; iirc, their original API was Flash.

However, I realized today that this tendancy to leave the AJAX API in the dust has resulted in something that seriously affects me: The Yahoo! maps AJAX API uses a different set of tiles, which has two fewer zoom levels available in it:

AJAX Maps: most zoomed in Flash Maps: Most zoomed in

For the new OpenStreetMap editor I’m working on, this is a *serious* difference: although the information actually available in these tiles isn’t *that* much higher, it allows the user to extract more information by getting in a bit more, and to be more precise in placement of objects when using Yahoo! as a basemap.

Although it would be relatively easy to rip the tiles out, and create an OpenLayers Layer class that loaded them directly, this violates the Yahoo! Terms of Use. This is understandable, but unfortunate, because it means I can’t solve the problem with my own code.

What I would really love to see is more providers creating a more friendly way of accessing their tiles. I understand the need for counting of accesses, and the need for copyright notifications. If an API were published, that allowed you to:

  • Fetch a copyright notice for a given area, possibly also returning a temporary token to use
  • Following that, fetch tiles to fill that area
  • Require users to copyright notice in such a way as to make Yahoo! and their providers happy

This would allow for building a layer into OpenLayers which complied with this, without depending on Yahoo! to write a Javascript layer that did these things for me.

Now, it’s understandable that this doesn’t happen — having the client out of control of Yahoo! means that they can’t *enforce* that the copyright is displayed prominently, as they are able to (to some extent) with their API. However, I think that this type of API would allow more innovation, and possibly even a *more* prominent placement for Yahoo’s copyrights and notices. For example, in many mapping apps, the bottom inch of the map is not seen much by the users. If there was an API to get text to display, then an application could display the text in a more prominent location, rather than burying it under many markers or other pieces of text that might overlap it.

In the short term, all I really wish was that the AJAX API used the apparently-newer set of satellite tiles that the Flash API appears to have access to. I think the fact that this isn’t currently possible leads to an alternative access pattern for tiles, one which may make more sense in the long run, where tiles can be used by an application without necessarily running in the constrained Javascript API that these providers have the ability to write. And of course, if you want to provide your users with a ‘default’ API to use, you can always use OpenLayers, and extend it to include your own extensions…

4 Responses to “Yahoo! Maps APIs, aka ‘grr, argh!’”

  1. Tom Hughes Says:

    When you were doing this comparison were you using the Yahoo JS API directly, or via OpenLayers? Only I wonder if OpenLayers ticket #1384 may have some bearing on this?

  2. crschmidt Says:

    Yahoo! API Directly, using the examples on their site. (I never trust that OL is actually doing things right.) If you look at the URLs, you’ll see that they have different image paths in them: one uses ‘/ae/’, and the other uses ‘aerial.maps.yimg.com’. The former is ‘0 at most zoomed in’ (1, actually), the older style of tile access that was originally used by Google Maps when no one thought they’d ever need more than 17 zoom levels, while the latter is ‘0 at most zoomed out’, a more sane pattern. (I’ve never had a problem increasing MAX_ZOOM_LEVEL on a map, since I know OL won’t ever keep up with these things.)

    That said, thanks for pointing out 1384; it’s committed now. (I don’t tend to see things without a milestone, sorry about that.)

  3. Bill McGonigle Says:

    It seems like more work to maintain(store,distribute,backup) two sets of tiles – is this really all to promote the Flash product, or just that the AJAX product hasn’t been touched for n(units of time)?

  4. crschmidt Says:

    Almost definitely the latter.