[Talk-us] OSM Elevation Data

[James Umbanhowar]

I think you can change the timer model in plotaroute by clicking on the 
timer box in the upper right of the planning web page.

On 10/17/22 09:45, Paul Toigo wrote:
> I've learned quite a bit in the last couple of weeks(, but still know 
> next to nothing). Indeed, plotaroute.com <http://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 
> <http://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 <http://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".
>
>
> _______________________________________________
> Talk-us mailing list
> Talk-us at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20221017/a260f52e/attachment-0001.htm>