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<gre...@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@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
_______________________________________________
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
