Re: [Tagging] Proposal: Rename wiki status Approved to Published
Don't mistake voting with documenting. And btw: neither the one nor the other prevents any mapper of misusing any tag. 2015-04-07 13:30 GMT+02:00 Martin Koppenhoefer dieterdre...@gmail.com: 2015-04-07 13:00 GMT+02:00 Martin Vonwald imagic@gmail.com: Especially there should be no vote before the tag is used on a wide base and proves itself! If different mappers use the same tag for different purposes we got a real problem, because you won't be able to tell what a tag on a given object is meant to say. voting somehow confirms a given definition and makes it possible to more or less rely on that definition, while pure usage numbers don't work to show acceptance for a certain tag, because it could mean different things. Cheers, Martin ___ 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] Proposal: Rename wiki status Approved to Published
In my opinion changing the word doesn't get rid of the problem. Especially if the word - no matter if it is published, approved, whatever - is the result of another glorious vote. There should be no vote at the end of any discussion, because the discussion never ends! Especially there should be no vote before the tag is used on a wide base and proves itself! (A very, very bad habit that established itself on this mailing list in the previous months.) Instead of any status we should show to the wiki reader how wide the acceptance and support of a given feature is. There should be a list of supporting mappers, supporting applications and - if possible - a number from taginfo. On each wiki page we should only show the number of supporting mappers and applications (including a link to the respective lists where) and the usage from taginfo. Every new tag/feature should be a proposal for at least a year (yes, I mean a year and not a week, day or hour). If after a year the tag/feature is used(!) by the community, it will be moved outside the proposal namespace. The determination of used by the community of course will be highly subjective and we can not define rules for this, because the usage strongly depends on the feature itself, e.g. camp-site features will have different usage numbers than traffic signs. But the number of supporters will provide some objective to the wiki readers. Finally - some of you may ask now: what about the rejecters, disapprovers, vetoers? Easy! They should find a better solution than the proposed one, document it, use it, support it. Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal: Rename wiki status Approved to Published
Here again comes the spirit of approved, i.e. voted-on tags :-( If one wants to avoid conflicts, one will always use different tags than tags that are already in use. A proposal should be the documentation of new tags that are actually used(!). A proposal should not be a drawing board idea that will only be used after some vote, just to find out five minutes later that it can't handle some common cases. 2015-04-07 13:40 GMT+02:00 Martin Koppenhoefer dieterdre...@gmail.com: 2015-04-07 13:33 GMT+02:00 Martin Vonwald imagic@gmail.com: Don't mistake voting with documenting. And btw: neither the one nor the other prevents any mapper of misusing any tag. the difference is that someone who has a different idea of the definition of a proposal in draft or proposed status could think that the definition will change in the direction he promotes, while for a feature that has been successfully voted on he would more likely choose a different tag to avoid conflict. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal: Rename wiki status Approved to Published
2015-04-07 14:07 GMT+02:00 Martin Koppenhoefer dieterdre...@gmail.com: 2015-04-07 13:50 GMT+02:00 Martin Vonwald imagic@gmail.com: If one wants to avoid conflicts, one will always use different tags than tags that are already in use. +-0, typically mappers want to use the same tags that other users also use to make usage of the map data easier (i.e. they want their stuff rendered, etc.). Of course everyone could invent new tags for everything everytime they map, and conflicts could be very much avoided (especially with a common tagging scheme and namespaces, e.g. martin_koppenhoefer:highway=motorway, martin_vonwald:highway=motorway, etc.). Not what you wanted to say? Can you expand in which cases one should use a different tag than those already in use? I was refering to different idea of the defintion. If someone has a different idea about what a tag should mean, one will either * be ignorant and use the tag in a (completely) different way * be cooperative and use a different tag. The type of documentation will not influence this behaviour. A proposal should be the documentation of new tags that are actually used(!). proposals sometimes also extend or restrict the usage of tags that aren't new. But the extended usage is new. How do we resolve cases of different people using the same tag for different things? How do we discover these cases? Exactly in the same way as we do it now. Nothing changes. We only use a different name for our documentation and its state. And we do not tell people that this is good, because three-and-a-half people made some green ticks somewhere, and this is bad, because my brother and his son hate this tag personally and therefore made some red ticks somewhere else. When should you write a proposal for a new tag (i.e. how much use should a tag have before you can document it?). I would write a short documentation right at the beginning and expand/adjust it continuously while increasing the discussion and usage of the tag. Actually that's the way I wrote all my proposals up to now and will continue to do it that way. Unless - of course - someone comes up with a better idea of introducing new tags. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] For your comment: New template: Unit summary
2015-04-03 10:01 GMT+02:00 Lukas Sommer sommer...@gmail.com: I think this template should be deleted or be changed to reflect exactly what Map_Features/Units says. (But probably even a direct link to Map_Features/Units would be easier and clearer – so I don’t see any need for this template.) +1 for the deletion (or at least move it to the proposal namespace). A simply direct link to Map_Features/Units should be enough. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] For your comment: New template: Unit summary
This contradicts in many cases our current page
http://wiki.openstreetmap.org/wiki/Map_Features/Units
* The use of meters is discouraged
* cm should not be used generally, maybe only on some specific tags
* There should always be a space in front of the unit
* Neither feet nor inches should be used, use feet'inch instead
* It is not discouraged to not include the default unit
regards,
Martin
2015-04-03 7:21 GMT+02:00 Bryce Nesbitt bry...@obviously.com:
To try and make unit description consistent here is a proposed template.
This would apply to tags like ele, est_width, circumference, height,
width, maxwidth, minwidth, distance. A separate table could be made for
speed weight.
Use as follows:
{{Unit_Tagging_Length|tag_name|furlongs}}
The template is defined at:
http://wiki.openstreetmap.org/wiki/Template:Unit_Tagging_Length
Other unit pages include:
http://wiki.openstreetmap.org/wiki/Category:Units
--
This particular summary promotes the notion of human centred tagging,
with parsers left to make conversion to computer readable units. It also
promotes explicit numbers (e.g. 20 m) over implicit ones ( e.g. 20 ).
Given the variety of unit styles already in the database, this seems to be
the most pragmatic approach.
___
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] For your comment: New template: Unit summary
2015-04-03 9:39 GMT+02:00 Bryce Nesbitt bry...@obviously.com: It's not a contradiction, it's a proposal. Then you should label it accordingly. Currently it is nowhere identified as proposal. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wiki page Vehicle types
I labelled the page now for deletion. Thanks for your comments. br, Martin 2015-03-31 15:26 GMT+02:00 Volker Schmidt vosc...@gmail.com: +1 for deleting On 31 March 2015 at 10:19, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2015-03-31 9:40 GMT+02:00 Marc Gemis marc.ge...@gmail.com: +1 on deleting it +1, seems the access page is documenting better what we do use. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Wiki page Vehicle types
Hi! I just stumbled upon this page: https://wiki.openstreetmap.org/wiki/Vehicle_types What is this page? A proposal or a should it be a complete list of vehicle types? Anyone ever heard about the tag automobile? Or animal_drawn? In my opinion this page should either be updated or - better - deleted. Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Increasing voting participation (Was Accepted or rejected?)
2015-03-18 8:21 GMT+01:00 Frederik Ramm frede...@remote.org: The following 35 people think that this proposal is a good idea and would recommend using it rather than This proposal has been accepted +1 (thousand) I already decided some time ago, that I will not put any of my proposal up for voting any more, but instead allow mappers to add themselves to a list of supporters. This feels much more osm-ish to me. If you like a proposal, use it. If you don't like it, don't use it - and preferable come up with something better. br, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Increasing voting participation (Was Accepted or rejected?)
2015-03-18 12:47 GMT+01:00 Markus Lindholm markus.lindh...@gmail.com: A thought, how difficult would it be to include in the wiki-page how many different mappers have actually used a specific tag. Perhaps via TagInfo. This in fact would be a very helpful information! Although - please everyone correct me if I'm wrong - the numbers from taginfo are not what we want: as far as I know, taginfo shows the number of mappers, that added or changed(!) an object with a given tag. Much more meaningful would be the number of mappers, that actually added a specific tag. This is much harder to determine and even this number would be biased, because of way-splits. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Separating usage docs from design docs (was: Increasing voting participation)
2015-03-18 14:14 GMT+01:00 moltonel 3x Combo molto...@gmail.com: On 18/03/2015, Frederik Ramm frede...@remote.org wrote: So please, don't go over board here by trying to force-involve every mapper in tag votes; they're simply not important enough, and they *should not be*. Don't try to make them important, lasting, or binding. +1 to all that. While I think that voting is very usefull, I think the whole concept of accepting a proposal (all the related arguments about voter thresholds) should be scraped entirely. Instead, how about revisiting the purpose of proposals pages vs key/tag pages : * key/tag pages would document the actual use (mainly observed via taginfo) * proposal pages would document a desired use (and include the current list of supporters/opponents) * ideally both pages would reference each other (many to many), maybe using a used/encouraged/discouraged by link template * key/tag pages could be kept up to date fairly objectively * proposal voters should put the page on their watchlist, in case a change in the proposal changes their opinion * proposals should only be end-of-lifed if there is near-unanimous opposition and near-zero actual usage This should clarify the old question of whether the wiki does/should document usage or intent. It'll allow competing proposals to coexist more visibly. It keeps the interesting opinion poll use of voting, while removing the obnoxious proposal is ready ! vote now so that we can start using it ! calls. Very good ideas and it would bring the original intention of OSM back into the play: the numbers count and not the two-and-a-half people putting a line starting with yes somewhere in the wiki. Full support for this at least from my side. br, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Current status of the key smoothness=*
Hi! 2015-03-13 2:06 GMT+01:00 David dban...@internode.on.net: No, numeric values are not a good choice - really not. I also don't like the values much, but at least it's clear that good is better than bad. But Martin, its not a good or bad situation, thats the point. Some people seek out extremely challenging roads to traverse. While dead smooth is good while getting there, why bother to go there if its going to be smooth all the way ? That's not what I meant. If someone has no idea about the meaning of the values and just look at the existing tags, one may guess correctly, that good means smoother than bad. But what is smoother? grade1 or grade5? And please do not claim that everyone will look in the wiki what the values actually mean. Please stay realistic ;-) And to answer the next argument: but if people don't know the exact meaning and also don't look in the wiki, we can not be sure that they use the values correctly. Yes. We can also not be sure that they use the values correctly IF the look in the wiki. But the chances that we get more appropriate values is much higher with smoothness=good than with smoothness=grade97, because a good smoothness will have a much wider common understanding than smoothness=31415whatever. Best regards, Martin P.S: I'm aware that we will not reach consensus about this on this mailing list ;-) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Current status of the key smoothness=*
2015-03-11 13:53 GMT+01:00 Pieren pier...@gmail.com: I search an adjective about this tag and I hesitate between very_bad and horrible ;-) In my opinion this tag is pretty bad. Btw, what's different today about its verifiability ? I think most of the people rejecting this tag simply ignore the discussions around it. Which is another problem: ignorance never leads to a solution. Especially if those people don't come up with any other - practical and feasible - suggestion. And this brings us back to the tag smoothness. It is completely subjective if the tag is good or bad, excellent or horrible. But it is 100% objective that this is the best tag, simply because it is the only one (please remember: practical and feasible). So I support the removal of the section Controversy. Maybe add some note about the limited verifiability. Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Current status of the key smoothness=*
2015-03-12 10:36 GMT+01:00 Martin Koppenhoefer dieterdre...@gmail.com: I believe that the main problem are the value names. If these were called grade1 to grade8 many more people would likely use these values and I guess there would be much fewer objections. Is grade1 now excellent or horrible? No, numeric values are not a good choice - really not. I also don't like the values much, but at least it's clear that good is better than bad. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] domestic fuel transport delivery мазут
2015-03-09 12:28 GMT+01:00 Martin Koppenhoefer dieterdre...@gmail.com: 2015-03-09 11:50 GMT+01:00 Martin Vonwald imagic@gmail.com: The description of the key service also ... I meant the key office and not service, sorry for that. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] domestic fuel transport delivery мазут
2015-03-09 10:45 GMT+01:00 Martin Koppenhoefer dieterdre...@gmail.com: what about shop=fuel_delivery? To me shop means a place where I can buy things. If I'm looking for a service, I would go to an office. The description of the key service also starts with A place predominantly selling services.. Sounds good to me. How about office=fuel_delivery? br, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Draft Proposed Relationship Area Steps
2015-03-05 8:00 GMT+01:00 Warin 61sundow...@gmail.com: On 5/03/2015 5:48 PM, Mateusz Konieczny wrote: For areas area:highway should be used, not highway. http://wiki.openstreetmap.org/wiki/Proposed_features/area:highway Proposed ... 2011. And this is a problem because...? P.S. No, I dont support highways as areas. I just question your attitude. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Breakdown bays?
Hi! 2015-02-27 16:22 GMT+01:00 fly lowfligh...@googlemail.com: Did sleep one night and now think we should include bays and lanes within the lanes:-Tagging lanes=3 lanes:forward=2 lanes:backward=1 access:lanes:forward=yes|yes|emergency access:lanes:backward=yes|emergency To me it just does not feel right. I don't see a lane there... All together I am not happy with the description of lanes=* and lanes:*=* anymore. Where is it useful as we already do not count bicycle lanes but do count exclusive bus or taxi lanes and even ones with access forbidden but wide enough for motorized vehicles. The key lanes and its subkeys are a misconception par excellence, no doubt there. Would prefer to change lanes=* and lanes:*=* to be the numbers with general access allowed and adding all additional lanes with access:lanes: I'm all in! Changing the meaning of a key that's used about 5 million times might get a little tricky though. lanes=2 lanes:forward=1 lanes:backward=1 I wouldn't use lanes=2 in this example. 1+1=2 access:lanes:forward=yes|no|no access:lanes:backward=yes|no bicycle:lanes:forward=yes|designated|no bicycle:lanes:backward=yes|yes bus:lanes:forward=yes|no|designated bus:lanes:backward=yes|designated taxi:lanes:backward=yes|yes That's an excellent example why the current access scheme sucks for this. traffic_designation:lanes:forward=none|bicycle|bus traffic_designation:lanes:backward=none|bicycle;taxi Wouldn't that be A LOT easier? Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Breakdown bays?
2015-02-25 19:56 GMT+01:00 Ole Nielsen on-...@xs4all.nl: On 25/02/2015 16:41, Martin Vonwald wrote: I don't think of them as lanes, so I wouldn't use some :lanes-tag. I thought that there is already a tag, that I simply put on the road for the length of the bay - just like e.g. sidewalk=right. But that's obviously not the case and it is not possible with highway=emergency_bay. When tagged as node I lose the length. Tagging as separate way seem counter-intuitive - there is no separate road. Tagging as area seems... strange ;-) Well, we already have the approved feature http://wiki.openstreetmap.org/ wiki/Tag:highway%3Dpassing_place for features of a very similar physical nature but for a different purpose. The consistent solution is to use highway=emergency_bay on nodes in the same way as for passing places. Consistent, but missing details. And why do you want that kind of details? If it is tagged as emergency_bay you know it is big enough for a broken down vehicle. That is the only information you really need if you are having car problems. We do not tag for broken cars ;-) And adding an attribute to a short section of highway just results in further (in my opinion unnecessary) fragmentation of highways. There are many different opinions on that matter. If an attribute of the road changes, I split. If you really want to add the length you could use maxlength=* for the maximum vehicle length fitting in the bay. Why measure the length and add a tag instead of simply putting a tag along the bay on the road? That seems a little bit too complicated to me. That would also be easier for data consumers to process. Are you speaking for all data consumers? Yesterdays solutions might not work tomorrow. Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Breakdown bays?
2015-02-25 16:52 GMT+01:00 fly lowfligh...@googlemail.com: Well, emergency=bay might interfere with access tagging and we should probably use left/right as you will find them not only on dual carriage roads. emergency_bay=both/left/right ? That seems reasonable to me. How do we tag emergency lanes ? I asked that some time ago, but afaik there's no solution (yet). ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Breakdown bays?
Hi! I obviously forgot how to tag breakdown bays (lay-bys, german: Pannenbucht), something like this: http://binged.it/1LCYpoM Couldn't find anything in the wiki or taginfo. Any tips? Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Breakdown bays?
2015-02-25 16:34 GMT+01:00 fly lowfligh...@googlemail.com: So what do you have in mind ? Tagging them as additional tag on the way with highway=*? Using lanes:-Tagging ? I don't think of them as lanes, so I wouldn't use some :lanes-tag. I thought that there is already a tag, that I simply put on the road for the length of the bay - just like e.g. sidewalk=right. But that's obviously not the case and it is not possible with highway=emergency_bay. When tagged as node I lose the length. Tagging as separate way seem counter-intuitive - there is no separate road. Tagging as area seems... strange ;-) Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Breakdown bays?
Hm...had a quick look how they are tagged and I'm not really convinced. They are tagged as area beside the road (without any connection) or as individual roads. In my opinion both does not fit well :-/ Thanks anyway, Martin 2015-02-25 16:11 GMT+01:00 Volker Schmidt vosc...@gmail.com: http://wiki.openstreetmap.org/wiki/Proposed_features/emergency_bay On 25 February 2015 at 15:33, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2015-02-25 15:20 GMT+01:00 Martin Vonwald imagic@gmail.com: I obviously forgot how to tag breakdown bays (lay-bys, german: Pannenbucht), something like this: http://binged.it/1LCYpoM Couldn't find anything in the wiki or taginfo. could be something for the emergency key? Or highway. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ 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] Wiki edits on junction=roundabout
I asked the user for an explanation and revert: https://wiki.openstreetmap.org/wiki/User_talk:Pmailkeey003 If he doesn't react within a reasonable time, we should revert it anyway. Opinions? Best regards, Martin 2015-02-23 10:37 GMT+01:00 Philip Barnes p...@trigpoint.me.uk: I would also question the make it circular, roundabouts don't have to be circular. Phil (trigpoint ) On Mon Feb 23 07:43:36 2015 GMT, Martin Vonwald wrote: Hi! Can someone please explain these edits to me: https://wiki.openstreetmap.org/w/index.php?title=Tag%3Ajunction%3Droundaboutdiff=1142769oldid=1107975 A little overkill - isn't it? And since when is area=no needed? Best regards, Martin -- Sent from my Jolla ___ 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] Wiki edits on junction=roundabout
As there haven't been any objections against a revert, I reverted the article now to the previous state [1] and again informed the user [2]. Hopefully he let us know what he think is unclear or missing. Best regards, Martin [1] https://wiki.openstreetmap.org/w/index.php?title=Tag%3Ajunction%3Droundaboutdiff=1143455oldid=1142769 [2] https://wiki.openstreetmap.org/wiki/User_talk:Pmailkeey003 2015-02-23 15:26 GMT+01:00 Volker Schmidt vosc...@gmail.com: On 23 February 2015 at 11:02, Martin Vonwald imagic@gmail.com wrote: I asked the user for an explanation and revert: https://wiki.openstreetmap.org/wiki/User_talk:Pmailkeey003 If he doesn't react within a reasonable time, we should revert it anyway. Opinions? I fully agree. Volker ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Wiki edits on junction=roundabout
Hi! Can someone please explain these edits to me: https://wiki.openstreetmap.org/w/index.php?title=Tag%3Ajunction%3Droundaboutdiff=1142769oldid=1107975 A little overkill - isn't it? And since when is area=no needed? Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] maxwidth vs. maxwidth:physical vs. width
Hi! 2015-02-16 10:58 GMT+01:00 Martin Koppenhoefer dieterdre...@gmail.com: * maxwidth:physical: according to the wiki page: a physical limit IIRR there were users of latin american countries telling that their bridges sometimes had 2 height informations signposted: maxheight and maxheight:physical and that this was the reason for the introduction of maxheight:physical (I assume that maxwidth is working just the same). The width of a feature in my understanding is a physical limit. -1, the width is one dimension of a feature (depending on the kind of thing you are describing, there are other dimensions like height, length, diameter, depth, etc.), I wouldn't call this (in all cases) a limit Ok. But that didn't really answer my question. When should maxwidth:physical be used? Does this have to be signposted? Measured? What exactly does it describe? When should one use it and when should width or maxwidth be used? So when should maxwidth:physical be used? One example I can think of might be a way with varying width, i.e. it is not possible to specify width and maxwidth:physical should be used to specify the minimum width along the way. Another one might be the maximum width of a vehicle, that may pass a barrier (this is indicated in the first sentence of the article). if there was something tagged like (example made up): barrier=bollard width=0.2m maxwidth=1.2m What about maxwidth:physical in this example? Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] maxwidth vs. maxwidth:physical vs. width
Hi! I just stumbled upon the wiki article regarding maxwidth:physical. From reading it - and the articles about maxwidth and width - I don't really understand when to use each key. My understanding so far: * width: this is the actual width of a feature * maxwidth: this is a legal limitation; nothing wider than the given value may use the feature * maxwidth:physical: according to the wiki page: a physical limit The width of a feature in my understanding is a physical limit. So when should maxwidth:physical be used? One example I can think of might be a way with varying width, i.e. it is not possible to specify width and maxwidth:physical should be used to specify the minimum width along the way. Another one might be the maximum width of a vehicle, that may pass a barrier (this is indicated in the first sentence of the article). Is this the intention of maxwidth:physical? Some additional examples and a section When to use might be helpful. best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] maxwidth vs. maxwidth:physical vs. width
Hi! 2015-02-16 11:16 GMT+01:00 Kytömaa Lauri lauri.kyto...@aalto.fi: The width of the vehicle that could use the way can be wider than the way itself, even if it depends on the conditions whether they're allowed to. For an example, a way in a park might be, say, 2 meters wide, but if there's just grass around it, a maintenance or construction vehicle or what ever could use that way even if all wheels don't fit on the intended surface (supposing the soil isn't too soft). Or a cycleway; the asphalt is 2.5 meters (width), but if there's no guard rail, a police van can use it even if they're wider than that (with mirrors included) - but if there's a guard rail on one side and a hedge on the other side, the physical maximum width could be just 2.6 meters (numbers off the top of my head.) Another likely case is when the width of a gate is, say, 3 meters (the whole structure), but the gap between the sides is only 2 meters: width=3 + maxwidth:physical=2 Less likely cases could be a road with trees next to it, such that the road is 6 meters wide, but for a section the branches limit the physical width usable for vehicles to, for example, 4 meters. Or a divider on the pedestrian crossing limits the physical width of passing vehicles to x meters, yet the road is more than 2*x wide. I haven't looked up if the maximum legal width sign refers to the actual width (with mirrors etc) or to the width stated in the vehicle's registration documents. Nevertheless, a road with a width of 2.6 meters (e.g. a narrow old town alley or a courtyard entrance) may, or may not, physically allow a vehicle with a width of 2.55 m + mirrors to pass. Thanks for all the examples. It's true that good example photos would be a nice touch to the documentation. That was the original intention of my question ;-) Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] maxwidth vs. maxwidth:physical vs. width
2015-02-16 11:18 GMT+01:00 Janko Mihelić jan...@gmail.com: Maybe If you read a documentation and afterwards you maybe know what it means, the documentation might need some kind of improvement. ;-) I think we got enough good examples in this thread. Anyone willing to update the wiki? Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tram tracks running in a road
Just one quick question: are there any tags describing the track bed and ties? 2015-02-07 11:19 GMT+01:00 Martin Vonwald imagic@gmail.com: 2015-02-07 0:31 GMT+01:00 Janko Mihelić jan...@gmail.com: I think this is the best way to tag this. There's a great map paint style for seeing roads in towns in JOSM, and it helps a lot with tagging lanes. It's called Lanes and road attributes. Unfortunately, it doesn't show trams, but if we start tagging them, it will probably start rendering them. Let me know if there's a place with a lot of such tags and I try to update the style. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tram tracks running in a road
2015-02-08 17:48 GMT+01:00 fly lowfligh...@googlemail.com: Let me know if there's a place with a lot of such tags and I try to update the style. (Please contact me directly via martin (the usual) vonwald (dot.) info for this) +1 Keep your +1 until I tried AND succeeded ;-) And yes: some consistent tagging scheme would be fine. Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tram tracks running in a road
2015-02-07 0:31 GMT+01:00 Janko Mihelić jan...@gmail.com: 2015-02-06 17:29 GMT+01:00 Luca Sigfrido Percich luca.perc...@gmail.com: We could also user a lanes modifier: lanes=3 lanes:backward=2 tram:lanes:backward=yes|no tram:forward=yes I think this is the best way to tag this. There's a great map paint style for seeing roads in towns in JOSM, and it helps a lot with tagging lanes. It's called Lanes and road attributes. Unfortunately, it doesn't show trams, but if we start tagging them, it will probably start rendering them. Let me know if there's a place with a lot of such tags and I try to update the style. (Please contact me directly via martin (the usual) vonwald (dot.) info for this) Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Whole planet flooded at main map?
Hi! Is it just me or is currently the whole planet flooded on the main map? At least at zoom level 1-6. Starting with 7 countries reappear. regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Access restrictions for shoulder lanes?
Hi! 2015-02-02 18:06 GMT+01:00 Paul Johnson ba...@ursamundi.org: On Feb 2, 2015 8:47 AM, Martin Vonwald imagic@gmail.com wrote: Yes - and what tag would that be for emergency stopping only? I think that is my main question. Do we have one for that? parking:lane=emergency seems like a good value. But those lanes are neither parking lanes nor is parking:lane=emergency an access value nor can we use it to solve the problem, when those lanes may be used by other vehicles like motorcycles at any time. 2015-02-02 18:53 GMT+01:00 Heiko Eckenreiter heiko.eckenrei...@gmx.net: Am 02.02.2015 um 16:31 schrieb Martin Vonwald: Still the question is unanswered: if, for example, one lane is a emergency/shoulder lane during night and a regular lane during day, how may we map this? access:lanes=yes|yes|now_it_is_a_shoulder @ night access:lanes=yes|yes|yes @ day On the german motorway A 8 southeast of Munich I have seen (and continued): access:lanes=yes|yes|yes|peak_traffic which seems to be a similar concept. This seems to be an intended replacement for access= @ condition, because peak_traffic is no known access value. It also can not be used for lanes, which may only be used for break-downs (at some times). Furthermore we can not use it for lanes which might be used regularly by other road user. I guess we don't have a solution for this at the moment. I would suggest to document a new access value for those, e.g. breakdown. Or would malfunction be better suited? Any other suggestions? We then could tag those lanes, e.g.: * vehicle:lanes=|breakdown @ night + vehicle:lanes=|yes @ day * vehicle:lanes=|breakdown + motorcycle:lanes=|yes Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Access restrictions for shoulder lanes?
2015-02-03 12:18 GMT+01:00 Colin Smale colin.sm...@xs4all.nl: That's an easy one: shoulder=yes. Can you please explain to me, how this answers the question WHERE the shoulder is? It does NOT have to be the leftmost or rightmost lane. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Access restrictions for shoulder lanes?
Yesterday I had the following case on a dual carriageway - lanes from left to right: * two regular lanes * one shoulder * one bicycle lane Sometimes the shoulder changes to a turning lane and back to a shoulder after a junction. There is no physical separation whatsoever of all those four lanes. Additional bicycle lanes may also be present. Regards, Martin 2015-02-03 12:33 GMT+01:00 Paul Johnson ba...@ursamundi.org: Unless I'm way off, maybe a gore point? Transition into a traditional toll plaza? On Feb 3, 2015 5:30 AM, Colin Smale colin.sm...@xs4all.nl wrote: A shoulder lane in the middle of the carriageway? Maybe you can illustrate your scenario. Under normal circumstances (one way per carriageway) shoulder=left/right/both should cover it. Or am I misunderstanding what you mean by shoulder? On 2015-02-03 12:23, Martin Vonwald wrote: 2015-02-03 12:18 GMT+01:00 Colin Smale colin.sm...@xs4all.nl: That's an easy one: shoulder=yes. Can you please explain to me, how this answers the question WHERE the shoulder is? It does NOT have to be the leftmost or rightmost lane. ___ Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ 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] Access restrictions for shoulder lanes?
Hi! 2015-02-03 11:54 GMT+01:00 Richard Welty rwe...@averillpark.net: On 2/3/15 4:36 AM, Colin Smale wrote: Then they are access=no (with foot=yes or whatever as appropriate) or barrier=boulder. The way is blocked both for emergency services and mere mortals. No need for access=emergency. then how do you create a routing engine for use by emergency vehicles? think it through, please, think it through. +1 Although I wouldn't even think that far. I just want to know which lane is the shoulder. The tag access=no doesn't tell me anything about that. Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Access restrictions for shoulder lanes?
Fine. But how do you specify where this lane is or if there is a lane at all? 2015-02-03 10:05 GMT+01:00 Colin Smale colin.sm...@xs4all.nl: Surely there is never a law against breaking down. When your car dies, it dies. If the intention is to persuade people to try to get their dying vehicle as far as possible to the right (left in the UK), well, we don't need to tag for that because it is standard. If the intention is to go against the defaults under some circumstances, Same thing really with emergency vehicles. There is no such thing as emergency=no - the police/ambulance etc will go wherever they need to if it is a real emergency. Therefore there cannot be any such thing as emergency=yes, and hence access=emergency is effectively the same as access=no. Discuss ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Access restrictions for shoulder lanes?
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
[Tagging] Looking for photos of italian motorways
Hi! I'm looking for photos of italian motorways, especially south Italy, e.g. between Napoli and Reggio Calabria, but also for north Italy. I couldn't find any on the usually suspects (Mapillary, autobahn-bilder). If you have some photos available, please let me know. If you plan any journeys there, please think of Mapillary or similar ;-) Thanks! Best regards, Martin P.S: Would be nice if someone with access to the italian mailing list might forward this. Thanks! ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Access restrictions for shoulder lanes?
Still the question is unanswered: if, for example, one lane is a emergency/shoulder lane during night and a regular lane during day, how may we map this? access:lanes=yes|yes|now_it_is_a_shoulder @ night access:lanes=yes|yes|yes @ day So what should we use for now_it_is_a_shoulder? Any what about lanes, which are free for motorcycles, but may only be used by cars in case of break-downs. I think something similar to this is valid in spain. best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Access restrictions for shoulder lanes?
2015-02-02 15:41 GMT+01:00 Paul Johnson ba...@ursamundi.org: Typical restrictions in the US would be emergency stopping only Yes - and what tag would that be for emergency stopping only? I think that is my main question. Do we have one for that? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Access restrictions for shoulder lanes?
I agree that access=no (or vehicle=no) leads in the right direction, but we are still missing the information that it might be accessed in case of break downs or similar. No? Or don't we care about that? 2015-02-02 15:07 GMT+01:00 Colin Smale colin.sm...@xs4all.nl: 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). ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] JOSM 7995 (January 2015) released
Spreading the word. Thanks to the devs. -- Forwarded message -- From: Dirk Stöcker openstreet...@dstoecker.de Date: 2015-02-01 13:40 GMT+01:00 Subject: [josm-dev] JOSM 7995 (January 2015) released To: josm-...@openstreetmap.org Hello, the new JOSM tested version for last month is out. Feel free to spread the word :-) Ciao ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] length=
2015-01-28 8:58 GMT+01:00 Florian Lohoff f...@zz.de: On Tue, Jan 27, 2015 at 04:18:57PM +0100, Martin Vonwald wrote: 2015-01-27 16:13 GMT+01:00 François Lacombe fl.infosrese...@gmail.com: I personally recommend to use the length key while mapping street cabinets as nodes. http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dstreet_cabinet On a node it makes perfect sense. At least as long as it is not possible/wanted/allowed to provide the geometry. Does it ? I cant think of any application where this makes sense. A node does not have an orientation so why can it have a length? If it has a length it does not make sense to use a node. Read my second sentence again. Some mappers do not want to draw geometry for some small feature. See e.g. man_made=street_cabinet. There you have a length and width. Together with the key direction one can determine the geometry. I don't see why anyone would want to do it that way instead of simply drawing a box, but I accept the fact, that some users do, so it's fine for me. Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] length=
2015-01-27 16:13 GMT+01:00 François Lacombe fl.infosrese...@gmail.com: I personally recommend to use the length key while mapping street cabinets as nodes. http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dstreet_cabinet On a node it makes perfect sense. At least as long as it is not possible/wanted/allowed to provide the geometry. But on a way? Hm... Any real-world examples for me? Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists
Who has admin power in the Wiki? I again request a ban of this user. Martin 2015-01-27 11:31 GMT+01:00 jgpacker john.pack...@gmail.com: Not five minutes later, he already reverted my changes, justifying it as a single user opinion and undiscussed changed. I also fixed some of his additions in other pages, but he is already reverting them. It seems he is trying to win the discussion by Fait accompli https://en.wikipedia.org/wiki/Wikipedia:Fait_accompli . ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] length=
2015-01-27 16:26 GMT+01:00 François Lacombe fl.infosrese...@gmail.com: In my mind, a road climbing a mountain won't have the same length in reality than in the DB : the Z dimension may have influence too. Ok - understood. Although I doubt, that there is real usage for that example. But I had a quick look in overpass: besides aeroways it is quite often used on bridges and tunnels, where the actual (official) length can be observed. Makes sense. Thanks, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists
2015-01-24 17:20 GMT+01:00 Никита acr...@gmail.com: Are you an idiot? I mean really. I hereby request a ban of this individual from this mailing list and I definitively support an OSM-wide ban. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists
2015-01-24 14:29 GMT+01:00 Никита acr...@gmail.com: Clueless people Once again I want to thank you for your kind words. The end. Any chance, that you will follow this rule anytime soon? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Motorroad does not apply to all lanes
2015-01-21 18:08 GMT+01:00 715371 osmu715...@gmx.de: Here is a picture of the situation. https://wiki.openstreetmap.org/wiki/File:Special_motorroad_situation.jpg Interesting... and confusing ;-) Is there any motorroad signpost before that part of the road? When looking at the photo I'm tempted to say that the left lane is a motorroad and the right one isn't, although I doubt that I would be brave enough to tag it that way. Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Overhead signs (Überkopfwegweiser)
Hi! 2015-01-16 10:19 GMT+01:00 Andreas Labres l...@lab.at: heading Brno: +---+ | Brno,... [A23]| |^^ ^ / | ||| |// | +---+ It might be quite hard for the consumer to determine what arrow/name refers to what lane. 2015-01-19 22:14 GMT+01:00 Johan C osm...@gmail.com: I prefer the existing destination:lanes and turn:lanes tagging, which already provides enough data for a lane assistant (and which is already a bit difficult for novice mappers). http://wiki.openstreetmap.org/wiki/Proposed_features/Destination_details Correct. The consumer may get the names from destination:lanes (and additional information from its sub-tags) and the arrows from turn:lanes. 2015-01-19 22:14 GMT+01:00 Johan C osm...@gmail.com: It might be useful to have a node at the location of the signpost referring to a Mapillary photo. This sounds like a good idea. Maybe we should add a node at the exact position of the signpost and add lane-independent information to that node, like e.g. a photo link, support, colour, maybe dimensions like height. And as some consumers insist on an absolutely realistic representation, we might even add a link to an external vector graphic (e.g. svg). But at least the last one might be a little bit too much at the moment, so let us start with simple photo links. 2015-01-18 18:28 GMT+01:00 fly lowfligh...@googlemail.com: Do we have traffic_sign=destination_sign or highway=destination_sign or similar tag as main tag for the node. Is gauntry that important, that we need an own main tag or would it better fit as subtag ? Eventually even support=* alone will work. As a non-native speaker I obviously prefer traffic_sign=destination_sign, because I never heard of gauntry before. But that's just me. I think traffic_sign=destination_sign + support=gauntry would be a good compromise. Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Motorroad does not apply to all lanes
2015-01-20 9:06 GMT+01:00 Volker Schmidt vosc...@gmail.com: So the correct mapping is that yo remove put motorroad=no on the short stretch on the bridge. yo remove put - you put ;-) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Motorroad does not apply to all lanes
2015-01-20 14:56 GMT+01:00 Martin Koppenhoefer dieterdre...@gmail.com: Am 20.01.2015 um 08:44 schrieb Martin Vonwald imagic@gmail.com: 2015-01-20 3:36 GMT+01:00 715371 osmu715...@gmx.de: motorroad:lanes=yes|yes|yes|no Seems absolutely fine to me. One alternative (for better compatibility) would be motorroad=yes + motorroad:lanes=yes|yes|yes|no this sounds strange to me, a motor road according to German law (and word) is referring to a road, not to a lane, so there shouldn't be roads with lanes of which some are motor roads and others aren't, it is more probable that the whole motor road gets interrupted by the bridge (to allow crossing by all vehicles) and restarts after it. My response was solely to the tagging itself. If the original observation is wrong, that's a completely different story ;-) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Motorroad does not apply to all lanes
Hi! 2015-01-20 3:36 GMT+01:00 715371 osmu715...@gmx.de: motorroad:lanes=yes|yes|yes|no Seems absolutely fine to me. One alternative (for better compatibility) would be motorroad=yes + motorroad:lanes=yes|yes|yes|no . Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists
I support the revert. The edits by Xxzme are in my opinion completely unacceptable. Best regards, Martin 2015-01-19 11:03 GMT+01:00 NopMap ekkeh...@gmx.de: There seems to be an edit war on the wiki page http://wiki.openstreetmap.org/wiki/Avoid_semi-colon_value_separator I personally think that the problem has been discussed many times and it is well understood that semicolon lists only work for some special tags and would generally be discarded as invalid values. Some of the more tricky problems like undefined order are harder to grasp. So making the problem as clear as possible in the wiki has its merits. However, the changes were somewhat extreme - especially the change of the page name would rather be hiding information. And they are not backed up by a link to any discussion. On the other hand, just reverting them does not feel right to me either. Some of the examples have their merit. What do you think? bye, Nop -- View this message in context: http://gis.19327.n5.nabble.com/Wiki-Edit-War-on-using-avoiding-semicolon-lists-tp5830523.html Sent from the Tagging mailing list archive at Nabble.com. ___ 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] Wiki Edit War on using/avoiding semicolon lists
Hi! 2015-01-19 12:34 GMT+01:00 jgpacker john.pack...@gmail.com: I.e. How is this: amenity=library library:stock=books;newspapers;recorded_music better than this?: amenity=library library:stock:books=yes library:stock:newspapers=yes library:stock:recorded_music=yes As a programmer, I find the first alternative to be easier to handle by a data consumer. And while it could be slightly easier for a mapper to visualize the second alternative (and this is debatable), it would take longer to write it down. If I had to guess, I would think that most people find the second alternative much more complicated than the first one. So I definitely disagree with In general avoid ';' separated values whenever possible. (as it's said in the wiki right now). I only agree with avoiding semicolons in main tags or in tags that logically shouldn't have multiple values. Fully agree! Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tag destination vs. relation destination_sign
2015-01-15 22:12 GMT+01:00 fly lowfligh...@googlemail.com: Please, do not forget to mention direction:lanes*. destination:lanes ;-) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tag destination vs. relation destination_sign
2015-01-15 19:48 GMT+01:00 Lukas Sommer sommer...@gmail.com: To clarify the wiki a little bit more, I would also add to the key:destination page a sentence like “Where to use? Use destination=* on the highway (OSM way) after the position of the signpost/groundwriting.” And I would remove (as explained above) the three examples with the yellow/white signposts for being confusing. Thoughts? I think you are right. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bicycle:lanes=designated|... vs cycleway:lanes=lane|...
2015-01-13 13:38 GMT+01:00 Hubert sg.fo...@gmx.de: I would not. IMO bicycle:lanes is an access Tag while cycleway:lanes defines es the type. So one could have cycleway:lanes:forward=none | lane and bicycle:lanes:forwad= yes | designated , for example. That's correct. AFAIK it is common understanding, that some kind of way with access tags bicycle=designated and vehicle=no (or similar) is more or less identical to a cyclelane. My problems with cycleway:lanes=...|lane|none|... are: * The value none is not specified for the key cycleway * The tag cycleway=lane tells use, there is a cyclelane, but it doesn't tell us where. Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bicycle:lanes=designated|... vs cycleway:lanes=lane|...
2015-01-13 13:52 GMT+01:00 Hubert sg.fo...@gmx.de: +1 to all. Except none in this case was meant to be the default value from the :lanes proposal. The default value is always an empty value, e.g. minspeed=|80|50. The value none might be defined by the main key, e.g. maxspeed=none. If the main key does not specify the value none, one should not use this value in any suffixed key. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tag destination vs. relation destination_sign
2015-01-10 19:40 GMT+01:00 Lukas Sommer sommer...@gmail.com: +1. Key:destination for the simple cases the the relation for the complex cases seems fine for me. I'll wait until monday and if up to then nobody complains, I'll update the wiki as mentioned before. bg, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Tag destination vs. relation destination_sign
Hi! Currently it reads in the section When to use on the wiki page of the key destination [1]: Attention: Do not use them for mapping at highway=primary and highway=secondary (or smaller). In such cases, a destination sign relation is the recommended way for direction directives. Also above that sentence a list of road types is given on which that key should be used and only on that road types. May I ask who exactly recommended the use of the relation destination_sign and who decided, that destination may only be used on a few type of roads? I suggest to remove the section When to use and instead add the following sentence (or similar): Instead of they key destination, one might also use the relation destination_sign, which is able to provide detailed information about the type and colour(s) of the road sign. That's the way I always thought about those two tagging schemes: destination is the simple variant and destination_sign the complex. I used both in the past, but only used the key lately. Best regards, Martin [1] https://wiki.openstreetmap.org/wiki/Key:destination#When_to_use P.S: I am aware, that I may simply ignore the wiki, but I don't want to lose any potential information, because someone thinks one must use destination_sign on e.g. highway=primary, but considers it as too complicated. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] hrmpf.
Hi! 2015-01-02 0:34 GMT+01:00 Rainer Fügenstein r...@oudeis.org: FR I think it's a slippery slope problem. Agreed that 13 nodes is not a FR lot. But at how many would you draw the line? 20? 100? 500? all 13 nodes have been checked and edited by me manually (not using search-and-replace). since this case is not covered in the mechanical edit policy, IMHO this policy does not apply. In my opinion this does not qualify as mechanical edit. This was clearly just a fix of an extremely limited number of nodes. Happy New Year, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] lanes=-1 especially in Canada
2014-12-30 22:36 GMT+01:00 Janko Mihelić jan...@gmail.com: 2014-12-30 22:16 GMT+01:00 John F. Eldredge j...@jfeldredge.com: It may well mean what it says, a one-lane road. Some rural areas in the USA still have one-lane roads, with occasional wider spots where one vehicle can pause to allow a vehicle going the other direction to pass by. Given how sparsely-populated some of the northern regions of Canada are, I would not be surprised to find some one-lane roads, and some extensive areas with no roads at all. I think you missed the minus sign. It's minus one lanes. When I read this, some small bell rang at the backside of my brain. If think I remember that a few years ago I read somewhere in the wiki, that lanes=-1 means a very narrow road. I might be completely mistaken and I'm pretty sure that this was already removed from the wiki, but that might be the origin of it. Of course it doesn't make any sense to use lanes=-1 for that; instead simply use width. Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - (Obligatory vs. optional cycletracks)
Here's the link to the proposal: http://wiki.openstreetmap.org/wiki/User:Proposed_features/Obligatory_vs._optional_cycletrack 2014-12-22 6:24 GMT+01:00 Mateusz Konieczny matkoni...@gmail.com: No, no, no. In my opinion, there are a few nos missing here. So I'll add at least one more: no. Well, make that two: No. br, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - (Obligatory vs. optional cycletracks)
2014-12-22 13:58 GMT+01:00 Richard Fairhurst rich...@systemed.net: Martin Vonwald (Imagic) wrote: Mateusz Konieczny wrote: No, no, no. In my opinion, there are a few nos missing here. So I'll add at least one more: no. Well, make that two: No. ...there's no limit... Oh my 1992... I'm getting old ;-) I even got the CD... P.S: For everyone who only knows iTunesCo: CD is something like a physical download. No one uses them today anymore ;-) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - (Obligatory vs., optional cycletracks)
2014-12-22 14:50 GMT+01:00 Warin 61sundow...@gmail.com: I think the only need for 'obligatory cycleway' is to remove bicyclist from certain roads! e.g. I'm bicycling north to south.. there is an obligatory cycleway 1000 kms west of me .. Do I have to use it? No. Totally unreasonable. Or is it only obligatory for the adjacent road? Yes. In which case the road can be tagged bicycle=no ... No. If - for example - you need to turn left on the next crossing and the adjacent cycleway is separated from the main road so that it is not possible to turn left from the cycleway, you are allowed to switch to the main road and drive on it in order to turn left. So bicycle=no is never correct in such situation. Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] maxspeed=signals vs. maxspeed:variable=yes + maxspeed=x
Hi! As the usage of maxspeed:variable continues to increase, I would like to draw your attention again to its proposal: https://wiki.openstreetmap.org/wiki/Proposed_features/Dynamic_maxspeed In my opinion maxspeed:variable is far superior to maxspeed=signals as it provides not only the information that the speed limit is variable, but additionally: * what is the maximum possible(!) speed limit * what is the reason(!) for the variable speed limit I consider both potentially valuable information to data consumers. Example: On motorways in Austria the speed limit is usually 130 km/h. Motorways which cross larger cities however have often variable speed limits and quite often with a maximum speed limit of 80 km/h. That's a long way down from 130 km/h to 80 km/h. If we provide only the information that the limit is variable, what speed limit should a consumer assume? Maybe it would be faster to drive around the city, because there is usually a limit of 130 km/h? I want to suggest to remove the recommendation within the wiki for maxspeed=signals and instead recommend maxspeed:variable=reason + maxspeed=maximum speed limit . Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - amenity=public_bookcase
2014-12-19 13:30 GMT+01:00 Janko Mihelić jan...@gmail.com: This might be the most vague tag I've ever seen. OT - just for a smile: http://taginfo.openstreetmap.org/tags/building=building ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mapping of kids areas
Hi! 2014-12-19 13:17 GMT+01:00 Martin Koppenhoefer dieterdre...@gmail.com: 2014-12-19 13:07 GMT+01:00 Никита acr...@gmail.com: leisure=playground (usually outdoor), kids_area (almost always indoor, esp in Russia during winter) why can't we get rid of the exceptions (usually, almost always) and state that one is outdoors, the other indoors (if standalone), or one is standalone, the other is part of another feature like a shop. I would prefer leisure=playground for standalone and kids_area=yes for an additional feature. This seems intuitive to me. Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mapping of kids areas
2014-12-19 13:59 GMT+01:00 Martin Koppenhoefer dieterdre...@gmail.com: I wouldn't add secondary criteria to the definition that is only sometimes or usually true. That's usually not a good idea, because sometimes a common motorway might also be some kind of runway for something similar to an aeroplane ;-) usually, sometimes co are good for examples but bad for definitions. We should try to avoid those. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mapping of kids areas
2014-12-19 14:05 GMT+01:00 Mateusz Konieczny matkoni...@gmail.com: -1, there is no reason to tag two identical playgrounds (outdoor, standard set of playground toys) differently just because one is near mall and other not. You are right. But we are not talking about near, we are talking about part of. This is relevant, for example a playground near a mall might be accessible 24/7, but a playground in a mall only when the mall is also open. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Introducting power=terminal and power=connection for power transmission
Just want to thanks François for his very professional approach in introducing new tags and cleaning up existing ones. Thumbs up. That's hard work and it's not always fun ;-) 2014-12-18 10:44 GMT+01:00 François Lacombe fl.infosrese...@gmail.com: They both aren't yet approved and must be used with caution. Tags doesn't have to be approved to be used by everybody. But caution is necessary with new tags: meaning might change or the majority might decide on other tags. But still: this is OSM and you're free to use any tags you want as long as you don't harm other taggings. We should never forget this. Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] city walls (was: Watermill attributes)
2014-12-17 10:24 GMT+01:00 Philip Barnes p...@trigpoint.me.uk: http://en.m.wikipedia.org/wiki/Whip-Ma-Whop-Ma-Gate Never been to York to date, but I already love it! Thanks for that ;-) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mapping of kids areas
2014-12-15 13:31 GMT+01:00 Tom Pfeifer t.pfei...@computer.org: I don't see a need for a new key here. The properties can be easily modelled with sub-tagging of playground: Fully agree. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] [tagging] Amenity=Ufficio_Pubblico
2014-12-15 15:42 GMT+01:00 sabas88 saba...@gmail.com: I know we have an unusual amount of bureaucracy in Italy, but we may not need a custom tag for it http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dpublic_building Why is this abandoned? I just read the talk page, but it is not really clear to me. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Combining gas stations convenience stores
2014-12-12 17:28 GMT+01:00 fly lowfligh...@googlemail.com: Am 05.12.2014 um 21:30 schrieb Paul Johnson: How about site relations? Seems like a good use of a site relation. As long as it possible to draw the whole site as a single polygon, there is no need of a site relation. Correct. I would like to ask everyone to keep in mind that OSM data is usually stored in some kind of spatial database. On core feature of any spatial database is the ability to determine what features overlap others or what feature(s) contain(s) specific other feature(s). In short: a relation is never necessary if you simple want to know what features are contained within an area. Just draw the area. And never forget the biggest advantage of a simple area compared to a relation: if you want to add a new feature and you used an area, you simply add the new feature and you're done. If you used the relation, you need to add the new feature also to the relation. If different mappers are involved, it is very likely that one or the other forgets this - or doesn't even know about it - and therefore breaks the relation. The site relation is a good example of a often misused relation. It is only necessary if the features of the site are spread over different places. I seriously doubt that this would be true for most - if not all - gas stations world wide. br, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - (Pipeline Extension)
2014-12-12 22:32 GMT+01:00 Rainer Fügenstein r...@oudeis.org: also a big thanks to Imagic, who tutored the very beginnings of the proposal, among other things. Did I? This is so long ago, it isn't even true already ;-) You did a fine job there, I merely pushed you a little in the right direction at the beginning, nothing more. Keep it up! Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Combining gas stations convenience stores
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
Re: [Tagging] Combining gas stations convenience stores
In my opinion the gas station is not the building but the whole area. Also the address belongs to the whole area and that's the way I tag gas stations: - Draw an area to cover the complete gas station and put amenity=fuel together with additional tags like the address on it. In my region it is usually quite clear on an aerial image where the station starts and where it ends (some kind of fence, barrier, whatever, ...). - Draw the roads (highway=service) and buildings (building=yes resp. building=roof + layer=1) - Additional attributes like amenity=car_wash, amenity=parking, shop=convenience go to there actual position, i.e. if there is a convenience store in one of the buildings I add the tag there. - No need to provide the address more than once: the address belongs to everything within the area tagged with amenity=fuel best regards, Martin 2014-12-05 6:19 GMT+01:00 Hans De Kryger hans.dekryge...@gmail.com: Hopefully this gets enough attention on the tagging list. Thought about posting this to talk U.S but changed my mind. Anyways to my problem. One of my passions to map in osm is gas stations. I've done hundreds since I've joined and now have fully come to realize a persistent problem that occurs frequently. The duplicate address tagging of a gas station and convenience store run by the same company. For example, say i just added a circle k gas station down the street from me to osm. But the gas station also has a convenience store. Well i have to copy over all the address info from one poi to the other since leaving the address Field blank makes no sense if someone would like to get there using a navigation app. I have thought about it a lot. And i go back and forth thinking both places should be tagged. Still a part of me thinks it makes no sense to have a address for a gas station tagged twice. One reason we cant completely combine the gas station and convenience store tag is some gas stations have the convenience store run by separate companies. As is the case with a circle k down the street from me. The convenience store is a circle k but the gas station is a shell. It would be nice to have a separate tag that combined the gas and convenience store shop together. I just want to make clear i don't want to get rid of the existing tags i just want to add one. *Regards,* *Hans* ___ 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] sub key for cycle ways
Hi! 2014-11-03 18:47 GMT+01:00 Hubert sg.fo...@gmx.de: But the question is, whether we should abandon cycleway=* tagging on the main road in favor for, let us say, cycleway:lanes=, or do we allow lane tagging in addition to the well established cycleway=* scheme. As I wrote the :lanes proposal I'm obviously in favour of using it whenever it is useful. And useful for me means: whenever there is not a simpler tagging variant. If there is a simple road, two lanes, one in each direction and on both side there's a cycle lane, then there is definitively no need at all for any :lanes tagging. On the other hand, if we are looking at junctions with multiple (turning) lanes and multiple cycle lanes, then we should use the :lanes tagging in addition(!) to the good old cycleway tagging. In general I would like to see the :lanes tagging used to provide more details and not to replace established tagging. Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - relation type=person
Just a quick note: 2014-10-14 21:19 GMT+02:00 Pieren pier...@gmail.com: If I find personal data on my own family in OSM, I will delete them immediatly without any permission. I guess you wanted to write asking anyone for permission instead of permission. You don't have to ask for permission, because you simply do not need one! This is something we should keep in mind every time someone wants to add personal data. For dead people it might be somehow ok (although I myself would never do that), but for living people it is a complete No-go and - depending on the data - will be illegal in many countries. My two cents: * Data that might be ok: name of the architect of a building, name of someone famous on his/her house of birth (if it is written on the building), ... * Data that is never ok: about living, ordinary people - never. Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - relation type=person
2014-10-14 23:31 GMT+02:00 moltonel 3x Combo molto...@gmail.com: I think that who is in which tomb is information that does belong in OSM. Finding the tomb you want in a cemetery is *hard* and I'd love to be able to use OSM for it (probably via a specialized smartphone app). A particular tomb is like any POI, OSM should enable me to find it. Not all cemeteries are well organised enough to have grave or even row numbers. This is not only about noteworthy people either, one should be able to map a cemetery exhaustively. Simple question: why? If those are relatives of you, you should know where they are buried. If not, you should not care. Really not. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] man_made=bridge
Hi! 2014-10-13 12:12 GMT+02:00 Lukas Sommer sommer...@gmail.com: I would add the requirement that the highways/railways/paths that go over a bridge have to share a node with the outline area. Second sentence in the section Tagging - Bridges with one level: Connect all OSM ways running over that bridge to the outline. Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] landuse=grass = natural=grass
Hi! 2014-09-17 23:44 GMT+02:00 Daniel Koć daniel@koć.pl: We (in Polish forum) think, that changing landuse=grass into natural=grass would make better tagging scheme, since grass is seldom a landuse (like the tree is natural=tree, not the amenity or something else). How do you find this idea? Not good. Contrary to other people I think that the readability of tags is most important, otherwise we could simply use tags like ptn=pnx or road=flying_saucer and define that those tags mean grass. Both could be processed perfectly fine but obviously doesn't make any sense at all. A while ago I wrote down some thoughts about a cleanup of landuse/natural/surface with the intention of clearly separating those tags and make it more easy to understand their meaning. I have to admit that I lost interest in this area so my writing just sits there and waits for someone to adopt it: http://wiki.openstreetmap.org/wiki/User:Imagic/landcover . The first section When to use ... would be the most important in your case. Therefore I would recommend landcover=grass in your case. If this area is also used to e.g. produce hay I would also use landuse=meadow. Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tag for livestocks pens
Hi! 2014-09-06 9:17 GMT+02:00 Severin Menard severin.men...@gmail.com: Am 01.09.2014 12:20, schrieb Severin Menard: How should we map the livestock pens in farmyards? barrier = fence And (IMHO): it should be a permanet installation and no temporary thing... Thanks for your answer. Sure for barrier=fence, but it does not say what is inside the fence. The houses have a fence for the people and those ones are for the animals. When it deals with potential epizootics, it is not the same thing. What about pen=yes or run=yes? (I do not find any occurrence in taginfo, though). livestocks=* would serve to mention the kind of penned animals. This should help: http://taginfo.openstreetmap.org/search?q=animal_keeping https://wiki.openstreetmap.org/wiki/Proposed_features/landuse%3Danimal_keeping Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mapping cave tunnels passable by human
2014-08-14 12:25 GMT+02:00 André Pirard a.pirard.pa...@gmail.com: On 2014-08-14 11:08, Janko Mihelić wrote : Well first, tunnel=yes is obviously wrong. We need to replace this with cave=yes. Other than that, I have no problems with this. If a cave has two cave entrances, then information that they are connected by footpaths is valuable information. Obviously? Regarding paths and waterways, especially ones fitted up for tourism, I wonder... Maybe not completely obvious, but I would agree with Janko. In my opinion, a tunnel is man-made, while a cave is not. Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] bridge movable vs swing vs swinging
Hi! 2014-08-12 22:57 GMT+02:00 Richard Z. ricoz@gmail.com: what else can I do? Maybe it's time to open up a change request for the main map style? The tag man_made=bridge seems to be used worldwide [1] in some - more or less - consistent way. It provides useful data, is simple to tag, it should be easy to render and it solves some ugly rendering issue. Is there a place where someone could take the main style, change it and see the difference in rendering? So we could not only open a ticket but also provide a patch. Best regards, Martin [1] http://taginfo.openstreetmap.org/tags/man_made=bridge#map ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] horse=designated for recommend routes?
Hi! The wiki article about horseback riding was just updated: https://wiki.openstreetmap.org/w/index.php?title=Ridingdiff=1072292oldid=872941 Since when is designated used for recommend routes? regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Follow up on destination= and destination:ref=
Hi! 2014-07-10 15:43 GMT+02:00 Martijn van Exel m...@rtijn.org: Here at Telenav, we have now adopted destination= and destination:ref= for signpost information. Great news! I just came back from my holidays where we used Skobbler (I guess you know it ;-) ) for navigation and it was hell. Skobbler desperately needs that kind of information. Just a brief summary for everyone who's never used the key destination and its sub-keys: * The key destination=* describes the direction of the highway by using the name of the city the highway is heading to. [1] * There are some proposed sub-keys to provide further information, e.g. destination:ref to provide the reference of the highway this highway is heading to. [2] * The JOSM style Land and road attributes [3] has rudimentary support for destination, destination:ref, destination:int_ref and destination:country, so you are able to see that kind of information while editing in JOSM. Best regards, Martin [1] http://wiki.openstreetmap.org/wiki/Proposed_features/Destination_details [2] http://wiki.openstreetmap.org/wiki/Proposed_features/Destination_details [3] http://josm.openstreetmap.de/wiki/Styles/Lane_and_Road_Attributes ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Area with a lot of destination_sign relations?
Thanks for the hint. Sadly the relations used there don't follow any convention I have found (direction often but not always used instead of destination, references included in the name instead in separate tags like destination:ref/destination:int_ref, comma instead of semicolon to separate multiple values, ) therefore my rendering doesn't work at all. But at least I found a bug in my error detection and can test left-hand traffic a little bit ;-) BTW: shouldn't active_traffic_management=yes be maxspeed:variable=peak_traffic or something similar? At least I couldn't find any documentation for that tag. Thanks, Martin 2014-02-05 Nick Allen nick.allen...@gmail.com: Martin, I haven't looked lately, but the M25 south of the Dartford river crossing, and round to junction 5, Sevenoaks, plus M20 in this area were starting to get populated. Nick Volunteer 'Tallguy' for https://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Team Mapping volunteer 'Tallguy' for http://www.openstreetmap.org Treasurer, website Bonus Ball admin for http://www.6thswanleyscouts.org.uk/ (treasu...@6thswanleyscouts.org.uk) On 05/02/14 13:57, Martin Vonwald wrote: Hi! Can someone point me to an area where a lot of destination_sign relations are used? I need some real-word examples for testing. Thanks, Martin ___ Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging ___ 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] Area with a lot of destination_sign relations?
At least in theory it works a little bit: http://vonwald.info/osm/images/Rendering_of_destination_sign.png 2014-02-06 Martin Vonwald imagic@gmail.com: Thanks for the hint. Sadly the relations used there don't follow any convention I have found (direction often but not always used instead of destination, references included in the name instead in separate tags like destination:ref/destination:int_ref, comma instead of semicolon to separate multiple values, ) therefore my rendering doesn't work at all. But at least I found a bug in my error detection and can test left-hand traffic a little bit ;-) BTW: shouldn't active_traffic_management=yes be maxspeed:variable=peak_traffic or something similar? At least I couldn't find any documentation for that tag. Thanks, Martin 2014-02-05 Nick Allen nick.allen...@gmail.com: Martin, I haven't looked lately, but the M25 south of the Dartford river crossing, and round to junction 5, Sevenoaks, plus M20 in this area were starting to get populated. Nick Volunteer 'Tallguy' for https://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Team Mapping volunteer 'Tallguy' for http://www.openstreetmap.org Treasurer, website Bonus Ball admin for http://www.6thswanleyscouts.org.uk/ (treasu...@6thswanleyscouts.org.uk) On 05/02/14 13:57, Martin Vonwald wrote: Hi! Can someone point me to an area where a lot of destination_sign relations are used? I need some real-word examples for testing. Thanks, Martin ___ Tagging mailing listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Area with a lot of destination_sign relations?
Hi! Can someone point me to an area where a lot of destination_sign relations are used? I need some real-word examples for testing. Thanks, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] How to tag an imaginary oneway barrier
Hi! 2014-02-01 Pee Wee piewi...@gmail.com: 3 Cut the way where the sign is into a tiny piece of way. Add a motorcar:backward =no to this tiny piece of way. That variant has been used in my area. The tiny piece is usually the part from the junction up to where the sign is located. Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Minor update of JOSM style Lane and road attributes
Hi! After the major update of JOSM yesterday I made a small update for the style Lane and road attributes [1] which renders many lane properties while editing: * Road markings for turning lanes are now rendered much more precisely. This was already available for a long time but disabled by default because of a huge memory leak which was fixed in the latest JOSM update (thanks to the developers again!). Just try turn:lanes=slight_left;left;sharp_left|slight_right;right;sharp_right . * Most style settings (including support for left-hand traffic) can now be configured using Edit - Settings - Display settings - Colours. See [1] for a more detailed description. Have fun, Martin [1] https://josm.openstreetmap.de/wiki/Styles/Lane_and_Road_Attributes ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging Religious Places that belongs to multiple Religion
Hi! 2014/1/13 Nirab Pudasaini developer.ni...@gmail.com The tag amenity:place_of_worship has a key religion:* but how can we add place of worship which are for multiple religions, as in case of Pashupatinath. Just use the semi-colon to separate the values: religion=religion1;religion2;;religionX Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature proposal - Voting - Gambling (reminder)
Hi! 2014/1/9 fly lowfligh...@googlemail.com and only use gambling, especially as it might collide with another value of amenity. In my opinion we all really should start accepting that a key might have more than one possible value. I don't see any problem in amenity=pub;gambling . - Ok, you don't like the semi-colon, so lets move gambling to a different key - now we have amenity=pub + gambling=yes - problem solved. Fine. Oh, wait - there's a pub that's also a nightclub! amenity=pub;nightclub? No way, so lets move nightclub to a different key - problem solved! Again. One moment: this pub sells ice_cream! No problem, just move ice_cream to a different key - See what I mean? The sooner we start to accept multiple values the less problems we will have in the future. --- my opinion! Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
