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
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?
Gervase Markham wrote: A nearly-approved proposal for a canal-side object has been objected to by someone who thinks that the tag should be on a node which is part of the canal rather than next to it, with left/right indicated as part of the tag key name. http://wiki.openstreetmap.org/index.php/Proposed_features/Mooring So what's the conclusion here? Am I in a position where half of the project will vote against if I propose the left:mooring=24h method, and the other half will vote against if I propose the add-a-separate-way method? Gerv ___ 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
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 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
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
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 KR 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.05918lon=6.57923zoom=17layers=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
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
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
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... sticks hand out, gets flattened by car approaching from other 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
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_number). 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
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
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
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
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
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
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
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
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_number). 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
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
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, 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
(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
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?
On Wed, Aug 27, 2008 at 12:13 AM, Robin Paulson [EMAIL PROTECTED] wrote: 2008/8/26 Mark Williams [EMAIL PROTECTED]: Is 'mapping for renderers' any worse than 'mapping for routers'? both are bad i think Step back from the we're going to use it for routing busses approach a moment; a fair few users may wish to print a map, so the renderers need to do this right. I will prefer to see the bus-stops pass on the sat-nav map as reference as I drive by them. I might like warning of busses likelihood of stopping. My main driver on this is that they are roadside features, not highway features. As I said, like pubs, postoffices, etc. This is the real world, mapping what's on the ground, bus stops are not like mini-roundabouts or traffic lights. well, it's a representation of the real world, and idealised, yet imperfect one at that i'm not sure why they're roadside features, rather than highway features. the bus stops *on* the highway (which includes the path, as we discussed earlier). at no point does it leave the highway the *sign* is on the roadside. we're not mapping signs. maps and signs do the same thing, but in different ways - they contain information about a mapworthy feature, but each are not mapworthy themselves. we're not mapping signs What it comes down to is this: a bus stop is not the same thing as where the bus stops. Although they're obviously related. We have half the people in this discussion trying to map the bus stop, and half of them trying to map where the bus stops, and half happy to do either really... so yes, it has a sign (and possibly a shelter), but it's not _just_ a sign: it's a destination in its own right and about the only sign I can think of right now that people queue up behind. It's also very important where it is, unlike most signs which are just telling you something about somewhere else. Whether a bus stop is a feature of the road, or a feature of the pavement is entirely a matter of perspective... If I happen to be standing at a bus stop I really don't care which road the bus will come down to pick me up: I'm at the bus stop so it should be fairly obvious. And the only important thing is how to get to the bus stop, because if I'm not in the right place the bus won't stop even if I wave at it frantically (OK, this bit varies from place to place... usually inversely proportional to the number of buses :-( ) On the other hand if I'm on the bus, then the exact position on the pavement of the bus stop where I get off isn't important. I just want to know when the bus has got to the right part of the route and I should hit the button to get off. The bus will stop in the right place on it's own (wow, magic). Any arguments re the pavement being part of the road anyway are ultimately flawed... ie: post boxes phone boxes, cycle parking and even ATMs would be way nodes under this definition and whether or not they should be doesn't really matter, as I don't think anyone is adding them as such. We can't represent both properties properly with a single node. In either case we lose something, or else make reconstructing it difficult. So I'd suggest this: map both, or whichever you happen to be interested in, and someone think up a way of binding them together nicely with a relation for the topologists. Personally I just stick a node where the bus stop actually is. That's what is most useful for me at the present time. Dave ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right?
David Ebling wrote: Discussions about whether the node can easily be understood by routers to be connected to the way seem spurious to me - surely you should just connect them into a route relation? Agreed. Relations should be used more for bus routes. There are lots of busses that drive past bus stops on their route cause they don't stop there. Having a bus stop on the way or not doesn't tell you if a bus will actually stop there. With relations it should be much simpiler to tie bus stops to ways. Rory ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right?
Date: Wed, 27 Aug 2008 09:41:03 +0100 From: Dave Stubbs [EMAIL PROTECTED] Subject: Re: [OSM-talk] Left and Right? To: Robin Paulson [EMAIL PROTECTED] Cc: OSM Talk talk@openstreetmap.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=UTF-8 On Wed, Aug 27, 2008 at 12:13 AM, Robin Paulson [EMAIL PROTECTED] wrote: 2008/8/26 Mark Williams [EMAIL PROTECTED]: Is 'mapping for renderers' any worse than 'mapping for routers'? both are bad i think Step back from the we're going to use it for routing busses approach a moment; a fair few users may wish to print a map, so the renderers need to do this right. I will prefer to see the bus-stops pass on the sat- nav map as reference as I drive by them. I might like warning of busses likelihood of stopping. My main driver on this is that they are roadside features, not highway features. As I said, like pubs, postoffices, etc. This is the real world, mapping what's on the ground, bus stops are not like mini-roundabouts or traffic lights. well, it's a representation of the real world, and idealised, yet imperfect one at that i'm not sure why they're roadside features, rather than highway features. the bus stops *on* the highway (which includes the path, as we discussed earlier). at no point does it leave the highway the *sign* is on the roadside. we're not mapping signs. maps and signs do the same thing, but in different ways - they contain information about a mapworthy feature, but each are not mapworthy themselves. we're not mapping signs What it comes down to is this: a bus stop is not the same thing as where the bus stops. Although they're obviously related. We have half the people in this discussion trying to map the bus stop, and half of them trying to map where the bus stops, and half happy to do either really... so yes, it has a sign (and possibly a shelter), but it's not _just_ a sign: it's a destination in its own right and about the only sign I can think of right now that people queue up behind. It's also very important where it is, unlike most signs which are just telling you something about somewhere else. Whether a bus stop is a feature of the road, or a feature of the pavement is entirely a matter of perspective... If I happen to be standing at a bus stop I really don't care which road the bus will come down to pick me up: I'm at the bus stop so it should be fairly obvious. And the only important thing is how to get to the bus stop, because if I'm not in the right place the bus won't stop even if I wave at it frantically (OK, this bit varies from place to place... usually inversely proportional to the number of buses :-( ) On the other hand if I'm on the bus, then the exact position on the pavement of the bus stop where I get off isn't important. I just want to know when the bus has got to the right part of the route and I should hit the button to get off. The bus will stop in the right place on it's own (wow, magic). Any arguments re the pavement being part of the road anyway are ultimately flawed... ie: post boxes phone boxes, cycle parking and even ATMs would be way nodes under this definition and whether or not they should be doesn't really matter, as I don't think anyone is adding them as such. We can't represent both properties properly with a single node. In either case we lose something, or else make reconstructing it difficult. So I'd suggest this: map both, or whichever you happen to be interested in, and someone think up a way of binding them together nicely with a relation for the topologists. Personally I just stick a node where the bus stop actually is. That's what is most useful for me at the present time. With regard to the Dave's important distinction between the bus stop (where passengers wait) and the actual position on the highway where the bus stops, let's not forget trams and trains where in some cases there may be one location where people wait which has tracks on both sides and vehicles stop either side of the Stop Point. This begs the question about how we map platforms and quays for trains/trams/metro and ferry which are actually areas features beside one or more ways. Trains also can have sub-platforms where there is platform 4 which for some services is split into 3A and 3B on in the case of my local station into 3A, 3B and 3C. My vote is to map where the fixed infrastructure is (the platform, pole, shelter) as point or area feature in the correct physical location beside the road but possibly software will need to deal with both models for the time being. If the separate node approach is used then the assumption should be that the software will associate it with the nearest Way at the nearest point and that the way should not be more than X meters from an appropriate way. We should note however that we are drifting from a network mode (of links and nodes) into a full 2D or even 3D
Re: [OSM-talk] Left and Right?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Karl Newman wrote: On Mon, Aug 25, 2008 at 3:34 PM, Mark Williams [EMAIL PROTECTED]wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 robin paulson wrote: Rory McCann wrote: Gervase Markham wrote: What's current tagging best practice with things which are to the left or the right of a way (e.g. bus stops)? A nearly-approved proposal for a canal-side object has been objected to by someone who thinks that the tag should be on a node which is part of the canal rather than next to it, with left/right indicated as part of the tag key name. http://wiki.openstreetmap.org/index.php/Proposed_features/Mooring Do we do that for any other tags? Do we have highway:left=bus_stop? Gerv Personally I add the node to left of the way, not as part of the way. I believe the OSM theory is that the way represents the middle of the road. So things like mini-roundabounds and traffic lights are part of the way (ie road), but a bus stop is off to the side of the road. the problem with this is that 'bus stop' (and canal mooring, etc,) implies a place where the bus stops, which is on the road. the fact the bus shelter, or sign, or bench, is some distance off to the side of the road shouldn't matter - the bus itself stops on the road, so the node imo should be part of the way if the bus stop is off to the side of the road, i.e. not connected to it, then the bus can't physically get to it, which seems very wrong or, consider from the pedestrian's point-of-view: it is assumed for all roads except motorways and where explicitly stated, that there is foot=yes access. in which case, the footpath/sidewalk/pavement is therefore part of the way which represents the road; we don't draw a separate way off to one side, running parallel. the bus stop must be on the footpath for the pedestrian to be able to walk up to it, so again it must be part of the way this problem is i think muddled by the fact we represent an area (a road) with a linear object (a way), which theoretically has zero width, so the natural step from this is to say: 'the way represents the centre of the road, and the bus stop/canal mooring is not in the centre of the road, it's at the side of the road, so I'll put it to one side of the way' as for placing the node to one side of the way in order to get the icon to be placed correctly, this sounds a lot like 'tagging for the renderer' I disagree with this view. Do you tag post boxes as way nodes? Shops? Telephones? No... So why bus stops? They aren't in the road. They are sites on the side, like all of the above. It makes no sense to tag them as way objects. I have seen the arguments about knowing which way they belong to; IMHO this is specious, no bus company works by looking at OSM to see where to route their buses, but a map user may well want to know just where the bus stop is - Anyone looking at a map of where they are who doesn't know which side they drive, is in trouble. The same goes for any navigation software. It really isn't hard to link from bus-stops as points to nearby ways - check out all the routing apps, not many need a hard node ID or way ID to commence from / get to - they find a nearby way from a lat/long. If Gosmore can do it, why not any other app? It just introduces a whole load of hassle working out which bus stop goes in which direction, sticking it in the middle of the road. It looks stupid in the renderers for a very good reason. My 2p, but I don't want this to look like everyone thinks that way nodes are good.. Mark If you happen to know exactly which nodes (which are not part of the way) are your start and end points, then routers can deal with that. If you want to know which bus stops you will pass while traveling along a way, that's a much more difficult problem if the nodes are not somehow topologically associated with the way. It's a more serious problem with house numbers because the data volume is so much higher (many more house numbers than bus stops), which makes it even more important to associate a number with a way (and not by using the street name--that's not topological, is subject to typos and is difficult to validate automatically). Karl Sorry? I don't have to specify a node for several of the routers, just a coordinate. Therefore I don't have to happen to know which node to go from. Equally, if I'm using a map to navigate I can see which POI's I pass, else (if I care) I can get a list by post-processing the route to see what's nearby - though I don't see that I'm likely to [care]. If the bus stops are tied to a bus route or a way by a relation, then it's trivial; especially compared to the difficulty of working out which bus stop to walk to when two are in the middle of the road, 200 yards apart. Is 'mapping for renderers' any worse than 'mapping for routers'? Step back from the we're going to use it for routing busses approach a
Re: [OSM-talk] Left and Right?
IMO, comparing bus stops to post boxes or phone booths is a bit specious. Of course the bus stop shelter, or sign, is off the road/street. Or else they would cause some problems to motorists ! But they are in fact closely tied to that road, as the buses that stop there drive on that road, not aside it. OTOH, when you want to use a post box or a phone booth, you normally don't just stop on the road nearby, you have to park somewhere and walk to it. Thus they are really off-road features, unrelated to the road. -Message d'origine- De : [EMAIL PROTECTED] [mailto:talk- [EMAIL PROTECTED] De la part de Mark Williams Envoyé : mardi 26 août 2008 00:34 À : robin paulson Cc : OSM Talk Objet : Re: [OSM-talk] Left and Right? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 robin paulson wrote: Rory McCann wrote: Gervase Markham wrote: What's current tagging best practice with things which are to the left or the right of a way (e.g. bus stops)? A nearly-approved proposal for a canal-side object has been objected to by someone who thinks that the tag should be on a node which is part of the canal rather than next to it, with left/right indicated as part of the tag key name. http://wiki.openstreetmap.org/index.php/Proposed_features/Mooring Do we do that for any other tags? Do we have highway:left=bus_stop? Gerv Personally I add the node to left of the way, not as part of the way. I believe the OSM theory is that the way represents the middle of the road. So things like mini-roundabounds and traffic lights are part of the way (ie road), but a bus stop is off to the side of the road. the problem with this is that 'bus stop' (and canal mooring, etc,) implies a place where the bus stops, which is on the road. the fact the bus shelter, or sign, or bench, is some distance off to the side of the road shouldn't matter - the bus itself stops on the road, so the node imo should be part of the way if the bus stop is off to the side of the road, i.e. not connected to it, then the bus can't physically get to it, which seems very wrong or, consider from the pedestrian's point-of-view: it is assumed for all roads except motorways and where explicitly stated, that there is foot=yes access. in which case, the footpath/sidewalk/pavement is therefore part of the way which represents the road; we don't draw a separate way off to one side, running parallel. the bus stop must be on the footpath for the pedestrian to be able to walk up to it, so again it must be part of the way this problem is i think muddled by the fact we represent an area (a road) with a linear object (a way), which theoretically has zero width, so the natural step from this is to say: 'the way represents the centre of the road, and the bus stop/canal mooring is not in the centre of the road, it's at the side of the road, so I'll put it to one side of the way' as for placing the node to one side of the way in order to get the icon to be placed correctly, this sounds a lot like 'tagging for the renderer' I disagree with this view. Do you tag post boxes as way nodes? Shops? Telephones? No... So why bus stops? They aren't in the road. They are sites on the side, like all of the above. It makes no sense to tag them as way objects. I have seen the arguments about knowing which way they belong to; IMHO this is specious, no bus company works by looking at OSM to see where to route their buses, but a map user may well want to know just where the bus stop is - Anyone looking at a map of where they are who doesn't know which side they drive, is in trouble. The same goes for any navigation software. It really isn't hard to link from bus-stops as points to nearby ways - check out all the routing apps, not many need a hard node ID or way ID to commence from / get to - they find a nearby way from a lat/long. If Gosmore can do it, why not any other app? It just introduces a whole load of hassle working out which bus stop goes in which direction, sticking it in the middle of the road. It looks stupid in the renderers for a very good reason. My 2p, but I don't want this to look like everyone thinks that way nodes are good.. Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIszNhJfMmcSPNh94RAkPOAJ9ALC4KpvGSUlTVxbVcNbW2jRuPFwCfcfAZ DIsY6girm+HvwS6kYgf/8V8= =dM1X -END PGP SIGNATURE- ___ 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?
On Tue, Aug 26, 2008 at 1:30 AM, Andy Robinson (blackadder-lists) [EMAIL PROTECTED] wrote: Chris Morley wrote: Sent: 24 August 2008 8:51 PM Cc: talk@openstreetmap.org Subject: Re: [OSM-talk] Left and Right? Karl Newman wrote: On Sun, Aug 24, 2008 at 9:53 AM, Rory McCann [EMAIL PROTECTED] Gervase Markham wrote: What's current tagging best practice with things which are to the left or the right of a way (e.g. bus stops)? A nearly-approved proposal for a canal-side object has been objected to by someone who thinks that the tag should be on a node which is part of the canal rather than next to it, with left/right indicated as part of the tag key name. http://wiki.openstreetmap.org/index.php/Proposed_features/Mooring Do we do that for any other tags? Do we have highway:left=bus_stop? Personally I add the node to left of the way, not as part of the way. I believe the OSM theory is that the way represents the middle of the road. So things like mini-roundabounds and traffic lights are part of the way (ie road), but a bus stop is off to the side of the road. A similar thinking is obvious in the Karlsruhe House Address Scheme ( http://wiki.openstreetmap.org/index.php/Proposed_features/House_numbers/Ka rlsruhe_Schema), since the buildings that are numbered are not physically in the middle of the road, they are added as nodes to the left or right of the way. Yes, and that method is not topological, which makes it very difficult to associate that feature (bus stop, house number, whatever) with the way that it's actually located on. It should either be a node that is part of the way, or have a relation to connect the node with the way. I think that the topological aspect of OSM's data structure is important and well worth maintaining in nodes and ways as well as in relations. We are not just drawing pictures, we are also recording relationships. This is why the representation of a mooring - a stretch of canal where boats tie up - as a separate way not connected to the canal seems wrong to me. In this case and with bus stops or house numbers, if you convey which side it is on by having a separate node or way displaced an arbitary short distance to one side, then you lose this side information at lower scales, when it may still be important to a user. With a topological description it is still available. I totally agree on this approach, ie the node is part of the way, but only for features which have direct relationship to each other. This for a bus stop of a mooring I make the node part of the way because these are features that apply and have a relationship with the way itself. For house numbers however I make a separate node. I do this for two reasons, the first is that the house has no relevance to the way it is alongside. We think of house What? Of course it has relevance. The number means nothing without the street. Houses don't have GUIDs. It has to be associated with it's street if you ever want to look it up by address. numbers being part of a street but in reality they aren't, they are references for buildings. The second reason is that if we were to add nodes for every house on both sides of the street to every way we would soon find out ways totally unmanageable. As a further reason, houses are normally connected to the street with a driveway/footpath. In a fully featured map you would draw these in eventually. Its these that make the true relationship between building and street. There's no need to add house numbers at every node in a way (except for weird cases where the house numbers are not sequential). Put the numbers at intervals and let interpolation take care of the rest. Always try top keep things simple. Keep like with like and don't try to over engineer the result and generally the result will be more than sufficient. The Karlsruhe schema is an example of what you get without any engineering at all--just look how many different scenarios are presented on that page! The common method used by other systems which store house numbers (for example, TIGER) is to associate a house number with the way and indicate if it's on the left or right. This is done only at certain points, and linear interpolation takes care of the rest. This is also what's expected by existing navigational systems (e.g., Garmin GPS) and if we ever hope to be able to use our house number data there, it needs to be able to be transformed into that format. The Karlsruhe schema does not allow for that without a huge amount of work and a lot of uncertainty about the result. I'm not opposed to putting the house number on a separate node, but it needs to be topologically connected with the way using a relation in that case, because in real life, the house address *is* associated with the street it's on. Karl
Re: [OSM-talk] Left and Right?
2008/8/26 Mark Williams [EMAIL PROTECTED]: I disagree with this view. Do you tag post boxes as way nodes? Shops? Telephones? No... So why bus stops? They aren't in the road. They are sites on the side, like all of the above. It makes no sense to tag them as way objects. a good point, and as i said, this is complicated a lot by representing areas as ways i.e. roads. no, i dont' suggest we change, but whatever we do to get round this will be a botch or compromise however, i will disagree that bus stops are off to one side. the bus stops on the road, not on the pavement. the positioning of the sign/shelter is irrelevant, the bus always stops on the road, regardless. and there are bus stops here where it says 'bus stop' painted on the road, not on a sign at all. as to the others, no i place them off to one side, as i do telephones. as for shops: well i was thinking about this on friday while walking round the university, and considering routing from one building to another, entirely on campus footpaths - it occurred to me that we may need an 'entrance' tag for buildings, otherwise where do we join the end of the path to? paths must lead to buildings, otherwise we can't route to them. so, in the case of shops, i would suggest a short footway from the highway to the shop entrance should po boxes be way nodes? i haven't thought about it previously, but to be consistent (something that's lacking in osm), we probably should. it needs more thinking about, but in a holistic way, not the haphazard way these things are done at the moment - something i'm guilty of myself, by the way... I have seen the arguments about knowing which way they belong to; IMHO this is specious, no bus company works by looking at OSM to see where to why not? there are non-profits and other orgs that have started using osm maps instead of their own/paid for 3rd party services. why shouldn't a bus company use them as well? i'd be very keen on my local council not doling out thousands a year to whoever they pay for their maps route their buses, but a map user may well want to know just where the bus stop is - Anyone looking at a map of where they are who doesn't know which side they drive, is in trouble. The same goes for any navigation software. people are including bus routes in osm data, so clearly they are used for more than people just getting to the stop It really isn't hard to link from bus-stops as points to nearby ways - check out all the routing apps, not many need a hard node ID or way ID to commence from / get to - they find a nearby way from a lat/long. If Gosmore can do it, why not any other app? i'll put this in the category of 'work around'. it's not any decent solution, but more corner-cutting. and it causes problems where for instance there is a stream, or railway track, that makes a destination physically close, but impractical/dangerous to get to. to solve that problem, we then have to come up with another solution, and it quickly becomes quite messy It just introduces a whole load of hassle working out which bus stop goes in which direction, sticking it in the middle of the road. It looks stupid in the renderers for a very good reason. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right?
2008/8/26 Mark Williams [EMAIL PROTECTED]: Is 'mapping for renderers' any worse than 'mapping for routers'? both are bad i think Step back from the we're going to use it for routing busses approach a moment; a fair few users may wish to print a map, so the renderers need to do this right. I will prefer to see the bus-stops pass on the sat-nav map as reference as I drive by them. I might like warning of busses likelihood of stopping. My main driver on this is that they are roadside features, not highway features. As I said, like pubs, postoffices, etc. This is the real world, mapping what's on the ground, bus stops are not like mini-roundabouts or traffic lights. well, it's a representation of the real world, and idealised, yet imperfect one at that i'm not sure why they're roadside features, rather than highway features. the bus stops *on* the highway (which includes the path, as we discussed earlier). at no point does it leave the highway the *sign* is on the roadside. we're not mapping signs. maps and signs do the same thing, but in different ways - they contain information about a mapworthy feature, but each are not mapworthy themselves. we're not mapping signs Finally, yes I think the above is right for house numbers as well. My house is next to the way; not even on the implied footpath, it's an off-road feature. I think this is true of most... absolutely. ideally, there would be a drive from the road to the parking area, then a path from that to the door ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right?
2008/8/27 Karl Newman [EMAIL PROTECTED]: What? Of course it has relevance. The number means nothing without the street. Houses don't have GUIDs. It has to be associated with it's street if you ever want to look it up by address. i'm not sure what a guid is, i assume it's 'globally unique identification'? in which case, yes they do - it's the property deed number. and it may sound pedantic, but we should really talk about the *property address*, not the *house address* - the first includes driveway, paths, car parks, garden, etc, etc. and maybe does not have a building there at all; the second makes all sorts of assumptions which will only be true in a small number of addresses this is going to be very relevant in the near future - land information new zealand are more than likely going to give us permission to include their property info database (the entire country, probably around a million ways defining property boundaries) in osm, so we're going to need a tagging scheme that accounts for it, and ties together the deed number and the street address numbers being part of a street but in reality they aren't, they are references for buildings. The second reason is that if we were to add nodes for every house on both sides of the street to every way we would soon find out ways totally unmanageable. As a further reason, houses are normally connected to the street with a driveway/footpath. In a fully featured map you would draw these in eventually. Its these that make the true relationship between building and street. spot on. There's no need to add house numbers at every node in a way (except for weird cases where the house numbers are not sequential). Put the numbers at intervals and let interpolation take care of the rest. Always try top keep things simple. Keep like with like and don't try to over engineer the result and generally the result will be more than sufficient. The Karlsruhe schema is an example of what you get without any engineering at all--just look how many different scenarios are presented on that page! The common method used by other systems which store house numbers (for example, TIGER) is to associate a house number with the way and indicate if it's on the left or right. This is done only at certain points, and linear interpolation takes care of the rest. This is also what's expected by existing navigational systems (e.g., Garmin GPS) and if we ever hope to be able to use our house number data there, it needs to be able to be transformed into that format. The Karlsruhe schema does not allow for that without a huge amount of work and a lot of uncertainty about the result. I'm not opposed to putting the house number on a separate node, but it needs to be topologically connected with the way using a relation in that case, because in real life, the house address *is* associated with the street it's on ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right?
2008/8/27 David Ebling [EMAIL PROTECTED]: I disagree. I might drive up to a post box to post a letter, if I was really lazy. However, unless I'm a bus driver (and let's face it, they're not going to be the main map users) you are unlikely to drive up to a bus stop to get on a bus (unless you're dropping someone off of course, in which case you may cause an obstruction to a bus.) Bus stops are POIs that are primarily of interest to pedestrians, not motorists, so which side of the road they are matters, and the logical place to put nodes is, IMHO, next to the road, not in the middle of it. The bus may stop in the road, or it may pull into a layby that forms part of the bus stop. However, the bus stop user stands to the side of the road. that's not really the point - the fact remains, it is a feature of the road, regardless of whether a road user or pavement user is more likely to use it. we shouldn't change the mapped location of an item based upon it's use case. it's either in one position or another - we shouldn't get all artistic with it Discussions about whether the node can easily be understood by routers to be connected to the way seem spurious to me - surely you should just connect them into a route relation? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right?
Robin : my thought, more or less, but you expressed it better. I've been tagging a few bus stops in my area, and placing them aside, unconnected to the way felt a bit strange to me. We should, however, find a standardized system to determine which side of the way, or more exactly which direction of the bus route the stop is used for. I see at least 2 cases that need it : - in some cases, the bus stops at a given place, but opposite directions, are located with an offset of 100m. This is quite a difference for a pedestrian. - more rarely, a bus will stop at a place when driving in a direction, but not the other. What matters here, is not so much the right or left side positioning of the stop, as you only have to cross the way to get to it. It is more the direction forth or back. I think we shouldnt rely on the side to determine the direction, as vehicles drive on different sides in different countries. -Message d'origine- De : [EMAIL PROTECTED] [mailto:talk- [EMAIL PROTECTED] De la part de robin paulson Envoyé : lundi 25 août 2008 03:48 À : OSM Talk Objet : Re: [OSM-talk] Left and Right? Rory McCann wrote: Gervase Markham wrote: What's current tagging best practice with things which are to the left or the right of a way (e.g. bus stops)? A nearly-approved proposal for a canal-side object has been objected to by someone who thinks that the tag should be on a node which is part of the canal rather than next to it, with left/right indicated as part of the tag key name. http://wiki.openstreetmap.org/index.php/Proposed_features/Mooring Do we do that for any other tags? Do we have highway:left=bus_stop? Gerv Personally I add the node to left of the way, not as part of the way. I believe the OSM theory is that the way represents the middle of the road. So things like mini-roundabounds and traffic lights are part of the way (ie road), but a bus stop is off to the side of the road. the problem with this is that 'bus stop' (and canal mooring, etc,) implies a place where the bus stops, which is on the road. the fact the bus shelter, or sign, or bench, is some distance off to the side of the road shouldn't matter - the bus itself stops on the road, so the node imo should be part of the way if the bus stop is off to the side of the road, i.e. not connected to it, then the bus can't physically get to it, which seems very wrong or, consider from the pedestrian's point-of-view: it is assumed for all roads except motorways and where explicitly stated, that there is foot=yes access. in which case, the footpath/sidewalk/pavement is therefore part of the way which represents the road; we don't draw a separate way off to one side, running parallel. the bus stop must be on the footpath for the pedestrian to be able to walk up to it, so again it must be part of the way this problem is i think muddled by the fact we represent an area (a road) with a linear object (a way), which theoretically has zero width, so the natural step from this is to say: 'the way represents the centre of the road, and the bus stop/canal mooring is not in the centre of the road, it's at the side of the road, so I'll put it to one side of the way' as for placing the node to one side of the way in order to get the icon to be placed correctly, this sounds a lot like 'tagging for the renderer' ___ 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?
robin paulson wrote: the problem with this is that 'bus stop' (and canal mooring, etc,) implies a place where the bus stops, which is on the road. the fact the bus shelter, or sign, or bench, is some distance off to the side of the road shouldn't matter - the bus itself stops on the road, so the node imo should be part of the way if the bus stop is off to the side of the road, i.e. not connected to it, then the bus can't physically get to it, which seems very wrong or, consider from the pedestrian's point-of-view: it is assumed for all roads except motorways and where explicitly stated, that there is foot=yes access. in which case, the footpath/sidewalk/pavement is therefore part of the way which represents the road; we don't draw a separate way off to one side, running parallel. the bus stop must be on the footpath for the pedestrian to be able to walk up to it, so again it must be part of the way this problem is i think muddled by the fact we represent an area (a road) with a linear object (a way), which theoretically has zero width, so the natural step from this is to say: 'the way represents the centre of the road, and the bus stop/canal mooring is not in the centre of the road, it's at the side of the road, so I'll put it to one side of the way' as for placing the node to one side of the way in order to get the icon to be placed correctly, this sounds a lot like 'tagging for the renderer' Part of it depends. In Ireland, bus stops are frequently marked with a sign on the path. This post is not on the road, it is on the path. I place the node where that post is on the ground (usually using Yahoo Imagery and local knowledge). For example here's a bus stop near where I used to live: http://www.openstreetmap.org/?lat=53.357268lon=-6.423311zoom=18layers=B00FTF It's basically on the corner of a few roads. Remember there are relations for bus routes, they include the bus stops and the ways that make up the route. They can be used to figure out where a bus will stop. With regards to house addresses, the Karlsruhe scheme has the (optional) addr:street=* tag, so you can associate those addresses with a street. I always use this. This is independent from left/right. Rory ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right?
2008/8/25 Rory McCann [EMAIL PROTECTED]: as for placing the node to one side of the way in order to get the icon to be placed correctly, this sounds a lot like 'tagging for the renderer' Part of it depends. In Ireland, bus stops are frequently marked with a sign on the path. This post is not on the road, it is on the path. I place the node where that post is on the ground (usually using Yahoo Imagery and local knowledge). For example here's a bus stop near where I used to live: http://www.openstreetmap.org/?lat=53.357268lon=-6.423311zoom=18layers=B00FTF It's basically on the corner of a few roads. i see what you're getting at, but the sign shouldn't be taken to indicate anything. after all, the sign can't be exactly where the bus stops, or the bus wouldn't be able to stop there (and it would get in the way of traffic). i think this is true for most signs - the sign is generally *near*, but not exactly at the location of the item it's marking Remember there are relations for bus routes, they include the bus stops and the ways that make up the route. They can be used to figure out where a bus will stop. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right?
2008/8/25 Kevin Ryan [EMAIL PROTECTED]: or, consider from the pedestrian's point-of-view: it is assumed for all roads except motorways and where explicitly stated, that there is foot=yes access. in which case, the footpath/sidewalk/pavement is therefore part of the way which represents the road; we don't draw a separate way off to one side, running parallel. the bus stop must be on the footpath for the pedestrian to be able to walk up to it, so again it must be part of the way Is this the case? I've never seen this written in anywhere before? If this is the case, how do you specify that there isn't a footpath running in parallel with one or both sides of a road? How this then rendered to indicate which side of a road had a path and which one doesn't. I've asked this before in the wiki, but didn't get any answers. I think this information for footpaths is very important for people with limited mobility. no, it's not written anywhere - i'm just using logic to extrapolate what we do at present to encompass how to deal with this situation there is a tag proposal discussion to explicitly determine whether a road has pavements on either side, both sides or neither, but i think it's stalled at some point. feel free to resurrect if you wish, i think it's something that needs sorting i'm sure the implied 'foot=yes', on all roads except motorways, is somehwere in the wikithough? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right?
2008/8/25 Kevin Ryan [EMAIL PROTECTED]: I would assume that 'foot=yes' on all roads implies that you are allowed to walk on the road - not that there is a footpath in parallel with it. yes, that's probably what it means (is that in the wiki?), but until there's an explicit difference made in the osm documentation, i'm also extrapolating it's use for the future to mean, 'there's a footpath on both sides of the road'. but this is getting away from the point i was trying to make, regarding bus stops and canal mooring points at some point in the future, when we do consider footpaths on the side of the roads, it will likely be done by assuming the presence of footpaths, unless there's a 'footpath_right=no' (or whatever) tag, implying that the way marking the centre-line of the road actually marks the route of the footpath as well, so it follows that the highway=bus_stop node should be a part of the way marking the road, not offset to one side 2008/8/25 Robin Paulson [EMAIL PROTECTED] 2008/8/25 Kevin Ryan [EMAIL PROTECTED]: or, consider from the pedestrian's point-of-view: it is assumed for all roads except motorways and where explicitly stated, that there is foot=yes access. in which case, the footpath/sidewalk/pavement is therefore part of the way which represents the road; we don't draw a separate way off to one side, running parallel. the bus stop must be on the footpath for the pedestrian to be able to walk up to it, so again it must be part of the way Is this the case? I've never seen this written in anywhere before? If this is the case, how do you specify that there isn't a footpath running in parallel with one or both sides of a road? How this then rendered to indicate which side of a road had a path and which one doesn't. I've asked this before in the wiki, but didn't get any answers. I think this information for footpaths is very important for people with limited mobility. no, it's not written anywhere - i'm just using logic to extrapolate what we do at present to encompass how to deal with this situation there is a tag proposal discussion to explicitly determine whether a road has pavements on either side, both sides or neither, but i think it's stalled at some point. feel free to resurrect if you wish, i think it's something that needs sorting i'm sure the implied 'foot=yes', on all roads except motorways, is somehwere in the wikithough? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 robin paulson wrote: Rory McCann wrote: Gervase Markham wrote: What's current tagging best practice with things which are to the left or the right of a way (e.g. bus stops)? A nearly-approved proposal for a canal-side object has been objected to by someone who thinks that the tag should be on a node which is part of the canal rather than next to it, with left/right indicated as part of the tag key name. http://wiki.openstreetmap.org/index.php/Proposed_features/Mooring Do we do that for any other tags? Do we have highway:left=bus_stop? Gerv Personally I add the node to left of the way, not as part of the way. I believe the OSM theory is that the way represents the middle of the road. So things like mini-roundabounds and traffic lights are part of the way (ie road), but a bus stop is off to the side of the road. the problem with this is that 'bus stop' (and canal mooring, etc,) implies a place where the bus stops, which is on the road. the fact the bus shelter, or sign, or bench, is some distance off to the side of the road shouldn't matter - the bus itself stops on the road, so the node imo should be part of the way if the bus stop is off to the side of the road, i.e. not connected to it, then the bus can't physically get to it, which seems very wrong or, consider from the pedestrian's point-of-view: it is assumed for all roads except motorways and where explicitly stated, that there is foot=yes access. in which case, the footpath/sidewalk/pavement is therefore part of the way which represents the road; we don't draw a separate way off to one side, running parallel. the bus stop must be on the footpath for the pedestrian to be able to walk up to it, so again it must be part of the way this problem is i think muddled by the fact we represent an area (a road) with a linear object (a way), which theoretically has zero width, so the natural step from this is to say: 'the way represents the centre of the road, and the bus stop/canal mooring is not in the centre of the road, it's at the side of the road, so I'll put it to one side of the way' as for placing the node to one side of the way in order to get the icon to be placed correctly, this sounds a lot like 'tagging for the renderer' I disagree with this view. Do you tag post boxes as way nodes? Shops? Telephones? No... So why bus stops? They aren't in the road. They are sites on the side, like all of the above. It makes no sense to tag them as way objects. I have seen the arguments about knowing which way they belong to; IMHO this is specious, no bus company works by looking at OSM to see where to route their buses, but a map user may well want to know just where the bus stop is - Anyone looking at a map of where they are who doesn't know which side they drive, is in trouble. The same goes for any navigation software. It really isn't hard to link from bus-stops as points to nearby ways - check out all the routing apps, not many need a hard node ID or way ID to commence from / get to - they find a nearby way from a lat/long. If Gosmore can do it, why not any other app? It just introduces a whole load of hassle working out which bus stop goes in which direction, sticking it in the middle of the road. It looks stupid in the renderers for a very good reason. My 2p, but I don't want this to look like everyone thinks that way nodes are good.. Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIszNhJfMmcSPNh94RAkPOAJ9ALC4KpvGSUlTVxbVcNbW2jRuPFwCfcfAZ DIsY6girm+HvwS6kYgf/8V8= =dM1X -END PGP SIGNATURE- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right?
On Mon, Aug 25, 2008 at 3:34 PM, Mark Williams [EMAIL PROTECTED]wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 robin paulson wrote: Rory McCann wrote: Gervase Markham wrote: What's current tagging best practice with things which are to the left or the right of a way (e.g. bus stops)? A nearly-approved proposal for a canal-side object has been objected to by someone who thinks that the tag should be on a node which is part of the canal rather than next to it, with left/right indicated as part of the tag key name. http://wiki.openstreetmap.org/index.php/Proposed_features/Mooring Do we do that for any other tags? Do we have highway:left=bus_stop? Gerv Personally I add the node to left of the way, not as part of the way. I believe the OSM theory is that the way represents the middle of the road. So things like mini-roundabounds and traffic lights are part of the way (ie road), but a bus stop is off to the side of the road. the problem with this is that 'bus stop' (and canal mooring, etc,) implies a place where the bus stops, which is on the road. the fact the bus shelter, or sign, or bench, is some distance off to the side of the road shouldn't matter - the bus itself stops on the road, so the node imo should be part of the way if the bus stop is off to the side of the road, i.e. not connected to it, then the bus can't physically get to it, which seems very wrong or, consider from the pedestrian's point-of-view: it is assumed for all roads except motorways and where explicitly stated, that there is foot=yes access. in which case, the footpath/sidewalk/pavement is therefore part of the way which represents the road; we don't draw a separate way off to one side, running parallel. the bus stop must be on the footpath for the pedestrian to be able to walk up to it, so again it must be part of the way this problem is i think muddled by the fact we represent an area (a road) with a linear object (a way), which theoretically has zero width, so the natural step from this is to say: 'the way represents the centre of the road, and the bus stop/canal mooring is not in the centre of the road, it's at the side of the road, so I'll put it to one side of the way' as for placing the node to one side of the way in order to get the icon to be placed correctly, this sounds a lot like 'tagging for the renderer' I disagree with this view. Do you tag post boxes as way nodes? Shops? Telephones? No... So why bus stops? They aren't in the road. They are sites on the side, like all of the above. It makes no sense to tag them as way objects. I have seen the arguments about knowing which way they belong to; IMHO this is specious, no bus company works by looking at OSM to see where to route their buses, but a map user may well want to know just where the bus stop is - Anyone looking at a map of where they are who doesn't know which side they drive, is in trouble. The same goes for any navigation software. It really isn't hard to link from bus-stops as points to nearby ways - check out all the routing apps, not many need a hard node ID or way ID to commence from / get to - they find a nearby way from a lat/long. If Gosmore can do it, why not any other app? It just introduces a whole load of hassle working out which bus stop goes in which direction, sticking it in the middle of the road. It looks stupid in the renderers for a very good reason. My 2p, but I don't want this to look like everyone thinks that way nodes are good.. Mark If you happen to know exactly which nodes (which are not part of the way) are your start and end points, then routers can deal with that. If you want to know which bus stops you will pass while traveling along a way, that's a much more difficult problem if the nodes are not somehow topologically associated with the way. It's a more serious problem with house numbers because the data volume is so much higher (many more house numbers than bus stops), which makes it even more important to associate a number with a way (and not by using the street name--that's not topological, is subject to typos and is difficult to validate automatically). Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Left and Right?
What's current tagging best practice with things which are to the left or the right of a way (e.g. bus stops)? A nearly-approved proposal for a canal-side object has been objected to by someone who thinks that the tag should be on a node which is part of the canal rather than next to it, with left/right indicated as part of the tag key name. http://wiki.openstreetmap.org/index.php/Proposed_features/Mooring Do we do that for any other tags? Do we have highway:left=bus_stop? Gerv ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right?
Gervase Markham wrote: What's current tagging best practice with things which are to the left or the right of a way (e.g. bus stops)? A nearly-approved proposal for a canal-side object has been objected to by someone who thinks that the tag should be on a node which is part of the canal rather than next to it, with left/right indicated as part of the tag key name. http://wiki.openstreetmap.org/index.php/Proposed_features/Mooring Do we do that for any other tags? Do we have highway:left=bus_stop? Gerv Personally I add the node to left of the way, not as part of the way. I believe the OSM theory is that the way represents the middle of the road. So things like mini-roundabounds and traffic lights are part of the way (ie road), but a bus stop is off to the side of the road. A similar thinking is obvious in the Karlsruhe House Address Scheme (http://wiki.openstreetmap.org/index.php/Proposed_features/House_numbers/Karlsruhe_Schema), since the buildings that are numbered are not physically in the middle of the road, they are added as nodes to the left or right of the way. Rory ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right?
On Sun, Aug 24, 2008 at 9:53 AM, Rory McCann [EMAIL PROTECTED] wrote: Gervase Markham wrote: What's current tagging best practice with things which are to the left or the right of a way (e.g. bus stops)? A nearly-approved proposal for a canal-side object has been objected to by someone who thinks that the tag should be on a node which is part of the canal rather than next to it, with left/right indicated as part of the tag key name. http://wiki.openstreetmap.org/index.php/Proposed_features/Mooring Do we do that for any other tags? Do we have highway:left=bus_stop? Gerv Personally I add the node to left of the way, not as part of the way. I believe the OSM theory is that the way represents the middle of the road. So things like mini-roundabounds and traffic lights are part of the way (ie road), but a bus stop is off to the side of the road. A similar thinking is obvious in the Karlsruhe House Address Scheme ( http://wiki.openstreetmap.org/index.php/Proposed_features/House_numbers/Karlsruhe_Schema ), since the buildings that are numbered are not physically in the middle of the road, they are added as nodes to the left or right of the way. Rory Yes, and that method is not topological, which makes it very difficult to associate that feature (bus stop, house number, whatever) with the way that it's actually located on. It should either be a node that is part of the way, or have a relation to connect the node with the way. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right?
See http://wiki.openstreetmap.org/index.php/Bus_stop#Usage_.28node_positioning.29 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right?
Gervase Markham wrote: What's current tagging best practice with things which are to the left or the right of a way (e.g. bus stops)? A nearly-approved proposal for a canal-side object has been objected to by someone who thinks that the tag should be on a node which is part of the canal rather than next to it, with left/right indicated as part of the tag key name. http://wiki.openstreetmap.org/index.php/Proposed_features/Mooring Do we do that for any other tags? Do we have highway:left=bus_stop? Gerv As for bus stops I usually use bus_direction=N|S|E|W (idea gotten from http://wiki.openstreetmap.org/index.php/Talk:Buses ). From that it's possible to infer what side of the road the stop is placed on, and it isn't dependent on the direction of the way. I have no idea if anyone else uses it regularly though ;) /Niclas Andersson [EMAIL PROTECTED] ___ 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?
Karl Newman wrote: On Sun, Aug 24, 2008 at 9:53 AM, Rory McCann [EMAIL PROTECTED] Gervase Markham wrote: What's current tagging best practice with things which are to the left or the right of a way (e.g. bus stops)? A nearly-approved proposal for a canal-side object has been objected to by someone who thinks that the tag should be on a node which is part of the canal rather than next to it, with left/right indicated as part of the tag key name. http://wiki.openstreetmap.org/index.php/Proposed_features/Mooring Do we do that for any other tags? Do we have highway:left=bus_stop? Personally I add the node to left of the way, not as part of the way. I believe the OSM theory is that the way represents the middle of the road. So things like mini-roundabounds and traffic lights are part of the way (ie road), but a bus stop is off to the side of the road. A similar thinking is obvious in the Karlsruhe House Address Scheme (http://wiki.openstreetmap.org/index.php/Proposed_features/House_numbers/Karlsruhe_Schema), since the buildings that are numbered are not physically in the middle of the road, they are added as nodes to the left or right of the way. Yes, and that method is not topological, which makes it very difficult to associate that feature (bus stop, house number, whatever) with the way that it's actually located on. It should either be a node that is part of the way, or have a relation to connect the node with the way. I think that the topological aspect of OSM's data structure is important and well worth maintaining in nodes and ways as well as in relations. We are not just drawing pictures, we are also recording relationships. This is why the representation of a mooring - a stretch of canal where boats tie up - as a separate way not connected to the canal seems wrong to me. In this case and with bus stops or house numbers, if you convey which side it is on by having a separate node or way displaced an arbitary short distance to one side, then you lose this side information at lower scales, when it may still be important to a user. With a topological description it is still available. Left/right are sometimes criticised as being dangerous because they can be accidentally reversed. It is editing programs that do all the reversing and it would be better if they provided better support. It would not be difficult to have a scheme with automatic reversal of tags (on the way or its nodes) containing left or right or a few others (like oneway), together with a more intelligent warning for the user in other cases. Chris ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right?
On Sun, Aug 24, 2008 at 6:08 PM, Gervase Markham [EMAIL PROTECTED] wrote: What's current tagging best practice with things which are to the left or the right of a way (e.g. bus stops)? Do we do that for any other tags? Do we have highway:left=bus_stop? I made a feable atempt at finding all the tags that are dependant on the direction of the way. If you have any examples please add: http://wiki.openstreetmap.org/index.php/Category:Way_Direction_Dependant ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Left and Right?
Rory McCann wrote: Gervase Markham wrote: What's current tagging best practice with things which are to the left or the right of a way (e.g. bus stops)? A nearly-approved proposal for a canal-side object has been objected to by someone who thinks that the tag should be on a node which is part of the canal rather than next to it, with left/right indicated as part of the tag key name. http://wiki.openstreetmap.org/index.php/Proposed_features/Mooring Do we do that for any other tags? Do we have highway:left=bus_stop? Gerv Personally I add the node to left of the way, not as part of the way. I believe the OSM theory is that the way represents the middle of the road. So things like mini-roundabounds and traffic lights are part of the way (ie road), but a bus stop is off to the side of the road. the problem with this is that 'bus stop' (and canal mooring, etc,) implies a place where the bus stops, which is on the road. the fact the bus shelter, or sign, or bench, is some distance off to the side of the road shouldn't matter - the bus itself stops on the road, so the node imo should be part of the way if the bus stop is off to the side of the road, i.e. not connected to it, then the bus can't physically get to it, which seems very wrong or, consider from the pedestrian's point-of-view: it is assumed for all roads except motorways and where explicitly stated, that there is foot=yes access. in which case, the footpath/sidewalk/pavement is therefore part of the way which represents the road; we don't draw a separate way off to one side, running parallel. the bus stop must be on the footpath for the pedestrian to be able to walk up to it, so again it must be part of the way this problem is i think muddled by the fact we represent an area (a road) with a linear object (a way), which theoretically has zero width, so the natural step from this is to say: 'the way represents the centre of the road, and the bus stop/canal mooring is not in the centre of the road, it's at the side of the road, so I'll put it to one side of the way' as for placing the node to one side of the way in order to get the icon to be placed correctly, this sounds a lot like 'tagging for the renderer' ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
