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