On Tue, Oct 6, 2009 at 8:46 AM, Frederik Ramm <frede...@remote.org> wrote:

> I fear that if many people treat OSM IDs as permanent, this will have a
> restraining influence on us editing our own data ("I wanted to replace
> this restaurant node by a building outline for the restaurant but then I
> got complaints from users of 15 restaurant guides and Flickr because the
> restaurant had suddenly vanished there, and so I reverted my edit").

Any time I discuss this, I always refer to Wikitravel Press. Now that
I've put the video online, everyone who wasn't at SOTM08 can also see
what Jani had to say on this topic. See http://vimeo.com/6847540 , and
(if you want to lose all context) skip to 6:00. For those of you who
don't want to watch the video or can't, they use the name and
approximate location to match things like restaurants and hotels
between wikitravel and OSM. There's no OSM information in wikitravel
or wikitravel links in OSM.

> If we really want to head in a direction where external users refer to
> OSM objects, then I think it would be wise to manifest that in the
> database somehow, and create some kind of "permanence API" or so, where
> you can request a permanent handle for a certain object from the API,
> and the API will give you a number, and then if someone deletes and
> re-creates an object they will be able to transfer that number to the
> new object somehow.

I'm a fan of the fuzzy matching that Wikitravel Press are using, for
two main reasons - it works in theory, and it works in practise too.
Most importantly - neither project knows what the primary key of the
other is, and that makes everything more robust.

I think your permanence API has the hallmarks of WOEID (Gary Gale's
talk from SOTM08 isn't online, but will be in the next few weeks),
just expanded to a much more granular level. But in my eyes, the best
link between two datasets (e.g. wikitravel and OSM) is using the
"facts" as the foreign key (the name, the place etc) rather than
worrying about the "fiction" (IDs).

> This is of course something for the future, but letting external users
> refer directly to OSM IDs sounds like asking for trouble to me.

Indeed. The primary key of any database should be only relied on
internally to that database.

Cheers,
Andy

_______________________________________________
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Reply via email to