date:20120613

Hi everybody,

I want to revive the discussion on how to tag restrictions that depend on 
certain conditions. My idea is to finalize the proposal described in 
http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags
 and finally accept it.

The reasons for picking this proposal:
* The proposal mostly describes syntax that is already used for tagging, e.g. a 
maxspeed in a certain direction is almost always tagged as maxspeed:forward, 
maxspeed:backward
* The proposal is intuitive and simple to use: the key of a tag is the base tag 
+ a set of conditions that all have to be true for the key to apply (i.e. 
logical AND).
* The proposal is complete: every logical formula of conditions can be 
expressed in it (technically, it's pretty similar to disjunctive normal form).
* The proposal is consise: it follows the pattern most dominant with road 
restrictions, namely overriding general restrictions with special restrictions. 
It normally uses no more than one tag per sign.
* The proposal is extensible: the set of conditions is not fixed and can be 
extended to new conditions. It is possible to set a sane default for new 
conditions that are experimental.
* The proposal is easily implementable: I implemented it in a prototype already.

The only real negative aspect that has been mentioned until now:
* the proposal puts a lot of information into keys and theoretically allows for 
an unlimited set of keys. (The reality however shows that those keys tend to be 
the same, e.g. taginfo shows no less than 335 elements with key 
maxspeed:(22:00-06:00)).

Competing proposals:
* http://wiki.openstreetmap.org/wiki/Proposed_features/access_restrictions_1.5 
- in my opinion a horrible and incomprehensible syntax with arbitrary 
distinctions, taginfo revealed almost no uses (for example, maxspeed:hgv:wet 
in the Extended Conditions proposal above is access:lgv?wet.speed in the 
Access Restrictions 1.5 proposal)

Opinions?

Eckhart

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the conditions debate

Am 13.06.2012 14:35, schrieb Eckhart Wörner:

Hi everybody,

I want to revive the discussion on how to tag restrictions that depend on
certain conditions. My idea is to finalize the proposal described in
http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags
and finally accept it.

The reasons for picking this proposal:
* The proposal mostly describes syntax that is already used for tagging, e.g. a
maxspeed in a certain direction is almost always tagged as maxspeed:forward,
maxspeed:backward
* The proposal is intuitive and simple to use: the key of a tag is the base tag
+ a set of conditions that all have to be true for the key to apply (i.e.
logical AND).
* The proposal is complete: every logical formula of conditions can be
expressed in it (technically, it's pretty similar to disjunctive normal form).
* The proposal is consise: it follows the pattern most dominant with road
restrictions, namely overriding general restrictions with special restrictions.
It normally uses no more than one tag per sign.
* The proposal is extensible: the set of conditions is not fixed and can be
extended to new conditions. It is possible to set a sane default for new
conditions that are experimental.
* The proposal is easily implementable: I implemented it in a prototype already.

The only real negative aspect that has been mentioned until now:
* the proposal puts a lot of information into keys and theoretically allows for an
unlimited set of keys. (The reality however shows that those keys tend to be the same,
e.g. taginfo shows no less than 335 elements with key maxspeed:(22:00-06:00)).

Competing proposals:
* http://wiki.openstreetmap.org/wiki/Proposed_features/access_restrictions_1.5 - in my opinion a
horrible and incomprehensible syntax with arbitrary distinctions, taginfo revealed almost no uses
(for example, maxspeed:hgv:wet in the Extended Conditions proposal above is
access:lgv?wet.speed in the Access Restrictions 1.5 proposal)

Opinions?

I think your example: access:weight5.5 = destination should be changed
into something like maxweight:destination=*. This seems to be more
logical and equal to your other examples.

There is also an actual proposal:
http://wiki.openstreetmap.org/wiki/Proposed_features/Conditions_for_Restrictions

Henning

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the conditions debate

2012/6/13 Eckhart Wörner ewoer...@kde.org:
 Competing proposals:
 * 
 http://wiki.openstreetmap.org/wiki/Proposed_features/access_restrictions_1.5 
 - in my opinion a horrible and incomprehensible syntax with arbitrary 
 distinctions, taginfo revealed almost no uses (for example, 
 maxspeed:hgv:wet in the Extended Conditions proposal above is 
 access:lgv?wet.speed in the Access Restrictions 1.5 proposal)

In my opinion the 1.5 proposal is not that horrible. The syntax is
quite complicated so that no mere mortal will ever understand it and
we would need quite some editor support there. But is also seems to be
more flexible and powerful.

However your example access:lgv?wet.speed is a good one against the
1.5 proposal. But why not combine those proposals? This would result
in maxspeed:hgv?wet. I read this as the MAXSPEED for HGV IF (the
question mark) weather is WET is  Sound reasonable to me.

To me the 1.5 proposal shows a good idea how to introduce conditions,
but I would not force everything in the access-namespace. From an
academic point of view the 1.5 this would be consistent, from a
practical point of view it would complicate things too much. IMO ;-)

Martin

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the conditions debate

2012-06-13 Thread Tobias Knerr

On 13.06.2012 15:07, Martin Vonwald wrote:
 2012/6/13 Eckhart Wörner ewoer...@kde.org:
 Competing proposals:
 * 
 http://wiki.openstreetmap.org/wiki/Proposed_features/access_restrictions_1.5 
 - in my opinion a horrible and incomprehensible syntax with arbitrary 
 distinctions, taginfo revealed almost no uses (for example, 
 maxspeed:hgv:wet in the Extended Conditions proposal above is 
 access:lgv?wet.speed in the Access Restrictions 1.5 proposal)
 
 In my opinion the 1.5 proposal is not that horrible. The syntax is
 quite complicated so that no mere mortal will ever understand it and
 we would need quite some editor support there. But is also seems to be
 more flexible and powerful.

Can you give a concrete example where it is actually more powerful?
Something that can be expressed with restrictions 1.5, but not with
the extended conditions syntax?

(Yes, it lists more of the same - more vehicle types, more groups of
users, more weather conditions and so on. But that's not what I mean.
These things don't have anything to do with the syntax.)

 However your example access:lgv?wet.speed is a good one against the
 1.5 proposal. But why not combine those proposals? This would result
 in maxspeed:hgv?wet. I read this as the MAXSPEED for HGV IF (the
 question mark) weather is WET is  Sound reasonable to me.

More reasonable than access:lgv?wet.speed, yes. But how is it easier
than maxspeed:hgv:wet?

Tobias

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the conditions debate

2012-06-13 Thread David Earl


On 13/06/2012 14:36, David Earl wrote:

http://www.frankieandshadow.com/xref/byway.jpg


BTW, this means I can use this road at all times as a cyclist, even when 
the barrier is locked shut, whatever the other restrictions on motor 
vehicles are.



___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the conditions debate

2012/6/13 Tobias Knerr o...@tobias-knerr.de:
 Can you give a concrete example where it is actually more powerful?

For example the self-defined conditions. Not elegant in my opinion,
improvable, but quite nice!

 Something that can be expressed with restrictions 1.5, but not with
 the extended conditions syntax?

 (Yes, it lists more of the same - more vehicle types, more groups of
 users, more weather conditions and so on. But that's not what I mean.
 These things don't have anything to do with the syntax.)

 However your example access:lgv?wet.speed is a good one against the
 1.5 proposal. But why not combine those proposals? This would result
 in maxspeed:hgv?wet. I read this as the MAXSPEED for HGV IF (the
 question mark) weather is WET is  Sound reasonable to me.

 More reasonable than access:lgv?wet.speed, yes. But how is it easier
 than maxspeed:hgv:wet?

Simply because it uses different separators for different purposes.
The : is used often for subkeys. It is not a good choice here. The 1.5
uses the ? in front of the condition. So it is obvious where the
condition starts. IMO a good approach.

Martin

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the conditions debate

Hi David,

Am Mittwoch, 13. Juni 2012, 14:47:09 schrieb aighes:
 I think your example: access:weight5.5 = destination should be changed 
 into something like maxweight:destination=*. This seems to be more 
 logical and equal to your other examples.

First, I did not write the proposal, someone else did a long time ago. :-)
Second, in principle I fully agree with you, destination is a condition. 
Technically, the tag:
access:(weight5.5)=destination
is equivalent to these two tags:
access:(weight5.5)=no
access:(weight5.5):destination=yes
However, destination as a value for access has been in use for quite some 
time, and I don't want to deprecate it (right now). The same goes for delivery, 
forestry, …

I have written down some lines on how to interpret legacy tagging in the 
comments.

 There is also an actual proposal: 
 http://wiki.openstreetmap.org/wiki/Proposed_features/Conditions_for_Restrictions

I've just learnt about this proposal, which is brand new. Most parts are the 
same, however, it has some new ideas I really don't like:
* It assumes access is the default, and e.g maxweight is a completely different 
beast. It isn't: maxweight=7.5 is just a shorter way of saying 
access:(weight7.5)=no. (Again, I don't want to deprecate the maxweight key 
(right now).
* It invents new values, e.g. oneway[:…]=forward. The Extended Conditions 
proposal tries to invent as little as possible.
* It tries to incorporate the lanes proposal, and I'm not sure that's a good 
idea. Extended Conditions are certainly a necessary building block for lane 
dependent conditions, but that's a different story.

Eckhart

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the conditions debate

2012/6/13 Eckhart Wörner ewoer...@kde.org:
*snip*
 access:(weight5.5):destination=yes
*snip*

This is a good example of a bad choice of separators. Because
(weight5.5) and destination are both conditions, but if I don't know
that they are conditions, I have no chance of figuring it out. If you
use a different character (like the ? in the 1.5) it would be clear
where the conditions start.


 There is also an actual proposal:
 http://wiki.openstreetmap.org/wiki/Proposed_features/Conditions_for_Restrictions
 I've just learnt about this proposal, which is brand new. Most parts are the 
 same, however, it has some new ideas I really don't like:

Didn't know about that too. And it has the same problem:
  maxspeed:lanes:hgv:wet=60|50|40

Where does the condition begin? Again this is not obvious. Small change:
  maxspeed:lanes?hgv:wet=60|50|40

Now it is clear.

Martin

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the conditions debate


Am 13.06.2012 16:12, schrieb Martin Vonwald:

2012/6/13 Eckhart Wörnerewoer...@kde.org:
*snip*

access:(weight5.5):destination=yes

*snip*

This is a good example of a bad choice of separators. Because
(weight5.5) and destination are both conditions, but if I don't know
that they are conditions, I have no chance of figuring it out. If you
use a different character (like the ? in the 1.5) it would be clear
where the conditions start.
For me the system is clear. 
basekey:condition_1:condition_2:...:condition_n=value.


I think maxweight is an already used basekey and maximum weight is also 
a part of access. So it should be used like maxspeed, maxheight etc.


Henning


___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the conditions debate

2012-06-13 Thread Martin Koppenhoefer

2012/6/13 aighes o...@aighes.de:
 I think maxweight is an already used basekey and maximum weight is also a
 part of access. So it should be used like maxspeed, maxheight etc.


+1
instead of access:(weight5.5)=no the established tagging is
maxweight=5.5 or maxweight=5.5t

cheers,
Martin

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the conditions debate

Hi Martin,

Am Mittwoch, 13. Juni 2012, 15:47:12 schrieb Martin Vonwald:
 For example the self-defined conditions. Not elegant in my opinion,
 improvable, but quite nice!

The only advantage of self-defined conditions is that you can remove some 
redundancy when two tags contain the same subset of conditions, e.g. applies in 
situations like this:
maxspeed:hgv:(weight7.5):(Mo-Fr 08:00-16:00):forward=50
maxspeed:hgv:(weight7.5):(Mo-Fr 08:00-16:00):backward=30

In this case one could somehow define:
heavy_trucks_during_week ≔ hgv:(weight7.5):(Mo-Fr 08:00-16:00)
And then write the tags as:
maxspeed:heavy_trucks_during_week:forward=50
maxspeed:heavy_trucks_during_week:backward=30

I'm not sure that's a real improvement (note that with the Access Restrictions 
1.5, the definition of heavy_trucks_during_week is slightly more complex.)

  However your example access:lgv?wet.speed is a good one against the
  1.5 proposal. But why not combine those proposals? This would result
  in maxspeed:hgv?wet. I read this as the MAXSPEED for HGV IF (the
  question mark) weather is WET is  Sound reasonable to me.
 
  More reasonable than access:lgv?wet.speed, yes. But how is it easier
  than maxspeed:hgv:wet?
 
 Simply because it uses different separators for different purposes.
 The : is used often for subkeys. It is not a good choice here. The 1.5
 uses the ? in front of the condition. So it is obvious where the
 condition starts. IMO a good approach.

The : is always used for subkeys, because that's the definition of a subkey. 
I'm not sure what you want to express here.
About different purposes: hgv is just short for I'm driving a heavy goods 
vehicle, i.e. just another condition (that can be evaluated to true or false).

Eckhart

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the conditions debate

2012/6/13 aighes o...@aighes.de:
 For me the system is clear.
 basekey:condition_1:condition_2:...:condition_n=value.

How about this:
http://wiki.openstreetmap.org/wiki/Key:parking:lane

The basekey is parking:lane. How do you know that lane is not a condition?


 I think maxweight is an already used basekey and maximum weight is also a
 part of access. So it should be used like maxspeed, maxheight etc.

Sorry, missed your point here.. ?

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the conditions debate


Am 13.06.2012 16:30, schrieb Martin Vonwald:

2012/6/13 aigheso...@aighes.de:

For me the system is clear.
basekey:condition_1:condition_2:...:condition_n=value.

How about this:
http://wiki.openstreetmap.org/wiki/Key:parking:lane

The basekey is parking:lane. How do you know that lane is not a condition?
Yes...but there is the problem? If you search for information for 
parking:lane, you can remove this string from the key and all conditions 
will left.



I think maxweight is an already used basekey and maximum weight is also a
part of access. So it should be used like maxspeed, maxheight etc.

Sorry, missed your point here.. ?
I think it isn't useful to have a new key for restriction based on 
weight. maxweight is already established.


Henning


___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the conditions debate

2012/6/13 aighes o...@aighes.de:
 Am 13.06.2012 16:30, schrieb Martin Vonwald:

 2012/6/13 aigheso...@aighes.de:

 For me the system is clear.
 basekey:condition_1:condition_2:...:condition_n=value.

 How about this:
 http://wiki.openstreetmap.org/wiki/Key:parking:lane

 The basekey is parking:lane. How do you know that lane is not a condition?

 Yes...but there is the problem? If you search for information for
 parking:lane, you can remove this string from the key and all conditions
 will left.

The problem is that you don't have a clear separation between key and
condition. In my opinion it would improve readability for people (not
programs) if we separate those two clearly.


 I think maxweight is an already used basekey and maximum weight is also a
 part of access. So it should be used like maxspeed, maxheight etc.

 Sorry, missed your point here.. ?

 I think it isn't useful to have a new key for restriction based on weight.
 maxweight is already established.

That's why I missed your point: I agree with you ;-)


Martin

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the conditions debate

2012/6/13 Tobias Knerr o...@tobias-knerr.de:
 On 13.06.2012 16:12, Martin Vonwald wrote:
 If you use a different character (like the ? in the 1.5)
 it would be clear where the conditions start.

 That's a valid argument, but we need to be aware that there is already a
 lot of existing tagging that uses a colon as the condition separator.
 These are usually examples with just a single condition, things like
 maxspeed:wet, :hgv,

Correct. And for the sake of compatibility I would never-ever touch them.

 :forward, :backward, ...

I don't think of them as conditions, but more a selection of a part of
a way. Just like :lanes is to me not a condition.

 I also doubt whether the distinction between a subkey and a
 condition would always be obvious to mappers.

 Didn't know about that too. And it has the same problem:
   maxspeed:lanes:hgv:wet=60|50|40

 Where does the condition begin? Again this is not obvious. Small change:
   maxspeed:lanes?hgv:wet=60|50|40

 That's interesting, I would have assumed that the tag should look like
 maxspeed:hgv:wet:lanes to allow for per-lane fallbacks.

Is lanes a condition? I don't think so. To me it's a subkey. So we
should always have
basekey:subkey1:subkey2?condition1:condition2=value


 For example, if there is only one lane that changes maxspeed when wet,
 one might want to write that as follows:

 maxspeed:lanes = 80|80|80
 maxspeed:lanes?wet = ||50

I would instead use maxspeed=80 for the first tag. Simpler. Compatible.

 Yes, you could evaluate this without any knowledge about the semantics
 of the base key. But doing so would result in the value of
 'maxspeed:lanes' is '||50' when the road is wet. That's not actually
 what we want - we do want the keep the '80' for the first two lanes.

Actually it is what we want. Because:
1) Either the application knows, what :lanes means. Then the value
of 'maxspeed:lanes' is '||50' when the road is wet means that the
first two lanes don't change the maxspeed value if the road is wet,
but the third changes it to 50.
2) Or the application does not know what :lanes mean. Then it also
has no clue what maxspeed:lanes is and ignores it.

To me it seems perfectly consistent.

Martin

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the conditions debate

Hi Tobias,

Am Mittwoch, 13. Juni 2012, 17:05:34 schrieb Tobias Knerr:
 For example, if there is only one lane that changes maxspeed when wet,
 one might want to write that as follows:
 
 maxspeed:lanes = 80|80|80
 maxspeed:lanes?wet = ||50

I would go even further and mandate that lane-independent information should 
not be hidden in lane-dependent tagging, i.e.:
maxspeed=80
maxspeed:lanes:wet = ||50

Eckhart

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the conditions debate

2012-06-13 Thread Martin Koppenhoefer

2012/6/13 Martin Vonwald imagic@gmail.com:
 The problem is that you don't have a clear separation between key and
 condition. In my opinion it would improve readability for people (not
 programs) if we separate those two clearly.


I tend to agree with Tobias here: it is not always clear whether it is
a condition or a subkey. hgv for instance could be interpreted as
condition (if you are in a heavy goods vehicle) or as a subkey
(vehicle class), and looking at the examples in this thread mappers do
choose one of these two but not always the same. I guess in the end
you won't be able to rely on this distinction.

Cheers,
Martin

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the conditions debate


Am 13.06.2012 17:07, schrieb Martin Vonwald:

2012/6/13 aigheso...@aighes.de:

Am 13.06.2012 16:30, schrieb Martin Vonwald:


2012/6/13 aigheso...@aighes.de:

For me the system is clear.
basekey:condition_1:condition_2:...:condition_n=value.

How about this:
http://wiki.openstreetmap.org/wiki/Key:parking:lane

The basekey is parking:lane. How do you know that lane is not a condition?

Yes...but there is the problem? If you search for information for
parking:lane, you can remove this string from the key and all conditions
will left.

The problem is that you don't have a clear separation between key and
condition. In my opinion it would improve readability for people (not
programs) if we separate those two clearly.
Ok human readability is a good point. But works only til we have a key 
like foo?bar=* ;-)

