Re: [Tagging] access in the wiki: move psv to by use
I have interpreted psv (public service VEHICLE), bus and taxi as vehicle categories in the past, but never required these keys in my area. So for me an empty taxi is allowed on taxi=yes. it is not a question whether it is empty or not (it might be going to pick up someone) but whether it is in service. in service was (and is) not required by the definition description of the psv tag or the taxi. Only in bus it was mixed in (acting as a public service). There is no way to tag taxi in service so far in OSM, only taxi (as a car category). So I do not agree that taxi and psv belong to the by-use group. I strongly suggest to move psv, bus and taxi back to the original place in the wiki! There are two issues, nobody has probably paid attention on so far: 1) public service is not public transport, as intended by the creators of the key. So if people make a road cleaning truck or an ambulance a PSV, then this was maybe not intended, but a result of ambiguous documentation/naming. if you look at wikipedia for instance: http://en.wikipedia.org/wiki/PSV this get's redirected to bus, so my guess is, that the common usage of this term is the same than the definition in OSM and not including all kind of public vehicles. Most mappers are not native English speakers. We can only guess what they really understand and have understood. But I don't think it is an intuitive tag. The source of defining psv as bus+taxi (taxi as public service is questionable by the way) is probably UK: https://www.gov.uk/psv-operator-licences But that does not make the tags intuitive. Non-intuitive tags sadly don't work well, no matter how good the wiki-documentation is... 2) Introduce value public_transport omnibus=no bus=yes can also be expressed as omnibus=public_transport IMHO we can stick to psv. not clear to me. psv for what? Separating bus as vehicle category from by-use - and putting it into a value like - is not just more consistent: It is more flexible (I can distinguish between taxi in service and any taxi the same way), it easier to understand what omnibus=public_transport means, compared to the current bus=yes. 3) Depreciatepsv (or broaden the meaning to all public service because of the JOSM turn restriction plugin? What about changing that plugin? no, the argument for depreciation was: There is no need for this artificial group: Grouping taxi (both in service as well as not in service) with only those buses acting as public transport. Taxi access and bus access are distinct things. No ambiguous, poorly understood (here the poor plug-in just confirms that PSV is not well-understood) short-cut like psv is needed. If taxi and bus can access, why not bus=* taxi=*? 4) Depreciate tourist_bus: There is no longer the need for tagging both (bus=yes and tourist_bus=yes) in the case any bus category is meant. It can be expressed by omnibus=yes now. not sure. I introduced this key because of a sign that said explicitly: tourist_bus=no. OK, didn't know the history about a sign. I thought it was introduced because bus was not covering all buses: Without tourist_bus it is impossible to tag that no buses are allowed. bus=no is not sufficient, because it was restricted to acting as public transport. In the current schema accurate mappers must map http://commons.wikimedia.org/wiki/File:Vorschriftszeichen_7f.svg as bus=no *and* as tourist_bus=no. I would bet many mappers haven't done this, because bus is misunderstood. By the way: The key name tourist_bus is also non-intuitive, not every non-public transport bus is a tourist bus. martinq ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] access in the wiki: move psv to by use
Hi, I propose to move psv (including taxi and bus) from the vehicle classes section to the section by use, because that's what it is. maybe that is what it should have been in the past. Sadly the actual use in real world tagging seems to interpret bus also as vehicle category (means the vehicle is registered as bus, in Europe class M2 or M3). Example: 3000 uses of maxspeed:bus, I am pretty sure these uses refer to vehicle category and not the use... See also http://wiki.openstreetmap.org/wiki/Talk:Key:access#Bus_has_multiple_meanings for an older discussion on the meaning of bus. There was no final agreement. Possible solution: use/purpose goes into the value, as we have already done it in agricultural or forestry (agricultural=* means vehicle type, *=agricultural means agricultural use), the key gets a vehicle category: bus=* refers to a vehicle registered as bus *=public (or public_transport, which is clearer but longer) if the vehicle in the key is used for public transport (public access, driving with strangers, no private negotiation needed) Example: bus=public_transport -- a registered bus is only allowed to access if it is used for public transport, excluding for example rented tour buses. bus=yes -- all registered buses can access, including hired buses Obvious issue: 200,000 uses of bus... Further refinement, e.g. bus:m2 or bus:m3, is possible, but I hardly see any need for this. -- Similar for taxi: taxi=* refers to vehicles registered as taxi. *=taxi (or taxi_service for clarity) refers to the use as taxi Examples: vehicle=taxi(_service) -- Only vehicles providing taxi service (no matter if small buses or special passenger cars) can access, so empty taxis cannot pass taxi=taxi(_service) -- Only vehicles registered as taxi AND providing taxi service can access taxi=yes -- Vehicles registered as taxi can access, including empty taxis without passengers Also here further hierarchical refinement is possible, e.g. taxicab and taxibus, but I do not see the need for this at the moment. There is a drawback of the use in values approach, but only for rare cases: 1) There is still no supported/accepted way to tag multiple values for the same key. But the more values we define, the more likely the demand for multiple values. 2) If other restrictions (maxweight or - more precisely - maxgcweight, maxgcweightrating or maxactualweight) are made conditional, we need an update of our conditional tagging, for example by introducing use: A maximum weight rating of 7.5 for everyone except public transport bus or agricultural traffic maxgcweightrating=7.5 maxgcweightrating=none @ use=agricultural maxgcweightrating:bus=none @ use=public_transport martinq ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] access in the wiki: move psv to by use
Hi, sorry, made a mistake: 2) If other restrictions (maxweight or - more precisely - maxgcweight, maxgcweightrating or maxactualweight) are made conditional, we need an update of our conditional tagging, for example by introducing use: Of course this is already possible in conditional restrictions without use=: So the given example can already be expressed with the existing conditional restrictions: A maximum weight rating of 7.5 for everyone except public transport bus or agricultural traffic maxgcweightrating=7.5 maxgcweightrating=none @ agricultural maxgcweightrating:bus=none @ public_transport There is no issue #2, no modification needed, the use-values already work. martinq ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] access in the wiki: move psv to by use
Obvious issue: 200,000 uses of bus... OK, probably most of them are associated with public_transport (e.g. bus stops). So the number of bus related access-restrictions is probably much lower. martinq ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] access in the wiki: move psv to by use
I started mapping in Jan 2008. By that time it was already clear that psv was taxis and buses. If we start questioning every consensus (even those documented on central pages of the wiki like the access-page) we can stop mapping now ;-) I have interpreted psv (public service VEHICLE), bus and taxi as vehicle categories in the past, but never required these keys in my area. So for me an empty taxi is allowed on taxi=yes. There are two issues, nobody has probably paid attention on so far: 1) public service is not public transport, as intended by the creators of the key. So if people make a road cleaning truck or an ambulance a PSV, then this was maybe not intended, but a result of ambiguous documentation/naming. 2) Taxi is actually not really a means of public transport (maybe disputed, I am sure several definitions of PT exist). The inclusion of taxi supports the misunderstanding that the psv key means a broad range of public service vehicles (road cleaning, etc.). -- Not sure if we can fix this misunderstanding (turn restriction plug-in) retrospectively in our database. Probably psv is broken now. But I do not see any real need for it. It is just coincidental that taxis can use bus lanes in some countries, I do not see the need to create a hierarchy just for this purpose. We can tag it with taxi and bus separately, PSV (or PTV) is a rather artificial group. -- Also the approach to mix use (public service/transport) with vehicle type was probably not the best choice back in the early days. It created the weird issue of requiring a new category for buses not used for public transport, since orthogonal use and type cannot be freely combined. For my suggestion to use key/value for category/use, e.g. bus=yes (any registered bus), bus=public_transport (only buses used for public_transport) [see other post] it is probably too late, even though the use of bus as access-key (and not as public_transport key) might be limited. Better backward compatibility I refine my proposal in the other post a little bit: 1) Update key hierarchy: + omnibus Vehicle registered as bus +++ busOmnibus vehicle, used for public transport at point of access 2) Introduce value public_transport omnibus=no bus=yes can also be expressed as omnibus=public_transport 3) Depreciatepsv (or broaden the meaning to all public service vehicles) 4) Depreciate tourist_bus: There is no longer the need for tagging both (bus=yes and tourist_bus=yes) in the case any bus category is meant. It can be expressed by omnibus=yes now. martinq ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] access=exclusion_zone
Hi, have I missed some discussion on a list, wiki or forum -- or has access=exclusion_zone been added to the wiki (http://wiki.openstreetmap.org/wiki/Key:access) without proper discussion (voting process)? I do not see any significant difference of the new value compared to the already existing access=no or access=private. martinq ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] gross weight - conclusions changes
there is one additional observation from my side: 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. b) Even though I don't like abbreviations in key names, I propose 'maxgcw' and 'maxgcwrating' for the combination (truck+trailer) variants. Otherwise the tags get very long (maxcombinedweightrating). I also considered the alternative train or GTW, which seems to be more common in UK. But I am afraid that in an international context train may be misunderstood or misinterpreted. Any opinions? By the way: I saw the first use of maxgrossweight on taginfo. Sorry that I propose a change of the key name now... martinq ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] gross weight - conclusions changes
Then what about maxactualweight as its counterpart? yes, good idea. Better than maxladenweight, which can be misunderstood as the weight of the load. martinq ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] gross weight - conclusions changes
Do we really need 2 tags, maxgrossweight and grossweight? What is the difference? - maxgrossweight is a key - grossweight is no key. It is a property used on the right side of conditional restrictions, for example to express a speed limit that only applied to vehicles with a certain gross weight. Same as: maxlength/maxheight/maxwidth (key) vs. length/height/width (property in conditional restrictions). IMHO you can assume that maxweight is about the actual weight (this is for 4 years on the wiki: Discussion gave me a different impression. The issue is that the wiki page did not make people aware that different weight types exist. Therefore I - and also other people on this list - assume that maxweight has been used for anything that looks like a weight limitation. Additionally, be aware of your regional bias: If I look for example at this page: http://wiki.openstreetmap.org/wiki/Road_signs_in_the_United_Kingdom both signs (No goods vehicles exceeding maximum gross weight and Maximum weight) are suggesting maxweight for gross weight limitations. It does not matter how many people have used this specific page: It just demonstrates that the author of the page - working with the best intentions - came to another conclusion. And if there is one author, there will be mappers too. [...]Obviously mappers that notice the problem will correct it, where grossweight (maxgrossweight) was intended but maxweight was tagged. Only gradual replacement by new more precise tags and the recommendation to use the new tags instead of the inaccurate 'maxweight' [deprecate maxweight] makes sense. -1, I'm against burning a well established and defined tag just because on one other recent wiki page there is a problem in the examples section. Better correct that contradiction. It is well established, but sadly used in for different weight types, which makes it useless for data users: maxweight=5.5 can mean completely different things now. If it was for vehicle weight, I can pass with 5t truck + 5t trailer. But if the mapper meant gross weight, then I cannot pass with my unloaded permissible gross weight 7.5t truck... We cannot redefine the meaning and hope that people start checking every maxweight sign (how do people know that it has already been checked?). The only clean way is to deprecate maxweight, inform people why its no longer recommended to use it -- and the good reasons for doing this. This makes it possible to distinguish between old and ambiguous weight limit and the new limits with more precise meaning in the future. I cannot agree that 'maxweight' is burned simply because we deprecate it: The maxweight definition on the wiki and maxweight tag will remain in the database for many years. But we should stop adding more ambiguous 'maxweight' tags and start a gradual replacement of old 'maxweight' tags with their more meaningful counterparts. martinq ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - gross weight
There is no (common) restriction that limits the actual weight of truck+trailer, thus it makes no sense to define maxweight as limit for the complete train. ... this one is for gross weight of vehicles _including_ trailers: http://commons.m.wikimedia.org/wiki/File:Zeichen_253.svg Yes, see second part of my posting you responded to. But the example does not support your original idea of defining maxweight (=*actual weight* restriction) for complete trains instead of vehicles. It only supports it for gross_weight, but this was already pointed out by me. To focus back on the original topic: What is your conclusion regarding the proposal and the tagging of these restrictions? The crucial part is to keep tagging simple. We cannot expect that everyone knows the subtle legal differences (I didn't know them until I have done my own investigation). A trade-off between pure road-sign tagging (which makes interpretation difficult) and the meaning (which is complex due to vehicle, trailers, weight types, etc) is required. martinq ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - gross weight
With this it would be: - max_weight: the maximum weight of the complete vehicle (including truck and trailer, in the German traffic rules (Straßenverkehrsordnung, StVO) that's a Zug; if I interpret my dictionary right, in English it's a road train. -1 There is no (common) restriction that limits the actual weight of truck+trailer, thus it makes no sense to define maxweight as limit for the complete train. Let me explain: http://commons.wikimedia.org/wiki/File:Zeichen_262.svg limits the permissible weight of a *vehicle*. The truck and the trailer are TWO distinct vehicles (!), thus - for the sign given above - the truck alone and the trailer alone must stay below 5.5t. The complete train may have a weight up to 11t! This it is not a good idea to define maxweight as weight limit for a road train. Instead we keep 'vehicle', the legislation of the country will define what is a 'vehicle'. Mappers should not have to worry about the exact interpretation of 'vehicle' in the context of semitrailers, agricultural tractors with trailers, etc. - maximum gross weight: (however the tag is called then): the maximum weight the complete road train is allowed to have if fully loaded. This sign http://commons.wikimedia.org/wiki/File:Vorschriftszeichen_7a_Gewicht.svg restricts the gross weight. But for highest level of confusion and inconsistency, the Vienna Convention restricts the gross weight of vehicle or combination of vehicles and not just vehicles, thus contrary to the road sign above, the trailer must be included. I sadly overlooked this. Thus if we define maxgross_weight per vehicle, the road sign cannot be tagged as maxgross_weight:hgv=5.5 as proposed. The proposal needs a fix! Since it applies to vehicles plus any trailers and not just vehicles (which are defined differently). And defining it as vehicle+trailer will add confusion and may not work in the international context outside the Vienna Convention countries. Any suggestions how to fix this? a) Introduce maxgross_train_weight=X? b) Keep maxweight=X, flush maxgross_weight (looks odd anyway) and add a new tag: maxweight:type=gross_vehicle, gross_train, laden, empty, etc. to qualify the maxweight? I would additionally define that the definitions + _weight can be used as properties in conditional restriction, eg. maxspeed=80 @ (empty_weight5.5). This suggestion also has better backward compatibility and it also enables country defaults. Drawback is that only one maxweight-restriction per way is possible. Opinions? martinq ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - RFC - gross weight
maxgross_weight: All vehicles have a registered upper limit on their allowable mass (when fully loaded). This is often known as the Gross Weight, and it is found in the vehicle documentation. unfortunately it is more complicated because the amount of axis and eventually the weight of trailers also have to be taken into account, therefore I'd prefer to have a reference from the osm definition (where it applies, e.g. European Union) to the legal documentation or copy these settings from the relevant legal code. (sounds more complicated than it is, I.e. s.th. like gross weight rating as defined by the law where applicable) 1) In Europe the number of axles only play a role for the *maximum* possible gross weight for vehicles registration [in other words: the maximum maximum permissible weight]. If there is a signposted restriction to for example 5.5t gross, then it applies to all vehicles no matter how many axles they have. Thus the tagging is not affected. Note: I know that in US there are weight limits depending on the number of axles, but this could be tagged (later or already?) by conditional tagging like maxgross_weight = X @ axles3; Y @ axles4... 2) Trailers: In fact the gross weight applies to trailer and main truck separately [as far as I know, since both are more or less legally treated as separate vehicles], thus if there is a limit of gross 3.5t, then the truck gross and the trailer gross must be below, but both together can exceed the limit [as far as I know this also applies to weight limits, e.g. at bridge with max 3.5t weight limit the trailer and the truck are evaluated separately, but I haven't cross checked this]. But does this affect the proposed tagging? We tag the rules (e.g. here is a gross weight limitation), but not how they have to be applied in a specific case (does this limit apply for trailer and truck separately or combined?). As of the suggestion maxgross_weight wouldn't it be better to use gross_maxweight? Looks a little bit engineered, since tags typically use the natural language order of words. But even I must confess that maxgross_weight looks also odd due to the '_' inconsistency. Since I cannot foresee a meaning conflict by just using the abreviated maxgross, this could be an alternative. martinq ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature proposal - RFC - gross weight
Restrictions on road access in many countries of the world make use of two different types of weight: 1) Actual weight of vehicle including empty vehicle + driver + passengers + load [the weight on a weighbridge] 2) Maximum permissible weight for a vehicle, typically used for registration and found in vehicle documents [and is a fixed number for a specific vehicle, not depending on the load] But current tagging does not distinguish the two types, neither maxweight=x nor access:conditional=... @ (weightx). But the difference is important for HGV routing and truck drivers and should be tagged more precisely. Since most car driver [and thus the average mapper] typically don't have to care know details about weight restrictions, I assume that many mappers are not aware of the subtle difference in the meaning of weight related road signs [at least I haven't until I investigated the situation]. Thus I decided to summarize previous discussions and my knowledge in following proposal: http://wiki.openstreetmap.org/wiki/Proposed_features/gross_weight I have added many examples to illustrate when road signs mean gross weight and when the refer to the actual weight. To avoid a German/Austrian bias I based many examples on the Vienna Convention on road signs and signals, which has been implemented in many countries in the world (this convention is the reasons why road signs look very similar in many countries). I know that some countries have not fully implemented this convention and thus there a country specific deviations, thus please update the comment column of the example if your country deviates from the convention rules. martinq ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Key: turn
Am 26.12.2012 12:57, schrieb Johan C: The key:turn http://wiki.openstreetmap.org/wiki/Key:turn has values for slight_left/right and sharp left/right. There are no signs associated to these four values. I also couldn't find any corresponding signs on this page: The history behind adding these values (and not just use left and right) is explained here (when :lanes was proposed): http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/lanes_General_Extension#Sharp_left.2C_left.2C_slight_left Short summary: It was not introduced for satnav purposes. There are links to examples which makes it more obvious that left and right is not sufficient to indicate the *lane* markings in all cases (also look at the non-standard arrows painted on the road). martinq ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Gross vehicle weight rating
Hi, How does this compare to other countries? The Vienna Convention on road signs is always a good basis for such discussions. It harmonizes the meaning of traffic signs in almost 100 countries of the world. Consolidated version of the convention: http://www.unece.org/fileadmin/DAM/trans/conventn/Conv_road_signs_2006v_EN.pdf UK has signed this convention, but never ratified it. Until today I haven't found major deviations from the convention in Europe. Section 5.15 (page 35 describes the sign with the image of a HGV and a weight restriction number. It clearly states that this is a restriction for environmental reasons (e.g. where roads are narrow and unsuitable for large vehicles, or to protect residents from the nuisance caused by lorries in residential streets) and is not used for structural limits. It appears that this is a Gross Vehicle Weight Rating (GVWR) from the sentence stating that the limit applies even if unladen and below the weight. The meaning is in accordance with the Vienna Convention. In Austria and Germany the sign has the same meaning, even though we use variants allowed by the convention: Austria places the gross weight below the silhouette of the HGV (but still in the sign), Germany uses additional panels below the sign containing just the goods vehicle silhouette. The convention defines the weight value as permissible maximum mass, which is based on the vehicle's registration. In Austria the sign is also often used for environmental reasons, but we do not write it into our law. The important thing is the meaning for the drivers, and this is independent of the reason. BTW: This sign (without additional panels modifying the meaning) does not apply to buses or agricultural vehicles -- only to goods vehicles. Section 5.31 to 5.33 gives the other sign (the one with a weight limit that applies to all vehicles). Again this is a maximum weight rating: Specifying gross vehicle weights makes enforcement simpler as it is necessary only to check the vehicle’s plated weight against that on the sign, eliminating the need for a vehicle to be taken to a weighbridge for checking. The UK sign deviates from the sign [C,7] in the convention by the letters mgw (mgw is not defined/allowed in the convention). The convention sign without mgw and just the weight figure (e.g. 7.5t) means NO ENTRY FOR VEHICLES EXCEEDING ... TONNES LADEN MASS, and laden mass is defined as the actual weight (drivers, passengers, load and vehicle itself) and NOT as gross weight of any kind. I assume most countries follow the convention (Austria and Germany do), thus the current definition of maxweight makes sense for many countries. If UK has tagged the mgw sign with maxweight, then this is IMO not in accordance with the wiki definition. martinq ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Emergency lane used by PSV at rush time
Hi, You could combine Conditional restrictions and the lanes suffix¹: [...] psv:conditional:lanes = | | yes @ rush_time There are a couple of issues here 1. I did not include 'lanes' when I created the Conditional Restrictions scheme (mostly not to complicate the discussion and voting process of the proposal). It could be done as suggested by you. However, I would prefer to write the key as psv:lanes:conditional in order to be consistent with other uses of conditional where the unconditional and the conditional tags can be distinguished just by the :conditional suffix. I may add this to the wiki page. Disagree. Both variant express a different meaning: key:lanes:conditional expresses that all lane values depend on a condition: maxspeed:lanes = 100|80 maxspeed:lanes:conditional = 80|60 @ So key:conditional:lanes expresses that the conditional restriction values depend on the lane: maxspeed:lanes = 100|80 maxspeed:conditional:lanes = 80 @ So | For practical tagging I think it is too theoretical for most mappers to understand the difference. For mappers and parsers it might be easier to request using parenthesis around conditional restrictions/values containing special characters: maxspeed:lanes:conditional = maxspeed:conditional:lanes = (80|60) @ So - or, 2nd example above - maxspeed:lanes:conditional = maxspeed:conditional:lanes = 80 @ So | The values are unambiguous (giving '|' technically a higher precedence) and the order of suffixes no longer matters. Then we can propose a preferred order. This way we also solve the issue with multiple values separated by ';': access:conditional = (delivery;forestry) @ So martinq ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
Colin, Martin, if it walks like a duck and quacks like a duck, then it had better be a duck... What I mean with this, is if the grammar is so English-like such that people are tempted to use constructions which are not (or not quite) supported by the grammar, or if the way it works is contrary to how the English language would interpret it, then errors will occur. Now, the primary intention was to allow to transfer conditions from sign-posted information as natural as possible. Due the fact that space is limited and people must be able to read it during driving, they use a extremely simplified language - mostly nouns plus words like except, if, when, on, then... You don't get a Nobel Prize for Literature for text like except vehicles less than 5m long (also in several variants, e.g. except vehicles with length5m). But nevertheless your point is valid. If we give the impression computer understands sentences, soon or later we will find things like tracktype:cond = grade2 if weather was good for more than 3 days, grade3 after a day of rain, grade4 after a thunderstorm. I haven't taken this into account. Plus, of course, that the majority of users will not have English as their first language, and we have to make this accessible to the man-in-the-street and not allow it to become so obfuscated that only PhD's need apply. As I said, for information (exceptions, conditions) typically sign-posted, you typically don't need a PhD. The parser can understand quite amazing amount of signs just with the nouns we have already defined for vehicles plus the properties (length, weight - plus variants like long) and a few the date and time (Su or Sunday, etc) things also described for other tags. For mappers that are not familiar with the English language, the benefit of the proposal is clearly massively reduced. [...] If you start with the premise that the answer must be expressed in ANTLR and shouldn't include brackets, that's putting the cart before the horse. The objective was to be able to understand sign-posted sentences. I picked ANTLR to play around - but no must. I also said I want to avoid to use brackets just for solving precedence problems - thus mappers shouldn't have to add brackets if they are not used on the sign. But one clear issue is the lack of a bigger amount of examples. Human language is sadly not very precise: except taxis AND bicycles does not mean, you must be in a vehicle that is both (it means if not taxis AND if not bicycles), The human language here is extremely precise to any fluent English-speaker. It means what it says. Yes, no ambiguity here. Picked a bad example. If I were king I would be looking for a system that: Huh, a new condition, added it to the parser. maxspeed:cond = 200 if your are king ;-) * makes common cases easy * makes complex cases possible * makes each rule as standalone as possible (one sign - one rule) * 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) Signs use extremely simplified language. Thus almost every word on the sign has an essential meaning and has to be translated into a system also using English nouns. But I haven't forgot your valid point - if people think that it is free-text English, then we will soon or later see fancy conditions. * uses grammatical constructions which are familiar to most people, or easily learnt The normal form is not easy to learn - this has to be made in addition to the own language - English translation. But translating simplified text from one language to a simplified English may also be a problem. Thus no major advantage here for the alternative proposal. However, looking to most signs, you will see combinations of one or two attributes plus time related information only. In this case the normal form is no challenge (but same is true for the simplified sign-language English). Outlook: Yet the parser cannot parse complex conditions, the extensibility requirements is therefore not fulfilled. Thus there is no alternative sign-language proposal yet. And it looks like it is not feasible with reasonable effort or unreasonable restrictions/rules (then we better stick to the normal form). IMO, the work done may be helpful for an editor: People can enter the sign-text and the editor converts it to normal form with standardized nouns and conditions. This tool may support several languages instead of just English. martinq ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
motor_vehicle:forward:(Mo-Fr 16:00-18:00) = agricultural goods:forward:(Mo-Fr 16:00-18:00) = yes motor_vehicle:backward:(Mo-Fr 16:00-18:00) = agricultural goods:backward:(Mo-Fr 06:00-09:00) = yes This is the point where I think it would be worth to start prefixing the expression by access (I would use the chance of the new proposal). The fact that access is omitted, has mainly historical reasons. hgv=yes actually is just a shortcut for access:hgv=yes, which would be more consistent with the remaining tagging system, e.g. maxspeed:hgv. access:(Mo-Fr 06:00-09:00)=yes access:female=no ... instead of (Mo-Fr 06:00-09:00)=yes female=no martinq ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate: first summary
* 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 Human language - no My proposal you are referring to was mainly to directly tag the (simplified!) language posted on the signs - not full human language. But meanwhile I changed my mind about my own idea. I would propose a new approach regarding human language: - We should offer a way to tag what they see on the signs, but not intended to be understood by machines. This way we can keep mappers happy that do not want to learn a technical language (normal form, logical transformations, etc.) for expressing conditions, for example by offering a tagging schema like: maxspeed:posted = 80 except HGV more than 10m long maxspeed:posted:DE = 80 ausgenommen LKWs mit mehr als 10m Länge It's not thought through, e.g. what happens if there are multiple additional signs with conditions. It also acts as kind of source information - or could be used by navigation software to display the condition as human readable text. And it allows other mappers to identify errors (inconsistencies) in the translation. - The tagging itself should follow stricter rules. Validators or other tools may be used to spot untranslated information of point 1) and mappers familiar with the condition tagging can transform it into the machine friendly form. Here we should continue improving the proposal(s) on the wiki. * most people argued that tagging should be human-readable I would interpret this as: Understandable without wiki lookup for the majority of cases (=mostly intuitive). * 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 I think we should distinguish between writing conditions and reading conditions. - Writing - editor support - Yes, agree (see also below) - But for reading, editor support is more tricky, because translating it back into human readable language form is in principle possible, but ambiguous (several posted text variants can result in the same tagging). Thus I would strongly prefer that the tags itself are understandable - see above. I would also like to ask people not to blindly start new proposals, because otherwise we'll inevitably end up with hundreds of proposals and no conclusion at all. I will cancel my proposal due lack of support and missing benefit (what I wanted to achieve - and what was intended to be the benefit - does not work so far). For me it makes more sense now to: 1) Provide a option to document posted conditions, but not trying to make it machine readable (in the language of the mapper) 2) Provide editor support (with a parser, maybe based on the work I have done so far on the proposal) to allow semi-automatic translation of posted information into conditions directly in the editor (helping people to learn conditions). This can be provided for different languages (e.g. also in German, French...), maybe also local variants, because text conditions posted on signs have a typical structure 3) Use a machine friendly (=stricter rules) - but human readable tagging for the conditions 4) Think about a tool that spots missing translations of 1) My favourite is clearly the extended conditions proposal. But it needs - as stated - some further development from an idea to a complete proposal - but I will do that directly in the wiki. martinq ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dispute prevention: meaning of lanes tag
I've had a look for uk guidance as the uk's ordnance survey was mentioned, and a lot of older uk advice appears based around a now historic view that 'cars = saloon cars' and were 1.8m or less. If cars were assumed to be 1.8m wide then implied OS figure of 4m for two lanes makes sense. I am not sure we should base the lanes tag value on typical car width. IMO the lanes tag should *not* be another kind of estimate for the width. A further problem is the definition: For example the euro track has a maximum allowed width of 2.55m without mirrors (refrigerated ones even 2.60m). This would be as fair as basis as a average car in UK or a UK guide. And in US or India we may find another situation again. My opinion: If the width of the road can be estimated and no lanes are marked: We should tag the width (of the carriageway(*)) only (or est_width or width+source:width) and no lanes tag. (*) Sadly the width itself is pretty ambiguous tag at the moment (e.g. is it the width of the complete street or just the carriageway, etc.). But this is a topic for its own. When you look at following example: http://wiki.openstreetmap.org/wiki/File:Bangalore_India_traffic.jpg then I conclude: If there are no marked lanes, it lanes gets simply too subjective. My current practice: On non-residential areas (tertiary, etc.) I typically tag lanes=2 only if the road allows *two* trucks (that don't require police escort because they are wider than allowed, means 2.6m) to pass. In my area this means 5.2m. In residential areas/streets I omit lanes if they are not marked. Parking allowance and parking cars on the street/carriageway make the situation very complicated. Look here: http://bit.ly/I2hna7 While the carriageway in this example is more than 6m wide and allows two trucks to pass, you also see parking cars in this street (I don't know the German law, but they might be allowed to do that). What would you do now? And if the parking allowance is time limited? For me lanes is simply not applicable here. -- I would tag the parking information with parking:lane, width, but not lanes. What I also propose: If lanes are marked, but narrow for trucks (e.g. just 2m each), I would tag them width:lanes=2.0|2.0 now. If there is a dedicated maximum width road sign -- maxwidth. Though I'd think a road 4.3m wide would fall under the 'lanes=1.5' idea [...] After reading through these emails I'm beginning to think the lanes=1.5 would less confusing for narrow two lane roads. -1 1.5 makes no sense. If we can agree that a lane is a strip, which is wide enough for one moving line of motor vehicles other than motor cycles (from the Vienna Convention of Road Signs, used as basis for local law in many countries all over the world) -- then either one line of vehicles can move -- or two. -- For me this lanes=1.5 is a clear indication for an attempt to turn the lanes tag into a rough width-estimate. I think the width tag is the better tag for width-estimates. martinq ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
