[OSM-talk] Superways again
aledmorris2 at gmail.com
Fri Mar 16 19:13:37 GMT 2007
I was thinking this exact same thing... all that needs to be done is to add
shapepoints to segments. Then explicitly allow ways to contain segments with
loops, spurs etc.
Surely what the renderers can or can't currently cope with should not affect
development of the underlying data model - in fact would it be better to
have some kind of abstraction layer between the raw data and the renderer,
because an exact representation of the data is usually the wrong thing to
do. (For example, rendering roundabouts as small solid circles, moving roads
apart so they do not overlap in the rendering, showing dual carriageways as
a single line, etc)
On 3/16/07, matthew-osm at newtoncomputing.co.uk <
matthew-osm at newtoncomputing.co.uk> wrote:
> On Fri, Mar 16, 2007 at 04:31:59PM -0000, David Earl wrote:
> > talked about it in passing in Oxford a couple of weeks ago. I think
> > this change this would be unproductive.
> > However, the concept of adding a higher level structure on top of ways
> is, I
> > think, still desirable; at the same time requiring that Ways are what we
> > all, I think, now believe they should be and do conventionally, i.e.
> > contiguous, ordered, unidirectional, non-branching sets of segments.
> I suggested to the list a while ago the following plan that would not
> all editors to be immediately updated. The idea is to extend segments to
> paths. This means that an existing editor will not break until a segment
> with >2
> nodes is downloaded. A way then becomes the "superway" or "group".
> Node stays as node
> Segment becomes an ordered list of two or more nodes
> Way stays as an unordered collection of segments (now paths).
> Then, push data from ways back down on to the "segments" again. This can
> automated (in fact, I've just written a ruby script that pretty much does
> that -
> ways are fairly useless in their current form of not being paths, so it
> the data to the segments and then builds paths up from them).
> I think this is the simplest method of updating, without breaking lots of
> existing stuff.
> > There are then lots of advantages to grouping such ways.
> > Not much new in this message, but I want to light the match again.
> Totally agree. I also appreciate that it is not an easy thing to be done
> quickly, so accept that it may take a while to actually happen.
> talk mailing list
> talk at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the talk