Re: [Tagging] Elevation and height on vertical features

Colin Smale wrote on 2016/01/08 17:47: How did all the elevation data get into OSM in the first place? > GPS is notoriously bad at determining elevation/altitude. Beside intentionally tagged elevation such as peaks, I found a lot of nodes in the data, that appear to come directly from GPX

Re: [Tagging] Elevation and height on vertical features

> On Jan 8, 2016, at 10:51 AM, Greg Troxel wrote: > > > Tod Fitch writes: > >>> On Jan 8, 2016, at 10:04 AM, Mike Thompson wrote: >>> >>> But I get it that the USGS surely publishes mountain heights >>> somehow. >>> I have asked,

Re: [Tagging] Elevation and height on vertical features

That could be someone converting from feet to meters. On Jan 8, 2016 10:32 AM, "Tom Pfeifer" wrote: > Colin Smale wrote on 2016/01/08 17:47: > >> How did all the elevation data get into OSM in the first place? >> > > GPS is notoriously bad at determining

Re: [Tagging] Elevation and height on vertical features

sent from a phone > Am 08.01.2016 um 17:18 schrieb Greg Troxel : > > I don't think it makes sense to add datum tags and have heights in other > datums. That just pushes the work onto the data consumer and adds > confusion. the advantage for the mapper is that it is quite

Re: [Tagging] Elevation and height on vertical features

