[OSM-talk] NCN refs - consistency

[Dave]

>
> No, you missed the point. baz,foo,bar are choices by the mapper. They
> are merely arbitrary ids to tie the group of tags together, unique only
> to routes within a single way; it doesn't mater what they are called.
>
> As I said, there needs to be an additional tag to say what kind of route
> it is. In my version of this you'll see I had
>    route=var1;var2;...
> and
>    route:var1=ncn
>    route:var2=bus
> etc
>

Yes, I was actually responding to the other suggestion. It was less
'meta' as someone put it.
Personally I'd prefer it if tagging systems were as simple as
possible, and introducing variables into the mix is an extra
complication.

It's also not really necessary as I see it. The major point of your
variable is that you don't have to define every route type, but your
route:var1=ncn needs defining anyway, so you might as well replace the
var1 with ncn... they're equivalent

I know there was the second feature which was you can have 2 instances
of the same type, ie: var1=ncn & var2=ncn, ref:var1=4 & ref:var2=5,
but this can be achieved by just doing ref:ncn=4;5 (or ncn_ref or
ncn:ref whatever).
You can even handle multiple tags (ie: name:ncn) if you make sure list
order is significant.

Complex multi tag routes maybe slightly simpler (well, more robust at
least) with the variable solution, but the usual simple ref case is
more complicated than I think it needs to be.

Just from the renderer perspective, we can use mapnik out of the box
as long as the key name is static -- as soon as it becomes dynamic we
need to write an adapter in the data import stage.

Of course with decent editor support the difference would be largely
unimportant to the user :-)

> If you're worried about clashes with other tag names (name:language is
> one) then we could do
>    name:route:var1=... ref:route:var1=...

Hadn't actually thought about that, but yes, they would prob be better
for the actual names -- just to make it obvious what's going on.