Also a :: would be possible.

Henning


___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the conditions debate

2012/6/13 aighes o...@aighes.de:
 Ok human readability is a good point. But works only til we have a key like
 foo?bar=* ;-)

I use this key now for a year or so for various data. I'm writing an
article about it in the next days ;-)

 Also a :: would be possible.

Possible: yes. Better?

Think of a:b:c:d=x and a:b?c:d=x . Where do you spot the condition faster?


Martin

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the conditions debate

2012-06-13 Thread Tobias Knerr

On 13.06.2012 17:18, Martin Vonwald wrote:
 
 :forward, :backward, ...
 
 I don't think of them as conditions, but more a selection of a part of
 a way. Just like :lanes is to me not a condition.

I think we've discussed this several times already, and as you know I do
not think this part of a way interpretation of forward/backward is
appropriate. You could easily place signs with different restrictions
for each direction on a one-lane road.

 I also doubt whether the distinction between a subkey and a
 condition would always be obvious to mappers.

As promptly illustrated by the fact that we can't even agree that
forward/backwards are conditions.

 Is lanes a condition? I don't think so.

I don't think so either. The point I was trying to make was a different
one, as I'm trying to explain below.

 For example, if there is only one lane that changes maxspeed when wet,
 one might want to write that as follows:

 maxspeed:lanes = 80|80|80
 maxspeed:lanes?wet = ||50
 
 I would instead use maxspeed=80 for the first tag. Simpler. Compatible.

