[OSM-talk] The segments vs ways vs superways question, again...

[Ed Davies]

Nick Whitelegg wrote:

> With the emergence of utilities to convert OSM data to .img and shapefile 
> format, I think now would be a good time to raise this question again, as
> both .img and shapefile are polyline-orientated formats, with no notion of 
> a segment. The presence of misordered ways 

The use of the word "misordered" here is a bit provocative - ways are
currently defined to be sets of segments with no defined order so
"unordered" would be a bit more accurate.

> and branched roads represented 
> by a single way in the OSM database causes big problems here: problems that 
> could be sorted by less than ideal work arounds (one polyline for one segment, 

One polyline per segment would be a bit silly.

> or programmatically re-ordering or splitting the way - a complex task I 
> suspect), 

I don't see why this needs to be complex.  For unordered linear
features all you have to do is match up nodes at the ends of segments.
Where there are branches things are a little more complicated but
I'd imagine that some simple heuristics would get you most of the
way.  E.g., Split into connected sub-graphs, find the longest path
through the each graph and take that as the "main" line then treat
all connected graphs of what's left recursively in the same way.  Or
maybe find the furthest apart connected nodes and take the shortest
path between them as a main line.

> but maybe best avoided in the first place by strongly recommending 
> a certain structure in the data model.

> There doesn't really seem to be much need for the concept of a segment in 
> OSM, the node/way/superway data model (superways being used, for example, 
> to cope with tree-like branched roads such as those found in housing 
> estates - each branch being a way) 

The node/way/superway model is a reasonable alternative to the node/
segment/way model.  However, it presumes a lot more - in particular,
that the nodes in the way are ordered.  The current model does not have
that ordering restriction so segments are required to indicate how the
nodes are connected.

> being a model which could cope with 
> every use case for the data that I can think of (even a node/way model 
> could be used if people were happy representing branched roads as several 
> ways with no entity for the whole road). However it would obviously be a
> major and probably impractical upheaval to do this, maybe doable in the 
> future if there was a lot of spare time to work on it.

> A better solution in the interim perhaps would be to provide strong 
> recommendations on the storage of ways - 

I worry about "strong recommendations".  Something should be either
right or wrong.  The best that "strong recommendation" could really
mean is that out-of-order or branched ways are OK but will look
horrible in some renderers.  This is just the sort of thing which
will trap and disappoint new users.

> for example, make sure that 
> ways comprise segments all aligned in the same direction 

What about parts of roads which are one-way in one direction in one
part and the other direction in another part?

> and logical 
> order, and, for branched streets, have one way per branch. This may 
> require a little more effort editing, 

More effort editing, especially if it comes without support or
guidance from the editors seems like a really bad idea to me.

> e.g. when adding new segments to 
> an existing way, make sure they are aligned in the same direction as the 
> current way, and follow on in logical order. Maybe adding numerical segment 
> indices (within the parent way) in JOSM would help here - then people 
> would know which end to extend the way so that the segments follow on 
> in logical order.

> Any thoughts on this?

1) Way sanitizer

Maybe there could be a handy "way sanitizer" that implements the
sort of heuristics I mentioned above which renderers and converters
could use with extracted .osm files before they start their main
operation.

Output would be identical to the input except that some of the ways
might be split into multiple ways and the segments within ways might
be reordered.  To node of one segment might not match the from node
of the the next as some segments might still be "back-to-front" but
that's fairly easy for a renderer to deal with.

2) Superways vs entities

A superway would be a collection of ways.  Could the be any use
generalizing this idea to have "entities" (he says, desperately
groping for a suitable word) which are arbitrary collections of
OSM objects (nodes, ways, other entities)?  E.g., a trading
estate including the area boundary, roads, and so on.  Then a
town, including the roads, residential areas, trading estates,
pubs, whatever.

Ed.