Hi @all, I try to render for some larger countries like China also province boundaries as well. (admin_level=4 additional to level 2). But don't want to show those in Mongolia for example. Therefore I write some intermediate tag to all level4-ways and then use the mkgmap:country tag in lines file to only show them in China. Unfortunately it's not very precise (ok it's logical). See attached screen shot. Red marked boundary line is missing, blue ones are shown, but shouldn't. Anyone has an idea how to solve this issue? I thought maybe use subarea of admin relations, but first they are not very common in OSM and 2nd, not sure how to code it in relations file. Henning *relations:* ( type=boundary | type=multipolygon ) & boundary=administrative & admin_level=4 { apply { set rrk:boundary:province=yes } } ( type=boundary | type=multipolygon ) & boundary=administrative & admin_level=2 { apply { set rrk:boundary:country=yes } } *lines:* rrk:boundary:country=yes [0x10017 level 8 continue] rrk:boundary:province=yes & ( mkgmap:country=CHN | mkgmap:country=AUS) & rrk:boundary:country!=yes [0x1010f level 7 continue]
Hi Henning, does your style include 'inc/address' before rules for boundaries? Default style doesn't make it easy to use mkgmap:country, which is actually generated after all rules in finalize stage. -- Best regards, Andrzej
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
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
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
Hi Gerd, while checking the process with echotags function, I can confirm the mkgmap:country tag is set wrong, but set. Henning
Hi Henning, for a way with 2 nodes n/2 gives 1, and the nodes are numbered starting with 0, so the n/2 node is the last, not the first. The last is in the north. Maybe it would be better to calculate the position of the middle for a way with just 2 nodes, at least this would solve this problem and it should not produce new problems. I'll check your sample file tomorrow. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Henning Scholland <osm@hscholland.de> Gesendet: Donnerstag, 12. Juli 2018 17:30 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Admin relations Hi Gerd, while checking the process with echotags function, I can confirm the mkgmap:country tag is set wrong, but set. Henning _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Henning, cannot find a problem in source.osm. I've tried with an old bounds.zip and with the current one from http://osm2.pleiades.uni-wuppertal.de/bounds/latest/bounds.zip With both the LocationHook sets mkgmap:admin_level2=MNG for the two admin_level 4 ways. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Donnerstag, 12. Juli 2018 19:16 An: Henning Scholland; Development list for mkgmap Betreff: Re: [mkgmap-dev] Admin relations Hi Henning, for a way with 2 nodes n/2 gives 1, and the nodes are numbered starting with 0, so the n/2 node is the last, not the first. The last is in the north. Maybe it would be better to calculate the position of the middle for a way with just 2 nodes, at least this would solve this problem and it should not produce new problems. I'll check your sample file tomorrow. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Henning Scholland <osm@hscholland.de> Gesendet: Donnerstag, 12. Juli 2018 17:30 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Admin relations Hi Gerd, while checking the process with echotags function, I can confirm the mkgmap:country tag is set wrong, but set. 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
Hi, I've implemented the small change for two node ways in r4195. As expected it fixes the problem for the way in China. In my previous post I forgot to add "in Mongolia" after "the two admin_level 4 ways.". Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Freitag, 13. Juli 2018 06:50 An: Henning Scholland; Development list for mkgmap Betreff: Re: [mkgmap-dev] Admin relations Hi Henning, cannot find a problem in source.osm. I've tried with an old bounds.zip and with the current one from http://osm2.pleiades.uni-wuppertal.de/bounds/latest/bounds.zip With both the LocationHook sets mkgmap:admin_level2=MNG for the two admin_level 4 ways. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Donnerstag, 12. Juli 2018 19:16 An: Henning Scholland; Development list for mkgmap Betreff: Re: [mkgmap-dev] Admin relations Hi Henning, for a way with 2 nodes n/2 gives 1, and the nodes are numbered starting with 0, so the n/2 node is the last, not the first. The last is in the north. Maybe it would be better to calculate the position of the middle for a way with just 2 nodes, at least this would solve this problem and it should not produce new problems. I'll check your sample file tomorrow. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Henning Scholland <osm@hscholland.de> Gesendet: Donnerstag, 12. Juli 2018 17:30 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Admin relations Hi Gerd, while checking the process with echotags function, I can confirm the mkgmap:country tag is set wrong, but set. 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 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, thanks for the fix, for the issue on Chinese side of the border it works fine. Henning On 13.07.2018 13:19, Gerd Petermann wrote:
Hi,
I've implemented the small change for two node ways in r4195. As expected it fixes the problem for the way in China. In my previous post I forgot to add "in Mongolia" after "the two admin_level 4 ways.".
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Freitag, 13. Juli 2018 06:50 An: Henning Scholland; Development list for mkgmap Betreff: Re: [mkgmap-dev] Admin relations
Hi Henning,
cannot find a problem in source.osm. I've tried with an old bounds.zip and with the current one from http://osm2.pleiades.uni-wuppertal.de/bounds/latest/bounds.zip With both the LocationHook sets mkgmap:admin_level2=MNG for the two admin_level 4 ways.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Donnerstag, 12. Juli 2018 19:16 An: Henning Scholland; Development list for mkgmap Betreff: Re: [mkgmap-dev] Admin relations
Hi Henning, for a way with 2 nodes n/2 gives 1, and the nodes are numbered starting with 0, so the n/2 node is the last, not the first. The last is in the north.
Maybe it would be better to calculate the position of the middle for a way with just 2 nodes, at least this would solve this problem and it should not produce new problems.
I'll check your sample file tomorrow.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Henning Scholland <osm@hscholland.de> Gesendet: Donnerstag, 12. Juli 2018 17:30 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Admin relations
Hi Gerd,
while checking the process with echotags function, I can confirm the mkgmap:country tag is set wrong, but set.
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 _______________________________________________ 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 all, the problem with e.g. Way 41230883 in Hennings real input data is this: The LocationHook is used for all ways in the input file and the ways are not yet trimmed to the bounding box. Now, with Hennings input file, the n/2-th point lies outside of the bbox, this node is ignored and mkgmap tries the first node (0) as next alternative. This node lies on the boundary between CHN and MNG, the returned result is more or less unpredictable. I am not yet sure how to handle this. Working on it. Gerd Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Henning Scholland <osm@hscholland.de> Gesendet: Freitag, 13. Juli 2018 16:21 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Admin relations Hi Gerd, thanks for the fix, for the issue on Chinese side of the border it works fine. Henning On 13.07.2018 13:19, Gerd Petermann wrote:
Hi,
I've implemented the small change for two node ways in r4195. As expected it fixes the problem for the way in China. In my previous post I forgot to add "in Mongolia" after "the two admin_level 4 ways.".
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Freitag, 13. Juli 2018 06:50 An: Henning Scholland; Development list for mkgmap Betreff: Re: [mkgmap-dev] Admin relations
Hi Henning,
cannot find a problem in source.osm. I've tried with an old bounds.zip and with the current one from http://osm2.pleiades.uni-wuppertal.de/bounds/latest/bounds.zip With both the LocationHook sets mkgmap:admin_level2=MNG for the two admin_level 4 ways.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Donnerstag, 12. Juli 2018 19:16 An: Henning Scholland; Development list for mkgmap Betreff: Re: [mkgmap-dev] Admin relations
Hi Henning, for a way with 2 nodes n/2 gives 1, and the nodes are numbered starting with 0, so the n/2 node is the last, not the first. The last is in the north.
Maybe it would be better to calculate the position of the middle for a way with just 2 nodes, at least this would solve this problem and it should not produce new problems.
I'll check your sample file tomorrow.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Henning Scholland <osm@hscholland.de> Gesendet: Donnerstag, 12. Juli 2018 17:30 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Admin relations
Hi Gerd,
while checking the process with echotags function, I can confirm the mkgmap:country tag is set wrong, but set.
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 _______________________________________________ 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
Sorry, I just realised after opening tile borders in jOSM, the split is just at tile border. Henning
participants (3)
-
Andrzej Popowski -
Gerd Petermann -
Henning Scholland