Yes. Simpler, compatible and all that, but irrelevant for the example.

 Yes, you could evaluate this without any knowledge about the semantics
 of the base key. But doing so would result in the value of
 'maxspeed:lanes' is '||50' when the road is wet. That's not actually
 what we want - we do want the keep the '80' for the first two lanes.
 
 Actually it is what we want. Because:
 1) Either the application knows, what :lanes means. Then the value
 of 'maxspeed:lanes' is '||50' when the road is wet means that the
 first two lanes don't change the maxspeed value if the road is wet,
 but the third changes it to 50.
[...]
 To me it seems perfectly consistent.

This means I didn't explain well enough. Let's update the example to
make this more clear:

maxspeed=80
maxspeed:lanes = 60|80|80
maxspeed:lanes?wet = ||50

First step: Evaluate the conditions without regard for the semantics of
the rest of the keys. wet is true, so this tagging changes to

maxspeed=80
maxspeed:lanes = ||50

for the purpose of further evaluation. Remember: We did not take the
semantics of maxspeed:lanes into account here, instead we relied on
the ? separator to treat the front part of the keys in a generic way.

This means that the maxspeed for the first lane will be 80 - there is no
lane-specific value, so the road's general maxspeed is used. But it
should of course be 60.

Tobias

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the conditions debate

