Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
2009/8/25 Mike Harris mik...@googlemail.com: I just tried to apply the 'architects' convention' of steps 'always' being from bottom to top. Then for unrelated reasons I reversed the way. Unlike 'oneway' this does not reverse the direction of the steps - i.e. the software doesn't know about the architects' convention. So I have to conclude that - at present at least - the assumption of an implicit sense is risky. yes, I know it is risky. I wanted to write this convention to the wiki some time ago, but then a discussion on talk-de started, why it could be more natural/logical to do it the other way round, and in the end no conclusion could be achieved. It is just a convention, all architects know about it. It has IMHO nothing to do with logics or nature. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
2009/8/23 Roy Wallace waldo000...@gmail.com: On Sat, Aug 22, 2009 at 8:35 PM, Morten Kjeldgaardm...@bioxray.au.dk wrote: hard-to-verify data - I don't see why incline=* is any harder to verify than ele=* - as you said yourself, if you have one you can calculate/verify the other... I think that incline up/down is much easier to verify and much more unambigous (e.g. which elevation-model is used to express the elevation?), but also far less usefull. Everybody can see on the ground if a street goes up or down. What? The key question is if a tag is verifiable. Incline=* is just as verifiable as ele=*. It's just in a different form. The good argument for adding incline=* is that it is 1) easy to read off a sign (say, source:incline=sign), I think you're confusing 2 things here: the sign AFAIK doesn't tell the inclination but the maximum inclination that occurs on a certain road. 2) provides valuable information in the meantime, while we wait for you to develop and import your ele=* solution. the ele-solution is already established. Please see the wiki. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
I just tried to apply the 'architects' convention' of steps 'always' being from bottom to top. Then for unrelated reasons I reversed the way. Unlike 'oneway' this does not reverse the direction of the steps - i.e. the software doesn't know about the architects' convention. So I have to conclude that - at present at least - the assumption of an implicit sense is risky. Mike Harris -Original Message- From: Martin Koppenhoefer [mailto:dieterdre...@gmail.com] Sent: 25 August 2009 12:08 To: Roy Wallace Cc: talk Subject: Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down 2009/8/23 Roy Wallace waldo000...@gmail.com: On Sat, Aug 22, 2009 at 8:35 PM, Morten Kjeldgaardm...@bioxray.au.dk wrote: hard-to-verify data - I don't see why incline=* is any harder to verify than ele=* - as you said yourself, if you have one you can calculate/verify the other... I think that incline up/down is much easier to verify and much more unambigous (e.g. which elevation-model is used to express the elevation?), but also far less usefull. Everybody can see on the ground if a street goes up or down. What? The key question is if a tag is verifiable. Incline=* is just as verifiable as ele=*. It's just in a different form. The good argument for adding incline=* is that it is 1) easy to read off a sign (say, source:incline=sign), I think you're confusing 2 things here: the sign AFAIK doesn't tell the inclination but the maximum inclination that occurs on a certain road. 2) provides valuable information in the meantime, while we wait for you to develop and import your ele=* solution. the ele-solution is already established. Please see the wiki. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
I am not an architect (!) and didn't know there was a convention for steps. So I expect 50% of my steps are wrong as I have always simply mapped them in the direction of (my) travel (:). If everyone agrees that the architects' convention should be adopted, could we document this? It seems to have been left open on the wiki http://wiki.openstreetmap.org/wiki/Steps . Elevation-derived tagging is rarely possible on steps as the elevation difference is usually small compared with the typical GPS vertical error. But the existence of steps will be important for many users - cyclists, wheelchairs, etc. Mike Harris -Original Message- From: Martin Koppenhoefer [mailto:dieterdre...@gmail.com] Sent: 22 August 2009 13:22 To: Mike Harris Cc: talk Subject: Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down 2009/8/22 Mike Harris mik...@googlemail.com: I'm with Martin on this one - up/down is better than nothing and is useful in its own right on steps for example. actually I wrote that it's IMHO not needed for steps: I draw them from down to up, they already have their direction. This is IMHO the natural way of doing it (as it is done like this worldwide in architecture, and I'm an architect ;-) ). I don't see much of a benefit for ways either, but I agree that ele-nodes have their own problems, and therefore the incline-tag on ways could at least indicate some kind of inclination (probably you could use this in hilly city centres, where SRTM is not sufficient, to avoid inclinations on bike or something like this). cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
Mike Harris wrote: If everyone agrees that the architects' convention should be adopted, could we document this? Even if people on the mailing list agree, most mappers will still not know about the convention. There will be no way to distinguish the steps of those who do know it from those who don't. Is there any realistic chance of reaching a situation where almost all steps will point in the same direction? It would at least require every editor to unambiguously convey the directionality of steps and its meaning - an entry in the wiki will not be read by someone using that seemingly obvious steps preset. Personally, I still think adding that little incline=up tag would be worth the effort... Tobias Knerr PS: How about adopting inline quoting for your mails to the list? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
I'm with Martin on this one - up/down is better than nothing and is useful in its own right on steps for example. Mike Harris -Original Message- From: Morten Kjeldgaard [mailto:m...@bioxray.au.dk] Sent: 21 August 2009 17:11 To: m...@koppenhoefer.com Cc: talk Subject: Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down On 21/08/2009, at 03.00, Martin Koppenhoefer wrote: Yeah, numeric value is better, but up/down is better than nothing. I think both should be allowed and within the scope of the proposal. if you already have good elevation data you can also tag the nodes with ele=xy (but nodes can always be moved, so this data might not be most reliable). Inclines are easy to calculate if elevation data is available. IMHO tagging data with incline=* is the wrong solution to an important problem, and it signals the beginning of an immense and never-ending task of maintaining hard-to-verify data. It would be much better to work on a proper solution that involves designing a system for registering topographical data within street maps. Cheers, Morten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
Roy Wallace wrote: Inclines are easy to calculate if elevation data is available - that's a big if, isn't it? Not really. There's a lot of elevation data available in the GPS traces, and since roads where incline=* is relevant are drawn along GPS traces, it's a matter of exploiting that data value. I'm aware that the GPS elevation data isn't terribly accurate on an absolute scale, but when determining inclines we will be making elevation differences which will decrease the error significantly. hard-to-verify data - I don't see why incline=* is any harder to verify than ele=* - as you said yourself, if you have one you can calculate/verify the other... The fact that there's a lot of unreliable and hard-to-verify data is no good argument for adding more. It would be much better to...design a system for registering topographical data - sounds good, go for it. But I don't see a problem with using incline=* in the meantime. Incline tagging is useless unless a consumer of this data can count on it being generally available. A driver might find herself on a steep incline when expecting a flat one, just because it wasn't tagged. IMHO it is much more productive to spend time working out some system that would allow us to compute inclines automatically on the whole dataset. That would give you the desired data all over the world and not just in your local area. Cheers, Morten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
--- On Sat, 22/8/09, Morten Kjeldgaard m...@bioxray.au.dk wrote: Not really. There's a lot of elevation data available in the GPS traces, and since roads where incline=* is relevant are drawn along GPS traces, it's a matter of exploiting that data value. I'm aware that the GPS elevation data isn't terribly accurate on an absolute scale, but when determining inclines we will be making elevation differences which will decrease the error significantly. I doubt most GPS traces would be useful for this kind of thing, most vertical GPS data is +/- 10m under the best possible conditions, usually I seem to be +/- 20m most of the time, and it's not a stable 20m diff it jumps about just like GPS positions do. You'd need a GPS with an altimeter, or a stand alone altimeter, to do this kind of elevation differences to get accuracy better than up/down. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
John Smith wrote: --- On Sat, 22/8/09, Morten Kjeldgaard m...@bioxray.au.dk wrote: Not really. There's a lot of elevation data available in the GPS traces, and since roads where incline=* is relevant are drawn along GPS traces, it's a matter of exploiting that data value. I'm aware that the GPS elevation data isn't terribly accurate on an absolute scale, but when determining inclines we will be making elevation differences which will decrease the error significantly. I doubt most GPS traces would be useful for this kind of thing, most vertical GPS data is +/- 10m under the best possible conditions, usually I seem to be +/- 20m most of the time, and it's not a stable 20m diff it jumps about just like GPS positions do. You'd need a GPS with an altimeter, or a stand alone altimeter, to do this kind of elevation differences to get accuracy better than up/down. Right, but when making differences the error will become much less significant. As you know, the GPS device reliably tracks your relative movements, although the absolute position might be in error. When subtracting two positions from each other, the absolute positioning error will disappear. In addition, for many traces there will be multiple measurements, which will give a much better determination of the gradient. Thirdly, time is on our side, because as tech develops, GPS devices become much more accurate... think Galileo etc. Cheers, Morten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
On 22 Aug 2009, at 11:48, John Smith wrote: --- On Sat, 22/8/09, Morten Kjeldgaard m...@bioxray.au.dk wrote: Not really. There's a lot of elevation data available in the GPS traces, and since roads where incline=* is relevant are drawn along GPS traces, it's a matter of exploiting that data value. I'm aware that the GPS elevation data isn't terribly accurate on an absolute scale, but when determining inclines we will be making elevation differences which will decrease the error significantly. I doubt most GPS traces would be useful for this kind of thing, most vertical GPS data is +/- 10m under the best possible conditions, usually I seem to be +/- 20m most of the time, and it's not a stable 20m diff it jumps about just like GPS positions do. You'd need a GPS with an altimeter, or a stand alone altimeter, to do this kind of elevation differences to get accuracy better than up/ down. Remember at last years osm birthday bash we were beside the Thames just above sea level and the 20 GPSs in the group were giving a variation of around 200 metres if I remember correctly. Shaun smime.p7s Description: S/MIME cryptographic signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
--- On Sat, 22/8/09, Morten Kjeldgaard m...@bioxray.au.dk wrote: When subtracting two positions from each other, the absolute positioning error will disappear. In addition, for many traces there will be multiple measurements, which will give a much better determination of the gradient. I disagree and I urge you to test this speculation out with 6-10 GPS devices and a hill and see what the results are, I doubt you would get any where near as accurate as you are assuming. Thirdly, time is on our side, because as tech develops, GPS devices become much more accurate... think Galileo etc. How many birds are in the sky now? Still 1 or did they put a second one up? You would have had better of talking about the Russian version of GPS, at least it has numerous sats in the sky even if they don't have enough for GPS type coverage. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
On Sat, 22 Aug 2009, Morten Kjeldgaard wrote: Right, but when making differences the error will become much less significant. As you know, the GPS device reliably tracks your relative movements, although the absolute position might be in error. not vertically because the actual device i own actually checks for a change in atmospheric pressure and does not calculate the height from the satellite data at short intervals so anyone using a Garmin etrex vista cx or similar device cannot provide height data which accurately tells you even if you are going up or down a hill at cycling speed - i've watched it when touring and you can either go up when you are going down or make huge jumps suddenly. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
2009/8/22 Mike Harris mik...@googlemail.com: I'm with Martin on this one - up/down is better than nothing and is useful in its own right on steps for example. actually I wrote that it's IMHO not needed for steps: I draw them from down to up, they already have their direction. This is IMHO the natural way of doing it (as it is done like this worldwide in architecture, and I'm an architect ;-) ). I don't see much of a benefit for ways either, but I agree that ele-nodes have their own problems, and therefore the incline-tag on ways could at least indicate some kind of inclination (probably you could use this in hilly city centres, where SRTM is not sufficient, to avoid inclinations on bike or something like this). cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
2009/8/22 John Smith delta_foxt...@yahoo.com: --- On Sat, 22/8/09, Morten Kjeldgaard m...@bioxray.au.dk wrote: Not really. There's a lot of elevation data available in the GPS traces, and since roads where incline=* is relevant are drawn along GPS traces, it's a matter of exploiting that data value. I'm aware that the GPS elevation data isn't terribly accurate on an absolute scale, but when determining inclines we will be making elevation differences which will decrease the error significantly. I doubt most GPS traces would be useful for this kind of thing, most vertical GPS data is +/- 10m under the best possible conditions, usually I seem to be +/- 20m most of the time, and it's not a stable 20m diff it jumps about just like GPS positions do. You'd need a GPS with an altimeter, or a stand alone altimeter, to do this kind of elevation differences to get accuracy better than up/down. +1. E.g. the widespread 60 CSx from a well known manufacturer offers this, but (I guess) almost noone does a calibration before every log (at least I almost never do). That's why absolute elevation is not reliable, but the relative data (i.e. difference from one junction to another) is still highprecision compared to GPS-elevation. I wonder if some smart programmer could use this in some way for OSM. Provided you have some reliable height-points, e.g. from public survey, mountain-tops, other official signs, you could use this relative data to calculate also the intermediate nodes. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
On 22/08/2009, at 13.14, John Smith wrote:
When subtracting two positions from each other, the
absolute positioning error will disappear.
In addition, for many traces there will be multiple
measurements, which will give a much better determination of
the gradient.
I disagree and I urge you to test this speculation out with 6-10 GPS
devices and a hill and see what the results are, I doubt you would
get any where near as accurate as you are assuming.
What kind of accuracy do you want? We are talking about people wanting
to tag incline={up, down}. GPS elevation differences are certainly
good enough to make that binary classification, especially if the
incline is one that matters.
Should every sorry GPS trace be used? Perhaps as a quick-and-dirty
start, but you are right, better and more accurate data is needed.
People who care about these things in a particular area could
certainly arrange to get accurate gpx data with an altimeter equipped
GPS.
In addition, we have access to topographical data many places, a fact
which has not been mentioned in this thread. This data can also be
used to derive elevation gradients of roads.
I realize it wont be possible to compute elevation gradients tomorrow,
but why not plan ahead? Who would've thought a few years ago that the
project would be so far advanced? Wouldn't you rather have nodes on a
way with incline=7% than incline=up? Wouldn't it be better to get
this data from a database lookup than from manual tagging?
Cheers,
Morten
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
--- On Sun, 23/8/09, Morten Kjeldgaard m...@bioxray.au.dk wrote: I realize it wont be possible to compute elevation gradients tomorrow, but why not plan ahead? Who would've thought a few years ago that the project would be so far advanced? Wouldn't you rather have nodes on a way with incline=7% than incline=up? Wouldn't it be better to get this data from a database lookup than from manual tagging? I doubt anyone is disagreeing, however up/down is like tagging highway=road, it's just a rough reference. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
2009/8/22 John Smith delta_foxt...@yahoo.com: --- On Sun, 23/8/09, Morten Kjeldgaard m...@bioxray.au.dk wrote: I realize it wont be possible to compute elevation gradients tomorrow, but why not plan ahead? Who would've thought a few years ago that the project would be so far advanced? Wouldn't you rather have nodes on a way with incline=7% than incline=up? Wouldn't it be better to get this data from a database lookup than from manual tagging? I doubt anyone is disagreeing, however up/down is like tagging highway=road, it's just a rough reference. I'm tempted to say gradient needs tagging, this can often be got off road signs. but I don't see why we can't tag any way with a gradient. This is also needed for steps and escalators. The issue is that it can't really be derived from elevation data as ways often go at an angle (to reduce gradient) or are built out from the land on man made structures. Some bridges my cause an incline which may need taging, ie hump backed bridges. Peter. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
On Sat, Aug 22, 2009 at 7:43 PM, Peter Childspchi...@bcs.org wrote: The problem with this tag is that it's about topology. up/down is like north/west or turn left/right. Like the tag is_in, it shouldn't be a tag to say where a point or a pair of points is geospatialized. Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
On Sat, Aug 22, 2009 at 8:35 PM, Morten Kjeldgaardm...@bioxray.au.dk wrote: hard-to-verify data - I don't see why incline=* is any harder to verify than ele=* - as you said yourself, if you have one you can calculate/verify the other... The fact that there's a lot of unreliable and hard-to-verify data is no good argument for adding more. What? The key question is if a tag is verifiable. Incline=* is just as verifiable as ele=*. It's just in a different form. The good argument for adding incline=* is that it is 1) easy to read off a sign (say, source:incline=sign), 2) provides valuable information in the meantime, while we wait for you to develop and import your ele=* solution. Incline tagging is useless unless a consumer of this data can count on it being generally available. A driver might find herself on a steep incline when expecting a flat one, just because it wasn't tagged. This is ridiculous. The absence of incline=* does not infer incline=0 - it infers that the incline is unknown/unspecified. Just as absence of ele=* doesn't infer ele=0 - it infers that the elevation is unknown/unspecified. IMHO it is much more productive to spend time working out some system that would allow us to compute inclines automatically on the whole dataset. That would give you the desired data all over the world and not just in your local area. Sounds great - but in the meantime, people will continue to tag what they see on the ground - especially on road signs - in any way they see fit. Better that incline=* is used consistently for tagging incline, in the meantime. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
On 21/08/2009, at 03.00, Martin Koppenhoefer wrote: Yeah, numeric value is better, but up/down is better than nothing. I think both should be allowed and within the scope of the proposal. if you already have good elevation data you can also tag the nodes with ele=xy (but nodes can always be moved, so this data might not be most reliable). Inclines are easy to calculate if elevation data is available. IMHO tagging data with incline=* is the wrong solution to an important problem, and it signals the beginning of an immense and never-ending task of maintaining hard-to-verify data. It would be much better to work on a proper solution that involves designing a system for registering topographical data within street maps. Cheers, Morten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
On Sat, Aug 22, 2009 at 2:11 AM, Morten Kjeldgaard m...@bioxray.au.dk wrote: On 21/08/2009, at 03.00, Martin Koppenhoefer wrote: Yeah, numeric value is better, but up/down is better than nothing. I think both should be allowed and within the scope of the proposal. if you already have good elevation data you can also tag the nodes with ele=xy (but nodes can always be moved, so this data might not be most reliable). Inclines are easy to calculate if elevation data is available. IMHO tagging data with incline=* is the wrong solution to an important problem, and it signals the beginning of an immense and never-ending task of maintaining hard-to-verify data. It would be much better to work on a proper solution that involves designing a system for registering topographical data within street maps. Inclines are easy to calculate if elevation data is available - that's a big if, isn't it? hard-to-verify data - I don't see why incline=* is any harder to verify than ele=* - as you said yourself, if you have one you can calculate/verify the other... It would be much better to...design a system for registering topographical data - sounds good, go for it. But I don't see a problem with using incline=* in the meantime. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] Feature Proposal - RFC - incline up down
Proposal for tagging the general direction of a way as incline=up/down: http://wiki.openstreetmap.org/wiki/Proposed_features/incline_up_down ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
2009/8/20 Tobias Knerr o...@tobias-knerr.de: Proposal for tagging the general direction of a way as incline=up/down: http://wiki.openstreetmap.org/wiki/Proposed_features/incline_up_down I personally use the direction of way for steps in the (architectural) standard way that the way point upwards, i.e. the bottom of the steps is the beginning of the steps-way and the top the end. If we could agree to this general definition a separate incline-tag would not be neeeded. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
On Fri, Aug 21, 2009 at 12:45 AM, Martin Koppenhoeferdieterdre...@gmail.com wrote: 2009/8/20 Tobias Knerr o...@tobias-knerr.de: Proposal for tagging the general direction of a way as incline=up/down: http://wiki.openstreetmap.org/wiki/Proposed_features/incline_up_down I personally use the direction of way for steps in the (architectural) standard way that the way point upwards, i.e. the bottom of the steps is the beginning of the steps-way and the top the end. If we could agree to this general definition a separate incline-tag would not be neeeded. What about a one-way way that points downhill? For this, incline=* is useful. It's also more explicit. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
2009/8/20 Roy Wallace waldo000...@gmail.com: I personally use the direction of way for steps ... What about a one-way way that points downhill? For this, incline=* is useful. It's also more explicit. for ways it is indeed a plus. I was referring just to steps. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
On Fri, 21 Aug 2009 01:54:23 +0200, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2009/8/20 Roy Wallace waldo000...@gmail.com: I personally use the direction of way for steps ... What about a one-way way that points downhill? For this, incline=* is useful. It's also more explicit. for ways it is indeed a plus. I was referring just to steps. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk incline should hold a numeric value, to indicate how steep it is, positive value is up, and negative is down, if steepness isn't trivial, leave it out. If you just want to render a steep road sign, why not find out (roughly) how steep the incline is, and tag it with that numeric value? -- Brgds Aun Johnsen via Webmail ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
On Fri, Aug 21, 2009 at 10:36 AM, Aun Johnsen (via Webmail)skipp...@gimnechiske.org wrote: incline should hold a numeric value, to indicate how steep it is, positive value is up, and negative is down, if steepness isn't trivial, leave it out. If you just want to render a steep road sign, why not find out (roughly) how steep the incline is, and tag it with that numeric value? Yeah, numeric value is better, but up/down is better than nothing. I think both should be allowed and within the scope of the proposal. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Proposal - RFC - incline up down
2009/8/21 Roy Wallace waldo000...@gmail.com: On Fri, Aug 21, 2009 at 10:36 AM, Aun Johnsen (via Webmail)skipp...@gimnechiske.org wrote: incline should hold a numeric value, to indicate how steep it is, positive value is up, and negative is down, if steepness isn't trivial, leave it out. If you just want to render a steep road sign, why not find out (roughly) how steep the incline is, and tag it with that numeric value? Yeah, numeric value is better, but up/down is better than nothing. I think both should be allowed and within the scope of the proposal. if you already have good elevation data you can also tag the nodes with ele=xy (but nodes can always be moved, so this data might not be most reliable). cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
