Has this discussion died now and awaits re-revival in another two,
three years? ;-)
Martin
2012/6/15 Eckhart Wörner ewoer...@kde.org:
Hi everybody,
let me try to summarize some parts of the discussion up to now. Hopefully
this won't become too biased:
* most people agreed that the syntax
Colin,
Martin, if it walks like a duck and quacks like a duck, then it had
better be a duck... What I mean with this, is if the grammar is so
English-like such that people are tempted to use constructions which are
not (or not quite) supported by the grammar, or if the way it works is
contrary
motor_vehicle:forward:(Mo-Fr 16:00-18:00) = agricultural
goods:forward:(Mo-Fr 16:00-18:00) = yes
motor_vehicle:backward:(Mo-Fr 16:00-18:00) = agricultural
goods:backward:(Mo-Fr 06:00-09:00) = yes
This is the point where I think it would be worth to start prefixing the
expression by access (I
* some people argued that conditions syntax should look similar to
human language, however, other people argued that this would trick
mappers into thinking that human language can be used without paying
attention to syntax, and others pointed out that that a parser that has
to be liberal about
Hi Eckhart,
On 15/06/2012 01:08, Eckhart Wörner wrote:
Hi Colin,
Am Freitag, 15. Juni 2012, 00:24:18 schrieb Colin Smale:
If I were king I would be looking for a system that:
* makes common cases easy
Extended conditions: ☑
* makes complex cases possible
Extended conditions: ☑
* makes
On 2012-06-15 09:07, Colin Smale wrote:
The bulk of the discussion up to now has been about access type tags,
producing a boolean value: can I or can't I use this road under the
given conditions. Why limit it to boolean? Why not address the use case
of what is the maximum speed for vehicle X
as the one who drafted Extended conditions I would like to make some
comments. The proposal should not compete with Access restriction 1.5 (or
similar proposals). My proposal aims to consolidate and unify existing tags
instead of proposing a complete new way of tagging -see the one example at
the
Hi Pieren,
Am Donnerstag, 14. Juni 2012, 12:10:49 schrieb Pieren:
condition1=wet
maxspeed:lgv=120 or 80 in condition1
I read this as if condition1 applies, the maxspeed is 120 or 80 - I'm pretty
sure this is not what you wanted to express.
If we consider that a special parser is required as
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
Hi Thomas,
Am Freitag, 15. Juni 2012, 02:03:31 schrieb ThomasB:
as the one who drafted Extended conditions I would like to make some
comments. The proposal should not compete with Access restriction 1.5 (or
similar proposals). My proposal aims to consolidate and unify existing tags
instead of
Hi everybody,
let me try to summarize some parts of the discussion up to now. Hopefully this
won't become too biased:
* most people agreed that the syntax of the competing Access Restrictions 1.5
proposal is quite complicated
* some people argued that it is important to separate syntax for
(Sorry for a possible double-post, this message I sent earlier today
(7:52:26 UTC) hasn't yet appeared for some reason.)
On 2012-06-15 09:07, Colin Smale wrote:
The bulk of the discussion up to now has been about access type tags,
producing a boolean value: can I or can't I use this road under
+1 to the summary and especially to:
Am 15.06.2012 um 16:41 schrieb Eckhart Wörner ewoer...@kde.org:
I would also like to ask people not to blindly start new proposals, because
otherwise we'll inevitably end up with hundreds of proposals and no
conclusion at all.
I would even prefer to have
2012/6/15 Eckhart Wörner ewoer...@kde.org:
What would your parser do to existing tagging like
name = Ministere a la condition femininne
- decide that femininne is an unknown condition and therefore
name = Ministere a la
does not apply?
well, it would probably not parse names at all, so
Hi Martin,
Am Freitag, 15. Juni 2012, 20:35:39 schrieb Martin Koppenhoefer:
2012/6/15 Eckhart Wörner ewoer...@kde.org:
What would your parser do to existing tagging like
name = Ministere a la condition femininne
- decide that femininne is an unknown condition and therefore
name =
Am 15.06.2012 00:51, schrieb Eckhart Wörner:
Hi martinq,
Am Donnerstag, 14. Juni 2012, 22:19:06 schrieb martinq:
and many other variants. It is almost impossible to tag it wrong.
I'm sorry, but every time I've heard a statement similar to you cannot get it wrong it
just boiled down to the
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
On 15.06.2012 23:38, Peter Wendorff wrote:
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.
There's one immediate problem: The 255 character limit for
Tobias, thanks for your constructive response.
On 14/06/2012 03:22, Tobias Knerr wrote:
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
Hi!
Maybe someone can help me defining the following access restriction
using the 1.5 proposal:
http://wiki.openstreetmap.org/wiki/File:Length_and_time_restriction_2.jpg
Right now I'm pretty lost. :-(
Martin
___
Tagging mailing list
I think I found a solution using a self-defined rule:
access:motor_vehicle!rule.time=10:00-18:00
access:motor_vehicle!rule.width=5+
access:motor_vehicle?rule=no
Can this be simplified somehow (using the 1.5 proposal)?
2012/6/14 Martin Vonwald imagic@gmail.com:
Hi!
Maybe someone can
2012 08:38:52 +0200
From: Colin Smale colin.sm...@xs4all.nl
To: tagging@openstreetmap.org
Subject: Re: [Tagging] Reviving the conditions debate
Message-ID: 4fd986fc.5070...@xs4all.nl
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Here's a test case. No motor vehicles mon-fri
: [Tagging] Reviving the conditions debate
Message-ID: 4fd986fc.5070...@xs4all.nl
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Here's a test case. No motor vehicles mon-fri between 1600-1800 except
agricultural vehicles and good vehicles *in this direction*. Going the
other way
On Thu, Jun 14, 2012 at 8:38 AM, Colin Smale colin.sm...@xs4all.nl wrote:
Back to my idea to move all 'variables' to the value :
Let say we create a new access keyword : condition (or
access_condition, cond, expr or whatever_you_like) suffixed by
a number, eg. condition1, condition2, etc
Yes, short and readable (IMO), but how would you express a conditional maxspeed?
I suggested something similar some time ago, but people didnt seem to
be very happy with it. It was something like:
condition:name=expression
anykey:conditional(name)=value
The obvious drawback is, that you always
I created a (still very small) table showing some examples for both
proposals: http://wiki.openstreetmap.org/wiki/User:Imagic/Werkstatt2
If you have any signposts or can provide a currently missing solution
please feel free to update this page or send me the link to the
signpost/a description and
On Thu, Jun 14, 2012 at 11:44 AM, Martin Vonwald imagic@gmail.com wrote:
Yes, short and readable (IMO), but how would you express a conditional
maxspeed?
You mean:
access:lgv.speed=120
access:lgv?wet.speed=80
condition1=wet
maxspeed:lgv=120 or 80 in condition1
If we consider that a
On 14/06/2012 11:19, Pieren wrote:
On Thu, Jun 14, 2012 at 8:38 AM, Colin Smale colin.sm...@xs4all.nl wrote:
Back to my idea to move all 'variables' to the value :
Let say we create a new access keyword : condition (or
access_condition, cond, expr or whatever_you_like) suffixed by
a number, eg.
Message: 2
Date: Thu, 14 Jun 2012 10:31:17 +0200
From: Martin Vonwald imagic@gmail.com
To: Tag discussion, strategy and related tools
tagging@openstreetmap.org
Subject: Re: [Tagging] Reviving the conditions debate
Message-ID
2012/6/14 Flaimo fla...@gmail.com:
Maybe someone can help me defining the following access restriction
using the 1.5 proposal:
http://wiki.openstreetmap.org/wiki/File:Length_and_time_restriction_2.jpg
alternate version:
access:motorized.time=Mo-Su 00:00-10:00,18:00-24:00
On 14.06.2012 08:38, Colin Smale wrote:
My concern with this is that it may become unwieldy and cumbersome with
anything beyond fairly trivial cases such as your maxspeed example.
For me, the goal is to make the common cases *easy*, and the rare
complex cases *possible*.
For the human
Hi.
I'm a little bit afraid about the discussion here and would like to
point out that a key IMHO should be different than a value.
I like the idea of namespaces for keys, to be able to group tags that
belong together, but I think, even namespaced stuff should belong keylike.
A key
On 14/06/2012 12:53, Flaimo wrote:
this notation has the same flaw as the current access scheme. it mixes
transportation modes and user roles. motor_vehicle is a
transportation mode. agricultural is a user role. not everywhere on
this planet agricultural automatically means motor_vehicle. that
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
On 14/06/2012 13:00, Tobias Knerr wrote:
On 14.06.2012 08:38, Colin Smale wrote:
My concern with this is that it may become unwieldy and cumbersome with
anything beyond fairly trivial cases such as your maxspeed example.
For me, the goal is to make the common cases *easy*, and the rare
complex
On 14.06.2012 13:30, Colin Smale wrote:
motor_vehicle:forward:(Mo-Fr 16:00-18:00) = agricultural
At first glance this looks like a motor vehicle going forward between
those times is considered agricultural. It doesn't feel very
intuitive, based on the established key=value paradigm.
Putting a
2012/6/14 Colin Smale colin.sm...@xs4all.nl:
each jurisdiction. I don't expect there to be total agreement about
agricultural either. There are signs for no agricultural vehicles, which
in my experience refer to the type of vehicle and not what it is being used
for at that moment. But this
The other usage of the term agricultural is the type of vehicle.
In the UK agricultural vehicles are prohibited on motorways due to their slow
speeds. But a farmer could use his Land Rover on a motorway as it is a car
being used for agriculture.
Phil
--
Sent from my Nokia N9
On 14/06/2012
Martin, if it walks like a duck and quacks like a duck, then it had
better be a duck... What I mean with this, is if the grammar is so
English-like such that people are tempted to use constructions which are
not (or not quite) supported by the grammar, or if the way it works is
contrary to how
Hi martinq,
Am Donnerstag, 14. Juni 2012, 22:19:06 schrieb martinq:
and many other variants. It is almost impossible to tag it wrong.
I'm sorry, but every time I've heard a statement similar to you cannot get it
wrong it just boiled down to the computer cannot tell you that it's wrong.
This
Hi Colin,
Am Freitag, 15. Juni 2012, 00:24:18 schrieb Colin Smale:
If I were king I would be looking for a system that:
* makes common cases easy
Extended conditions: ☑
* makes complex cases possible
Extended conditions: ☑
* makes each rule as standalone as possible (one sign - one rule)
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
66 matches
Mail list logo
