Manage drive-on-left/drive-on-right in resources\LocatorConfig.xml
Hi all, this point is on the to do list, but I am not sure what the target is. I guess it should replace the two options drive-on-right and drive-on-left. ("dor","dol") A possible implementation looks like this: 1) add property driveOnLeft="true" to the appropriate countries in LocatorConfig.xml 2) add methods to lookup the property for a given roundabout 3) count the number of "dol" and "dor" roundabouts 4) If neither the --drive-on-left option or --drive-on-right option is set, use the counters: if the "dol" number is larger than the "dor" number, set the "dol" flag in the NOD header to 1. So far so easy. I guess in most usage cases one of the counters is 0 and the other is not, so that would work fine. Open questions: 1) What should happen for those tiles containing both "dol" and "dor" roundabouts? 2) What should happen if the --drive-on-left option is given and the tile contains only "dor" roundabouts (or vice-versa) ? Should we ignore the option given by the user and print a corresponding warning? 3) We have the --check-roundabouts option which also might set the flag in the NOD header if the user doesn't specify --drive-on-left or --drive-on-right. The current implementation simply uses the direction of first roundabout (clockwise or not) to decide which driving side is to be used and it reverses the direction of all following roundabouts which don't match the direction of the first one. I assume this should be changed so that we use the above counters as well? @Steve: The data in the LocatorConfig.xml seems to be only used in combination with the --bounds option, without precompiled bounds the default style will not set mkgmap:country which is used to get the data from the LocatorConfig.xml. I did expect that an option like --country-name or --country-abbr could be used to set a default, and the code really passes the values to a method in Locator called setDefaultCountry(), but that method is only adding /overwriting a HashMap of country-name+iso-code which is filled from LocatorConfig.xml . Is that intended?
Hi Gerd, my suggestion is to use following priority: 1. If there is option --check-roundabouts then use roundabouts to define drive-on setting. 2. Use option dirve-on-left/drive-on-right. 3. Use value from LocatorConfig.xml. 4. Set drive-on-right. When using --check-roundabouts, count "dol" and "dor" and select drive-on-xxx, for which there is more roundabouts. If number of "dol" == "dor", then move to next point in priority list. -- Best regards, Andrzej
Hi Andrzej, in the patch v1 I've implemented a different order. 1) the "dol" and "dor" counters are calculated 2) if neither --drive-on-left nor --drive-on-right is specified and the "dol" counter is higher, set the driving side to drive-on-left. I think I should add code to set drive-on-right else. 3) This happens before check-roundabouts is used. because I don't like the idea that check-roundabouts depends on the first found roundabout, which might be wrong in the OSM data or simply the only "dol" one in a large "dor" area. I think the option --drive-on-left or --drive-on-right should always be stronger if we keep them. Gerd
Date: Wed, 26 Nov 2014 13:40:30 +0100 From: popej@poczta.onet.pl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Manage drive-on-left/drive-on-right in resources\LocatorConfig.xml
Hi Gerd,
my suggestion is to use following priority: 1. If there is option --check-roundabouts then use roundabouts to define drive-on setting. 2. Use option dirve-on-left/drive-on-right. 3. Use value from LocatorConfig.xml. 4. Set drive-on-right.
When using --check-roundabouts, count "dol" and "dor" and select drive-on-xxx, for which there is more roundabouts. If number of "dol" == "dor", then move to next point in priority list.
-- Best regards, Andrzej
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, 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. 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. 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. -- Best regards, Andrzej
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
Hi Gerd,
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.
I haven't thought about correcting roundabouts. So maybe better leave it as option to rebuild wrong roundabouts but use some other option to detect of driving side? For example: drive-on=detect (count "dol/dor") drive-on=left (the same as drive-on-left) drive-on=detect,left ("left" as fallback, when "detect" fails) -- Best regards, Andrzej
How can we make the behaviour deterministic where the map area covers both? For example, you can't make a rectangular box around the UK without including bits of France. If the splitter/mkgmap combo decides to start in the bottom right, the whole of the UK will be driving on the right. So I don't see when the "detect" option is realistically going to be useful. Between the UK and France there is a big bit of water, but there are many land borders between dor and dol countries. Can we get a combined map that contains both? Colin On 2014-11-26 17:39, Andrzej Popowski wrote:
Hi Gerd,
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.
I haven't thought about correcting roundabouts. So maybe better leave it as option to rebuild wrong roundabouts but use some other option to detect of driving side?
For example: drive-on=detect (count "dol/dor") drive-on=left (the same as drive-on-left) drive-on=detect,left ("left" as fallback, when "detect" fails)
Hi Colin,
How can we make the behaviour deterministic where the map area covers both?
There is no good solution in this case. Gerd is trying to find which choice would be better, since we are forced to set drive direction for whole tile. The proper solution would be to divide tiles at country border. I think this could be done if splitter/mkgmap would use bounding polygon instead of bounding box to define a tile. -- Best regards, Andrzej
Hi Colin, Colin Smale wrote
How can we make the behaviour deterministic where the map area covers both? For example, you can't make a rectangular box around the UK without including bits of France. If the splitter/mkgmap combo decides to start in the bottom right, the whole of the UK will be driving on the right. So I don't see when the "detect" option is realistically going to be useful. Between the UK and France there is a big bit of water, but there are many land borders between dor and dol countries. Can we get a combined map that contains both?
Yes, would be interesting to know how Garmin solves this problem e.g. in Africa. I don't know how many roundabouts they have which are likely to fall into a mixed area. I think Steve said that it is possible to use boundary nodes which are not all on a straight line, so it would be possible to cut a administrative boundaries. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Manage-drive-on-left-drive-on-right-in-resour... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi Gerd,
Yes, would be interesting to know how Garmin solves this problem e.g. in Africa. I don't know how many roundabouts they have which are likely to fall into a mixed area.
Garmin divides tiles at borders, look for example at City Navigator. cGPSmapper can do this too, you define shape of a tile with background object (0x4B), which can be an irregular polygon. I guess this can be implemented in mkgmap too, only would need more processing then with bounding box. -- Best regards, Andrzej
Hi Andrzej, thanks for the info. I don't have a City Navigator map, but I think I understand now how it could work. I think tt would be very difficult to implement that in splitter but in mkgmap it would probably be possible to do it by changing the clipping methods. Gerd
Date: Wed, 26 Nov 2014 21:39:58 +0100 From: popej@poczta.onet.pl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Manage drive-on-left/drive-on-right in resources\LocatorConfig.xml
Hi Gerd,
Yes, would be interesting to know how Garmin solves this problem e.g. in Africa. I don't know how many roundabouts they have which are likely to fall into a mixed area.
Garmin divides tiles at borders, look for example at City Navigator. cGPSmapper can do this too, you define shape of a tile with background object (0x4B), which can be an irregular polygon. I guess this can be implemented in mkgmap too, only would need more processing then with bounding box.
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, try this free map of Poland: http://ump.waw.pl/update/48000009.zip Unpack it and run install_UMP-topo.bat, this will install map for MapSource. Look at the shape of the tiles at Polish border. I think there could be some easy solutions for splitter. For example use existing areas list and overlay it with map of country areas. Borders will cross some tiles and these tiles could be split again at the borders. Or simply these tiles could be copied with added bounding polygons, different for each copy. Even better would be to make first split with map of countries and then additionally split map inside of each country. I think splitter should require map of countries as an input data, there is no need to guess, which border to use. -- Best regards, Andrzej
Hi Andrzej, thanks for the link, that'll probably help a lot for the non-rectangular tiles stuff. Gerd
Date: Wed, 26 Nov 2014 23:06:49 +0100 From: popej@poczta.onet.pl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Manage drive-on-left/drive-on-right in resources\LocatorConfig.xml
Hi Gerd,
try this free map of Poland: http://ump.waw.pl/update/48000009.zip
Unpack it and run install_UMP-topo.bat, this will install map for MapSource. Look at the shape of the tiles at Polish border.
I think there could be some easy solutions for splitter. For example use existing areas list and overlay it with map of country areas. Borders will cross some tiles and these tiles could be split again at the borders. Or simply these tiles could be copied with added bounding polygons, different for each copy.
Even better would be to make first split with map of countries and then additionally split map inside of each country.
I think splitter should require map of countries as an input data, there is no need to guess, which border to use.
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Gerd Petermann <gpetermann_muenchen@hotmail.com> writes:
thanks for the info. I don't have a City Navigator map, but I think I understand now how it could work. I think tt would be very difficult to implement that in splitter but in mkgmap it would probably be possible to do it by changing the clipping methods.
splitter could just split to rectangles until small enough, and then the clippign could be done producing two. That would result in more tiles than some polygon-aware splitter, but my guess is that the # of extra tiles that could have been avoided will be low enough.
As well as Africa, how about looking at Hong Kong/Macau/China as an example of a busy land border which switches sides, including this work of civil engineering art: http://en.wikipedia.org/wiki/Ponte_Flor_de_L%C3%B3tus How can we make a map for regular travellers between e.g. Shenzen and Hong Kong? Colin On 2014-11-26 18:26, GerdP wrote:
Hi Colin,
Colin Smale wrote
How can we make the behaviour deterministic where the map area covers both? For example, you can't make a rectangular box around the UK without including bits of France. If the splitter/mkgmap combo decides to start in the bottom right, the whole of the UK will be driving on the right. So I don't see when the "detect" option is realistically going to be useful. Between the UK and France there is a big bit of water, but there are many land borders between dor and dol countries. Can we get a combined map that contains both?
Yes, would be interesting to know how Garmin solves this problem e.g. in Africa. I don't know how many roundabouts they have which are likely to fall into a mixed area. I think Steve said that it is possible to use boundary nodes which are not all on a straight line, so it would be possible to cut a administrative boundaries.
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/Manage-drive-on-left-drive-on-right-in-resour... [1] Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev [2]
Links: ------ [1] http://gis.19327.n5.nabble.com/Manage-drive-on-left-drive-on-right-in-resour... [2] http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 26/11/14 09:22, Gerd Petermann wrote:
Hi all,
this point is on the to do list, but I am not sure what the target is. I guess it should replace the two options drive-on-right and drive-on-left. ("dor","dol")
In my opinion all we should do is: 1. Use the option set by the user. 2. If options is not given, look up the countries (from LBL) in the LocatorConfig; if all are drive-on-the-same-side use that. 3. In all other cases (and --route is given) warn loudly. So I'd just ignore roundabouts in the normal case. Obviously --check-roundabouts can make any checks that it likes, it is useful to debug OSM data, its not supposed to be essential to produce a map.
@Steve: The data in the LocatorConfig.xml seems to be only used in combination with the --bounds option, without precompiled bounds the default style will not set mkgmap:country which is used to get the data from the LocatorConfig.xml. I did expect that an option like --country-name or --country-abbr could be used to set a default, and the code really passes the values to a method in Locator called setDefaultCountry(), but that method is only adding /overwriting a HashMap of country-name+iso-code which is filled from LocatorConfig.xml . Is that intended?
Probably not. The --country-* options were added very early on since every POI has to have a country either directly or it has a region that has to have a country. At that time they were defaults for when there was no addr:country on a POI (almost always in those days!). I suppose that if the bounds file is complete there is no need for a default, but I would expect that the --country-name should be used if there isn't one. ..Steve
Hi Steve,
1. Use the option set by the user. +1
2. If options is not given, look up the countries (from LBL) in the LocatorConfig; if all are drive-on-the-same-side use that.
I counted the roundabouts because they seem to be the only affected elements of this flag and I thought it might be easier to find a clean cut between different "dol" and "dor" areas. The code for that is simple enough.
3. In all other cases (and --route is given) warn loudly. OK. I'll change that in my patch.
So I'd just ignore roundabouts in the normal case. Obviously --check-roundabouts can make any checks that it likes, it is useful to debug OSM data, its not supposed to be essential to produce a map.
I never liked the idea that an option called check-xxx is also changing the data, although I am not sure if this still happens today.
Probably not. The --country-* options were added very early on since every POI has to have a country either directly or it has a region that has to have a country. At that time they were defaults for when there was no addr:country on a POI (almost always in those days!).
I suppose that if the bounds file is complete there is no need for a default, but I would expect that the --country-name should be used if there isn't one.
Okay, if I got it right we just have to add a few lines in StyledConverter. I'll post a patch for this. Gerd
participants (6)
-
Andrzej Popowski -
Colin Smale -
Gerd Petermann -
GerdP
-
Greg Troxel -
Steve Ratcliffe