Re: [Tagging] Access restrictions for shoulder lanes?
Getting back on topic for a moment Hard shoulders should be access=no, not access=breakdown or access=emergency (the last two shouldn't even exist IMHO). The baseline is that you shouldn't be there at all. You get away with it if you have permission (blue lights) or no choice (breakdown) although it seems there may need to be parking restrictions or minimum speed tags added in Oklahoma. There are of course hard shoulders which are opened as running lanes during certain hours or in certain conditions. In that case they alternate between access=no and access=yes/motor_vehicle. This is what the access:conditional tag is for. On 2015-02-03 11:15, Paul Johnson wrote: On Feb 3, 2015 4:11 AM, Philip Barnes p...@trigpoint.me.uk wrote: On Tue Feb 3 09:36:21 2015 GMT, Colin Smale wrote: On 2015-02-03 10:20, Paul Johnson wrote: On Feb 3, 2015 3:06 AM, Colin Smale colin.sm...@xs4all.nl wrote: Preventable? How does that look in law? Is that Failure to maintain the vehicle or what? What exactly will you get a ticket for? Running out of fuel is certainly a case of a preventable breakdown. Definitely one to do the math on if there's any doubt around here, too. Since you're either on a cattle chute of a motorway with no services or exits, or in the middle of mountains, forests, open prairie or totally uninhabited desert depending on where you travel outside of metro Tulsa or OKC here. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Access restrictions for shoulder lanes?
Assuming you are talking about the hard shoulder AKA emergency lane on motorways, in NL and GB it would quite simply be access=no. The only exceptions are if you break down, if you are an emergency service, or if you are instructed to by the police (or similar authority). On 2015-02-02 14:17, Martin Vonwald wrote: Hi! If shoulder lanes are mapped (for whatever reason!), what access restrictions should we apply? A simple vehicle=no doesn't seem right to me. In some countries those lanes may be accessed regularly, e.g. by pedestrians or motorcycles, so foot=yes + motorcycle=yes is obvious, but what would be the access restrictions for all other vehicles? Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists
Tag namespaces already provide a kind of data structure facility. IMHO a syntax that is close to the traditional way of representing vectors of structures would be something like this: addr[1]:housenumber=1234 addr[1]:street=Main Street addr[2]:housenumber=7654 addr[2]:street=Elm Avenue All house numbers are called housenumber, addr[1] and addr[2] are both instances of an address. In fact, if the : is replaced by a ., it starts to look very familiar Is the maximum length of a value still 255 characters (or is it bytes?)? With the ; syntax we could easily come up against that limit, whereas an array / key-based syntax would allow 255 for each individual value. Obviously (at least IMHO) the data model of OSM would benefit from having a defined method to represent higher-level constructs. Some people are already talking about having an area or a polygon distinct from a way with start=end. Why not have a proper discussion about how to represent lists of values? Of course it helps to have some examples in mind, but let's step back and find a more generic solution which will also address our current problem. I really don't think the fact that some people don't understand regular expressions is a good reason to not look to the future. Once a standard is defined, the software will soon catch up - if the standard is well-specified. If the standard is not well-specified, poorly documented, too many exceptions etc then it will be ignored. Colin On 2015-01-23 17:29, Tod Fitch wrote: On Jan 23, 2015, at 7:47 AM, Richard Welty wrote: On 1/23/15 10:13 AM, jgpacker wrote: I don't understand the insistence in using regexes as some kind of argument against semicolon lists. A semicolon list is an extremely simple pattern. Such a pattern can be easily parsed even WITHOUT regexes. Me and other developers in this thread (Imagic, Friedrich, David, Dmitry, Marc) are trying to tell you semicolons are not a problem. +1 competent languages provide simple mechanisms for splitting strings on single characters. sometimes the function is even called split richard Yes, nearly every scripting language I've used has an easy way to split a string on a character or substring. Is there is a value string that contains a semi-colon that is part of the actual value rather than a delimiter between values. I can't think of any but since for some key names the value field is free form I suppose it could happen. A semantic solution to that would be to document which keys may have (or maybe a shorter list of exceptions that cannot have) multiple values separated by semi-colons. However there is the related question of how to deal with things like multiple addresses for one object, the subject of another current thread. In this case you probably don't want to be dealing with: addr:housenumber=1234;7654 addr:street=Main Street;Elm Avenue So you will be dealing with something like: addr:housenumber=1234 addr:street=Main Street addr:housenumber_1=7654 addr:street_1=Elm Avenue Coming up with a uniform way of dealing with arrays of values would mean that a simple and consistent solution could be used for both problems. I don't much care if the syntax of the key is key:1, key_1, key#1 or key[1] but I do think that something needs to be picked for sets of keys that have related values. And once you do that the solution could be applied as an alternative to semi-colon delimited values in the case being discussed here. Having one approach that solves two issues seems better to me than having two solutions. Yes, any robust data consumer software will have to deal with all the existing ways things are done now. But standardizing on way to go forward should help in the future. Cheers, Tod Fitch ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Boundary Relations. What's a subarea used for?
On 2015-01-09 12:25, Dave F. wrote: I'll leave them for now, as I can work around them, but I'm still not convinced of their use or comments given by others as reasons to keep them. Out of respect to the mappers who have gone before you, isn't a valid excuse to keep data if it's incorrect. The sentiment of what you say is easy to agree with, but determining what is incorrect is exactly what we are grappling with here. Just because you would do it differently, doesn't make it incorrect. I assume that these subarea links are actually correct in a factual sense. Your willingness to leave them for now should really be upgraded to leave them until the community agrees to remove them which IMHO means that another way is found of conveying the same information which we agree is so superior to what we have that it is worth the effort of converting the existing data and data consumer tooling. Colin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - (Obligatory vs. optional cycletracks)
In NL I think it is similar to Germany. The definition of the sign is verplicht fietspad i.e. compulsory cycle track. When the cycle track runs adjacent to a road the intention is clear, but the sign is interestingly also used for cycle paths through the middle of the countryside with no adjacent road. One might interpret this as you MUST follow this path, even if it goes in the wrong direction for you In Dutch law a snorfiets (light motorbike with pedals, max. 25 km/h) is equivalent to a bicycle, but a proper moped (max. 45 km/h) is a different class of vehicle. A snorfiets (called a mofa in OSM - is that a German term?) must follow the same rules as cycles. In some areas a moped is expected to use cycle tracks (the round blue sign shows both a cycle and a moped) but in other areas mopeds must follow the roads. There is also a non-mandatory cycle track which is a path on which it is permitted to cycle. Snorfietsen can use these paths as well of course, but only in in pedal mode (unless they are electric). Colin On 2014-12-22 10:54, Frederik Ramm wrote: Hi, what is the legal situation in different countries - is Germany one of a very small number of countries that has this concept of if there is a certain type of cycleway than cyclists must not use the road, or is this quite common? Bye Frederik ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - admin_title=*
On 2014-12-18 14:42, Friedrich Volkmann wrote: On 17.12.2014 23:23, Colin Smale wrote: In the UK designation= is in wide usage for this. I don't know if it is typically a UK thing (it wouldn't surprise me) but local governments sometimes have the right to change their style - for example a civil parish can choose autonomously to call itself a community council. It can also choose to call itself a town council although I suspect this needs cooperation from its parent authority. And a council can become a city council basically only through a central decision. I think that the name of the council does not matter. Exactly, that's my point. A simple civil parish and Salisbury City Council are administratively equivalent and are both tagged designation=civil_parish. This tagging should not, however tempting or logical some people might think it, be based on the name, but on the legal/constitutional status. Some districts (admin_level=8) have the status of borough. All this doesn't change the legal powers and responsibilities of the council, it's all about what they are called. There's a lot of snobism involved as well... I have tried to summarise a tagging scheme for UK local authorities here: http://wiki.openstreetmap.org/wiki/User:Csmale/ukboundaries [1] So far we have destination=* for the UK, official_status=* for Russia, and name:prefix for other countries. That diversity makes the tags essentially unusable for applications. It's a pity that every national OSM community make up their own tags, without caring what others do, as if there were berlin walls around each country. Finding the right balance between universal, world-wide tagging and local conventions (at whatever level) is one of the biggest challenges we have. Usually any attempt at formalisation gets either shot down in flames by a vociferous minority or ignored by the silent majority. Personally I don't care if the key is admin_title=*, designation=*, or official_status=*. We just should decide for one. +1 from me, good luck with getting the consensus, and then getting the loser to retag everything... Links: -- [1] http://wiki.openstreetmap.org/wiki/User:Csmale/ukboundaries ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - admin_title=*
In the UK designation= is in wide usage for this. I don't know if it is typically a UK thing (it wouldn't surprise me) but local governments sometimes have the right to change their style - for example a civil parish can choose autonomously to call itself a community council. It can also choose to call itself a town council although I suspect this needs cooperation from its parent authority. And a council can become a city council basically only through a central decision. Some districts (admin_level=8) have the status of borough. All this doesn't change the legal powers and responsibilities of the council, it's all about what they are called. There's a lot of snobism involved as well... I have tried to summarise a tagging scheme for UK local authorities here: http://wiki.openstreetmap.org/wiki/User:Csmale/ukboundaries It is not official in any way, they are only my own notes at present - based on current usage and my thoughts to keep my work on these boundaries consistent. I expect the system in Germany is a bit less variable, although the different Länder seem to have very different local government structures. Colin On 2014-12-17 16:25, Friedrich Volkmann wrote: This is about a new attribute for administrative devisions. http://wiki.openstreetmap.org/wiki/Proposed_features/admin_title [1] Links: -- [1] http://wiki.openstreetmap.org/wiki/Proposed_features/admin_title ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Combining gas stations convenience stores
I agree with Greg. Many people still think it is possible to get worldwide consensus on tagging. This will never happen as long as the tags are so subjective. Check out the thread on the definitions of cafe/restaurant/fast_food for a wonderful case of what happens if the input side rules the project. You have heard of ROM? Ever heard of WOM? A large part of the IT budget of large companies is spent on understanding the data they already have. Missing or incorrect documentation, misuse of fields (overloading), no data quality control... I spend my life trying to save them money. Unfortunately every day they are still creating more of tomorrow's legacy. Unless someone wants to declare OSM to be a big data project (store everything you have, just in case it's useful later) and get IBM Watson to find your nearest place to buy a burger. Colin On 2014-12-11 08:34, Martin Vonwald wrote: 2014-12-11 0:52 GMT+01:00 Greg Troxel g...@ir.bbn.com: The main reason is that while designign complicated tagging seems to be what people do, tagging designs should be done from the point of view of those writing code to consume the database and do something useful. 100% incorrect. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Various alt_name values?
Big +1 for that. To me, solving it from the root means formalising the use of the semicolon as a value separator, and cracking some hard nuts like how to handle a legitimate semicolon in the data itself and how to handle the quoting/escaping that that will involve. But let's do it once and once only, so it can be used consistently across all the editors and consumers in our ecosystem. Usually any attempt at formalisation gets shot down in flames by the free-for-all tagging advocates though so I have little hope for this. Colin On 2014-11-27 12:01, Tom Pfeifer wrote: Friedrich Volkmann wrote on 2014-11-27 03:38: On 26.11.2014 18:23, Brian Quinion wrote: At the moment nominatim supports alt_name_[0-9]+:language_code=name for alt names I've added this to the wiki Please don't document values supported by single applications. The wiki should represent values which are in use in the database, or approved by voting. +1 Documenting that a particular software has found a workaround for some odd tagging manifests and spreads the problem, instead of solving it from the root. Tom ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Various alt_name values?
So the root problem is how to support multi-valued keys. Using the semicolon puts the solution into the value, using numbered keys puts the solution into the keys. As (AFAIK) both the keys and the values are limited to 255 chars, I can see that being a limitation for value-based solutions. Just putting :1 at the end of the key is dangerous because this will overlap with the namespace idea. Should you parse a:1 as the first value of key a or as key 1 in the namespace a? Adding _1 will cause similar issues - is a_1 a the first value of key a or is it a key in its own right? These are some of the things which will normalising and documenting. The traditional way of representing a vector element uses some kind of brackets, so we might have name[1]=value. The advantage of this is that it is unambiguous and familiar to many people. Multi-valued keys, if implemented properly in the underlying data model, will require a change to the database layout, the XML/PBF formats, and of course to numerous pieces of software. Colin On 2014-11-27 12:59, moltonel 3x Combo wrote: On 27/11/2014, Colin Smale colin.sm...@xs4all.nl wrote: Big +1 for that. -1. On what do you base your assumption that nominatim is the only software implementing numbered keys ? How is documenting what a major osm software does a bad thing ? For better or worse, the numbered keys scheme sees a good bit of use according to taginfo (it's harder to get numbers on the semicolon scheme). To me, solving it from the root means formalising the use of the semicolon as a value separator, and cracking some hard nuts like how to handle a legitimate semicolon in the data itself and how to handle the quoting/escaping that that will involve. To me, the semincolon scheme as a general solution is a very bad idea, and I'd hate to see it formalised to the exclusion of other schemes. That's because it's so easy for data users to get it wrong. Either the data user forgets to do the split, or he does it when it wasn't the mapper's intent, or litteral semincolons in the data get in the way. In contrast, the numbered keys scheme is a bit ugly and harder to use, but it's very unlikely that a data user would get it wrong. At worse, only the first value will be picked up, which is a more gracefull degradation than the semicolon worst-case. It's still an unsatisfactory solution, and I've been arguing for direct support of multi-value keys in the osm data model, but that's a much longer-term prospect. But let's do it once and once only, so it can be used consistently across all the editors and consumers in our ecosystem. Agreed. And that's why I don't like the semiclon scheme, because I can't imagine it being used in an error-free consistent manner. PS: whiile we're talking about multiple values for the alt_name key specificaly... WTF ? alt_name is already a way to encode 1 additional value for the name key, so if you're describing a scheme to add any number of additional values, apply this scheme to name and not alt_name. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] sport= non-physical tags and the exceptions people come up with...
Let's look at the entity relations in play here. Surely a club IS an organisation, not a building. The club MAY USE one or more buildings, and MAY OWN one or more buildings. A club HAS a contact address, HAS members, HAS a board etc etc. So following the rules of one object, one set of tags, putting club=chess on a building could be considered to be wrong, as the building may be used by several clubs. Bearing in mind how some people hate multi-valued tags with semicolons, how about club:chess=meeting_place? Then multiple clubs could use the same building, each with a different role if required. Otherwise use a simple node (per club) within the building to indicate some relationship between the club and the building. Colin On 2014-11-24 14:36, Richard Z. wrote: On Mon, Nov 24, 2014 at 02:13:07PM +0100, Martin Koppenhoefer wrote: 2014-11-24 13:57 GMT+01:00 Richard Z. ricoz@gmail.com: According to the approved http://wiki.openstreetmap.org/wiki/Proposed_features/Club [1] chess has an own club=chess, as has fishing, automobile, hiking - all of which can be either leisure type or sport type activities. I think club=automobile for a motorsport / racing club would not be very well chosen as this might really mean a lot of different things, some of them clearly neither leisure nor sport, e.g. the ADAC (biggest German automobile club, almost every 4th German is a member, http://en.wikipedia.org/wiki/ADAC [2] ) does organize also some racing event, but is mostly seen as kind of insurance if your car breaks down (and as very strong political lobbyist advocating mainly individual motorized traffic). Documentation of the club tag is very scarse at the moment: http://wiki.osm.org/wiki/Key:club [3] and I am not sure how it can be improved, e.g. if I wanted to write something about club=automobile, would I have to write to all the mappers that have put these 127 club=automobile on the map, to ask what they have used the tag for? I think much the same problem exists with other club=value as well like club=chess? Nevertheless.. you may walk by a building with a tag something like a chess-club and if it is mapped as club=chess it is correct. It is also fairly un-informative but we are supposed to map what we see and not do background checks of clubs with google or wikipedia? Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [4] Links: -- [1] http://wiki.openstreetmap.org/wiki/Proposed_features/Club [2] http://en.wikipedia.org/wiki/ADAC [3] http://wiki.osm.org/wiki/Key:club [4] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] governmental / public_administrative landuse are not commercial
I would not expect the landuse value of the municipal bus company's HQ to change if the bus company was privatised... Only the ownership will have changed, nothing else. Actually, as the buildings are probably leased from a property company anyway, even that would stay the same. Just the shareholders of the company would different. So I would suggest civic or government or whatever should only be applied where the activities taking place there are actually civic administration - council meetings, committees, births/deaths/marriages, highways,. i.e. the core business of a local authority as defined in law. Sidelines like running transport companies or sports grounds are not landuse=civic to my mind. C. On 2014-11-07 08:16, Marc Gemis wrote: My question was indeed for their offices (head-quarters etc.) regards m On Fri, Nov 7, 2014 at 7:54 AM, John Willis jo...@mac.com wrote: That is an interesting question. I think that falls outside the goal of this tag but I am unsure. In America, Amtrak is nationalized, but I think most of their facilities would fall under transportation related things - railway stations, etc. but their main office, which is not a train station, would be landuse=civic(_admin) I think. The bus station would be transportation related, but their office, where all the paper-pushers reside, (who administers the service) Would probably be similarly tagged. Javbw On Nov 7, 2014, at 3:32 PM, Marc Gemis marc.ge...@gmail.com wrote: What about buildings of public transport companies (bus, train, airplane) that are owned and operated by the government. I assume they should be added to the civic part ? I know more and more countries are turning those companies into privately owned, but there are probably countries where this is not the case. regards m On Fri, Nov 7, 2014 at 2:32 AM, Tom Pfeifer t.pfei...@computer.org wrote: To help us making up our minds which tag to prefer, or to check if we should use two of them, I have started a table of use cases that would suit one ore the other tag class better, and started with some examples, on the Talk page. Tom Pfeifer wrote on 2014-11-05 11:21: Matthijs Melissen wrote on 2014-11-05 01:27: I might have missed it in the discussion, but why not simply landuse=governmental? Well that was among my first ideas, hence the subject of this thread. We are currently collecting the arguments for each potential tags on the Talk page, feel free to contribute there or here: https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/landuse%3Dcivic#Alternative_values [1] I start thinking that we might need even two tags, one for the civic/municipal cases and one for the govenmental/administration ones. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [2] ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [2] ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [2] ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [2] Links: -- [1] https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/landuse%3Dcivic#Alternative_values [2] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] default value for oneway
On 2014-08-28 15:53, Dan S wrote: As Peter said, the default for services using OSM is always to assume a way is _not_ oneway unless tagged otherwise. Unless it is tagged as junction=roundabout ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bridge=humpback ?
On 2014-08-10 12:13, Никита wrote: I.e they define this tag as subtype of http://en.wikipedia.org/wiki/Arch_bridge [5]. I don't see any real application/use to bridge=humpback. Also, bridge=humpback does not imply covered=yes by default. It does not define routing aspects or adds any features to end users. In the UK there are warning signs for some humpback bridges, and with good reason - if you don't slow down substantially from the ambient speed you will be launched into orbit. Therefore they should be useful for routers, implying a lower speed on that part of the road. https://uk.answers.yahoo.com/question/index?qid=20120222085933AAsnJiP Some are so humpy that a vehicle with a long gap between the axles and/or a low ground clearance (e.g. a low-loader) may actually be unable to cross the bridge. So I don't think it is right to say that bridge=humpback cannot be of value for routing or end users... --colin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bridge=humpback ?
No need to define it as UK-only... such bridges occur across the whole world, I am sure. The UK may be unique by having a specific road sign, which may indicate that a bridge could/should be tagged as a humpback (as stated in the wiki[1]). There is also a sign for explicitly indicating a risk of grounding often seen at railway crossings. In the UK it can be made objective by linking the use of the tag to the presence of the sign, but then we would miss the many bridges which the average person would call a hump bridge but are not signed as such. I would suggest something like a bridge requiring driving speed to be reduced due to the vertical profile (i.e. not because it is narrow, or some other attribute). Not sure this depends on who is driving by the way, the laws of dynamics apply to all of us equally. But I agree that calculating whether a particular truck can pass a particular bridge is not easy to put into simple tags. It can be rather complex, which is why products like [2] exist. --colin [1] http://wiki.openstreetmap.org/wiki/Road_signs_in_the_United_Kingdom [2] http://www.autopath.co.uk/ On 2014-08-10 15:34, Никита wrote: I'm fine with this tag being used in UK. But I care about it's definition. If this tag will be interesting only in some territory, why not to define this tag specific to UK? You didn't answer how we should define humpiness of bridge?.. Is this you who minority and cannot pass this bridge without speed reduction or it is me who can drive everywhere at regular speed? This is really subjective. 2014-08-10 16:47 GMT+04:00 Yves yve...@gmail.com: There is a lot of things not of interest to the majority of users in OSM, this is why it is rich. Yves On 10 août 2014 12:41:22 UTC+02:00, Colin Smale colin.sm...@xs4all.nl wrote: On 2014-08-10 12:13, Никита wrote: I.e they define this tag as subtype of http://en.wikipedia.org/wiki/Arch_bridge [1] [5]. I don't see any real application/use to bridge=humpback. Also, bridge=humpback does not imply covered=yes by default. It does not define routing aspects or adds any features to end users. In the UK there are warning signs for some humpback bridges, and with good reason - if you don't slow down substantially from the ambient speed you will be launched into orbit. Therefore they should be useful for routers, implying a lower speed on that part of the road. https://uk.answers.yahoo.com/question/index?qid=20120222085933AAsnJiP [2] Some are so humpy that a vehicle with a long gap between the axles and/or a low ground clearance (e.g. a low-loader) may actually be unable to cross the bridge. So I don't think it is right to say that bridge=humpback cannot be of value for routing or end users... --colin - Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [3] -- Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [3] ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [3] Links: -- [1] http://en.wikipedia.org/wiki/Arch_bridge [2] https://uk.answers.yahoo.com/question/index?qid=20120222085933AAsnJiP [3] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bridge=humpback ?
It is neither constructed with the intention of calming traffic, nor is it intended as any kind of barrier (a bridge is usually exactly the opposite!) Let us not be afraid of using a different tag for what is clearly a different attribute. --colin On 2014-08-10 17:52, fly wrote: Can't we use traffic_calming=hump for this situation or some barrier=*? cu fly Am 10.08.2014 16:23, schrieb Colin Smale: No need to define it as UK-only... such bridges occur across the whole world, I am sure. The UK may be unique by having a specific road sign, which may indicate that a bridge could/should be tagged as a humpback (as stated in the wiki[1 [1]]). There is also a sign for explicitly indicating a risk of grounding often seen at railway crossings. In the UK it can be made objective by linking the use of the tag to the presence of the sign, but then we would miss the many bridges which the average person would call a hump bridge but are not signed as such. I would suggest something like a bridge requiring driving speed to be reduced due to the vertical profile (i.e. not because it is narrow, or some other attribute). Not sure this depends on who is driving by the way, the laws of dynamics apply to all of us equally. But I agree that calculating whether a particular truck can pass a particular bridge is not easy to put into simple tags. It can be rather complex, which is why products like [2 [2]] exist. --colin [1] http://wiki.openstreetmap.org/wiki/Road_signs_in_the_United_Kingdom [1] [2] http://www.autopath.co.uk/ [2] On 2014-08-10 15:34, Никита wrote: I'm fine with this tag being used in UK. But I care about it's definition. If this tag will be interesting only in some territory, why not to define this tag specific to UK? You didn't answer how we should define humpiness of bridge?.. Is this you who minority and cannot pass this bridge without speed reduction or it is me who can drive everywhere at regular speed? This is really subjective. 2014-08-10 16:47 GMT+04:00 Yves yve...@gmail.com mailto:yve...@gmail.com: There is a lot of things not of interest to the majority of users in OSM, this is why it is rich. Yves On 10 août 2014 12:41:22 UTC+02:00, Colin Smale colin.sm...@xs4all.nl mailto:colin.sm...@xs4all.nl wrote: On 2014-08-10 12:13, Никита wrote: I.e they define this tag as subtype of http://en.wikipedia.org/wiki/Arch_bridge [3] [5]. I don't see any real application/use to bridge=humpback. Also, bridge=humpback does not imply covered=yes by default. It does not define routing aspects or adds any features to end users. In the UK there are warning signs for some humpback bridges, and with good reason - if you don't slow down substantially from the ambient speed you will be launched into orbit. Therefore they should be useful for routers, implying a lower speed on that part of the road. https://uk.answers.yahoo.com/question/index?qid=20120222085933AAsnJiP [4] Some are so humpy that a vehicle with a long gap between the axles and/or a low ground clearance (e.g. a low-loader) may actually be unable to cross the bridge. So I don't think it is right to say that bridge=humpback cannot be of value for routing or end users... --colin Tagging mailing list Tagging@openstreetmap.org mailto:Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [5] -- Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté. ___ Tagging mailing list Tagging@openstreetmap.org mailto:Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [5] ___ Tagging mailing list Tagging@openstreetmap.org mailto:Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [5] ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [5] ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [5] Links: -- [1] http://wiki.openstreetmap.org/wiki/Road_signs_in_the_United_Kingdom [2] http://www.autopath.co.uk/ [3] http://en.wikipedia.org/wiki/Arch_bridge [4] https://uk.answers.yahoo.com/question/index?qid=20120222085933AAsnJiP [5] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bridge=humpback ?
Exactly my point. In the UK you can be objective by linking it to the presence of the sign, other countries may not use a sign. Having established that such information (this bridge requires you to slow down to avoid being launched) may be useful in certain cases, now we are trying to represent that information in OSM. The reasonable_max_speed would be a start, but if it is accompanied by some indication of WHY the speed is what it is, like reasonable_max_speed:reason=hump_bridge, then everybody could be happy. OSM is essentially a 2D system. Whereas hazards like sharp bends can possibly be derived from 2D information, anything significant in the vertical plane needs all the help it can get, including hump bridges and steep inclines. I'm not sure where you are from Richard, but don't you agree a bridge like this is asking for some special tag? http://farm2.static.flickr.com/1263/1186115057_7f88a4aaed_o.jpg Same applies as far as I'm concerned for dips and steep hills which constitute a hazard. As they can't be derived from 2D geometry, let's find a way of marking them explicitly. There has already been work done on incline=*: http://wiki.openstreetmap.org/wiki/Incline --colin On 2014-08-10 23:28, Richard Z. wrote: On Sun, Aug 10, 2014 at 06:14:24PM +0200, Colin Smale wrote: It is neither constructed with the intention of calming traffic, nor is it intended as any kind of barrier (a bridge is usually exactly the opposite!) Let us not be afraid of using a different tag for what is clearly a different attribute. without clear speed limits or hazzard signs it is just a very abstract danger of which plenty are more evil than a humpback bridge but not tagged in any way.. generations of drivers did drive there. We don't tag narrow winding mountain roads with special attributes, nor do we expect routing software to deduce that wisdom from road geometry? Sometimes I wish we would have something like key:reasonable_max_speed but we don't. So either bridge=humpback is a substitute for key:reasonable_max_speed - than we should think about that - or it is more an optical thing which could be handled within bridge:structure? On Sun, Aug 10, 2014 at 08:24:05PM +0400, Никита wrote: Yeah, traffic_calming was bad idea too, we use it for artificial objects with purpose of calming traffic. Back to the topic: a bridge requiring driving speed to be reduced due to the vertical profile (i.e. not because it is narrow, or some other attribute). very similar danger situation like hazard=dip, some railway crossings and any number of similar situations. Would it be worth to have an abstraction for that? Richard ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Distinction between amenity=restaurant and fast_food
On 2014-08-04 05:52, Shawn K. Quinn wrote: On Sun, 2014-08-03 at 13:19 -0700, Tod Fitch wrote: Thinking about this there seems to be several items that distinguish a fast food restaurant from other restaurants in my mind: 1. Does it have a drive-through window? Yes implies fast food. 1. Are the plates and cutlery are disposable? Yes implies fast food. Agree with both of these for the most part. 2. Does the establishment has a license to sell alcoholic beverages? No implies fast food. However, yes does not imply not fast food either, as it would disqualify Chipotle and Taco Cabana, both of which serve margaritas, and the latter at least has bottled beer too. No alcohol does not imply fast_food at many middle eastern restaurants either, nor at restaurants with a bring your own wine compromise policy either. I don't think alcohol has anything at all to do with the distinction between restaurant and fast_food. --colin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Townhouse
What's your definition of townhouse? I suspect this word may be in use around the world, meaning different things. What are the essential characteristics? We have to try to be objective - it IS what is IS, but what it is CALLED may vary. On 2014-07-20 06:08, Hans De Kryger wrote: Anyone know the tag for townhouses? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviewing the use of addr:housename
In the UK, some house names are added for vanity and these names are not recognised for addressing purposes; the house has a number, and this is what is in the official address. Other houses however (often old properties along country lanes) actually have a house name instead of a number. These names are registered with the local authority and the postal authorities, and changing them is an official process. Hence electronic systems handling UK addresses have to allow for house names as well as numbers. Colin On 2014-06-15 21:19, Matthijs Melissen wrote: On 15 June 2014 19:22, Peter Wendorff wendo...@uni-paderborn.de wrote: What is the address in your opinion? That is of course not black and white. But I do think house names have a different status in the UK than they have in Germany. In Germany, you would normally not include the house name when writing a letter. In the UK, that is common practice: Electronic systems usually only ask for postal code and house number, and then expand this to the full address, including house name. - If it is what the post office uses - then in Germany the city name is not a required part of the address as far as I know as it's included in the postcode. The German post office recommends including the city name: see https://www.deutschepost.de/de/b/briefumschlag-richtig-beschriften.html [1] . -- Matthijs ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [2] Links: -- [1] https://www.deutschepost.de/de/b/briefumschlag-richtig-beschriften.html [2] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Signal-controlled roundabouts
A signal-controlled roundabout reverts to being a normal roundabout if the traffic signals are not working (assuming it is also signed as a roundabout), so the presence/absence of the traffic signals cannot be a criterion for it being a roundabout or not. I expect most countries will have a traffic sign meaning roundabout. Apart from anything else they suggest that you should not be surprised or disorientated when you have to turn left while you actually wanted to turn right (left-hand traffic) - keep going round and you will get to your exit. Colin On 2014-06-13 18:25, Volker Schmidt wrote: Good question. I think this is because originally it was, as many others in the UK, a true roundabout with priority in the ring. The traffic signals were added later to avoid blocking up the (ex-)roundabouts. I have seen many roundabouts in the UK go through these phases: New clean roundabout; access control by traffic signals (sometimes part-time); traffic signals in the actual ring (as in the example. Even though they are still called xxx-roundabout, I agree with you that they do not correspond to the criteria for roundabouts, and I believe there are no roundabout traffic signs either I would invite comments form the UK mappers on this, as they seem to have added the corresponding paragraph into the wiki article on roundabouts. Here in Italy I would not tag a similar road layout as junction=roundabout On 13 June 2014 17:54, Fernando Trebien fernando.treb...@gmail.com wrote: Hello, I used to believe that, by definition, all roundabouts have free transit and right of way along the circle, and that anything that didn't display that property isn't a roundabout (just a circle). But reading the wiki once again, I'm a little in doubt. The wiki mentions that this is a roundabout, but I would previously have thought it wasn't because of the traffic lights within it: http://www.openstreetmap.org/#map=19/52.59689/-1.14146 [1] So why is it a roundabout? Is it because of the circular shape? Or could it be because it's impossible to infer that any of the entering ways have right of way, since they are all controlled by traffic lights? -- Fernando Trebien +55 (51) 9962-5409 [2] Nullius in verba. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [3] ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [3] Links: -- [1] http://www.openstreetmap.org/#map=19/52.59689/-1.14146 [2] tel:%2B55%20%2851%29%209962-5409 [3] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] capital and state_capital: how are they being used in your country?
Tagging capital=* or admin_level=* on a place is IMHO not to be done lightly. It is not actually an attribute of the place at all, because if you moved the place to e.g. the middle of the Atlantic Ocean it would no longer be a capital. It is an attribute of the relationship between the place and an (administrative) area. So the place and the area (represented by a relation in OSM) may reference each other, for example by including the place in the relation with a role such as admin_centre. Because a place cannot be a capital in and of itself (it can only be a capital OF somewhere) putting these tags on the place node is a denormalisation - to make things more convenient for the data consumers, so they don't have to go through the relations to see if a place is a capital or not. Such denormalisations are not always a Bad Thing (it's a balance), but there must be an acceptance that there is only One Truth, and zero or more derivatives. The One Truth would be in the relations and we will need a mechanism (or at least an algorithm) to derive the tagging for the place from the relations which reference it. capital=2 only means it's the capital of A country. Without a link to the country in question, this tag could be misused to increase prominence on the maps, AKA mapping (incorrectly) for the renderer, which is frowned upon. So I say let's ban capital=* and admin_level=* on the place nodes! Colin. On 2014-05-15 19:36, fly wrote: Am 15.05.2014 18:32, schrieb Andreas Goss: Am 5/15/14 16:30 , schrieb fly: Regarding the original discussion I am in favour of using capital=[2-10]* if an additional tag is needed. I meant additional to the roles for the boundary relation above (cutted). admin_centre for 1 or more nodes capital if not equal to admin_centre or more than one admin_centre present. The semicolon (;) is defined as value separator so we could have capital=4;6;8 or similar. This just sounds like a disaster waiting to happen. I also don't see why it would be needed. You are doubling the risk of errors when it comes to admin_levels. Now you don't just have to ensure all relations are correct, but also all nodes. As we are talking about admin_level (- capital) on nodes and it was mentioned that it might be easier to use and I am not sure if it is used. If any I would go with capital=* and not admin_level=* You also have no reference to those numbers. When you add one admin_level to a relation that relation has a name (Bavaria is a state). When placing admin_centre you know the name of the relation and of the city so you can make a connection (Munich is the capital of Bavaria). And while that maybe is obvious at level 2 and 4, it becomes more compicated when you get into smaller administrative areas. This also makes it more complicated to find errors in the first place. I also bet that people are going to assume that some numbers are missing and are simply going to add them, especially as it varies from country to country, from state to state etc. Others might simply add a number with good intend, because they had the wrong admin_levels in mind. Cheers fly ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] admin_level on nodes: wiki vs practice
See also the use of the admin_centre in boundary relations. This allows a place to have a different role/importance for each admin area it is in. An interesting case is Amsterdam, which is the capital of NL but not the provincial capital of the province it is in (that's Haarlem). The tagging reflects the facts, and how they are represented on the map is a matter for the renderer... http://wiki.openstreetmap.org/wiki/Relation:boundary Colin On 2014-05-11 10:37, sabas88 wrote: On 11 May 2014 06:32, Fernando Trebien fernando.treb...@gmail.com wrote: Hm I've looked up a few other cities (Hamburg, Munich, Cologne, Lyon, Marseille, Rotterdam, Zurich, Manchester, Birmingham, Salzburg, Aarhus) and they do not have an admin_level tag on the place=* node. At the same time, I found some other cities that do: Paris [1], Kopenhagen [2], Barcelona [3], Madrid [4], Brussels [5], Amsterdam [6], Bern [7], Vienna [8], Rome [9], Milan [10]: In Italy we use capital=* with the corresponding (minimum) admin level, so Rome has capital=2 and so on.. Regards, Stefano [1] http://www.openstreetmap.org/node/17807753 [2] [2] http://www.openstreetmap.org/node/13707878 [3] [3] http://www.openstreetmap.org/node/152364165 [4] [4] http://www.openstreetmap.org/node/21068295 [5] [5] http://www.openstreetmap.org/node/1635651356 [6] [6] http://www.openstreetmap.org/node/268396336 [7] [7] http://www.openstreetmap.org/node/18477455 [8] [8] http://www.openstreetmap.org/node/17328659 [9] [9] http://www.openstreetmap.org/node/72959652 [10] [10] http://www.openstreetmap.org/node/62505581 [11] I see an approximate pattern: capital cities tend to have an admin_level tag, others tend not to have it. Maybe it's something in use for backward compatibility, such as an with and old renderer that uses it instead of the capital tag to render a label at lower zoom levels. On Sun, May 11, 2014 at 12:04 AM, Andreas Goss andi...@t-online.de wrote: Berlin Honestly looks like and error nobody has noticed yet. I mean admin_level=2 ? Berlin is a city state which might justify =4, but unless we somehow tag capitals like this I don't see the reasoning behind this tag in the first place. Andi __ openstreetmap.org/user/AndiG88 [12] wiki.openstreetmap.org/wiki/User:AndiG88 [13] ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] -- Fernando Trebien +55 (51) 9962-5409 Nullius in verba. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/tagging [2] http://www.openstreetmap.org/node/17807753 [3] http://www.openstreetmap.org/node/13707878 [4] http://www.openstreetmap.org/node/152364165 [5] http://www.openstreetmap.org/node/21068295 [6] http://www.openstreetmap.org/node/1635651356 [7] http://www.openstreetmap.org/node/268396336 [8] http://www.openstreetmap.org/node/18477455 [9] http://www.openstreetmap.org/node/17328659 [10] http://www.openstreetmap.org/node/72959652 [11] http://www.openstreetmap.org/node/62505581 [12] http://openstreetmap.org/user/AndiG88 [13] http://wiki.openstreetmap.org/wiki/User:AndiG88 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] direction=forward/backward on nodes ?
Have to disagree here. There are plenty of real uses for reversing a way, and not everyone uses JOSM. Colin On 2014-04-12 22:43, Janko Mihelić wrote: 2014-04-12 20:39 GMT+02:00 John Packer john.pack...@gmail.com: I have never used this key before because of the drawback you mentioned: There is no editor supporting this tag when reverting a way direction, Does anyone else think that the reverse tool should be removed from editors? There's no real use for it, and it only gives us problems when new mappers use it. If someone really needs it, they can download a JOSM plugin. Janko ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting Extended - amenity=boat_sharing
Well put André. +100. On 2014-03-30 22:25, André Pirard wrote: On 2014-03-29 14:13, SomeoneElse wrote : On 29/03/2014 12:41, nounours77 wrote: As discussed in my earlier post, I think voting is important even for specific service tags to make them offical. Not really - OSM doesn't have official tags. It has commonly used ones, and people agree not to use the same tag to mean different things, but a lack of interest in a proposal is a pretty good indicator that, er, no one is actually interested. If you think that something is important enough to be mapped, then map it! If you think people are using different tags to express what is essentially the same concept, discuss it with those people to see if it is the same concept or if there are nuances that anyone is missing. Please don't expect people who have no knowledge of the real-world concept that you're trying to capture to be able to offer a useful opinion. Unfortunately, this is the kind of fuzziness that makes GPSes send cars to forbidden places or through mud (1) or hikers on a 5 km useless detour, that makes people laugh at OSM users, that makes OSM taggers laugh at themselves and laugh at me when I say that routing is a prominent application of OSM. That disparages OSM as a whole. Different features have different degrees of importance. Mapping every details like trees and their species is adorning and less important. But mapping the features that tourists look for like Nounours wants to do or road hazards, especially to spare a child's life while looking for the features, like I want to do are important, and both are disregarded. I have tried to show that renting is akin to selling, that they fit in the same framework, that if you have car renting defined and you want to support boat renting too, you almost just add the word boat to the framework (like reusing an object in object oriented programming) and that this lessens the fuss of voting new propositions. No one seems interested. I also had rendering problems. In the same reasoning vein, I suggested to use object oriented like generic rendering (e.g. landuse=leisure) that would be used if no particular rendering exists (leisure:miniature_golf=yes). Such frameworks tend to have everybody think in the same direction. No interest. If you look at (random cases) associatedStreet relation or addr:country=*, some discussions will say that you should not use it and other discussions will say that you should, but the wiki is mute about that or almost. The reasoning about addr:country can be found under is_in=* which is an older alternative but none of them points to each other and it's not said that addr:country is better that is_in=* because it shows that the name is a country. In conclusion, half of the taggers will do it one way and half the other way. And as the discussions say that one of the ways is not supported by all data consumers, half of the tagging won't work for that consumer. What about everybody doing the same thing so that the consumer did the job only once, whichever way it is? Yes, Nounours is right. If tagging is not precisely defined, the taggers will tag each their own way and data consumers will not understand it and it will have been tagged in vain. It is true that some cases are less strict than others but the problem is that many taggers have a tendency to make no difference and tag everything à la Picasso. Last but not least, I think we forgot to thank Nounours deeply for the work he does. Or tries to do. Cheers, André. (1) I had found (with Osmand too) and corrected several similar GPS routing tagging mistakes (there are many) and I was wondering why the same mistakes repeat over and over again. Then I found that the same mistake existed in my country's national wiki instructions!!! I put that right, but I was told off by someone standing himself as a chief and I was commanded to put the error back to the wiki because 1) no one would tag it that way (too complicated (3 tags)), 2) everybody knows that signal XXX means what I wanted to have the tags mean 3) there had been no discussion. A little bit of thinking leads to these conclusions: 2a: such tagging is not a matter of people but of programs understanding it, which I had corrected it for; 2b: if one sees tags, they don't say which road sign they describe, so that not even a human can interpret it rightly; 3: if a car is sent to where it shouldn't go by the tagging, replacing it with the tags that send it to the right way needs little discussion beyond fine, thanks; 1: if nobody will do it that way and wiki instructions are to not do it that way and OSM is laughed at and even laughs at themselves, well, how should I say, there is a problem. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Driving side
Agreed, we map roads and attributes of those roads. Sorry, I thought you were suggesting a tag with the meaning cars have their steering wheels on the left|right. Colin On 2014-03-21 22:06, Fernando Trebien wrote: We only map the roads because we have an interest in using them, right? Therefore, we also often map how vehicles are supposed to use these roads. See: access, oneway, maxspeed, surface, tracktype, smoothness, height, restriction, etc. On Fri, Mar 21, 2014 at 5:54 PM, Colin Smale colin.sm...@xs4all.nl wrote: Sorry, bad idea. We map the roads, not the vehicles. It is not illegal to drive a car with the wheel on the wrong side - millions of Europeans do it regularly, both on holiday and because certain models of car are only made for certain markets. Let's stick to driving_side referring to the side of the road. By the way, when Samoa changed from driving on the right to driving on the left a couple of years ago, that was because most of the vehicles were imported second-hand from Australia and therefore had the steering wheel on the right anyway... Colin On 2014-03-21 21:24, Fernando Trebien wrote: I wonder what you mean by Is there any interest of using it on countries?. It's been defined for countries, and is used on it, as you said. You could simply tag the country with driving_side=right/left and use the same (but with the opposite value) on those streets. That said, I think driving side also implies driver side inside the vehicle. Though I find it very unlikely to! see this information in use one day, it's best to define this meaning early on. A change of driver side requires either a change of vehicle or some special vehicle that can drive on both sides. In the case of your city, driving side changes, but driver side doesn't. You could include that in the description of opposite. One more thing: this only makes sense if there is no physical barrier between the opposite traffic directions. If there is, then it's just a separate way with no special change in driving side. On Fri, Mar 21, 2014 at 5:19 PM, Fernando Trebien fernando.treb...@gmail.com wrote: On Fri, Mar 21, 2014 at 5:07 PM, John Packer john.pack...@gmail.com wrote: There is a tag documented on the wiki called driving_side=right/left. According to it's description, this tag should only be used on countries, and it describes the side of the traffic in the whole country. So far so good, but according to taginfo it is used only once on a relation, however there are some uses on so! me ways, and even nodes(?). There are, in my city, a couple of streets that have an inverted driving side. So I am going to extend this tag's documentation to include ways that have it's driving side opposite to it's country's normal driving side. Is there any interest of using it on countries? If there is not, I will exclude the possibility of use on countries from this tag's documentation. Perhaps, with this new definition, this tag could be redefined to have only one value: driving_side=opposite (this way, it could avoid any confusion about it's use) What do you think? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Landuse=civic_admin
Interesting! That is more generic than simply civic_admin - one would not expect the primary land use of a school or a hospital to be administration. When/to whom is this classification significant? Colin On 2014-03-16 19:49, Eugene Alvin Villar wrote: On Sun, Mar 16, 2014 at 11:42 PM, Colin Smale colin.sm...@xs4all.nl wrote: They all sound much like offices (landuse=commercial) to me. Ownership has nothing to do with land use. In this case, the city council happen to be the users of the property, but if they need to downsize for whatever reason and a particular building gets a new tenant, will the land use change? I wouldn't have thought so. Well, in my country, these are classified as a different landuse and not commercial. Please see this land use map as an example: http://mandaluyong.gov.ph/img/profile/map9.gif [2] Hospitals, schools, universities, and civic/admin facilities (such as municipal or village townhalls) are classed as institutional landuse. So for my country, landuse=civic_admin (or similar) would make sense. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/tagging [2] http://mandaluyong.gov.ph/img/profile/map9.gif ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Landuse=civic_admin
Civil administration is surely hardly a land use. A council office is no different to any other office. I suggest looking at planning zones and their designations as a reference. Typically classifications like residential, retail, commercial, industrial and agricultural are seen, and changing the use of a parcel of land from one classification to another is a serious process which doesn't happen very frequently (in the big scheme of things). I don't expect so see the local plans define a particular plot as civil administration as the specific land use will be covered by one of the other classifications. The council can't just knock down a council office building or a courthouse and replace it with a highways yard in the middle of a city centre because they are all the same land use. Colin On 2014-03-15 17:09, Martin Koppenhoefer wrote: Am 14/mar/2014 um 00:54 schrieb johnw jo...@mac.com: I'm very interested to hear people's opinion on landuse=civic_admin It would be a landuse for townhalls and other capital buildings, Federal Buildings, DMV, courthouses, and other basic civic administrative offices where it is clearly a government building. maybe this is a language or cultural problem, but I'd consider neither courthouses nor government buildings administration. Courthouses serve the Judiciary and administration is together with government the executive branch. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fwd: tag for planetarium
I would not call it an amenity, which is (to me, native UK English speaker) something for the benefit/enjoyment of society as a whole (or at least a large part of it). These days a planetarium is probably for enjoyment/entertainment (suggesting leisure=planetarium). Colin On 2014-02-24 22:53, Johannes wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Original Message Subject: tag for planetarium Date: Mon, 24 Feb 2014 21:22:16 +0100 From: Johannes jotpe@gmail.com To: tagging@openstreetmap.org Hello, i was looking for suitable tag, that describes a planetarium. But until now nothing, there's no mention in the wiki. But there are several different usages out there. After a discussion on talk-de there was a majority for amentiy=planetarium We could not agree us, if a planetarium is a theater/cinema or a museum. So we took amenity as key. Any protest? If not, i will make theses wiki changes. Best regards, Johannes -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ [1] iQEcBAEBAgAGBQJTC79CAAoJEIhNWXvfzcR1mTIH/2rPzwL/o5FTlYyFhI9evRGm +YLRmnBlDolQ40Mu60jT03zRzTfEjjhgPjd6VOKF2WiRSMYpO52aM6C9wrJU0Gai E4c/usozrnSJFNCwssYT4PaQ0ava2iIK+36ri3+3ALioEv2lqBoUUqtUSQ8tL+eu A8mVuhCoz1udkTXMk0hSABvsiCpZMYRC3KrSiTaPP3bDCWZRViSjgB3QpwDNaCns D5lVsf2px6y09w1ni0855ZB3ePZL9CQ4+11dJyamk+EnRDtzOESLIqhSp+VIJY+y GFqSMpCnG5SY24dta+R4PfV1Nav0SPHwvgwm79LF6t+qsH/0irjg/hvFbeLrhXI= =JE0R -END PGP SIGNATURE- ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [2] Links: -- [1] http://www.enigmail.net/ [2] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Metropolitan counties and other boundaries
Hi, In the last couple of years I have put in a lot of hours maintaining the UK's admin boundaries in OSM. Having started in Kent (home territory) I have gradually been fanning out to cover more and more of the country. Although there is a lot of consistency in the tagging, one thing I noticed is that there are two schools of thought regarding Metropolitan Districts. These are a subdivision of Metropolitan Counties, of which there are six: Greater Manchester, Merseyside, South Yorkshire, Tyne and Wear, West Midlands and West Yorkshire. The Metropolitan Counties still exist in law, and certain functions (e.g. FireRescue, public transport) are often governed at that level. The Councils no longer exist as bodies however. The Metropolitan Districts (which are styled as Boroughs or Cities) are therefore effectively 99% the same as unitary authorities. In the situation between 1974 and 1986 the tagging would be obvious: both the County and the District would be boundary=administrative, with admin_level=6 for the county and admin_level=8 for the districts. In OSM, things have diverged a bit since then, and proper Unitary Authorities are tagged as admin_level=6 putting them on the same level as Non-Metropolitan Counties. The current situation in OSM is: admin_level County county tag county district GM ceremonial n/a 8 Merseyside ceremonial n/a 8 S Yorks administrative 6 8 TWear ceremonial n/a 6 W Mids administrative 6 8 W Yorks ceremonial n/a 8 I would like to normalise this tagging, and looking at the current usage above and the wiki[1], propose that the Metropolitan Counties become boundary=ceremonial, and the Metropolitan Districts become boundary=administrative, admin_level=8. Are there any objections or other comments? If not I will make the changes in a few days' time. By the way, I have been creating a wiki page to try to give an overview of UK boundary tagging at [2]. Please look at it - any comments, corrections, additions etc are most welcome, and if people feel it's useful the content can be moved into a more obvious place in the wiki. Thanks, Colin [1] http://wiki.openstreetmap.org/wiki/Admin_level [2] http://wiki.openstreetmap.org/wiki/User:Csmale/ukboundaries ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] tag man_made=campanile to be replaced with man_made=belfry?
Strictly speaking belfry can mean either the whole tower or more specifically the space where the bells are hung - usually near the top of a tower. However I would suggest that in common English usage the word is more closely associated with the space than with the building. I would prefer to see building/tower/man_made refer to the building as a whole, perhaps labelled as a bell tower, with belfry referring to the presence of a peal of bells. Perhaps belfry=yes/no, as many (former) bell towers no longer have functional bells? (Is a belfry with no bells still a belfry?) Or perhaps belfry:bells=8 to indicate the number of bells in the peal, or belfry:tenor=1000 for the weight of the largest bell in kg (typical UK)? The bells may also be a carillon, so belfry:carillon=yes? All this is of course about the bells which are installed in the belfry which is part of the bell tower. Colin On 2014-02-07 14:28, alessandro zardo wrote: +1 Il Venerdì 7 Febbraio 2014 13:11, Volker Schmidt vosc...@gmail.com ha scritto: The tag man_made=campanile documented in the wiki (http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dcampanile [2]) seems to be wrong as it refers to the swedish Klockstapel (https://sv.wikipedia.org/wiki/Klockstapel [3]), which is completely different from a campanile (see https://en.wikipedia.org/wiki/Bell_tower [4]; https://it.wikipedia.org/wiki/Campanile [5]) As it's use is very limited (less than 150) it could still be corrected. The closest concept in English that I can think of is belfry, so I would suggest man_made=belfry to replace man_made=campanile in the wiki for the Scandinavian Klockstapel, Klokkestabel, Kellotapuli, Klokkestøpul, for the German Glockenstapel, and the Hungarian Harangláb. The normal tagging for an English Belltower, Italian campanile, or German Glockenturm should remain man_made=tower + tower:type= bell_tower (it's used more then 5000 times). Volker ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/tagging [2] http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dcampanile [3] https://sv.wikipedia.org/wiki/Klockstapel [4] https://en.wikipedia.org/wiki/Bell_tower [5] https://it.wikipedia.org/wiki/Campanile ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag an imaginary oneway barrier
On 2014-02-01 17:30, Masi Master wrote: Normally traffic signs belongs to the road to the next intersection/crossing. That depends on the country - different jurisdictions have different conventions. In the UK the sign's effect is often until further notice, i.e. until there is another sign telling you differently. It doesn't automatically get nullified at the first side road like it does in many countries. Colin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag an imaginary oneway barrier
On 2014-02-02 02:15, André Pirard wrote: On 2014-02-01 17:39, Colin Smale wrote : On 2014-02-01 17:30, Masi Master wrote: Normally traffic signs belongs to the road to the next intersection/crossing. That depends on the country - different jurisdictions have different conventions. In the UK the sign's effect is often until further notice, i.e. until there is another sign telling you differently. It doesn't automatically get nullified at the first side road like it does in many countries. Strange to me again because the reason why the signs HAVE TO be repeated is that drivers entering the road at that next crossing wouldn't know them otherwise. How do the UK drivers know? They have to use their memory. The legal basis is also often different. There is often (it depends on the sign/restriction) a Traffic Order which says something like the road from A to B is now 30mph maximum speed and prima facie you are committing an offence if you disobey the order whether there are signs or not. However you can defend yourself in court by saying the signs were absent, hidden, confusing etc. So the highway authority has to be reasonable about putting up signs, and it is your problem if you miss one. In NL at least the offence is created by the sign itself, so no sign = no offence. By the way, diving off-topic for a second, their memory is not tested as much as drivers on Dutch motorways. You may have to have a stack of up to 5 speed limits at any one time. Imagine encountering the following signs, in order: 1) start of motorway - class of road says it is 130 2) static sign says it is 120 3) static sign also says it is 100 between 0700 and 1900 4) temporary static sign says it is 90 (e.g. for roadworks) 5) overhead displays say temporary speed limit is 70 (e.g. for congestion ahead) 6) in the course of the traffic jam you see a temporary static sign at the end of the road works which says end of 90 limit (black circle, diagonal bar, grey 90 visible) 7) overhead displays say end of restriction (circle with diagonal bar) What is the speed limit after sign 6 (the time is 1859)? And after sign 7? And why is everybody suddenly overtaking you? There is a catch at point 7) - end of restriction on overhead displays now only cancel limits from overhead displays. So is the limit after sign 6) 100, or 130? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] aerialway=drag_lift
Drag lift is more generic - both t-bar and platter (and rope_tow) are subtypes of drag lift. The distinction between t-bar, platter and rope_tow is very important to some people (particularly inexperienced skiers). In some areas like Austria the t-bar is more popular whereas in France you see only platters. Colin On 2014-01-22 17:47, remont...@free.fr wrote: So, why we have platters, and why it is recommended on iD editor ? And what is the utility of t-bar, because it's a platter with 2 persons, so aerialway:occupancy=2, no ? I can't understand why it is duplicate. It's not good... 2014/1/22 Martin Koppenhoefer dieterdre...@gmail.com 2014/1/22 remont...@free.fr remont...@free.fr I think we can delete aerialway=drag_lift of Openstreetmap's wiki because it's a duplication of platter. Same thing for t-bar, for 2 places platters, we have the tag aerialway:occupancy=2, which is not easily parametrable in iD editor. According to taginfo, aerialway=platter is used much fewer than drag_lift and t-bar is almost at par with platter. The proposal states that this is only to be used for Platter lift [1], similar to a t-bar, but with a disc instead of a bar. Single-person only. http://wiki.osm.org/wiki/Proposed_features/Piste_Maps [2] http://taginfo.openstreetmap.org/keys/aerialway#values [3] drag_lift [4] 4 830 platter [5] 1 471 goods [6] 1 217 t-bar [7] 1 206 so NO, DO NOT DELETE the mentioned values from the wiki! cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [8] ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [8] Links: -- [1] http://en.wikipedia.org/wiki/Platter_lift [2] http://wiki.osm.org/wiki/Proposed_features/Piste_Maps [3] http://taginfo.openstreetmap.org/keys/aerialway#values [4] http://taginfo.openstreetmap.org/tags/aerialway=drag_lift [5] http://taginfo.openstreetmap.org/tags/aerialway=platter [6] http://taginfo.openstreetmap.org/tags/aerialway=goods [7] http://taginfo.openstreetmap.org/tags/aerialway=t-bar [8] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] aerialway=drag_lift
I disagree, they are not the same at all! Just ask my wife, who has skied for years, has no problems with platter lifts, about a 50% success rate with t-bars on her own, and 10% success rate on t-bars with someone else. Occupancy is also not really the right word as that would refer to the actual number of people using it, and not its capacity per seat. So occupancy would probably be between 0 and 1.7 people per seat (or, otherwise stated, between 0% and 85%) depending on how busy it is. Colin On 2014-01-22 18:38, remont...@free.fr wrote: But t-bar are only platters with aerialway:occupancy=2 2014/1/22 Colin Smale colin.sm...@xs4all.nl Drag lift is more generic - both t-bar and platter (and rope_tow) are subtypes of drag lift. The distinction between t-bar, platter and rope_tow is very important to some people (particularly inexperienced skiers). In some areas like Austria the t-bar is more popular whereas in France you see only platters. Colin On 2014-01-22 17:47, remont...@free.fr wrote: So, why we have platters, and why it is recommended on iD editor ? And what is the utility of t-bar, because it's a platter with 2 persons, so aerialway:occupancy=2, no ? I can't understand why it is duplicate. It's not good... 2014/1/22 Martin Koppenhoefer dieterdre...@gmail.com 2014/1/22 remont...@free.fr remont...@free.fr I think we can delete aerialway=drag_lift of Openstreetmap's wiki because it's a duplication of platter. Same thing for t-bar, for 2 places platters, we have the tag aerialway:occupancy=2, which is not easily parametrable in iD editor. According to taginfo, aerialway=platter is used much fewer than drag_lift and t-bar is almost at par with platter. The proposal states that this is only to be used for Platter lift [1], similar to a t-bar, but with a disc instead of a bar. Single-person only. http://wiki.osm.org/wiki/Proposed_features/Piste_Maps [2] http://taginfo.openstreetmap.org/keys/aerialway#values [3] drag_lift [4] 4 830 platter [5] 1 471 goods [6] 1 217 t-bar [7] 1 206 so NO, DO NOT DELETE the mentioned values from the wiki! cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [8] ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [8] ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [8] ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [8] Links: -- [1] http://en.wikipedia.org/wiki/Platter_lift [2] http://wiki.osm.org/wiki/Proposed_features/Piste_Maps [3] http://taginfo.openstreetmap.org/keys/aerialway#values [4] http://taginfo.openstreetmap.org/tags/aerialway=drag_lift [5] http://taginfo.openstreetmap.org/tags/aerialway=platter [6] http://taginfo.openstreetmap.org/tags/aerialway=goods [7] http://taginfo.openstreetmap.org/tags/aerialway=t-bar [8] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] one-directinal bicycle dismount on oneway road ?
I agree. In the UK there is a difference between no cycles and no cycling. Although in general you may be correct that a dismounted cyclist is effectively a pedestrian, there are also footways (or whatever you want to call them) signed as no cycles, which means that in these cases a dismounted cyclist is not equivalent to a pedestrian. If foot=yes (explicit or implied) implies bicycle=dismount which corresponds to no cycling, I would suggest that bicycle=no would then mean no cycles i.e. not even if dismounted. But watch out for talking about what is legally allowed as it varies widely by country! Colin On 2014-01-19 11:27, Georg Feddern wrote: Am 19.01.2014 09:19, schrieb Volker Schmidt: I frequently need to map short pieces of a bicycle routes where cyclists have to dismount and walk their bicyle on a one-road in the wrong direction. I need something like a one-directinal bicycle dismount. Any suggestions? Yes: Nothing. A cyclist who dismount is legally a pedestrian. A pedestrian is legally allowed to use a one-way-road in the opposite direction. Any bicycle router can use a foot=yes (even implied) just as well as a cyclist=dismount - for routing and/or for advising. Georg ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] one-directinal bicycle dismount on oneway road ?
Well, certainly I have seen them applied to large permissive areas like shopping centres. If we don't use bicycle=no for this, how about bicycle=prohibited? The standard sign for no vehicles (red ring on white background) does not apply to bicycles being pushed by hand, but as a bicycle is technically a vehicle whether it is being ridden or not, there are some esoteric edge cases in the no vehicles category, like no vehicles carrying explosives. If your bike carrier is full of Semtex, dismounting is IMHO not enough to allow you to pass the sign. I could also mention that it is not always clear what the status is of unicycles, tricycles etc. The UK legislation seems to vary between the use of the word bicycle and pedal cycle (which covers them all). I found this article which illustrates some of the complexities: http://www.theguardian.com/environment/bike-blog/2011/jul/28/cycling-pavement-offence Colin On 2014-01-19 17:13, Martin Koppenhoefer wrote: 2014/1/19 Colin Smale colin.sm...@xs4all.nl there are also footways (or whatever you want to call them) signed as no cycles, which means that in these cases a dismounted cyclist is not equivalent to a pedestrian. If foot=yes (explicit or implied) implies bicycle=dismount which corresponds to no cycling, I would suggest that bicycle=no would then mean no cycles i.e. not even if dismounted. are these public ways? Is this backed by british legislation? Of course on a private way you can invent all kind of arbitrary rules, like no women with red hats, but on a public way? cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] access in the wiki: move psv to by use
Nobody uses the archaic word omnibus these days. You may as well suggest replacing car with horseless carriage. I really think we are trying to square a circle here. There are irreconcilable differences between countries, and we should not waste our energy in a war of attrition. Whether a taxi with no passengers is still a taxi, whether a bus on its way back to the depot is still a PSV, whether a bus being driven by a mechanic on a test-drive is allowed in a bus lane, all these things are going to vary by country. Why don't we all come up individually with a model which fits our own countries, and then we can see how much correlation there is between the countries. A few questions which come to mind: * If there is a road sign indicating Taxis only (might be a road, might be parking), what is considered a Taxi? * When is a bus allowed to use a bus lane? Does it include long-distance scheduled services? Does it include touring cars (a.k.a. coaches in the UK)? Does it include sightseeing tours? * What is considered a PSV? Does this concept actually exist in your country - for vehicle licensing or for driver licensing or something else? This is intended to *derive* a model of reality, instead of suggesting thousands of potential ways of tagging things until almost everyone gives up and goes home. Whatever tagging scheme is used, it should have some way of representing reality in many (preferably all) countries. If the semantics of a tag/value are different by country, let us just document the standards for that country and move on. Colin On 2014-01-16 16:13, Martin Koppenhoefer wrote: 2014/1/15 martinq osm-mart...@fantasymail.de 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). in service is implicit in public service vehicle, because if they are not in service they are not psv. For taxi I am not sure, I don't know whether a taxi is a taxi when the driver is not working, but my guess is it is not. Maybe someone has more references to clear this up. There is no way to tag taxi in service so far in OSM, only taxi (as a car category). is there really a taxi vehicle category? I am aware that the vehicle has certain requisites e.g. in Germany in order to be able to work as taxi, but I am not sure if it is a taxi also off duty. So I do not agree that taxi and psv belong to the by-use group. OK, if you get more we have to think about how this can be handled (e.g. voting?) I strongly suggest to move psv, bus and taxi back to the original place in the wiki! for bus there shouldn't be space for discussion, as the definition is explicit for a long time. 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. I think that people that are not native speakers are less of a problem, as they won't have an idea about the meaning of a cryptic abbreviation prior to looking it up in the wiki, while people speaking English but not UK English as their mothertongue are more at risk of understanding something else (and not looking the definition up in the wiki). I do agree that it is not an intuitive tag (but it saves us lots of bytes in the db ;-) ), and it is a very old tag and quite used. 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? as generic term for buses and taxis. I agree that creating a new vehicle class omnibus is also appealing, and there are currently 0 uses of this key so it might work out. 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. +1 3) Depreciatepsv (or broaden the meaning to all public service because of the JOSM turn restriction plugin? What about changing that plugin? broaden the usage will probably not get a majority, but we can see. Not sure if this is needed anyway. 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=*? you mean omnibus rather than bus, no? +1 By the way: The key name tourist_bus is also non-intuitive, not every non-public transport bus is a tourist bus well, as this doesn't seem to be well defined outside of
Re: [Tagging] access in the wiki: move psv to by use
On 2014-01-16 17:55, Martin Koppenhoefer wrote: 2014/1/16 Colin Smale colin.sm...@xs4all.nl If the semantics of a tag/value are different by country, let us just document the standards for that country and move on. I'd prefer to use a different tag then, because that's what tagging is about: describing the real situation with k/v pairs. What's the point of using the same tag with different meaning? Then we should not use tags which mean different things to different people. Instead of bus, should we use vehicle_constructed_or_adapted_for_the_carriage_of_individual_fare-paying_passengers_on_scheduled_service in one country and vehicle_constructed_for_the_carriage_of_passengers_over_short_distances in another? Seriously, this is what we do all the time. Highway=trunk for example - many differing interpretations across the world, but usually more-or-less consistent within countries. We can all dream of a nice uniform world where all these debates are no longer needed, but it ain't gonna happen in our lifetime... In the mean time, we have to adapt our model to fit the world, because going the other way has proven rather challenging. Colin cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Unsuitable?
I am not sure why it was suddenly changed (today) from unsuitable to discouraged, but Unsuitable for HGVs is seen frequently in the UK. To my understanding there is a difference between the semantics of unsuitable and discouraged, the former being a simple statement of (official) opinion and the latter indicating that active measures have been taken to decrease its occurrence. In any case it might not be legally enforceable, but if you are shown to have ignored the official warning it may affect your position if it came to an incident (insurance claim). Taginfo gives 318 occurrences of hgv=unsuitable. The principle of hgv=* (and other vehicle-class tags) using the same values as access=* would also suggest there is some merit in documenting unsuitable as a recognised value. If AndyS is reading this, maybe he could explain the change? Colin On 2014-01-08 14:45, Martin Koppenhoefer wrote: 2014/1/8 Pieren pier...@gmail.com Since when is unsuitable an accepted value for the access keys? I always thought that the access keys describe legal restrictions. It says usage is discouraged (e.g. HGVs on narrow lanes) . Often marked by a traffic sign So maybe, there is a traffic sign for unsuitable which is different from no. An example would be appreciated. The value was now changed to discouraged. I have found 2 occurances of this in taginfo (checked access, foot, vehicle and motor_vehicle and found just 2 bicycle=discouraged), hence my suggestion is to remove this from the access page for now, as it wasn't discussed or officially proposed and isn't in use either. Please make a proposal and see what others think about this, before adding it to the documentation of established tags. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - bicycle=use_cycleway
Be aware that road: you may only cycle on the cyclepath if the cyclepath is going where you're headed is ambiguous. 1) if the cyclepath is going where you're headed, then (and only then) are you allowed to use the cyclepath 2) if the cyclepath is going where you're headed, you are obliged to use the cyclepath, to the exclusion of all other carriageways I think number 2) is intended here? Colin On 2013-11-14 12:08, Martin Koppenhoefer wrote: 2013/11/14 Kytömaa Lauri lauri.kyto...@aalto.fi road: you may only cycle on the cyclepath if the cyclepath is going where you're headed +1 additionally there might be other factors that make it impossible to use the cycleway (and as the road is not actually forbidden you will use it), for instance in the winter there might be ice and snow on the cycleway. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - bicycle=use_cycleway
There are very many roads (in NL at least) marked with bicycle=no with no explicit sign. It is implicit in the fact that a parallel cycle track is marked as compulsory (blue round sign). IMHO the definition of this sign (in law) is totally screwed. It is also used for cycle tracks which are nowhere near roads. It seems to mean that I am obliged to use that cycle track even if it is going in the wrong direction for me... so it becomes rather subjective in many cases as to how mandatory it really is. It is usually regarded as applying where the main carriageway and the cycle track are the same road. If they are parallel and not too far apart (how far is this?) that's almost trivial to determine, compared to some of the incredibly complex cycle track layouts around junctions. The law in NL says that cycles wider than 75cm are not bound by the obligation to follow the mandatory cycle track and are allowed on the main carriageway; this includes trikes and some trailers (e.g. for carrying windsurfers). So why not tag the main road to reflect the width limit? bicycle:minwidth=0.75? Colin On 2013-11-13 10:10, Erik Johansson wrote: Are you proposing tagging all ways with a parallel cycleway with bicycle=use_cycleway? Sounds like it's made for mechanical edit abuse. But if you are saying that there are roads marked with bicycle=no which really do not have such a sign, then that's different. On Tue, Nov 12, 2013 at 7:16 PM, Pee Wee piewi...@gmail.com wrote: Together with user Masimaster I've made a proposal for a new tag to improve bicycle routing. I think (and hope) the wiki is clear enough but I'll say a few words about this new tag. The tag is introduced to separate 2 kinds of roads where you are not supposed to ride your bike. The first is a road with a traffic sign (bicycle icon with red edge) that makes clear it is forbidden to ride a bicycle . (common tag: bicycle=no) The second is a road that has a parallel compulsory cycleway but does not have the bicycle forbidden sign. On this type of road you're not supposed to ride your bike but there are exeptions. Legally these 2 roads are not the same. For example.. in NL some 3 wheel bicycles with certain measurements are allowed to ride the second type of road. In other countries there is also a legal difference. For this reason we propose this new tag. Cheers PeeWee32 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] admin_boundary with multiple levels / county free citys / Kreisfreie Staedte
Surely the boundary way itself is unlikely to have a name, other than a synthetic a/b boundary? Unless of course the name refers to some feature like a road or a river which in a specific case may be part of the boundary. As administrative bodies (and their boundaries) are usually hierarchical in nature, it feels a more natural fit to allow segments of a boundary way to be shared between admin areas at different levels, which are defined in relations. All the names and other characteristics of the admin unit go on the relation, and the ways which represent segments of the boundaries don't need tags at all (although a basic boundary=administrative is usually applied to make them render, although this should not be required). In this way there are no conflicts in the tagging. There is also a single point of definition for the name of the admin unit; any changes only need to be made on the relation, and do not need propagating to the constituent ways. The discussion then shifts to the rendering - how do you control how boundaries are rendered? What is to be the text on the boundary - if any? Let's not make the tagging suboptimal for the sake of getting our preferred text to show up on the map. This is called tagging for the renderer and we don't do that. Colin On 2013-11-06 10:31, Pieren wrote: Now I see that the county free big city. is incorrect. If the admin level exists but is just matching another level boundary, we duplicate the relation in my country since years. See for instance - Paris, the municipality (city), level 8 : http://www.openstreetmap.org/browse/relation/7444 [1] - Paris, the departement (equ. to your county), level 6 : http://www.openstreetmap.org/browse/relation/71525 [2] (there is even one for admin_level 7) We just had a dispute about the tag name. Some countries seem to apply a different name for the county and the city relation. Two examples: - Orange county (vs Orange) in US : http://www.openstreetmap.org/browse/relation/396466 [3] - Canton Capellen (vs Capellen) in Luxemburg : http://www.openstreetmap.org/browse/relation/407813 [4] Personnally, I'm in favour to apply the same policy in France where others said that the tag admin_level is providing the information. Pieren Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [5] Links: -- [1] http://www.openstreetmap.org/browse/relation/7444 [2] http://www.openstreetmap.org/browse/relation/71525 [3] http://www.openstreetmap.org/browse/relation/396466 [4] http://www.openstreetmap.org/browse/relation/407813 [5] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] admin_boundary with multiple levels / county free citys / Kreisfreie Staedte
OK, sorry if I misunderstood. On 2013-11-06 11:25, Pieren wrote: On Wed, Nov 6, 2013 at 10:59 AM, Colin Smale colin.sm...@xs4all.nl wrote: Surely the boundary way itself is unlikely to have a name, other than a synthetic a/b boundary? To clarify, my remark was just about the tag name in the two relations which are indeed identical excepted the admin_level value. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] admin_boundary with multiple levels / county free citys / Kreisfreie Staedte
In the UK we do the opposite. In Unitary Authorities, which combine the role of the county with the district (sounds like the same as the Kreisfreie Staedte) we tag the UA as admin_level=6, i.e. at the same level as counties, and not admin_level=8 which is the level for the districts. We also occasionally use designation with specific values (from a controlled vocabulary) to distinguish between the different entities which may share an admin level. Colin On 2013-11-05 16:55, Pieren wrote: On Tue, Nov 5, 2013 at 4:22 PM, Florian Lohoff f...@zz.de wrote: A fix would be an admin_level=6;8 on the boundary or duplicating the relation. I'm surprised you still have such questions in Germany. Your description is not clear since you don't explain what is on the way and what is on the relation. But I can tell how it *should* be : on the boudary way : put the highest admin level (thus, with the lowest numerical number). And create one relation per admin_level, obviously. What I guess is that the admin_level on the way is just used for rendering purpose, not by nominatim which should exclusively work with admin boundary relations or place nodes. For the county free big city, simply don't create a relation with admin_level 6 but keep only the one exclusively for admin_level 8. Pieren ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] access=exclusion_zone
The tag used in the examples is military=exclusion_zone, whereas it has been documented as access=exclusion_zone. The tagging makes sense in my eyes, but the wiki needs bringing in line. Colin On 2013-10-30 09:08, Martin Vonwald wrote: Hi! 2013/10/29 martinq osm-mart...@fantasymail.de 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 [1]) without proper discussion (voting process)? Same here - never heard about it. I do not see any significant difference of the new value compared to the already existing access=no or access=private. Me neither. This should be removed again and put into a proper proposal. The tag is used 5 times currently and was added all by one user: http://www.openstreetmap.org/browse/way/164794093 [3] http://www.openstreetmap.org/browse/way/164794065 [4] http://www.openstreetmap.org/browse/way/164794088 [5] http://www.openstreetmap.org/browse/way/164794096 [6] http://www.openstreetmap.org/browse/way/164794117 [7] Anyone already contacted the user? Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [2] Links: -- [1] http://wiki.openstreetmap.org/wiki/Key:access [2] https://lists.openstreetmap.org/listinfo/tagging [3] http://www.openstreetmap.org/browse/way/164794093 [4] http://www.openstreetmap.org/browse/way/164794065 [5] http://www.openstreetmap.org/browse/way/164794088 [6] http://www.openstreetmap.org/browse/way/164794096 [7] http://www.openstreetmap.org/browse/way/164794117 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Hiking route abandoned
Of course we tag for the renderer (a.k.a. data consumer), that's the only reason OSM exists. What we DON'T do, is deliberately tag *incorrectly* to persuade the renderer to produce a desired result. Renderers need to be able to make certain distinctions - if not based on an explicit tag, then by derivation based on other tags. Colin On 2013-10-02 18:20, Fernando Trebien wrote: I'm sorry but maybe some misspellings changed the message. So let me clarify. Renderers often don't support life cycle tags, but that doesn't matter because we don't tag for the renderer/applications, right? If you just add a disused tag, the route likely will still be rendered in current map styles made for hikers. That may or may not be a good thing. I think it's good if the route is still open to the public, otherwise no. Didn't mean to say hiking routes should not be rendered, sorry for the confusion. I think they should. On Oct 2, 2013 7:36 AM, SomeoneElse li...@mail.atownsend.org.uk wrote: Fernando Trebien wrote: Wouldn't the more generic disused=yes apply to this case? Rendering apps should support lifecycle tags and render them accordingly (though often then don't ... I think that you've answered your own question already :) ... and none would support this anyway). If you mean don't render hiking routes than that's obviously wrong; if you mean don't render _disused_ hiking routes then that's probably a feature, but any that do render hiking routes that don't also look for disused=yes (or whatever) will miss it. Cheers, Andy ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Pre-proposal: gambling
I would recommend making a clear distinction between the premises and the activity. Lotteries are rarely carried out in shops, but the tickets are sold in all manner of establishments with a different primary purpose. And whether you can ever call gambling an amenity (for the public good) is open to discussion as far as I am concerned. Colin Matthijs Melissen i...@matthijsmelissen.nl wrote: Dear all, There are currently various tags for gambling-related shops and amenities in use, including amenity=casino, shop=bookmaker, shop=betting, shop=lottery, and shop=gambling. See here for an overview of usage statistics: http://wiki.openstreetmap.org/w/index.php?title=Proposed_features/gambling . As shops and amenities for gambling are already widely used, we should aim to stay as close to the current way of tagging as possible when writing a proposal. However, the usage statistics to which I linked show some issues with the current way of tagging, which would be good to resolve. These issues include the following. - The current tagging contains some ambiguous tags. For example, amenity=gambling is used for both bookmakers and casinos. - Some real-world objects are tagged in (many) different ways. For example, bookmakers are tagged as shop=bookmaker, shop=betting, and (less frequently) amenity=gambling. Lotteries are tagged in many different ways as well. Data consumers (and end-users as a consequence) would benefit if these issues were resolved. Fixing current tagging will probably be difficult, but more guidance in the form of well-documented tags might help prevent these issues at least for future tagging. In order to create clearer documentation for future mappers and resolve ambiguities, I am interested in the opinion of the community on the following questions. 1. Should we map all gambling-related places in a single way, for example as amenity=gambling and then specify with gambling=*-tags, or should we keep different tags for different kind of gambling places? 2. If we want to use different tags for different kind of gambling places, which types of gambling places should we distinguish? For example: - Should we distinguish bookmakers and lotteries? Note that some places combine sports betting with traditional lotteries. - Should we distinguish casinos (with croupiers) and 'playing halls' (or whatever they are called) without croupiers? With kind regards, Matthijs Melissen ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to map an household goods store?
From a UK perspective my feeling is that houseware and home are not synonyms - home suggests more furnishings, maybe lighting etc but not so much the utilitarian objects that might be better labelled as houseware. Kitchenware would be a category of houseware; other categories/subsets might include bathroom stuff (brushes, sponges, ...), garage stuff (cloths, sponges, ...), garden stuff (buckets, hoses, gloves, ...) etc. Lighting, furnishings etc would not be houseware but (I suggest) furnishing (distinct from furniture which suggests more the larger things like beds, cupboards, sofas etc). Colin On 2013-09-16 10:09, Alex Rollin wrote: personally I think housewares is OK. In many cases this would (in my evaluation of English usage) go so far as to include: kitchen simple repair simple furniture basic linens I prefer the term home store, personally, but that is just because I like the word better. I feel that home is synonymous with housewares. -- Alex On Mon, Sep 16, 2013 at 2:51 PM, Simone Saviolo simone.savi...@gmail.com wrote: 2013/9/16 Philip Barnes p...@trigpoint.me.uk On Mon, 2013-09-16 at 05:47 +0200, Stefano Fraccaro wrote: I have some shops that sell only household goods like dishes, pots, coffee makers, blenders, oven thermometers, ... IMHO shop=supermarket and shop=general are non appropriate. Which is the correct tag? I would have thought that would be shop=cookware. But only used 9 times on the planet. It's not only about cooking, there may be (here in Italy, at least) decorations, some furniture like tables and chairs, lamps, so it's more of a shop that sells houseware with a possible focus on kitchenware. I think I'd be equally good with household and houseware as a value - even though houseware seems to be more fitting, but this may be due to a misconception that I have because I'm not a native English speaker. Ciao, Simone ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] owner vs operator
On 2013-09-03 13:45, Richard Welty wrote: On 9/3/13 7:31 AM, John Sturdy wrote: On Tue, Sep 3, 2013 at 11:59 AM, François Lacombe francois.laco...@telecom-bretagne.eu wrote: Operator could be given by operator=* and the effective owner by a new owner=* tag. What about when a business is owned by one entity, but operated on their behalf by another, in a building that they lease from yet another one --- does owner= refer to the business, or the building? If people feel a need to tag things like this, I have no objection, but I do think it's getting to the edge of what really belongs on the OSM database. it's also something that's subject to change and therefore creates a maintence issue. i guess i want to know whether this enables anything that makes the maintenece effort worth it. my fear of course is that we end up with a collection of useless out-of-date data. Unfortunately the whole world is subject to change. Where does one draw the line? Data must have a life expectancy of more than 1 year? Which deliberately does not refer to the age of the information by the way, only some indication of how frequently a particular type of data might be expected to change. What about websites? Phone numbers? Postcodes? Road names? Colin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] funny tags: turning_radius
Won't the calculated radius depend on the number of points on the way, and the width of the road? If you look closely at the geometry of a curved road in OSM it is of course made up of straight segments with a certain angle between them. A right angle junction might be a 45 steps of 2 degrees each, giving a smooth curve with a certain radius, but it can also be represented by a single node with an angle of 90 degrees. How do you work out the turning radius from that? On 2013-08-29 16:48, John F. Eldredge wrote: On 08/29/2013 09:33 AM, Pieren wrote: On Thu, Aug 29, 2013 at 4:07 PM, André Pirard a.pirard.pa...@gmail.com wrote: I was very surprised to come across that tag [2] I will remove it from the map features page. Radius can be calculated from the way geometry. It has been used 7 times by one user so far... Next comments on this should be forwarded to the tagging list. Pieren ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging [1] I suppose the logic is to say what is the largest turning radius that can turn around at this point, but it does make more sense to calculate it from the way geometry instead. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging [1] Links: -- [1] http://lists.openstreetmap.org/listinfo/tagging [2] http://wiki.openstreetmap.org/wiki/Key:turning_radius ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] access at own risk
In what way is this any different to any other road? Even on a government maintained road you accept a degree of own responsibility. What additional risks are we talking about here? Colin Volker Schmidt vosc...@gmail.com wrote: I am sure this has been asked many times before: How do I tag correctly a path/track/road that bears the label access at your own risk ? Volker ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Are addresses ... objects vs attributes
Surely Peter's point (which I agree with) is that leisure and sport are two different things, and should not be seen as mutually exclusive or as competitors to each other. There are many sports which (can) take place in a (suitable) swimming pool (swimming, diving, water polo etc), but not all pools are suitable for any of them. Just laying in the water and cooling off can not really be called a sport. Sports have rules and governing bodies and things. On 2013-07-25 10:03, Andreas Labres wrote: On 25.07.13 09:33, Peter Wendorff wrote: a pool that allows swimming leisure=swimming_pool (more than 291.000!) is prevailing, I would say. /al ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging [1] Links: -- [1] http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] gross weight - conclusions changes
The UK Government seem to think an HGV starts at 3.5t GVW, not 7.5t. By those standards, hgv=no is not a correct transposition of the sign with a lorry+weight(7.5t) symbol. Nor is maxweight=7.5 (I think) because it only applies to goods vehicles - not buses/coaches for example (correct me if I'm wrong!) I also get the impression that a semitrailer is considered part of the towing vehicle whereas a drawbar trailer is considered a separate vehicle. Found this concise document: https://www.worcestershire.gov.uk/cms/pdf/A-Simplified-Guide-to-Lorry-Types-and-Weights.pdf [2] Colin On 2013-07-01 13:28, Philip Barnes wrote: On Mon, 2013-07-01 at 13:03 +0200, Martin Koppenhoefer wrote: 7.5t gross weight or actual loaded weight? Does this include trailers? It is gross weight, a vehicle with a gross weight of more than 7.5t being regarded as a HGV. Phil (trigpoint) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging [1] Links: -- [1] http://lists.openstreetmap.org/listinfo/tagging [2] https://www.worcestershire.gov.uk/cms/pdf/A-Simplified-Guide-to-Lorry-Types-and-Weights.pdf ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - More Consistency in Railway Tagging
What about the difference in signalling systems? As I understand it, what I would call a Tram is completely under control of the driver. He/she alone decides when to stop/start, and even which way to go at junctions. They have traffic lights which are interconnected with the lights for other road users. One tram can approach the rear of another without any problem, just as other vehicles wait behind each other at junctions. What I would call Light Rail uses a more serious signalling system, more closely related to its big brother where train paths are pre-planned using some kind of (fixed/moving) block system. Is tram vs light rail an attribute of the vehicles, the service or the infrastructure? Can a single route transition from being one to the other? Colin On 2013-04-14 15:21, Rovastar wrote: It seems that the terms light rail and tram are used interchangeably around the world so mostly ignore my last comments. I don't know where this leave OSM tagging standards for them though. In the UK we do class them as different and it just show my sheltered life and knowledge on this subject... -- View this message in context: http://gis.19327.n5.nabble.com/Feature-Proposal-RFC-More-Consistency-in-Railway-Tagging-tp5756879p5757037.html [1] Sent from the Tagging mailing list archive at Nabble.com. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging [2] Links: -- [1] http://gis.19327.n5.nabble.com/Feature-Proposal-RFC-More-Consistency-in-Railway-Tagging-tp5756879p5757037.html [2] http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Catchment Areas
In my mind there is a conceptual difference between formally defined administrative areas and informal catchment areas. For the former, there is (somewhere) a documented source of the truth, whereas there is no official document to describe the delivery area of a pizza restaurant. Religious administration is formalised (at least for the christian churches), and is therefore verifiable. Same for health care areas, emergency services etc. These will be defined and documented by some higher authority. As such, I would think they are in the same category of boundary as government administrative areas and would not be out of place in OSM. The freedom to make an exception is very limited, if it exists at all; changes to these areas go through some kind of formal process and are fairly rare. Even schools (in the UK at least) often use a catchment area defined by postcode areas. A pizza delivery service is however always free to make an exception as it sees fit. Colin On 2012-12-03 10:20, Pieren wrote: On Mon, Dec 3, 2012 at 1:12 AM, Christopher Baines cbain...@gmail.com wrote: After more consideration, and the helpful feedback from the list. I have revised the proposal [1]. It now uses a boundary relation. Once again, does anyone have any comments? 1: https://wiki.openstreetmap.org/wiki/Proposed_features/Catchment [1] About place_of_worship, check this old (and in use) proposal: https://wiki.openstreetmap.org/wiki/User:FrViPofm/Tag:boundary%3Dreligious_administration [2] boundary=religious_administration + admin_level=8 for the smallest Pieren ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging [3] Links: -- [1] https://wiki.openstreetmap.org/wiki/Proposed_features/Catchment [2] https://wiki.openstreetmap.org/wiki/User:FrViPofm/Tag:boundary%3Dreligious_administration [3] http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Status of maxspeed:wet
pOn 2012-12-03 20:27, Ole Nielsen wrote:/p pgt; BTW, I'm not sure how useful the wet tag (old style or new style) is./p pIn France the speed limit on motorways is 130 when dry and 110 when wet. I don't know what the legal definition of wet is for these purposes. I do know I would not like to be in a discussion with a French policeman about whether moist counts as wet or dry. One day someone might build a router with a checkbox for assume roads are wet./p pColin/p ___ 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 One sign (with the picture of the lorry) talks about goods vehicles, the other (top-left of next page with Weak Bridge) refers to vehicles. I expect that a bus is not classed as a goods vehicle even though it weighs typically 10-15T. Same for (army) tanks etc - I don't expect these to be classed as goods vehicles. Colin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposed feature - age groups in schools
Take a look at the discussions on this page: http://wiki.openstreetmap.org/wiki/Talk:Tag:amenity%3Dschool Min_age and max_age are already proposed there, as is the use of the UN classifications (ISCED) for the level of education. So I'm afraid I will be voting against your proposal; not because it is a bad idea, but because I think it should build on earlier discussions and be integrated with them. Colin On 25/11/2012 01:08, Svavar Kjarrval wrote: Hi. The RFC process has started for my proposal to tag the age groups schools offer education for. More information is on the wiki page. The proposal is at https://wiki.openstreetmap.org/wiki/Proposed_features/age_group . With regards, Svavar Kjarrval ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Gross vehicle weight rating
I think you mean maximum gross vehicle weight, not just gross vehicle weight. Maximum GVW is documented on the registration documents. The GVW itself is the mass of the vehicle plus specified elements 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 ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Gross vehicle weight rating
Sorry, please ignore this, it was a random thought I was preparing and I pressed the wrong button by accident. I think you mean maximum gross vehicle weight, not just gross vehicle weight. Maximum GVW is documented on the registration documents. The GVW itself is the mass of the vehicle plus specified elements 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 ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] fire district boundaries
I wouldn't use boundary=admin with admin_level unless there is actually a hierarchical relationship with the levels above/below. Otherwise they should really be in their own hierarchy, using something like boundary=fire_service. AIUI the US fire departments are at the city or county level. Can a city/county have more than one FD within its borders? Can an FD's jurisdiction extend across local government boundaries? The points I'm trying to make are that: 1) a fire district is not a unit of local government, so it doesn't fit naturally with boundary=admin 2) the use of admin_level (the level bit) implies a hierarchy which may not be the case. The basic hierarchy is that the US consists of States which consist of Counties which have Cities (yes I know it's more complicated than that in practice). A City may have fire districts, but it may also have suburbs, police precincts etc which have little or no relationship to each other in terms of boundaries, although they are all subsets of the enclosing City. Perhaps all of these should be the same admin_level, one level below the city, with some distinguishing tag to separate police areas from fire etc. Excuse me if I have misunderstood (I am not an American) but I am just trying to keep different concepts separate, avoiding reuse of tags for conceptually different things because it seems easy. Colin admin boundary levels 9 10 are unused in the US. i see some usage of level 9 for fire district boundaries in the US. opinions? thanks, richard ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] exit_to on motorway_junction
Using only exit_to there is no way to handle junction topologies other than a straightforward highway exit, where there is one big through road and one small road leaving. What about wrong-side exits? Or where the highway splits into two (or more) roads of equal importance? Destination tagging is used a lot in the Netherlands, placed on the first segment of each way *after* the node where they split. My Garmin warns me ahead of time which side to keep to, so there doesn't seem to be a need to start the tagging at the first sign (which may be 1km or more before the actual junction). I have not yet found a case where adding destination=* around a junction felt like the wrong thing to do. IMHO destination=* on the ways is the right balance between the rudimentary exit_to on the node and using a relation which will have problems with support/adoption by both mappers and toolmakers. Colin I don't see any reason to deprecate exit_to, it seems to be the simplest method of mapping a destination sign on a motorway junction or similar exit. I use exit_to fairly frequently and it has been a documented tag for a while (although on the motorway junction page rather than it's own page) and is also used in JOSM presets. I feel it is a less ambiguous tag than destination (as a tag on a way) as it shows the specific point where a destination is signed, unlike destination tagged on a way. If you use destination as a tag on a way then I think you'd need to be sure that at every point along that way the destination(s) given is the same throughout and if not or you didn't know you'd need to split the way. The Taginfo stats also seem to show that exit_to is the most popular of the three different ways of mapping destinations: a destination relation, exit_to on a junction node, or destination as a tag on a way. A destination relation is also a clear way of mapping a destination as the intersection and both the 'from' and 'to' ways are part of the relation, and is particularly useful in mapping situations where exit_to wouldn't work (like at a crossroads) so I do also use this method. It is however more complex (and so is unlikely to be a method that a new mapper would be able to use) particularly where there are multiple destinations given on a sign which requires a relation for each destination. Cheers, Paul Williams (Paul The Archivist) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Differences between crop and produce?
As a sidenote there seems to be suggestions for maize and corn, which, if I interpret this right, are the same plant, the first being BE and the second AE? (As we generally use BE, maybe if what I suppose is true we should mark corn as deprecated?) From wikipedia http://en.wikipedia.org/wiki/Corn_(disambiguation) : Corn is the name used in the United States, Canada, and Australia for the grain maize. In much of the English-speaking world, the term corn is a generic term for cereal crops, such as: Barley Oats Rye Wheat This certainly corresponds to my understanding, and my brother's (he's a farmer). Looking at other European languages, I think maize is less likely to be misunderstood; in many languages the native word is clearly a variant of maize: http://www.collinsdictionary.com/dictionary/english-french/maize?utm_source=searchboxutm_medium=widgetutm_campaign=frenchutm_content=french.about.com So I would vote for using maize and not corn as maize is hyponym of corn. Colin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] exit_to on motorway_junction
Johan, I agree with your statement that destination is much more universal than exit_to. I would prefer to see destination brought into wider use and exit_to deprecated. I only use destination, which I use very frequently to help make routing instructions (not: routing calculations - these have nothing to do with destination tags) more closely reflect landmarks on the ground (i.e. large signs at junctions). Colin On 18/11/2012 19:08, Johan C wrote: On http://wiki.openstreetmap.org/wiki/Tag:highway%3Dmotorway_junction you can find the following description on the exit_to tag. 'exit_to http://wiki.openstreetmap.org/wiki/Key:exit_to=* should be used to detail the destinations where the junction exits to---for example, if signage states a road leads to Anytown on the A1000... exit_to http://wiki.openstreetmap.org/wiki/Key:exit_to=Anytown A1000 http://wiki.openstreetmap.org/w/index.php?title=Tag:exit_to%3DAnytown_A1000action=editredlink=1; if multiple destinations are shown on signage, tag them with semicolons: for example, exit_to http://wiki.openstreetmap.org/wiki/Key:exit_to=Anytown A1000; Elsewhere A1001; Anyvillage http://wiki.openstreetmap.org/w/index.php?title=Tag:exit_to%3DAnytown_A1000;_Elsewhere_A1001;_Anyvillageaction=editredlink=1; note that Anyvillage doesn't have a ref number' Unfortunately, exit_to is not documented. The destination in my opinion has same purpose as exit_to, but is a better choice because you can use it on both outgoing parts of the Y-branch and because you can use in in conjunction with destination:lanes. Some questions on this: 1. Have you ever used exit_to? 2. Have you ever used destination? 3. are you willing to document exit_to? 4. is it clear for you when to use exit_to and when to use destination? 5. do you have any problems (and if so: which ones) when the exit_to description is removed from the wiki? I'm looking forward to your answers Cheers, Johan. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] exit_to on motorway_junction
Phil, there's a difference between routing calculation (which neither knows nor cares about road names, numbers, signposts etc) and how the result of the calculation is presented to the user. Then you need to relate the nodes/edges in the routing graph back to the real world. The value in this tag (as well as name, destination etc) is that the navigation software can give instructions based on recognisable landmarks instead of referring to way IDs. This distinguishes between pure routing and useful navigation. Colin On 18/11/2012 21:12, Philip Barnes wrote: On Sun, 2012-11-18 at 20:20 +0100, malenki wrote: What is the use of tagging some examples where one road connects to when there is a system-inherent focus on finding such connections automagically (this one is called Routing)? I'd like to have examples, please I found this one by accident when I was looking at motorway junctions after reading this thread. http://www.openstreetmap.org/?lat=52.65853lon=-2.29423zoom=15 Eastbound Wolverhampton (W) A41 Westbound Whitchurch A41;Weston They are just copied from the signposts. I see no value in this tag, after all as you say its called routing. Phil ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] exit_to on motorway_junction
On 18/11/2012 21:59, Philip Barnes wrote: On Sun, 2012-11-18 at 21:26 +0100, Colin Smale wrote: Phil, there's a difference between routing calculation (which neither knows nor cares about road names, numbers, signposts etc) and how the result of the calculation is presented to the user. Then you need to relate the nodes/edges in the routing graph back to the real world. The value in this tag (as well as name, destination etc) is that the navigation software can give instructions based on recognisable landmarks instead of referring to way IDs. This distinguishes between pure routing and useful navigation. Thats the point I am making, the most useful instruction a satnav can give is leave the motorway a junction 4, or words to that effect. There is nothing more recognisable than the junction number. Well, for a start junctions are only numbered on motorways and some trunk roads. I think most people would consider keep left on the A1001 towards Anytown clear enough (assuming that's what's on the sign), with or without a junction number. There has also been a discussion going on (admittedly outside of the UK) about the use of destination:ref to store the ref of the destination, so in this case we would have destination=Anytown and destination:ref=A1001, plus junction:ref=5 or whatever. By structuring the information in this way we give navigation software the choice of how to present the data. Colin Phil ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fuel, additional tags
On Mon, 2012-11-12 at 20:00 +, Malcolm Herring wrote: On 12/11/2012 19:27, Jo wrote: The dye added is not the common denominator. We need the British term for the tax break status of it. Two common terms in use are: marked diesel and agricultural diesel. In the UK its usually called Red Diesel. Have never seen it sold alongside normal petrol or diesel however, it is illegal to drive on a public road when using it. Strictly speaking this is not true in the UK: there are many circumstances in which you can use red diesel on a public road. It depends on what you are doing, and with what. Low-duty diesel is also available to boat-owners, although not for propulsion. You buy red diesel and settle up the fuel duty with the supplier according to your declaration of how many percent of this fuel will be used for propulsion in UK waters, and how much for other things such as heating/electricity. More info here: http://www.rya.org.uk/infoadvice/regssafety/reddiesel/Pages/buyingreddiesel.aspx ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging GB railway stations and track
Wouldn't the route code be better in a relation? I'm sure there will be some bits of the network which are part of multiple routes. Why include the word code in the tag name for CRS (and nr_route_code) and not for TIPLOC and STANOX? Colin All, I'm part of a group of people who are working to get a richer set of metadata attached to the railway network in Great Britain, specifically: - Tagging railway stations with the three-letter CRS (computer reservation system) codes, which is widely used by train companies and the public to refer to stations, plus TIPLOC (TIming Point LOCation) codes - used in timetable planning - to relevant parts of stations, and STANOX (Station Number) codes used for train reporting - Adding junctions as nodes or closed ways (depending on their structure) to existing railway lines, along with their TIPLOC and STANOX codes - Adding Network Rail route codes to logical groups of routes and tidying up line names I've started using three tags - ref:crs_code, ref:stanox and ref:tiploc for locations, and ref:nr_route_code for route codes - they're attached to St Albans Abbey station and stations toward Watford Junction as an example. Does anyone have thoughts or comments on the above? I've set up a Wiki page at http://wiki.openraildata.info/index.php/AddingJunctionsAndSidingsToOsm and there's a mailing list at https://groups.google.com/forum/#!forum/openraildata-talk if you want to get involved. Peter ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tag ref on motorway_link
2012/10/30 Colin Smale colin.sm...@xs4all.nl: There is also the destination tag set which covers the ref as signposted, allowing the ref=* to reflect the actual administrative ID. http://wiki.openstreetmap.org/wiki/Key:destination If you mean by destination tag set the key destination:ref I'll agree. But please don't put refs into destination. In the case of ref that's indeed exactly what I meant. Personally I also allow destination to override name in mkgmap so the routing instructions reflect the big signs in preference to the small signs. That's why I was speaking slightly more generically. Colin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tag ref on motorway_link
* Andrew Errington erringt...@gmail.com [2012-10-24 14:49 +0900]: I think it's incredibly relevant whether it's included on the sign. I suspect that the vast majority of people who use maps with reference numbers on them use those maps for navigation. I think such people would primarily be interested in signed reference numbers, because it's pretty hard to navigate by unsigned ones. Thus, there should be some difference in the tagging of signed and unsigned reference numbers. There has to be room for both. Sometimes the signposts lie in the interests of clarity for navigation by road users. There is also the destination tag set which covers the ref as signposted, allowing the ref=* to reflect the actual administrative ID. http://wiki.openstreetmap.org/wiki/Key:destination Colin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tag ref on motorway_link
Hi Martin, First and foremost, tags applied to an object should of course refer to that object. I normally interpret the ref tag on a ROAD as the reference ID of that ROAD as designated by the powers-that-be. Motorway slip roads are (in my experience in UK/NL) administratively speaking an extra part of the motorway, which means the ref should be whatever the authorities consider it to be part of. There are often clues to this in the form of codes on street lights and distance posts. On the other hand, if the ref is to be interpreted as the road reference for that road as present on the signs for the public (referring to that very road itself, not the road the ramp leads to) then the junction number may be more appropriate. On the English wiki page for motorway_link it kind of hints in this direction. A motorway exit is really a compound object including typically four slip roads and sometimes roundabouts etc. Puritanically speaking we could considering modelling exits as a relation, with the motorway_links included with role=on_ramp etc. Then the junction number would live on the relation. A link from one motorway to another could then easily be shared between the relations for the junctions on each motorway. (In the UK, motorway-motorway junctions are numbered like any other junction. In NL they are not included in the junction numbering sequence; instead they have names like Knooppunt Oudenrijn). I guess the same question may be applied to the name tag? Colin Hi! I'm wondering what ref should be used on slip roads/ramps of a motorway (not the junction node, but the way tagged with motorway_link). Up to now I've seen: * the reference of the junction * the reference of the motorway * the reference of the junction not in the ref tag but in junction:ref * nothing (neither ref nor junction:ref) In the Wiki (English and German) I couldn't find an answer. Any opinions/comments/hints are welcome. Thanks, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag: Legally separated ways
There's maybe a difference between the case of two lanes in the same direction, and two lanes in opposite directions. On 16/10/2012 11:44, Janko Mihelic' wrote: I posted this picture the last time this came up. It shows that dividing roads is silly in some situations, for example countryside roads: http://i.imgur.com/p5Oto.png You have to divide the road each time there is not a full line on the road, ad you should put a restriction where those roads meet that restricts U-turns. What is the answer to that? Janko 2012/10/16 Simone Saviolo simone.savi...@gmail.com mailto:simone.savi...@gmail.com 2012/10/16 Martin Koppenhöfer dieterdre...@gmail.com mailto:dieterdre...@gmail.com Am 16/ott/2012 um 11:28 schrieb Markus Lindholm markus.lindh...@gmail.com mailto:markus.lindh...@gmail.com: To be able to do proper routing for emergency vehicles perhaps it would be a good idea to introduce something like landuse=highway that would denote an area suitable for motor vehicles and that is free of physical obstacles. There is a relation proposal (area) that suggests a solution to this without explicitly drawn closed areas Martin, could we please try to revive the proposal and make it go forward? I am one of those who would like to draw roads as an area, as you know :-) ___ Tagging mailing list Tagging@openstreetmap.org mailto:Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Conditional restrictions accepted – turn restrictions ahead?
On 16/10/2012 17:45, Rob Nickerson wrote: Hi Eckhart, Your right, voting has come to an end for the Conditional Restrictions proposal, which was approved. A statement was not made on this list as Ole and I are working on how best to write the feature page so that some of the concerns raised (about complexity / difficulty to understand) are reduced as much as possible. Like Martin, I'm not hugely convinced about the need for complicated turn restrictions (most of the restrictions will be on the road and the detail on the turn sign will simply be advanced warning for the driver). Having said that, you have provided a few examples so I have looked into it: 1. Currently we tag a no left turn restriction using restriction = no_left_turn. 2. If we want this to apply only to HGVs then the key is changed so that it become restriction:hgv =no_left_turn. To draw the comparison with Conditional Restrictions the above tags cover of restriction type, transportation mode and the tag value. There is no need to specify direction as this is already captured in the relation (from, via, to). I am not sure you can say this. It should work where the junction angles are close to 90 degrees, but for a shallow Y junction things might need a hint as to whether it is a curve to the right with a junction to the left, or a curve to the left with a junction to the right. The type of restriction should reflect the road signs. At a T-junction, a mandatory left turn could be considered different to a no right turn, even if they are effectively the same thing. This cannot be derived from the geometry alone. Colin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] destination_ref vs. dest_ref vs. destination:ref
I saw the choice between dest_ref and destination_ref and adopted dest_ref for the simple reason that it's shorter. In my mkgmap styles I allow for either, and recently added destination:ref to that list. I'm not particularly bothered which one wins, but I'm always in favour of a bit of standardisation. Slightly OT: Can I put in a plea to continue to populate these tags on the way as a whole even when the :lanes: data is present? Promising as it is, it will take a while before :lanes is properly supported by mappers and tools. Please don't remove useful, working data just because there's a new kid on the block. Colin On 15/10/2012 09:23, Martin Vonwald wrote: Hi! Up to now I usually used the tag destination_ref to specify the ref of the road where a link-road is heading, in analogy with the destination key. Now I've seen the key dest_ref in use and also destination:ref. Of course none is documented in the wiki ;-) What should we do? I could write a proposal but what for what tag? Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag: Legally separated ways
I would choose option b). Even if all four lanes are one piece of carriageway, it is useful for routing directions etc to be able to make a distinction between the left and right parts of the road. Normal mortals are supposed to treat the solid white lines as if they were a brick wall anyway, and be on the correct part of the road before part 5 starts. If we start tagging exceptions to traffic laws for emergency vehicles then we have an awful lot of work to do... I am not sure I would interpret the diagram in that way though; the fact that there are no arrows on the road from part 5 onwards suggests to me that there is no chance of changing your mind. I think the intention is that part 5 is the start of physical separation, but I might be wrong here. Colin On 15/10/2012 10:56, Martin Vonwald wrote: Hi! Some kind of short how-would-you-tag-this-survey. Have a look at part five of this motorway: http://wiki.openstreetmap.org/wiki/File:Lanes_Example_2.png Only part 5 is relevant. Assume there is no physical separation just a double line between the upper and lower two lanes. How would you tag this: a) One way with lanes=4 b) Two separate ways with lanes=2 each c) Tell me! Please also reason your decision. Many thanks in advance, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag: Legally separated ways
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. Colin On 15/10/2012 19:55, Alberto wrote: a) One way with lanes=4 b) Two separate ways with lanes=2 each c) Tell me! a) because distinction between physical and legal barriers is important. Ok in that picture there is no much difference, but as Simone pointed out, for long roads there is a big difference: if any router can't distinguish between physical and legal barrier, it will not suggest to emergency vehicle to cross the line, and it will tell them to do a long alternative trip instead. This is a big problem, because when you are driving the GPS shows you only a little portion of the route and you may not understand (especially in emergency) that you can shorten the route simply crossing the line. Moreover if we accept solution b) we should tag every road with continuous line in the middle as two separate roads, one for each direction. Additionally to the lanes=4 and oneway=yes you could put a divider-tag on the way http://wiki.openstreetmap.org/wiki/Proposed_features/Divider even if it doesn't explicitly tell you where the divider is placed you might be able to infer it from the following ways (at least in this case). +1 We can improve this proposal, to make clear where the divider is placed. Cheers Alberto (Viking81) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Naming boundary ways - the — separation character
On 10/10/2012 21:53, Alexander wrote: Hi, I think the separation sign should be chosen by the render. +1 Why not adding new tags like: name:left=Mexico name:right=USA -1 This looks to me like blatant tagging for the renderer, i.e. manipulating the tagging to produce an optically pleasing result. I would contest that the border itself has no name; the names belong to the areas on either side, which are of various types and admin_levels. Therefore no name could ever be right under all circumstances. The renderer must make a choice out of the names of the boundary relations to which the way belongs, depending on whether the map is to show the countries of the world or the municipalities of Texas. Plus that the boundary way may actually also be a geographical feature such as a river with its own name; giving name:left and name:right a completely different set of semantics to the basic name tag doesn't sound like good practice to me. Colin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] name of river/admin area
On 04/09/2012 15:30, Phil! Gold wrote: I fully agree that there's no way to set a global standard; it should be left to the locals, who know the features best. But how local is local? It's obvious that a single standard for the whole world is not going to happen, but there has to be some level at which standardisation is a good thing. If individual mappers set their own standards, with no regard for their neighbours, we will have total anarchy and useless data. Somewhere between those two extremes there has to be a place for some guidance. Many things have multiple names according to the context (official, signed, colloquial etc). Look at the use of language variants: different versions of the same data can be tagged easily by appending a context identifier (in this case a language code). But there can still only be one default as indicated in e.g. name=*. Renderers need to be in a position to choose whether to display the official name of a city, or the short name, or the colloquial name or whatever. If a renderer has no way of knowing what type of name is indicated by name=*, the finished map will be an inconsistent mess. The proper solution is IMHO that the renderers can rely on some kind of standards, based on explicit tags for the different types of names and giving plain old name=* a lower priority than the explicit type of name it is looking for. It must be possible, based on the tagging and the territory(i.e. country, state, county???) for a data consumer to obtain directly or to derive what it needs. Losing the usage context for a name is like lossy audio compression. Once the detail is lost, it's gone for ever. We already tag names in multiple languages, so the renderer can choose which version to use. There is plenty of discussion about which value goes in plain name=* of course. armour flameproof=yes We can avoid the whole problem by deprecating the plain name tag, thus forcing every name to be labelled with a language. Same for rivers and admin areas - forget name, only use official_name, short_name, loc_name etc etc. with defined and documented semantics, which may vary by territory, in combination with a language code. /armour Colin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] name of river/admin area
I can't find any guidance or consistency in the data, so I thought I'd let up a balloon here... Should the name=* for a river include the word River? Is it name=Thames or name=River Thames? According to the wiki [1] we should only use Thames in this case. If we consider River Thames to be the full name we can put that in full_name or official_name. The word River doesn't always precede the name: there are many examples of XXX River (e.g. Hudson River in NYC). Because of this I think we should put the full name somewhere. An analgous situation occurs with administrative units such as cities, boroughs etc. Should the NYC boundary be tagged with name=New York or name=New York City or name=City of New York? In the UK, is it name=Maidstone or name=Maidstone Borough Council or name=Borough of Maidstone? Colin [1] http://wiki.openstreetmap.org/wiki/Names#Name_is_the_name_only ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Carriageway divider
I live in hope that, one day, we might have documented defaults or implied values per territory. Until that time, we may have to map both the tangible artefact (solid line) and the implications for routing (no u-turns etc.) separately. They are distinct concepts, related by the rules of the territory. Colin On 21/08/2012 09:47, Pieren wrote: On Tue, Aug 21, 2012 at 1:04 AM, Tobias Knerr o...@tobias-knerr.de wrote: So I think that mapping divider based on pattern type is a better choice than mapping them based on their legal effects. Until now in OSM tagging, all turning restrictions have been described by the restriction, not by the traffic sign itself like arrow_up or arrow_left_crossed-out. Your argument about unambiguous if you know the law locally is true in both translations. Excepted that with solid_line, you ask the applications to know all local laws arround the world. With the value no_u_turn, applications or other contributors around the world understand immediately what it means. Your second argument about multiple tags is correct but the list of line patterns on the ground can be very long as well (double solid line, dotted lines on one side, colours, etc). Pieren ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Carriageway divider
Isn't that what turn restrictions are for? Colin On 20/08/2012 13:10, Markus Lindholm wrote: On 20 August 2012 12:57, Markus Lindholm markus.lindh...@gmail.com wrote: On 20 August 2012 09:39, Elena ``of Valhalla'' elena.valha...@gmail.com wrote: On 2012-08-19 at 14:09:18 +0200, Markus Lindholm wrote: In my opinion it's best to treat legal separation (i.e. solid_line) the same way as physical separation, i.e. create two separate highways, one in each direction. This doesn't correspond to reality: I believe that an emergency vehicle can cross a solid line, while of course they would have problems with a physically separated road. I consider legal restrictions to be part of reality. Also consider that a physical separation might be nothing more than a 20cm high curb that could be as easy to cross for an emergency vehicle as a painted line. One other aspect: it would not be possible to create correct routes from an address that's in a middle of a block where the the street has lanes in both direction but that are legally separated. Now if the shortest route would be to turn left (in a country with right hand traffic) but the legal route would require to start the trip by going right, there's no way to express that without having to separate highways, one in each direction. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] traffic=fast
As every track segment has a maximum speed, why not just apply the existing maxspeed=* tag to the tracks? It is not clear to me whether your intention with traffic=fast refers to some attribute of the track itself, or the use to which it is put. Is it some official designation (from Network Rail)? I recall also seeing things like service=main_line (from memory) to distinguish main line from local tracks. Colin On 09/08/2012 11:33, Richard Mann wrote: There's two things that distinguish HSLs/LGVs/NBSs: high maxspeed (typically 250-320, though some would include the new lines in Switzerland, which are only 200), and a lack of slow traffic (freight, stopping passenger services) because they have alternative routes. In some cases, you can get pretty high speeds without providing a second pair of lines, if traffic is sparse (upto 200kmh in the UK, upto 230kmh in Germany), so I think the presence/absence of a parallel slow route is something that can usefully tagged explicitly. Richard On Thu, Aug 9, 2012 at 12:21 AM, St Niklaas st.nikl...@live.nl mailto:st.nikl...@live.nl wrote: Hi taggers, Colins question are there more countries with different speed rules on tracks ? Yes all the TGV like tracks in Europe through, France, Germany and Netherlands are specially build for TGVs but somewhere there still tracks combined, limited speed up to 100 miles / hr. Hendrik ___ Tagging mailing list Tagging@openstreetmap.org mailto:Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Advice clarification of the railway tracks=* tag required.
While we're at it, what's traffic=fast on a rail line? What other values could there be? Weren't we using service=* for this kind of thing? Colin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] on the name of a tag for landcover
On 03/08/2012 13:36, Martin Vonwald wrote: To cut a long story short: landcover=herbs would also be fine, IF we would expect that those tag will be often used and the difference to landcover=grass is substantial enough. As I doubt that I would recommend landcover=grass and grass=herbs. Grass is an example of a herbaceous plant, and we tag from generic towards specific, so it should really be landcover=herbaceous and herbaceous=grass. I would advise against using herbs in this context. Although it may be technically not incorrect amongst biologists, in common English usage it refers to plants used for flavourings etc. like Thyme, Rosemary, and Oregano. Joe Mapper is never going to forget that, although Jean-Luc Cartographe might be excused for confusing grass and herbs (herbe is French for grass, as well as the culinary plants) Colin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging u-turn restriction with continuous painted line
On 03/07/2012 13:29, Janko Mihelić wrote: I think no_left_turn is the best solution. The line on the middle of the street is not a u-turn indicator, it is an overtake indicator which can be tagged with overtaking=no and overtaking=both. Are you sure that the dotted overtake line allows you to make a u-turn? Not sure about other countries, but in UK and NL a solid line means (formally) no crossing and not no overtaking. For larger vehicles it might be effectively the same thing, but for motorcycles (for example) it's not as they can overtake another motorcycle without crossing the line. So if it's a solid line, that also means no U-turns, and also no left turn (driving on right). Colin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Ref tag
Strictly speaking the international E-numbers are routes, not roads. The European Route Network is overlaid on top of the national networks and doesn't bother about international boundaries. In Belgium however it is very common to use the E-route numbers on signs instead of any local A-number where a motorway is part of the ERN. In this case I would say that int_ref and ref should have the same value - ref should be used for what's on the signs. If the motorway has an underlying A-number (purely for administrative purposes) then this might fit in nat_ref. In the UK, the E-numbers are not signed at all, but there are ERN routes there. For example the E20: http://en.wikipedia.org/wiki/European_route_E20 which runs from Ireland to Russia. Colin On 19/06/2012 11:06, Martin Vonwald wrote: The reason why I'm asking is the SS3bis/E45 in Italy: http://www.openstreetmap.org/browse/way/22873607 It is the first road I've seen where the ref tag contains the international ref and not the national ref (besides int_ref and nat_ref). Martin 2012/6/19 Martin Koppenhoefer dieterdre...@gmail.com: +1, I'd put the national ref in ref and the international ref in int_ref. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Ref tag
Up to the usual standards one has come to expect from these large international organisations, I would say. On 19/06/2012 13:20, Philip Barnes wrote: There is no ferry between Kingston upon Hull and Esbjerg. An alternative ferry is available from Harwich (350 km/220 mi from Kingston upon Hull) to Esbjerg. A well thought out route? Phil -- Sent from my Nokia N9 On 19/06/2012 11:46 Colin Smale wrote: Strictly speaking the international E-numbers are routes, not roads. The European Route Network is overlaid on top of the national networks and doesn't bother about international boundaries. In Belgium however it is very common to use the E-route numbers on signs instead of any local A-number where a motorway is part of the ERN. In this case I would say that int_ref and ref should have the same value - ref should be used for what's on the signs. If the motorway has an underlying A-number (purely for administrative purposes) then this might fit in nat_ref. In the UK, the E-numbers are not signed at all, but there are ERN routes there. For example the E20: http://en.wikipedia.org/wiki/European_route_E20 which runs from Ireland to Russia. Colin On 19/06/2012 11:06, Martin Vonwald wrote: The reason why I'm asking is the SS3bis/E45 in Italy: http://en.wikipedia.org/wiki/European_route_E20 It is the first road I've seen where the ref tag contains the international ref and not the national ref (besides int_ref and nat_ref). Martin 2012/6/19 Martin Koppenhoefer dieterdre...@gmail.com mailto:dieterdre...@gmail.com: +1, I'd put the national ref in ref and the international ref in int_ref. ___ Tagging mailing list dieterdre...@gmail.com mailto:dieterdre...@gmail.com http://en.wikipedia.org/wiki/European_route_E20 ___ Tagging mailing list dieterdre...@gmail.com mailto:dieterdre...@gmail.com http://en.wikipedia.org/wiki/European_route_E20 ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
Hi Eckhart, On 15/06/2012 01:08, Eckhart Wörner wrote: Hi Colin, Am Freitag, 15. Juni 2012, 00:24:18 schrieb Colin Smale: If I were king I would be looking for a system that: * makes common cases easy Extended conditions: ☑ * makes complex cases possible Extended conditions: ☑ * makes 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. You might be right about this. Of course it would be best to only use the specification at entry time. What I had in mind was the ability to share functions with the world without having them replicated millions of times through the database, which is what will happen if you put a function in a tag so you can reuse its value. Using an external file (i.e. not in the database - analogous to how mapnik/mkgmap style sheets are handled) will also not impose any standards on anybody so as not to anger a significant majority of OSM users. Editors can pick the files up dynamically and use what they choose to use. Maintaining a strict division between specification and implementation would require some kind of packaging. Languages like perl and python allow pre-compiled packages, but they also allow you to share scripts and execute them directly. * 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. The bulk of the discussion up to now has been about access type tags, producing a boolean value: can I or can't I use this road under the given conditions. Why limit it to boolean? Why not address the use case of what is the maximum speed for vehicle X under these conditions (returning a number) or what are the opening hours of this amenity on a given date (returning a string which can be parsed as a date, or returning an object containing some more date objects if you want to go further)? * can use the value of other tags as variables That's just a desaster waiting to happen. Why do you think that would be such a disaster? * 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' ? The comparison operator here is which is definitely usual. Thanks for adding unit conversions to the list! * supports string concatenation operation name = (lang == 'de' ? 'Bahnhof von ' : 'Gare de ') + 'Lyon' Please provide a use case. Well, this specific example is already adequately covered in current tagging practise (name:fr=Gare de Lyon). It's more for completeness - if it wasn't there, I am sure someone will miss it. I wouldn't like us to paint ourselves into a corner by only supporting boolean operations. I wonder if this discussion could also be useful to the lanes discussion in some way? Use cases for routers like how many lanes does this road have, am I allowed in lane 2 etc etc also need to be dynamic and show a lot of similarity to the basic road-level access business. Eckhart ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
Tobias, thanks for your constructive response.
On 14/06/2012 03:22, Tobias Knerr wrote:
On 13.06.2012 23:48, Colin Smale wrote:
Taking the access discussion to a higher
level of abstraction, and without abandoning the key-value pair
paradigm, I believe we are looking for a way of giving a tag a value
which depends on all kinds of variables. *IMHO* we need a way of
making expressions, with operators to combine basic values in different
ways. These basic values might be literals, other tags, runtime values
or function calls. These functions might be built-in (or assumed) for
the most basic stuff, but it would be good if we could define additional
user-defined functions.
Whatever syntax is used, the *primary* requirement is that it is
usable by programs - editors, renderers, routers etc. followed by a
secondary requirement that it be understood by humans.
Any condition syntax needs to be parsed by programs, this much we should
all be able to agree on.
As for the secondary requirement, I think that keeping the number of
different basic constructs small can help a lot. The resulting
micro-language can then be easier to read, and also easier to wrap into
a GUI than a language construct that gives the user a lot of freedom.
So when we talk about requirements, we should also consider whether
there are things we _don't_ need.
Fully agree.
And imo there are several, such as:
- Or operators. Maxspeed is 80 if it's wet or Sunday can be
rephrased as Maxspeed is 80 if it's wet. Maxspeed is 80 if it's
Sunday. IOW, these can be modelled by using two tags instead of one.
- Not operators. These can also modelled by using two tags, and common
tagging idioms like access=no + x=yes even do this already.
- Brackets for expressions. If we limit ourselves to just and
operators, evaluation order doesn't matter.
My concern with this is that it may become unwieldy and cumbersome with
anything beyond fairly trivial cases such as your maxspeed example. Then
the debate will erupt again, and PhD's in boolean algebra will point out
that it *can* be done... In the mean time everyone has to learn a new
grammar and mistakes will be made. and, or and not are the
building blocks of boolean logic and are easily understood by computers.
For the human audience who can't grasp it yet there are millions of
books and websites. The way it is presented in map editors will be
extremely critical in any case. Also, let's not forget to peek beyond
the boundaries of the current discussion about access (i.e. routing)
to see how the conclusion here would fit in other domains.
Here's a test case. No motor vehicles mon-fri between 1600-1800 except
agricultural vehicles and good vehicles *in this direction*. Going the
other way the sign is similar but the times are between 0600 and 0900.
This is a short stretch of narrow road and the restrictions are intended
to stop commuters using it as a rat-run, while at the same time allowing
work to carry on as usual on the farms and businesses along that road.
http://goo.gl/maps/ymvt
motor_vehicle:forward:expr=vehicle_type==agricultural ||
vehicle_type==goods || weekday == SATURDAY || weekday == SUNDAY ||
time16:00|| time18:00
motor_vehicle:backward:expr=vehicle_type==agricultural ||
vehicle_type==goods || weekday == SATURDAY || weekday == SUNDAY ||
time06:00|| time09:00
What would this look like using only AND operators?
Pseudo-Javascript: (!is_motor_vehicle(vehicle_type)) ||
((vehicle_type='hgv') (time'10:00' || time'20:00')
intention='loading')
So starting from your Pseudo-Javascript example quoted above,
we could get to something like
is_motor_vehicle(vehicle_type) - no
(vehicle_type='hgv') (time'10:00' || time'20:00')
intention='loading') - yes
It has fewer language constructs, but expresses the same thing - and
still fulfils all the requirements.
Another aspect to consider is that some of the problems we are trying to
solve here have already been tackled elsewhere in OSM. This includes:
- defining a syntax for time intervals (opening_hours)
- defining a subset hierarchy of vehicle categories (such as
motor_vehicle including hgv as a subset)
Probably it would make sense to re-use these existing building blocks.
This could be done with a small change to the example above:
in_vehicle_category('vehicle_type') - no
in_vehicle_category('hgv') in_time_interval('20:00-10:00')
intention='loading') - yes
So how do the existing proposals fit in here? Well, the primary
difference between the example above and extended conditions is that
the latter aims for for short, manually editable strings by letting
literals for vehicle classes, weather conditions etc., as well as time
intervals, stand for themselves - based on the assumption that a parser
will be able to unambiguously identify them.
If we chose to do this for our returning example, it might look like this:
motor_vehicle - no
hgv 20:00-10:00 loading - yes
And that differs from extended condition just
Re: [Tagging] Reviving the conditions debate
On 14/06/2012 11:19, Pieren wrote: On Thu, Jun 14, 2012 at 8:38 AM, Colin Smale colin.sm...@xs4all.nl wrote: Back to my idea to move all 'variables' to the value : Let say we create a new access keyword : condition (or access_condition, cond, expr or whatever_you_like) suffixed by a number, eg. condition1, condition2, etc (unlimited but easy to parse; separator unnecessary). Then conditions are combined using a plain text language, not using ||, , ~, $ or any symbols only known by software programmers (important for readability by wide audience) eg. and , or , not , in like SQL. I fully agree that the complexity should be principally in the value, not the key. Sounds good. I think parentheses (or some equivelent) will still be necessary however for grouping, so you can say A or (B and C) or D as A or B and C or D would not do the right thing (using conventional precedence rules). As I understand it you are proposing that the operands be variables (syntactically speaking). It's only a small jump from there to allow literals, and add a couple of operators like equals/not equal/greater than etc. Like that the definition of the conditions as separate tags could be redundant in many cases, but it would allow for reuse of common subexpressions. I am sure that users will be able to get their head around something like this - I hope so, because they will have to. The users will have to learn a new trick anyway, whether it be this expression syntax or the access 1.5 proposal or its competitors. Which approach will give least problems? Can they be understood unambiguously by humans and computers? Or are we going to get lots of bad data due to people misunderstanding/misinterpreting the rules? The set of operators is limited (basically just comparison operations plus and/or/not), and the editors can support the users by presenting the logic represented by the expression in some kind of more natural language if required. Examples: Here's a test case. No motor vehicles mon-fri between 1600-1800 except agricultural vehicles and good vehicles *in this direction*. Going the other way the sign is similar but the times are between 0600 and 0900. access=yes (this implies agricultural=yes and goods=yes) condition1=Mo-Fr 16:00-18:00 condition2=Mo-Fr 06:00-09:00 motor_vehicle:forward=not condition1 motor_vehicle:backward=not condition2 I think there should be an explicit way of identifying condition1 and condition2 as time constraints. There will also be conditions based on other dimensions such as weight, length, etc. no motor vehicles except for loading/unloading by hgvs between 8pm and 10am access=yes motor_vehicle=no condition1=loading // improving current 'destination' condition2=10:00-20:00 hgv=condition1 and not condition2 Short, readable and easy, no ? Definitely readable. Could be shorter. Easiness is a rather subjective measure. How do these alternatives score? motor_vehicle:expr=(vehicle_type==hgv) ((time20:00)||(time10:00)) (intention==loading) motor_vehicle:expr=(vehicle_type=hgv) and ((time20:00) or (time10:00)) and (intention=loading) One small point though: loading is not the same as destination, although this may vary by jurisdiction. You can't park in a parking bay marked for loading just because you want to visit someone nearby. Pieren ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
On 14/06/2012 12:53, Flaimo wrote: this notation has the same flaw as the current access scheme. it mixes transportation modes and user roles. motor_vehicle is a transportation mode. agricultural is a user role. not everywhere on this planet agricultural automatically means motor_vehicle. that is what the 1.5 proposal tries to solve. I would say that according to current usage motor_vehicle is a class of vehicles. The tagging is intended to represent restrictions enacted by laws and indicated by signs. A large proportion of the countries in the world adhere more-or-less to the UN (ECE?) standards for road signs, which is why the sign for no motor vehicles is so ubiquitous. There are minor variations in the exact definition of motor vehicle for these purposes (does it include mopeds? mowing machines?) but within a traffic law jurisdiction its definition will be consistent. There have been many debates on whether or not to document OSM defaults or assumptions for each jurisdiction. I don't expect there to be total agreement about agricultural either. There are signs for no agricultural vehicles, which in my experience refer to the type of vehicle and not what it is being used for at that moment. But this again may vary per jurisdiction. If a farmer uses his combine harvester to go to the shop for some sugar, is that agricultural? Colin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
On 14/06/2012 13:00, Tobias Knerr wrote: On 14.06.2012 08:38, Colin Smale wrote: My concern with this is that it may become unwieldy and cumbersome with anything beyond fairly trivial cases such as your maxspeed example. For me, the goal is to make the common cases *easy*, and the rare complex cases *possible*. Difficult to argue with that! The second part makes a flexible grammar essential, as you cannot predict what these rare complex cases might look like. It's far easier to build a visual editor if you only need to support a limited subset of boolean logic. For example, the filter editor in my mail client (Thunderbird) is limited to a subset of boolean logic as well, for the same reason. Sure, it's limited to match all/match any and a fixed list of operators. But Thunderbird is not trying to represent something in the physical world here, only to help the user. Here's a test case. No motor vehicles mon-fri between 1600-1800 except agricultural vehicles and good vehicles *in this direction*. Going the other way the sign is similar but the times are between 0600 and 0900. What would this look like using only AND operators? motor_vehicle:forward:(Mo-Fr 16:00-18:00) = agricultural At first glance this looks like a motor vehicle going forward between those times is considered agricultural. It doesn't feel very intuitive, based on the established key=value paradigm. I thought of the following, based on the premise that the class motor_vehicle can be partially overridden by a subclass such as hgv or agricultural: motor_vehicle=yes motor_vehicle:forward:(Mo-Fr 16:00-18:00)=no motor_vehicle:backward:(Mo-Fr 06:00-09:00)=no hgv=yes agricultural=yes Colin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
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. 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. Bottom line: I question whether making it kind of pseudo-English-like is the right goal to aim at. A simple grammar which is (mis)understood equally over the whole world might be better. Your post below is full of examples supporting my point. The grammar should be derived from what you are trying to model, just as a (descriptive) grammar for English is reverse-engineered from the way the language is used. 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. Please feel free to carry on with your experimentation to see if you can make a grammar on this basis, but remember that humans have to read and write this stuff (which does not detract from my earlier assertion that machine-readability is a slightly higher priority than human-readability) and they often need clear boundaries to make the most of their creativity. If you put a child in the middle of an infinitely large field with no boundaries obvious to the child, they won't move far from where you put them. If you put the same child in a large fenced enclosure, they will explore every inch. Give a child a paintbrush in front of a huge blank wall and you will get a small picture. Mark out a frame on the wall and say paint in this and it will all get used. Give a mapper no limits on tagging, and many things will not get tagged (because of inner doubts about how to do it). Give the same mapper a menu of 100 tags which can be used, and he will use many more of them. 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. It's the IT-based interpretation of the word AND which leads to the grammar misinterpreting the intention. Think of the expression: a * b + c * d To the untrained eye this may appear ambiguous or be interpreted differently to how a compiler will interpret it. Nonetheless it's valid code and no compiler will complain. However style-wise there is a school of thought that such constructions are unsafe because a bug caused by precedence problems is difficult to find by a quick inspection. My mandating the use of parentheses to make the programmer's intentions clear to a code-reviewer helps to detect bugs early, and has the desirable side-effect of making the programmer think just a little bit harder about how it's going to work out. Prevention is better than cure: anything making it less likely that coding errors make it into the database is most definitely a Good Thing To Have. Grammars which allow just about everything are a pain because they frustrate this error checking and delay error detection considerably, often relying on a user to report an anomaly, triggering all kinds of incident management and problem management processes and costing thousands of times more to fix than if the input validation had stopped the error occurring in the first place. If I were king I would be looking for a system that: * 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) * uses grammatical constructions which are familiar to most people, or easily learnt * has a grammar allowing for a user-extensible function repertoire * allowing user-defined functions to be stored in an external file (accessible at entry and run time) * fits comfortably with the key-value-pair paradigm of OSM * can produce a result in a variety of data types including at least boolean, number, string * can use the value of other tags as variables * can use other variables supplied at run time (e.g. weather, time, vehicle type) * supports the usual comparision and numeric operations * supports string concatenation operation Colin On 14/06/2012 22:19, martinq wrote: Hi, sadly this discussion was restarted before I could establish a reference implementation for a less technical way of tagging conditional values (for those who are interested: it is a ANTLR grammar, hopefully with built-in evaluation code). The reference implementation is for me
Re: [Tagging] Reviving the conditions debate
For some reason everyone seems determined to come up with the most complex system imaginable, instead of taking successful ideas from the rest of the world. This trait is what causes many projects to fail. Let's not look at this as simply a discussion about access tags, but an opportunity to extend the syntax of the current key-value pair system to include flexible extensibility. How about something like access:expr=expression, where the expression is in some simple syntax and can reference pseudo-variables like time, day, weather, weight, height etc. Why not use a javascript-compatible syntax? Or a bit of XML? No point in re-inventing the wheel. Colin On 13/06/2012 14:35, Eckhart Wörner wrote: 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 ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Reviving the conditions debate
On 13/06/2012 18:23, Eckhart Wörner wrote: Hi Colin, Am Mittwoch, 13. Juni 2012, 18:11:53 schrieb Colin Smale: For some reason everyone seems determined to come up with the most complex system imaginable, instead of taking successful ideas from the rest of the world. This trait is what causes many projects to fail. Let's not look at this as simply a discussion about access tags, but an opportunity to extend the syntax of the current key-value pair system to include flexible extensibility. How about something like access:expr=expression, where the expression is in some simple syntax and can reference pseudo-variables like time, day, weather, weight, height etc. Why not use a javascript-compatible syntax? Or a bit of XML? No point in re-inventing the wheel. my sarcasm detection seems to be broken - are you seriously suggesting JavaScript or XML? Or are you suggesting that the proposal is too complex? Yes, yes, and yes. Colin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mapping larger Mini-roundabouts
On 06/06/2012 09:13, Martin Vonwald wrote: If you want to specify the dimension of the mini-roundabout I think it would be sufficient to specify the width of the approaching roads. Martin How about diameter=15 on the mini-roundabout node? This is factually correct, verifiable on the ground and (IMHO) non-controversial; routing would not be affected (no need to route over areas) and renderers can draw a bigger blob. Problem solved, simples. Colin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New access tag value needed?
When a UK sign says unsuitable for motor vehicles or unsuitable for HGVs it means discouraged in your terms. There is no guarantee that you *will* get into problems, but it is just a strong warning. A road that becomes a muddy track might present a problem for a normal car, but a trial bike or a tractor would be fine. The warning is probably not enforceable, i.e. if you ignore it you couldn't get a ticket for that fact alone; luckily for many drivers it's not illegal to be an idiot. So if the word unsuitable has the above semantics in normal use, it would make sense to me to call it unsuitable in the tagging instead of discouraged and using unsuitable to mean something else. How about unsuitable (i.e. preferably not) and impassable (i.e. don't even think about it)? Colin On 01/06/2012 09:09, Martin Vonwald wrote: 2012/5/31 Philip Barnesp...@trigpoint.me.uk: On Thu, 2012-05-31 at 14:41 +0200, Martin Vonwald wrote: 2012/5/31 Richard Mannrichard.mann.westoxf...@gmail.com: http://www.bbc.co.uk/news/uk-england-bristol-17530125 (lorry stuck on very tight corner) This is tagged hgv=unsuitable in OSM http://www.openstreetmap.org/browse/way/69590803 In my opinion this doesn't need a special tag. Because the geometry of the way (together with the tag width, if necessary) should carry enough information. Where there is signage stating 'Un-suitable For HGV', then the tag is valid and should be used, as should 'Un-suitable For Motors', although there are a few that I doubt the validity of. A couple of Google examples http://goo.gl/maps/JoD9 and http://goo.gl/maps/LCw9. I love the 2nd, 'Unsuitable For Motors' combined with NSL. Thanks for the examples. I wasn't aware that some real signposts exists for this. So actually we would need two values: * unsuitable: if you are allowed to drive/go there, but you most certainly are not able to * discouraged: if you are able to drive/go there, you are also allowed to, but you should not The value discouraged would be the correct one for Rob's second example (the UK cycle paths). The value unsuitable would fit your example (Unsuitable for motor vehicles). But we have to make sure, that this values are only applied if real indications (e.g. signposts) are present and not e.g. if one just thinks that some vehicle can not drive there. Also for most data consumers (I guess) there wouldn't be any difference between unsuitable and no. The value discouraged might be used for routers to add some penalty to a way. Any more opinions on this? regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] New access tag value needed?
On 01/06/2012 14:19, Jason Cunningham wrote: On 1 June 2012 08:09, Martin Vonwald imagic@gmail.com mailto:imagic@gmail.com wrote: But we have to make sure, that this values are only applied if real indications (e.g. signposts) are present and not e.g. if one just thinks that some vehicle can not drive there. The example given is within the UK. Within the UK signs or signposts haver no 'status' unless they're listed within official documents and linked to legislation. I am confident this unsuitable for HGVs sign has no legislative status. It's existence may be due to local residents asking their local politician to find a way to 'stop' HGV's following satnavs down this road because the noise reduces they're enjoyment of their evening cocktails (Very unlikely, but a possibility). Therefore it's more than possible that an 'unsuitable status sign' may refer to a road that is very suitable. People or business will place signs adjacent to UK roads in rural areas which attempt to alter the actions of drivers, and we should not map these. And if these signs are placed by the highway authority? I think these most definitely do have a place in OSM. It's then up to the data consumers whether they attach any value to them. By making the data available, we are enabling e.g. HGV routing programs to take these hints into account. Without these hints, trucks may be directed down unsuitable routes. The political process leading to their erection is not important - only their existence. Political pressure has a large influence on speed limits as well. In this instance the 'unsuitability' should be derived by OSM end users though other tags, such as 'width' 'lanes' 'surface' 'children_play_here' 'local_resident_doesnt_like_big_HGVs'? All the above does not mean that I believe 'unsuitable' tag has no place within OSM. Jason ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Golf courses: clubhouse and course entrance?
I'd like to get some input about tagging golf courses as navigation targets.
I found a detailed page describing the tagging for the actual sporting
areas (tees, greens etc) but no clear pointers about how to tag things
to get you to the course in the first place. The club house building is
often in the middle of nowhere and often not near the centroid of the
course. So to get a POI usable for navigation, we should have some way
of indicating the clubhouse (and the associated parking areas) and/or
the entrance (road).
The clubhouse could be a {leisure=sports_centre,sport=golf} but calling
it a sports centre might be stretching the imagination a bit. Maybe
{club=sport,sport=golf}?
Assuming the public entrance road crosses the boundary of the course
area at some point, a shared node with entrance=yes might be useful for
navigation.
Does anyone have any suggestions how these can best be tagged?
Colin
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
