On Tue, Aug 5, 2008 at 5:49 PM, Matthias Julius <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] (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 _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
