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
Message: 4
Date: Thu, 14 Jun 2012 16:45:28 +0200
From: Martin Koppenhoefer dieterdre...@gmail.com
To: Tag discussion, strategy and related tools
tagging@openstreetmap.org
Subject: [Tagging] access agricultural, WAS Re: Reviving the
conditions debate
Message-ID:
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
Am Freitag, 15. Juni 2012, 09:32:11 schrieb Flaimo:
very easy. use the 1.5 proposal :-). for germany you could use
access:motorizedagricultural=yes. in developing countries, where
motor vehicles are not common for most people, you could just use the
role: access:agricultural=yes. That is 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
16 matches
Mail list logo
