Re: [OSM-talk] [tagging] Feature Proposal - RFC - h==highway
Renaud MICHEL wrote: > Le lundi 30 mars 2009 à 05:46, PAA a écrit : >> Request for comments on creating the key:h and making it synonymous with >> key:highway. > > That's just ridiculous. > Don't start duplicating tags with the same meaning. No it's not. It's called convenience. > And once you start with tag names, you could go on with values and > replace "primary" with "p", "secondary" with "s" and so on. Then I would like to propose 1 for primary, 2 for secondary, and so on. trunk roads would be 0 and highways -1. Add .5 for _link. Can we implement this tomorrow? Maarten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Allowed ? GSoC'09
Hi, Nick Black wrote: > Just to be clear the "Personal Use" parts of the CloudMade T&Cs refer to the > site contents and use of the website - cloudmade.com, rather than any of the > APIs and web service. You, and everyone else are welcome to use CloudMade's > APIs, web services and the documentation provided on the site in personal, > public or business uses. Sorry for misrepresenting that then! I read about the "personal use" in the Ts and Cs and thought "well it cannot probably mean that they don't want business users to look at their web page so it must mean the tiles/services/APIs". It would be great if you could link to > http://developers.cloudmade.com/projects/web-maps-lite/terms > http://www.cloudmade.com/products/libraries_apis/terms_of_use from > http://cloudmade.com/terms_conditions because the latter is the one that you find when you google for "cloudmade terms and conditions"! Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Propoasl - RFC - Gym
Am Montag 30 März 2009 schrieb Adrian Moisey: > Hi > > >> > Someone else started a proposal for a gym, I need it in my area. So > >> > I'm finishing it off: > >> > http://wiki.openstreetmap.org/wiki/Proposed_features/Gym > >> > >> Why not simply use: > >> > >> leisure=sports_centre > >> sport=work_out (or gymnastics or ...) > >> > >> Regards, ULFL > > > > wh have a key for sports facilites, so why not sport=gym? > > There are no tags for 'sport=work-out' or 'sport=gym'. > Also, a Gym isn't a sports_centre, its an actual building designed for > Gymning. > right. so you have to create a new one. as most gyms are not part of a sports centre, tagging leisure=sports_centre for every gym would be wrong. a gym is used for physical workout, so sport is better suited than amenity. sport=gym (only this, whithout leisure=...) says everything needed to basically describe and categorize this facilities, so it should be better than amenity=gym. signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - h==highway
Le lundi 30 mars 2009 à 05:46, PAA a écrit : > Request for comments on creating the key:h and making it synonymous with > key:highway. That's just ridiculous. Don't start duplicating tags with the same meaning. > As i understand things, this has four huge benefits: > -reduce data entry time when editing OSM (e.g. 6/7ths less characters to > type) JSOM already helps you there, when adding a new highway tag I only have top type "hig" and JSOM adds "hway", same for values. If three letters is still too much for you you can make a JOSM plugin that will translate h into highway. > -reduce data entry errors when editing OSM (current obvious errors from > tagwatch europe: highlight, hightway, highwaY, highwat, higwhway, and the > champion, higway, with 1478 entries) That's what predefined settings are made for, you click on a menu and select "primary road". > -reduce OSM data storage space (over 6M highways just from > http://tagwatch.stoecker.eu/Europe/En/tags.html; simple naive estimate > 6M*6 bytes=36MBytes uncompressed data reduction) > -reduce bandwidth for transfers to/from OSM planet files are already compressed, you won't gain much by replacing meaningful tags by codeletters. And once you start with tag names, you could go on with values and replace "primary" with "p", "secondary" with "s" and so on. -- Renaud Michel ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Propoasl - RFC - Gym
Hi >> > Someone else started a proposal for a gym, I need it in my area. So I'm >> > finishing it off: >> > http://wiki.openstreetmap.org/wiki/Proposed_features/Gym >> >> Why not simply use: >> >> leisure=sports_centre >> sport=work_out (or gymnastics or ...) >> >> Regards, ULFL >> > wh have a key for sports facilites, so why not sport=gym? There are no tags for 'sport=work-out' or 'sport=gym'. Also, a Gym isn't a sports_centre, its an actual building designed for Gymning. http://en.wikipedia.org/wiki/Gym Adrian ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] Feature Proposal - RFC - h==highway
Request for comments on creating the key:h and making it synonymous with key:highway. As i understand things, this has four huge benefits: -reduce data entry time when editing OSM (e.g. 6/7ths less characters to type) -reduce data entry errors when editing OSM (current obvious errors from tagwatch europe: highlight, hightway, highwaY, highwat, higwhway, and the champion, higway, with 1478 entries) -reduce OSM data storage space (over 6M highways just from http://tagwatch.stoecker.eu/Europe/En/tags.html; simple naive estimate 6M*6 bytes=36MBytes uncompressed data reduction) -reduce bandwidth for transfers to/from OSM What do you think? Cheers, P ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging dangerous areas
On Mar 29, 2009, at 10:42 PM, NL wrote: > Is it unsafe to park a bike/car there? We should mark areas of high bicycle theft, but we'd need a map to display it. -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - Twitter: Russ_OSM - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Tagging dangerous areas
This isn't a formal proposal so much as presenting an idea. When i was booking a hotel recently for travel, a friend who knew the area advised me that it was a dangerous neighborhood. That allowed me to find a different hotel in a safer area and possibly save myself some unpleasantness. This kind of word-of-mouth knowledge is the kind of thing open projects can excel at providing. The problem, of course, is a metric for something as subjective as "dangerous neighborhood". It it dangerous at 12:00 or at 01:00? Is it unsafe to park a bike/car there? Would some tagging system to indicate dangerous area be desirable, and how would it best be implemented? Cheers P ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] Feature Proposal - RFC - shop=pet
Hi It seems that a way to tag shops that sell pets and pet supplies is desirable and the clear way to do that is with shop=pet. There are some sub-tags in the proposal, too. Please review it at http://wiki.openstreetmap.org/wiki/Proposed_features/pet_shop and share your thoughts and suggestions. -P ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Allowed ? GSoC'09
Rajan + list, This one is from written with my CloudMade keyboard ;-) Just to be clear the "Personal Use" parts of the CloudMade T&Cs refer to the site contents and use of the website - cloudmade.com, rather than any of the APIs and web service. You, and everyone else are welcome to use CloudMade's APIs, web services and the documentation provided on the site in personal, public or business uses. Which CloudMade libraries are you particularly interested in using? The Ruby, Python and Java libs are all open source (L-GPL) and we're happy to support anyone who'd like to develop libraries in other languages. Libraries T&Cs (L-GPL) - http://www.cloudmade.com/products/libraries_apis/terms_of_use Website T&Cs - http://cloudmade.com/terms_conditions Web Maps Lite (Jacascript library) T&Cs - http://developers.cloudmade.com/projects/web-maps-lite/terms Hope this clarifies things for you. Nick On Sat, Mar 28, 2009 at 7:13 AM, Frederik Ramm wrote: > Hi, > > rajan vaish wrote: > > Hi,I am working on my proposal for GSoC'09 right now and for the routing > > implementation tasks ,I intend to use Libraries/APIs of CloudMade ( > > http://developers.cloudmade.com/ ) which works on OSM as well.Am I > allowed > > to use the same ? > > I don't see why not. > > It is true that CloudMade say you may use their site "solely for your > personal use", whereas Google say any software you produce must be > licensed under an OSI approved license (i.e. you cannot produce software > licensed as "only for personal use"). > > But you can simply pass on this restriction to the users of your > software: The software you make is free for use/inspection/modification > by anybody as per the OSI compliant license you choose, but if people > then use your software to access the CloudMade site then they may only > do so for their personal use. > > As you correctly point out, the situation is similar to GSoc students > writing software that interacts with Google Maps. > > Whether or not the OSM project accepts and endorses a proposal for a > GSoC project that will only work using the services of CloudMade (which > are outside the control of the OSM project) is of course another matter, > but I guess if it is something seriously cool then nobody will ask many > questions. > > I believe that CloudMade used to have a developer sponsorship programme > of their own where they handed out grants for the development of > OSM-related software, so that might be another avenue for you to follow > up (but you should really ask them directly as it has been a while since > this was last mentioned). > > Bye > Frederik > > -- > Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > -- -- Nick Black twitter.com/nick_b ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] What is amenity=food_outlets in map features?
Someone added amenity=food_outlets to the map features and even after reading the comment "An area with several food outlets" I'm quite unsure what this could be. Is this a collection of several amenity=fast_food or a kind of vending_machine or ...? In the US we have a thing called "food court". There is a central common seating area, and around the edge there are places selling food, typically fast food type. Each has a counter that would almost join the next one's counter - think of a mcdonald's where only the counter part and behind of the restaurant exists. There may also be some kiosk/stands that are self-contained in the middle. These are typically places you don't want to go and don't want to buy food at, but are convenient. They are found in shopping malls, airports and some train stations. There are also areas in airports with multiple restaurants near each other and individual seating. To be a food court (in my view), there has to be a shared seating area among the restaurtants, with the restaurants not having seating. From the US point of view I would tag the entire common area 'amenity=food_court', and tag some of the individual restaurants 'amenity=fast_food'. Some of the places sell coffee and pastries and are more properly amenity=cafe. The public can't go in the individual restaurants in a food court. http://commons.wikimedia.org/wiki/File:Union_station_dc_food_court.jpg http://pdphoto.org/PictureDetail.php?pg=8061 http://www.yelp.com/biz_photos/qoHkEmKspps3ZCwor3xLug?select=TNc3qREb5TJ_tr1AicIatg http://www.flickr.com/photos/flaneur/409846061/in/set-72157594581857903/ http://www.flickr.com/photos/mr_t_in_dc/2085996881/in/pool-canon-eos-450d pgpk3bYXuOC0T.pgp Description: PGP signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] What is amenity=food_outlets in map features?
I'm guessing a food court. That's the term I've always heard, anyway. http://en.wikipedia.org/wiki/Food_court Stephen 2009/3/29 Ulf Lamping : > Hi! > > Someone added amenity=food_outlets to the map features and even after > reading the comment "An area with several food outlets" I'm quite unsure > what this could be. > > Is this a collection of several amenity=fast_food or a kind of > vending_machine or ...? > > Can someone explain this a bit? > > Regards, ULFL > > P.S: A photo would also be nice and may explain it even better ... ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Propoasl - RFC - Gym
Am Sonntag 29 März 2009 schrieb Ulf Lamping: > Adrian Moisey schrieb: > > Hi > > > > Someone else started a proposal for a gym, I need it in my area. So I'm > > finishing it off: > > http://wiki.openstreetmap.org/wiki/Proposed_features/Gym > > Why not simply use: > > leisure=sports_centre > sport=work_out (or gymnastics or ...) > > Regards, ULFL > wh have a key for sports facilites, so why not sport=gym? signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] turn restriction relations: via
Nic Roets wrote: > I implemented "only_*" as something that's disallowed i.e. a restriction. > The "obligation" interpretation only came later. > > Perhaps we can specify that complex vias may not have "only_*"'s and require > people to implement their ideas with no_'s ? While I don't see a problem with this requirement in theory, I doubt that the idea would be a very popular, partly because the traffic signs (rendering hints) and the relation semantics have been merged by using that strange only_/no_-prefix solution. >> Despite via splitting not being necessary for proper relation handling, >> I still think that "a relation using via nodes will always contain all >> nodes as via nodes one would travel along" is essential. Otherwise, >> there would inevitably be some problems: >> If, in your example, the via information was represented by via nodes on >> S instead of via way(s), that restriction would also forbid turning left >> from A onto S, following S without turning into B, then using other >> roads to return to the double carriageway and following B back to the >> restriction's "to" part. This is obviously not intended. > > I think we should require that complex vias must always include all the ways > that are traveled. Does "way" mean way primitives here, as opposed to nodes? Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Propoasl - RFC - Gym
Adrian Moisey schrieb: > Hi > > Someone else started a proposal for a gym, I need it in my area. So I'm > finishing it off: > http://wiki.openstreetmap.org/wiki/Proposed_features/Gym Why not simply use: leisure=sports_centre sport=work_out (or gymnastics or ...) Regards, ULFL ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
talk@openstreetmap.org
Whoops! Yes - cyclists are supposed to give way to pedestrians and horse riders. Fingers faster than brain - sorry! Mike Harris -Original Message- From: Gregory Williams [mailto:gregory.willi...@purplegeodesoftware.co.uk] Sent: 29 March 2009 15:09 To: talk@openstreetmap.org Subject: Re: [OSM-talk] highway=cycle&footway > -Original Message- > From: talk-boun...@openstreetmap.org [mailto:talk- > boun...@openstreetmap.org] On Behalf Of Mike Harris > Sent: 28 March 2009 15:05 > To: 'Chris Hill'; 'Stephen Hope'; talk@openstreetmap.org > Subject: Re: [OSM-talk] highway=cycle&footway > > By the way - in England and Wales, cyclists are normally allowed to use > public bridleways (but the highways authority has no obligation to > maintain the way to a standard that makes it possible to cycle) unless > explicitly forbidden by a very localised regulation. Cyclists must also > give way to cyclists and horse riders. [Snip] I guess you meant that cyclists are meant to give way to pedestrians and horse riders. Cyclists having to give way to other cyclists would lead to deadlock :-) Gregory ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] turn restriction relations: via
Hi Tobias & Marcus On Sun, Mar 29, 2009 at 8:06 PM, Tobias Knerr wrote: > > > I'm not exactly sure what the semantics of an "only_*" with several via > members would be, though. Should it require that you use at least one > via member or every via member? I implemented "only_*" as something that's disallowed i.e. a restriction. The "obligation" interpretation only came later. Perhaps we can specify that complex vias may not have "only_*"'s and require people to implement their ideas with no_'s ? > > > Despite via splitting not being necessary for proper relation handling, > I still think that "a relation using via nodes will always contain all > nodes as via nodes one would travel along" is essential. Otherwise, > there would inevitably be some problems: > If, in your example, the via information was represented by via nodes on > S instead of via way(s), that restriction would also forbid turning left > from A onto S, following S without turning into B, then using other > roads to return to the double carriageway and following B back to the > restriction's "to" part. This is obviously not intended. > > Tobias Knerr > I think we should require that complex vias must always include all the ways that are traveled. >One question, >does anyone have an implementation of turn-restrictions that >have "via" as more then an optional specifier for a list of nodes >to limit the effect of the restriction to only intersections where >"from" and "to" meet at one of the "via"-nodes? >(either "via" being a start- , end- or middle- node of "to" and "from")? Not me. Regards, Nic ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] Feature Propoasl - RFC - Gym
Hi Someone else started a proposal for a gym, I need it in my area. So I'm finishing it off: http://wiki.openstreetmap.org/wiki/Proposed_features/Gym Please RFC. Adrian ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] turn restriction relations: via
Nic Roets schrieb: > Based on this description I can't see why we should require that via ways > like S should be split into optimal ways, i.e. at D and E. The program will > run faster, but the mapper is ultimately responsible from spotting > ambigueties and splitting ways so that they don't occur. Avoiding ambiguous restrictions is indeed the main reason for the assumptions I suggested. However, splitting the 'via' ways isn't really necessary for that purpose. That I thought it was is probably a consequence of thinking in the box of my own implementation (which creates ordered "forbidden sequences" to represent restrictions). Apparently, ignoring order solves any problems associated with that, though I still have to try whether that works (I guess it will.) I'm not exactly sure what the semantics of an "only_*" with several via members would be, though. Should it require that you use at least one via member or every via member? Despite via splitting not being necessary for proper relation handling, I still think that "a relation using via nodes will always contain all nodes as via nodes one would travel along" is essential. Otherwise, there would inevitably be some problems: If, in your example, the via information was represented by via nodes on S instead of via way(s), that restriction would also forbid turning left from A onto S, following S without turning into B, then using other roads to return to the double carriageway and following B back to the restriction's "to" part. This is obviously not intended. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tag template "status" section
Cool, thats step 1. .. thanks for fixing. For the 2nd part, should it be standard for all proposed tags to have draft/proposed/voting/post-vote cleanup. also on this template?? For the 3rd part, i think noting the following sections for the template would be helpful to users. And perhaps the "voting" section should also be included?? so then people know that the key/value was actually voted on... and what the results were.. (so if the status is 'rejected' then people would be able to learn why instantly. and the suggested alternates would be shown. ** ==How to Map == ==Extended Usage == ==Examples == (chart with) Picture/Description TagsMapnik Osmarender ==See Also== ==Voting == *** Cheers, Sam ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tag template "status" section
I do not quite understand the structure. Yet I would like to know more about how it works. Is this a semantic mediawiki -feature? I am curious as to how to add more information to such a table. (Using either a wiki-category or this table -structure to document what tags are supported by what of the major applications.) Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] turn restriction relations: via
On Sun, Mar 29, 2009 at 1:50 PM, Tobias Knerr wrote: > I've been implementing turn restriction support for some (still > unpublished) software recently -- and, of course, have also added every > restriction I could find to OSM. While the concept of "restriction" > relations generally works well, there is one thing in particular I'm not > really happy with: the effort that is required to handle via members. One question, does anyone have an implementation of turn-restrictions that have "via" as more then an optional specifier for a list of nodes to limit the effect of the restriction to only intersections where "from" and "to" meet at one of the "via"-nodes? (either "via" being a start- , end- or middle- node of "to" and "from")? We may have specified something that is just too complex to be implemented and debugged in every or the routers we have. PS: I found the idea of Nic to be easy to implement when he mentioned it before. It took me less then 2 days to convert a well documented and structured Dijkstra -implementation to work as he described and observed no visible performance loss so far. (You may try for yourself by using Traveling Salesman and calculating the same route while having either "MultiTargedDijkstraRouter" or "TurnRestrictedMultiTargedDijkstraRouter" in the options-dialog. No restart is required after changing the option.) Marcus http://travelingsales.sourceforge.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tag template "status" section
On Sunday 29 March 2009 17:17:53 Sam Vekemans wrote: > Hi, > From the wiki description, it seems that all tags .. keys/values > should have the basic template. > The last part of the template box is "status" and just shows up as > 'undefined' .. > How do i change that status, so it could be more meaningful? > > http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dworks You mean something like what I made from it just now? ;) -- m.v.g., Cartinus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tag template "status" section
I analysed the http://wiki.openstreetmap.org/index.php?title=Template:ValueDescription&action=edit and found that adding a "status=Approved|" to the parameter-list does what you want. Marcus On Sun, Mar 29, 2009 at 4:17 PM, Sam Vekemans wrote: > Hi, > From the wiki description, it seems that all tags .. keys/values > should have the basic template. > The last part of the template box is "status" and just shows up as > 'undefined' .. > How do i change that status, so it could be more meaningful? > > http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dworks > > Thanks, > Sam > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] tag template "status" section
Hi, >From the wiki description, it seems that all tags .. keys/values should have the basic template. The last part of the template box is "status" and just shows up as 'undefined' .. How do i change that status, so it could be more meaningful? http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dworks Thanks, Sam ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] turn restriction relations: via
Let me first give a bit of an introduction to the algorithms for other
readers on the list. At first glance Dijkstra finds the shortest route to
any node n from a given node a, but exactly how (from the North, South etc)
node n was reached is not specified. So turning restrictions cannot be
handled.
One solution is to look at http://en.wikipedia.org/wiki/Line_graph but it
does not really handle complicated restrictions like this one:
A single carriage way S crosses a double carriage way consisting of ways A
and B at nodes D and E. Traveling down A you are not allowed to use S to
make a u-turn into B.
A simple solution to this problem is not to think of Dijkstra vertices as
OSM nodes, but to think of them as state-machine states, for example "I'm at
D traveling backwards along S". And the above mentioned restriction would
require having than 2 times as many possible states as there are segments.
That's all the ussual states ("I'm at ... traveling forwards / backwards
along ... without having triggered any restrictions") as well as states like
"I'm at D traveling backwards along S after triggering restriction R". This
last state will mean that :
S is in R's via
If W1, W2,...,Wk,S is the list of ways that I traveled along then there
exists a i such that Wi=R.from and Wi+1,...,Wk are all in R.via.
I guess there are even a few real world examples where we will need states
where more than one restriction was triggered. Like a small service way
leaving the abovementioned junction from E that you may not enter coming
from A. It means the code will not be very fast, but given how rare these
things are, speed's not an issue.
Based on this description I can't see why we should require that via ways
like S should be split into optimal ways, i.e. at D and E. The program will
run faster, but the mapper is ultimately responsible from spotting
ambigueties and splitting ways so that they don't occur.
Regards,
Nic
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
talk@openstreetmap.org
> -Original Message- > From: talk-boun...@openstreetmap.org [mailto:talk- > boun...@openstreetmap.org] On Behalf Of Mike Harris > Sent: 28 March 2009 15:05 > To: 'Chris Hill'; 'Stephen Hope'; talk@openstreetmap.org > Subject: Re: [OSM-talk] highway=cycle&footway > > By the way - in England and Wales, cyclists are normally allowed to use > public bridleways (but the highways authority has no obligation to > maintain the way to a standard that makes it possible to cycle) unless > explicitly forbidden by a very localised regulation. Cyclists must also > give way to cyclists and horse riders. [Snip] I guess you meant that cyclists are meant to give way to pedestrians and horse riders. Cyclists having to give way to other cyclists would lead to deadlock :-) Gregory ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Cycle map: trunk-roads in mountains
2009/3/29 Dave Stubbs : > Here's the solution: get the local authority to add a cycle lane, tag > the road as having a cycle lane. Then the road will be blindingly > obvious. The roads in that area tend to have an "all-purpose additional lane" on both sides, comprising a gravel surface (with about 10mm stones) which is used by cyclists, pedestrians, goods vehicles (i.e. mules), and as an overtaking lane. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Cycle map: trunk-roads in mountains
2009/3/29 Iván Sánchez Ortega : > El Domingo, 29 de Marzo de 2009, Dave Stubbs escribió: >> 2009/3/29 OJ W : >> > Can you spot it? >> > >> > http://www.openstreetmap.org/?lat=31.4122&lon=-7.3859&zoom=12&layers=00B0 >> >FTF >> >> That's what you get for not building epic bridges, tunnels, and other >> contour defying structures :-P > > No, that's what you get for colouring trunks green instead of red as > it should be. Ha! Trunk roads should be green. I have the stone tablets to prove it. :-) Here's the solution: get the local authority to add a cycle lane, tag the road as having a cycle lane. Then the road will be blindingly obvious. Anyway, having actually been down that road in a manically driven minibus I can honestly say I wouldn't recommend cycling down it... but then I wouldn't really want to cycle/drive in morroco at all. Dave ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] turn restriction relations: via
I've been implementing turn restriction support for some (still unpublished) software recently -- and, of course, have also added every restriction I could find to OSM. While the concept of "restriction" relations generally works well, there is one thing in particular I'm not really happy with: the effort that is required to handle via members. Can/should I assume * that there will always be exactly one finite sequence per restriction that includes all via members? * that via ways will be split to connect with each other and with from/to only at start/end nodes (this is recommended for from/to, but not mentioned anywhere for via ways)? * that a relation using via nodes will always contain all nodes as via nodes one would travel along * that a restriction will include either via ways or via nodes, but not both? Making these assumptions wouldn't prevent the description of any real-life-situation. It would, however, make evaluating restrictions (as well as understanding the effects of a restriction as a mapper) more easy. I also wondered whether it is really necessary to allow both (multiple) nodes and ways as via members, as each possibility alone can perfectly handle all situations and there is no significant difference in mapping effort either. So why don't we restrict the via role to ways (except maybe for the popular single-via-node case)? Tobias Knerr PS: I'm perfectly aware that there is no authoritative documentation, that I can implement and map whatever I want etc. I'm just interested in other people's opinions. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Cycle map: trunk-roads in mountains
El Domingo, 29 de Marzo de 2009, Dave Stubbs escribió: > 2009/3/29 OJ W : > > Can you spot it? > > > > http://www.openstreetmap.org/?lat=31.4122&lon=-7.3859&zoom=12&layers=00B0 > >FTF > > That's what you get for not building epic bridges, tunnels, and other > contour defying structures :-P No, that's what you get for colouring trunks green instead of red as it should be. I'll just file this one next to the "don't paint motorways the same colour as rivers" one. Cheers, -- -- Iván Sánchez Ortega ¿Que sentido tiene correr cuando estamos en la carretera equivocada? signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Cycle map: trunk-roads in mountains
2009/3/29 OJ W : > Can you spot it? > > http://www.openstreetmap.org/?lat=31.4122&lon=-7.3859&zoom=12&layers=00B0FTF LOL, not at all - it needs more than a slight colour adjustment... -- Łukasz [DeeJay1] Jernaś ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Cycle map: trunk-roads in mountains
2009/3/29 OJ W : > Can you spot it? > > http://www.openstreetmap.org/?lat=31.4122&lon=-7.3859&zoom=12&layers=00B0FTF > That's what you get for not building epic bridges, tunnels, and other contour defying structures :-P Dave ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] Feature Proposal - Voting - Miniature Golf
Hi Please go vote for the Miniature golf tag: http://wiki.openstreetmap.org/wiki/Proposed_features/Miniature_Golf Adrian ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Cycle map: trunk-roads in mountains
Can you spot it? http://www.openstreetmap.org/?lat=31.4122&lon=-7.3859&zoom=12&layers=00B0FTF ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] What is amenity=food_outlets in map features?
2009/3/29 Ulf Lamping : > Hi! > > Someone added amenity=food_outlets to the map features and even after > reading the comment "An area with several food outlets" I'm quite unsure > what this could be. > > Is this a collection of several amenity=fast_food or a kind of > vending_machine or ...? > > Can someone explain this a bit? > > Regards, ULFL > > P.S: A photo would also be nice and may explain it even better ... > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > I'm guess its a an area with several different resterants and or fast food outlets together, Say a McDonalds, Burger King, Frankey and Benny's, etc etc. usually found near a cinema, or in one corner of a large Shopping Centre like Bluewater, or even China Town in central London (at a pinch). Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] What is amenity=food_outlets in map features?
Hi! Someone added amenity=food_outlets to the map features and even after reading the comment "An area with several food outlets" I'm quite unsure what this could be. Is this a collection of several amenity=fast_food or a kind of vending_machine or ...? Can someone explain this a bit? Regards, ULFL P.S: A photo would also be nice and may explain it even better ... ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
