Ticker Berkin <rwb-mkgmap@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!