[Talk-us] OSM Elevation Data

[Paul Toigo]

I've learned quite a bit in the last couple of weeks(, but still know next
to nothing). Indeed, plotaroute.com has a digital elevation model (DEM)
that currently only looks at SRTM. In the coming months they are making
several changes and plan to have their DEM be based on multiple data
sources, not just SRTM.

I found a distantly related feature request on the plotaroute.com site that
also discusses their DEM.
https://www.plotaroute.com/posts/3084/D/1
I learned from this thread that Strava already is doing what I propose, but
not in OSM. I found the elevation of my 4 rides up and down the Poudre
Canyon, benchmarked to the endpoints, to be in close agreement with each
other and Strava.

My prediction is that the improved Plotaroute DEM will still be a
disappointment. Furthermore, the Plotaroute timer model is really for
trekking, not cycling. So I'm currently of a mind to create routes in
Strava to get good elevation values and then apply a cycling specific timer
model to that route.


On Thu, Oct 6, 2022 at 5:47 AM Greg Troxel <gdt at lexort.com> wrote:

>
> Paul Toigo <toigopaul at gmail.com> writes:
>
> > I want to "improve" the elevation data for roads in mountainous regions.
> > About the only thing I've found on the matter is the following
> > question posted on OSM help.
> >
> https://help.openstreetmap.org/questions/9681/adding-elevation-data-to-existing-routes-conflation
> > All I can glean from this is that Frederik Ramm doesn't like the idea.
> All
> > the other jargon escapes me.
>
> You seem to be talking about a large-scale change, which means you have
> to follow Import and Mechanical Edit guidelines, which means that you
> have to clearly explain what you are actually wanting to do.  If you
> don't understand the fundamentals of OSM and elevation (which is
> nontrivial), then you shouldn't be doing this until you have learned
> them.
>
> You put "improve" in quotes, and I can only interpret that to mean that
> you are using the word to mean other than the dictionary meaning.
> Please try to say that you mean in plain language.  If you mean "I want
> to do an import for the whole US where, for each node in OSM that is
> part of a way with a highway= tag, look up the elevation in the USGS
> 3DEP DEM, and modify the node to add ele=.  By look up I mean 2D linear
> interpolation in the grid, and then transforming the native NAVD88 to
> WGS84 Orthometric height using GEOID18, a Helmert transformation, and
> EGM2008." then people would tell you that while your proposal is not
> technically confused, it changes the OSM data and editing model in a
> massive way that isn't supported by current tools, and it doesn't make
> sense in a workflow sense in that OSM data users who need elevation can
> just do that on the fly.
>
> Note that OSM does not contain contour lines.  These are used as an
> additional dataset at rendering time.
>
> I read the question, and I agree with Frederik's answer.  OSM currently
> only has elevation tags on a few point objects, like peaks.  Routers use
> separate databases of elevation, where they can look up elevation from a
> dataset not stored in OSM.  There are lots of examples, and the first
> that comes to mind is OsmAnd which shows elevation profiles on routes
> when the roads and their nodes do not have elevation.  See also brouter
> and graphhopper.
>
> I just went to openstreetmap.org, clicked directions, right-clicked
> start and end points, and chose graphhopper and got a route with total
> ascent/descent and the values look sane.
>
> To explain terminology: raster refers to data that is in a grid, like an
> image.  The imagery we use to edit OSM is raster.  The other kind of
> data is vector, which has points, lines, etc. that are described by
> coordinate.  Besides imagery, there is a kind of raster dataset called
> Digital Elevation Model which is like an image except that the value
> rather than being brightness is height.  So you can ask the model: what
> is the height at this coordinate.
>
> OSM data is vector.  This is a fundamental aspect of the data model
> design.  It is obviously the right call to the point where nobody even
> talks about if it should have been otherwise.   It is use to generate
> raster maps (tiles) for humans to look at, in varying styles.
> Elevation data is expressed as raster, almost always.
>
> It would make sense if you were responsible for highway engineering to
> gather vector data with height of highway centerlines, but this is a
> much more expensive endeavor than OSM users drawing roads from imagery,
> and needs more careful maintenance.  It is entirely beyond what is
> possible for the OSM community to do at the moment.
>
> Another aspect of height is that there different height reference
> systems.  "Height about Mean Sea Level" is a fuzzy concept.  People
> use various height systems:
>
>   Height Above Ellipsoid or HAE (Native in GPS, only used for surveying
>   and other professional use.  Water does not flow downward in HAE!)
>
>   WGS84 Orthometric Height (What GPS receivers show to humans as
>   altitude.  Closely matches the concept of height above sea level.
>   Water flows downhill.  This is what OSM uses in ele tags, although
>   this is not widely understood.)
>
>   Various national/region height datums, e.g. NAVD88 in the US (Use in
>   national maps and engineering.  Close to but not exactly WGS84
>   Orthometric Height; arguably close enough for OSM accuracy standards.
>   Closely matches the concept of height above sea level.  Water flows
>   downhill.)
>
> Anyone adding height in bulk needs to be clear on the above.
>
> So you should instead be asking about routers and finding one that uses
> a good DEM (meaning high-resolution and accurate).  Or you could write
> one or modify one; there is open source code for many, OSM data is
> available, and in the US high-resolution accurate data is available.
> Overall I would say "use brouter or graphhopper and then figure out if
> there is anything that should be different".
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20221017/94d29198/attachment.htm>