[OSM-talk] NCN refs - consistency
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
> 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
> 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
More information about the talk