Re: [Tagging] Dispute prevention: meaning of lanes tag
The narrow road example was clearly the wrong image. I changed that to lanes=1 and added a photo from Philip Barnes as example for a narrow two-lane road. Further I removed the assumptions for two-way motorways/trunks, as it is recommend to map their carriageways as two separate way. Anyone else has a problem with the suggested solution to the lanes=1.5 problem? And should I add a recommendation to always tag the lane count, also e.g. for residentials? Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dispute prevention: meaning of lanes tag
On Fri, Apr 27, 2012 at 9:18 AM, Martin Vonwald Anyone else has a problem with the suggested solution to the lanes=1.5 problem? I think we should simply recommend to not use fractions since they can be misinterpreted by any one (not only applications). I still don't know if 1.5 means an intermediate status between 2 lanes and 1 lane segments or a wide single lane or a normal lane plus a half size lane or two narrow lanes. Pieren ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dispute prevention: meaning of lanes tag
On Fri, 27 Apr 2012, Pieren wrote: On Fri, Apr 27, 2012 at 9:18 AM, Martin Vonwald Anyone else has a problem with the suggested solution to the lanes=1.5 problem? I think we should simply recommend to not use fractions since they can be misinterpreted by any one (not only applications). I still don't know if 1.5 means an intermediate status between 2 lanes and 1 lane segments a wide single lane a normal lane plus a half size lane two narrow lanes ...While I didn't fully understand the first definition. ...I don't find much different between those definitions but perhaps you can enlighten me if there's anything else than some fancy wordsmithing looking into the very same road from different angles? :-) -- i. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dispute prevention: meaning of lanes tag
On Fri, 27 Apr 2012, Ilpo Järvinen wrote: On Fri, 27 Apr 2012, Pieren wrote: On Fri, Apr 27, 2012 at 9:18 AM, Martin Vonwald Anyone else has a problem with the suggested solution to the lanes=1.5 problem? I think we should simply recommend to not use fractions since they can be misinterpreted by any one (not only applications). I still don't know if 1.5 means an intermediate status between 2 lanes and 1 lane segments a wide single lane a normal lane plus a half size lane two narrow lanes ...While I didn't fully understand the first definition. ...I don't find much different between those definitions but perhaps you can enlighten me if there's anything else than some fancy wordsmithing looking into the very same road from different angles? :-) Btw, IMHO these plurar definitions you gave for the same thing is one of the reasons why lanes=1.5 appears in the db in the first place. The width alternative hardly conveys all the same meaning as it cannot say lanes=1+wide and lanes=2+narrow at the same time! -- i.___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] area=yes on polygones (was Block names)
On Fri, Apr 27, 2012 at 2:53 AM, Tobias Knerr o...@tobias-knerr.de wrote: If a feature can be either a closed way or an area, the default interpretation should always be the closed way. Otherwise, you'd have to know arbitrary defaults for each type of object. You have to know anyway if your feature can be either a closed way or an area and therefore need some special handling in your apps. The question is then more to consider certain features as area or closed way by default. On this point, I'm always standing on the contributors side and wont ask them to add an unnecessary tag for 99.99% of the cases. Pieren ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dispute prevention: meaning of lanes tag
On Fri, Apr 27, 2012 at 9:58 AM, Ilpo Järvinen if there's anything else than some fancy wordsmithing looking into the very same road from different angles? :-) Well, sometimes you have 1 lane, sometimes 2, or something in between. Sometimes it is related to the width, sometimes only about the painting on the road. It is bit more than fancy wordsmithing. It is simply impossible to interpret. As Martin said, it is too subjective and should be avoided. Pieren ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dispute prevention: meaning of lanes tag
I'm quite happy with lanes=n where n is an integer. I am very happy to assume that a one-way road without lanes=* has only one lane. I am also happy to assume that a not-one-way road without lanes=* has two lanes (one in each direction). I am extremely happy to see a width=* tag that I can use in conjunction with the lane count (even if the lane count is assumed). It tells me the width of each lane. A lane count of 1.5 is very confusing. What does it mean? What is the width of each lane? Is it really 1.5? Should it be 1.55, or 1.4, or 1.6? It's more useful to tell me width of the road. Then, if there is one lane I can see maybe it's very wide, or if two lanes I can see maybe they are very narrow. It's okay to let me assume the number of lanes because the assumption is safe, and if it's really wrong then someone will tag it properly later. In summary, I think simpler is better. A non-integer lane count is useless. Use the width tag. Best wishes, Andrew ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] contact:phone or phone to combine with amenity=telephone
Am 26.04.2012 18:07, schrieb Mike N: On 4/26/2012 8:51 AM, Martin Koppenhoefer wrote: Can we use the taginfo stats to revert the change made the 2nd may 2010 where phone has been replaced by contact:phone and add a big deprecate notice on the contact: namespace wiki ? (overall, we still have 10 times more phone than contact:phone, 20 times more website than contact:website, etc) +1 from me, but I know there are other mappers opposing this and trying to push the contact: prefix. I agree with those wanting the 'contact:' format that it is unambiguous and might be easier to use and analyze, but since no data consumers use it (that I know of), 'phone' is preferred.I know of several data consumers on mobile apps that use 'phone'. well, I too appreciate the namespaces if they avoid ambiguity - but is there really any ambiguity with phone, fax, email, website, webcam? contact: is a mere categorisation than distinction - and so it is just stuffing for me. Georg ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dispute prevention: meaning of lanes tag
Through observations I can see that there is a minimum width for lane marking in the UK. I am not sure what the value is, but have seen sections of road where lines end where the road narrows. Will try to find an example. I am not sure I would want to add a lanes tag where the width falls below this minimum, and would tend to prefer the width tag. Whilst following cars, it has occurred to me that knowing their width would be a reasonable yardstick for estimating the width of a road. Phil On 27/04/2012 10:29 Andrew Errington wrote: I'm quite happy with lanes=n where n is an integer. I am very happy to assume that a one-way road without lanes=* has only one lane. I am also happy to assume that a not-one-way road without lanes=* has two lanes (one in each direction). I am extremely happy to see a width=* tag that I can use in conjunction with the lane count (even if the lane count is assumed). It tells me the width of each lane. A lane count of 1.5 is very confusing. What does it mean? What is the width of each lane? Is it really 1.5? Should it be 1.55, or 1.4, or 1.6? It's more useful to tell me width of the road. Then, if there is one lane I can see maybe it's very wide, or if two lanes I can see maybe they are very narrow. It's okay to let me assume the number of lanes because the assumption is safe, and if it's really wrong then someone will tag it properly later. In summary, I think simpler is better. A non-integer lane count is useless. Use the width tag. Best wishes, Andrew ___ 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] Dispute prevention: meaning of lanes tag
Am 27. April 2012 12:01 schrieb Philip Barnes p...@trigpoint.me.uk: I am not sure I would want to add a lanes tag where the width falls below this minimum, and would tend to prefer the width tag. +1 Whilst following cars, it has occurred to me that knowing their width would be a reasonable yardstick for estimating the width of a road. for regular cars, 1,60-1,90 might be a good (European) approximation, add ~25-30cm for 2 mirrors. Minivans (e.g. Mercedes Sprinter) are around 2 m without mirrors, trucks are around 2,50). http://www.mercedes-benz.com.cy/content/cyprus/mpc/mpc_cyprus_website/enng/home_mpc/trucks_/home/long_distance/actros_long_distance_haulage/Cabs.0004.html cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dispute prevention: meaning of lanes tag
IMHO it would be a good idea to remove fractional lanes amounts and forget about them. They are too subjective. What do you think of lanes=3.5? I have an example here: http://maps.google.it/maps?hl=enll=41.899274,12.464333spn=0.008497,0.021136t=hz=16layer=ccbll=41.899391,12.464289panoid=O8BHrnM_gTAW2XQUWqxcXgcbp=12,353.6,,0,4.57 When the lanes are marked on the ground, it ought to be an offence to drive continuously on the lines separating lanes; hence, there are only three lanes in the link above, even if some or many drivers think they can get away with it. Not sure, how many lanes these are, could be 5 or even 5.5? Depends on the car widths and the experience of the drivers: http://maps.google.it/maps?hl=enll=41.876836,12.481943spn=0.000378,0.00066t=hz=21 Changing lanes and overtaking within an intersection ought to be an offence in developed countries, so from the modelling point of view there can only be as many lanes as there are on any of the incoming or outgoing carriageways. vehicles can pass at the same time, lanes=1.5 doesn't really help you, it will always remain unclear which width is the street. There are those roads (yes, roughly 4 meters wide) that, based on the overall setting, can not be called two lane roads, but it would be misleading to tag them with lanes=1, either. Aren't we supposed to safely assume that every road can be tagged with some correct lanes tag? -- Alv ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dispute prevention: meaning of lanes tag
Am 27.04.2012 09:23, schrieb Ilpo Järvinen: On Thu, 26 Apr 2012, Martin Koppenhoefer wrote: What do you think of lanes=3.5? I have an example here: Not sure, how many lanes these are, could be 5 or even 5.5? Depends on the car widths and the experience of the drivers: Heheh... :-) ...there's one major difference between 1.5 and=2.5, ie., whether the traffic in one direction almost always interferes with the opposite direction of the traffic, in the latter case it shouldn't happen So you mean 1.5 is the same as 1 regarding the almost always interfere? ;-) Georg in the mood too - but in jolly springtime mood ;-) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dispute prevention: meaning of lanes tag
Am 27. April 2012 12:18 schrieb Kytömaa Lauri lauri.kyto...@aalto.fi: IMHO it would be a good idea to remove fractional lanes amounts and forget about them. They are too subjective. What do you think of lanes=3.5? I have an example here: http://maps.google.it/maps?hl=enll=41.899274,12.464333spn=0.008497,0.021136t=hz=16layer=ccbll=41.899391,12.464289panoid=O8BHrnM_gTAW2XQUWqxcXgcbp=12,353.6,,0,4.57 When the lanes are marked on the ground, it ought to be an offence to drive continuously on the lines separating lanes; hence, there are only three lanes in the link above, even if some or many drivers think they can get away with it. It's not that they think they get away with it: they _do_ get away with it. If everybody in this area drives in a certain style, and police doesn't enforce the official rules, then there are factually more lanes on the ground than painted on the road. Not sure, how many lanes these are, could be 5 or even 5.5? Depends on the car widths and the experience of the drivers: http://maps.google.it/maps?hl=enll=41.876836,12.481943spn=0.000378,0.00066t=hz=21 Changing lanes and overtaking within an intersection ought to be an offence in developed countries, so from the modelling point of view there can only be as many lanes as there are on any of the incoming or outgoing carriageways. not sure, this is a point where _several_ (4) carriageways meet, each of them with at least 2 lanes, and they don't go all in one direction but in two, where for one of these it is also unclear how many lanes there are (the other are 2.4 I'd say ;-) ). vehicles can pass at the same time, lanes=1.5 doesn't really help you, it will always remain unclear which width is the street. There are those roads (yes, roughly 4 meters wide) that, based on the overall setting, can not be called two lane roads, but it would be misleading to tag them with lanes=1, either. yes, and even lanes=1.4 or 1.6 will be unclear. In these cases (which usually also don't have painted lanes) the best thing to do is omit the lanes tag and go for width. See also above in this thread. Aren't we supposed to safely assume that every road can be tagged with some correct lanes tag? IMHO no, but if you insist on setting them, what about lanes=1, oneway=no, width=4? cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dispute prevention: meaning of lanes tag
On Fri, 27 Apr 2012, Georg Feddern wrote: Am 27.04.2012 09:23, schrieb Ilpo Järvinen: On Thu, 26 Apr 2012, Martin Koppenhoefer wrote: What do you think of lanes=3.5? I have an example here: Not sure, how many lanes these are, could be 5 or even 5.5? Depends on the car widths and the experience of the drivers: Heheh... :-) ...there's one major difference between 1.5 and=2.5, ie., whether the traffic in one direction almost always interferes with the opposite direction of the traffic, in the latter case it shouldn't happen So you mean 1.5 is the same as 1 regarding the almost always interfere? ;-) ...A more appropriate word would be somewhat stronger prevents for real lanes=1 I suppose, but I'm not native so I might be wrong? ;-) (Or alternatively one needs a road excursion / passing place). ...Besides, this distinction based on interfering is mostly mean to differentiate from normal lanes=2 road, not from lanes=1 one. -- i.___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dispute prevention: meaning of lanes tag
Wouldn't this discussion benefit from a summary of the use cases we are trying to address? I see multiple semantics being suggested for the lanes tag, and at the end of the day we will have to choose one. * Renderers such as mapnik might want to reflect the number of lanes in the width of the line * Routers might use the lane count (along with many other attributes) in heuristics for the road capacity and travel time * Other renderers might try to derive a picture of the road or junction Sometimes it's about what is painted on the road; sometimes it's how many vehicles fit across the road; sometimes it's something else. If we choose one definition for the lanes tag, and allow the other definition to be derived by combining lanes=* with something else, then everyone could be happy. To choose one definition above the other options we should look at which is likely to be the most useful to the most users (in the broadest sense). The minority use cases will then be able to derive what they need by combining tags. As a simple example, on a motorway with 3 normal lanes plus a hard shoulder, we could have lanes=3 and shoulder=yes in one model, or lanes=4 shoulder=yes in another model. In either case, provided the semantics of the tags are applied consistently, one can satisfy all the use cases I listed above. If there are narrower lane This is a classic case of a discussion dragging on for hundreds of posts discussing different points of view (and there's nothing wrong with that of course) without a common cause to allow the discussion to converge. If we only discuss how to put things INTO the data without a view of how we (and others) might want to USE that data, we will end up with nobody being happy. If this situation arose on my project I would be having SERIOUS discussions with the customer - maybe the project should never have been started. Colin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dispute prevention: meaning of lanes tag
On Fri, 27 Apr 2012 18:54:26 Ilpo Järvinen wrote: On Fri, 27 Apr 2012, Andrew Errington wrote: A lane count of 1.5 is very confusing. What does it mean? What is the width of each lane? Is it really 1.5? Should it be 1.55, or 1.4, or 1.6? ...No, it's not multiple of some magical default lane width like you imply. But simply _something_ between normal lanes=1 and normal lanes=2. But the width=* tag tells you this. Specifically, the width tag tells you if there will be a problem *for you*. Since I have never met you and I don't know what vehicle you are using it would be presumptious of me to tell you that there are 1.5 lanes. Also, it doesn't make sense to allow lanes=1.5 but deny 1.55, 1.4, 1.68 or any other fractional value. What you are doing is introducing a 'special' value with a special meaning. I think we should try to avoid having to interpret special cases. It's more useful to tell me width of the road. Then, if there is one lane I can see maybe it's very wide, or if two lanes I can see maybe they are very narrow. ...But how can I tag you this: A road which is lanes=1+wide _AND_ lanes=2+narrow at the same time? ...You ask me to provide width and select one of those two, and that is what I oppose, unless you give me some real tag that is not width to tell that 'hey, there really isn't lanes marked (which makes it kind of lanes=1) but two can somewhat fit (which makes it kind of lanes=2 but not really because it's only somewhat)'! ...What I would not want to do is to tag those lanes=1 because that's certainly a lie as anyone can clearly see after observing some bidirectional traffic there. It's not a lie. A single lane may be bidirectional. In fact, in this case you *should* tag it lanes=1. If oneway=yes is not present then it means one bidirectional lane. In summary, I think simpler is better. A non-integer lane count is useless. Use the width tag. I oppose using width tag (at least alone) for this because it won't convey the double meaning. Some other tag than width and tagging with lanes=2 perhaps (like I already suggested much earlier)? I don't think there is a double meaning. lanes=1 tells me there is one lane. It does not mean one direction, nor should anyone assume that. I *think* you are saying that lanes=1.5 tells me this road is not really wide enough for two-way traffic, but there *is* two-way traffic so if there is a car coming the other way you have to wait[1]. For the purpose of discussion, let us assume that a road of 2.5 m width is too narrow for cars to pass. lanes=1 width=2.5 tells me the same thing (one narrow lane, cars travel both directions, but only one direction at a time). lanes=2 width=2.5 tells me the same thing (two very narrow lanes, cars travel both directions, but only one direction at a time). lanes=1 tells me the same thing (one lane implies cars cannot travel both directions at the same time, but no oneway=yes tag implies cars can travel in both directions. We don't know the width but there must have been a reason for a mapper to tag it with lanes=1). width=2.5 tells me the same thing (no lanes=* tag and no oneway=yes tag implies two lanes, but both must be very narrow therefore cars can only travel one direction at a time). I don't think any of these assumptions are unreasonable, and they don't alter the existing meaning of the tags, which I believe are already quite clear, so we should use them and not alter them with special cases. Best wishes, Andrew [1] I have made this sentence to interpret what lanes=1.5 means. If my understanding is incorrect please state what lanes=1.5 actually means. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dispute prevention: meaning of lanes tag
On Fri, 27 Apr 2012, Martin Vonwald wrote: Maybe we could put an end to this discussion by enumerating the pro and cons for both approaches? What exactly is the problem with lanes=integer+width, that is solved with lanes=1.5 ? Please pick the integer first so we can discuss more. ...Although I think I've already explained it multiple times for both possible values :-). -- i. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] lanes=* on cycleways
How do we handle lane counts where there's more than one bicycle lane? How do we count lanes on cycleways? Since these lanes are narrower than what cars can fit down, things like Gresham segments of the Springwater Corridor (4 lanes) and situations like 12th Avenue (which has a couple spots with bike lanes on both sides of a one-way street) or the Hawthorne Bridge (two car lanes, two bicycle lanes on the westbound approach; two bike lanes on the one-way cycleways) would all count as lanes=0 or only count car lanes under the existing lanes=* proposal. I imagine the Dutch have a similar problem, given that I have a sneaking suspicion multilane cycleways are somewhat more common there. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] area=yes on polygones (was Block names)
On Thu, Apr 26, 2012 at 8:53 PM, Tobias Knerr o...@tobias-knerr.de wrote: Anthony wrote: On Wed, Apr 25, 2012 at 5:17 AM, Nathan Edgars II nerou...@gmail.com wrote: Where did I mention a renderer? If you draw a closed polygon with railway=platform, that's a continuous platform with a hole in the middle. There may be a few cases of such in real life at a complicated junction. If so, they should be tagged with area=no. area=no can be considered a sic!, but that tag should never have any actual effect. Effect on what? If I were writing a renderer, I would assume that a closed way railway=platform represented an area unless it was tagged area=no. So that's an effect. If a feature can be either a closed way or an area, the default interpretation should always be the closed way. Otherwise, you'd have to know arbitrary defaults for each type of object. A default set to the value which is correct 99.9% of the time is not arbitrary. Should defaults be documented somewhere? Absolutely. Should users of the data ignore reality because someone wrote something somewhere in the wiki? Absolutely not. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Dispute prevention: meaning of lanes tag
On Fri, 2012-04-27 at 10:01 +, Philip Barnes wrote: Through observations I can see that there is a minimum width for lane marking in the UK. I am not sure what the value is, but have seen sections of road where lines end where the road narrows. Will try to find an example. Sorry its been too wet to go out and take photos. An example where the road become too narrow for lane markings as it crosses a bridge, the lines recommence on the other side when the road becomes wide enough. http://g.co/maps/7svgs Again lines end where the road becomes too narrow, cars can pass but you have to wait for anything much larger. http://g.co/maps/3y7ja Maybe this one is silly, http://g.co/maps/atszn The road is a lot less than 3m wide, the lines indicate a warning for the give way as it reaches the trunk road ahead. It is still a single lane. Phil ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] area=yes on polygones (was Block names)
On Fri, Apr 27, 2012 at 4:12 AM, Pieren pier...@gmail.com wrote: On Fri, Apr 27, 2012 at 2:53 AM, Tobias Knerr o...@tobias-knerr.de wrote: If a feature can be either a closed way or an area, the default interpretation should always be the closed way. Otherwise, you'd have to know arbitrary defaults for each type of object. You have to know anyway if your feature can be either a closed way or an area and therefore need some special handling in your apps. The question is then more to consider certain features as area or closed way by default. On this point, I'm always standing on the contributors side and wont ask them to add an unnecessary tag for 99.99% of the cases. I don't mind asking them to (hence I don't mind the wiki saying that they *should* do so). But I do mind if people take the fact that the wiki asks them to as an excuse not to add area=no in the other 0.01% of cases. Or, in RFC-speak. I would be fine with Users SHOULD add area=yes when mapping a railway platform as an area. Users MUST add area=no when mapping a railway platform with a closed way which does not represent an area. I'd prefer Users MAY add area=yes when mapping a railway platform as an area. Users MUST add area=no when mapping a railway platform with a closed way which does not represent an area. though. If the (nonexistent) specs say that area=no is the default for railway=platform closed ways, the (nonexistent) specs are broken. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] area=yes on polygones (was Block names)
Am 27. April 2012 20:14 schrieb Anthony o...@inbox.org: A default set to the value which is correct 99.9% of the time is not arbitrary. how would you distinguish between default values and incomplete data/missing information? We could have a tag defaults_checked=area;surface;lanes;oneway;lit;width;... to show which defaults have been checked, and maybe have different default-schemes maintained by different people or for different topics. We could define default sets in the wiki, default_set_garry:version2=yes, with Versioning, so we can later amend the defaults_sets without bothering... But for simplicity when in doubt I'd set the tag explicitly. According to your estimations every default that is tagged explicitly is at least 0.1% better than not having it. ;-) cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] area=yes on polygones (was Block names)
Op 27 apr. 2012 20:41 schreef Martin Koppenhoefer dieterdre...@gmail.com het volgende: Am 27. April 2012 20:14 schrieb Anthony o...@inbox.org: A default set to the value which is correct 99.9% of the time is not arbitrary. how would you distinguish between default values and incomplete data/missing information? The same way as you distinguish between old and current data: just not. Wait until some mapper sees that it's wrong. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] area=yes on polygones (was Block names)
Anthony wrote: area=no can be considered a sic!, but that tag should never have any actual effect. Effect on what? On renderers or any other applications working with OSM data. If I were writing a renderer, I would assume that a closed way railway=platform represented an area unless it was tagged area=no. So that's an effect. If I were writing a renderer (actually, I am), I would assume that a closed way does not represent an area unless it a) has an always-area tag such as landuse or b) is tagged with area=yes. Your idea that some tags should make a closed way into an area by default, unless there's also a certain other tag (like area=no) present, is not established mapping style as far as I can tell. Currently, tags are either unambiguous, or the default assumption is not an area. Tobias ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] area=yes on polygones (was Block names)
On Fri, Apr 27, 2012 at 2:40 PM, Martin Koppenhoefer dieterdre...@gmail.com wrote: Am 27. April 2012 20:14 schrieb Anthony o...@inbox.org: A default set to the value which is correct 99.9% of the time is not arbitrary. how would you distinguish between default values and incomplete data/missing information? You can't distinguish between them. That's why defaults should be set to the value that's right most of the time. At least, they usually should (sometimes other considerations come into play, for example if the cost of guessing wrong on one side is much higher than the cost of guessing wrong on the other side). Note that I'm talking here about situations where presenting the end-user with unknown is not reasonable. I wouldn't suggest for a map to show default speed limits when nothing was provided. (On the other hand, a routing program probably is going to have to provide default speed limits when calculating the fastest path, and this is a situation where the value that's right most of the time might not be the best one to use.) We could have a tag defaults_checked=area;surface;lanes;oneway;lit;width;... to show which defaults have been checked, and maybe have different default-schemes maintained by different people or for different topics. We could define default sets in the wiki, default_set_garry:version2=yes, with Versioning, so we can later amend the defaults_sets without bothering... This doesn't sound reasonable. But for simplicity when in doubt I'd set the tag explicitly. I think that's probably a good idea for most tags, where the split is 80/20, or 60/40, or 90/10, or where the cost of getting it wrong is very high. For something like railway=platform I wouldn't bother. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] area=yes on polygones (was Block names)
On Fri, Apr 27, 2012 at 3:06 PM, Tobias Knerr o...@tobias-knerr.de wrote: Anthony wrote: If I were writing a renderer, I would assume that a closed way railway=platform represented an area unless it was tagged area=no. So that's an effect. If I were writing a renderer (actually, I am), I would assume that a closed way does not represent an area unless it a) has an always-area tag such as landuse or b) is tagged with area=yes. Your idea that some tags should make a closed way into an area by default, unless there's also a certain other tag (like area=no) present, is not established mapping style as far as I can tell. Currently, tags are either unambiguous, or the default assumption is not an area. Well that's a mistake that should be fixed. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] area=yes on polygones (was Block names)
While this is ongoing, Pieren continues to remove area=yes from railway=platform, which has been on the page since it was created in 2008: http://wiki.openstreetmap.org/w/index.php?title=Tag:railway%3Dplatformaction=history ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
