Hi Andrzej,
I have assumed, that option --check-roundabout gets a new algorithm, the one that you have described. I would prefer that use of "dol/dor" counting was controlled by user and option --check-roundabouts looks prefect for this purpose. The counting is simple and needs only only a few HashMap lookups. The question is what we do with the values.
I think that flags in IMG should be consistent, the one you have mentioned in NOD and a flag in TRE. So any decision about drive-on-left/right should be taken once and should force setting of both flags.
Ah, I did not think about TRE header until now. BTW: The current implementation in trunk sets the flag in the TRE header only if option drive-on-left is set, it ignores the results of the check-roundabout option.
My idea is that user can select following processing:
- Automatic detection of left/right by using --check-roundabout with options --drive-on-left/right as a fallback.
- Forced setting with option --drive-on-left/right alone.
- Default setting when no options are used. Defaults could be taken from LocatorConfig.xml or simply set as drive-on-right (hope this is more common).
This description also defines priority of processing, with "dol/dor" counting as a first choice, but only if user set explicit option.
I am not sure if you understand what check-roundabouts is doing. It determines whether a roundabout is clockwise or not and changes the order if it doesn't match. The first roundabout is used to find out if left or right is correct. The test data contains a few cases where roundabouts in the UK have the wrong direction, I don't know if this is still the case. So, in my eyes the user sets check-roundabouts to make sure that all round-abouts are either clockwise or ccw, and he uses --drive-on-left or --drive-on-right to avoid the weak auto-detection. Gerd