[OSM-talk] Fwd: Superways again

Nigel Magnay nigel.magnay at gmail.com
Fri Mar 16 16:46:39 GMT 2007


---------- Forwarded message ----------
From: Nigel Magnay <nigel.magnay at gmail.com>
Date: 16-Mar-2007 16:46
Subject: Re: [OSM-talk] Superways again
To: David Earl <david at frankieandshadow.com>

If you just store ways, and ways are a collection of {node|way}, then you
can easily convert that to ways+segments for outputting to 'old style'
renderers.

Round-tripping to older editors is probably also possible by using
additional tags on the nodes ( I.E a tag that says "actually, this segment
is "really" part of way id 12).

Needs a bit of thought, but I feel pretty sure it could be done whilst the
editors caught up (and that said, the pace of these things is that I'm sure
by the time the bugs in the newer implementation for the server were ironed
out, the editors would have had more than enough time to update).

On 16/03/07, David Earl <david at frankieandshadow.com> wrote:
>
> In view of the discussion on tagging junctions, I thought I'd raise this
> old
> chestnut again under a separate thread.
>
> There have been a number of discussions around abandoning segments
> completely, arguing that ways would become simply a linear chain of nodes.
>
> While I think most people agree there is merit in this, it has the
> enormous
> disadvantage that it requires pretty much everything (editors, renderers,
> utilities, ...) to be rewritten to accommodate such a change. Some of us
> talked about it in passing in Oxford a couple of weeks ago. I think making
> 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.
>
> Reiterating some of what's gone before:
>
> There are then lots of advantages to grouping such ways.
>
> * If you break a Way at a bridge, you can group the three Ways (either
> side
> and the bridge itself) so their commonality (it's the same road) can be
> represented (and so on along the road).
>
> * An estate road with many branches can be represented as a whole.
>
> * If you want to represent a bus route, the route tag in theory allows
> this,
> but in practice you can't put more than one route on the same Way, so it
> can't also be a different bus route or a cycle network route, and the
> route
> isn't coherent in any useful way - you have to search for where it goes
> next. So grouping ways to represent the concept of route would be helpful.
> Note this means ways can belong to more than one superway.
>
> * A non-roundabout and non-node junction could be represented (together
> with
> its name or number) as a bag of ways (consider a grade separated single
> carriageway with four slip roads, or a cloverleaf).
>
> At the same time, we need the database api and ideally editors to enforce
> (and naturally create without bothering the user) the stricter definition
> of
> a Way, and prevent (all? some?) tags being put on segments. Ideally
> editors
> would also suppress the visibility of segments to the user, even though
> they
> are there underneath, as they are just 'glue' to hold the ways to the
> nodes.
>
> Not much new in this message, but I want to light the match again.
>
> David
>
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20070316/f9deb6da/attachment.html>


More information about the talk mailing list