[mkgmap-dev] check-roundabout-flares

Mon Jul 27 20:22:53 BST 2020

Dear all,

I have been working on improvements to the --check-roundabout-flares option
to provide better decisions as to what should be considered a flare and have
managed to greatly reduce the number of messages that relate to roads that
are not flares. Of course it is not possible to discard all unwanted
messages without discarding the odd message this is relevant, hence the
rules need to be configurable to suit the circumstances in the area being
mapped.

I propose to deprecate the --check-roundabout-flares and
--max-flare-length-ratio options, with the former moving into the
--check-roundabouts option and the latter into a new set of rules.

The --check-roundabouts option would be extended to accept the following
list of values [all|loop|direction[:fix]|junctions|flares,...] where:

*	all applies all the checks and fixes.

*	loop checks that roundabouts are formed from a single loop with no
forks or gaps.

*	direction checks that the one way direction is in the expected
direction for the side of the road on which traffic drives. If the fix
suffix is supplied then roundabouts failing this check have their direction
reversed.

*	junctions checks that no more than one connecting highway joins at
each node.

*	flares checks that roundabout flare roads are one-way, point in the
correct direction, and don't extend beyond the flare.

This gives more flexibility over which checks are applied whilst reducing
the number of command line options.

For backwards compatibility, specifying the option with no value would be
the same as --check-roundabouts=loop,direction:fix,junctions, and the
default would be to not check anything.

Specifying --check-roundabout-flares would set --check-roundabouts=flares
and display an error message saying the option had been deprecated.

For the flare processing, I have used a set of rules and am considering the
best way to allow users to specify the rules that are to be applied in the
decision making process. I don't want to add them as individual options as
this complicates the interface too much. The choice therefore seems to be
between a separate rules file and a command line option with a list of rule
names and values.

The rules I have are as follows:

max-flare-length-multiple=NUM - Discard candidates where the length of one
of the possible flares is greater than NUM times the length of the other.
Default is 3. Set to 0 to disable.

max-flare-to-separation-multiple=NUM - Discard candidates where the length
of both of the possible flares are greater than NUM times the distance
between the nodes on the roundabout that the flare roads connect to. Default
is 7. Set to 0 to disable. (This is equivalent to the existing
--max-flare-length-ratio option)

max-flare-angle=NUM - Discard candidates where the angle subtended between
the two possible flares is greater than NUM. Default is 90. Set to 0 to
disable.

max-flare-bearing=NUM - Discard candidates where the angle between the
initial bearing of a possible flare road and the centre of the roundabout is
greater than NUM. Default is 90. Set to 0 to disable.

max-entry-angle=NUM - Discard candidates where the angle subtended from the
centre of the roundabout to the two roundabout junction nodes is greater
then NUM. Default is 145. Set to 0 to disable.

both-flares-extend=[=yes|no] - Discard candidates where both roads extend
beyond the point where they meet.

more-roads-meet-roundabout=[=yes|no] - Discard candidates where the point
where the roads meet contains more roads directly
connecting to the roundabout. Default yes.

multiple-flares=[=yes|no] -  Discard candidates where the next node of a
continuation of one of the roads has a road leading directly to the
roundabout, forming a bigger flare. Commonly encountered where adjacent
flares cross. Default yes.

different-names=[=yes|no] - Discard candidates where the two roads have
different names and neither name
is a substring of the other. Default yes.

Specifying -- max-flare-length-ratio would set the
max-flare-to-separation-multiple value and display an error message saying
the option had been deprecated.

At the moment I have all the rules hard coded to the default values
mentioned above. I am asking for feedback on whether the rules would be
better placed in a rules file, or in a command line option, i.e. either
--roundabout-flare-rules=LIST-OF-RULES or
--roundabout-flare-rules-file=FILENAME.

Also, if you have any ideas for more rules that could be used to remove
unwanted flare candidates then I could look at including them. Ideally, I
would like to compare the Garmin type code of the two roads, but I can't see
how to get to it from a RoadDef. Perhaps you can suggest how this can be
achieved?

When a candidate is discarded,  a message is logged, so it is also possible
to use those messages to identify errors in the OSM data (I found and
corrected a few name typos by looking at the roads discarded because of
having different names).

If you think any of the keywords could be improved, please let me know. I
realise that some of the rules really need pictures to describe how they
operate!

Regards,
Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20200727/f1083188/attachment-0001.html>