[mkgmap-dev] Commit 4710

Thu May 13 22:36:48 BST 2021

Hi

Various thoughts:

The 0x40 polyLine direction flag probably has no effect on modern
Garmin devices. As Gerd says, GPSMapEdit puts an arrow on lines if it
is set. In my notes from testing all line types, I found some cases
where an eTrex put compass bearings (N/NE/E/...) on some line types
where the top byte was 0x5 (ie this flag was set), so modifying the
meaning line types 0x10 to 0x1f. I think they looked like 0x01 to 0x0f
but with the compass label.

I'll have a go at reproducing this - it was a while ago, I had to hack
some mkgmap code, and I can't remember which device it was.

Using the existing direction flag logic is overloading it; there is no
reason why another flag couldn't be introduced to inhibits line
reversal in attempts to merge. However, as the flag is already there,
seems to have correct meaning, doesn't have any known harmful effects
and might, possibly, be accessible to the TYP representation, then
there are many advantages in using it.

I notice an old posting by Andrzej saying one-way arrows are displayed
on some devices by default when no TYP graphics. @Andrzej - do you have
more details about this?

An option should allow the default setting of this flag per line Type.
It would be expected to be set for the types used for rivers, streams,
embankments, coastline.... The style/TYP author is responsible for
this. It could be one of the options allowed in style/options.

The oneway tag sets it, and it can also be set/cleared with mkgmap:has
-direction=yes/no. Should mkgmap:has-direction=no clear the flag if set
by one-way? Yes, as long as reversal is also inhibited by oneway.

I don't think there is any need for the style system to look for usages
of this tag and change behaviour.

Ticker