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 a
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
Let's take a step back and look at what the discussions in this thread
have actually been about.
There's a lot of discussions about possible solutions, without much
analysis of "the problem". Taking the access discussion to a higher
level of abstraction, and without abandoning the key-value pa
Am 13.06.2012 um 20:47 schrieb Colin Smale :
>> my sarcasm detection seems to be broken - are you seriously suggesting
>> JavaScript or XML? Or are you suggesting that the proposal is too complex?
>>
> Yes, yes, and yes.
Is your first yes referring to JavaScript or the sarcasmus detector?
No,
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 m
Hi Pieren,
Am Mittwoch, 13. Juni 2012, 18:42:54 schrieb Pieren:
> > negative aspect ... the proposal puts a lot of information into keys and
> > theoretically allows for an unlimited set of keys
> +1
> But this could be fixed by moving all variables into the value part
> (syntax to be defined)
T
On Wed, Jun 13, 2012 at 2:35 PM, Eckhart Wörner wrote:
> The reasons for picking this proposal:
> ... already used...intuitive and simple to
> use...complete...consise...extensible
+1
> negative aspect ... the proposal puts a lot of information into keys and
> theoretically allows for an unlim
Am 13.06.2012 um 18:23 schrieb Eckhart Wörner :
>> Why not use a javascript-compatible syntax?
>> Or a bit of XML? No point in re-inventing the wheel.
>
> my sarcasm detection seems to be broken - are you seriously suggesting
> JavaScript or XML? Or are you suggesting that the proposal is too c
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 many projects to fail.
> Let's not loo
Am 13.06.2012 um 18:11 schrieb Colin Smale :
> 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 discussion about "acces
Am 13.06.2012 um 17:45 schrieb Tobias Knerr :
> 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 semantics of
> the r
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
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
2012/6/13 aighes :
> 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 of a:b:c:d=
Am 13.06.2012 17:07, schrieb Martin Vonwald:
2012/6/13 aighes:
Am 13.06.2012 16:30, schrieb Martin Vonwald:
2012/6/13 aighes:
For me the system is clear.
:::...:=.
How about this:
http://wiki.openstreetmap.org/wiki/Key:parking:lane
The basekey is parking:lane. How do you know that lane is n
2012/6/13 Martin Vonwald :
> 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 whether it is
a conditi
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 lane-indepe
2012/6/13 Tobias Knerr :
> 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 uses a colon
2012/6/13 aighes :
> Am 13.06.2012 16:30, schrieb Martin Vonwald:
>
>> 2012/6/13 aighes:
>>>
>>> For me the system is clear.
>>> :::...:=.
>>
>> 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?
>
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 uses a colon as the condition separator.
These
Am 13.06.2012 16:30, schrieb Martin Vonwald:
2012/6/13 aighes:
For me the system is clear.
:::...:=.
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?
Yes...but there is the problem? If you search for
2012/6/13 aighes :
> For me the system is clear.
> :::...:=.
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 used basekey and maximum weight is also a
> part of acces
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 o
2012/6/13 aighes :
> 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:(weight>5.5)=no the established tagging is
maxweight=5.5 or maxweight=5.5t
cheers,
Martin
Am 13.06.2012 16:12, schrieb Martin Vonwald:
2012/6/13 Eckhart Wörner:
*snip*
access:(weight>5.5):destination=yes
*snip*
This is a good example of a bad choice of separators. Because
(weight>5.5) and destination are both conditions, but if I don't know
that they are conditions, I have no chanc
2012/6/13 Eckhart Wörner :
*snip*
> access:(weight>5.5):destination=yes
*snip*
This is a good example of a bad choice of separators. Because
(weight>5.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 a different c
Hi David,
Am Mittwoch, 13. Juni 2012, 14:47:09 schrieb aighes:
> I think your example: access:weight>5.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 Tobias Knerr :
> 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 conditions" syntax
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.
___
On 13.06.2012 15:07, Martin Vonwald wrote:
> 2012/6/13 Eckhart Wörner :
>> 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 n
2012/6/13 Eckhart Wörner :
> 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,
> "maxspeed:hgv:wet" in the
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
an
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 t
(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 combinat
34 matches
Mail list logo
