Geonames and Yahoo's WoE ("Where On Earth")

[n[ate]vw]

Probably isn't news to most of you, but Yahoo! has opened a new API
that (as far as I can tell) is pretty much just a proprietary
replacement for what geonames.org is doing (see
http://developer.yahoo.com/geo/,http://radar.oreilly.com/archives/2008/05/yahoo-internet-location-platfo.html).

I see no advantage to the WoE platform, and being able to download and
use the entire user-updatable database under CC-BY is a HUGE advantage
as far as I'm concerned. But Yahoo's focus seems to be to turn THEIR
id's into The Standard, and with established services like Flickr and
upcoming ones like FireEagle, they may be able to pull it off. In
light of the Microsoft debacle, I'm sort of happy for Yahoo, but as a
software developer I would much prefer to stick with open standards
rather than locking myself into a big corporation, much less one that
recently found itself a gaggle of investors who root for things like
hostile takeovers.

Long story short, I'm wondering two things:

1. Yahoo guarantees that their identifiers will always remain valid,
being remapped if necessary to a replacement or parent feature. Does
geonames have a policy for _permanent_ identification numbers?

2. Database/factual intellectual property law is a pretty hairy thing,
but I'm wondering if geonames.org could map between WoE ids and
Geoname ids. This could involve legal, graph-theoretical and technical
problems, but seems worth tackling. What do you think?

thanks,
-natevw
http://calftrail.com/

[Marc Wick]

Hi Nate

Did you find any information about the license of the data? I couldn't.

1. The GeoNameId is implemented as a database sequence and geoNameIds
will not be reused even if a record is deleted.We are aware that there
is a potential problem with deleting and reinserting the same record
with a different geonameid. This is the reason it needs more rights to
delete a record on the GeoName wiki interface. We want to make sure
inexperienced users don't accidentally delete records. My impression is
that this is not a serious problem so far. To deal further with it, we
keep the history of the records and could implement a redirection for
deleted records to the replacing record if we see that there is need for
it. What sometimes happens is that we (geoname users) discover
duplicates and delete them. Up to now it happens rarely. In this case we
write the geonameId of the record we keep in the comments of the deleted
record. It would be nice to have a more formal log and handling of the
process for duplicate elimination. As for the 'guarantee' of a
'permanent' id by yahoo. It is kind of funny to be claimed by a company
whose days are obviously numbered ;-)

2. Technically it should certainly be possible to map a great number of
ids and I don't think it would be a legal problem to store the ids. What
is more interesting, however, is the question of what are we allowed to
do with the data itself (lat/lng, polygons, i18n, admin division, etc).
As I said I could only find some very generic terms of use and this
could mean that we are not allowed to use the data for anything real.
Otherwise, with a liberal license, it could become an interesting
additional source of data for the GeoNames project.

Marc

[edb]

Yahoo!'s terms of service for GeoPlanet (the name for the new API) are
spelled out at http://info.yahoo.com/legal/us/yahoo/api/api-2140.html.
You can decide whether they are liberal or conservative.

Eddie

> >http://developer.yahoo.com/geo/,http://radar.oreilly.com/archives/200...).

[SteveK]

I'm currently working on an API to merge both WoE id's and geonameID.
The problems that I'm currently facing is the fact that both Yahoo!
and Geonames store different lat/lng co-ordinates for places. Example:
querying for "Vancouver" will result in the following:

GeoNames
---------------
Lat: 49.249657393
Lng: -123.119340403
GID: 6173331

Geo Planet
----------------
Lat: 49.260448
Lng: -123.113937
WoEID: 9807

The following could be done:
1) After finding the lat/lng from Geo Planet, query multiple results
on GeoNames and find the closest point in proximity.
2) Round up to the nearest decimal place and select whichever one is
closest.
3) create an average between the 2 points and provide an additional
lat/lng.

I haven't had any problems by doing it like #2 but it seems like
voodoo when trying to find smaller towns or cities. Any other
suggestions on how to make this more accurate? Is it possible to query
geonames with lat/lng co-ordinates and have it return the geonameid?
(my initial research into the geonames api told me I couldn't :( )

On May 13, 11:09 am, "n[ate]vw" <nat...@gmail.com> wrote:
> Probably isn't news to most of you, but Yahoo! has opened a new API
> that (as far as I can tell) is pretty much just a proprietary

> replacement for what geonames.org is doing (seehttp://developer.yahoo.com/geo/,http://radar.oreilly.com/archives/200...).

[Marc Wick]

Hi Steve

Finding a place with given lat/lng coordinates is called 'reverse
geocoding'. GeoNames has some reverse geocoding services:
http://www.geonames.org/export/web-services.html#findNearbyPlaceName

The closest point will not be enough to match GeoNames toponyms with
Yahoo toponyms. You will also have to compare feature codes and name
similarity. For name similarity I normally use a combination of
Levenshtein distance (edit distance) and letter-pair similarity.

Best

Marc