I was invited to attend this event and presented a talk entitled The Open Location Ecosystem and the Mobile Internet, together with Justin Davies from NinetyTen and Buddyping and Andrew Grill, a mobile advertising evangelist.

Mobile Location-Based Services (LBS) have been ‘the next big thing’ for years now, but have not materialised due to a mixture of technical and business constraints. With increasing numbers of mobile phones being equipped with Wi-Fi and GPS receivers, this looks set to change.

What are the main location technologies and how do they work? What technical, business and social challenges do companies face when developing LBS for mobiles? What LBS can we expect to see on mobiles in the next 2-3 years? How will current favourites such as social networking and online advertising evolve in a location-aware world? This talk will address these questions and more.

Join us at this dynamic free event to learn more and share your views.

Our expert presenters are:

* JUSTIN DAVIES Founder & CTO, NinetyTen/Buddyping,
http://www.ninetyten.com http://www.buddyping.com
* GARY GALE Head of UK Engineering, Yahoo! Geo Technologies,
http://www.ygeoblog.com, http://developer.yahoo.com/geo/
* ANDREW GRILL Mobile Advertising Evangelist
http://www.andrewgrill.com/blog/

Yahoo! received a very warm welcome from the BCS, from the other presenters and from the audience; the hot topics for Yahoo! at the Q&A session afterwards were GeoPlanet, use of WOEIDs and Fire Eagle. The deck I presented is available for download here.

The resources referred to in the Yahoo! presentation are listed below.

• Yahoo! Geo Technologies blog - http://www.ygeoblog.com
• Fire Eagle: http://fireeagle.yahoo.net/
• Fire Eagle Developer APIs: http://developer.yahoo.com/fireeagle/
• Yahoo! GeoPlanet: http://developer.yahoo.com/geo/
• Yahoo! BluePrint: http://mobile.yahoo.com/developers/roadmap

More outreach and talks of this type are being planned and you’ll be able to read about them here on the Yahoo! Geo Technologies blog first.

Gary Gale, Head of UK Engineering, Yahoo! Geo Technologies

First, we added a new query parameter called “callback” that allows GeoPlanet to return JSON data wrapped in a JavaScript function call (aka JSONP), so you can more easily process the GeoPlanet response within a JavaScript application and avoid cross-site serving issues.

Second, we added support for a new response format called GeoJSON. This is an evolving standard for adding geographic content to JSON.

Third, we added a new filter for the /places collection called “$and”. This filter allows you to apply two other filters (such as .q and .type) to the same request. This means that you can now limit results to just the place types you are interested in. The syntax for filters may seem strange, but it offers a lot of functionality.

Fourth, we added a /placetype resource that allows you to get information about a place type. This is handy if you want to find the name and/or description (see the next item) for a single place type.

Last, we added support for a long representation for the /placetype resource (and /placetypes collection) that includes a one line description of the place type. This is handy if you want a better understanding of a place type.

More detailed information about these new features is available in the GeoPlanet documentation, and examples are available on our GeoPlanet General Discussion Forum.

We also fixed several bugs reported by our developer community. We continue to view GeoPlanet as an evolving product, so let us know how we can make it better! Post a message to one of our GeoPlanet developer forums and tell us what you think.

Eddie Babcock, Principal Engineer, Yahoo! Geo Technologies

It’s clear that the individual charged with illustrating the pamphlet searched for ‘Birmingham’, found what looked like a nice skyline, and failed to fact-check. It is also possible that this individual never realized that there are multiple towns called ‘Birmingham’ (eighteen, actually). Whatever the cause, the story highlights some fundamental-but-oft-overlooked challenges in geoparsing that we embrace at Yahoo! Geo Technologies.

Geoparsing is of course the process of identifying places referenced in free- or unstructured text, and is the essential ingredient of any system where we want to geolocate content with machine analysis. The two steps of successful geoparsing are (1) token identification, and (2) geographic disambiguation. Let’s take a look at each briefly:

The first step in geoparsing is token identification: identifying place-names, such as ‘Wayne’ or ‘The Bay Area’, in unstructured content like newspaper articles or web pages, while ensuring at the same time that one does not falsely identify terms like ‘New England Clam Chowder’ as a place (a post on our fun with these potential false-positives will follow).

But token identification is the easy half of the battle; many entity-recognition applications, like the otherwise excellent OpenCalais are not capable of geotagging the above BBC article on ‘Birmingham’, for example, as it — correctly — identifies seven ‘Birminghams’, but does not tell us whether those referred to within are the UK city, one of its seventeen US namesakes, or a mix of both. (You can try this yourself with any text using the Calais Viewer.) Human cognition can certainly determine this with a quick read-through, but we’re looking at machine parsing specifically here.

