[OSM-talk] Id stability

[straup]

For what it's worth Flickr often had a similar conversation with the 
Y!Geo / WOE kids, especially in the early days when we were just getting 
to know one another.

The short version is that we were simply not going to use their IDs if 
they couldn't guarantee that they has some measure of permanence and 
reliability. We were not in a position (time or technology-wise) to run 
a full geo-stack so we needed to use those IDs as bridges back to the 
details.

Once we all agreed on that the next question became what constituted a 
significant change in the meaning of an ID. For example, some WOE IDs 
would be updated to fix a typo in the name but others would change place 
type (a "neighbourhood" might become an "historical town") which was ... 
always an issue.

Our suggestion was that WOE start to include a pair of properties with 
each record: "supersedes" and "superseded_by". These were simply meant 
to be pointers to and from other WOE ID and was predicated on the 
assumption that numbers (especially 64-bit ints) are cheap. We were fine 
with needing to do the work to pay attention to the fact that something 
had been updated and follow the breadcrumbs accordingly.

Sadly, it never happened.

The corollary to this idea are start/end dates which Frankie Roberto 
touched on at SOTM 2009. [1] Also a good thing but since this is a 
thread about UIDs I'll just set that aside for now :-)

I'm not going to pretend to understand the guts of the OSM code well 
enough to suggest that supersedes/superseded_by would be easy to 
implement or not but it's always seemed like a useful approach to me.

Cheers,

--

[1] http://www.vimeo.com/5843154


On 8/2/11 7:55 AM, Ture Pålsson wrote:
> 2011/8/2 Gregor Horvath<gregor at ediwo.com>:
>
>> OSM provides uri's to ID's which are linked to names of
>> physical objects. Example:
>>
>> http://www.openstreetmap.org/browse/node/1381574156
>
> But these objects often make no sense in the real world!
>
> In the real world, there are things like streets, pubs, counties and
> hospitals, which have geometry (and other properties). In the OSM
> database, in contrast, there are pieces of geometry, subdivided
> according to topology into points (nodes), linestrings (ways), and
> everything else (relations), which have "thingyness". The relation
> between OSM objects and real-world objects is quite hairy and probably
> depends on what sort of real-world object you are intrested in at the
> moment (is a hospital a place to get yourself stitched back together
> after falling of the bike while mapping, or a contender for "largest
> building in a 5km radius from home"?).
>
> I am beginning to suspect that the only sensible use for the OSM
> database, is as input data to a processing step that converts it to
> something more usable for a specific task. Using it "as is" is a
> recipe for headaches.
>
> I'm not saying this is a bad thing. The database is extremely flexible
> and can accommodate almost any sort of geographic information one
> cares to throw at it, it just takes some programming to use it!
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>