Re: [Tagging] opening-hours off closed
Hi André, Am Samstag, 30. November 2013, 02:06:36 schrieb André Pirard: You wrote that off must not be defined but grasped and it really looks so. You keep using the word wrong instead of showing what is right. I told you both how off has to be interpreted and the reason why it has to be interpreted that way in a previous mail already. Unfortunately I cannot tell you what is right, only what I perceive to be right. - open and closed appear to be some new invention You'd better explain this: times_for_days *24/7* → open *open* [ comment ] *closed* [ comment ]→ closed day_list *off* → closed You do realize that you took this from a page which states: This specification corresponds […] to opening_hours.js. - daily, weekly, monthly don't exist in that form. It is perfectly valid to combine them, e.g. Apr-Oct Mo-Fr 07:00-20:00 That isn't causing tagging mistakes as you suggest below. You are right, this one does not cause tagging mistakes, I merely listed it for completeness. My goal was to untangle all that for the users and they seem to like it. They like it and they tag it the wrong way don't exclude each other. The best way to make what you mean understood is to write the correct diagram line and change it. http://wiki.openstreetmap.org/wiki/Proposed_features/Time_domains […] one can expect two outcomes: (1) someone might correct the mistake (2) people start tagging the wrong way In the last two months, only (2) happened. (3) people applauded the gift and thanked for having found something more comprehensible Again, (2) and (3) don't exclude each other. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] opening-hours off closed
Hi André, Am Donnerstag, 28. November 2013, 16:15:39 schrieb André Pirard: So, I thought that this fuzzy matter had to be be solved by writing a simple syntax diagram. Should anything be wrong in it, someone would put it right and it would be a good job jobbed and a big step forward. If you add wrong information in the most prominent spot in a very popular article, one can expect two outcomes: (1) someone might correct the mistake (2) people start tagging the wrong way In the last two months, only (2) happened. And now, probably in thanks for my contribution, my diagram was adorned with this: Warning http://wiki.osm.org/wiki/File:Ambox_warning_pn.svg The syntax diagram below had no proper discussion and vote, and conflicts with established tagging. *Don't use it!* Yes, that was me, in reaction to (2). It is obviously something very difficult to understand that a diagram translating an article needs no discussion nor vote but needs to be corrected to align with the obscure explanations by their gurus. Else, it's the article itself that suffers from lack of discussion and vote. That remark still doesn't say what's wrong in the diagram. Okay, here is a (probably incomplete) list: - open and closed appear to be some new invention - the meaning of off is wrong - daily, weekly, monthly don't exist in that form. It is perfectly valid to combine them, e.g. Apr-Oct Mo-Fr 07:00-20:00 I know that the diagram is wrong […] …and you don't mind that mappers follow the wrong diagram? Eckhart ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] opening-hours: how to code always but...? Syntax diagram.
Hi André, Am Sonntag, 20. Oktober 2013, 19:19:35 schrieb André Pirard: […loads of quoted text…] please do not quote an entire conversation on top of your reply, otherwise people have a hard time finding your actual reply. No, that is completely wrong. 24/7 is *not* meant to be used as a building block. Where is that explained and is it correctly explained if readers understand it completely wrong? The wiki states If it is 24 hours 7 days a week [opening_hours] has a specific value: 24/7. this way it can render a specific icon. IMHO, the first thing in this discussion is to define what off means. The first thing in this discussion is to *grasp* the meaning of off, not *define* it. off has been in use for quite some time already. http://wiki.openstreetmap.org/wiki/Proposed_features/Time_domains explains quite well how the overall opening_hours syntax works. Before I added my diagram, the only things one could find is vague things like that a weekday off is wd off. After adding my diagram, one can at last read a definition of off to which everyone agreed: who is everyone? Eckhart ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] opening-hours: how to code always but...? Syntax diagram.
Hi André, Am Samstag, 19. Oktober 2013, 22:30:44 schrieb André Pirard: I've had multiple difficulties described here https://josm.openstreetmap.de/ticket/9085 coding a simple opening-hours always except one period. opening_hours=00:00-24:00; Fr 00:00-14:00,22:00-00:00 Eckhart ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] opening-hours: how to code always but...? Syntax diagram.
Hi Janko, Am Samstag, 19. Oktober 2013, 22:54:04 schrieb Janko Mihelić: 24/7;Fr 00:00-14:00,22:00-24:00 No, that is completely wrong. 24/7 is *not* meant to be used as a building block. I wouldn't use off, I'm not sure a lot of data consumers consider it. To my knowledge, all data consumers consider it. (However, off is not useful in the discussed case.) Eckhart ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] gross weight - conclusions changes
Hi martinq, Am Dienstag, 2. Juli 2013, 20:01:59 schrieb martinq: For highest level of confusion, gross weight is not used as (short) synonym for *permissible* maximum mass everywhere. In contrary! In US they distinguish between: GVW = gross vehicle weight, meaning the *ACTUAL* weight GVWR = gross vehicle weight rating, meaning the maximum GVW defined in vehicle documents For combinations GCW and GCWR (gross combination weight rating) are used. a) Thus, for less ambiguity it suggest to use maxweightrating instead of maxgrossweight as originally proposed. Then what about maxactualweight as its counterpart? Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Through_route next steps
Hi Rob, Am Samstag, 15. Juni 2013, 13:33:24 schrieb Rob Nickerson: The next steps with any tag proposal that reaches a hung jury is to read through the comments and update the proposal to address the issues raised. In this case I think the wiki page needs to be clearer about what this tag is for (a few photo/aerial image examples would help), and how it differs from other tags. I don't think the rejection of the proposal is based on missing illustration. In my eyes, the proposal almost completely misses the underlying problem: the representation of data in OSM is unsuitable for inferring turn instructions. The closest thing to a junction in OSM right now is a node: if there are three or more points connected to a node, we call it a junction. Let's talk a bit about that node: how should we infer routing instructions from the constellation of ways connected to that node? Should we take the classification of the road into account? Most OSM routing programs are doing an exceptionally bad job at this, and yet they are not to blame; since the only way they are actually able to work is by applying heuristics, and the reason for that is simple: there are no conventions *at all*. The second problem is that a junction is not necessarily node-like at all. Think about divided highways. Or think about links, and you'll soon realize that turns can have an extent as well. A third aspect of the problem is that even if you are perfectly able to deduce appropriate turn instructions from the geometry, you may still end up with turn instructions that differ from what the signs say. Deviating from the signs is probably not a good idea unless your plan is to confuse the user. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fast Food Restaurants
Am Donnerstag, 30. Mai 2013, 05:22:27 schrieb Tac Tacelosky: postgres also has ILIKE, which does case-insensitive searches, so that's working for the moment. Unfortunately, ILIKE will not use any indexing (unless your pattern starts with some characters that are not affected by capitalization). Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Follow-up on Time Domains
Hi Serge, Am Dienstag, 22. Januar 2013, 06:51:29 schrieb Serge Wroclawski: Except why use abbreviations that no one uses elsewhere? I've never seen two letter abbreviations for days of the week outside OSM, in any computer system. So why use a codification that no one else uses, to save a byte? nobody else? Windows Vista: http://www.askdavetaylor.com/1-blog-pics/vista-date-time-pop-up.png Windows 7: http://www.homeandlearn.co.uk/bc/win7/taskbar/changeDateTime.gif Windows 8: http://www.liberiangeek.net/wp-content/uploads/2012/12/date_time_windows8_2_thumb.png Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Follow-up on Time Domains
Hi everybody, Am Sonntag, 20. Januar 2013, 15:16:14 schrieb Eckhart Wörner: The latest version of the proposal is here: http://wiki.openstreetmap.org/wiki/Proposed_features/Time_domains there have been some minor additions resulting in an updated spec. Here is the list of opening_hours values and their validity in the time domain spec: http://eckhart-woerner.de/~eckhart/time/time-static.html (652 KB) If you feel anything important is missing, please mention it on the list or in the wiki. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] business closed for renovation - tagging best practice
Hi Steve, Am Donnerstag, 17. Januar 2013, 13:25:44 schrieb Steve Doerr: Would this fit the bill: http://wiki.openstreetmap.org/wiki/Proposed_features/temporary ? Probably this would fit the bill even better: http://wiki.openstreetmap.org/wiki/Key:opening_hours with http://wiki.openstreetmap.org/wiki/Proposed_features/Time_domains Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Follow-up on Time Domains
Hi everybody, last year, I started an RFC to properly define time domains. Unfortunately, due to lack of time I wasn't able to follow-up on this. I would like to revive the discussion. The latest version of the proposal is here: http://wiki.openstreetmap.org/wiki/Proposed_features/Time_domains In the meantime, I had a look at the compatibility of existing opening_hours values wrt the time domains proposal: http://eckhart-woerner.de/~eckhart/time/time.html Green color: value is allowed by the time domain specification Red color: value is not allowed by the time domain specification Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Follow-up on Time Domains
Hi Serge, Am Sonntag, 20. Januar 2013, 10:00:11 schrieb Serge Wroclawski: The Microformats community seems to be going through a similar process: http://microformats.org/wiki/opening-hours The funny part is that they use our current spec as an example of opening hours done right. I fail to see where your done right comes from. The OSM format is mentioned on the brainstorming page, that's all. Maybe you can go into more detail about where you think the current format is lacking, and why you think it needs this major overhaul. The problem, as I have explained in the original RFC, is that the opening_hours page is *not* a specification. It is a collection of random examples that even contradict each other. The result is that the number of implementations is quite low and that those implementations conflict. Here are the goals of the RFC mail: - has to be implementable - reuses opening_hours syntax as much as reasonable - is properly defined - is reasonably complete - is reasonably extensible And then you can perhaps go into an implementation or two of the new spec (as well as possibly a path for transition)? There is no path for transition. An implementation of the current version of the time domain spec is not that difficult (basically just evaluating from left to right). Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Follow-up on Time Domains
Hi Richard, Am Sonntag, 20. Januar 2013, 09:46:37 schrieb Richard Welty: Generating results, this may take some time... how long does this normally take? it downloads some data, then processes it using JavaScript. Here is a static version: http://eckhart-woerner.de/~eckhart/time/time-static.html Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] business closed for renovation - tagging best practice
Hi Greg, Am Freitag, 18. Januar 2013, 08:11:54 schrieb Greg Troxel: Removing things is not such a good idea when you have people downloading offline data and use data that is 6 months to a year of of date, I don't think we should optimize the database for bugs in people's processing pipelines. I have not encountered good reasons to be more than a month or so out of date (on Garmin with OSM data). well, maybe you should start looking beyond your own backyard: • downloading 1 GB of navigation data per month is not a viable option for the majority of people in the world • providing up-to-date map material can be prohibitively expensive as soon as you leave the toy status Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Source tag - deprecated for use on objects?
Hi Richard, Am Montag, 7. Januar 2013, 15:12:41 schrieb Richard Fairhurst: FWIW, back when changesets didn't exist and we had created_by on objects, I took the view that the created_by tag was the property of an object _at_the_revision_in_which_it_was_inserted_. That's why P1's created_by behaviour was as it was. The same still holds true for source-on-object, I think. well, except this does not make any sense. Why should I be interested in the source an ancient revision is based on? Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Source tag - deprecated for use on objects?
Hi Richard, Am Montag, 7. Januar 2013, 11:21:58 schrieb Richard Fairhurst: If putting source on the changeset is to be the way forward I don't think that's at all a given. Serge and some other people are proponents of it. Other people think it simply doesn't work for real-world mapping. Except that source-tag-on-object does not work either for real-world mapping. Source tags are rarely updated when the source changes. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Restrictions based on the weight of a trailer
Hi Martin, Am Dienstag, 4. Dezember 2012, 09:53:03 schrieb Martin Vonwald: I'm looking for a possibility to tag the following traffic sign: http://vonwald.info/osm/images/dscn5532.jpg It forbids from 05:00 to 22:00 overtaking for HGV with a weight of more than 7.5t and also for vehicles with a trailer, when the trailer weights more than 750kg. So far I have: overtaking:hgv:conditional=no @ (05:00-22:00 AND weight7.5 ) overtaking:trailer:conditional=no @ My problem is I don't know how to tag the weight of the trailer. Do we have a tag for this? not that I'm aware of. Maybe add something like trailerweight / trailergrossweight to conditional restrictions? Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Gross vehicle weight rating
Hi Rob, Am Montag, 26. November 2012, 20:33:08 schrieb Rob Nickerson: Conclusion - in the UK all weight limits are Gross Vehicle Weight Rating limits and thus maxweight=* and hgv:maxweight=* would be enough. except that maxweight does *not* limit the Gross Vehicle Weight Rating, but the actual weight. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Gross vehicle weight rating
Hi Rob, Am Sonntag, 25. November 2012, 23:40:04 schrieb Rob Nickerson: In the UK I've spotted that some maximum weight road signs have just the weight limit on the sign, whilst others also include a picture of a HGV. I've only realised this difference recently and have not had time to research the legal side of things but the brief description on the Department for Transports website suggests the sign with the HGV only applies to that type of vehicle. If this is indeed the case, can we simply use the following (as appropriate): And this is not the case. A brief look at http://www.direct.gov.uk/prod_consum_dg/groups/dg_digitalassets/@dg/@en/documents/digitalasset/dg_070644.pdf (first page, lower right corner) suggests that this sign is not about weight, but about gross weight. So maxweight:hgv is wrong. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - Gross vehicle weight rating
Hi, this is a minor follow-up proposal for Conditional Restrictions. As the discussion has shown, there are both traffic signs that restrict access based on the actual weight and traffic signs that restrict access based on the gross vehicle weight rating. Here are some examples (based on German law): This sign refuses access to hgv with a gross vehicle weight rating of more than 7.5 tons: http://www.ruhrnachrichten.de/storage/scl/mdhl/artikelbilder/lokales/rn/shlo/schwerte/2646917_m3mst1w564h376q75v10324_0811SH-LKW_VERBOT_KLUSENWEG_4.jpg?version=1319471040 This sign refurses access to all vehicles with an actual weight of more than 7.5 tons: http://cdn-media.ln-und-oz.de/images/newsdesk/images/a/6/4/3415594_400x300_4f86bb2e5646a.jpg My proposal is to add a grossweight vehicle property to the Conditional Restrictions page in addition to the already existing weight vehicle property. The proposal + discussion can be found at http://wiki.openstreetmap.org/wiki/Talk:Conditional_restrictions#Addition:_Gross_vehicle_weight_rating Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal – RFC – Time domains
Hi Peter, Am Sonntag, 4. November 2012, 22:08:38 schrieb Peter Wendorff: However, I want to write examples based on a specification, not the other way round, therefore the specification has to come first. As the tagging advice is already there, I partly disagree here. Please don't change the rules because your formal description does not fit with the existing tagging. The problem – which I already mentioned in the introduction – is that there are no rules. The opening_hours page has a bunch of examples which suggest rules that conflict with each other. Unless the rule is everything is allowed, in which case I heartly disagree with you: the spec needs to change then. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal – RFC – Time domains
Hi Martin, Am Sonntag, 4. November 2012, 22:15:22 schrieb Martin Koppenhoefer: there is this example, which is quite obvious on the page: Mo-Fr 08:00-16:00; We 08:00-20:00 But how are things if this is Mo-Fr 08:00-12:00; We 14:00-18:00 ? Will it be open on a Wednesday at 11:00? the opening_hours kind-of explains it: Exceptions to a range of days, first the range then the exception (e.g., Mo-Sa 10:00-20:00; Tu off) or (e.g., Mo-Sa 10:00-20:00; Tu 10:00-14:00) (this means these are not additions, for example Mo-Fr 08:00-12:30; We 14:00-17:00 means that on Wednesdays, the shop is only opened in the afternoons and not additionally) Therefore: Mo-Fr 08:00-12:00; We 14:00-18:00 ➡ not open Wednesday 11:00 Mo-Fr 08:00-12:00; We 08:00-12:00, 14:00-18:00 ➡ open Wednesday 11:00 However, this is exactly the kind of problem that is in desparate need of a good explanation. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal – RFC – Time domains
Hi Tobias, Am Sonntag, 4. November 2012, 22:25:56 schrieb Tobias Knerr: Does your new page take into account existing work on the topic? For example, there is a relevant and quite thorough specification with associated code hosted here: http://www.netzwolf.info/en/cartography/osm/time_domain/specification http://www.netzwolf.info/en/cartography/osm/time_domain http://www.netzwolf.info/kartografie/osm/j/time_domain.js You'll find that the time domain proposal has been inspired by time is not optional anymore. On the other hand, most of the changes and extensions deviate even further from the syntax in opening_hours. So yes, the page *does* take into account existing work on the topic. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal – RFC – Dynamic maxspeed
Hi everybody, I would like to draw your attention to http://wiki.openstreetmap.org/wiki/Proposed_features/Dynamic_maxspeed again. The used key has now been changed to maxspeed:variable and an FAQ section has been added. All questions on the Talk page should have been answered, so I'd like to start voting soon. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Conditional restrictions accepted - turn restrictions ahead?
Hi Rob, Am Dienstag, 16. Oktober 2012, 21:42:56 schrieb Rob Nickerson: 1. Although it is difficult to calculate how many turn restrictions have some form of condition, the numbers can't be that many in comparison to normal restrictions that apply at all times. Adding the condition data to the restriction=* tag therefore will not break the majority of restrictions (they stay unchanged). Similarly adding the information in a new tag will not break the majority of restrictions. Agreed. 2. For those restrictions that do have conditional details, if: a) you add the details in restriction = you break the current tagging and routing software will not know how to interpret it. The routing then does not include the turn restriction (i.e. no restriction when you want one), or if b) you add the condition to a new tag then the routing software does not see it (i.e. you have a restriction when you don't want one). Both cases need the routing software to be updated... There is one difference for routers which do not know about conditions: (a) lets them calculate illegal routes, while (b) lets them calculate non-optimal routes. Since there are a lot of routers which still fail at certain restrictions, I guess we have to take those routers into account. I therefore definitely prefer (b). As you see all proposed ideas will need the end users to change something. And, in fact, as we currently don't have a way of including conditions, we may already have incorrect turn restriction in OSM. We definitely have them. Here are some from a quick search: http://www.openstreetmap.org/browse/relation/338059 http://www.openstreetmap.org/browse/relation/1735851 (for more, just search through note/fixme tags) _Conclusion_: Whatever we do should keep the tagging as simple and easy to understand as possible. As we already have some applies type information in restriction:hgv = no-u_turn, my gut instinct is to include all the applies type info in this tag. Hence the example *restriction:hgv = no_u_turn @ (length 6)*. This would be (a) from above. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Conditional restrictions accepted - turn restrictions ahead?
Hi Rob, (Putting tagging ML back in To since this might be of interest to other people as well, I hope you don't mind.) On topic: In your suggesttion you proposed applies = *. What would you do with the following: * day_on, etc... * restriction:hgv, etc * except Would you suggest deprecating them? Thus a restriction that applies to only hgv's becomes: restriction = no_u_turn applies = no (to switch it off for all transportation modes) applies:hgv = yes (to switch it back on for HGVs) yeah, that's the idea. The implied default would be something like applies=yes, applies:foot=no so that by default, turn restrictions apply to everyone but pedestrians. The big advantage of using applies is that from a language POV it is immediately clear what is meant, and that the syntax will be *exactly* the same as in Conditional Restrictions. day_on, … should definitely get deprecated, those tags are an unholy mess: people mess up off and on; people interpret them them as both from day A time B to day C time D and from time B to time D each day between day A and day C. except can probably stay, it can easily be translated (except=bus translates to applies:bus = no) restriction:hgv should get deprecated / reverted, someone recently sneaked this into the wiki page without any discussion. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Conditional restrictions accepted - turn restrictions ahead?
Hi Tobias, Am Mittwoch, 17. Oktober 2012, 01:31:00 schrieb Tobias Knerr: This trap would not exist with restriction:hgv=*, restriction:conditional=* and so on, because there you would not rely on an implicit default. I agree, this might be a trap, however, this can be easily caught by editors like JOSM (value of applies:conditional will be ignored since there are only 'yes' values). Also, I am not fully understanding what the value of restriction:conditional would be in your type of tagging. Maybe some complete example with all tags present? Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Conditional restrictions accepted - turn restrictions ahead?
Hi Tobias, Am Mittwoch, 17. Oktober 2012, 01:56:05 schrieb Tobias Knerr: As for examples, I hope the following two will help: Example 1: type = restriction restriction:conditional = no_right_turn @ 08:00-18:00 That sounds like the following might be correct as well (k!): type = restriction restriction:conditional = no_right_turn @ (08:00-18:00); only_right_turn @ (18:00-08:00) restriction = only_straight_on restriction:psv = none Basically, use Conditional restrictions syntax on the restriction key in the same manner as it would be applied to, say, maxspeed or access. A drawback of this approach is the need to invent a value for no restriction - I've called it none for the example above. Okay, then the following does actually make sense: type=restriction restriction=none (probably default) restriction:psv=no_right_turn Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal – RFC – Dynamic maxspeed
Hi Martin, Am Montag, 15. Oktober 2012, 16:35:59 schrieb Martin Vonwald: And I would like to suggest a different tag: instead of dynamic_maxspeed I would prefer maxspeed:variable for the following reasons: * as far as I know those kind of speed limits are usually called variable speed limit and not dynamic speed limit * I would like to see the key right beside the maxspeed key in an editor key has been renamed. :-) Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Conditional restrictions accepted – turn restrictions ahead?
Hi everybody, apparently Conditional Restrictions has become an approved feature, even though nobody mentioned it here. While I still believe that this is a sub-optimal solution (and still nobody has passed the test I created earlier in the discussion, even though a lot of people tried), I have now abandoned the Extended Conditions proposal. I guess the next step is to adopt conditional restrictions for turn restrictions, to achieve some consistency. One possibility would be applies as basekey, and then conditional restriction tagging like applies:bus=no applies:hgv:conditional = no @ (length12) (the implied default being applies=no, applies:vehicle=yes) Any volunteers? :-) Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag: Legally separated ways
Hi Colin, Am Montag, 15. Oktober 2012, 20:08:01 schrieb Colin Smale: I don't understand why emergency vehicles are so important in this discussion. In the first place they have wide-ranging exemptions from traffic rules, which (let's be honest) we are never going to tag in OSM. Secondly they are never going to be relying on OSM data (or indeed any normal sat-nav) for lane-precise routing. They are trained to use their eyes and brains to make split-second decisions on what is safe and an acceptable risk under the circumstances of that moment. Thirdly, they will be about 0.01% of the potential users of OSM data - why should we compromise service to the vast majority of real users for the hypothetical benefit of the very few. I fully agree with you; if we were going to map for emergency vehicles, we'd probably have to add oneway:conditional = no @ emergency for almost all oneway roads first. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Conditional restrictions accepted – turn restrictions ahead?
Hi Martin, Am Dienstag, 16. Oktober 2012, 02:18:30 schrieb Martin Koppenhoefer: apparently Conditional Restrictions has become an approved feature, even though nobody mentioned it here. While I still believe that this is a sub-optimal solution (and still nobody has passed the test I created earlier in the discussion, even though a lot of people tried), I have now abandoned the Extended Conditions proposal. I guess the next step is to adopt conditional restrictions for turn restrictions, to achieve some consistency. are you sure that we need this? In real life I only met these in cases where they would have already been implicit in OSM (i.e. in addition to the signs limiting access to a road there was a turn_restriction sign to advert the driver in advance but this wasn't restricting more than what the road access permissions already did). Just for the start: • there are some no left turn restrictions in Munich that only apply during rush hour (i.e. specified intervals on a sign) to improve traffic flow, with day_on… not being sufficient • there are some no u-turn restrictions in Augsburg that only apply to vehicles longer than 6 metres • there has been a no right turn restriction near Neusäß that only applied during night time and holidays (got removed a few years ago) to calm down a residential road None of these are representable implicitly or with what we have right now, and those are just a few random examples off the top of my head; I have seen a lot more of them. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Emergency lane used by PSV at rush time
Hi Tobias, Am Sonntag, 14. Oktober 2012, 14:40:45 schrieb Tobias Knerr: You could combine Conditional restrictions and the lanes suffix¹: lanes=3 access:lanes = yes | yes | no emergency:lanes = | | yes psv:conditional:lanes = | | yes @ rush_time and what exactly is rush_time supposed to mean? Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Turn Restrictions
Hi James, Am Sonntag, 14. Oktober 2012, 10:04:47 schrieb James Mast: Gauß has now also added a new section called More turn restrictions with a ton of new restrictions that none of the editors support. Heck, I don't think any routers support them as well. All these new turn restrictions deal with half turns.. Maybe Gauß needs a time out on editing that page, because it's now beyond confusing, especially for new mapers. Plus, I don't recall any vote on these new turn restrictions types he added. There hasn't been any vote. I have now changed the page back to the last edit before Gauß started vandalizing, maybe some admin can lock the page as well? Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Turn Restrictions
Hallo Martin, Am Sonntag, 14. Oktober 2012, 16:42:56 schrieb Martin Koppenhoefer: I have now changed the page back to the last edit before Gauß started vandalizing, maybe some admin can lock the page as well? Has someone tried to approach him directly? Locking and blocking usually don't solve these kind of issues in a sustainable and permanent way. I haven't yet, feel free to go ahead. :-) Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Standard for external links to location based services
Hi Tobias, Am Freitag, 12. Oktober 2012, 13:13:47 schrieb Tobias Knerr: New players should indeed be treated the same as dominating platforms (see Flickr): If they want OSM integration, they should link to OSM, not the other way around. well, except that linking to OSM is notoriously difficult. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Naming boundary ways - the — separation character
Hi Alexander, Am Mittwoch, 10. Oktober 2012, 21:53:42 schrieb Alexander: Why not adding new tags like: name:left=Mexico name:right=USA this would also enable developers to render the border like this: http://fissl.com/border.svg Really? You need the whole outline (i.e. the relation) to do something similar, otherwise you'll end up with text outside the boundary. Also, it should be pretty simple to add some correct automatic naming to editors like JOSM without abusing the name tag, the rule would probably be pick members with highest classification, join them using /. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Conditional Restrictions vs. Extended Conditions
Hi everybody, Am Mittwoch, 19. September 2012, 20:01:35 schrieb Eckhart Wörner: == The task == […] It reveals quite a lot about the voting process that nobody has managed to solve this seemingly simple exercise (though several people have tried and failed), yet there is a high number of yes voters. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal – RFC – Dynamic maxspeed
Hi everybody, as a follow-up to a previous discussion on this topic here is an RFC that tries to improve the dynamic maxspeed situation. The text of the proposal can be found here: http://wiki.openstreetmap.org/wiki/Proposed_features/Dynamic_maxspeed Please comment using this list or in the discussion page of the proposal. 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,
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
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
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
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 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
[Tagging] Conditional Restrictions vs. Extended Conditions
Hi everybody, it probably comes as no surprise that I am against the Conditional Restrictions proposal and in favor of the Extended Conditions proposal. My main reason is that I believe the Conditional Restrictions proposal is so complicated it will kill mapping of those conditions almost completely, while its benefits are only dubious. However, since the majority of participants in the whole discussion has apparently never tried to do anything with either of the two tagging schemes, here is a simple challenge. Maybe you should complete the challenge *before* voting. == The situation == A short section of a motorway. There is a bridge which is prone to accidents when wet, therefore the speed is reduced to 80 kmph on the bridge when wet, with a gradual reduction of speed before the bridge. There are also people living nearby complaining about the noise, so the administration decides to limit the speed of the whole motorway section to 100 kmph between 10 pm and 6 am. == The task == 1) Map the night-time speed limit using the Conditional Restrictions proposal. Here is the starting position: http://eckhart-woerner.de/~eckhart/conditional-restrictions.osm 2) Map the night-time speed limit using the Extended Conditions proposal. Here is the starting position: http://eckhart-woerner.de/~eckhart/extended-conditions.osm 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 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] access restrictions on ways
Hi Martin, Am Montag, 17. September 2012, 16:04:19 schrieb Martin Vonwald: My two cents: we should allow such kind of restriction to be placed on a node, because that's the way they work. They are just some kind of legal barrier and barriers on a road we (usually) map as a node. that wouldn't solve the problem; vehicles are forbidden to pass the legal barrier coming from both sides. Technically, it would be more of a turn restriction. In any case, the extended conditions/conditional access debate has to be solved first, because otherwise the combination of signs is a problem in itself. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] access restrictions on ways
Hi David, Am Montag, 17. September 2012, 10:57:16 schrieb David ``Smith'': Excuse me if I don't understand the situation entirely, but I think the problem is the actual access restriction or enforcement of it is different from a literal reading of the signs. This must be the case if the signs don't give adequate information to completely describe the restriction. In that case, do your best to determine the actual restriction as it is enforced and map accordingly. To my understanding, the administration itself says that the sign only applies to vehicles passing the sign in the right direction, which means this is just like a turn restriction (no_straight_on). The only problem is that right now, the restriction itself cannot be represented adequately. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] access restrictions on ways
Hi André, Am Montag, 17. September 2012, 17:10:11 schrieb André Pirard: In this C23 case, heavy vehicles are forbidden to go to Esneux, not to leave it. That would be extra fun; you have understood that, politically, the restriction is *before* the sign. One way restriction. And, to me, a node restriction. No relations, please, no thanks. The relation with the extended cond* prompted me to hasten my posting. There are three possible types of restrictions: node restrictions, turn restrictions and way restrictions. - You cannot use node restrictions, since they do not have any direction information (stuff like forward or backward is meaningless on nodes) - You are against turn restrictions, even though they are the proper solution in this case. - This leaves you with a direction-dependent way restriction, like maxweight:forward / maxweight:backward. More precisely, this is also wrong, since the weight restriction only applies to hgv vehicles (but that is what the whole conditions debate is about) My french is not that good, does that sign apply to 7.5t actual vehicle weight or 7.5t gross vehicle weight? Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging Digest, Vol 35, Issue 23
Hi Frederik, Am Freitag, 10. August 2012, 14:46:11 schrieb Frederik Ramm: Many suggestions in this thread have been made from a programmer viewpoint. From a programmer viewpoint, in a perfect world where every software correctly parses these tags, I could take every maxspeed=60 and change it to maxspeed:(0h-24h):(weight10tons)=60 and it would not make a difference, right? But in practice, this would likely make the maxspeed information unavailable to the majority of users who are stuck with clients not having a perfect restriction parser (and even those that have would probably irritate the user with some kind of asterisk that says addidional restrictions apply click here for details or so). Yes, this is a hypothetical example but I hope it drives home the point that for the overwhelming number of users, a complex grammar for a restriction tag is likely *less* useful than note: lower speed limit at night or so - even if the programmer wets his pants about the sheer beauty and flexibility of the tag he has just defined. Maybe you should just refrain from participating in the discussion if you have nothing useful to add? Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - RFC - Extended Conditions
Hi everybody, since I am still convinced that the Extended Conditions proposal is the best proposal out there to deal with conditional tagging and several people encouraged me to do so, I have resubmitted the Extended Conditions proposal to the whole process, and also cleaned it up a bit. http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags (For those who missed it, there is now a competing proposal at http://wiki.openstreetmap.org/wiki/Proposed_features/Conditional_restrictions ) Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extended tagging schema - my thoughts
Hi Rob, Am Freitag, 10. August 2012, 15:47:23 schrieb Rob Nickerson: p.s. To address some criticisms of my earlier proposal: Here are some disadvantages of merging everything into a single value: - readability and ease of manual editing suffers This suffers in any lenthy tag schema. Thr proposal is consistent so editors can be adapted to provide a fantastic GUI. As written before, a fantastic GUI can be provided for every tagging scheme that is computer-readable. That does not invalidate the argument that competing proposals split the tagging into several key/value pairs to improve readability. - you lose backward compatibility The proposal falls back to existing tag schemas therefore providing backwards compatability. No, it doesn't. If you set maxspeed=120; wet 80, then none of the existing routing programs can use this tag anymore. The Extended Conditions proposal uses the tagging maxspeed=120, maxspeed:wet=80, which allows existing routing programs to still use the maxspeed key. - you run into the (real) risk of exceeding the 255 byte limit imposed on values That would have to be one hell of a complicated access rule!! Oh, you haven't seen anything. German inner city pedestrian zones are infamous for complex access restrictions (taking into account bicycles, delivery traffic, destination traffic, taxis, all of them depending on the day of week and the time of the day, and sometimes even on the direction). Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Extended Conditions
Hi Pieren, Am Freitag, 10. August 2012, 16:59:26 schrieb Pieren: And you decided to ignore all negative comments from first vote and ML. Many people told you that they have no problem with maxspeed:wet=80 because key part can be considered as constant. But you didn't change anything about the most disputed parts like maxspeed:(Mo-Fr 07:00-17:00)=30 or access:(weight5.5)=destination. No, I didn't, because I believe those parts are quite important. But as you might have noted there is now a competing proposal which tries to suit your wishes. Besides, here's a quick summary of the votes *opposing* the proposal: 1) un-OSM-y, kills performance 2) dislike without argument 3) dislike without argument 6) alternate proposal that doesn't work 7) un-OSM-y, kills performance (refers to 1) 8) dislike without argument 9) un-OSM-y (refers to 1) 10) dislike without argument 11) dislike without argument 12) special characters 13) against colon as main separator 14) dislike without arguments 15) dislike without arguments (refers to 14) 16) dislike without arguments, alternate proposal that doesn't work 17) dislike without arguments 18) too complex, number of unique keys 19) without reason 20) go back to discussion 21) without reason 22) dislike without argument, alternate proposal that doesn't work 23) without reason That makes quite a few votes which are based on no arguments at all or arguments that are just plain wrong. (And it would have helped if some people actually read the discussion before voting.) As you said, you are convinced that your proposal is the best. I never said my proposal for a simple reason: someone else created it. Probably you will push it as a de facto standard soon or later (in middle term, by moving the wiki proposal to the formal documentation templates). I don't care myself if you accept remarks in the wiki that some of your ideas are not considered as good by a majority of reviewers... Again, those are not my ideas, although they obviously have my full support. And if the idea is really that bad, maybe other people could start using *real* arguments to prove it. The quality of an idea is normally measured by the weight of pro and contra arguments, not by the number of pro arguments vs dislikes. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Everybody is hiding?
Hi tagging list, the Extended Conditions proposal has been shot down by a majority, and therefore there is still no official way of tagging quite a lot of things. (As a side note, the Extended Conditions proposal is still the de facto standard.) Therefore, I expected that those people who had voted against the proposal came up with a well-designed alternative proposal – yet nothing happened. Shall I conclude that all those people who voted against the proposal did this just for the sake of voting against? Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Everybody is hiding?
Hi Frederik, Am Donnerstag, 9. August 2012, 14:36:40 schrieb Frederik Ramm: You have to work on your expectations then. Has it occurred to you that some people don't find extended conditions important enough at all? Personally, I think that most of the extended conditions that the proposal tried to address were not worth having a tagging scheme for; they were stuff that only a few perfectionists would want to map anyway. Yeah, e.g. those quixotic perfectionist geeks from Synyx. And while I am not against perfectionists mapping stuff they like, I am against elevating this to the state of an accepted proposal because that would convey too much mindshare to such a marginal issue. In constrast to *really* important features like diet meals, clocks or fire hydrants… The proposal is driven by a geek-y desire to convert every last bit of information contained in a road sign into an OSM tag. But I don't think Okay, I repeat it one more time for you: this is not about some stuff geeks want to add to the database, this is serious stuff that some companies actually want to use (and other companies like MapQuest and Tele Atlas sell this kind of information). If you don't believe me then just have a look at GDF, which is an industrial standard that specifies exactly the same geek-y stuff (IIRC you can find some older versions of the standard on the internet). that this is what people will usually want to do, and I fear that giving this idea more mindshare will in the end lead to our editors being burdened by special restriction composer preset tabs where you can generate stuff like time and weather dependent speed limits for disabled persons with children. Yeah, like the UI-cluttering turn restrictions plugin in JOSM… wait, what? Yes, it is a *plugin*. If you do not like it, just do not download it. I don't think that the proposal is the de facto standard either. I think some of its parts will probably be used - e.g. I could see maxspeed:wet being of use. I think it is likely however that this will be interpreted like a normal, fixed tag, […] I cannot find any wiki entry for - maxspeed:wet - maxspeed:hgv:forward - maxspeed:motorcycle - toll:hgv - toll:forward - access:hgv:forward (just to pick a few). If those are all fixed tags, then where are the wiki entries for them? On the other hand, the Extended Conditions proposal explains *all* of them, just in one page instead of thousand pages. […] and I don't believe anyone will actually implement a restriction parser that understands any combination of restrictions on any tags. It's not that difficult to implement, trust me. I have no problem whatsoever if the mapping of speed limits that only apply to HGV at night happens by way of a note tag. It's just not frequent enough to even discuss. For something that's not worth discussing, the discussion is quite lengthy. About that note tag proposal of yours: this is the most stupid proposal I have heard so far. I have a better one: why not stuff everything we ever want to tag into one big note tag, that would make all editors a *lot* simpler. (On the other hand, it would make using the data impossible, but as you already stated, the mapper is the only person that is important.) Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Everybody is hiding?
Hi Ole, Am Donnerstag, 9. August 2012, 17:55:24 schrieb Ole Nielsen / osm: First of all I actually approved the proposal but later realized that having variable keys is less than ideal. then *please* tell me the reason why you believe this is the case, because I haven't seen any compelling counter-argument so far. What I have seen from different people: - allows for an almost infinite number of keys: existing tagging shows that keys tend to cluster, e.g. maxspeed:(22:00-06:00) is in use 395 (!) times with 6 different values (putting this into perspective: meagre 4494 occurences of maxspeed:backward). Those clustering effects become even stronger with increased usage. - kills PostgreSQL database performance: when you preprocess your routing data, you have to do a linear scan over all tag hstores anyway. - difficult because of special chars: the only situation where this actually matters is when you search inside your editor – and in that case the ':' already requires you to quote your key, at least in JOSM - difficult to parse for computers: every programmer can tell you in a second that this is plain wrong - difficult to parse for humans: so far, everybody I talked to about this was able to grasp the meaning of maxspeed:(22:00-06:00) = 100 in a split second And – of course – my favourite: - un-OSM-y, don't like it Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extended tagging schema - my thoughts
Hi Rob, Am Donnerstag, 9. August 2012, 17:33:59 schrieb Rob Nickerson: Can I therefore give alternative suggestions: * maxspeed=120; 80?wet; 60?wet+hgv Ask a few mappers not participating in this discussion what this key/value combination is supposed to express, and I'll bet most of them will have problems telling you the correct meaning; e.g. the first time I read this, I interpreted wet+hgv as wet or hgv. Here '?' can be interpreted as 'if' and '+' as 'and'. Many alternatives can be proposed using alternate symbols (or none at all). In fact, it is already in use: * opening_hours=Mo-Sa 10:00-20:00; Tu off I'd be careful using the opening_hours syntax as an analogy, e.g. what is maxspeed = 80?wet;120 supposed to mean? Advantages: Easy to reduce back to the basic condition, editors can implement this in a fancy GUI; expandable, can use bots to analyse/fix I'm not sure what easy to reduce back to the basic condition means. However, all the other advantages you list exist for almost any tagging scheme proposed so far. Here are some disadvantages of merging everything into a single value: - readability and ease of manual editing suffers - you lose backward compatibility - you don't integrate widely used conditions like forward, hgv, … - you run into the (real) risk of exceeding the 255 byte limit imposed on values Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extended Conditions - response to votes
Hi Frederik, Am Freitag, 6. Juli 2012, 01:12:55 schrieb Frederik Ramm: In my eyes this proposal is a typical designed-on-the-desk-of-a-database-person idea. Wow, that is the most compelling argument ever made in the discussion. But I think these kinds of complex tagging schemas only satisfy a few über mappers who are delighted to be able to model something complex. They won't be adopted by a large enough group of people to even remotely rely on these tags being present and correct. Before you start to think and make some completely wrong assumptions, you could as well have a look at taginfo and realize that the scheme is in widespread use already. Let me pick some numbers for you: 4 583 maxspeed:forward 4 397 maxspeed:backward 3 442 maxspeed:hgv 566 maxspeed:wet 447 maxspeed:children_present 377 maxspeed:(22:00-06:00) What you (and some other people) fail to see is that this proposal is designed to just blend in, something *all* other proposals so far failed to do. I suggest the following course of action: 1. Use the proposed tag in a limited area somewhere. This limited area is the world, and people use it. 2. Create an application that acutally makes good use of the proposed tag, something where people go: Wow, great, this bicycle routing engine on my iphone gives me different routes depending on whether the pedestrian area is open for traffic or not, that's something I have *so* been waiting for! 3. Then, based on the strength of this cool real-world application will work better if these access rules are properly mapped so let's all agree on the best way to do it, get the discussion going. You're trying to create a classic chicken-and-egg situation here. Why should anybody invest time (and maybe money) into a routing application based on if this application becomes successful, go back to the drawing table and break it? With this procedure, there's a remote chance that people will indeed use the tag because they get tangible results. Even then it will be I already addressed your remote chance. difficult because we already demand a lot of our mappers. Frankly, I'm sick of hearing oh we'll just make a nice template in the editor for this because those templates already give every mapper the impression that a simple street with a name is not enough anymore - a new mapper stupid enough to open the JOSM preset for a residential road is already asked whether the road is lit, how many lanes it has, what the surface and the maximum speed were, how wide the road was (in metres), whether there was an incline... this has all grown from the oh let's just make a nice template then mappers can enter this stuff idea but the result is that every mapper is left feeling inadequate because he cannot remember if there were street lights in the street he surveyed. And what is your point here? There is no template in this proposal, and with current JOSM, this is also impossible. I'm a big fan of the show application, introduce tags idea. Everything else is just wouldn't it be nice if... tag wanking that gets us nowhere. show application, introduce tags is broken, as argued above. I would agree with show compelling use case, introduce tags, and this one is imho pretty compelling; just look at any good commercial routing application out there - if we want to get there, we need this proposal. As long as there are no real-world applications for this kind of detailed access mapping one can simply use the note tag and add stuff in natural language. That's my proposal for now ;) And you're the one who is then going through the already huge number of 257 572 different values of the note key? Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extended Conditions - response to votes
Hi Martin,
Am Freitag, 6. Juli 2012, 14:54:01 schrieb Martin Vonwald:
If you say so. So a general speed limit of 100, 80 for hgv and 70 for all in
case of rain, snow and ice is crystal clear (for mappers and apps)?
[…]
Good point. If the specificness is just a bit of routine programming work
everything's fine.
Let's have a look at an example again, and see how an algorithm might work:
maxspeed=none
maxspeed:hgv=100
maxspeed:(22:00-06:00)=120
maxspeed:(22:00-06:00):hgv=80
maxspeed:wet=80
First we have to find out the set of conditions each key contains:
- for the maxspeed key, the set of conditions is empty: {}
- for the maxspeed:hgv key, the set of conditions is {hgv}
-for the maxspeed:(22:00-06:00) key, the set of conditions is {22:00-06:00}
- for the maxspeed:(22:00-06:00):hgv key, the set of conditions is
{22:00-06:00, hgv}
- for the maxspeed:wet key, the set of conditions is {wet}
Key X is more specific than key Y if the set of conditions of X is a superset
of the set of conditions of Y.
Key X conflicts with Y if neither X is more specific than Y nor Y is more
specific than X.
Therefore,
- maxspeed:(22:00-06:00):hgv is more specific than both maxspeed:(22:00-06:00)
and maxspeed
- maxspeed:(22:00-06:00) is more specific than maxspeed
- maxspeed:wet is more specific than maxspeed
- maxspeed:(22:00-06:00), maxspeed:wet and maxspeed:hgv conflict with each other
We now order the keys according to their specificness, most specific ones first
(this is possible since specificness defines a partial order):
maxspeed:(22:00-06:00):hgv=80
maxspeed:wet=80
maxspeed:hgv=100
maxspeed:(22:00-06:00)=120
maxspeed=none
This is all part of the preprocessing. Now comes the time to actually evaluate
the maxspeed (e.g. to display a speed limit to the driver). Let us assume we
are driving a normal car, it is midnight and it is raining:
- maxspeed:(22:00-06:00):hgv does not apply, we just move on in the list
- maxspeed:wet applies, we write down 80, we note that we have to skip
maxspeed, since maxspeed:wet is more specific than maxspeed
- maxspeed:hgv does not apply, we just move on in the list
- maxspeed:(22:00-06:00) applies, we write down 120, we note that we have to
skip maxspeed since maxspeed:(22:00-06:00) is more specific than maxspeed
- we skip maxspeed
We found two possible values, 120 and 80, and take 80 as the more restrictive
one.
Another use case is reducing the above list, based on some fact we know. Let us
assume that we are designing a navigation system built into an hgv vehicle
(therefore, the condition hgv is always true):
- maxspeed:(22:00-06:00):hgv becomes maxspeed:(22:00-06:00)
- maxspeed:wet stays maxspeed:wet
- maxspeed:hgv becomes maxspeed, since hgv is always true
- maxspeed:(22:00-06:00) stays maxspeed:(22:00-06:00), however, since we
already have a maxspeed:(22:00-06:00) from above, we ignore this one
- maxspeed stays maxspeed, however, since we already have a maxspeed from
above, we ignore this one
We therefore end up with a reduced maxspeed table for hgv:
- maxspeed:(22:00-06:00)=80
- maxspeed:wet=80
- maxspeed=100
Eckhart
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extended Conditions - response to votes
Hi Chris, Am Freitag, 6. Juli 2012, 15:33:00 schrieb Chris Hill: Let's have a look at an example again, and see how an algorithm might work: […] And you expect Jo Mapper to get this and moreover to use it, without mistakes? Those were two different algorithms obviously *not* designed for human beings, but for computers. Joe Mapper has to know how to put the information into the OSM database: - there is no general speed limit on motorways in Germany (therefore maxspeed=none) - there is a speed limit sign saying 80 combined with another sign bei Nässe (therefore maxspeed:wet=80) - there is a speed limit sign saying 120 combined with another sign 22:00-6:00 (therefore maxspeed:(22:00-06:00)=120). - there is a speed limit sign saying 100 combined with another sign with the pictogram of an hgv (therefore maxspeed:hgv=100) etc. Jane User has to do nothing, since her navigation system will display the corresponding speed limit, regardless of the time, and warns her if she starts speeding. I'm not sure where your problem is. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extended Conditions - response to votes
Hi Peter, Am Donnerstag, 5. Juli 2012, 11:04:11 schrieb Peter Wendorff: Let's consider a routing engine that has to load osm data to built the routing graph. Here the data parsing itself probably isn't the most expensive part of the whole process, but nevertheless: currently a fixed string comparison is used; with variable keys a substring comparison would be necessary to fetch the necessary tags. Every software that stores tags in key-value stores would have to parse over all keys instead of a simple lookup. The only software affected by this is routing preprocessors, and I highly doubt you could even spot the difference. This argument is flawed in two ways: First of all, there is plenty of precedent: the (old) TMC scheme uses variable keys extensively, As you note yourself: that's the old TMC scheme, that has been in critics very often because it's not maintainable. The new TMC scheme uses a fixed set of keys and IMHO increases maintainability by doing this. The old TMC scheme is not maintainable because it a) extensively uses relations, and b) made no attempt at simplifying tagging. But yeah, that's a bit off-topic. b. Merge all conditions and all possible values into one value, i.e. maxspeed=complex expression or access=complex expression First of all, complex expressions are actually complex, people inevitably will get them wrong. well, but is it really more easy to create a concise set of tags dividing the one very complex value to several semi-complex values using several semi-complex keys? First of all, the values are not semi-complex, they are dead-simple, since they are exactly from the same range as their base keys: maxspeed=100 maxspeed:(weight7.5)=70 Second, since the system is based on specialization, it naturally maps signs, implicit restrictions, etc. In the above example, the maxspeed key is due to a country-specific speed limit on rural roads, the maxspeed:(weight7.5) is a sign. Here [1] is a simple implementation that evaluates maxspeed in less than 100 SLOC, 100 SLOC are a lot, if you take into account, that it's not fault tolerant: changing the last key in your example to maxspeed:(weight1.5t) your interpreter fails to tolerate the t as a default unit, adding a unit to the maxspeed-value (e.g. 100mph) fails, too. Please bear in mind that this is just proof-of-concept code. Also note that the code contains both the preprocessing step *and* the final evaluation, starting with raw key/value pairs. The actual evaluation happens in the evaluateConditionStructure() and is 25 LOC. Unit parsing and conversion should take place in the preprocessing, not in the final evaluation. Also, unit parsing/date parsing/whatever are all things that have to happen regardless of any tagging scheme (unless you want to limit yourself to access=yes/no). As this has to be taken into account even in the KEY parser, the regular expression get's more complicated again, and it's not an argument that everybody should use km/h as a unit for tagging, because we tag what's on the ground, and 60mp/h (96,56...km/h) are different from 100km/h - but tagging a maxspeed of 60mph is okay. You seem to read to much into my regular expressions. Those things are just implementation details. (Also, just for the record: regular expressions are not slow, they are among the fastest tools we have, it's just the build of the state machine that's slow.) Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extended Conditions - response to votes
Hi Frederik, Am Donnerstag, 5. Juli 2012, 14:30:49 schrieb Frederik Ramm: reading this discussion again demonstrates how useless our voting process is. +1, but for completely different reasons, but that is another story. It is obvious that this issue has not been thoroughly discussed, that there is no consensus about which problem exactly it should solve and what the implications for mappers or users would be. I am sorry, but my definition of obvious is a bit different: * the issue has not been thoroughly discussed: the issue has been discussed for more than four years now, and the discussion has earned the label thorough * there is no consensus about which problem exactly it should solve - the problem that should be solved is pretty clear, most (all?) people even agree that the problem needs to be solved, the discussion is only about the solution to choose. * implications for mappers or users: it allows mappers to add a lot of information that is important (especially for routing software) and that they couldn't add before in a meaningful way (i.e. other than note=maxspeed is only valid between 10pm and 6am). It defines a meaningful transitive closure of existing tagging practice, and therefore should not give anyone a surprise. This means the whole thing isn't ready for voting. Yet I read that If a discussion stops to be fruitful, it is definitely time for voting. voting was full underway. You cannot vote *instead* of having a discussion, it won't work. Legitimate criticism cannot be countered by but we got 51% in the vote for this. Whoever started a vote on something so un-ready is certainly not helping anyone. That would be me. As has been pointed out already, the discussion stopped being fruitful, and the discussion stopped - an attempt to revive it failed. A good part of the criticism that appeared in the vote hasn't even been mentioned in the discussion phase. Also, the problem with legitimate criticism is the subjectivity of legitimate. There has been quite a lot of criticism, which several people tried to address. Yet the same criticism appear over and over again (I stopped counting people who ignored the limitations of the 0.6 API). Does this make criticism legitimate? Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extended Conditions - response to votes
Hi Pieren, Am Donnerstag, 5. Juli 2012, 15:58:06 schrieb Pieren: Well, we had some discussion before the vote. On the wiki, I already pointed out that the variable content in key was a major issue in this proposal (not e.g. maxspeed:wet=* but about such maxspeed:(Mo-Fr 07:00-17:00)=*). And your main arguments were we've never done that before, it doesn't feel right and it kills performance, which I have addressed both in the wiki and in the thread-starting mail. I even started some alternative proposal but I saw that a real good alternative proposal would require much more thinking and time and motivation than I have. …and probably a different API with structured tagging. The extended conditions proposal definitely is not perfect, but it (imho) does a good job in solving the problem at least for the next ten years, and I have yet to see an alternative that even comes close. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Extended Conditions - response to votes
Hi Martin, Am Donnerstag, 5. Juli 2012, 22:49:30 schrieb Martin Vonwald: There could occasionally be an issue with the value length limit, though. That's what IMO is the limiting factor. And I don't think at the database limit, but instead on the willingness of people to read/write extremely long values. But those very long values would only appear for unusually complex restrictions. I expect situations with more than 1-2 conditions to be very rare. Do you disagree with that assumption? Here are a few examples for you: Nearby motorway: maxspeed=none maxspeed:hgv=100 maxspeed:(22:00-06:00)=120 maxspeed:(22:00-06:00):hgv=80 maxspeed:wet=80 Nearby pedestrian area (I will try to get a picture of the signs for this one for educational purposes): access:bicycle=yes access:vehicle:(weight10):(Mo-Fr 06:00-11:00; Sa 06:00-10:00):delivery=yes access:vehicle:(19:00-10:00):destination=yes access:vehicle:taxi:(Mo-Fr 20:00-10:00; Sa, Su, PH 20:00-11:00)=yes We cannot just discard an idea when we find one flaw. We need to identify the solution whose flaws matter the least in practice. 100% correct. But I have the feeling that the extended conditions proposal is not the solution whose flaws matter the least. But as I also don't have the perfect solution in my pocket I will not oppose it. However I hope that no solution is approved and instead the discussion is restarted and kept alive until a good solution is found. I hope it but it doubt the latter. Well, if this proposal fails I would say everybody who voted against it has to come up with a better one (where better is based on some actual arguments), but I do not believe in Santa Claus either. What probably happens is that this discussion dies, and people will either use this proposal (as they have done before) or use the note and fixme keys (as they have done before). Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Extended Conditions - response to votes
Hi everybody, the vote is fully underway, and some contra arguments are repeated over and over again, and I feel the need to address some of them in more detail: 1. constant keys is a fundamental rule in OSM If such a rule actually exists, it has never been written down, at least I couldn't find any hints in the wiki, it has only been mentioned as an argument to shoot down this proposal. The wiki states: Tags, consisting of a 'Key' and a 'Value' can be associated with either elements (nodes, ways and relations) or changesets. Both the key and value are free format textual fields, although in practice there are agreed conventions of how tags are used for most common purposes. Now one may argue that this rule has been established just by not using variable keys until now. This argument is flawed in two ways: First of all, there is plenty of precedent: the (old) TMC scheme uses variable keys extensively, the source base key uses variable keys (source:key has key as variable), to my knowledge OpenSeaMap uses them for lights, etc. Also, the argument is broken: not having done something in the past is not an argument by itself for not doing something in the future. However, let's have a look at some alternatives: a. Use maxspeed:conditionX=condition, maxspeed:valueX=value (or something similar), where X is a number: first of all, the key is also a variable, which violates the constant key rule the same way. Second, one could easily argue that from a semantic POV this is even worse, since only the combination of keys gives a key its meaning. With the extended conditions proposal, I could easily setup a wiki page Key:maxspeed:(22:00-06:00) and define the exact meaning of this single tag (whether such a page is actually useful is a different topic). b. Merge all conditions and all possible values into one value, i.e. maxspeed=complex expression or access=complex expression First of all, complex expressions are actually complex, people inevitably will get them wrong. More importantly, one can quite easily exceed the 255 byte limit for tag values. 2. [the new tagging scheme is] unusable for data consumers (or not without huge impact on performances) The tagging scheme is pretty simple to implement; just match all tag keys against /^access(:.*)/, sort all matching tags according to their specificness, and skip less specific tags accordingly. Here [1] is a simple implementation that evaluates maxspeed in less than 100 SLOC, the only thing that makes access more difficult is because there is a lot of keys that are not prefixed with access. Eckhart [1] http://eckhart-woerner.de/~eckhart/extcond.html ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging u-turn restriction with continuous painted line
Hi Janko, Am Dienstag, 3. Juli 2012, 14:12:16 schrieb Janko Mihelić: I think this is the wrong way to look at this. If you rely on routers to make this kinds of decisions, you are going to have a lot of problems. What if there was a roundabout island where you were allowed to u-turn? You should put in a allow_roundabout_u_turn or something. Also, some routers are not going to have the same logic. Anyway, if you don't put a no_u_turn restriction in this case, routers are rarely going to route through that, so I think we are safe either way :) They will happily use that turn for re-routing. *Always* tag such restrictions. This is not limited to roundabouts, it is scary how many turn restrictions are missing in general because people think they are obvious. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging u-turn restriction with continuous painted line
Hi Pieren, Am Dienstag, 3. Juli 2012, 14:21:18 schrieb Pieren: I think the case can appear very often. Imagine a router based on OSM data and you take the wrong roundabout exit. The router will re-route you and most probably with a u-turn, back to the roundabout (but you are right, because of the delays and distance, most probably after the divider intersection node). But anyway, representing the no-crossing is important for routing and we should consolidate the wiki between the overtaking and divider tags. Indeed. Could we consider that overtaking=no applies to the end nodes as well, like we do for the oneway restriction ? In what way does oneway=yes apply to end nodes? Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging u-turn restriction with continuous painted line
Hi Martin, Am Dienstag, 3. Juli 2012, 14:56:21 schrieb Martin Koppenhoefer: +1, I guess it's the same everywhere. AFAIK there is no difference between a double solid line and a single one. You are not allowed to cross them (but you could if you didn't care about traffic rules, and you can if you are walking). This implies generally a legal restriction against overtaking, turning left and u-turns. No, it doesn't. * A divider does not imply overtaking restrictions, as has been argued before. In most (all?) countries, you are still allowed to overtake as long as you don't cross the divider. * A divider does not prevent left-turns or u-turns. Reason: a divider is a linear feature, it is applied to ways, and implications on nodes (especially end nodes) are completely undefined. A closer look reveals that dividers at nodes are way more complicated, and we already have an answer to that: turn restrictions. well, whether something is sensible or not depends on a lot of parameters (e.g. the amount of other traffic). We have to tell the router that there is a solid line in the first place, something we currently mostly don't do (see taginfo, http://taginfo.openstreetmap.org/keys/divider has only 192 occurencies on ways). No surprise since divider seems to be an abandonded feature. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging u-turn restriction with continuous painted line
Hi Markus, Am Dienstag, 3. Juli 2012, 15:38:57 schrieb Markus Lindholm: Physical separation doesn't necessarily mean that it's impossible to cross, it might be no more than a 20cm high curb that an emergency vehicle or a SUV easily could cross. I still think it's more straight forward to map as two separate ways than to add tags to provide a logically consistent view about how to drive from A to B in a legal way. Bank robbers and emergency vehicle drivers make anyway their own decision on the spot. And about pedestrians, I add sidewalks around such street and tag the street with foot=no. There is a reason why this is a bad idea: routing along linear features has to work under the assumption that routes are just paths in the data. By splitting ways, you're removing quite a lot of possible routes; e.g. try pedestrian routing to the house opposite to yours. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - Voting - Extended conditions for access tags
Hi everybody, Am Donnerstag, 21. Juni 2012, 12:32:10 schrieb Martin Vonwald: Has this discussion died now and awaits re-revival in another two, three years? hopefully the lack of discussion indicates that everything important has been said already. :-) Therefore I'd like to move on to the voting phase. Here's the proposal: http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags Voting starts today and ends July 7th, according to proposal guidelines. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] maxspeed=signals
Hi Paul, Am Mittwoch, 27. Juni 2012, 07:07:49 schrieb Paul Johnson: What's the purpose of a lowest speed limit? To be able to display a range, or estimate the correct value when other data (such as speed limits that vary based on time of day) is available. Speed limits that only depend on the time of day are not dynamic. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] maxspeed=signals
Hi Martin, Am Dienstag, 26. Juni 2012, 12:43:10 schrieb Martin Vonwald: The tag maxspeed=signals doesn't carry any useful information in this situation. If I tag those speed limits with this tag we completely lose the information that on this part(s) of the motorway one usually can drive 100km/h and not 130km/h. So is this tag really a good idea in this case? I understand that this might be necessary on roads where the speed limit changes frequently, e.g. at some specific times. here's another example: motorway A 100 in Berlin has maxspeed signs that might change between 80 and 60, depending on traffic conditions [1], and is therefore tagged maxspeed=signals. If route calculation just takes the default maxspeed for motorways, it will end up with maxspeed=none, which is way off. Also, a routing program could warn the driver if he's going more than 80. First of all, the problems we're actually trying to solve: a. Route calculation needs a tentative maxspeed on roads with dynamic speed limits b. Speed warning needs an absolute maxspeed on roads with dynamic speed limits to prevent the driver from speeding when possible (it is not acceptable if the software warns on a limit that's too low) I believe the difference between tentative maxspeed and absolute maxspeed is small enough to justify that we just assume tentative maxspeed = absolute maxspeed. Problems we should avoid: a. Static speed information that depends on conditions known to a routing software or the driver (time of day, weather, children present). They are covered by the extended conditions proposal. b. Dynamic speed information that is in fact not dynamic (speed signs that are programmed to show specific speed signs at specific times). They are also covered by the extended conditions proposal. (Correctly identifying a dynamic sign as static can be quite difficult, though.) Eckhart [1] http://goo.gl/maps/uyQz ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] access agricultural, WAS Re: Reviving the conditions debate
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 whole purpose of splitting user roles and transportation modes. and you don't run into the risk of a germanification of openstreetmap by always taking the german law or other western country laws as the basis for all tagging rules and leave out underrepresented countries. The huge list of conditions listed on the 1.5 proposal page is by no means an argument for it, it just hides the essence of the proposal. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
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 soon as one of the keywords condition, or , and , in , not is present in the value, we could even reduce the amount of tags: 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? Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
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 key. The problem is that different restrictions combine different conditions that may exist more than once. E.g. there are roads where access restrictions depend on several different weights, different times, and any combinations of them. access:length, access:time, … is by no means sufficient. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
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 proposing a complete new way of tagging -see the one example at the beginning of the proposal. Extended conditions will not change any of the existing access restriction tags and also not change the existing : separator for compatibility reasons. even if you don't want it to, your proposal *does* compete with Access restrictions 1.5 and everything else mentioned here, because it is the most logical generalization of existing tagging. :-) Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Reviving the conditions debate: first summary
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 vehicles (hgv, bicycle, …) and other conditions, however, other people pointed out that hgv could as well represent the condition in a hgv and the distinction between vehicles and other conditions is arbitrary. * most people agreed that every proposal must be complete, i.e. every boolean formula of conditions can be expressed in it * most people agreed that proposal should make the common case easily taggable for humans, however, some people said that editor support is required anyway and therefore the readability for humans does not really matter * some people argued that putting conditions into keys is a bad idea because it allows for an unlimited set of keys, however, other people argued that putting conditions into values is a bad idea because it pollutes the values and might lead to ambiguities, since a value could be anything, including an identifier * 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 what he accepts cannot spot errors anymore * some people argued that any proposal should take existing tagging into account * most people argued that tagging should be human-readable * some people argued that the syntax has to be similar to existing programming languages, however, other people argued that this would just make the syntax more error-prone My favorite: * a lot of people agreed that the Extended Proposals is ... already used...intuitive and simple to use...complete...consise...extensible 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. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
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 = Ministere a la does not apply? well, it would probably not parse names at all, so that's rhetorical. Sometimes streets are renamed, and name = Street A name:(2013 Jan 1+) = Street B shows the advantages of conditional tagging even on the name tag. In this case, an automatic validation tool could detect in 2013 that the condition will always evaluate to true, and suggest appropriate actions. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
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 is the price you pay for mimicking human language, and I'm not sure I'm willing to pay that price. However, the author struggled with the same basic problem, e.g. there is a (non-intuitive) difference between using ',' and ';' now. Also, except for a basic time restrictions it is impossible to tag and also difficult to read these expressions. Clearly powerful, but too compressed for casual mappers. Can you read this? Dec 25-Su-28 days - Mar Su[-1]: 22:00-23:00 I cannot read it for a simple reason: the specification does not tell the meaning of : inside that expression. The : is defined by an implementation, which just shows the problem of not standardizing properly. However, I believe we should not make time domains part of this discussion at all. open:cond = yes if time is 10:00-18:00 Your example suggests that you have a problem with defining what the if actually means: Does open:cond=yes if time is 10:00-18:00 tell a) open from 10:00-18:00, not open from 18:00-10:00 or b) open from 10:00-18:00? 2) Value vs. key I think value side conditions would be more intuitive, because the value depends on the condition. I think key side conditions would be more intuitive, because the validity of the key depends on the condition. ;-) Also, it easier to filter the things in the database, especially if left/right forward/backward is also mixed into the conditions (or should we simple go the next step and see them as condition too?). The Extended Conditions proposal already treats forward/backward as conditions. Normal form is nice to parse - but do you think everybody can map it? Non-normal form is not so nice for machines - thus I cannot promise that I achieve to parse it - and the discussion is theoretical until I can prove it (with reference implementation). Except that this kind of normal form is the way signs are written normally (that's why it's called normal form ;-) ), see http://wiki.openstreetmap.org/wiki/File:Length_and_time_restriction_2.jpg for an example: access:motor_vehicle:(10:00-18:00)=no (first sign) access:motor_vehicle:(10:00-18:00):(length5)=yes (second sign) (How would you tag this?) I'm sure that 95 per cent of the time you won't get more than one tag per sign. I also see no reason why an application may not be able to treat this as equivalent: hgv = yes(shortcut for:) access:hgv = yes (which is a valid expression also in the proposed extension) access:cond = yes [hgv] The Extended Conditions proposal treats the first two as equivalent. But why do you want to mix two ways of tagging (second + third)? Just for fun? Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
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) Extended conditions: ☑ * does not rely on the user's fluency in English grammar (knowledge of a set of specific words, e.g. tags and functions, is fine) Extended conditions: ☑ * uses grammatical constructions which are familiar to most people, or easily learnt Extended conditions: ☑ * has a grammar allowing for a user-extensible function repertoire Extended conditions: ☑ * allowing user-defined functions to be stored in an external file (accessible at entry and run time) I'm not sure I get that one, but it sounds to me like you're trying to mix specification and implementation, which is just a bad idea. * fits comfortably with the key-value-pair paradigm of OSM Extended conditions: ☑ * can produce a result in a variety of data types including at least boolean, number, string Please provide a use case. * can use the value of other tags as variables That's just a desaster waiting to happen. * can use other variables supplied at run time (e.g. weather, time, vehicle type) Extended conditions: ☑ * supports the usual comparision and numeric operations Which usual comparison operations? '12 knots' '35 mph' ? * supports string concatenation operation name = (lang == 'de' ? 'Bahnhof von ' : 'Gare de ') + 'Lyon' Please provide a use case. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Reviving the conditions debate
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 this proposal: * The proposal mostly describes syntax that is already used for tagging, e.g. a maxspeed in a certain direction is almost always tagged as maxspeed:forward, maxspeed:backward * The proposal is intuitive and simple to use: the key of a tag is the base tag + a set of conditions that all have to be true for the key to apply (i.e. logical AND). * The proposal is complete: every logical formula of conditions can be expressed in it (technically, it's pretty similar to disjunctive normal form). * The proposal is consise: it follows the pattern most dominant with road restrictions, namely overriding general restrictions with special restrictions. It normally uses no more than one tag per sign. * The proposal is extensible: the set of conditions is not fixed and can be extended to new conditions. It is possible to set a sane default for new conditions that are experimental. * The proposal is easily implementable: I implemented it in a prototype already. The only real negative aspect that has been mentioned until now: * the proposal puts a lot of information into keys and theoretically allows for an unlimited set of keys. (The reality however shows that those keys tend to be the same, e.g. taginfo shows no less than 335 elements with key maxspeed:(22:00-06:00)). 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 Extended Conditions proposal above is access:lgv?wet.speed in the Access Restrictions 1.5 proposal) Opinions? Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
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 else did a long time ago. :-) Second, in principle I fully agree with you, destination is a condition. Technically, the tag: access:(weight5.5)=destination is equivalent to these two tags: access:(weight5.5)=no access:(weight5.5):destination=yes However, destination as a value for access has been in use for quite some time, and I don't want to deprecate it (right now). The same goes for delivery, forestry, … I have written down some lines on how to interpret legacy tagging in the comments. There is also an actual proposal: http://wiki.openstreetmap.org/wiki/Proposed_features/Conditions_for_Restrictions I've just learnt about this proposal, which is brand new. Most parts are the same, however, it has some new ideas I really don't like: * It assumes access is the default, and e.g maxweight is a completely different beast. It isn't: maxweight=7.5 is just a shorter way of saying access:(weight7.5)=no. (Again, I don't want to deprecate the maxweight key (right now). * It invents new values, e.g. oneway[:…]=forward. The Extended Conditions proposal tries to invent as little as possible. * It tries to incorporate the lanes proposal, and I'm not sure that's a good idea. Extended Conditions are certainly a necessary building block for lane dependent conditions, but that's a different story. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
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 conditions, e.g. applies in situations like this: maxspeed:hgv:(weight7.5):(Mo-Fr 08:00-16:00):forward=50 maxspeed:hgv:(weight7.5):(Mo-Fr 08:00-16:00):backward=30 In this case one could somehow define: heavy_trucks_during_week ≔ hgv:(weight7.5):(Mo-Fr 08:00-16:00) And then write the tags as: maxspeed:heavy_trucks_during_week:forward=50 maxspeed:heavy_trucks_during_week:backward=30 I'm not sure that's a real improvement (note that with the Access Restrictions 1.5, the definition of heavy_trucks_during_week is slightly more complex.) However your example access:lgv?wet.speed is a good one against the 1.5 proposal. But why not combine those proposals? This would result in maxspeed:hgv?wet. I read this as the MAXSPEED for HGV IF (the question mark) weather is WET is Sound reasonable to me. More reasonable than access:lgv?wet.speed, yes. But how is it easier than maxspeed:hgv:wet? Simply because it uses different separators for different purposes. The : is used often for subkeys. It is not a good choice here. The 1.5 uses the ? in front of the condition. So it is obvious where the condition starts. IMO a good approach. The : is always used for subkeys, because that's the definition of a subkey. I'm not sure what you want to express here. About different purposes: hgv is just short for I'm driving a heavy goods vehicle, i.e. just another condition (that can be evaluated to true or false). Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
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-independent information should not be hidden in lane-dependent tagging, i.e.: maxspeed=80 maxspeed:lanes:wet = ||50 Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - TMC - New tagging scheme for TMC
Am Montag, 14. Mai 2012, 17:04:19 schrieb fly: By the way, where do you get the data from and is it somewhere available ? With the old scheme there existed another website with the data. (http://osm.anders-hamburg.de/?lcd=1) the German import is described here: http://wiki.openstreetmap.org/wiki/TMC/TMC_Import_Germany#The_import Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - TMC - New tagging scheme for TMC
Hi, Am Samstag, 12. Mai 2012, 18:31:26 schrieb fly: The inspector shows wrong data. Seems to me that the system was not updated after the last proposal changes and now the tags are mixed up. http://osm-tmc.infoware.de/tmc/?view=tmclon=7.60801lat=47.58486zoom=16overlays=tmc_database,missing_tmc_links,tmc_links,tmc_points,ways_with_tmc_tags_ok,link_ways_with_too_many_ends,ways_with_tmc_tags_error,nodes_with_tmc_tags_ok,nodes_with_tmc_tags_error,connection_and_end_nodes_ok,connection_and_end_nodes_error,ways_with_tmc_tags_non_areas,ways_with_tmc_tags_areas,ways_in_rels_with_tmc_tags,tmc_areas,nodes_with_tmc_tags The DE:*-* and DE:*+* need to be switch the sides of the road. Are you sure? In Germany we drive on the right side of the road, and that side seems to match the tmc tagging used by the original proposal from infoware (not my proposal though), which has everything reversed. (btw, I'd really like to see more input from infoware in this discussion.) By the way: Where is the tmc location at the boarder ? At the boarder control or at the real boarder ? I guess at the real border. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - TMC - New tagging scheme for TMC
Hi everybody, based on the changes I believe are important I added a modified proposal to the wiki: http://wiki.openstreetmap.org/wiki/DE_talk:Proposed_features/New_TMC_scheme#Neues_Proposal Changes: * Versions are an (optional) part of the proposal. If they are not needed, they can be left out, so this does not complicate tagging. * TABCD is enclosed by : on both sides now. * Directions of ways are properly taken into account. Ignoring the direction makes TMC information useless on non-oneway ways (which I already argued for in a previous mail). * Point locations may have an extent. * Added some informational notes about error checking. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - TMC - New tagging scheme for TMC
Hi Colliar, Am Sonntag, 29. April 2012, 18:49:39 schrieb fly: I have only one point left: What to do with more than on TMC route on one way. Do we still need relations for that ? no, we don't. My modified proposal skipped over that section (since I changed nothing in it), but the original proposal talks about this: http://wiki.openstreetmap.org/wiki/DE:Proposed_features/New_TMC_scheme#Mehrere_Locations_an_einem_Way Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - TMC - New tagging scheme for TMC
Am Sonntag, 29. April 2012, 17:08:05 schrieb Eckhart Wörner: based on the changes I believe are important I added a modified proposal to the wiki: http://wiki.openstreetmap.org/wiki/DE_talk:Proposed_features/New_TMC_scheme#Neues_Proposal Changes: * Versions are an (optional) part of the proposal. If they are not needed, they can be left out, so this does not complicate tagging. * TABCD is enclosed by : on both sides now. * Directions of ways are properly taken into account. Ignoring the direction makes TMC information useless on non-oneway ways (which I already argued for in a previous mail). * Point locations may have an extent. * Added some informational notes about error checking. I forgot to mention another change: * 20+5 now means going from LCD 20 to LCD 5, which is way more intuitive (the original proposal maps 20+5 to going from LCD 5 to LCD 20) Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - TMC - New tagging scheme for TMC
Hi, Am Freitag, 20. April 2012, 14:32:17 schrieb Heinrich Knauf: 1) The big problem: missing directional information Let's assume there is a way in OSM tagged tmc=DE:123+456;DE:456-123. One also has real-time traffic information that talks about a traffic jam at LCD 456, negative direction, extent 1. One therefore knows that this traffic jam affects DE:123-456, and since we have a way with that information, we know that this way is affected. However, there's one problem: which direction of the way is affected? It could be either the direction from the first point of the way to the last (called forward from now on), or vice versa (backward). This essential information is missing and makes the TMC information on non-oneway ways useless. There are several solutions to this problem. Probably the best solution is not using the tmc tag at all, but using tmc:forward and tmc:backward instead. Thus assuming the direction of the way is from LCD 123 to LCD 456, the tagging would be tmc:forward=DE:123+456, tmc:backward=DE:456-123. forward and backward are already used in tagging (for example, maxspeed:forward) and are also protected by tools. E.g. if you try to reverse the before-mentioned way, JOSM suggests to swap tmc:forward and tmc:backward (which is the correct thing to do in that case). That's no problem at all. The TMC direction must not be mixed up with the driving direction, which here does not matter at all. All that counts is the direction given (and defined) by the TMC data. If a traffic event extends forward woth respect to the direction defined by TMC, then + is used, if it extends in the revers direction, we use -. This is very concise, and using forward or backward instead would just blow the tags. Please re-read my argument. (Note that I use positive/negative to indicate a direction along TMC chains, and forward/backward to indicate a direction along an OSM way). Arguing that the driving direction does not matter at all is wrong as soon as you're not talking about oneways anymore. An event affecting the positive direction of a TMC chain may affect either the forward or the backward direction of an OSM way, and this entirely depends on the OSM way. 3) Bad influence: TMC information at junctions One thing that I cannot wrap my head around is the TMC information *at* junctions. As far as I remember, a traffic jam at LCD 456, negative direction, extent 1 affects the road *between* LCD 123 and LCD 456, but not the actual junctions 123 or 456. However, the rules of adding tmc tags to the actual junctions influence a lot of maneuvers going over those junctions but not using any other part of the way. This is especially true for roundabouts or junctions between dual carriageways. Please could you supply an image, or probably refer to the figures and the numbering that we use in the proposals examples? That would make it a lot clearer. See http://wiki.openstreetmap.org/wiki/DE_talk:Proposed_features/New_TMC_scheme#Auswirkungen_von_TMC-Nachrichten_an_Kreuzungen for a discussion of the problem. 4) Exits and entries TMC specifies messages that apply to entries or exits, which I feel are not adequately represented in the proposal, even though the proposal mentions them. For example, assume that the 2nd exit slip road going west at Köln-Süd (where I already discovered the new tagging) is closed (and I believe there is a TMC message for that). How do I find this 2nd slip road? (Yes, I picked a really hard one.) Isn't that just a matter of the granularity of TMC location coding versus OSM mapping? If so, then there's nothing to help about that with any TMC tagging scheme whatsoever. Unless I'm wrong (and I haven't read the TMC specs in a while) this should be possible with TMC, OSM just needs to supply the relevant data. Anyway, parts of this have been covered in a different mail. Eckhart Wörner ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - TMC - New tagging scheme for TMC
Hi, Am Freitag, 20. April 2012, 14:32:17 schrieb Heinrich Knauf: 2) A matter of taste: + and - Using + and - is just straightforward. I would not expected intereference or incompatibility with any other software from these, and for the tests that we made so far everything works fine. I'll take this one back, in the context of my other mails + and - look like a sane solution. Eckhart Wörner ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - TMC - New tagging scheme for TMC
Hi, Am Mittwoch, 11. April 2012, 15:42:29 schrieb fly: I still do not get one major point which was totally left out on the first scheme. What actually belongs to a point and how are they tagged. Especially on big crossings and roundabouts I always was confused (e.g. it might be possible that a part of this point is blocked but how do I know which one and you might be able to use the first/last exit/entrance of a junction but not the rest. ) Indeed, this is what I was worried about as well. Here's a proposed (partial) fix, which starts from the original proposal. Let's assume that 123, 456 and 789 are connected LCD which describe a road. Further assume that at 456 there's a big intersection. Then: - All ways between 123 and 456 are marked tmc=DE:123+456, and all ways between 456 and 789 are marked tmc=DE:456+789. - All ways on the intersection 456 leading from 123 to 789 are then marked tmc=DE:456+. This has several advantages: - A traffic jam between 123 and 456 will not block the intersection 456 anymore. - Exits are defined as follows: an exit at 456 in positive direction starts at a way that is tagged either tmc=DE:456+ or tmc=DE:123+456 (from), uses a node that is part of a way tagged either tmc=DE:456+ or tmc=DE:456+789 (via) and ends at a way that is tagged neither tmc=DE:456+ nor tmc=DE:456+789, nor tmc=DE:123+456 (to). An exit is therefore a maneuver. This may sound a bit technical at first, but none of this is exposed to the tagging, and the idea of an exit is probably quite intuitive. - Likewise, entries are defined. - Automatic consistency checking is still possible, as there are no holes. There is at least one issue that still has to be addressed: this tagging does not imply an ordering of the exits / entries; it is not clear what the first, second… exit would be. Eckhart Wörner ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - TMC - New tagging scheme for TMC
Hi, (sorry for starting a new thread, I just subscribed to the list) infoware GmbH, Bonn, Germany, and Geofabrik GmbH, Karlsruhe, Germany, have developed an improved tagging scheme for TMC data which we would like to propopose to the OSM community. I believe this is much needed, so thank you for starting this effort. The one thing I like very much about the proposal is that it allows people to start using TMC information without spending too much time implementing insane heuristics or programming shortest path algorithms. However, I feel like there are some problems with your design, which should be discussed on a mailing list, since Wiki discussions are ugly. 1) The big problem: missing directional information Let's assume there is a way in OSM tagged tmc=DE:123+456;DE:456-123. One also has real-time traffic information that talks about a traffic jam at LCD 456, negative direction, extent 1. One therefore knows that this traffic jam affects DE:123-456, and since we have a way with that information, we know that this way is affected. However, there's one problem: which direction of the way is affected? It could be either the direction from the first point of the way to the last (called forward from now on), or vice versa (backward). This essential information is missing and makes the TMC information on non-oneway ways useless. There are several solutions to this problem. Probably the best solution is not using the tmc tag at all, but using tmc:forward and tmc:backward instead. Thus assuming the direction of the way is from LCD 123 to LCD 456, the tagging would be tmc:forward=DE:123+456, tmc:backward=DE:456-123. forward and backward are already used in tagging (for example, maxspeed:forward) and are also protected by tools. E.g. if you try to reverse the before-mentioned way, JOSM suggests to swap tmc:forward and tmc:backward (which is the correct thing to do in that case). 2) A matter of taste: + and - I'm not sure how others are feeling about this, but I find DE:123+456, DE:456-123 somehow confusing. Here's an alternate proposal: DE:123+456 becomes DE:123-456, and DE:456-123 becomes DE:123-456 (notice the changed order). Therefore, the LCD order is encoded in the position of the numbers, and the movement between the LCDs is encoded in the arrow. I would go even one step further and allow ← (LEFTWARDS ARROW; U+2190) and → (RIGHTWARDS ARROW; U+2192) as an *alternative*. I know that not everybody knows how to enter these codes, but every editor and every operating system nowadays should be able to display them, and we have full unicode support in the database. Because of 1), DE:123/456 does not make sense at all. 3) Bad influence: TMC information at junctions One thing that I cannot wrap my head around is the TMC information *at* junctions. As far as I remember, a traffic jam at LCD 456, negative direction, extent 1 affects the road *between* LCD 123 and LCD 456, but not the actual junctions 123 or 456. However, the rules of adding tmc tags to the actual junctions influence a lot of maneuvers going over those junctions but not using any other part of the way. This is especially true for roundabouts or junctions between dual carriageways. 4) Exits and entries TMC specifies messages that apply to entries or exits, which I feel are not adequately represented in the proposal, even though the proposal mentions them. For example, assume that the 2nd exit slip road going west at Köln-Süd (where I already discovered the new tagging) is closed (and I believe there is a TMC message for that). How do I find this 2nd slip road? (Yes, I picked a really hard one.) 5) Versioning You argue that versioning is not needed, since data can be changed in a timely manner, and the errors that appear are mostly harmless. I don't feel that way: a) Experience tells that data is not always changed in a timely matter, especially since TMC data does not appear on most of the maps. It takes a while to process data (being half a month outdated seems to be normal even for online routing), and offline maps make this situation worse (just look at the bug reports at MapDust that appeared since Skobbler had started shipping offline maps). b) When LCDs are inserted into chains, things break *badly*, since the extents are then out of sync as well. Eckhart Wörner ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
