Hi Steve, the current code in NodCheck (NodFile.java) stops reading route nodes when if (low == 0 && flags == 0) return null; The code in mkgmap may write route nodes where both values are 0. If I got that right this happens when the node is (one of) the last nodes in a route center. IIGTR the value also depends on the constant NODHeader.DEF_ALIGN With current mkgmap the nodes in one route center are sorted by position. NodCheck doesn't seem to verify this so I assume there is no need for this order. Maybe the nodes in Garmin maps have a different order? For example, nodes with flags == 0 could come first? Gerd
Hi Gerd
the current code in NodCheck (NodFile.java) stops reading route nodes when if (low == 0 && flags == 0) return null;
Yes your right that check is not needed, because we know the correct size of the section. I've found a few cases where it is wrong since there is only a single spare zero byte at the end of the center.
The code in mkgmap may write route nodes where both values are 0. If I got that right this happens when the node is (one of) the last nodes in a route center.
On the other hand I couldn't find any cases in my maps of flags being 0x00. In fact none with the top nibble as 0.
With current mkgmap the nodes in one route center are sorted by position. NodCheck doesn't seem to verify this so I assume there is no need for this order. Maybe the nodes in Garmin maps have a different order? For example, nodes with flags == 0 could come first?
Garmin maps appear to sorted by position - at least by longitude, although maybe not latitude as mkgmap does. It is possible that there is some secondary sort condition that we have not found yet. From what I've just found there seems to be some kind of sorting on destclass. The first center tends to be all destclass=0 and the last one destclass=4. Steve
Hi Steve, yes, mkgmap already groups the centers by the result of the getGroup() method. With my latest patch it first write those nodes which have no arcs. Nodes in one center are sorted by longitude and latitude, and I also think that Garmin uses this order. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Steve Ratcliffe <steve@parabola.me.uk> Gesendet: Mittwoch, 8. Juli 2020 18:34 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Crash in NodCheck Hi Gerd
the current code in NodCheck (NodFile.java) stops reading route nodes when if (low == 0 && flags == 0) return null;
Yes your right that check is not needed, because we know the correct size of the section. I've found a few cases where it is wrong since there is only a single spare zero byte at the end of the center.
The code in mkgmap may write route nodes where both values are 0. If I got that right this happens when the node is (one of) the last nodes in a route center.
On the other hand I couldn't find any cases in my maps of flags being 0x00. In fact none with the top nibble as 0.
With current mkgmap the nodes in one route center are sorted by position. NodCheck doesn't seem to verify this so I assume there is no need for this order. Maybe the nodes in Garmin maps have a different order? For example, nodes with flags == 0 could come first?
Garmin maps appear to sorted by position - at least by longitude, although maybe not latitude as mkgmap does. It is possible that there is some secondary sort condition that we have not found yet. From what I've just found there seems to be some kind of sorting on destclass. The first center tends to be all destclass=0 and the last one destclass=4. Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi
the current code in NodCheck (NodFile.java) stops reading route nodes when if (low == 0 && flags == 0) return null;
Yes your right that check is not needed, because we know the correct size of the section.
Sorry this is wrong; we know the size of the section but the entries are variable size and there has to be a way to know when we have found the last one. I think that flags==0 is the marker. Have you seen any Garmin map with flags==0? It seems to me that a node is either on the boundary or has arcs, or else it is not a routing node. Steve
Hi Steve, I found no node with low==0 and flag==0 in Garmin maps, but I think there are ones with flags==0. I have to double check but I think there are tiles in a demo map for Hungaria. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Steve Ratcliffe <steve@parabola.me.uk> Gesendet: Mittwoch, 8. Juli 2020 21:57 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Crash in NodCheck Hi
the current code in NodCheck (NodFile.java) stops reading route nodes when if (low == 0 && flags == 0) return null;
Yes your right that check is not needed, because we know the correct size of the section.
Sorry this is wrong; we know the size of the section but the entries are variable size and there has to be a way to know when we have found the last one. I think that flags==0 is the marker. Have you seen any Garmin map with flags==0? It seems to me that a node is either on the boundary or has arcs, or else it is not a routing node. Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Steve, reg. flags==0: yes, the Hungary demo map contains nodes with flags==0 but it might not be a good example map. Routing in this map typically gives weird results in Basecamp. I also see such a node in the transalpin demo map (display tool r552) | | | | | | New node 000000b7 | 00002a | 02 | low 2 000000b8 | 00002b | 00 | Flags 0 | | | : no-arcs destclass=0 000000b9 | 00002c | 26 8f 15 | longitude 11.09533 -218 | | | latitude 46.90902 +344 Routing results look OK in this map but it is probably too small for a test case. Anyway, I think I'll commit your patch for now and try to find out more about special cases with end nodes. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Mittwoch, 8. Juli 2020 22:35 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Crash in NodCheck Hi Steve, I found no node with low==0 and flag==0 in Garmin maps, but I think there are ones with flags==0. I have to double check but I think there are tiles in a demo map for Hungaria. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Steve Ratcliffe <steve@parabola.me.uk> Gesendet: Mittwoch, 8. Juli 2020 21:57 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Crash in NodCheck Hi
the current code in NodCheck (NodFile.java) stops reading route nodes when if (low == 0 && flags == 0) return null;
Yes your right that check is not needed, because we know the correct size of the section.
Sorry this is wrong; we know the size of the section but the entries are variable size and there has to be a way to know when we have found the last one. I think that flags==0 is the marker. Have you seen any Garmin map with flags==0? It seems to me that a node is either on the boundary or has arcs, or else it is not a routing node. 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 Gerd
With current mkgmap the nodes in one route center are sorted by position. NodCheck doesn't seem to verify this so I assume there is no need for this order.
I've looked at this again. There was code to check the sorting, but I didn't give an error because it wasn't working out. Changing the check to be only on longitude does work out though, so I will change the NodCheck code to check that. Sorting by latitude as well maybe harmless, unless there is another secondary sort that we don't know about. Steve
participants (3)
-
Gerd Petermann -
Gerd Petermann
-
Steve Ratcliffe