[OSM-talk] Left and Right - a proposal

Hugh Barnes list.osm at hughbris.com
Sun Aug 31 02:24:56 BST 2008


(It's getting a tad difficult to keep the thread integrity. Other relevant 
replies from me may follow soon)

On Sunday 31 August 2008 08:08:23 Gervase Markham wrote:
> Hugh Barnes wrote:
> > 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?
>
> I hadn't thought of that; I was focussing on simple features in the
> common case. Does the above seem sensible, or do you have an objection
> if I say a tentative "Yes"? :-)
>

That's why you asked for comments! :~)

Well, it doesn't feel right to me - seem to be drifting quickly into the land 
of kludge. I personally plan to apply lots of metadata to bus stops for my 
routing needs. It seems more natural to just point to another node and keep 
its metadata there. Then we're back at relations, aren't we?

Actually, when I slept on this, I realised you're just proposing a shorthand: 
relations lite if you will.

You are using one node as a proxy for another's metadata.

> > 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.
>
> I've picked that convention because it's already used in the project.
> But I'm not wedded to it; if people would prefer an underscore, that's
> fine. But it seems that underscores are part of some tag names, not
> separators.
>
> Gerv
>

OK, good, and I'm not saying "don't steal XML syntax", I'm saying it could be 
confusing and more importantly "don't overload that convention in the same 
project (it may well bite you)".

So, underscores etc seem OK as far as the idea goes, but you'll end up with 
lots of (e.g.) "left_name", "right_ref" tags which any tool or aggregator or 
renderer will need to parse to get all names or refs out. (NB. I'm not 
designing around current tools, I'm looking for easy interfaces for them). 
You'd potentially triple/treble the tags in common use.

Cheers




More information about the talk mailing list