[mkgmap-dev] Commit 4710

Fri May 14 06:11:20 BST 2021

Hi Ticker and all,

reg. tests of the 0x40 flag:
Attached small patch would be my guess for the lines with extended type.

The oneway attribute is stored in NOD and in the direction flag, I think that makes sense. The oneway=yes tag used to set the direction flag since more than 10 years (r738).

I do agree now that an option in the style to list types with direction is the better approach, the tag handling is much more complex. The size effects of r4710 reported by Felix show
that his style did not set the tag consistently for the same type and I think this can be really tricky.
So, I think I'll remove the code for mkgmap:has-direction=true and add a new option to list the types which should be treated as having a direction, e.g. --line-types-with-direction=0x18,0x1f, 0x10005, 0x10006 . The oneway=yes/oneway=-1 tag will continue to set the direction flag.
The default style might need some changes to distinguish waterways with direction from others, e.g. I think canals and rivers should have different types.

I'll change the option  --x-force-reverse-merge to --allow-reverse-merge with the default --allow-reverse-merge=no. These two options will effect RoadMerger and LineMerger.

I've not yet made up my mind regarding the reversing of lines (and roads) in LineMerger for the overview map. Felix says there is no need to care about direction in the overvew map.

I'll remove the code which tries to propagate the direction flag to underlying roads for now. Let's see first how often this is really needed.

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
Gesendet: Donnerstag, 13. Mai 2021 23:36
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

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

_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dir-for-extended.patch
Type: application/octet-stream
Size: 474 bytes
Desc: dir-for-extended.patch
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20210514/47000e21/attachment-0001.obj>