On Saturday 30 August 2008 22:03:33 Aurelien Jacobs wrote: I think this idea might evolve into something worth championing.
Aurelian has covered a few points I was just composing :~) > Gervase Markham wrote: > > It seems to me that there are three ways we can deal with this: > > > > 0) Just place point features next to the way, with no explicit > > association apart from proximity. This is what we do now, and this lack > > of association causes problems. For linear features, you need to create > > a new, parallel way for that feature. Having to create this extra way is > > sub-optimal. > > > > One other problem with this is that it defines a set distance from the > > feature to the way. > > I don't see this as a problem. It's in fact an additional useful > information that your left/right scheme just loose. > +1 right there, maybe loosing some for the spelling :~) > > This means that, as you zoom out, the feature icon > > migrates onto the way itself as the way rendering "thickens". > > As you zoom out, the POI aren't displayed anymore, so I doubt > this can be a problem. > And if you think it's really a problem, when used along with > relations as proposed below, the renderer can treat those points > exactly as if they were part of the way with left/right tags. +1 > > > 1) Create relations to associate the point with the way - one relation > > per feature type, or perhaps a generic relation type. > > That would be useful. > > > Except that relations are heavyweight things > > Heavyweight things ?? I don't get what you mean here. > > > complicated to set up (in current editors). > > The same way we shouldn't map for renderers, we also shouldn't > map for editors ! > If editors are somewhat complicated at setting relations, > the should be improved... +lots . Don't think Gervase has properly refuted the model as such here. It should be about creating an adequate representation, no? > > > 2) The generic left-right scheme proposed below. > > > > Left/Right Scheme > > ----------------- > > > > I propose that it be possible for features to be tagged using a generic > > left/right scheme, with left and right being relative to the direction > > of the way. > > > > So you might have a road way with a node somewhere in the middle with > > (for example): > > left:highway=bus_stop > > right:parking=pay_and_display > > So, just to clarify, if I want apply more properties to the bus stop, is it like this: left:highway=bus_stop left:name=Park Road … etc? Have I missed something? Syntax: ---------- This is where I really noticed a problem, but it certainly doesn't kill the idea. The problem is that you're using a syntactic convention that I (at least) associate with XML namespaces. I've seen other tags like piste:foo fashioned after XML namespace prefixes, and they make sense, i.e. the "piste" vocabulary. This "scheme" is really a collection of two qualifiers which play the role of directing the descriptions away from the node [insert more stuff and get accused of being an astronaut]. Anyways, I see danger in this syntax. P.S. Richard's reply has now come through. I can't think of a use case for distance from the way, but nor can I rule it out. Still, it's a "hook" to the real world we're describing and I can't see problem with keeping such possibilities open. At the same time, not sad to see it left out. It *is* a great idea - needs development, expansion, and perhaps better arguments than the current toolset. Please point me to IRC logs or whatever if it's already been fleshed through. Slightly incoherent myself, I admit, but at least in my defence I can point to the clock :~) Cheers _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
