Re: [OSM-talk] Path rendering in the cycleway
I think it is really confusing for tags to appear on the main list of features (http://wiki.openstreetmap.org/index.php/Map_Features) which then don't get implemented by core applications and I fear that we could end up with a maze of different tags used by different applications which would be really confusing for mappers and expecially newcomers? A new person, reads up, does some cautious editing and them some features don't appear on some applications they get told, well. if you want a walking route to appear on mapnik you should tag it as , but if you want it on osmarender remember that you mustn't use yyy however on the cycle layer it is best to yyy except that free-map prefers zzz and if you want it to route on openrouteservice you should etc etc. I think there are two messages here, firstly we should be really careful about voting for new features in the core tagging list unless they are strictly necessary, and secondly when a tag does get added then we should look for rapid adoption across the main applications. So, I am not really commenting on the path tag as such (although I could because I have used it and do want it to appear on the cycle layer), it is more that I want to avoid different dialects of tagging being used to pander to different applications. The rule 'render and they will come' will become really divisive if different application demand different tagging for the same features. Regards, Peter(Ito) > -Original Message- > From: [EMAIL PROTECTED] [mailto:talk- > [EMAIL PROTECTED] On Behalf Of Christoph Eckert > Sent: 30 August 2008 21:13 > To: talk@openstreetmap.org > Subject: [Spam] Re: [OSM-talk] Path rendering in the cycleway > > Hi, > > > highway=path has never been rendered on the cyclemap. > > > > highway=footway is currently rendered, so if you want it to appear, > > then you'll need to use that tag. > > was it possible to add highway=path? > > Best regards, > > ce > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right - a proposal
On Sunday 31 August 2008 09:15:37 Frederik Ramm wrote: > We will then still need a relation that combines the road > area and the bus stop area, saying: "These are not independent of each > other; they are meant to be adjacent, and dear editor, if you move one, > please move the other as well". > Excellent point, which is why mere proximity is not meaningful enough on its own (and should rightly be portrayed geospatially only). A relation is what's needed. Maybe we can work on making the interface easier for tools - I will need to look further into what exactly the problems are before I can say more on this. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right - a proposal
(It's getting a tad difficult to keep the thread integrity. Other relevant replies from me may follow soon) On Sunday 31 August 2008 08:08:23 Gervase Markham wrote: > Hugh Barnes wrote: > > So, just to clarify, if I want apply more properties to the bus stop, is > > it like this: > > > > left:highway=bus_stop > > left:name=Park Road > > … etc? > > > > Have I missed something? > > I hadn't thought of that; I was focussing on simple features in the > common case. Does the above seem sensible, or do you have an objection > if I say a tentative "Yes"? :-) > That's why you asked for comments! :~) Well, it doesn't feel right to me - seem to be drifting quickly into the land of kludge. I personally plan to apply lots of metadata to bus stops for my routing needs. It seems more natural to just point to another node and keep its metadata there. Then we're back at relations, aren't we? Actually, when I slept on this, I realised you're just proposing a shorthand: relations lite if you will. You are using one node as a proxy for another's metadata. > > This is where I really noticed a problem, but it certainly doesn't kill > > the idea. The problem is that you're using a syntactic convention that I > > (at least) associate with XML namespaces. I've seen other tags like > > piste:foo fashioned after XML namespace prefixes, and they make sense, > > i.e. the "piste" vocabulary. > > I've picked that convention because it's already used in the project. > But I'm not wedded to it; if people would prefer an underscore, that's > fine. But it seems that underscores are part of some tag names, not > separators. > > Gerv > OK, good, and I'm not saying "don't steal XML syntax", I'm saying it could be confusing and more importantly "don't overload that convention in the same project (it may well bite you)". So, underscores etc seem OK as far as the idea goes, but you'll end up with lots of (e.g.) "left_name", "right_ref" tags which any tool or aggregator or renderer will need to parse to get all names or refs out. (NB. I'm not designing around current tools, I'm looking for easy interfaces for them). You'd potentially triple/treble the tags in common use. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right - a proposal
Hi, > someone suggested a while back on talk, that once a way is drawn, we > don't allow it's direction to be changed and for one way streets, we use > oneway=-1 if it is pointing in the wrong direction. this could be > enforced for any tags (including incline) that rely on the direction of > the way. The API currently does not look at the contents of tags. I do not think it would be wise to introduce anything relating to tag syntax/content at the API level. > this could be done at a suitable bump in API, and the command removed > from the available list, so non-compliant editors can't reverse a way There is no command for reversing a way on the API level. If you tell your editor to reverse the way, what the API sees is simply a new version of the way being uploaded; the API does neither know nor care that this version is the same as the previous version, just reversed. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right - a proposal
Frederik Ramm wrote: > My major problem with attaching significance to the direction of ways is > the ease with which that direction can and will be changed. We will > never have API support for juggling around all sorts of left/right tags > (plus oneway, incline and what-have-you), so this is the burden of the > editing software. I think it is realistic to assume that there will > always be some editors which do not properly implement any rules that > you might define regarding left/right tagging - be that due to > misunderstandings, incompleteness, or just bugs. i agree with your points frederik - left and right are somewhat subjective and not obvious. someone suggested a while back on talk, that once a way is drawn, we don't allow it's direction to be changed and for one way streets, we use oneway=-1 if it is pointing in the wrong direction. this could be enforced for any tags (including incline) that rely on the direction of the way. this would completely negate any issues of changing the direction of ways this could be done at a suitable bump in API, and the command removed from the available list, so non-compliant editors can't reverse a way > The less important the direction of a way is, the less fragile the > system becomes vis-a-vis non-complying editors, people writing robots, > and the like. I don't think we have the manpower to set up an "editor QA > task force", nor would it be in the spirit of the project to grant edit > access only to approved software (who would set the rules, who would > approve, etc.etc.). ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right - a proposal
Hi, > Why so? The direction of ways is (or can be) indicated with arrows in > editors. Yes but talking of a "left" and "right" side of a road, in everyday speech, alway means "in the direction of travel". We're used to saying "the Britons drive on the left", which is a different use of the terms than you want to establish. > Why is it a problem to have tagging which is > way-direction-dependent? We already have it with e.g. oneway. I don't like oneway that much either, but at least (ignoring "oneway=-1" for a moment) this is a situation where the situation on the ground gives a very strong indication of the way direction (much like rivers and unlike any normal road). My major problem with attaching significance to the direction of ways is the ease with which that direction can and will be changed. We will never have API support for juggling around all sorts of left/right tags (plus oneway, incline and what-have-you), so this is the burden of the editing software. I think it is realistic to assume that there will always be some editors which do not properly implement any rules that you might define regarding left/right tagging - be that due to misunderstandings, incompleteness, or just bugs. The less important the direction of a way is, the less fragile the system becomes vis-a-vis non-complying editors, people writing robots, and the like. I don't think we have the manpower to set up an "editor QA task force", nor would it be in the spirit of the project to grant edit access only to approved software (who would set the rules, who would approve, etc.etc.). > I am not suggesting that maps would ever use the terms "left" and > "right" with relation to such tagging. You are right, that would be very > confusing. But for people editing the data, when the way has a clear > direction I can't think of two better terms to use. > > What terms would you use? I would certainly not use any terms that somehow relate to the direction of the way. If I wanted some sort of informal relative positioning I would probably go with compass directions, splitting the way in those rare cases where it is shaped too funny for this to work. That being said, I tend to take the long-term view; I firmly believe that the time of linear features will be over soon and we'll have more and more areas (e.g. rivers and roads - this is starting already with large rivers and roads becoming plazas; but I'm sure it will happen for ALL rivers and ALL roads). Of course this needs good editor support to prevent one from going crazy. Phone booths and post boxes will remain point features for some time, but bus stops will (IMHO) definitely become areas. We will then still need a relation that combines the road area and the bus stop area, saying: "These are not independent of each other; they are meant to be adjacent, and dear editor, if you move one, please move the other as well". If I were you I'd map all the relevant canal details as areas even today. Because it is going to happen anyway - if you spend a lot of effort to map it as a point feature today, someone else is going to make an area of it in a few months' time. I suspect this might not seem right to you because you have a certain map representation in mind but there's no written rule that anything drawn as an area must also be rendered as one; it is obvious that in the long run renderers will need (and get) mechanisms to collapse areas into lines or points at low-detail zoom levels. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right - a proposal
Aurelien Jacobs wrote: > This makes me think to something else. What about the route relation. > A way with a bus stop on each side and a bus route which would include > only one of the stop (or the two stops but with different stop_). > Having separate nodes for each bus stop makes this much easier. I don't quite understand your objection. Are you saying there would be a problem if you had a way with a particular node which was tagged as: left:highway=bus_stop right:highway=bus_stop ? If so, the solution is easy - put another node in the way. Anyway, bus stops are rarely directly opposite each other, at least in the UK, because you don't want two buses blocking the road in the same place. Gerv ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right - a proposal
Frederik Ramm wrote: > I find that this only makes sense when what is left and what is right is > discernible *without* reference to the actual direction of the way. Why so? The direction of ways is (or can be) indicated with arrows in editors. Why is it a problem to have tagging which is way-direction-dependent? We already have it with e.g. oneway. > E.g. rivers: We have agreed to always tag them in the direction of the > flow. So when I'm there tagging something which is on one side of the > river, I *know* whether it is left or right, or vice versa, if I look up > the way in the database and it is tagged to have a towpath on the left > then I *know* where the towpath will be without even looking at the > lat/lon of the nodes. Even the general public will be able to use the > information that there is something on the "left hand side" of a river. > > On the other hand, when tagging stuff that is to the left and right of a > road or footpath, there is no way to know which direction it will have > in the database. There is no widely agreed general rule on what > constitutes the left side of a road and what the right side. I strongly > dislike using "left" and "right" in such a situation where direction is > arbitrary. I am not suggesting that maps would ever use the terms "left" and "right" with relation to such tagging. You are right, that would be very confusing. But for people editing the data, when the way has a clear direction, I can't think of two better terms to use. What terms would you use? Gerv ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right - a proposal
Robin Rattay wrote: > JOSM already does this. For "oneway" only? Or for the words "left" and "right"? Gerv ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right - a proposal
Hugh Barnes wrote: > So, just to clarify, if I want apply more properties to the bus stop, is it > like this: > > left:highway=bus_stop > left:name=Park Road > … etc? > > Have I missed something? I hadn't thought of that; I was focussing on simple features in the common case. Does the above seem sensible, or do you have an objection if I say a tentative "Yes"? :-) > This is where I really noticed a problem, but it certainly doesn't kill the > idea. The problem is that you're using a syntactic convention that I (at > least) associate with XML namespaces. I've seen other tags like piste:foo > fashioned after XML namespace prefixes, and they make sense, i.e. the "piste" > vocabulary. I've picked that convention because it's already used in the project. But I'm not wedded to it; if people would prefer an underscore, that's fine. But it seems that underscores are part of some tag names, not separators. Gerv ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Coastline not updated on the cycle map ?
Just a cosmetic question here : I've been refining the coastline around my place, south most point of Provence in S-E of France. The old coastline is still drawn on the cycle map, with the new one in dotted line. http://www.opencyclemap.org/?zoom=17&lat=43.04637&lon=5.85862&layers=B000 I was just wondering if the right coastline would be taken in account eventually. The cycle map is beautiful, BTW. Congrats on the design. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Path rendering in the cycleway
Hi, > highway=path has never been rendered on the cyclemap. > > highway=footway is currently rendered, so if you want it to appear, > then you'll need to use that tag. was it possible to add highway=path? Best regards, ce ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right - a proposal
On Sat, Aug 30, 2008 at 07:37:09PM +0200, Frederik Ramm wrote: > On the other hand, when tagging stuff that is to the left and right of a > road or footpath, there is no way to know which direction it will have > in the database. There is no widely agreed general rule on what > constitutes the left side of a road and what the right side. I strongly > dislike using "left" and "right" in such a situation where direction is I do like the "north, south, west, east" of a way. even if ways are moved somewhat they will still remain valid. You would have to move the ways a lot (turn it to be more precise) to make it point into the wrong direction. spaetz ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Path rendering in the cycleway
On Sat, Aug 30, 2008 at 2:24 PM, Elena of Valhalla <[EMAIL PROTECTED]> wrote: > Hi > > I've noticed that paths are no longer rendered on the cycle map (were > they once? i believe so, but i'm not sure) and that is unfortunate for > my abuse of the cycle map as an hicking map, but understandable :) > > however, it seems that the names remained (at zoom level 15 - 17) > > http://openstreetmap.org/?lat=45.86667&lon=8.78932&zoom=16&layers=00BFTF > > it is an highway=path with foot=designated and sac_scale=mountain > > P.S. i looked for a direct contact for cyclemap problems, but i > couldn't find any: did I miss some place? highway=path has never been rendered on the cyclemap. highway=footway is currently rendered, so if you want it to appear, then you'll need to use that tag. The cyclemap home is at http://www.opencyclemap.org/ Dave ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right - a proposal
Gervase Markham schrieb: > Editors: > Editors would need to switch "right" for "left" and vice versa in all > tags when reversing a way. Note that this requires no special knowledge > of what the prefixed tag means - that's why we have a generic mechanism. > They might also apply this switching to some special cases such as "oneway". JOSM already does this. Robin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Coastline checker / NL-tileserver / planet extracts not updated
Hi, > It will start working after the next planet dump wednesday (assuming > it dumps properly) or when the daily diff is fixed, whichever comes > first. If this helps anybody, a manually repaired version of the broken daily diff is here: http://www.remote.org/frederik/tmp/20080828-20080829.osc.gz You will lose some of the contents of the offending "note" tag if you use this, otherwise it is identical to the original diff. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right - a proposal
Hi, > Left/Right Scheme > - > > I propose that it be possible for features to be tagged using a generic > left/right scheme, with left and right being relative to the direction > of the way. I find that this only makes sense when what is left and what is right is discernible *without* reference to the actual direction of the way. E.g. rivers: We have agreed to always tag them in the direction of the flow. So when I'm there tagging something which is on one side of the river, I *know* whether it is left or right, or vice versa, if I look up the way in the database and it is tagged to have a towpath on the left then I *know* where the towpath will be without even looking at the lat/lon of the nodes. Even the general public will be able to use the information that there is something on the "left hand side" of a river. On the other hand, when tagging stuff that is to the left and right of a road or footpath, there is no way to know which direction it will have in the database. There is no widely agreed general rule on what constitutes the left side of a road and what the right side. I strongly dislike using "left" and "right" in such a situation where direction is arbitrary. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Coastline checker / NL-tileserver / planet extracts not updated
To avoid getting too many question: due to the recently discovered UTF-8 problems in the daily diffs, the daily planet dumps on hypercube won't be updated for a while. As a consequence the NL tile server and the coastline checker won't update either. It will start working after the next planet dump wednesday (assuming it dumps properly) or when the daily diff is fixed, whichever comes first. Have a nice day -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right - a proposal
On Saturday 30 August 2008, Hugh Barnes wrote: > So, just to clarify, if I want apply more properties to the bus stop, > is it like this: > > left:highway=bus_stop > left:name=Park Road > … etc? > > Have I missed something? Since this shows that we need an "entity" to put all data on which wouldn't interfere with other street features on the same node (suppose you have a shop and a bus stop at the same location), this makes me think more about something I'd call "offset node": I don't know how well this could be fit in with relations, but it would be great if renderers supported these offset nodes without showing any of the relations stuff. Offset node being defined as: the road the node belongs to, the node itself, and the location of the node being defined according to the road: situation along the road (like 0.0 being at beginning and 1.0 at end) + which side + (in cases where it could be useful) distance from the middle of the road. Now I think of it, this might be impossible with the current API, since it needs the concept of a "node" without a geographical location defined as longitude/latitude, but it needs to be an entity that can be used in relations. And since I'm brainstorming here, I just thought of it that it still might be possible with relations: add a relation to the road, and add the parameters from above, and there you have the entity. Needs good editor handling though in case you're going to split/join/inverse/move/extend/shorten ways... I think there once was mention of the idea called "offset way" as well IIRC, a long time ago, maybe we can look at this properly once. Anyway, sorry if this doesn't really look thought through, I'm just brainstorming as said. But at first sight the idea of "offset node" appeals to me. Greetings Ben ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Connecting ferry routes to roads?
Dan Karran wrote: > I fixed up the Isle of Man Steam Packet ferry route so that it goes > all the way into Douglas harbour in the Isle of Man again. While I was > at it, I connected it up with the road network so that routing > programmes could route traffic through it as well. Is this common > practice, and is there a standard way of linking them in? I've just > linked the route to a service road which is connected to the rest of > the road network. > > > Cheers, > Dan > I've been taking this approach aswell, eg: http://openstreetmap.org/?lat=-4.07891&lon=39.66457&zoom=15&layers=B00FTF I've added nodes where the coastline and the road meet and tagging them with "amenity=ferry_terminal" Rory ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Connecting ferry routes to roads?
I fixed up the Isle of Man Steam Packet ferry route so that it goes all the way into Douglas harbour in the Isle of Man again. While I was at it, I connected it up with the road network so that routing programmes could route traffic through it as well. Is this common practice, and is there a standard way of linking them in? I've just linked the route to a service road which is connected to the rest of the road network. Cheers, Dan -- Dan Karran [EMAIL PROTECTED] www.dankarran.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right - a proposal
Hugh Barnes wrote: > On Saturday 30 August 2008 22:03:33 Aurelien Jacobs wrote: > > I think this idea might evolve into something worth championing. > > Aurelian has covered a few points I was just composing :~) > > > Gervase Markham wrote: > > > 1) Create relations to associate the point with the way - one relation > > > per feature type, or perhaps a generic relation type. > > > > That would be useful. > > > > > Except that relations are heavyweight things > > > > Heavyweight things ?? I don't get what you mean here. > > > > > complicated to set up (in current editors). > > > > The same way we shouldn't map for renderers, we also shouldn't > > map for editors ! > > If editors are somewhat complicated at setting relations, > > the should be improved... > > +lots . Don't think Gervase has properly refuted the model as such here. It > should be about creating an adequate representation, no? Indeed, I haven't seen any refutation of this model. > > > 2) The generic left-right scheme proposed below. > > > > > > Left/Right Scheme > > > - > > > > > > I propose that it be possible for features to be tagged using a generic > > > left/right scheme, with left and right being relative to the direction > > > of the way. > > > > > > So you might have a road way with a node somewhere in the middle with > > > (for example): > > > left:highway=bus_stop > > > right:parking=pay_and_display > > > > > So, just to clarify, if I want apply more properties to the bus stop, is it > like this: > > left:highway=bus_stop > left:name=Park Road > … etc? > > Have I missed something? +1 This makes me think to something else. What about the route relation. A way with a bus stop on each side and a bus route which would include only one of the stop (or the two stops but with different stop_). Having separate nodes for each bus stop makes this much easier. Aurel ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Path rendering in the cycleway
Hi I've noticed that paths are no longer rendered on the cycle map (were they once? i believe so, but i'm not sure) and that is unfortunate for my abuse of the cycle map as an hicking map, but understandable :) however, it seems that the names remained (at zoom level 15 - 17) http://openstreetmap.org/?lat=45.86667&lon=8.78932&zoom=16&layers=00BFTF it is an highway=path with foot=designated and sac_scale=mountain P.S. i looked for a direct contact for cyclemap problems, but i couldn't find any: did I miss some place? -- Elena of Valhalla homepage: http://www.trueelena.org email: [EMAIL PROTECTED] ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right - a proposal
robin paulson wrote: > Richard Fairhurst wrote: > > A bus stop where you have to stand in the middle of a junction to > > catch the bus? This I have to see... > > > > > direction> > > > i think he means where there is a t-junction (say, a minor road in to a > major road), and the bus stop is on the major road, exactly opposite the > minor road. the node is shared between both roads, so the renderer may > draw the bus stop twice, once for each road Exactly. And the two road don't need to form a square angle. See: ^ | | X /| / | / | v ^ One street headed north, one headed southwest. To which street the tags applied to the the X node should refer to ? > in reality, this is unlikely to happen, because it's dangerous, and > councils would never be so stupid as to encourage large road vehicles to > stop there In reality it happens. But anyway, this don't have to be a bus_stop. The right/left tags are supposed to be useful for many other situations... And it don't seem uncommon to have something worth to map on one side of a T junction... Aurel ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right - a proposal
On Saturday 30 August 2008 22:03:33 Aurelien Jacobs wrote: I think this idea might evolve into something worth championing. Aurelian has covered a few points I was just composing :~) > Gervase Markham wrote: > > It seems to me that there are three ways we can deal with this: > > > > 0) Just place point features next to the way, with no explicit > > association apart from proximity. This is what we do now, and this lack > > of association causes problems. For linear features, you need to create > > a new, parallel way for that feature. Having to create this extra way is > > sub-optimal. > > > > One other problem with this is that it defines a set distance from the > > feature to the way. > > I don't see this as a problem. It's in fact an additional useful > information that your left/right scheme just loose. > +1 right there, maybe loosing some for the spelling :~) > > This means that, as you zoom out, the feature icon > > migrates onto the way itself as the way rendering "thickens". > > As you zoom out, the POI aren't displayed anymore, so I doubt > this can be a problem. > And if you think it's really a problem, when used along with > relations as proposed below, the renderer can treat those points > exactly as if they were part of the way with left/right tags. +1 > > > 1) Create relations to associate the point with the way - one relation > > per feature type, or perhaps a generic relation type. > > That would be useful. > > > Except that relations are heavyweight things > > Heavyweight things ?? I don't get what you mean here. > > > complicated to set up (in current editors). > > The same way we shouldn't map for renderers, we also shouldn't > map for editors ! > If editors are somewhat complicated at setting relations, > the should be improved... +lots . Don't think Gervase has properly refuted the model as such here. It should be about creating an adequate representation, no? > > > 2) The generic left-right scheme proposed below. > > > > Left/Right Scheme > > - > > > > I propose that it be possible for features to be tagged using a generic > > left/right scheme, with left and right being relative to the direction > > of the way. > > > > So you might have a road way with a node somewhere in the middle with > > (for example): > > left:highway=bus_stop > > right:parking=pay_and_display > > So, just to clarify, if I want apply more properties to the bus stop, is it like this: left:highway=bus_stop left:name=Park Road … etc? Have I missed something? Syntax: -- This is where I really noticed a problem, but it certainly doesn't kill the idea. The problem is that you're using a syntactic convention that I (at least) associate with XML namespaces. I've seen other tags like piste:foo fashioned after XML namespace prefixes, and they make sense, i.e. the "piste" vocabulary. This "scheme" is really a collection of two qualifiers which play the role of directing the descriptions away from the node [insert more stuff and get accused of being an astronaut]. Anyways, I see danger in this syntax. P.S. Richard's reply has now come through. I can't think of a use case for distance from the way, but nor can I rule it out. Still, it's a "hook" to the real world we're describing and I can't see problem with keeping such possibilities open. At the same time, not sad to see it left out. It *is* a great idea - needs development, expansion, and perhaps better arguments than the current toolset. Please point me to IRC logs or whatever if it's already been fleshed through. Slightly incoherent myself, I admit, but at least in my defence I can point to the clock :~) Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right - a proposal
Aurelien Jacobs wrote: >> One other problem with this is that it defines a set distance from the >> feature to the way. > > I don't see this as a problem. It's in fact an additional useful > information that your left/right scheme just loose. Except that there's no meaningful distance that "moorings" should be from a canal, or that "parking restrictions" should be from a road. >> This means that, as you zoom out, the feature icon >> migrates onto the way itself as the way rendering "thickens". > > As you zoom out, the POI aren't displayed anymore, so I doubt > this can be a problem. It depends what the POI is, what distance you've set the node from the road, and so on. >> Except that relations are heavyweight things > > Heavyweight things ?? I don't get what you mean here. A relation requires you to define a minimum of three things - two ways/nodes to be in relationship, and a name for the relationship they have. Therefore, however good you make the editors, there is a minimum complexity you can't get around. Given this, and given the fact that this problem is common, we should try and look for a more lightweight solution. The easier it is, the more people will use it. Typing "left:" or "right:" when adding a tag is always going to be easier than setting up a relation. >> And a way which forms part of a canal might have (for example): >> right:mooring=24h >> left:embankment > > How do you specify the distance from the middle of the way ? As Richard said, you don't. In almost all cases, it's not a meaningful number. > How do you render a node which has a right:highway=bus_stop tag and which > belongs to several ways ? (at an intersection for example) > > | > | > | > --->-+->-- There are not many bus stops in the middle of junctions. :-) This is the edgiest of edge cases, but if we ever were to find this situation coming up, where the tagging could be ambiguous, then you could just add another node to take the tag, a very short distance down the correct way. | | | --->-++>-- You can make the distance between the two nodes arbitrarily small if you like. Gerv ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [patch] correct icons for graveyards
Hello, I decided to give the correct display of religious symbols a shot. As a first step I created icons for the graveyards of the different religions and to extend the osm.xml file. The png icons were generated from higher resolutions bitmap files (sorry no svg (at least not yet)) which I can provide. Also attached is the osm file which I use for testing. The bounding box to render the file is ll = (9.833, 49.780, 9.846, 49.790). The resulting png is too big for this list and can be seen at http://www.petschge.de/image.png Patrick "Petschge" Kilian graveyards.tgz Description: application/compressed-tar --- osm-template.xml 2008-08-26 11:46:25.0 +0200 +++ osm-template-extended.xml 2008-08-28 09:51:43.0 +0200 @@ -363,10 +363,57 @@ - + + 5 [landuse] = 'cemetery' - + + + + + 5 + [landuse] = 'cemetery' and [religion] = 'bahai' + + + + 5 + [landuse] = 'cemetery' and [religion] = 'buddhist' + + + + 5 + [landuse] = 'cemetery' and [religion] = 'christian' + + + + 5 + [landuse] = 'cemetery' and [religion] = 'hindu' + + + + 5 + [landuse] = 'cemetery' and [religion] = 'jewish' + + + + 5 + [landuse] = 'cemetery' and [religion] = 'muslim' + + + + 5 + [landuse] = 'cemetery' and [religion] = 'pastafarian' + + + + 5 + [landuse] = 'cemetery' and [religion] = 'sikh' + + + + 5 + [landuse] = 'cemetery' and [religion] = 'taoist' + ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right - a proposal
Richard Fairhurst wrote: > Aurelien Jacobs wrote: > > > The same way we shouldn't map for renderers, we also shouldn't > > map for editors ! > > If editors are somewhat complicated at setting relations, > > the should be improved... > > Great - looking forward to your patch! Please use K&R brace style but > with function declarations braced on the same line, and indent with > hard tab width of 4, kthx. This would fit my style except for the hard tab, but unfortunately I already have far too much commitments with other FOSS projects... > > How do you render a node which has a right:highway=bus_stop tag and > > which > > belongs to several ways ? (at an intersection for example) > > A bus stop where you have to stand in the middle of a junction to > catch the bus? This I have to see... You mean, like this one ? http://www.openstreetmap.org/?lat=49.05918&lon=6.57923&zoom=17&layers=0B0FTF There are many other similar examples. Aurel ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right - a proposal
Richard Fairhurst wrote: > A bus stop where you have to stand in the middle of a junction to > catch the bus? This I have to see... > > direction> i think he means where there is a t-junction (say, a minor road in to a major road), and the bus stop is on the major road, exactly opposite the minor road. the node is shared between both roads, so the renderer may draw the bus stop twice, once for each road in reality, this is unlikely to happen, because it's dangerous, and councils would never be so stupid as to encourage large road vehicles to stop there ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right - a proposal
Aurelien Jacobs wrote: > The same way we shouldn't map for renderers, we also shouldn't > map for editors ! > If editors are somewhat complicated at setting relations, > the should be improved... Great - looking forward to your patch! Please use K&R brace style but with function declarations braced on the same line, and indent with hard tab width of 4, kthx. >> 2) The generic left-right scheme proposed below. >> >> Left/Right Scheme >> - >> >> I propose that it be possible for features to be tagged using a >> generic >> left/right scheme, with left and right being relative to the >> direction >> of the way. >> >> So you might have a road way with a node somewhere in the middle with >> (for example): >> left:highway=bus_stop >> right:parking=pay_and_display >> >> And a way which forms part of a canal might have (for example): >> right:mooring=24h >> left:embankment > > How do you specify the distance from the middle of the way ? I don't see that you need to. It is by definition at the edge of the way (canal, road, whatever). If there's a width tag set on the way, that gives you the information. If not, well, surely that's the first priority. > How do you render a node which has a right:highway=bus_stop tag and > which > belongs to several ways ? (at an intersection for example) A bus stop where you have to stand in the middle of a junction to catch the bus? This I have to see... > [auto-reversing] > The problem with this is that as long as an editor without this > feature > is still in use somewhere, it will get us into trouble. (and some > people > tend to use old versions for a long time) No, that needn't be a problem. The offline editors will all have to be upgraded to cope with API 0.6 anyway, with access from old versions denied, so this feature could just be introduced at the same time. And obviously with Potlatch upgrading isn't an issue. Gerv, I think it's a good plan. cheers Richard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right - a proposal
Gervase Markham wrote: > [This post contains other people's ideas and points; thanks to all of them.] > > It seems from the Left and Right discussion that there are many features > we wish to map which are associated with the "side" of a way. This is a > consequence of the fact that we are using things with zero width (ways) > to represent real-world features which have a width (e.g. roads and canals). > > Examples include bus stops and shelters, parking restrictions and taxi > ranks on roads, or mooring information, embankments and turning points > on canals. Note that some of these are point features and others are > length features. > > The key commonality is that *these are all things that would not be > there if the way was not there*. This definition is what excludes phone > boxes, post boxes etc. from needing this sort of association. (House > numbers seem to me to be an edge case; let's leave that for now.) > > It seems to me that there are three ways we can deal with this: > > 0) Just place point features next to the way, with no explicit > association apart from proximity. This is what we do now, and this lack > of association causes problems. For linear features, you need to create > a new, parallel way for that feature. Having to create this extra way is > sub-optimal. > > One other problem with this is that it defines a set distance from the > feature to the way. I don't see this as a problem. It's in fact an additional useful information that your left/right scheme just loose. > This means that, as you zoom out, the feature icon > migrates onto the way itself as the way rendering "thickens". As you zoom out, the POI aren't displayed anymore, so I doubt this can be a problem. And if you think it's really a problem, when used along with relations as proposed below, the renderer can treat those points exactly as if they were part of the way with left/right tags. > 1) Create relations to associate the point with the way - one relation > per feature type, or perhaps a generic relation type. That would be useful. > Except that relations are heavyweight things Heavyweight things ?? I don't get what you mean here. > complicated to set up (in current editors). The same way we shouldn't map for renderers, we also shouldn't map for editors ! If editors are somewhat complicated at setting relations, the should be improved... > 2) The generic left-right scheme proposed below. > > Left/Right Scheme > - > > I propose that it be possible for features to be tagged using a generic > left/right scheme, with left and right being relative to the direction > of the way. > > So you might have a road way with a node somewhere in the middle with > (for example): > left:highway=bus_stop > right:parking=pay_and_display > > And a way which forms part of a canal might have (for example): > right:mooring=24h > left:embankment How do you specify the distance from the middle of the way ? > Changes Needed > -- > > Renderers: > Renderers would need to place the icon for the feature offset at right > angles to the way, a feature-dependent distance, with a default for most > features of "just far enough that the icon appears alongside the way", > which is probably zoom-dependent. (This is a good thing - avoids the > problems given above.) After moving the location, they render the > feature as normal, as if a node were there. Renderers already have code > for choosing a good location for icons for area features such as parking > lots, so it'll be similar to that. How do you render a node which has a right:highway=bus_stop tag and which belongs to several ways ? (at an intersection for example) | | | --->-+->-- Here, the intersection node (+) is tagged with right:highway=bus_stop. It's quit obvious for us what it means, but a renderer may have hard time with it. Note that the solution of placing a node next to the way along with a relation allows the exact same rendering as what you propose, without the above mentioned ambiguity. > Editors: > Editors would need to switch "right" for "left" and vice versa in all > tags when reversing a way. Note that this requires no special knowledge > of what the prefixed tag means - that's why we have a generic mechanism. > They might also apply this switching to some special cases such as "oneway". The problem with this is that as long as an editor without this feature is still in use somewhere, it will get us into trouble. (and some people tend to use old versions for a long time) Aurel ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Combined amenities?
There exists many cases where amenity is not given. For example here in Norway, post-offices are getting outsourced to supermarked. And even a bank has started a similar concept. Likewise, I guess on smaller places, pharmacy could have a similar concept So what about a tag additional_services/additional_amenities=bank;post_office;pharmacy? Or: amenity:additional=bank;post_office;pharmacy ? This is sort of a generalization of atm=yes on amenity=bank, although I'm not sure we should touch that one. -- - Vegard Engen, member of the first RFC1149 implementation team. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right - a proposal
On Sat, Aug 30, 2008 at 12:26:49PM +0100, Gervase Markham wrote: What do people think? As I've already expressed in other threads: IMO that's the way to go. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right - a proposal
Gervase Markham wrote: > What do people think? i think it's fantastic - it addresses most of the problems that have come up the last few days on this subject i'm sure in the future we'll find some edge cases that don't fit, but i think this deserves at least some experimenting to see how it works in reality. are there dev copies of the main map where this could be trialled? i recall earlier this week someone made a comment about not allowing ways to be reversed. i think that would be tidier than expecting the editor to change all the tags along a way (imagine all the bus stops, phone boxes, post boxes, etc. on even a 5km road in a city) if it were to be reversed. as he suggested, the 'oneway=-1' can overcome the problem of the way pointing the wrong direction as an aside, we could use this to start rendering pavements as well (say zoom 15 - 17 only). by default, it draws them in at some offset, dependent on the road type/width. if there's a 'left:pavement=none', etc. then it would miss it ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Left and Right - a proposal
[This post contains other people's ideas and points; thanks to all of them.] It seems from the Left and Right discussion that there are many features we wish to map which are associated with the "side" of a way. This is a consequence of the fact that we are using things with zero width (ways) to represent real-world features which have a width (e.g. roads and canals). Examples include bus stops and shelters, parking restrictions and taxi ranks on roads, or mooring information, embankments and turning points on canals. Note that some of these are point features and others are length features. The key commonality is that *these are all things that would not be there if the way was not there*. This definition is what excludes phone boxes, post boxes etc. from needing this sort of association. (House numbers seem to me to be an edge case; let's leave that for now.) It seems to me that there are three ways we can deal with this: 0) Just place point features next to the way, with no explicit association apart from proximity. This is what we do now, and this lack of association causes problems. For linear features, you need to create a new, parallel way for that feature. Having to create this extra way is sub-optimal. One other problem with this is that it defines a set distance from the feature to the way. This means that, as you zoom out, the feature icon migrates onto the way itself as the way rendering "thickens". 1) Create relations to associate the point with the way - one relation per feature type, or perhaps a generic relation type. Except that relations are heavyweight things, complicated to set up (in current editors). And you still have the rendering problems described above. 2) The generic left-right scheme proposed below. Left/Right Scheme - I propose that it be possible for features to be tagged using a generic left/right scheme, with left and right being relative to the direction of the way. So you might have a road way with a node somewhere in the middle with (for example): left:highway=bus_stop right:parking=pay_and_display And a way which forms part of a canal might have (for example): right:mooring=24h left:embankment A key point here is that the logical place to put the information is not exactly the same as the logical place to put the icon representing it. We can put the information on the way, but renderers can put the icon next to the way (see below). This finesses the argument about whether we are mapping the place where the bus stops or the sign that tells us it's a bus stop. Any feature proposal would be able to say "uses the left/right scheme" to opt in to this generic mechanism. Changes Needed -- Renderers: Renderers would need to place the icon for the feature offset at right angles to the way, a feature-dependent distance, with a default for most features of "just far enough that the icon appears alongside the way", which is probably zoom-dependent. (This is a good thing - avoids the problems given above.) After moving the location, they render the feature as normal, as if a node were there. Renderers already have code for choosing a good location for icons for area features such as parking lots, so it'll be similar to that. Editors: Editors would need to switch "right" for "left" and vice versa in all tags when reversing a way. Note that this requires no special knowledge of what the prefixed tag means - that's why we have a generic mechanism. They might also apply this switching to some special cases such as "oneway". What do people think? Gerv ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] amenity=cabin
Hi, > In lack of a defined amenity=cabin, I'll start using something like > this scheme as my own placeholder. that's great. BTW: There already are some proposals for similar things. I'm curious if we will somehow merge them one day: http://wiki.openstreetmap.org/index.php/Proposed_features/Shelter http://wiki.openstreetmap.org/index.php/Proposed_features/Alpine_Hut Cheers, ce ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] amenity=cabin
In lack of a defined amenity=cabin, I'll start using something like this scheme as my own placeholder. Please take this as a start of a discussion.. amenity=cabin - for a cabin in the mountain/nature (mountain_cabin should be redundant - is it in the mountains, it will be a mountain_cabin :-) access=private (private=yes?) is for when you tag random, privately-owned cabins. They are useful to have on a map, especially if you actually use it for orientation when you're there :) We should tag if there's possibilities for food and lodging. Self-service? In Norway, we have a lot of tourist-association run cabins where you can just go get the key beforehand, use it, and then pay after usage. Some are simple, with no food stored, some have a self-service kitchen. This, I'd like to tag in a way. But gonna think a bit more, as I haven't marked any yet :) But I know people in the local tourist association, so things may happen that way... lodging=yes/no/private (the last one, I intend to use to signify that it's possible to lodge, but it's owned by someone you have to ask first. Could be the tourist association. operator-tag is definitely useful. Then you can find all cabins belonging to a certain tourist association. cafe=yes, restaurant=yes ? A lot of cabins are open for serving daytime. Some only weekends or other occations...(easter holiday?) Thus, we could need cafe_opening_hours and restaurant_opening_hours ? Please improve this one :) But those with only serving of food/drinks, we could just as well tag as amenity=restaurant, amenity=cafe etc. Well. Back to tagging yesterdays mountain-trip. -- - Vegard Engen, member of the first RFC1149 implementation team. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
