[Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"

Eckhart Wörner ewoerner at kde.org
Wed Sep 19 10:08:20 BST 2012


Hi,

just seen that there is more FUD that needs to be adressed:

Am Dienstag, 18. September 2012, 23:15:57 schrieb Rob Nickerson:
> * No variable parts in the key. This is essential as keys are used to
> search for data in the OSM database. If a key comprises a variable part it
> can no longer be retrieved during search unless you know the exact
> condition you are looking for (database searches do not allow wildcards in
> search keys).

This is completely wrong. There is *one* key/value storage called hstore in *one* database called PostgreSQL that doesn't support this inside the data structure, due to the nature of the data structure.
Even then, it is trivially possible to do exactly what has been described: SELECT * FROM each('highway=>primary,maxspeed=>80,maxspeed:wet=>60'::hstore) WHERE key LIKE 'maxspeed%';
Note that this argument is moot anyway; when preprocessing data for routing, you normally deal with the full set of tags outside the database anyway.
If that is still not enough, please do write down the query to pick every aspect of access you need for hgv routing in the Conditional Restrictions proposal (see below).

> Variable parts in keys will also lead to an undesired
> proliferation of unique keys.

This is the only argument that is not completely broken, and it has two sides: the Extended Conditions proposal has a moderate amount of keys and a moderate amount of values. The Conditional Restrictions proposal has a tiny set of keys and an insane amount of values. Do the math.

> * Avoids the requirement for problematic characters in the key such as "<"
> or ">"

Which is a huge problem for data consumers that process XML using regular expressions, and nobody else.

> * Clear distinction between scope (transportation mode, vehicle class) and
> condition.

That distinction is so clear that things already moved between those two sides. (Is "electric" a vehicle class or a condition?)

> * Possibility to combine conditions using operators.

…or more specifically, the AND operator, which has already been a key element in the Extended Conditions proposal.

> * The conditional restriction can be defined as a single tag. Some prior
> proposals required multiple tags such as hour_on and hour_off tags. For
> objects having multiple restrictions this could lead to problems (which
> tags belong to which restriction?)

"single tag" is a slight understatement. Just to get the access for an hgv vehicle in Germany right, you have to consider:
access
access:conditional
access:vehicle
access:vehicle:conditional
access:motor_vehicle
access:motor_vehicle:conditional
access:hgv
access:hgv:conditional

> * Backward compatible. Doesn't break any established tagging schemes.
> //end quote//

I have already shown that this is completely wrong, but just for the record: maxspeed:wet, access:disabled, …

Eckhart



More information about the Tagging mailing list