Re: [OSM-talk] Left and Right - a proposal
On Mon, Oct 13, 2008 at 08:57:01PM +0100, Gervase Markham wrote: > Stephen Gower wrote: > > I see from later posts that you also suggest using this scheme for cycle/bus > > lanes to indicate which side of the road they should be rendered. > > Did I? I thought it was you - it certainly came up in the discussion. > > > To derive a travelling direction from the Left/Right terms a routing > > engine is usually going to need to know the local "rule of the road" - > > do we just leave this to the routing engine to factor in (needing to > > work out where in the world it is), or is there another simple solution > > I've missed. > > Surely the routing engine needs to know this already, for example to > take you up or down the correct ramp at a motorway interchange? I'd have thought there's already an implied oneway=yes for motorway ramps, so the routing engine just follows that. s ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right - a proposal
Stephen Gower wrote: > I see from later posts that you also suggest using this scheme for cycle/bus > lanes to indicate which side of the road they should be rendered. Did I? > This > highlighted to me a general problem with the scheme. For rendering the > scheme is perfect - drawing a bus stop or a cycle lane on one side of a road > is exactly what is needed. However, for routing you need to know which > direction a bike may travel along a cycle lane, or which direction buses > from a stop will be heading. To derive a travelling direction from the > Left/Right terms a routing engine is usually going to need to know the local > "rule of the road" - do we just leave this to the routing engine to factor > in (needing to work out where in the world it is), or is there another > simple solution I've missed. Surely the routing engine needs to know this already, for example to take you up or down the correct ramp at a motorway interchange? Gerv ___ 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: > > 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 I see from later posts that you also suggest using this scheme for cycle/bus lanes to indicate which side of the road they should be rendered. This highlighted to me a general problem with the scheme. For rendering the scheme is perfect - drawing a bus stop or a cycle lane on one side of a road is exactly what is needed. However, for routing you need to know which direction a bike may travel along a cycle lane, or which direction buses from a stop will be heading. To derive a travelling direction from the Left/Right terms a routing engine is usually going to need to know the local "rule of the road" - do we just leave this to the routing engine to factor in (needing to work out where in the world it is), or is there another simple solution I've missed. Sorry if this has been covered already - I'm 400 posts behind in talk/legal combined. s ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right - a proposal
Andy Allan wrote: > That's the main problem. You are now making a proposal that > distinguishes nodes at the end of a way from non-terminating nodes - > since only those in the middle can inherit a sense of direction from > the way. True, but not a problem. There's no "rule" about how many nodes in a way, so if you want to do this, you can add another one near the end. This is no different to adding it 5m to the left of the end, it's just that it's now associated with the way in a "relations lite" sort of way (as Hugh described it). > I'm also with frederick on the left/right thing (most bus stops are > 'on the left', as far as I'm concerned - even when they are on > opposite sides of the road) and the other objection with compass > directions is valid for U-shaped roads. We need to decide whether these things are ways or roads. If they are roads, they need to have a thickness and be represented as such. (Then we can tag the two sides differently.) If they are ways, we need to stop thinking of road-related terminology when we talk about their properties. Pick one :-) > The latitude and longitude of point objects should be as accurate as > we can make them, and if they need some form of logical linking with > something then we can logically link them without creating bogus > latlongs :-) What is the lat and long of a parking restriction on one side of a road? Gerv ___ 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 PM, Gervase Markham <[EMAIL PROTECTED]> wrote: > So you might have a road way with a node somewhere in the middle That's the main problem. You are now making a proposal that distinguishes nodes at the end of a way from non-terminating nodes - since only those in the middle can inherit a sense of direction from the way. If I've split a road in two because it's 5 metres wide then becomes 10 metres wide after the bus stop, and the ways point in different directions, then the node can't be a bus stop - and that's hardly intuitive. >X< I'm also with frederick on the left/right thing (most bus stops are 'on the left', as far as I'm concerned - even when they are on opposite sides of the road) and the other objection with compass directions is valid for U-shaped roads. The latitude and longitude of point objects should be as accurate as we can make them, and if they need some form of logical linking with something then we can logically link them without creating bogus latlongs :-) Oh, and bus stops are positions on the pavement that the bus stops beside, not just level with a particular catseye on the centerline of the road :-) Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right - a proposal
On Sun, Aug 31, 2008 at 12:39 PM, Ben Laenen <[EMAIL PROTECTED]> wrote: > On Sunday 31 August 2008, Frederik Ramm wrote: >> Hi, >> >> Ben Laenen wrote: >> > This could be very annoying if you're making a way for an area and >> > at the end suddenly remembers that you should have done it >> > clockwise and not anticlockwise. >> >> Direction is irrelevant for areas. (Coastline currently being an >> exception.) > > Then that's also one of those things that change without it being > mentioned somewhere. > http://wiki.openstreetmap.org/index.php/Tag:natural=water still says: > > "Direction > This is important for rendering. The direction of the way should be > chosen such that land is on the left side and water on the right side > of the way (when viewing in the direction of the way arrows). If you > regard this as tracing around a lake, then the way(s) should be running > clockwise. It's easy enough to reverse the direction of a way in > Potlatch, JOSM, and all good editors." Fixed. "Direction Since all renderers (hopefully) ensure that you haven't made a polygon the size of the planet, it doesn't matter which way round the way goes. " ;-) Cheers, Andy ___ 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, Frederik Ramm wrote: > Hi, > > Ben Laenen wrote: > > This could be very annoying if you're making a way for an area and > > at the end suddenly remembers that you should have done it > > clockwise and not anticlockwise. > > Direction is irrelevant for areas. (Coastline currently being an > exception.) Then that's also one of those things that change without it being mentioned somewhere. http://wiki.openstreetmap.org/index.php/Tag:natural=water still says: "Direction This is important for rendering. The direction of the way should be chosen such that land is on the left side and water on the right side of the way (when viewing in the direction of the way arrows). If you regard this as tracing around a lake, then the way(s) should be running clockwise. It's easy enough to reverse the direction of a way in Potlatch, JOSM, and all good editors." I have no idea whether it matters or not for renderers, since I always tag with the feature on the right (i.e. clockwise). Ben ___ 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 9:41 PM, spaetz <[EMAIL PROTECTED]> wrote: > [...] > 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. for a point feature this would be fine, but for a linear feature it may be a problem on a road that turns, e.g. /--- | \--> here the left side is on the south, east and north of the road -- 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
Hi, Ben Laenen wrote: > This could be very annoying if you're making a way for an area and at > the end suddenly remembers that you should have done it clockwise and > not anticlockwise. Direction is irrelevant for areas. (Coastline currently being an exception.) Bye Frederik ___ 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, robin paulson wrote: > 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 This could be very annoying if you're making a way for an area and at the end suddenly remembers that you should have done it clockwise and not anticlockwise. Frankly, I don't get why these left-right tags are such an issue. it should be just basic knowledge for the mappers that they should be very careful when reversing a way. It's equally important not to move nodes in a way around that are tagged for example, or to remember to join ways at junctions etc. But we don't try to work around these issues by not allowing nodes to move. This is all very basic understanding, but still somehow not everyone seems to know this... Why don't we have some small test to make sure mappers at least know about these fundamental issues before we let them do any mapping? Just a dozen questions or so which brings them to the attention of some easy pit-falls. Ben ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right - a proposal
Gervase Markham schrieb:
> Robin Rattay wrote:
>> JOSM already does this.
>
> For "oneway" only? Or for the words "left" and "right"?
Both. And also "forward"/"backward". This works for both key and value
and no matter if as prefix ("left:*") or suffix ("*:left"). It's not
very flexible, so any changes/extensions need to be hard coded (such as
other word pairs or different separators), but that's one of the things
I'm working on, when I find the time. Also missing is changing of
relation roles.
Robin
___
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
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] 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] 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
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] 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
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
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
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
