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 known,
> as someone mak
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 important, i.e. this
> dis
> 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, and so far I have not gotten an answer as to where I can find
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 there). I'd also prefer to h
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 easy, you simply rea
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 elevation/altitude.
>
> Beside intentional
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.
>>
> Is this the type of data you are looking for
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 track
> 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?
http://www.ngs.noaa.gov/c
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 elevations of peaks in the US came from the GNIS import. In turn the
>
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 from the National Elevation Dataset (NED) [1], a
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
mostly uses the North Ame
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 that people are
>> even
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
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 have always had the impre
I've always thought of ele representing the lower part, which is clear for
man made features like buildings or obelisks (elevation of the ground, then
add height for the highest point at that spot). Now when it comes to
vertical elements like cliffs, where you have ground on both ends, it
admittedl
2016-01-08 12:11 GMT+01:00 Colin Smale :
> Where do we go from here? Maybe we should encourage an explicit reference
> to the datum used, such as ele:wgs84=* or ele:osgb=*?
>
this is what some people are already doing (not so few, but few compared to
the total number of ele-tags):
http://taginfo
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 exp
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 typic
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
___
Tagging
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 mappin
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 it's
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 a line, but
>in
>> general we should allow f
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.
>
Actually, sometimes th
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 a
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
wrote:
>
>
>sent from a p
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 p
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 of
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 clear for man
made fea
29 matches
Mail list logo
