[OSM-dev] Essen / data model paper

[Robert (Jamie) Munro]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Frederik Ramm wrote:
> Hi,
> 
>     Jochen and I have prepared a paper containing some ideas for a  
> new OSM data model. The paper is still very fuzzy on details and will  
> need a lot of work, but we're hoping to discuss some of the technical  
> aspects at the Essen workshop and determine whether the ideas are  
> sound and worth pursuing, or whether it is just a waste of time.
> 
> Those of you coming to Essen and interested in the topic: it'd be  
> great if you get to read it before we meet.
> 
> Those of you not coming to Essen but still interested: We are happy  
> about any comments and feedback. Feel free to read the paper and send  
> feedback (preferably off-list, we'll summarize), but you can also  
> wait for the results of the Essen workshop - if we don't collectively  
> kill off the idea there, there will be more mature documents to read  
> in the weeks after.
> 
> The paper is available as a PDF file:
> http://www.remote.org/frederik/tmp/towards-a-new-data-model-for-osm.pdf

I've finally got around to reading this. A couple of points from reading it:

3.1.5 "2 kinds of point ... One kind is the point which is of interest
in and of itself, say the location of a phone booth or the location of a
junction where several roads meet. Often this is called a Point of
Interest (POI). "

I'd say that a junction is different to a POI. An POI is a temporary way
to place something you can't be bothered to measure accurately enough
and put as a small shape. In theory it should be replaced with a shape
when we add more detail - i.e. a building or a telephone box. Road
junctions are different - they are topological connections between
roads. They don't have shape of their own then are just formed by the
intersection of their constituent roads.

Rail stations are an interesting case of being both - it is a logical
connection in a railway (and possibly a road/path network for modeling a
route like walk to the station, catch the train), and it is a building
that has a shape.



3.3.2 "Think of a bunch of roads that meet at a plaza". As we get better
and better detail, I think the topology in this case needs to be
extremely high resolution. We need to tell people which lane they should
be in on the plaza. I'm thinking about places like Marble Arch, Arc de
Triumph, Hyde Park Corner or Piccadilly circus.



More generally, while I like a lot of the ideas, and think we should be
moving in that direction, I do believe that this structure is much too
complicated. What I know from databases I have done before is that if a
database gets this complicated, it never works. The amount of work it
will take to just implement is huge. Then you've got to make something
that can download and edit it. It's a useful exercise to dream of the
ultimate data model, but we have to figure out ways to get there in
stages. I don't believe it can be done in on go. For example, we should
enforce key names & tag values where appropriate. Make list fairly easy
to edit, but a two stage process - create a new key (or value for a
restricted key) with a description (perhaps by making a special wiki
page), then the backend should strictly enforce it. The next thing is to
make some way to tag the relationship between ways, or possibly a way
and a node. Maybe throw in ways-ways as well, and we have a link
anything to anything superway, supernode grouping system.

Robert (Jamie) Munro
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGN86Gz+aYVHdncI0RAsyyAJ9M0jEeg1jyfksoKIR+0DSFBdUVJgCgi9Vb
OjGwsweKRY9W1YbNXn5GMaQ=
=J2SK
-----END PGP SIGNATURE-----