[OSM-dev] Suggestion about design of OSM data structure (take out segment component)

[Iván Sánchez Ortega]

El Thursday 26 July 2007 18:22:47 Chien Nguyen Khac escribió:
>   Without segments, I still can use simple way to model area with hole.
>   For example: I have 11 nodes. Node: 1, 2, 3, 4, 10, 11 form the outer
> ring clockwise and nodes: 5, 6, 7, 8, 9 form inner ring anticlockwise. Two
> rings joined at node 4 and 5.
>
>   So, to model the above area with hole, I can use simple way like this (1,
> 2, 3, 4, 5, 6, 7, 8, 9, 5, 4, 10, 11)

Looks way too hack-ish to me. And, you are wasting a little bit of space 
duplicating info about nodes 4 and 5.

>   If we can implement data structure like this:
>   nodes (id, lat, lon, tag)
> ways (id, nodeid[0],nodeid[1],...,nodeid[n], tag)
>
>   Then we can save a lot of space in planet.osm xml file and other program
> will process osm data more easily (trim, convert...)

I'll be doing a quick proposal, based on having read a couple of times the 
(hideous) OGC specs:

node = (lat, lon)
string = (nodeid[0], nodeid[1], nodeid[2], ... )
poly = (stringid[0], stringid[1], ...)

So:
Nodes are still nodes,
A string is the same as a "simple way" right now,
A poly is either a polystring (a "complex way" with branches, or the 
dubbed "superway") or a polygon (the first string being the outer hull, any 
others being the inner hulls)

Checking for areas (closed rings) would be fairly easy: the first node id is 
the same as the last one. And the polygon model should be fairly good.

Simple editors (e.g. potlach) should not worry about polys, to keeps things 
even simpler, and complex ones should ("want to create an area? learn to use 
JOSM"), as well as cleaning-up tools.


Should this solve everyone's problems?


Cheers,
-- 
Iván Sánchez Ortega <ivansanchez at escomposlinux.org>