Am 15.06.2012 16:29, schrieb Eckhart Wörner:
Hi Peter,
Am Donnerstag, 14. Juni 2012, 13:10:44 schrieb Peter Wendorff:
A key access:weight is okay IMHO and can contain weight-related access
restrictions.
access:length, access:time and so on - okay.
but the specific weight a restriction belongs to should be part of the
value, not the key.
The problem is that different restrictions combine different conditions that
may exist more than once. E.g. there are roads where access restrictions depend
on several different weights, different times, and any combinations of them.
access:length, access:time, … is by no means sufficient.
Why is it a problem?
If - as some of you here discuss currently - introduce a really complex
grammar for access values nevertheless, why not doing it a little bit
more complex to put everything in one tag?
If it's already hard to understand as
complicated:tag:with:conditions:and:whatever=complicated:value, then why
not doing a simplekey=set:of:complicated:conditions:values?
The opening hours key IMHO is manageable by humans for the "usual" case.
It get's difficult already when dealing with seasons (summer different
from winter, holidays, days before holidays and so on), I fear, too
difficult for some people - but well, let's accept that.
At least it's one tag, and a mapper may decide not to touch that one tag.
To introduce variable tags is worse:
* For mappers the attribute list get's long, and I have to ignore more
tags than before.
* For common data usage applications like osm2pgsql, osmosis and so on
filtering has to be done on substring operations on keys - much more
complex than on whole keys only, to deal with exceptions; while a value
is a simple string that can (for the first run) simply be copied.
* Tags relying on each other (as proposed somewhere in this thread as a
matter of "use other tags as variables") is error prone
* Software that put's different attributes into different columns of a
table (like, but not restricted to mapnik) for easier search and index
functionality has to introduce more - and even worse: variable table
columns to support this tagging scheme. On the other hand one tag with a
incredible complex value grammer could be used simply by copy and paste,
and, if necessary, interpreted and processed to fill different columns
or even tables by that interpretation step (e.g. a timetable for opening
hours or sth. like that).
To conclude: I really don't see any benefit in creating variable keys
over creating fixed keys with a variable, slightly more complex
(compared to the already complex one) value scheme.
regards
Peter
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
