Hi, In the last couple of years I have been making maps with mkgmap for both the UK and various continental countries. One problem that I have never been able to fix until now is that the "drive-on-left" flag didn't seem to have any effect on roundabouts in the UK. The "impact" is limited because roundabouts are one way anyway, but the pictographic representations of roundabouts always assume drive-on-right so you appear to be directed to drive the wrong way. I took a look at the code and saw that the drive-on-left and drive-on-right flags are only used to set a flag in NODHeader.java. However I just discovered ImgTool[1] which exposes the "TRE parameters", a sequence of four numbers which, I noticed, include a flag for "drive-on-left". This was not being set on my UK maps (despite using the drive-on-left option for mkgmap) so they all appeared to be drive-on-right. With ImgTool I was able to simply set this bit in my img file - and then the problems with the roundabout direction disappeared! I am not really a Java programmer so I don't feel confident about trying to fix this myself, but it seems there is related code in TREHeader.java including the following declarations: public static final int POI_FLAG_TRANSPARENT = 0x2; public static final int POI_FLAG_STREET_BEFORE_HOUSENUMBER = 0x4; public static final int POI_FLAG_POSTALCODE_BEFORE_CITY = 0x8; I think it just needs something like this adding: public static final int POI_FLAG_DRIVE_ON_LEFT = 0x20; plus the code to set this bit depending on the drive-on-left flag. It would be great if this could be changed in mkgmap. If I should really be logging this elsewhere please accept my apologies and point to me to the right place and I will enter the details there. Best regards (and thanks everyone for a tremendous program!) Colin [1] https://sites.google.com/site/sherco40/imgtool [1] Links: ------ [1] https://sites.google.com/site/sherco40/imgtool
On 05/08/13 19:30, Colin Smale wrote:
I took a look at the code and saw that the drive-on-left and drive-on-right flags are only used to set a flag in NODHeader.java. However I just discovered ImgTool[1] which exposes the "TRE parameters", a sequence of four numbers which, I noticed, include a flag for "drive-on-left". This was not being set on my UK maps (despite using the drive-on-left option for mkgmap) so they all appeared to be drive-on-right. With ImgTool I was able to simply set this bit in my img file - and then the problems with the roundabout direction disappeared!
Very interesting. I've created a patch based on your discovery which is attached. It only works when there is an explicit --drive-on-left flag and not when mkgmap infers it by looking at the direction of roundabouts. How important do you think that is? I think it is much safer to give the flag than letting mkgmap guess which can be wrong for all kinds of reasons. Cheers, ..Steve
Hi Steve, thanks for the patch... any chance of a jar file please? Then I can check it out. Will this find its way into the standard code? As I mentioned I am not a java programmer although I can read and understand it well enough. Thanks again, Colin On 2013-08-06 16:21, Steve Ratcliffe wrote:
On 05/08/13 19:30, Colin Smale wrote:
I took a look at the code and saw that the drive-on-left and drive-on-right flags are only used to set a flag in NODHeader.java. However I just discovered ImgTool[1] which exposes the "TRE parameters", a sequence of four numbers which, I noticed, include a flag for "drive-on-left". This was not being set on my UK maps (despite using the drive-on-left option for mkgmap) so they all appeared to be drive-on-right. With ImgTool I was able to simply set this bit in my img file - and then the problems with the roundabout direction disappeared!
Very interesting.
I've created a patch based on your discovery which is attached.
It only works when there is an explicit --drive-on-left flag and not when mkgmap infers it by looking at the direction of roundabouts. How important do you think that is? I think it is much safer to give the flag than letting mkgmap guess which can be wrong for all kinds of reasons.
Cheers,
..Steve
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev [1]
Links: ------ [1] http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 06/08/13 21:01, Colin Smale wrote:
Hi Steve, thanks for the patch... any chance of a jar file please? Then I can check it out. Will this find its way into the standard code?
Sure, here you go: http://files.mkgmap.org.uk/download/147/mkgmap.jar Its a simple patch, so I will commit it into the standard code as soon as you've confirmed it and no one else has raised any problems with it. Best wishes ..Steve
Hi Steve, that seems to work perfectly, thanks a lot! I realise this needs the explicit drive-on-left option and won't work with the implied value from the "first roundabout". Personally I can live with that very easily, but I wonder if the final value of that "implication" could be propagated to the TRE header somehow, so it is simpler to document and understand? Any idea if the "base map" vs. "detail map" flag (0x01) is important? I noticed that the maps produced by mkgmap are "base maps" whereas Garmin's own maps are "detail maps". Similarly with the "background=water" vs "background=land" (0x10) which ImgTool also reveals. Colin On 2013-08-06 23:46, Steve Ratcliffe wrote:
On 06/08/13 21:01, Colin Smale wrote:
Hi Steve, thanks for the patch... any chance of a jar file please? Then I can check it out. Will this find its way into the standard code?
Sure, here you go:
http://files.mkgmap.org.uk/download/147/mkgmap.jar [1]
Its a simple patch, so I will commit it into the standard code as soon as you've confirmed it and no one else has raised any problems with it.
Best wishes ..Steve
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev [2]
Links: ------ [1] http://files.mkgmap.org.uk/download/147/mkgmap.jar [2] http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi
live with that very easily, but I wonder if the final value of that "implication" could be propagated to the TRE header somehow, so it is simpler to document and understand?
The way that the implied value is transmitted to the NOD header does not work in the case that you have max-jobs greater than one and you are compiling files with differing left/right sides. So I am not keen to extend that any further.
Any idea if the "base map" vs. "detail map" flag (0x01) is important? I
It can't be that important, given that have survived this long without it. But I think we should set it. Could you let me know which byte in the header it is or create a patch.
noticed that the maps produced by mkgmap are "base maps" whereas Garmin's own maps are "detail maps". Similarly with the "background=water" vs "background=land" (0x10) which ImgTool also reveals.
I don't know anything about this one. It sounds like it might be important though. ..Steve
Hi Steve and list, Thanks very much for committing that change! On 2013-08-13 10:50, Steve Ratcliffe wrote:
Hi
live with that very easily, but I wonder if the final value of that "implication" could be propagated to the TRE header somehow, so it is simpler to document and understand?
The way that the implied value is transmitted to the NOD header does not work in the case that you have max-jobs greater than one and you are compiling files with differing left/right sides. So I am not keen to extend that any further. ...
noticed that the maps produced by mkgmap are "base maps" whereas Garmin's own maps are "detail maps". Similarly with the "background=water" vs "background=land" (0x10) which ImgTool also reveals.
I don't know anything about this one. It sounds like it might be important though.
As I think you mentioned earlier, the "left/right implication" code may not be used very often in practice. Removing that code, allowing it to default to drive-on-right and needing to set the option for the drive-on-left countries sounds to me like it should be acceptable. What we have now is really that already; drive-on-left won't actually work fully unless you set the flag explicitly.
Any idea if the "base map" vs. "detail map" flag (0x01) is important? I
It can't be that important, given that have survived this long without it. But I think we should set it. Could you let me know which byte in the header it is or create a patch.
This is what ImgTool shows now for a UK map: 63260001 TRE 12061 Fat: C00h Data section: 2AE000h Date: 07.08.2013 00:56:14 MapID: 03C54561 (63260001) Priority: 26 TRE parameters: 1 3 17 32 (Basemap - Not transparent - Display house # before street - Display PCode after city - Background: land - Driving side is left) Coordinates: N: 51.503906 S: 49.086914 O:-9.096680 E:-4.262695 Levels [15,16,18,20,22,24], Zoom [85,4,3,2,1,0] Map data (c) OpenStreetMap and its contributors http://www.openstreetmap.org/copyright This map data is made available under the Open Database License: http://opendatacommons.org/licenses/odbl/1.0/ Any rights in individual contents of the database are licensed under the Database Contents License: http://opendatacommons.org/licenses/dbcl/1.0/ Map created with mkgmap-r2661M Program released under the GPL The "TRE parameters" are coming out as 1,3,17,32 where the fourth number (32) corresponds to the flags shown on the "TRE parameters" dialog when you click the button at top left. When I saw "drive on left" I went searching though the source code and found that these bits seemed to correspond to the declarations in TREHeader.java: public static final int POI_FLAG_TRANSPARENT = 0x2; public static final int POI_FLAG_STREET_BEFORE_HOUSENUMBER = 0x4; public static final int POI_FLAG_POSTALCODE_BEFORE_CITY = 0x8; Now there is a value (0x20) added for drive-on-left as well. Judging by ImgTool's output, we could add: public static final int POI_FLAG_DETAILMAP = 0x1; public static final int POI_FLAG_BACKGROUND_IS_WATER = 0x10; But as ImgTool allows you to manipulate the values directly, we can experiment with these two to see what the effect is before making any changes to mkgmap. I will certainly give this a try, but I don't think I know enough about all the places to look for possible effects so it would be good if others can comment as well. BTW, ImgTool is here: https://sites.google.com/site/sherco40/imgtool [1] Download here: https://sites.google.com/site/sherco40/ImgTool1.7.4.zip?attredirects=0
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev [1]
Links: ------ [1] http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev Links: ------ [1] https://sites.google.com/site/sherco40/imgtool
Hi,
noticed that the maps produced by mkgmap are "base maps" whereas Garmin's own maps are "detail maps". Similarly with the "background=water" vs "background=land" (0x10) which ImgTool also reveals.
I don't know anything about this one. It sounds like it might be important though.
yes, if these flags can be used to avoid saving land and water polygons I guess it could save some space and time. Gerd
Am 06.08.2013 16:21, schrieb Steve Ratcliffe:
I think it is much safer to give the flag than letting mkgmap guess which can be wrong for all kinds of reasons. Hi Steve, I don't think this is a good solution. If you think mkgmap guessing is not good enough, then this should be removed at all. It's hard to understand, why some parts of "drive-on-left" works automatical and others doesn't.
Btw.: If it's necessary to set --drive-on-left to get everything you need for such a map, then we can remove also the automatism, because everyone will set the param ;) Henning
Hi
Btw.: If it's necessary to set --drive-on-left to get everything you need for such a map, then we can remove also the automatism, because everyone will set the param ;)
I'm in favour of removing the guessing. In addition to the problem that it might be wrong because of bad data or two countries in the same tile (the UK/France is particularly likely), the code is not thread safe and so could cause extra tiles to have the wrong flag when used with --max-jobs. I realise that it probably works 99 times out of a 100 or even more, but when it does fail there is no possible warning or clue as to what might have happened. ..Steve
Hi
Btw.: If it's necessary to set --drive-on-left to get everything you need for such a map, then we can remove also the automatism, because everyone will set the param ;)
I'm in favour of removing the guessing. In addition to the problem that it might be wrong because of bad data or two countries in the same tile (the UK/France is particularly likely), the code is not thread safe and so could cause extra tiles to have the wrong flag when used with --max-jobs.
I realise that it probably works 99 times out of a 100 or even more, but when it does fail there is no possible warning or clue as to what might have happened.
..Steve
Hi Steve, attached patch forwards the "guessed" drive-on-left value in a thread safe way to the NOD header by using a ThreadLocal variable. This is a small code change. Anyhow this makes only sense if you think that the guess algorithm is ok. WanMil
Hi
Btw.: If it's necessary to set --drive-on-left to get everything you need for such a map, then we can remove also the automatism, because everyone will set the param ;)
I'm in favour of removing the guessing. In addition to the problem that it might be wrong because of bad data or two countries in the same tile (the UK/France is particularly likely), the code is not thread safe and so could cause extra tiles to have the wrong flag when used with --max-jobs.
I realise that it probably works 99 times out of a 100 or even more, but when it does fail there is no possible warning or clue as to what might have happened.
..Steve
Hi Steve,
attached patch forwards the "guessed" drive-on-left value in a thread safe way to the NOD header by using a ThreadLocal variable. This is a small code change. Anyhow this makes only sense if you think that the guess algorithm is ok.
WanMil
I have commited the patch although it does not solve all problems. I found out that the driveOnLeft flag is always set to false if precompiled sea is used and there are mixed sea/land areas in the tile. The reason is that loading of precompiled sea tiles uses a MapDataSource that instantiates a StyledConverter without any config parameters. Therefore the driveOnLeft flag is always set to false. I will fix that soon. WanMil
Thanks for this WanMil! Although the original patch appeared to work at first, it turned out to work in some areas and not in others. I was trying to find some kind of logic in what worked and what didn't, but I think you hit the nail on the head. I just tried it out with the v2671 jar and it's looking good so far. Colin On 2013-08-18 20:13, WanMil wrote:
Hi Btw.: If it's necessary to set --drive-on-left to get everything you need for such a map, then we can remove also the automatism, because everyone will set the param ;) I'm in favour of removing the guessing. In addition to the problem that it might be wrong because of bad data or two countries in the same tile (the UK/France is particularly likely), the code is not thread safe and so could cause extra tiles to have the wrong flag when used with --max-jobs. I realise that it probably works 99 times out of a 100 or even more, but when it does fail there is no possible warning or clue as to what might have happened. ..Steve Hi Steve, attached patch forwards the "guessed" drive-on-left value in a thread safe way to the NOD header by using a ThreadLocal variable. This is a small code change. Anyhow this makes only sense if you think that the guess algorithm is ok. WanMil
I have commited the patch although it does not solve all problems. I found out that the driveOnLeft flag is always set to false if precompiled sea is used and there are mixed sea/land areas in the tile. The reason is that loading of precompiled sea tiles uses a MapDataSource that instantiates a StyledConverter without any config parameters. Therefore the driveOnLeft flag is always set to false. I will fix that soon. WanMil _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev [1] Links: ------ [1] http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Colin, thanks for testing! I found one additional location where the drive-on-left flag was set wrong (coastlinefile option) but that was easy to fix too. I hope that's all now :-) WanMil
Thanks for this WanMil! Although the original patch appeared to work at first, it turned out to work in some areas and not in others. I was trying to find some kind of logic in what worked and what didn't, but I think you hit the nail on the head. I just tried it out with the v2671 jar and it's looking good so far.
Colin
On 2013-08-18 20:13, WanMil wrote:
Hi
Btw.: If it's necessary to set --drive-on-left to get everything you need for such a map, then we can remove also the automatism, because everyone will set the param ;) I'm in favour of removing the guessing. In addition to the problem that it might be wrong because of bad data or two countries in the same tile (the UK/France is particularly likely), the code is not thread safe and so could cause extra tiles to have the wrong flag when used with --max-jobs. I realise that it probably works 99 times out of a 100 or even more, but when it does fail there is no possible warning or clue as to what might have happened. ..Steve Hi Steve, attached patch forwards the "guessed" drive-on-left value in a thread safe way to the NOD header by using a ThreadLocal variable. This is a small code change. Anyhow this makes only sense if you think that the guess algorithm is ok. WanMil I have commited the patch although it does not solve all problems.
I found out that the driveOnLeft flag is always set to false if precompiled sea is used and there are mixed sea/land areas in the tile. The reason is that loading of precompiled sea tiles uses a MapDataSource that instantiates a StyledConverter without any config parameters. Therefore the driveOnLeft flag is always set to false.
I will fix that soon.
WanMil
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi, WanMil wrote:
attached patch forwards the "guessed" drive-on-left value in a thread safe way to the NOD header by using a ThreadLocal variable. This is a small code change. Anyhow this makes only sense if you think that the guess algorithm is ok.
Shouldn't it be a TRE header? Or TRE header too? According to help for options, guessing is connected with "check-roundabouts", which revers directions of roundabouts. This option is wrong for tiles, that contain multiple countries with different drive-on rules. In that case "check-roundabouts" would damage some good roundabouts. If you make a map for a single country, you don't need guessing. And you can't invoke guessing for a map with multiple countries. So this guessing feature looks rather redundant. In my opinion there should be no guessing but a simple count. If a tile has more than 50% of roundabouts as drive-on-left, then this tile should be marked as drive-on-left. That way most of roundabouts would look correctly when navigating. Perfect solution would be to make tile splitting along country border. But if we can't do that, then maybe we could get statistically best settings for drive-on flags? -- Best regards, Andrzej
Hi Andrzej,
attached patch forwards the "guessed" drive-on-left value in a thread safe way to the NOD header by using a ThreadLocal variable. This is a small code change. Anyhow this makes only sense if you think that the guess algorithm is ok.
Shouldn't it be a TRE header? Or TRE header too? If we use guessing, yes, TRE header too.
According to help for options, guessing is connected with "check-roundabouts", which revers directions of roundabouts. This option is wrong for tiles, that contain multiple countries with different drive-on rules. In that case "check-roundabouts" would damage some good roundabouts.
well, "check-roundabouts" also enables some checks in RouteNode regarding overlapping and forking of roundabouts. I do not yet understand the meaning of them.
If you make a map for a single country, you don't need guessing. And you can't invoke guessing for a map with multiple countries. So this guessing feature looks rather redundant.
+1
In my opinion there should be no guessing but a simple count. If a tile has more than 50% of roundabouts as drive-on-left, then this tile should be marked as drive-on-left. That way most of roundabouts would look correctly when navigating.
+1, esp. if you take care to have reasonable tile borders. In my eyes, a value near 50% should produce a warning.
Perfect solution would be to make tile splitting along country border. But if we can't do that, then maybe we could get statistically best settings for drive-on flags?
That's a very interesting point. If I got that right, the IMG format doesn't require a rectangular tile border, so we would need some changes: 1) tile splitter should allow to create such tiles. The bounding polygon option was a first step into this direction. 2) tile splitter has to pass the information about the used polygon within each tile. I don't know an "official" way, so maybe this means to add a way with a tag like splitter:tile-border which has to be filtered by mkgmap? Gerd
Can't you use mkgmap:country=* in the style files to set the drive-on-left flags?
If you make a map for a single country, you don't need guessing. And you can't invoke guessing for a map with multiple countries. So this guessing feature looks rather redundant.
In my opinion there should be no guessing but a simple count. If a tile has more than 50% of roundabouts as drive-on-left, then this tile should be marked as drive-on-left. That way most of roundabouts would look correctly when navigating.
Perfect solution would be to make tile splitting along country border. But if we can't do that, then maybe we could get statistically best settings for drive-on flags?
-- Best regards, Andrzej
Hi Minko,
Can't you use mkgmap:country=* in the style files to set the drive-on-left flags?
that doesn't solve the problem that a tile can contain data from two (or more) different countries with different with drive-on-left settings. See e.g. http://www.rent-a-car-international.com/ Gerd
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yes, but it should be unique in each country. So it should be possible to use a mkgmap:drive_on=left or something similar. Henning -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (MingW32) iQEcBAEBAgAGBQJShjTpAAoJEPFgsWC7jOeTxdUIAOKwTZz3AIHGTnAvxw3p+xoB 8uNZ66gdz2dcCggyca+Gvba/8/SLQQNgofn4O9PnCszwRTLer1SXKcIragTcr8ji rZTyiyhb6T1zDR0OoVbri8gvXDvdSoriS9ADWPMj0riDFyeENT5oG6UXekwXJneT SSb4FnK0no959WD8+kXVjIQqy/+ivAW5oKmLdvnMCZyStjFNNGyS5nIMNdVED+lE 0zZWojL4pTVYVNKjMzzuBBbs78oL9Byv5nUIGDaVf331AT/RQyIHYNkwbFFIsg+A CNAy0qhMeXPKjaSYdu/6ak1kl0S7zBvLfUyIDmIbU8oA8aE0/23uuH+Zq3q8sRA= =e2qK -----END PGP SIGNATURE-----
Yes, but it should be unique in each country. So it should be possible to use a mkgmap:drive_on=left or something similar.
sure, but what could mkgmap do with it if a tile contains more than one country? The problem is that we cannot store the drive-on-left for each roundabout. The info is stored once for each tile (well, once in TRE, once in NOD) Gerd
participants (7)
-
Andrzej Popowski -
Colin Smale -
Gerd Petermann -
Henning Scholland -
Minko -
Steve Ratcliffe -
WanMil