To do this properly, we first require the means to refer to a place in a permanent, unambiguous, and machine-friendly manner: usually this is attempted by expanding the geographic context so that the token ‘Wayne’, when found in text, can be indexed as ‘Wayne, PA, USA’; this works sometimes but is hardly machine-friendly. (Furthermore, there are ten towns called ‘Wayne’ in Pennsylvania, so the above string gets us no closer to our goal.) In truth, string-based indexing will always have its exceptions, so we have opened GeoPlanet, our gazetteer of places and their unique Where-on-Earth Identifiers (WOEIDs), to provide the vocabulary to describe the world’s places without ambiguity.

So, now that we’ve found the correct tokens (’Wayne’) in our hypothetical text, and dismissed misleading, place-sounding terms (’Yorkshire Pudding’), we then determine which place, of all the places with that name, is specifically being referenced. This is geographic disambiguation (or geodisambiguation for the portmanteau-inclined). Let’s take for example ‘Rome’, of which there are over thirty: there is of course ‘the’ Rome, in Italy (WOEID: 721943), and for many of us, this is the only Rome we know. However, residents of Rome, Georgia (WOEID: 2484261) would argue otherwise. This highlights the problem: how can we be certain which place is being referenced when we have only ‘Rome’ in the text? Obviously the language helps in some instances, as does context (is ‘Georgia’ or ‘Italy’ mentioned elsewhere in the document?). But when geodisambiguating at Yahoo! (and this is the fun bit), we take into account the location of the user (or publisher) to capture the ‘locality’ of the term, and really put geography in the first-person. For example, although ‘Rome’ by itself will usually refer to ‘Rome, Italy’, the probability of its referring to ‘Rome, Georgia’ increases as we move geographically towards the latter. This approach ensures that Yahoo! returns the ‘correct’ city when a search for ‘Birmingham’ is performed in the UK, compared to the same search in the US. This approach ensures that content originating from Rome, Georgia will be geoparsed and disambiguated correctly to the correct and local ‘Rome’.

Acknowledging that geography is in the eye of the beholder is just one way that Yahoo! Geo Technologies provides our users with the most personally georelevant results. Shame Birmingham Council did not come to us first.

Tyler Bell, Advanced Products Manager, Yahoo! Geo Technologies

I’ve been a huge fan of Fire Eagle since its inception — as a business driver it was conceived to slice horizontally through the vertical towers that now dominate the Location Based Services landscape. Its launch not only returns ownership of User Location to the hands of the user, but undoubtedly triggers the tearing out of hair and significant re-writing of business plans; this can only be good — opening user location ensures that new businesses are built on the opportunities this affords, and not on the ‘captive audience, closed service’ concepts that currently dominate.

The product ethos is focused wholly on protecting user privacy while exposing the power of location; this is what really is most impressive. While developers usually tout the ‘heavy lifting’ that Fire Eagle does to make geolocation appear easy (more on this below), I would suggest that Fire Eagle’s greatest success is the care and attention evident in the product to ensure that users have complete control over who has access to their location, and at what granularity this is exposed. Far from shying away from the complex and at times intractably confused technical and policy issues surrounding user location, privacy, and geolocation, the Fire Eagle Team has carefully met them head-on and delivered a well-conceived, innovative, and enabling technology. This is delicate ground, certainly, and each subsequent step must be taken with similar diligence, but I am very excited to see what new ideas, products, and businesses emerge from Open User Location.

I am, of course, hardly an unbiased observer: the Yahoo! Geo Technologies team provides the machinery that performs the aforementioned ‘heavy lifting’. Our tech helps Fire Eagle determine where on earth its users are, assists with its geographic granularity protection, and ensures that developers can integrate the geographic data returned by Fire Eagle with other systems via ‘where on earth’ IDs (WOEIDs) and our GeoPlanet Web service. In a similar manner we also power the geoinformatics underlying Flickr’s new geotagging service. Combined with the significant geo wizardry and craft of the Fire Eagle, Flickr, and other teams at Yahoo!, we are continuing to provide the tools and platforms to spatially enable the Web and provide our users with the most personally georelevant experience possible.

Tyler Bell, Advanced Products Manager, Yahoo! Geo Technologies

You’ll find forum categories for requesting enhancements, showcasing applications or demos which make use of GeoPlanet, requests for using GeoPlanet in a commercial environment and general discussions, conversations and Geo related chat.

Members of the Yahoo! Geo Technologies group will be on the forums and we look forward to meeting and chatting with you all there.

You can find out more by pointing your browsers to the Yahoo! Developer Network GeoPlanet forums at http://developer.yahoo.net/forum/index.php?showforum=31 now.

Cheers,

Gary Gale, Head of UK Engineering, Yahoo! Geo Technologies

These past few months we’ve focused on improving the usability of Yahoo! Maps, and some of the modifications we encourage you to try include:

