
Hi Gerd, I felt a little strange, as it is the only tile causing this problem. I took a look into the result of splitter, added two nodes with test=country and they were set to the matching country code. As the issues were matching exactly with the tile boundaries, I was thinking maybe it's just swapped for this tile. You are right, the ways are quite long in that area. But for the east level4-border in Mongolia, which is shown, there are plenty of nodes in Mongolia. Even after splitting the way at the tile edge and even on the west level4-border in Mongolia, there are 4 nodes after splitting the way at tile edge. I put relevant data in attachment. Those ways issue doesn't match to your explanation. For the Chinese level4-border it just contains a 2-node way, with or without splitting it on the tile edge. So there is no n/2-node for my understanding of your explanation. The direction of the way is from south-to-north. So the first node should be definitely in China, the last one is on the borderline. Either I got your explanation wrong or there is some issue on that tile. Maybe because of it flat and long shape? If you need I can send you the result of splitter for that tile by private mail. In general it could be a idea to calculate an artificial middle node for 2-node ways to check first, as there is no n/2 one. But as pointed out above, I don't think this is the issue in my case. Henning (Hope you enjoyed the cycling trip) On 12.07.2018 13:19, Gerd Petermann wrote:
Hi Henning,
I think you might hit a problem here because of the way how the LocationHook uses the data in the bounds file. When used for a way with n nodes it first tries to get information for node n/2. If that fails it tries the first, then the last, finally all other nodes. The lines in your screenshot all look straight, so the corresponding OSM ways might have only 2 nodes. In that case the only tested node may be the one on the border between China and Mongolia. I assume that the actual mkgmap:admin_level2 value for those nodes are more or less random or that the value is empty.
If the value for mkgmap:admin_level2 is empty mkgmap should probably try another node. This doesn't happen. I see no easy way to handle this when the value is set.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Henning Scholland <osm@hscholland.de> Gesendet: Donnerstag, 12. Juli 2018 01:58:16 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Admin relations
Hi Andrzej, yes they are both in and in general it's working. Just on the borders I get these issues. I guess it's because of precision, how mkgmap calculates the area of China. The strange thing is, that the missing red part on Chinese border (Inner Mongolia/Gansu) Is roughly from the center of the last way to the end. For the blue marked ways it's shorter than half of it's length. So can't be the reason, a way or so is missing or is ignored completly. It's seems more, that there is kind of buffer, as both has the same length missing. And the both blue ways seems to end at same latitude. Sorry for forgetting the scale on the picture, but it's about 50km length missing/too much.
If it's like this I wonder how mkgmap:country can work for address search in more dense populated areas.
Henning _______________________________________________ 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