<div dir="ltr">To the best of my knowledge, the timer model is wholly based on Naismith's rule for estimating walking times.<div><a href="https://www.plotaroute.com/tip/11/how-to-estimate-the-time-to-complete-a-route">https://www.plotaroute.com/tip/11/how-to-estimate-the-time-to-complete-a-route</a><br></div><div>Yes, I can change several parameters in this timer model, but this model is not suitable for cycling. I'm looking to transform the beloved Chung method for my timer module.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 17, 2022 at 12:53 PM James Umbanhowar <<a href="mailto:jumbanho@gmail.com">jumbanho@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>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.<br>
</p>
<div>On 10/17/22 09:45, Paul Toigo wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">I've learned quite a bit in the last couple of
weeks(, but still know next to nothing). Indeed, <a href="http://plotaroute.com" target="_blank">plotaroute.com</a>
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.
<div><br>
</div>
<div>I found a distantly related feature request on the <a href="http://plotaroute.com" target="_blank">plotaroute.com</a>
site that also discusses their DEM.<br>
<div><a href="https://www.plotaroute.com/posts/3084/D/1" target="_blank">https://www.plotaroute.com/posts/3084/D/1</a></div>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Oct 6, 2022 at 5:47 AM
Greg Troxel <<a href="mailto:gdt@lexort.com" target="_blank">gdt@lexort.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Paul Toigo <<a href="mailto:toigopaul@gmail.com" target="_blank">toigopaul@gmail.com</a>>
writes:<br>
<br>
> I want to "improve" the elevation data for roads in
mountainous regions.<br>
> About the only thing I've found on the matter is the
following<br>
> question posted on OSM help.<br>
> <a href="https://help.openstreetmap.org/questions/9681/adding-elevation-data-to-existing-routes-conflation" rel="noreferrer" target="_blank">https://help.openstreetmap.org/questions/9681/adding-elevation-data-to-existing-routes-conflation</a><br>
> All I can glean from this is that Frederik Ramm doesn't
like the idea. All<br>
> the other jargon escapes me.<br>
<br>
You seem to be talking about a large-scale change, which means
you have<br>
to follow Import and Mechanical Edit guidelines, which means
that you<br>
have to clearly explain what you are actually wanting to do.
If you<br>
don't understand the fundamentals of OSM and elevation (which
is<br>
nontrivial), then you shouldn't be doing this until you have
learned<br>
them.<br>
<br>
You put "improve" in quotes, and I can only interpret that to
mean that<br>
you are using the word to mean other than the dictionary
meaning.<br>
Please try to say that you mean in plain language. If you
mean "I want<br>
to do an import for the whole US where, for each node in OSM
that is<br>
part of a way with a highway= tag, look up the elevation in
the USGS<br>
3DEP DEM, and modify the node to add ele=. By look up I mean
2D linear<br>
interpolation in the grid, and then transforming the native
NAVD88 to<br>
WGS84 Orthometric height using GEOID18, a Helmert
transformation, and<br>
EGM2008." then people would tell you that while your proposal
is not<br>
technically confused, it changes the OSM data and editing
model in a<br>
massive way that isn't supported by current tools, and it
doesn't make<br>
sense in a workflow sense in that OSM data users who need
elevation can<br>
just do that on the fly.<br>
<br>
Note that OSM does not contain contour lines. These are used
as an<br>
additional dataset at rendering time.<br>
<br>
I read the question, and I agree with Frederik's answer. OSM
currently<br>
only has elevation tags on a few point objects, like peaks.
Routers use<br>
separate databases of elevation, where they can look up
elevation from a<br>
dataset not stored in OSM. There are lots of examples, and
the first<br>
that comes to mind is OsmAnd which shows elevation profiles on
routes<br>
when the roads and their nodes do not have elevation. See
also brouter<br>
and graphhopper.<br>
<br>
I just went to <a href="http://openstreetmap.org" rel="noreferrer" target="_blank">openstreetmap.org</a>,
clicked directions, right-clicked<br>
start and end points, and chose graphhopper and got a route
with total<br>
ascent/descent and the values look sane.<br>
<br>
To explain terminology: raster refers to data that is in a
grid, like an<br>
image. The imagery we use to edit OSM is raster. The other
kind of<br>
data is vector, which has points, lines, etc. that are
described by<br>
coordinate. Besides imagery, there is a kind of raster
dataset called<br>
Digital Elevation Model which is like an image except that the
value<br>
rather than being brightness is height. So you can ask the
model: what<br>
is the height at this coordinate.<br>
<br>
OSM data is vector. This is a fundamental aspect of the data
model<br>
design. It is obviously the right call to the point where
nobody even<br>
talks about if it should have been otherwise. It is use to
generate<br>
raster maps (tiles) for humans to look at, in varying styles.<br>
Elevation data is expressed as raster, almost always.<br>
<br>
It would make sense if you were responsible for highway
engineering to<br>
gather vector data with height of highway centerlines, but
this is a<br>
much more expensive endeavor than OSM users drawing roads from
imagery,<br>
and needs more careful maintenance. It is entirely beyond
what is<br>
possible for the OSM community to do at the moment.<br>
<br>
Another aspect of height is that there different height
reference<br>
systems. "Height about Mean Sea Level" is a fuzzy concept.
People<br>
use various height systems:<br>
<br>
Height Above Ellipsoid or HAE (Native in GPS, only used for
surveying<br>
and other professional use. Water does not flow downward in
HAE!)<br>
<br>
WGS84 Orthometric Height (What GPS receivers show to humans
as<br>
altitude. Closely matches the concept of height above sea
level.<br>
Water flows downhill. This is what OSM uses in ele tags,
although<br>
this is not widely understood.)<br>
<br>
Various national/region height datums, e.g. NAVD88 in the US
(Use in<br>
national maps and engineering. Close to but not exactly
WGS84<br>
Orthometric Height; arguably close enough for OSM accuracy
standards.<br>
Closely matches the concept of height above sea level.
Water flows<br>
downhill.)<br>
<br>
Anyone adding height in bulk needs to be clear on the above.<br>
<br>
So you should instead be asking about routers and finding one
that uses<br>
a good DEM (meaning high-resolution and accurate). Or you
could write<br>
one or modify one; there is open source code for many, OSM
data is<br>
available, and in the US high-resolution accurate data is
available.<br>
Overall I would say "use brouter or graphhopper and then
figure out if<br>
there is anything that should be different".<br>
</blockquote>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
Talk-us mailing list
<a href="mailto:Talk-us@openstreetmap.org" target="_blank">Talk-us@openstreetmap.org</a>
<a href="https://lists.openstreetmap.org/listinfo/talk-us" target="_blank">https://lists.openstreetmap.org/listinfo/talk-us</a>
</pre>
</blockquote>
</div>
</blockquote></div>