[OSM-talk] superways as relations ?

[Dave Stubbs]

On Tue, Aug 5, 2008 at 5:49 PM, Matthias Julius <lists at julius-net.net> wrote:
> vegard at engen.priv.no (vegard) writes:
>
>> On Mon, Aug 04, 2008 at 11:07:24AM -0000, m*sh wrote:
>>> On Mon, August 4, 2008 10:14, vegard wrote:
>>> > For naming of streets in cities, where properties change very often and
>>> > you have to make many small ways, it sometimes gets annoying that the
>>> > name is duplicated.
>>> >
>>> > I was wondering: How good/easy would it be to make a superway-relation
>>> > to fix that? I.e. group several ways for labeling-intentions?
>>> >
>>> > I'm no expert on the inner workings in either of the renderers, but to
>>> > me it sounds like a quick fix to a small annoyance. If someone that
>>> > knows the renderers could either agree or disagree, I'd be happy anyways
>>> > (well, obviously happier if they agree :)
>>>
>>> Actually there is a 'mantra' on a german mailing list stating that,
>>> "we are not tagging for the renderer"
>>
>> I agree. We're not tagging for the renderer. At least, we're not tagging
>> it *wrongly* for the renderer.
>>
>> But in practise, we might need to give the renderer some hints with
>> some extra tagging. Of that, I personally am a little more inclined to
>> accept that. But others might agree/disagree with me. I think adding a
>> relation like that to help the renderer does in no way destroy the data
>> model.
>
> Regardless of the renderers, duplication of data is evil, IMHO.  Every
> time a way is split to allow one of its properties to change all other
> properties are duplicated.
>
> I would love to have a method of specifying that a way is named xxx
> from node A to E and named yyy from E to G, is a secondary highway
> from A to D and tertiary from D to G, is oneway from C to F, B to C is
> on a bridge, D to F has a speed limit of z, ... Then there are bus,
> tram and cycle routes ...
>
> The more detail is put into database the more reasons people have to
> split ways.
>
> There are probably several ways to implement this.  My favourite one
> is to move all meta-data into relations and to degrade ways
> essentially into multi-node segments.
>
> Better ideas?


The whole splitting ways things is definitely an irritation at the
moment, but at least the editors cope quite well with it.

Can you demonstrate a working editor interface for the degraded ways
idea? Or at least come up with some reasonable ideas as to how such an
editor would work?

By working I mean:
  - no need for a degree in the use of modifier keys
  - no need for an eleven button mouse
  - the interface makes the segmented data clearly visible
  - users can comprehend what's going on

If you can then it makes it possible, if you can't then it'll just
make the data uneditable.

Dave