[OSM-talk] [tagging] Feature Proposal - RFC - incline up down

[Mike Harris]

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:dieterdreist at 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 <waldo000000 at gmail.com>:
> > On Sat, Aug 22, 2009 at 8:35 PM, Morten 
> Kjeldgaard<mok at 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
> 
> 
>