[OSM-talk] conditions as part of value/key

Roy Wallace waldo000000 at gmail.com
Sat Aug 8 02:34:02 BST 2009


On Sat, Aug 8, 2009 at 10:49 AM, Tobias Knerr<osm at tobias-knerr.de> wrote:
> Roy Wallace wrote:
>> You don't need "all maxspeeds" to be in a single value. Nor would it
>> break existing applications. Maxspeed=* is still maxspeed=*. You would
>> be adding additional keys such as maxspeed:time, or maxspeed:vehicle,
>> or maxspeed:weather, etc.
>
> That seems to be superior to other value-based approaches I've seen so
> far. However, I can't see how you would handle a situation with multiple
> conditions for a tag's value, for example what I would express as
> "maxspeed[hgv][wet]". Did I miss something or is that simply not possible?

Yeah you missed something, originally in thread with subject "[RFC]
restriction=school_zone (second email)". I'll repeat:

<X>:<K> = <L>;<V>, where
X = the standard tag (maxspeed, or access, or bicycle, etc.)
K = the kind of condition
L = the value of the condition (in an appropriate format according to K)
V = the value for <X> (e.g. yes/no, speed in kmph, etc.)

For the multiple conditions, I suggested extending this to:
<X>:<K1>[:<K2>]* = <L1>[;<L2>]*;<V>
which for your example would be maxspeed:vehicle:weather = hgv;wet;<value>

>> The only disadvantage is that if you have
>> two of the same kind of restrictions, e.g. an "in general" maxspeed,
>> plus TWO OR MORE maxspeed:time restrictions, for example, you need to
>> add _1, _2 at the end of the keys, which sucks, although John pointed
>> out this is apparently already in use.
>
> I haven't ever seen this one being used (though I can imagine it as an
> attempt to set multiple alternative names and the like) and for sure I
> haven't seen any documentation for it. It definitely isn't really
> "key-ish", either. ;)

Yeah. The alternative is to store multiple values, where necessary, in
the value field (basically, as a serialized array). You'd just need to
introduce another delimiter, say, "|". e.g. Which is better of the
following?:

maxspeed:vehicle:weather_1 = hgv;wet;<value1>
maxspeed:vehicle:weather_2 = motorcycle;wet;<value2>

OR

maxspeed:vehicle:weather = hgv;wet;<value1>|motorcycle;wet;<value2>

Actually that's quite readable...

> Well, we already have some keys which are actually conditional tagging
> in disguise, such as bicycle=yes (which is an access=yes with a vehicle
> condition, imo). So /keeping/ keys key-ish might not quite work...

Yep, "keeping" wasn't the right word. But IMHO we shouldn't be
discouraged from introducing a good scheme because existing schemes
are different, as long as they can cooperate nicely. You are right,
though, bicycle=yes could potentially be rewritten as access:vehicle =
bicycle;yes. But it doesn't have to be.

> Btw, it's nice to finally get some ideas about the conditional tagging
> issue. I only wonder why people didn't provide this sort of feedback
> when I explicitly requested it for for my proposal[1] and its
> predecessor. *scratches head*

Guess that's the problem with being a volunteer organisation :)




More information about the talk mailing list