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] [ta
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 d
--- On Sat, 22/8/09, Morten Kjeldgaard 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 terrib
John Smith wrote:
> --- On Sat, 22/8/09, Morten Kjeldgaard 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 eleva
On 22 Aug 2009, at 11:48, John Smith wrote:
--- On Sat, 22/8/09, Morten Kjeldgaard 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
--- On Sat, 22/8/09, Morten Kjeldgaard 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
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 a
2009/8/22 Mike Harris :
> 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 doin
2009/8/22 John Smith :
> --- On Sat, 22/8/09, Morten Kjeldgaard 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 e
http://wiki.openstreetmap.org/wiki/Proposed_features/Escalator
I'm trying to work out how to tag Escalators I'm not sure the current
tagging it clear, or even partially useful.
This ties in Greatly with the long running Path discussion..
There seams to be no clear way to tag "Moving Walkways
Peter Childs wrote:
> http://wiki.openstreetmap.org/wiki/Proposed_features/Escalator
>
> I'm trying to work out how to tag Escalators I'm not sure the current
> tagging it clear, or even partially useful.
I wouldn't call this "current tagging". That page is a proposal in
"draft" state, i.e. its n
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
--- On Sun, 23/8/09, Morten Kjeldgaard 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 "inc
2009/8/22 Tobias Knerr :
> Peter Childs wrote:
>> http://wiki.openstreetmap.org/wiki/Proposed_features/Escalator
>>
>> I'm trying to work out how to tag Escalators I'm not sure the current
>> tagging it clear, or even partially useful.
>
> I wouldn't call this "current tagging". That page is a prop
2009/8/22 John Smith :
> --- On Sun, 23/8/09, Morten Kjeldgaard 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
hi,
I changed some things on http://wiki.openstreetmap.org/wiki/Key:access -
only to document current (best) practices.
* Transportation modes
The transportation mode hierarchy picture is replaced by a simple outline,
because the picture was not integrated in the text and too small to read
o
On Sat, Aug 22, 2009 at 7:43 PM, Peter Childs 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
Hello,
Walking Papers has just sprouted two localized translations, German by
Jonas Krückel and Dutch by Milo van der Linden. I encourage you to try
it out and report any issues to:
http://github.com/migurski/paperwalking/issues
It should auto-detect your browser language if applicabl
Hi,
it's a good thing that someone finally tries to clarify access
documentation - it definitely needs some care. I agree with your
reasoning to replace the image with editable content and some of your
definitions (such as avoiding to put an entry into the hierarchy
multiple times and separating w
Proposal for tagging land areas covered by greenhouses used for growing
plants.
http://wiki.openstreetmap.org/wiki/Proposed_features/greenhouse_horticulture
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
On 22/08/2009 20:33, Christiaan Welvaart wrote:
> hi,
>
> I changed some things on http://wiki.openstreetmap.org/wiki/Key:access -
> only to document current (best) practices.
>
>
> Added a separate tag for cars, because AFAICT any routing app computing
> routes for cars uses this transportation mo
On Sat, Aug 22, 2009 at 8:35 PM, Morten Kjeldgaard 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 da
I have done a dataset conversion in preparation for a bulk import of an NHD
coastal sub-basin in the US. One of the last river stages generated a
multipolygon relation containing about 3,000 members.
Is it best to break this into multiple 'bands' before importing it, or is
there no perform
Hi,
A while ago I tried to work out how to use osmxapi to extract just the
highways that
didn't have a name in an area, but couldn't work out how to express this.
Is this possible ? or have I just been stupid ;-)
thanks
--
Franc
___
talk mailing list
--- On Sun, 23/8/09, Mike N. wrote:
> I have done a dataset conversion in
> preparation for a bulk import of an NHD
> coastal sub-basin in the US. One of the
> last river stages generated a
> multipolygon relation containing about 3,000 members.
>
> Is it best to break this into multiple
On Sat, 22 Aug 2009 21:33:27 +0200 (CEST), Christiaan Welvaart
wrote:
> hi,
>
> I changed some things on http://wiki.openstreetmap.org/wiki/Key:access -
> only to document current (best) practices.
>
>
> * Transportation modes
>
> (Note that
> *=agricultural is not necessarily defined by thi
2009/8/23 Tobias Knerr :
> I believe the best way to solve this is to create a new top-level (that
> is, highway) value for all variants of conveyor transport. So, for
> example, we could do:
Is this intended to be only for human transport? I know of some quite
lengthy conveyors for goods - eg co
Hi!
Christiaan Welvaart schrieb:
> I changed some things on http://wiki.openstreetmap.org/wiki/Key:access -
> only to document current (best) practices.
It is a good thing that you try to complete and clarify the page.
However I must protest the way of doing it: Change the access tag page
and
28 matches
Mail list logo
