[mkgmap-dev] line types for unpaved roads (was default style improvements)

Mon Jan 7 15:48:54 GMT 2019

Ticker Berkin <rwb-mkgmap at jagit.co.uk> writes:

> On Sun, 2019-01-06 at 08:50 -0500, Greg Troxel wrote:
>
> This request is slightly confused by 2 issues:
>
> 1/ The mkgmap/garmin attribute mkgmap:unpaved which is used by the
> routing option "avoid unpaved" on some (older?) Garmin devices to avoid
> unpaved roads.
>
> 2/ The line type 0x0a = "Unpaved Road" being used by the default style
> for highway=track, highway=unsurfaced and railway=abandoned

> Is the existing setting in the default style of mkgmap:unpaved (based
> on tags surface, mtb:scale, tracktype, sac_scale) adequate, or are
> there other tags/values that need to considered? 

I have no reason to think anything is wrong there.

Is there another mechanism for avoidance on other devices?  That could
interact with the line type choice, if those avoid line 0x0a only, and
e.g. not extended line types we want to use to show other unpaved ways.

> Are you thinking of having another line type? The default style has
> used all but 1 of the non-extended road types that show on newer
> devices without a typ-file specification; and I was thinking of using
> the last one (0x0b) as the Hint portion of a *_link instead of 0x06,
> which is also used for highway=minor & highway=unclassified

Yes, basically.

(highway=minor sounds like an osm bug; that could also get a comment in
the style that it's accomodating strange tagging.)

Upleveling as I am wont to do from excessive formal computer science
training:

I think we're at the point where the richness of the OSM data model
exceeds that of the basic Garmin data model.   I see two approaches:

  project OSM onto Garmin, losing detail

  use new line types and a TYP file

There is merit in each approach; perhaps there should be a no-typ
default style and then a style that has within it a typ sourcefile that
is used by default with the style, developed together with the style.

> Which highway types should be changed, eg unclassified, minor,
> tertiary, *_link, ... motorway? Should this new road type have the same
> [road_class road_speed resolution] attributes as the existing highway
> that it is replacing or can it just have a single fixed set of these
> attributes?

Ideally, we'd have

  a separate visual presentation for unpaved versions of
    motorway/primary/secondary/tertiary/unclassified/residential/service
    plus all their link variants
  (I agree that unpaved motorway feels wrong, and arguably it can be
  ignored because if there is one (Alaska still?) everybody knows
  already and in those places checking "avoid unpaved roads" isn't useful.)

  from a routing point of view, road class and road_speed should be set
  on these in the same manner as if paved, presumably class from osm way
  type, and speed from tags (or maybe defaults).
  (Maybe maybe there should be a default maxpeed:practical to unsurfaced
  ways if there is no explicit maxspeed tag, but that's tricky business
  of second-guessing defaults to make routing work better.)

  avoid unpaved knows about these on all devices

  I don't see why resolution should be different than if paved; way type
  encodes hierarchy.

  track, path, railroads (active/abandoned/razed) all look different.
  track has less visual weight than unpaved residential.

  in particular, a highway=secondary or highway=tertiary with
  surface=unpaved should show up on the map quite differently than
  track.

I think these goals lead to using unused extended line types and
controlling their appearance with the TYP file.  I think this approach
means that TYP file is not optional and needs to be in sync with the
style.

> Given answers to these questions, it can be done, but again, in some
> future change

Sure -- I was not meaning to suggest that your present changes are
problematic because they don't do everything I have ever wanted!