• Improved Local Search integration that utilizes the Search/Direct Display Index
• More user-friendly Driving Directions - a more user-friendly left rail that’s both wider and more legible (larger text), for easier reading of driving directions
• A redesigned Print Page
• The ability to minimize multiple driving direction instructions to save vertical space
• The ability to display inline turn-by-turn images for each driving direction segment
• An Interactive Print Page Map
• Users can now select from a variety map views (full route, full route + finish, full route + start + finish)
• Drag/Pan/zoom functionality for print page maps
• Interactivity between Points of Interest (POIs) and Map view; minimized POIs are removed from the map view
• Improved POIs - with ability to minimize/collapse multiple POIS to maximize viewing area

Stay tuned for updates and improvements throughout 2008, as Yahoo! Geo Technologies continues bringing the world to your fingertips!

Cheers,

Gus Maldonado, Sr. Product Manager, Yahoo! Geo Technologies

At Yahoo! we’ve been using geo technologies to ensure that our half-a-billion users globally receive the most geographically relevant information possible. As part of the Y! OS initiative, we are making these geo developer tools accessible to all, and writing about it here.

Here you will learn about Yahoo!’s products, tools, and resources that help bridge the disconnect between the Real World and the Internet, including coverage of Yahoo! Maps, our geolocation and geoinformatic initiatives, user location services, and all clever uses of geo technology at Yahoo!

We’re therefore taking the opportunity to proudly announce that today we are launching Yahoo! GeoPlanet™, an open, permanent and intelligent infrastructure for geo-referencing data on the Internet. (You may have seen this previewed as the Internet Location Platform at Where 2.0 in Burlingame, CA earlier this year.)

Our two driving principles in creating GeoPlanet are to be as comprehensive as possible (we continue to add thousands of places daily) and to ensure that we capture the geography of the Earth as it is called by the world’s people. Within the collection of over six million named places we include (big breath): Continents, Countries, Counties, States, Provinces, Prefectures, Country, Regions, Federal Districts, MSAs, Provinces, Parishes, Departments, Districts, Communes, Municipalities, Districts, Wards, Cities, Towns, Villages, Hamlets, Postcodes, ‘Supernames’ (USSR, Western Europe, Latin America), Time Zones, Points of Interest, and Colloquial Names (such as Wine Country, the French Riviera, South East England, SOMA, and the Pacific States). Phew.

What’s more, we’ve attempted to solve one of the real bugbears of geographic indexing: how do you uniquely identify places in a uniform and consistent manner? We’re talking geotagging here: string matching won’t always help (there are over 100 Springfields) and providing a string geographic context will not always work (there is more than one Wayne, PA, USA for example). Lat/Long is of course the obvious choice, and this is perfect for geotagging (say) photos that were taken at a single point on the earth’s surface. The coordinate-based approach however can fall down when we want to associate a unit of information with an area – such as a country, region, or neighborhood – because we usually do not know the exact point within that area that the contents of, for example, a newspaper article refers to.

This question therefore is how do we associate the spatial and political entity with a news article or other information about that place? We can geotag a newspaper article about Afghanistan with its centroid, but this associates the article with a point on the earth’s surface – we don’t know which intersecting place it specifically relates to: Afghanistan, Kandahar, or a specific neighborhood of Kandahar itself. We can of course represent the place by a polygon, but this becomes hugely cumbersome. More critically, it becomes difficult to match with articles geotagged in the same manner. For different systems to geotag two different articles about Afghanistan, they would need to employ identical coordinate pairs to represent that place – just one pair amiss and the systems are geotagging two different areas. We know that this can be determined though various spatial functions here — our point is that we should not need to; fundamentally, coordinate pairs are best employed to describe Space, not Place.

What we still require in this scenario is the ability to geotag an information unit with a unique identifier for a place, so that the information is associated with a Place – or in a quantum-like manner, associated with all points in that place at the same time. Yahoo! provides what we believe is the solution with WOEIDs, Where On Earth IDs, unique identifiers for every named place in GeoPlanet. When you tag a unit of information with a WOEID, it associates that information with the concept of that place, not with a spatial approximation of the place itself. This is actually much more appropriate — our concern is to provide a common naming convention, and to ensure that places are correctly represented in relation to each other in a global, consistent framework. In practice this means that we are not in a position to claim that a particular neighborhood stops at one block and starts at the next, only that the concept of that neighborhood be identified consistently. Our primary concerns are relative geography and the semantics of place.

Lastly, because we conceive of the idea of a place as being conceptually distinct from how it is called, we can ensure that multiple names for the same place are managed consistently. For example, München in Germany is Munich to the English speaking world and Monaco di Bavaria to the Italians. But it may also be keyed as Muenchen and Munchen if special characters, diacritic marks, and ligatures are not available to the user. All of these spatial appellations are simply multiple names for the same place, and therefore reside within GeoPlanet mapped to the same WOEID (676757).

We are delighted to present GeoPlanet to the Geographic Developer Community and look forward to posting further news and musing on Yahoo! Geo Technologies here shortly. There’s much to talk about.

The Yahoo! Geo Technologies Group