[mkgmap-dev] unpaved roads

Thu Feb 23 07:31:41 GMT 2017

Hi Greg,

as you said we have to live with the limitations of the Garmin img format and the routing algo.
My understanding is that the default style should produce reasonable results for correct input data.

If I got you right you'd like to have some user interface (maybe sliders in a GUI) to express your
preferences of different road types or surface types and that should be used to "fine tune" the 
values for road_speed, road_class, and the unpaved flag so that one doesn't have to understand all
the complex rules? 

Gerd

________________________________________
Von: Greg Troxel <gdt at lexort.com>
Gesendet: Mittwoch, 22. Februar 2017 15:42
An: Gerd Petermann
Cc: Greg Troxel
Betreff: Re: AW: [mkgmap-dev] unpaved roads

[you didn't copy the list.  if you want me to post this I'm happy to.]

Gerd Petermann <GPetermann_muenchen at hotmail.com> writes:

> okay, a bit late.

understood.  I didn't mean to complain, just to offer a perspective that
I thought might be helpful.

> The default style was already changed to set the unpaved flag in the
> same way as the surface wiki suggests.

Arguably that is the most reasonable default.

> I agree that this is just one of many ways to use the flag, but I have
> no idea what you try to describe with the part following "try to map
> some utility function ..." .

What I meant is that a routing user will have an opinion about the
usefulness/goodness of any route based on many things.  Right now there
is a strong bias towards "shortest distance" and "fastest time" in the
routing world and "least fuel" is starting to show up.

I probably should not have said "utility function".  That's a concept
from economics which assigns a numerical value to a situation, and
there's an assumption that a rational actor seeks to maximize utility.

  https://en.wikipedia.org/wiki/Utility

This concept acknowledges lots of complexity.  A car that works but is
not fancy might be worth 100 points and one that is just as useful but
looks nicer 120, to one person.   Or 200 to someone who sees it as
jewelry/status, or 90 to someone who finds the niceness pointless and
then worries about damage.

What I was getting at is that for a route, one can think of each segment
as having a cost (which is sort of inverse utility), where the cost is
about how the route user feels about it.   Here, the cost function
encodes how one feels about surface types, speeds, distance, congestion,
traffic lights, left turns, etc.

Then, I was suggesting that optimal routing takes the OSM data and
compute a route with min user-cost according to the user's cost
function.  In OSMand you can sort of do this, because most of the OSM
data is or can be on the phone.

In Garmin, you can't, because we have to use the Garmin intermediate
representation and because we have to use the Garmin routing engine.
So, one could think about defining these user-cost functions, and then
trying to have a transformation of OSM data to Garmin data such that the
shortest time computation on the Garmin leads to a route that has
minimal user-cost.

> Do you suggest a new mkgmap option which overrides or influences the
> results of the style?  Can you give an example that shows the
> advantage compared to a "private" style ?

I think I'm really suggesting private styles, in some sense, but perhaps
something more than that, which is a language to express these user cost
functions and have that change the style.

This is arguably way too complicated.  Certainly it's premature until
there is a style that does something that people find more useful than
the default.

What I was really trying to do was to express the notion that correctly
encoding paved should not necessarily be the goal, but instead to allow
most people to be able to create good routes.

All that said, I find that around me, most connecting roads are paved
and it doesn't matter much.  In Upstate NY, there are connecting roads
that are unpaved.  But there, you really want to ask the question "would
I rather drive 10 miles unpaved or 50 miles paved" rather than just
"avoid".

This reminds me that max_speed isn't really the right thing either, but
OSM doesn't yet have a culture of "typical_speed".   To me, routing is
all about "on this route, what will my total experience be, and will I
prefer it to this other route's experience".  And that's very hard.

So thanks for listening, and hope it was worth your time!