Hi Gerd, the code checks that roundabout flares are oneway and point in the right direction. However, it currently produces more false positives than wanted results. For example, the current version of mkgmap outputs the following false positive messages: Incoming roundabout flare road (http://www.openstreetmap.org/browse/way/14580082) does not start at flare? http://www.openstreetmap.org/?mlat=52.794324&mlon=-2.097365&zoom=17 - this one is picked up by the both-flares-extend rule Incoming roundabout flare road (http://www.openstreetmap.org/browse/way/43246413) does not start at flare? http://www.openstreetmap.org/?mlat=52.809973&mlon=-2.118326&zoom=17 - this one is picked up by the max-flare-angle rule, because the angle between the two roads going to the roundabout at the end of Red Lion Street is greater than 90 degrees. Outgoing roundabout flare road (http://www.openstreetmap.org/browse/way/48683049) is not oneway? http://www.openstreetmap.org/?mlat=53.024112&mlon=-2.183047&zoom=17 - this one is picked up by the max-flare-length-multiple rule. Outgoing roundabout flare road (http://www.openstreetmap.org/browse/way/4283042) is not oneway? http://www.openstreetmap.org/?mlat=52.703440&mlon=-1.997837&zoom=17 - this one I don't currently detect, but if I could compare the Garmin types codes for the roads I would be able to do so. I can't work out how to get to that from a RoadDef or RouteArc though. From what I can see, the Garmin type is held in the MapElement, which MapRoad is derived from. MapRoad contains a RoadDef, but I don't know how to go the opposite way. Any suggestions? The existing code also incorrectly warns that roads point in the wrong direction when they are not oneway because it checks for direction before checking the oneway flay is set. I have used my modified version to detect most of the real incorrect flares in the UK and have fixed them in OSM, so there won't be many real errors of this type in the UK OSM data. Of course there's always the possibility that one of the rules may incorrectly reject a pair of roads as a flare, but by making each rule optional and with variable values they can be tweaked to suit the particular environment. I think it is better to miss the odd real error if a rule gets rid of a large number of false positives. I have included info level message that indicate why candidates have been rejected as flares, so it also possible to examine these messages (I identified and fixed a few typos in road names where one flare's name was spelled differently than the other by looking at these messages). Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 28 July 2020 14:40 To: 'Development list for mkgmap' <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] check-roundabout-flares Hi Mike, since nobody else responded: to be honest: I don't even know what this test is about. Maybe you can post a link to a flare road which should be flagged but isn't and another one which is a false positive? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Mike Baggaley <mike@tvage.co.uk> Gesendet: Montag, 27. Juli 2020 21:22 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] check-roundabout-flares 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