[OSM-talk] Left and Right - a proposal

[Hugh Barnes]

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