Welcome, guest Sign Out

Yahoo! Developer Network Blog

« Previous | Main | Next »


May 12, 2008

Abstracting Spatial Relationships with the Yahoo! Internet Location Platform

Note: This blog post was originally published on the Yahoo! Local & Maps Blog.

Like the London Tube Map, recording and retrieval of locations and their relationships doesn’t always have to do with their Lat/Lon. There is a more elegant way to abstract the relationships of location, and unambiguously describe places in a permanent, language-neutral manner. Since Where on Earth joined Yahoo! in 2005, Yahoo! has geo-enabled the network, including geo-tagging advertising, Flickr photos, Yahoo! Maps, and so many of the location-based services that Yahoo! has offered.

Yahoo! is now offering a developer preview of this Yahoo! Internet Location Platform.

Here’s an example of the new platform in action. Check out this photo on Flickr. This photo was geo-tagged by the user, and since it was placed on a map, we were able to give it a set of these location tags. If you browse in to the tagged metadata using the Flickr API, you’ll notice a set of geo-tags called WOEID (Where On Earth IDs) which are permanent, unambiguous, language neutral tags that represent that location.

Since we have content with a tag, we can find out some interesting things, tag 727232 for example, is Amsterdam, and we can use the new APIs that we’re releasing to find out all sorts of relevant relationship information, including:

  • The parent, the administrative region of Amsterdam
  • Neighbors, such as Landsmeer, Zaandam, and Watergang.

  • Belong Tos, such as North Holland, Western Europe, and the Europe/Amsterdam Time Zone

  • and more!

  • (Note: The links above are in XML, and may not be viewable in all browsers.)



This service allows you to discover location relationships from free-text place names, tag your content with location IDs for easy indexing, disambiguate numerous objects tagged with the same location, and so on.


Go ahead and check out the documentation on the Yahoo! Developer Network at http://developer.yahoo.com/geo/.

Congrats to the Yahoo! Geo team on this preview.

Michael Lawless
Sr. Product Manager, Yahoo! Maps

P.S. For more on subject, check out the post by Dan Catt on geobloggers.com.

Posted at May 12, 2008 6:58 PM

Comments

I get 406 errors when I click on the example links in your post:


406 Not Acceptable

Requested representation not available for this resource

Posted by: Ryan Shaw at May 12, 2008 8:27 PM

This is great! Very nice service, very useful, in fact so useful we
may want to use it in an app.

To use it in an app, though, we'd need to know what would happen if
Yahoo decided to shut it down. According to the T&Cs, Yahoo can shut
it down without any notice at any time, which of course would be a
problem. We'd also need some clarification about the attribution
clause when the service was used as part of a back-office function.

The feature set is really nice. I like belongtos and all that. One
thing that would be nice would be some sort of confidence score for
the various matches, e.g. Boston matches Boston, MA with 99%
confidence and Boston, Lincolnshire with 1% confidence.

It would also be useful to be able to set some sort of context for
searches. Right now, you can set the context to be a state or country
using the syntax "xxx, yyy", but that doesn't work for a continent --
e.g. 'oxford,europe' finds Europe (24865675), but not Oxford and
'rome,europe' finds Rome, Italy, but also various US Romes. And as far
as I can tell, there is no way to say "the York that has something to
do with higher education (i.e. York University)" or "the Washington
that has something to do with the Pacific Ocean" (or with salmon!).

Here are a few observations about the system's behavior. I hope they're useful.

The place lookup usually works very well, and it is very useful that
it is "ordered by the most likely", but it seems to be very US-centric
and have other areas that could use improvement. I'm afraid the
following list includes data problems, algorithm issues, etc., all
mixed together...:

