[Tagging] Reviving the conditions debate

Martin Vonwald imagic.osm at gmail.com
Fri Jun 15 08:47:10 BST 2012


Good morning,

After reading martinq's mail and all the responses to it up to now I
want to share my thoughts.

At first I thought that it's an interesting idea. Unusual, but still
interesting. Then I read Colin's arguments and at first had to agree
with him: a human language - no matter which one - is far too complex
and therefore it might be much too error-prone to parse. Especially as
the majority of the mappers don't have english as their native
language.

Our alternatives all have their own (hopefully) exact specified syntax
and therefore should be easier to process. Their syntax - or lets call
it language - is (assumed) simple and therefore (possibly) easy to
learn. One moment: their language has to be learned? So what's the
difference to martinq's approach here? If someone doesn't speak
english he has to learn the basic version of it to express conditions.
In case of our other alternatives he has to learn their "language",
aka syntax. So again: where's the difference? Obviously a human
languages is much more flexible and ambiguous in many ways. Here comes
Colin's duck-argument: humans might express conditions in a way that
is correct but not understood by our parser. Simple because human
language gives us endless possibilities to express something.

But again - where's the difference? When we consider only simple
examples, like a speed limit when it's raining, we can safely rely on
the laziness of people. They will write something like "maxspeed:cond
= 80 if wet" or "maxspeed:cond = 80 in case it is raining", but they
will not write "maxspeed:cond = 80 in the inconvenient case that the
humidity approaches 100%". So I'm very sure that for those cases
martinq's approach would work as good as our other ideas.

How about more difficult cases? How about this one:
  Extended condition:
  _____________________
  motor_vehicle:forward:(Mo-Fr 16:00-18:00)=agricultural
  goods:forward:(Mo-Fr 16:00-18:00)=yes

  motor_vehicle:forward:(Mo-Fr 06:00-09:00)=agricultural
  goods:forward:(Mo-Fr 06:00-09:00)=yes
  _____________________

  access 1.5:
  _____________________
  access!forwardrule.time=Mo-Fr 16:00-18:00
  access!forwardrule.direction=forward
  access!backwardrule.time=Mo-Fr 06:00-09:00
  access!backwardrule.direction=backward

  access:motorized?forwardrule=no
  access:motorized?backwardrule=no

  access:motorized&&agricultural=yes
  access:motorized&&delivery=yes
  _____________________

How many people do you think can read and write this correctly? No
matter how good you document it! 10% of all mappers? 1%? How many will
try and end up with incorrect rules? Never forget we rely heavily on
all our mappers. As many mappers as possible must be able to
understand our tags so that they are constantly verified, updated,
corrected. That is also the reason why human readability must be our
first priority.

Lets have a look at the last example in human language:
_____________________
No motor vehicles from Monday to Friday between 16:00-18:00 except
agricultural vehicles and good vehicles in forward direction. Going
the other way the time is between 6:00 and 9:00.
_____________________
Yes, that's damned long. But so is the 1.5 solution and it uses a lot
of tags. Will a parser be able to understand this (correctly)?
Martinq: that's your part ;-)


What's my point after all this? For simple cases it doesn't matter if
someone has to learn to write "maxspeed:wet=80" or "maxspeed=80 if
wet". If you don't already know it (syntax or english) you have to
learn it!
For complex cases we will always have the problem that only a few will
be able to read and write those tags correctly. But at least we
shouldn't crowd the tag list with a lot of tags that only describe
one, single conditional value. (The last one seems to be an argument
against 1.5 which seems to rely quite often on self-defined
conditions.)

So finally I think there is not much difference between martinq's
approach and all the others. I personally am not really convinced of
this approach but I suggest to give this approach a fair chance, try
it and see how it works.

I would like to put some examples in my comparison table (@martinq:
could you provide some, that are already working?). I also want to
write some small questionnaire with examples of all approaches and
give it to new mappers - preferable one with no or limited knowledge
of the english language - and see if they understand what those tags
mean without explaining anything in advance.

Martin

P.S.: An expression builder is no argument - neither for one nor any
other approach. One can provide an expression builder for any
approach.



More information about the Tagging mailing list