[OSM-dev] Idea about ways / meta-ways

matthew-osm at newtoncomputing.co.uk matthew-osm at newtoncomputing.co.uk
Tue Nov 28 00:22:50 GMT 2006


Hi,

I've been thinking this through for a few days now with nothing else to do being
ill, and it seems sensible to me, so I'll hand it over for you all to tear apart
;-) [I've done graph theory, apologies if I use terms that are not normal
English usage!]

We currently have:

  node - lat/lon position
  segment - directed edge between two nodes
  way - ordered list of segments

There seems to have been a bit of discussion every now and then about scrapping
segments, making a way a list of nodes, and then possibly creating a "meta-way"
(or whatever) that is a group of ways. This would be

  node - lat/lon position
  way - ordered list of nodes (a path)
  metaway - un(?)ordered list of ways (possibly disconnected graph)

I like the this idea a lot from the map-side of things, but have some serious
problems with getting to this state. There are some non-trivial issues with
breaking up an existing way in the database (which could be a tree, or even
contain cycles) into a set of new ways. To keep this mail short (a first for
me), I'll skip this for now.

I propose, therefore, the following "simple" change. I say simple... the
database schema alteration would need a bit of thought, but I don't currently
know anything about that side of things. Sorry if I'm trivialising lots of
complicated work.

  node - lat/lon position
  segment - ordered list of nodes (a directed path)
  way - ordered list of segments

The existing data can stay exactly as is (in the altered schema) - each existing
segment can stay the same - it is a path of length 1. Each existing way can stay
the same, too. I'd probably call segments "paths", and ways "groups", or
similar.

The final move is then to alter user tools such as JOSM to be able to first
handle "new segments" with more than two nodes, and then to add tools to make it
easy to manually convert the segments in an existing way into a new type of
segment. Scripts should be able to automate some of this, but the whole process
is overseen by humans, rather than an automated process that has to make some
difficult decisions about how to split ways, and may get it wrong. Users that do
not want to use the new paths don't have to - they can continue to work as they
are if they wish.

Finally, some data could be moved back to the new paths. A simple road would be
a path, no need for a group there. Complex roads (i.e. branches off) would be a
group of paths, with tags on the group. This also legitimises the current
"bridge=yes" case, where all the tags are on the way, but a single hard to see
segment has the bridge tag.

I would alter the way tool in <insert favourite editor here> to become a "group"
tool that lists the paths in a box, rather than necessarily highlighting them
all the time, I think.  This should make it much easier to add tags to paths,
and then to view all paths in a group. Currently (in JOSM at least) it is quite
difficult to see segment tags when part of a way.

Comments?

Thanks!

-- 
Matthew





More information about the dev mailing list