[Tagging] Reviving the conditions debate

[Ilari Kajaste]

Hi fellow mappers!

Disclaimer: I'm a relative newbie to OSM, so feel free to take my
opinions as such. (I'm not a newbie to usability,
data structure definitions or programming though.)

On Wed, 13 Jun 2012, Colin Smale wrote:
> Whatever syntax is used, the *primary* requirement is that it is "usable" by programs - editors, renderers,
> routers etc. followed by a secondary requirement that it be understood by humans. If the human aspect was
> primary, then using a free-text field would be enough as humans are capable of incredible inference - something
> which "normal" computers still find challenging.

I don't understand your logic here. If the human aspect was the *only*
requirement, *then* a free-text field would
be enough. Nothing to do with it being a primary requirement, since
nobody was saying the tags shouldn't *also* be
computer readable - that's why they're kept in a structured format
instead of free text.


I consider human understandability to be primary. That means, human
understandability without any assisting
programs (other than maybe direct key/value semantic reference lists
for some conformity).

I consider computer readability to be secondary. It being "secondary"
does *not* make it *unimportant*. It is still
a requirement, just like the human understandability.

Why? Mostly becuse OSM seems to be built in that way. Moving away from
that looks to me to be a *major* deviation.
It's of course still possible it is the right way to go, but it's not
how OSM is right now. And it seems to work
for OSM.-


What I like about the "Extended conditions" proposal of simply having
and-conditions separated by a colon (":") is
that it doesn't try to be anything complex that requires you to read
any documentation to understand it. You can
learn it completely by example, fast. It also matches with the current
way of specifying special conditions
(subtags) (note that subtags are used for other purposes as well). It
really seems to be the OSM way of doing
things.

The only problem is that it does push data into the keys, but I don't
see a good way out of that - bloating the
value seems like a bad suggestion as well, and having the


As to the conditions vs. subtags differentiation - I don't see there
being that big of a difference between them. I
do understand the difference, though, but becuse it's often not a
clear and intuitive issue, separating conditions
from subtags probably shoudn't be done. Introducing a new rather
non-intuitive character ("?") to mark a difference
that isn't in many common context very clear will, in my opinion,
cause too much confusion compared to the
benefits.


> Editors can be extended with an expression builder and for advanced users they can be taught to check the syntax
> before comitting a change.

But would this actually happen? Would we get good, understandable
expression builders in editors, and would anyone
use them? I do doubt it.

Having complex laguage that relies on editor support (for most users)
doesn't seem like a realistic approach, from
what I've seen. But I admit I may be wrong here, since I'm not all
that familiar with OSM development history.

> Next point is that we really shouldn't be spending all our time discussing which delimiter to use and other
> similar aspects of the physical representation of the data.

That's only if we abandon human intuitive understandability. The
physical representation does matter if we want
humans to type in these conditions. That's why it's being discussed.


But if we *do* go into the direction that some tags (these conditions,
then probably lanes too) are written as
computer-intuitive programmer-understandable instead of
humanmapper-intuitive computer-understandable then I would
suggest these tags or values could always be prefixed with something
(eg. "special:", "code:", "computer:",
"extended:"). That way editors could know to only display them via a
special editor, instead of plaintext (unless
requested by user).

I really would hate to see xml, json or anysuch jumping at a mapper's
eyes in some tag/value list - that might have
a deterring effect on editing.

--
    - Ilari Kajaste -

E-Mail: ilari.kajaste at iki.fi
WWW: http://iki.fi/ilari.kajaste