(Added tagging@osm. Isn't this more of a tagging discussion all-in-all?)
Should both description and note keys be encouraged especially when using
atypical tags/combinations?
-Jaakko
--Original Message--
From: Maarten Deen
To: t...@openstreetmap.org
Subject: Re: [OSM-talk] Tag
Hi everybody,
I want to revive the discussion on how to tag restrictions that depend on
certain conditions. My idea is to finalize the proposal described in
http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags
and finally accept it.
The reasons for picking
Am 13.06.2012 14:35, schrieb Eckhart Wörner:
Hi everybody,
I want to revive the discussion on how to tag restrictions that depend on
certain conditions. My idea is to finalize the proposal described in
http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags
2012/6/13 Eckhart Wörner ewoer...@kde.org:
Competing proposals:
*
http://wiki.openstreetmap.org/wiki/Proposed_features/access_restrictions_1.5
- in my opinion a horrible and incomprehensible syntax with arbitrary
distinctions, taginfo revealed almost no uses (for example,
On 13.06.2012 15:07, Martin Vonwald wrote:
2012/6/13 Eckhart Wörner ewoer...@kde.org:
Competing proposals:
*
http://wiki.openstreetmap.org/wiki/Proposed_features/access_restrictions_1.5
- in my opinion a horrible and incomprehensible syntax with arbitrary
distinctions, taginfo revealed
On 13/06/2012 14:36, David Earl wrote:
http://www.frankieandshadow.com/xref/byway.jpg
BTW, this means I can use this road at all times as a cyclist, even when
the barrier is locked shut, whatever the other restrictions on motor
vehicles are.
___
2012/6/13 Tobias Knerr o...@tobias-knerr.de:
Can you give a concrete example where it is actually more powerful?
For example the self-defined conditions. Not elegant in my opinion,
improvable, but quite nice!
Something that can be expressed with restrictions 1.5, but not with
the extended
Hi David,
Am Mittwoch, 13. Juni 2012, 14:47:09 schrieb aighes:
I think your example: access:weight5.5 = destination should be changed
into something like maxweight:destination=*. This seems to be more
logical and equal to your other examples.
First, I did not write the proposal, someone
2012/6/13 Eckhart Wörner ewoer...@kde.org:
*snip*
access:(weight5.5):destination=yes
*snip*
This is a good example of a bad choice of separators. Because
(weight5.5) and destination are both conditions, but if I don't know
that they are conditions, I have no chance of figuring it out. If you
use
Am 13.06.2012 16:12, schrieb Martin Vonwald:
2012/6/13 Eckhart Wörnerewoer...@kde.org:
*snip*
access:(weight5.5):destination=yes
*snip*
This is a good example of a bad choice of separators. Because
(weight5.5) and destination are both conditions, but if I don't know
that they are conditions,
2012/6/13 aighes o...@aighes.de:
I think maxweight is an already used basekey and maximum weight is also a
part of access. So it should be used like maxspeed, maxheight etc.
+1
instead of access:(weight5.5)=no the established tagging is
maxweight=5.5 or maxweight=5.5t
cheers,
Martin
Hi Martin,
Am Mittwoch, 13. Juni 2012, 15:47:12 schrieb Martin Vonwald:
For example the self-defined conditions. Not elegant in my opinion,
improvable, but quite nice!
The only advantage of self-defined conditions is that you can remove some
redundancy when two tags contain the same subset of
2012/6/13 aighes o...@aighes.de:
For me the system is clear.
basekey:condition_1:condition_2:...:condition_n=value.
How about this:
http://wiki.openstreetmap.org/wiki/Key:parking:lane
The basekey is parking:lane. How do you know that lane is not a condition?
I think maxweight is an already
Am 13.06.2012 16:30, schrieb Martin Vonwald:
2012/6/13 aigheso...@aighes.de:
For me the system is clear.
basekey:condition_1:condition_2:...:condition_n=value.
How about this:
http://wiki.openstreetmap.org/wiki/Key:parking:lane
The basekey is parking:lane. How do you know that lane is not a
2012/6/13 aighes o...@aighes.de:
Am 13.06.2012 16:30, schrieb Martin Vonwald:
2012/6/13 aigheso...@aighes.de:
For me the system is clear.
basekey:condition_1:condition_2:...:condition_n=value.
How about this:
http://wiki.openstreetmap.org/wiki/Key:parking:lane
The basekey is
2012/6/13 Tobias Knerr o...@tobias-knerr.de:
On 13.06.2012 16:12, Martin Vonwald wrote:
If you use a different character (like the ? in the 1.5)
it would be clear where the conditions start.
That's a valid argument, but we need to be aware that there is already a
lot of existing tagging that
Hi Tobias,
Am Mittwoch, 13. Juni 2012, 17:05:34 schrieb Tobias Knerr:
For example, if there is only one lane that changes maxspeed when wet,
one might want to write that as follows:
maxspeed:lanes = 80|80|80
maxspeed:lanes?wet = ||50
I would go even further and mandate that
2012/6/13 Martin Vonwald imagic@gmail.com:
The problem is that you don't have a clear separation between key and
condition. In my opinion it would improve readability for people (not
programs) if we separate those two clearly.
I tend to agree with Tobias here: it is not always clear
Am 13.06.2012 17:07, schrieb Martin Vonwald:
2012/6/13 aigheso...@aighes.de:
Am 13.06.2012 16:30, schrieb Martin Vonwald:
2012/6/13 aigheso...@aighes.de:
For me the system is clear.
basekey:condition_1:condition_2:...:condition_n=value.
How about this:
2012/6/13 aighes o...@aighes.de:
Ok human readability is a good point. But works only til we have a key like
foo?bar=* ;-)
I use this key now for a year or so for various data. I'm writing an
article about it in the next days ;-)
Also a :: would be possible.
Possible: yes. Better?
Think
On 13.06.2012 17:18, Martin Vonwald wrote:
:forward, :backward, ...
I don't think of them as conditions, but more a selection of a part of
a way. Just like :lanes is to me not a condition.
I think we've discussed this several times already, and as you know I do
not think this part of a way
For some reason everyone seems determined to come up with the most
complex system imaginable, instead of taking successful ideas from the
rest of the world. This trait is what causes many projects to fail.
Let's not look at this as simply a discussion about access tags, but
an opportunity to
Am 13.06.2012 um 17:45 schrieb Tobias Knerr o...@tobias-knerr.de:
This means I didn't explain well enough. Let's update the example to
make this more clear:
maxspeed=80
maxspeed:lanes = 60|80|80
maxspeed:lanes?wet = ||50
First step: Evaluate the conditions without regard for the
Am 13.06.2012 um 18:11 schrieb Colin Smale colin.sm...@xs4all.nl:
For some reason everyone seems determined to come up with the most complex
system imaginable,
That's simply because everyone has a solution that is better than all other
solutions ;-)
Let's not look at this as simply a
On 13/06/2012 18:23, Eckhart Wörner wrote:
Hi Colin,
Am Mittwoch, 13. Juni 2012, 18:11:53 schrieb Colin Smale:
For some reason everyone seems determined to come up with the most
complex system imaginable, instead of taking successful ideas from the
rest of the world. This trait is what causes
On 13.06.2012 23:48, Colin Smale wrote:
Taking the access discussion to a higher
level of abstraction, and without abandoning the key-value pair
paradigm, I believe we are looking for a way of giving a tag a value
which depends on all kinds of variables. *IMHO* we need a way of
making
26 matches
Mail list logo