2012-06-13 Thread Colin Smale

For some reason everyone seems determined to come up with the most
complex system imaginable, instead of taking successful ideas from the
rest of the world. This trait is what causes many projects to fail.
Let's not look at this as simply a discussion about access tags, but
an opportunity to extend the syntax of the current key-value pair system
to include flexible extensibility.

How about something like access:expr=expression, where the expression is
in some simple syntax and can reference pseudo-variables like time, day,
weather, weight, height etc. Why not use a javascript-compatible syntax?
Or a bit of XML? No point in re-inventing the wheel.

Colin

On 13/06/2012 14:35, Eckhart Wörner wrote:

Hi everybody,

Opinions?

Eckhart

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the conditions debate

Am 13.06.2012 um 17:45 schrieb Tobias Knerr o...@tobias-knerr.de:

 This means I didn't explain well enough. Let's update the example to
 make this more clear:
 
 maxspeed=80
 maxspeed:lanes = 60|80|80
 maxspeed:lanes?wet = ||50
 
 First step: Evaluate the conditions without regard for the semantics of
 the rest of the keys. wet is true, so this tagging changes to
 
 maxspeed=80
 maxspeed:lanes = ||50
 
 for the purpose of further evaluation. Remember: We did not take the
 semantics of maxspeed:lanes into account here, instead we relied on
 the ? separator to treat the front part of the keys in a generic way.
 
 This means that the maxspeed for the first lane will be 80 - there is no
 lane-specific value, so the road's general maxspeed is used. But it
 should of course be 60.

To me your evaluation is correct and your tagging is wrong. Any :lanes-tag 
specifies the values for all lanes for the basekey. If a lane value is omitted 
the general (i.e. non-lane) value applies. So the tagging should be:
  maxspeed=80
  maxspeed:lanes = 60|80|80
  maxspeed:lanes?wet = 60|80|50
or using default values:
  maxspeed=80
  maxspeed:lanes = 60||
  maxspeed:lanes?wet = 60||50

And finally: don't get me wrong! I really don't care a lot if it is a:b:c=x or 
a:b?c=x or whatever. As long as most people can live with it, use it and 
applications support it I'm fine with everything. I just throw my opinions in 
the ring, hope that many join and we find a good and accepted solution.

Martin
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the conditions debate