Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"
Hi Rob, Am Mittwoch, 19. September 2012, 20:10:45 schrieb Rob Nickerson: > Am Mittwoch, 19. September 2012, 18:08:30 schrieb Rob Nickerson: > >* Despite some of the perceived benefits of this proposal being > >challenged*>* (mainly in regards to their relevance),* > Except for one claimed benefit, I did not question the relevance of > the claims, but their validity. Maybe you should read mails before > summarizing them? > -- End -- > > Please accept my apologies that my English was not clear. I did read > your mails and my wording should be seen as it was intended - that is, > the perceived benefits may not be "relevant" due to the "invalidity" > of the thing they are trying to fix. I will try to be more exact next > time. I apologize for being a bit harsh on my response. My intention was not to be picky about the language, just to note that there is an important distinction. "Invalidity" is something that can normally verified/falsified, "relevance" lies in the eye of the viewer. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"
-- Eckhart wrote -- Hi Rob, Am Mittwoch, 19. September 2012, 18:08:30 schrieb Rob Nickerson: >* Despite some of the perceived benefits of this proposal being challenged*>* >(mainly in regards to their relevance),* Except for one claimed benefit, I did not question the relevance of the claims, but their validity. Maybe you should read mails before summarizing them? -- End -- Hi Eckhart, Please accept my apologies that my English was not clear. I did read your mails and my wording should be seen as it was intended - that is, the perceived benefits may not be "relevant" due to the "invalidity" of the thing they are trying to fix. I will try to be more exact next time. Kindest regards, Rob ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"
Hi Rob, Am Mittwoch, 19. September 2012, 18:08:30 schrieb Rob Nickerson: > Despite some of the perceived benefits of this proposal being challenged > (mainly in regards to their relevance), Except for one claimed benefit, I did not question the relevance of the claims, but their validity. Maybe you should read mails before summarizing them? > There will never be a 100% perfect solution (which is no argument for adopting inferior solutions) > due to the fact that, in the > absence of a tag scheme, many alternate tags have crept into use. However, some proposals actually manage to embrace and extend existing tagging. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"
Hi All, Despite some of the perceived benefits of this proposal being challenged (mainly in regards to their relevance), the overwhelming thing that was clear was that this proposal was well thought out. Ole looked carefully at the feedback that was given during previous proposals and worked to find solutions for many of them. There will never be a 100% perfect solution due to the fact that, in the absence of a tag scheme, many alternate tags have crept into use. Despite this I feel it is important to push ahead with a conditional restrictions tagging scheme as it provides some form of standardisation and therefore simplifies the task of downstream users (which ultimately will lead to more use of OSM's fantastic data). To put this into some context, recall that there was a discussion recently (on talk list I think), where it was made clear that the German auto industry had asked OSM how we intend to "close the gap" between us and commercial navigation. As noted by Andy, I do however agree that this proposal (like many others) could slip under the radar of many people. Due to it's potential reach, I would have liked to have seen something posted to the Developer mailing list during the Draft & RFC stages. Kind Regards, Rob p.s. I know voting isn't popular, but it is one part of communications (i.e. giving feedback) and I encourage you to reconsider it if you have so far opted not to vote. http://wiki.openstreetmap.org/wiki/Proposed_features/Conditional_restrictions ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"
Hi Ronnie, Am Mittwoch, 19. September 2012, 16:17:07 schrieb Ronnie Soak: > I've added a column for the Extended Conditions scheme to the examples > table on the discussion page of the Conditional Restriction > scheme. [1] > > (Why doesn't have the Extended Conditions scheme it's own examples?) It does: http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags#Examples (without pictures, though) > Would you please help me fill in the blanks? You seem more experienced > in this scheme than me. > (Although that would make me more suited as a test candidate.) Will have a look at it later. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"
I'm sorry. Here it is again in English: Eckhart, I've added a column for the Extended Conditions scheme to the examples table on the discussion page of the Conditional Restriction scheme. [1] (Why doesn't have the Extended Conditions scheme it's own examples?) Would you please help me fill in the blanks? You seem more experienced in this scheme than me. (Although that would make me more suited as a test candidate.) All others are invited too, of course. Regards, > > Chaos > > > [1] > http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Conditional_restrictions#Pictorial_examples ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"
Eckhart, Ich habe gerade eine Spalte für das Extended Conditions Schema zur Beispieltabelle auf der Diskussionsseite des Conditional Restriction Schemas hinzugefügt. [1] (Warum hat das Extended Conditions Schema eigentlich keine Beispiele?) Würdest du mir helfen die Lücken zu füllen? Du scheinst mehr Erfahrung damit zu haben als ich. (Obwohl mich das zum besseren Versuchskaninchen macht ..) Andere dürfen natürlich auch ... Gruß, Chaos [1] http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Conditional_restrictions#Pictorial_examples ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"
On 19.09.2012 14:44, SomeoneElse wrote: > What attempt has been made to get editor support for this "proposal"? Tagging ideas are often documented (as a proposal or elsewhere) first, then actually used in the database, and only then added to editors. At this point, a JOSM/Potlatch patch would probably be rejected because this tagging style has yet to prove itself in the database. Tobias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"
Hi Ilpo, Am Mittwoch, 19. September 2012, 15:45:44 schrieb Ilpo Järvinen: > > > Variable parts in keys will also lead to an undesired > > > proliferation of unique keys. > > > > This is the only argument that is not completely broken, and it has two > > sides: the Extended Conditions proposal has a moderate amount of keys > > and a moderate amount of values. The Conditional Restrictions proposal > > has a tiny set of keys and an insane amount of values. Do the math. > > With this proposal I can still pick the key I'm interested in from > rather small set of keys. Ignoring compatibility keys, we are already talking about ~150 keys for any base key. That's not something you want to pick from a list. > And I know what I'm talking here... Somebody > around here has been doing some traffic volume counting and now all those > different times put into the keys basically occupy most of the key space > already (in fact e.g. ITO won't even show all keys anymore because they're > so many which would obviously be fixable in that particular case as long > as the browsers can handle such insanely long lists but still highlights > my point about key space explosion beyond what was considered "sensible" > upper limit by somebody). Which "ITO" tool is that? > I don't find it useful to have a semi-large key > and semi-large value space instead of sensibly small key space and > insanely diverse value space per key. I can only image what your proposal > would cause when all those different times would be put to all keys > instead of just one. And what *can* you imagine? The only negative effect you have brought up so far is that it is not possible to list all keys on one page anymore (which has been impossible for quite some time). Also, existing tagging practise tells us that with the Extended Conditions proposal, keys tend to cluster (e.g. maxspeed:(22:00-06:00) has been used 416 times all over Germany), while with the Conditional Restrictions proposal, clustering in values rarely happens. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"
Hi Ilpo, Am Mittwoch, 19. September 2012, 15:45:44 schrieb Ilpo Järvinen: > > > * Avoids the requirement for problematic characters in the key such as "<" > > > or ">" > > > > Which is a huge problem for data consumers that process XML using > > regular expressions, and nobody else. > > This is a false claim. I've seen e.g. misdecoded ampersand just too many > times here and there. Example? I have yet to encounter a single OSM tool that does not handle XML correctly. > And I doubt that such services had anything to > do with regexp. XML is a format explicitly designed for exchange of *arbitrary* data, and libraries that manipulate XML documents go to great effort to ensure stuff like character entities are handled correctly. The only reason why such errors happen is because some idiots believe that they can handle XML in five lines of code, which normally involves some "clever" regexp'ing. Apart from that, the argument is flawed anyway because both key and value end up as attributes in the XML, and the Conditional Restrictions proposal has "<" in its values. > > > * Possibility to combine conditions using operators. > > > > or more specifically, the AND operator, which has already been a key > > element in the Extended Conditions proposal. > > Now you're arguing bothways. Extented conditions wanted to get rid of > such operator and use multiple keys instead of an operator. The use of a > _real_ operator prevents the key space explosion which you hold so dear, > so no, extented conditions does not have operators in the same sense this > proposal has. Extended Conditions does not have an *explicit* AND operator, however, there is an *implicit* AND written as ":". maxspeed:hgv:(22:00-06:00):forward is the maxspeed that applies if you are in an hgv *and* the time is between 22:00 and 06:00 *and* the relative direction is forward. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"
On Wed, 19 Sep 2012, Eckhart Wörner wrote: > Am Dienstag, 18. September 2012, 23:15:57 schrieb Rob Nickerson: > > Variable parts in keys will also lead to an undesired > > proliferation of unique keys. > > This is the only argument that is not completely broken, and it has two > sides: the Extended Conditions proposal has a moderate amount of keys > and a moderate amount of values. The Conditional Restrictions proposal > has a tiny set of keys and an insane amount of values. Do the math. With this proposal I can still pick the key I'm interested in from rather small set of keys. And I know what I'm talking here... Somebody around here has been doing some traffic volume counting and now all those different times put into the keys basically occupy most of the key space already (in fact e.g. ITO won't even show all keys anymore because they're so many which would obviously be fixable in that particular case as long as the browsers can handle such insanely long lists but still highlights my point about key space explosion beyond what was considered "sensible" upper limit by somebody). I don't find it useful to have a semi-large key and semi-large value space instead of sensibly small key space and insanely diverse value space per key. I can only image what your proposal would cause when all those different times would be put to all keys instead of just one. > > * Avoids the requirement for problematic characters in the key such as "<" > > or ">" > > Which is a huge problem for data consumers that process XML using > regular expressions, and nobody else. This is a false claim. I've seen e.g. misdecoded ampersand just too many times here and there. And I doubt that such services had anything to do with regexp. > > * Possibility to combine conditions using operators. > > or more specifically, the AND operator, which has already been a key > element in the Extended Conditions proposal. Now you're arguing bothways. Extented conditions wanted to get rid of such operator and use multiple keys instead of an operator. The use of a _real_ operator prevents the key space explosion which you hold so dear, so no, extented conditions does not have operators in the same sense this proposal has. -- i.___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"
To echo Sir Humphrey*, my first reaction was "beautifully typed". My second reaction was as follows: What attempt has been made to get editor support for this "proposal"? Without it no-one, apart from the dwindling proportion voting on the wiki, will ever even have heard of it. Without editor support even people looking at the wiki page won't be able to understand what they're supposed to do (for example, the "Tagging" section appears to contradict the "Examples" section). Presumably the submitter of this proposal is already working on a patch for Potlatch and a JOSM plugin? Cheers, Andy * http://books.google.co.uk/books?id=qPxeFwAk9T8C&pg=PA382&lpg=PA382&dq=%22beautifully+typed%22+%22sir+humphrey%22&source=bl&ots=HB0DwsugrB&sig=TZUnIzVTIfG0G7TwxGsxjdkl4qU&hl=en ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"
Hi David, Am Mittwoch, 19. September 2012, 08:26:07 schrieb David ``Smith'': > Wouldn't that be... > access > access:conditional > vehicle > vehicle:conditional > motor_vehicle > motor_vehicle:conditional > hgv > hgv:conditional > ...? Actually, no. To quote: "For access restrictions it is *allowed* to use the abbreviated form by omitting access: in front of the category." The list would therefore look like: access access:conditional access:vehicle access:vehicle:conditional vehicle vehicle:conditional access:motor_vehicle access:motor_vehicle:conditional motor_vehicle motor_vehicle:conditional access:hgv access:hgv:conditional hgv hgv:conditional However, since *both* the Conditional Restrictions and the Extended Conditions proposal have this kind of shortening for backward compatibility, I deliberately omitted these tags. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"
On Sep 19, 2012 5:09 AM, "Eckhart Wörner" wrote: > "single tag" is a slight understatement. Just to get the access for an hgv vehicle in Germany right, you have to consider: > access > access:conditional > access:vehicle > access:vehicle:conditional > access:motor_vehicle > access:motor_vehicle:conditional > access:hgv > access:hgv:conditional Wouldn't that be... access access:conditional vehicle vehicle:conditional motor_vehicle motor_vehicle:conditional hgv hgv:conditional ...? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"
Hi,
just seen that there is more FUD that needs to be adressed:
Am Dienstag, 18. September 2012, 23:15:57 schrieb Rob Nickerson:
> * No variable parts in the key. This is essential as keys are used to
> search for data in the OSM database. If a key comprises a variable part it
> can no longer be retrieved during search unless you know the exact
> condition you are looking for (database searches do not allow wildcards in
> search keys).
This is completely wrong. There is *one* key/value storage called hstore in
*one* database called PostgreSQL that doesn't support this inside the data
structure, due to the nature of the data structure.
Even then, it is trivially possible to do exactly what has been described:
SELECT * FROM each('highway=>primary,maxspeed=>80,maxspeed:wet=>60'::hstore)
WHERE key LIKE 'maxspeed%';
Note that this argument is moot anyway; when preprocessing data for routing,
you normally deal with the full set of tags outside the database anyway.
If that is still not enough, please do write down the query to pick every
aspect of access you need for hgv routing in the Conditional Restrictions
proposal (see below).
> Variable parts in keys will also lead to an undesired
> proliferation of unique keys.
This is the only argument that is not completely broken, and it has two sides:
the Extended Conditions proposal has a moderate amount of keys and a moderate
amount of values. The Conditional Restrictions proposal has a tiny set of keys
and an insane amount of values. Do the math.
> * Avoids the requirement for problematic characters in the key such as "<"
> or ">"
Which is a huge problem for data consumers that process XML using regular
expressions, and nobody else.
> * Clear distinction between scope (transportation mode, vehicle class) and
> condition.
That distinction is so clear that things already moved between those two sides.
(Is "electric" a vehicle class or a condition?)
> * Possibility to combine conditions using operators.
…or more specifically, the AND operator, which has already been a key element
in the Extended Conditions proposal.
> * The conditional restriction can be defined as a single tag. Some prior
> proposals required multiple tags such as hour_on and hour_off tags. For
> objects having multiple restrictions this could lead to problems (which
> tags belong to which restriction?)
"single tag" is a slight understatement. Just to get the access for an hgv
vehicle in Germany right, you have to consider:
access
access:conditional
access:vehicle
access:vehicle:conditional
access:motor_vehicle
access:motor_vehicle:conditional
access:hgv
access:hgv:conditional
> * Backward compatible. Doesn't break any established tagging schemes.
> //end quote//
I have already shown that this is completely wrong, but just for the record:
maxspeed:wet, access:disabled, …
Eckhart
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"
Dear List,
{This is a cross post - please reply to the tagging mailing list or the
proposals [2] talk page }
- - - Announcement - - -
Several attempts have in the past been made to develop a tagging scheme
that is capable of handling the more complex access restrictions (e.g. No
motor vehicles between 10am and 6pm except vehicles less than 5 meters
[1]). Voting has started on the latest proposal [2]. Due to the wide reach
of this proposal, I am announcing it here and encouraging users to
carefully consider the proposal and vote.
To help, I have summarised the alternate proposals (in alphabetic order and
including this one) [3]. Note that not all of these are in active
development. I have also attempted to write the case for and case against
this proposal.
As a reminder of terminology, a Tag consists of 'Key' and a 'Value' pair
(key=value). For example "maxspeed=80".
- - - Case "For" - - -
Extract by the proposal author from the proposal's wiki page [2]:
//start quote// This proposal overcomes some objections to previous
attempts at tagging conditional restrictions.
* No variable parts in the key. This is essential as keys are used to
search for data in the OSM database. If a key comprises a variable part it
can no longer be retrieved during search unless you know the exact
condition you are looking for (database searches do not allow wildcards in
search keys). Variable parts in keys will also lead to an undesired
proliferation of unique keys.
* Avoids the requirement for problematic characters in the key such as "<"
or ">"
* Clear distinction between scope (transportation mode, vehicle class) and
condition.
* Possibility to combine conditions using operators.
* The conditional restriction can be defined as a single tag. Some prior
proposals required multiple tags such as hour_on and hour_off tags. For
objects having multiple restrictions this could lead to problems (which
tags belong to which restriction?)
* The syntax of the key is essentially identical to the established access
key syntax with an additional qualifier ":conditional".
* Backward compatible. Doesn't break any established tagging schemes.
//end quote//
- - - Case "Against" - - -
Extracts from those who have currently (18/09/2012) voted against the
proposal:
//start quotes//
* Breaks a lot of tags which came "natural" to the mappers, e.g.
maxspeed:wet=80 becomes maxspeed:conditional=80 @ wet, access:disabled=yes
becomes access:conditional=yes @ disabled, …
* Creates arbitrary distinctions: depending on whether something is defined
to be a transportation mode or a condition, it belongs either in the key or
in the value, e.g. "hgv" is a transportation mode, but "hazmat" is a
condition
* Has bad editor support: adding a conditional restriction like "speed
limited to 80 when wet" to a set of ways is quite complicated if there are
already different restrictions on those ways; merging :conditional tags in
JOSM by default produces a value that is completely wrong, yet cannot be
identified as wrong.
* It's to difficult for users, not intuitive. There are too many subkeys
and subvalues. I think value with logic instruction (AND) (and maybe
special/new signs (@)) are not good tagging rules.
//end quotes//
- - - How to Vote - - -
0. Take a moment to conside the pros/cons and their relative importance /
how would you do it differently?
1. Log-in to OSM wiki (as far as I know this is not your usual OSM
username/password.
2. Navigate to the proposal page [2]
3. Click edit (to the right of the "Voting" heading
4. Add "{{vote|yes}} --" or "{{vote|no}} --" after the existing
votes.
Kind Regards,
RobJN
[1] Example Signpost:
http://wiki.openstreetmap.org/wiki/File:Length_and_time_restriction_2.jpg
[2] The Proposal:
http://wiki.openstreetmap.org/wiki/Proposed_features/Conditional_restrictions
[3] Summary of alternate proposals:
http://wiki.openstreetmap.org/wiki/Proposed_features/Advanced_access_tags
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
