<pre>Eckhart wrote:<br><br>><i> > - you lose backward compatibility
</i>><i> 
</i>><i> The proposal falls back to existing tag schemas therefore providing
</i>><i> backwards compatability.
</i>
No, it doesn't. If you set maxspeed=120; wet 80, then none of the existing routing programs can use this tag anymore. The Extended Conditions proposal uses the tagging maxspeed=120, maxspeed:wet=80, which allows existing routing programs to still use the maxspeed key.

><i> > - you run into the (real) risk of exceeding the 255 byte limit imposed on values
</i>><i> 
</i>><i> That would have to be one hell of a complicated access rule!!
</i>
Oh, you haven't seen anything. German inner city pedestrian zones are infamous for complex access restrictions (taking into account bicycles, delivery traffic, destination traffic, taxis, all of them depending on the day of week and the time of the day, and sometimes even on the direction).

Eckhart<br><br><br>-------------<br><br>Apologies. What was meant was that software need only cut off the extended values to return to existing systems (and thus compatibility). For example "maxspeed=120; wet 80" is chopped down to "maxspeed=120
". As there are lots of tags in use, it will be tricky to find a schema that is both liked and does not break a single thing.<br><br><br>As for 255 bytes. All vehicles have their own tag, so would be tricky to hit 255 bytes.<br>
<br>Regards,<br>Rob<br><br>p.s. I am trying to suggest an alternative that does not put all the conditions in the tag key (as this was one of the big criticisms).<br></pre>