[Talk-us] OSM Elevation Data

[Greg Troxel]

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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20221006/c5d92f1b/attachment.sig>