[OSM-dev] ways with 'spurs'

80n 80n80n at gmail.com
Mon Feb 26 15:43:40 GMT 2007


On 2/26/07, Barry Crabtree <barry.crabtree at gmail.com> wrote:
>
>
> On 2/26/07, Nick Whitelegg <Nick.Whitelegg at solent.ac.uk> wrote:
> > Sent by:        dev-bounces at openstreetmap.org
> > To:     dev at openstreetmap.org
> > cc:
> > Subject:        [OSM-dev] ways with 'spurs'
> >
> > >I've come across some ways that go:
> >
> > >   A -> B -> C -> B -> D
> >
> > >Shouldn't they be done as:
> >
> > >   A -> B -> D, with a separate way B -> C?
> >
> > A contentious point, but I would say "yes".  It makes renderers and data
> > models with no notion of two-point segments (only multi-point polylines)
> > handle the data better, e.g. shapefiles.
>
> Contentious? Where is the contention :-) Surely a way would never double
> back on itself? Isn't it as wrong as a zero length segment? I understand the
> debate about forked/looped/disjoint ways. I can see how they can be
> *logically* fine but a complete pain for a rendering engine. In this case we
> have a way that overlaps itself. I can't see how that can be ok!

Currently the api permits ways of this kind to be created.  In the
absence of any authoritative documentation to clarify this, we have to
assume that this is a deliberate and intentional behaviour of the api.
 It has been like this for many months and I've never seen any
statement or documentation that indicates that such non-contiguous
ways is either a bug or an unintended behaviour.  It would be nice if
there were some authoritative clarification (Steve?).

So currently it *is* perfectly valid to have a way made up of more
than one non-contiguous sub-paths.  Renderers just have to cope with
it.

Interestingly the definition of a path in svg allows it to be made up
of multiple discontinuous sub-paths and I would imagine that they
thought about this kind of thing quite deeply before agreeing the w3c
recommendation for svg.

Personally, I feel it would be easier if non-contiguous ways were not
permitted and superways were used to to group and tag them.  But thats
another story.

80n




More information about the dev mailing list