[OSM-dev] [+1] OSM IDs as foreign keys

[Chris Hill]

Frederik Ramm wrote:
> Hi,
>
> (for those on dev; this started out as a discussion on whether or not we 
> want to put any legal/license restrictions on external users linking to 
> OSM objects for identification, e.g. a restaurant guide saying "this pub 
> is OSM node #12345")
>
> Matt Amos wrote:
>   
>> i would hope so too, as it makes OSM data more attractive for those
>> users who don't need to manipulate the data, but need to annotate it
>> or reference it. i, for one, would really like to see the next
>> beerintheevening or tripadvisor based on OSM data, not just the tiles.
>>     
>
> My problem with this is that while I'd gladly allow anybody to do that 
> from a licensing point of view, I'd rather not have people do that from 
> a technical point of view (and that's why I'm switching over to dev with 
> this).
>
> Personally I view OSM object IDs as quite frail, and subject to change 
> without notice at any time. I do not think that OSM object IDs should be 
> used as foreign keys in any application. I even object to all those 
> lists on the Wiki which point to hard-coded relation IDs - I, for one, 
> will delete and re-create an object any time without much thought if it 
> makes sense to me, breaking any such external entry point.
>
> 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").
>
> Until now, if someone asked me a question in that direction, I always 
> said they should make their own ID a foreign key and tag the OSM object 
> with something like "restaurant_guide_xyz_id:1234". Which is not ideal 
> from a data access perspective of course, but allows people editing OSM 
> to properly work with that.
>
> 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.
>
> This is of course something for the future, but letting external users 
> refer directly to OSM IDs sounds like asking for trouble to me.
>
> Bye
> Frederik
>   
+1