[OSM-talk] NCN refs - consistency

David Earl david at frankieandshadow.com
Thu Jul 12 11:23:43 BST 2007

On 12/07/2007 11:08, Dave wrote:
>> 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

No, not true. In Cambridge there are examples where two ncn routes run 
along the same Way, and I'm sure this holds true elsewhere.

Many roads have multiple bus routes along them.

(Of course a sensible person using the variables wouldn't use foo and 
bar, but ncn and bus, or ncn11 and bus33 where necessary).

> 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.

I thought about that. But I think it is actually more complicated, 
because you have to be sure that there is a 1:1 correspondence of 
sequence an number of semicolon separated clauses across all tags that 
implicitly reference the route tag. This is hard to maintain, especially 
if not all the tags are appropriate to all the routes (you need blanks 
then; indeed what if he difference between absence of a tag and a 0 
length string value for a tag is significant?)

Thinking about it abstractly, your suggestion is like a set of parallel 
arrays where there are implicit numeric indices, so index 3 always 
refers to the same route wherever it applies, whereas mine is like a 
hash on named hash keys.

> 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.

Would it help to have something like

   route_ref=foo:NCN 11;bar:33;baz:101


More information about the talk mailing list