[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? Matthias _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
