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 - 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
