[OSM-talk] [tagging] Feature Proposal - RFC - incline up down
mikh43 at googlemail.com
Tue Aug 25 15:17:16 BST 2009
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.
> -----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.
More information about the talk