[Tagging] Feature Proposal - RFC - Obstacle
Hi! I worked hard for reconstruct quickly the recent proposed * «Difficult_Passability»* (pagehttp://wiki.openstreetmap.org/wiki/Proposed_features/Difficult_Passability) to the feature proposed *«Obstacle»*. I'm happy with the new resulting proposal that includes reviews and suggestions of the community: http://wiki.openstreetmap.org/wiki/Proposed_features/Obstacle (discussion page http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Obstacle) Hope you like it. I wait for comments, suggestions and criticisms for make the proposal better. Thanks a lot! Regards -- *KONFRARE ALBERT* La Konfraria de la Vila del Pingüí de La Palma WEB:http://www.konfraria.org TWITTER: http://twitter.com/La_Konfraria FACEBOOK: http://ca-es.facebook.com/people/Konfraria-Vila-Del-Pingui/11918952076 ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Obstacle
I'd suggest some additional values: * rockfall = some rocks have fallen onto the road * guardrail_broken = there is a hole in the guard rail or in a retaining wall alongside the road (i.e. you might fall) Not sure if the latter is really an obstacle, it is a danger element but as it is on the side of the road it will usually not obstruct the road itself. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Obstacle
Am 13.10.2012 11:28, schrieb Martin Koppenhoefer: I'd suggest some additional values: * rockfall = some rocks have fallen onto the road * guardrail_broken = there is a hole in the guard rail or in a retaining wall alongside the road (i.e. you might fall) Not sure if the latter is really an obstacle, it is a danger element but as it is on the side of the road it will usually not obstruct the road itself. -1 for guardrail_broken as part of obstacle. It isn't. Do we have anything for danger sources where it could fit? regards Peter ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Obstacle
2012/10/13 Peter Wendorff wendo...@uni-paderborn.de: Am 13.10.2012 11:28, schrieb Martin Koppenhoefer: I'd suggest some additional values: * rockfall = some rocks have fallen onto the road * guardrail_broken = there is a hole in the guard rail or in a retaining wall alongside the road (i.e. you might fall) -1 for guardrail_broken as part of obstacle. It isn't. Do we have anything for danger sources where it could fit? I agree, what might be an interesting value to add to obstacle is landslide (part of the road slipped away, mostly occuring in hilly / mountainous terrain) cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Obstacle
Hazard = for things like broken barriers? Actually hazard could work for things like landslides and fallen trees too? Graham from my phone. On 13 Oct 2012 11:27, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2012/10/13 Peter Wendorff wendo...@uni-paderborn.de: Am 13.10.2012 11:28, schrieb Martin Koppenhoefer: I'd suggest some additional values: * rockfall = some rocks have fallen onto the road * guardrail_broken = there is a hole in the guard rail or in a retaining wall alongside the road (i.e. you might fall) -1 for guardrail_broken as part of obstacle. It isn't. Do we have anything for danger sources where it could fit? I agree, what might be an interesting value to add to obstacle is landslide (part of the road slipped away, mostly occuring in hilly / mountainous terrain) cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Narrow Bridge (was: Reconstructing «Dificult passability» proposal to «Obstacle»)
Well, car as a unit of road width can be used with the lanes tag. If it catches on it can be put as a proposal. I don't like the lanes tag where there are no lines on the street, it misses the point. Janko 2012/10/13 Stephen Hope slh...@gmail.com Eric, The English version did say that at one point, as well, before it was changed back to the current definition. Maybe the French one was copied from it during that period. Stephen On 13 October 2012 04:49, Eric SIBERT courr...@eric.sibert.fr wrote: Indeed, as pointed out by Martin, I have to use lanes=1. I had a misunderstanding with the lanes=* key. I thought lanes=* indicated the number of lanes in each direction, not the total number in both directions. The French wiki lanes=* page need a strong update, compared to the English one (todo list...). So, I will go on with lanes=1. Éric __**_ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.**org/listinfo/tagginghttp://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] How to tag railroad named control points?
My employer is a contractor for a few railroads, and through that experience I have gained personal knowlege of several named control points for one railroad in particular. A control point typically consists of signals facing both ways, switch tracks to transfer between multiple mainline tracks if applicable, and often signs displaying the name of the control point. While the extents of a control point are not sharply defined (as far as I know) they can be roughly described as a few hundred feet long and as wide as the railroad right-of-way in most cases. How should such a feature appear in OSM? A single node? An area-way around the associated physical features? A relation with several nodes as members? And what tags are appropriate? Does this count as a new feature I should propose? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Obstacle
Hi! I added the value obstacle=heap (the opposite of hole), that could be formed by fallen rocks, debris, etc... -- http://wiki.openstreetmap.org/wiki/Proposed_features/Obstacle#Tagging (the last value for the key in the table) Also I added a mention to landslides -- http://wiki.openstreetmap.org/wiki/Proposed_features/Obstacle#Other_obstacles Thanks for suggestions and comments. Regards ALBERT 2012/10/13 Graham Jones grahamjones...@gmail.com Hazard = for things like broken barriers? Actually hazard could work for things like landslides and fallen trees too? Graham from my phone. On 13 Oct 2012 11:27, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2012/10/13 Peter Wendorff wendo...@uni-paderborn.de: Am 13.10.2012 11:28, schrieb Martin Koppenhoefer: I'd suggest some additional values: * rockfall = some rocks have fallen onto the road * guardrail_broken = there is a hole in the guard rail or in a retaining wall alongside the road (i.e. you might fall) -1 for guardrail_broken as part of obstacle. It isn't. Do we have anything for danger sources where it could fit? I agree, what might be an interesting value to add to obstacle is landslide (part of the road slipped away, mostly occuring in hilly / mountainous terrain) cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging -- *KONFRARE ALBERT* La Konfraria de la Vila del Pingüí de La Palma WEB:http://www.konfraria.org TWITTER: http://twitter.com/La_Konfraria FACEBOOK: http://ca-es.facebook.com/people/Konfraria-Vila-Del-Pingui/11918952076 ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Obstacle
I second the name hazard. This covers obstacles and dangerous areas. Any hazard can be shown as a simple icon by any software. Specific hazards can be parsed from the values and shown with a specific icon if necessary. If a landslide blocks the road, then just break the way. Routing software will then avoid that route. If the landslide blocks part of the road then modify the way to lanes=1, maxspeed=20 for example. This should cause routers to avoid the route except for access. Best wishes, Andrew On Sat, 13 Oct 2012 23:07:49 Konfrare Albert wrote: Hi! I added the value obstacle=heap (the opposite of hole), that could be formed by fallen rocks, debris, etc... -- http://wiki.openstreetmap.org/wiki/Proposed_features/Obstacle#Tagging (the last value for the key in the table) Also I added a mention to landslides -- http://wiki.openstreetmap.org/wiki/Proposed_features/Obstacle#Other_obstacl es Thanks for suggestions and comments. Regards ALBERT 2012/10/13 Graham Jones grahamjones...@gmail.com Hazard = for things like broken barriers? Actually hazard could work for things like landslides and fallen trees too? Graham from my phone. On 13 Oct 2012 11:27, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2012/10/13 Peter Wendorff wendo...@uni-paderborn.de: Am 13.10.2012 11:28, schrieb Martin Koppenhoefer: I'd suggest some additional values: * rockfall = some rocks have fallen onto the road * guardrail_broken = there is a hole in the guard rail or in a retaining wall alongside the road (i.e. you might fall) -1 for guardrail_broken as part of obstacle. It isn't. Do we have anything for danger sources where it could fit? I agree, what might be an interesting value to add to obstacle is landslide (part of the road slipped away, mostly occuring in hilly / mountainous terrain) cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Obstacle
Thanks Andrew, I understand your position, but I want to note that my proposal focuses in pedestrians. No value is really a danger to pedestrians, but is an impediment. In the same way, the values given should not be a danger to cyclists, horse riders or drivers ... only depends on the ability that everyone has to overcome the obstacle. Regards ALBERT 2012/10/13 Andrew Errington erringt...@gmail.com I second the name hazard. This covers obstacles and dangerous areas. Any hazard can be shown as a simple icon by any software. Specific hazards can be parsed from the values and shown with a specific icon if necessary. If a landslide blocks the road, then just break the way. Routing software will then avoid that route. If the landslide blocks part of the road then modify the way to lanes=1, maxspeed=20 for example. This should cause routers to avoid the route except for access. Best wishes, Andrew On Sat, 13 Oct 2012 23:07:49 Konfrare Albert wrote: Hi! I added the value obstacle=heap (the opposite of hole), that could be formed by fallen rocks, debris, etc... -- http://wiki.openstreetmap.org/wiki/Proposed_features/Obstacle#Tagging(the last value for the key in the table) Also I added a mention to landslides -- http://wiki.openstreetmap.org/wiki/Proposed_features/Obstacle#Other_obstacl es Thanks for suggestions and comments. Regards ALBERT 2012/10/13 Graham Jones grahamjones...@gmail.com Hazard = for things like broken barriers? Actually hazard could work for things like landslides and fallen trees too? Graham from my phone. On 13 Oct 2012 11:27, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2012/10/13 Peter Wendorff wendo...@uni-paderborn.de: Am 13.10.2012 11:28, schrieb Martin Koppenhoefer: I'd suggest some additional values: * rockfall = some rocks have fallen onto the road * guardrail_broken = there is a hole in the guard rail or in a retaining wall alongside the road (i.e. you might fall) -1 for guardrail_broken as part of obstacle. It isn't. Do we have anything for danger sources where it could fit? I agree, what might be an interesting value to add to obstacle is landslide (part of the road slipped away, mostly occuring in hilly / mountainous terrain) cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging -- *KONFRARE ALBERT* La Konfraria de la Vila del Pingüí de La Palma WEB:http://www.konfraria.org TWITTER: http://twitter.com/La_Konfraria FACEBOOK: http://ca-es.facebook.com/people/Konfraria-Vila-Del-Pingui/11918952076 ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Standard for external links to location based services
I think that contact info of an amenity (allow me to group shops, restaurants, bars, and companies under that umbrella just for a minute) should be considered all of equal importance. They are amenities that stay for long time like post offices. And amenities that are changing very fast like shops and restaurants. I think OSM should concentrate on the first. OSM is not a google-like bot scanning the web to build automatically a yellow-page db. Surveying things like commercial streets are inevitably outdated quickly. I would say that amenities that cannot be found in wikipedia should be considered as commercial advertising. i just wanted to note that at least facebook and foursquare links wouldn't only apply to shops, restaurants and companies (stuff with a commercial value), but also sights and landmarks, cities, parks, playgrounds, train stations. everything that has a location ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] What is and what isn't a valid type=multipolygon relation for osm ?
Hi, In response to this change on the wiki : http://wiki.openstreetmap.org/w/index.php?title=Relation%3Amultipolygonaction=historysubmitdiff=820392oldid=797879 (which I do not completely agree with to say the least) I think it should be discussed and agreed on. Perhaps with more examples of what is valid and what isn't. Reading this : http://wiki.openstreetmap.org/wiki/Talk:Relation:multipolygon#Multipolygon_should_consist_of_polygons_rather_than_ways we can guess that it is hot topic, but allowing the wiki to change what is accepted or not every now and then isn't really something usefull I guess. What about splitting in two maybe : - what is considered valid/accepted from an OSM point of view - what is considered good practice/avoid if possible from a mapper/consumers point of view -- sly (sylvain letuffe) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] What is and what isn't a valid type=multipolygon relation for osm ?
On Oct 13, 2012 11:12 AM, sly (sylvain letuffe) li...@letuffe.org wrote: In response to this change on the wiki : http://wiki.openstreetmap.org/w/index.php?title=Relation%3Amultipolygonaction=historysubmitdiff=820392oldid=797879 I mostly agree with the added text, with the following criticism: it's a very mathematical way of saying what shouldn't need to be said in the first place. It should be obvious that a valid multipolygon relation unambiguously defines a polygonal region, and I wasn't aware it was necessary to explicitly declare all the subconditions required to achieve that result. I think the mappers who might break a multipolygon's validity probably don't have the patience to read through several rules written in math-speak. Perhaps it would be better to show counterexamples to each rule, and how to remedy each one (assuming the mapper actually knows what region the multipolygon should cover -- because if the relation is broken, software can't know). ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] What is and what isn't a valid type=multipolygon relation for osm ?
2012/10/13 David ``Smith'' vidthe...@gmail.com: I think the mappers who might break a multipolygon's validity probably don't have the patience to read through several rules written in math-speak. from my experience many are not even aware that there was a multipolygon involved in their edit when they break them. I think there are already a lot of pictures on these pages, and some of the rules added are recommendations or already inherent in other rules. E.g. * Member ways MUST have two or more nodes --- all ways must have 2 or more nodes * Exactly two unclosed ways belonging to a role, and no more should share an endpoint (eg. the most extreme nodes of a way represented by the black dot in the images). If an endpoint is shared by less than two unclosed ways, the polygon can't be closed and is ill formed. invalid example 1 If an endpoint is shared by more than two unclosed ways, it's ill formed and a closed polygon can't be reconstructed unambiguously. invalid example 2 this is saying that you can't have 2 touching inner rings with a shared inner way, but you can according to previous docs. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Narrow Bridge (was: Reconstructing «Dificult passability» proposal to «Obstacle»)
Am 13.10.2012 um 14:48 schrieb Janko Mihelić jan...@gmail.com: I don't like the lanes tag where there are no lines on the street, it misses the point. It completely misses the point! The lanes tag should only be used for lanes that are somehow marked - usually with lines. A narrow bridge is a narrow bridge: a bridge with a small width. Therefore simply use the width key. Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Narrow Bridge (was: Reconstructing «Dificult passability» proposal to «Obstacle»)
2012/10/13 Martin Vonwald (imagic) imagic@gmail.com: Am 13.10.2012 um 14:48 schrieb Janko Mihelić jan...@gmail.com: I don't like the lanes tag where there are no lines on the street, it misses the point. It completely misses the point! The lanes tag should only be used for lanes that are somehow marked - usually with lines. living in an area with a scarce tendency to mark lanes I disagree. Lanes is a useful information also when there are no marked lanes, or only partially marked lanes. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Narrow Bridge (was: Reconstructing «Dificult passability» proposal to «Obstacle»)
I can see nothing wrong with tagging a single track road as lanes =1. Single track roads are rarely the same width along their entire length, and the term will be understood by UK drivers. Usual width is, I would guess, between 2.5 and 3 metres, but this varies. Sometimes, but not often there are signed passing places. Adding width tags to every single track road will be a lit of work, whereas selecting and tagging lanes=1 is easy. The more difficult ones, which are wide enough for 2 cars to pass, these are the ones not wife enough for a centre line. These do need a width tag. On many roads the centre line is intermittent as the road width varies. These need the way to be split. Phil -- Sent from my Nokia N9 On 13/10/2012 20:12 Martin Vonwald (imagic) wrote: Am 13.10.2012 um 14:48 schrieb Janko Mihelić jan...@gmail.com: I don't like the lanes tag where there are no lines on the street, it misses the point. It completely misses the point! The lanes tag should only be used for lanes that are somehow marked - usually with lines. A narrow bridge is a narrow bridge: a bridge with a small width. Therefore simply use the width key. Martin ___ Tagging mailing list jan...@gmail.com http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - RFC - Obstacle
Would the same landslide tag be used both where part of the hill above the road had slid into the road, and where part of the road had slid downhill, leaving a hole? Also, how would you tag a point where cracks had started to appear, but the full-scale landslide hadn't happened yet? -- John F. Eldredge -- j...@jfeldredge.com Reserve your right to think, for even to think wrongly is better than not to think at all. -- Hypatia of Alexandria ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
