Hi While trying to diagnose a indexing problem, I find that a bit code in imgfmt/app/mdr/MdrUtils.java:getGroupForPoi() troublesome: ... * 4-5 Recreation / Entertainment / Attractions * 6 Shopping * 7 Auto Services * 8 Community * 9 ? * */ public static int getGroupForPoi(int fullType) { // We group pois based on their type. This may not be the final thoughts on this. int type = getTypeFromFullType(fullType); int group = 0; if (fullType <= 0xf) group = 1; else if (type >= 0x2a && type <= 0x30) { group = type - 0x28; } else if (type == 0x28) { group = 9; ... type 0x28 is, according to my device, "Island", but not the one that is findable under Geographic Points/Water Features, as used by the default style, which is 0x650c. So, the first question is, does anyone know why 0x28 was given it's own group. The second problem is that the code that builds up the group start indexes into Mdr10 for Mdr9 assumes that the type ranges of the POI allocated for a group are in the same order as the groups, so, if you actually have a POI of type 0x28 then, because it has a lower type but a higher group than the 0x2a..30 range/groups, mdr9 is wrong. Unless there is a good reason to have 0x28=group 9, then the simplest fix is just to remove the lines of code and put in a comment that the types must be in order. I'm trying to fix something else in this area so I can include this in some future patch. Regards Ticker
Hi Ticker
So, the first question is, does anyone know why 0x28 was given it's own group.
I've no idea why, but that is the way it is as far as I could determine.
The second problem is that the code that builds up the group start indexes into Mdr10 for Mdr9 assumes that the type ranges of the POI allocated for a group are in the same order as the groups, so, if you actually have a POI of type 0x28 then, because it has a lower type but a higher group than the 0x2a..30 range/groups, mdr9 is wrong.
I don't see where that happens but that would be wrong and mdr9 should be ordered by group. Cheers Steve
Hi Ticker, I also don't know what 0x28 is, but you are probably right that the code is wrong. A change from LinkedHashMap to TreeMap for field index in MDR9 should fix this, right? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Steve Ratcliffe <steve@parabola.me.uk> Gesendet: Montag, 15. April 2019 23:12 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] MDR 9 & 10 groups Hi Ticker
So, the first question is, does anyone know why 0x28 was given it's own group.
I've no idea why, but that is the way it is as far as I could determine.
The second problem is that the code that builds up the group start indexes into Mdr10 for Mdr9 assumes that the type ranges of the POI allocated for a group are in the same order as the groups, so, if you actually have a POI of type 0x28 then, because it has a lower type but a higher group than the 0x2a..30 range/groups, mdr9 is wrong.
I don't see where that happens but that would be wrong and mdr9 should be ordered by group. Cheers Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd & Steve When I was running with a small example it seemed that the MDR9 was written in group order, each with start record to MDR10 that is calculated on the assumption that MDR10 was also generated in the same group order. However the step in MDR10 caused by a single 0x28/group 9 POI appeared incorrect. Now, with a real map, I'm having trouble working out what is going on and it might be correct. I need to check more carefully. I thought LinkedHashMap did preserve an order. Regards Ticker On Tue, 2019-04-16 at 05:46 +0000, Gerd Petermann wrote:
Hi Ticker,
I also don't know what 0x28 is, but you are probably right that the code is wrong. A change from LinkedHashMap to TreeMap for field index in MDR9 should fix this, right?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Steve Ratcliffe <steve@parabola.me.uk> Gesendet: Montag, 15. April 2019 23:12 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] MDR 9 & 10 groups
Hi Ticker
So, the first question is, does anyone know why 0x28 was given it's own group.
I've no idea why, but that is the way it is as far as I could determine.
The second problem is that the code that builds up the group start indexes into Mdr10 for Mdr9 assumes that the type ranges of the POI allocated for a group are in the same order as the groups, so, if you actually have a POI of type 0x28 then, because it has a lower type but a higher group than the 0x2a..30 range/groups, mdr9 is wrong.
I don't see where that happens but that would be wrong and mdr9 should be ordered by group.
Cheers Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi I was wrong - MDR 9 & 10 are correct regardless of the out-of-order 0x28/group 9. Sorry wasting your time. Ticker On Tue, 2019-04-16 at 11:50 +0100, Ticker Berkin wrote:
Hi Gerd & Steve
When I was running with a small example it seemed that the MDR9 was written in group order, each with start record to MDR10 that is calculated on the assumption that MDR10 was also generated in the same group order. However the step in MDR10 caused by a single 0x28/group 9 POI appeared incorrect.
Now, with a real map, I'm having trouble working out what is going on and it might be correct. I need to check more carefully.
I thought LinkedHashMap did preserve an order.
Regards Ticker
On Tue, 2019-04-16 at 05:46 +0000, Gerd Petermann wrote:
Hi Ticker,
I also don't know what 0x28 is, but you are probably right that the code is wrong. A change from LinkedHashMap to TreeMap for field index in MDR9 should fix this, right?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Steve Ratcliffe <steve@parabola.me.uk> Gesendet: Montag, 15. April 2019 23:12 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] MDR 9 & 10 groups
Hi Ticker
So, the first question is, does anyone know why 0x28 was given it's own group.
I've no idea why, but that is the way it is as far as I could determine.
The second problem is that the code that builds up the group start indexes into Mdr10 for Mdr9 assumes that the type ranges of the POI allocated for a group are in the same order as the groups, so, if you actually have a POI of type 0x28 then, because it has a lower type but a higher group than the 0x2a..30 range/groups, mdr9 is wrong.
I don't see where that happens but that would be wrong and mdr9 should be ordered by group.
Cheers Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, point 0x28 is a label or region name without an icon. Do any Garmin's map include 0x28 in search index? -- Best regards, Andrzej
Hi Andrzej, I've looked at output of mdrDisplay and found some in Deutschland-v3, but I never tried to find out what they are good for. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Mittwoch, 17. April 2019 13:44 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] MDR 9 & 10 groups Hi Gerd, point 0x28 is a label or region name without an icon. Do any Garmin's map include 0x28 in search index? -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (4)
-
Andrzej Popowski -
Gerd Petermann -
Steve Ratcliffe -
Ticker Berkin