* 'oxford' gives Oxford, MS, OH, NY, CT, PA, before Oxford,
Oxfordshire, UK. And it doesn't return Oxford University at all
(though 'oxford university' does, and 'harvard' gets Harvard
University as #1). Surely the most likely referent of plain
'Oxford' is first of all the University, secondly the city in
Oxfordshire (outside, say, Faulkner scholarship). Compare the Yahoo
search results for 'oxford' or the query 'harvard', which finds
Harvard University as #1.

* 'boston' correctly gives #1 Boston, MA, but doesn't give Boston,
Lincolnshire (13318) at all. Clearly Boston, Lincolnshire
(population 35,000) is much less likely than Boston, MA (population
600,000), but it is surely more likely than Oxford, WI (population
536) is for 'oxford'.

* 'lincoln' finds Lincoln, Lincolnshire (population 100,000+) as #35,
after a host of obscure US towns.

* 'boston,uk' correctly finds Boston, Lincolnshire, but not Boston
Borough (12696016), which contains it.

* 'syracuse' finds #1 Syracuse, NY (OK) and various minor US
Syracuses, but not Syracuse, Sicily, Italy (724236), which should
be #2 or possibly even #1

* 'poland springs' returns #1 Poland (country) which is not relevant,
and Poland, ME (which is) as #2, and not Poland Spring, ME; 'poland
spring' correctly returns Poland Spring, ME.

* 'harvard,ma' finds Harvard University, but not the town of Harvard,
MA (#3 for 'harvard')

* the list seems to be cut off arbitrarily, sometimes including very
obscure places, sometimes not. For example, 'washington' finds
Washington, DC and Washington State, but none of the dozens of
towns named Washington, including Washington, MA.

* 'ucsb' finds the University of Sao Paolo (? I don't believe this is
a common name for it); Ausbau, Germany (substring?); Esenboga,
Turkey (???); Esbo, Finland; etc. but not the University of
California at Santa Barbara, by far the most common referent.

* I can't get the neighbors of Europe (place/24865675/neighbors).

* 'crete' gives Crete, NE, IL, before Crete, Greece, which seems wrong.

* 'luxembourg' gives only the country; 'luxemburg' correctly gives
the country as #1; but neither gives the Belgian region of
Luxemburg (7153302).

* 'danzig' gives Danzig, ND as #1, and Gdansk as #2, which seems
backwards.

* 'alps' doesn't find the Alps, and 'the alps' finds 55863663, coded
as a Land Feature in Italy (not France, Switzerland, Austria,
etc.?!)

* 'clitunno' doesn't find Campello sul Clitunno, Umbria, Italy
(711845 -- its name is given as Campello)

* I'm not sure where your historical data comes from, and frankly it
is not terribly useful for our business application, but a few
quick tests show that it is rather incomplete: nothing for Lutetia
(modern Paris); 'new amsterdam' doesn't find New York; 'prussia'
finds a town in Iowa; 'rhodesia' finds a town in Nottinghamshire,
not Zambia (formerly Northern Rhodesia) or Zimbabwe (formerly
Southern Rhodesia, then just Rhodesia).

* 'mid-cambridge' is listed as a 'suburb' in Middlesex County, MA.
In fact, it is a neighborhood entirely contained in Cambridge, MA.

* 'state house' gives the Kansas State Capitol (55862270) as a
suburb. Aren't there 49 other state houses?

* 'czechoslovakia' (24865708) is a Supername whose only child is
the Czech Republic; Slovakia should also be its child

Posted by: Stavros Macrakis at May 13, 2008 2:10 PM

@Ryan Shaw: Are you using Internet Explorer 6?

Taken from the ILP page on YDN: http://developer.yahoo.com/geo/


The API is accessed via HTTP GET; the following examples can be cut-and-paste into a web browser to view the results (note that these links do not work properly with IE6):


The links work fine in other browsers; I've had no issues on FireFox or on Safari

Posted by: Gary Gale at May 14, 2008 6:33 AM

Some browsers send a restrictive Accept header (content type) such as image/gif or text/html which is not supported by the web service. You can override the content type by using the format parameter. Append "?format=xml" to get an XML response, or "?format=json" to get a JSON response.

Posted by: Eddie Babcock at May 15, 2008 9:37 AM

@Stavros Macrakis -- many thanks for the detailed comments. The Y!Geo team will be providing additional documentation on ILP shortly which will answer the majority of your concerns, but in the interim:

T&C: more will follow
Many of your issues relate to disambiguation. We will be providing more information on how the focus can help ensure that the relativity of Place is accommodated, but the guideline is to be as specific as possible in your query: if you want to know the WOEID for Oxford UK, submit 'Oxford, UK' to the system; same for 'Boston, Lincs'.
Alps: natural features are not supported in this release
Historical Data: also out of scope for this release; we will define the contents with greater detail when the Developer Preview is concluded.

Please consider continuing this dialog on the new ILP Group Mail List.

Posted by: Tyler Bell at May 16, 2008 8:43 AM

Posted by: Tyler Bell at May 16, 2008 8:46 AM

Post a comment

Comment Policy: We encourage comments and look forward to hearing from you. Please note that Yahoo! may, in our sole discretion, remove comments if they are off topic, inappropriate, or otherwise violate our Terms of Service.

Remember Me?

Subscribe

YDN Blog: Get Yahoo! Developer Network Blog on your personalized My Yahoo! home page.

Add To My RSS Feed

YDN Link Blog: Get Yahoo! Developer Network Linkblog on your personalized My Yahoo! home page.

Add To My RSS Feed

Recent Readers

YDN LIBRARIES & BEST PRACTICES

YAHOO! APIs & WEB SERVICES

LANGUAGE CENTERS

Copyright © 2009 Yahoo! Inc. All rights reserved. Copyright | Privacy Policy

Help us continue to improve the Yahoo! Developer Network: Send Your Suggestions