Martin Koppenhoefer writes: > the advantage for the mapper is that it is quite easy, you simply read > an elevation off a sign and add the reference height system to the > value. (yes, you have to know what is this reference height system, > that's why the "quite" is

Re: [Tagging] Elevation and height on vertical features

Mike Thompson writes: > On Fri, Jan 8, 2016 at 9:47 AM, Colin Smale wrote: >> >> How did all the elevation data get into OSM in the first place? >> > The elevations of peaks in the US came from the GNIS import. In turn the > GNIS elevations came

Re: [Tagging] Elevation and height on vertical features

Tod Fitch writes: >> On Jan 8, 2016, at 10:04 AM, Mike Thompson wrote: >> >> But I get it that the USGS surely publishes mountain heights >> somehow. >> I have asked, and so far I have not gotten an answer as to where I can find >> the data. >> >

Re: [Tagging] Elevation and height on vertical features

Mike Thompson writes: > [1] do care about the "official" elevation of mountains. I think OSM > should - in these cases - match official government surveys where > available. Fully agreed that it should be right. > The particular datum is not important, as long as it is

Re: [Tagging] Elevation and height on vertical features

On Fri, Jan 8, 2016 at 12:15 PM, Martin Koppenhoefer wrote: > > > FWIW, for most usages of these ele values it doesn't really matter if a > value is 20 meters more or less, they are used to get a rough idea, not to > be used in calculations where a meter more or less is

Re: [Tagging] Elevation and height on vertical features

On Fri, Jan 8, 2016 at 10:54 AM, Greg Troxel wrote: > > Mike Thompson writes: > > > On Fri, Jan 8, 2016 at 9:47 AM, Colin Smale > wrote: > >> > >> How did all the elevation data get into OSM in the first place? > >> > > The

Re: [Tagging] Elevation and height on vertical features

> On Jan 8, 2016, at 10:04 AM, Mike Thompson wrote: > > But I get it that the USGS surely publishes mountain heights > somehow. > I have asked, and so far I have not gotten an answer as to where I can find > the data. > Is this the type of data you are looking for?

Re: [Tagging] Elevation and height on vertical features

2016-01-07 23:56 GMT+01:00 Colin Smale : > Nobody will be using the raw data to fly a plane. +1, and you wouldn't fly "blindly" (i.e. without sight) on a low-altitude flight with OSM-maps anyway, the idea sounds ridiculous. Cheers, Martin

Re: [Tagging] Elevation and height on vertical features

2016-01-08 2:30 GMT+01:00 Warin <61sundow...@gmail.com>: > Grasping at straws .. the elevation of a mountain is given as its peak. If > there is consistency within the map then the elevation of all objects > should be their maximum height. > don't confuse elevation and height. Elevation is

Re: [Tagging] Elevation and height on vertical features

So if all the elevations in OSM should be interpreted as WGS84, but many (most?) of them are not, we have no way of knowing which are "right" and which are "wrong". Even if the numerical value of ele=* is correct, we have unreliable data. Where do we go from here? Maybe we should encourage an

Re: [Tagging] Elevation and height on vertical features

Colin Smale writes: > So if all the elevations in OSM should be interpreted as WGS84, but many > (most?) of them are not, we have no way of knowing which are "right" and > which are "wrong". Even if the numerical value of ele=* is correct, we > have unreliable data. I

Re: [Tagging] Elevation and height on vertical features

Colin Smale writes: > On 2016-01-08 17:18, Greg Troxel wrote: > >> So we just have to fix things that are wrong, and transform heights in >> other datums into WGS84 before entering them. This is exactly the same >> situation that we encounter for horizonal datums, except

Re: [Tagging] Elevation and height on vertical features

On 2016-01-08 17:18, Greg Troxel wrote: > So we just have to fix things that are wrong, and transform heights in > other datums into WGS84 before entering them. This is exactly the same > situation that we encounter for horizonal datums, except that people are > even less aware of which vertical

Re: [Tagging] Elevation and height on vertical features

On Fri, Jan 8, 2016 at 9:47 AM, Colin Smale wrote: > > > How did all the elevation data get into OSM in the first place? > The elevations of peaks in the US came from the GNIS import. In turn the GNIS elevations came from the National Elevation Dataset (NED) [1], and it

Re: [Tagging] Elevation and height on vertical features

On Thu, Jan 7, 2016 at 3:40 PM, Colin Smale wrote: > Cliffs are never truly vertical. A bird's eye view from above will show > that. If they are steep enough they could be modelled as a line, but in > general we should allow for a polygon, with a high side and a low side.

Re: [Tagging] Elevation and height on vertical features

On 8/01/2016 9:56 AM, Colin Smale wrote: Nobody will be using the raw data to fly a plane. It doesn't matter if we use the ele tag for the top or the bottom - as long as the height is given, the other value can easily be derived. What is important is consistency, both in its definition and

Re: [Tagging] Elevation and height on vertical features

Nobody will be using the raw data to fly a plane. It doesn't matter if we use the ele tag for the top or the bottom - as long as the height is given, the other value can easily be derived. What is important is consistency, both in its definition and it's usage. Defining it as sometimes the top

Re: [Tagging] Elevation and height on vertical features

Indeed. On 7 January 2016 23:57:40 CET, Mike Thompson wrote: >On Thu, Jan 7, 2016 at 3:40 PM, Colin Smale >wrote: > >> Cliffs are never truly vertical. A bird's eye view from above will >show >> that. If they are steep enough they could be modelled as

Re: [Tagging] Elevation and height on vertical features

On Thu, Jan 7, 2016 at 6:30 PM, Warin <61sundow...@gmail.com> wrote: > > Grasping at straws .. the elevation of a mountain is given as its peak. If > there is consistency within the map then the elevation of all objects > should be their maximum height. > Sort of. By convention (in general

Re: [Tagging] Elevation and height on vertical features

On Thursday 07 January 2016, Aaron Spaulding wrote: > Hi all, > > I’ve been working on generating 3D meshes based on OSM data and I ran > into a problem. Vertical features like 'natural=cliff', > 'barrier=retaining_wall’ and 'waterway=waterfall' occupy two points > in physical space, but because

Re: [Tagging] Elevation and height on vertical features

sent from a phone > Am 07.01.2016 um 17:14 schrieb Aaron Spaulding : > > Either of these models can be used. I think option 1 makes the most sense, > but I’d like to know what the community consensus is. I've always thought of ele representing the lower part, which is

Re: [Tagging] Elevation and height on vertical features

On 8/01/2016 3:32 AM, Christoph Hormann wrote: On Thursday 07 January 2016, Aaron Spaulding wrote: Hi all, I’ve been working on generating 3D meshes based on OSM data and I ran into a problem. Vertical features like 'natural=cliff', 'barrier=retaining_wall’ and 'waterway=waterfall' occupy two

Re: [Tagging] Elevation and height on vertical features

Cliffs are never truly vertical. A bird's eye view from above will show that. If they are steep enough they could be modelled as a line, but in general we should allow for a polygon, with a high side and a low side. On 7 January 2016 17:32:49 CET, Martin Koppenhoefer