Proof of concept for better sea in overview map
Hi, the attached patch improves the overview map, but so far only when precomp-sea is NOT used. I tested it with --generate-sea=multipolygon,floodblocker so that mkgmap really has a multipolygon with the natual=sea data. For each level in the overview map it uses the original multipolygon data to compute the rings which will might visible at the given resolution. This requires more time compared to the current code but the result is much better and some fine tuning is possible. To be able to use this also with --precomp-sea we need some changes in the code which generates sea.zip so that one multipolygon relation for each tile is stored. I've uploaded the results here: https://files.mkgmap.org.uk/download/511/compare.7z What do you think? Gerd
Hi, forgot to mention that the maps were created with these options: --generate-sea=multipolygon,floodblocker --preserve-element-order --order-by-decreasing-area --allow-reverse-merge -c e:\xxx\template.args for the data in https://files.mkgmap.org.uk/download/507/xxx.zip Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> Gesendet: Sonntag, 6. Juni 2021 16:02 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: [mkgmap-dev] Proof of concept for better sea in overview map Hi, the attached patch improves the overview map, but so far only when precomp-sea is NOT used. I tested it with --generate-sea=multipolygon,floodblocker so that mkgmap really has a multipolygon with the natual=sea data. For each level in the overview map it uses the original multipolygon data to compute the rings which will might visible at the given resolution. This requires more time compared to the current code but the result is much better and some fine tuning is possible. To be able to use this also with --precomp-sea we need some changes in the code which generates sea.zip so that one multipolygon relation for each tile is stored. I've uploaded the results here: https://files.mkgmap.org.uk/download/511/compare.7z What do you think? Gerd
Hi Gerd This is going to take some studying to work out the implications. Can't do much for the next few days however, but will look carefully at the end of the week. Ticker On Sun, 2021-06-06 at 14:02 +0000, Gerd Petermann wrote:
Hi,
the attached patch improves the overview map, but so far only when precomp-sea is NOT used. I tested it with --generate-sea=multipolygon,floodblocker so that mkgmap really has a multipolygon with the natual=sea data.
For each level in the overview map it uses the original multipolygon data to compute the rings which will might visible at the given resolution. This requires more time compared to the current code but the result is much better and some fine tuning is possible.
To be able to use this also with --precomp-sea we need some changes in the code which generates sea.zip so that one multipolygon relation for each tile is stored.
I've uploaded the results here: https://files.mkgmap.org.uk/download/511/compare.7z What do you think?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Is it only much slower because of not using precomp sea? Or will it be much slower in general? And what is much slower for say Europe continent map? If a modern 4core/8thread processor needs 30 minutes more I would prefer the old way knowing it is worse (if the time difference is negligible with precomp-sea then that would be great). On Mon, 7 Jun 2021 at 12:26, Ticker Berkin <rwb-mkgmap@jagit.co.uk> wrote:
Hi Gerd
This is going to take some studying to work out the implications. Can't do much for the next few days however, but will look carefully at the end of the week.
Ticker
On Sun, 2021-06-06 at 14:02 +0000, Gerd Petermann wrote:
Hi,
the attached patch improves the overview map, but so far only when precomp-sea is NOT used. I tested it with --generate-sea=multipolygon,floodblocker so that mkgmap really has a multipolygon with the natual=sea data.
For each level in the overview map it uses the original multipolygon data to compute the rings which will might visible at the given resolution. This requires more time compared to the current code but the result is much better and some fine tuning is possible.
To be able to use this also with --precomp-sea we need some changes in the code which generates sea.zip so that one multipolygon relation for each tile is stored.
I've uploaded the results here: https://files.mkgmap.org.uk/download/511/compare.7z What do you think?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
With the provided patch the speed is very poor for areas like Norway, probably twice the time. It is much slower because it does the complex multipolygon cutting for each level in the overview map. Probably too slow for complex coastal areas. This time will be the same for precomp-sea unless we can store sea polygons for each resolution. Performance will be no problem if I find a way to use Douglas-Peucker or similar before cutting. That was my original idea but DP produces self intersecting polygons and the MultipolygonCutter cannot cope with that. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Montag, 7. Juni 2021 11:55 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map Is it only much slower because of not using precomp sea? Or will it be much slower in general? And what is much slower for say Europe continent map? If a modern 4core/8thread processor needs 30 minutes more I would prefer the old way knowing it is worse (if the time difference is negligible with precomp-sea then that would be great). On Mon, 7 Jun 2021 at 12:26, Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>> wrote: Hi Gerd This is going to take some studying to work out the implications. Can't do much for the next few days however, but will look carefully at the end of the week. Ticker On Sun, 2021-06-06 at 14:02 +0000, Gerd Petermann wrote:
Hi,
the attached patch improves the overview map, but so far only when precomp-sea is NOT used. I tested it with --generate-sea=multipolygon,floodblocker so that mkgmap really has a multipolygon with the natual=sea data.
For each level in the overview map it uses the original multipolygon data to compute the rings which will might visible at the given resolution. This requires more time compared to the current code but the result is much better and some fine tuning is possible.
To be able to use this also with --precomp-sea we need some changes in the code which generates sea.zip so that one multipolygon relation for each tile is stored.
I've uploaded the results here: https://files.mkgmap.org.uk/download/511/compare.7z What do you think?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org
OK, I think found a good solution. Speed is quite OK, I see 9 min 48 secs for map of norway and instead of 8 min 44 secs with r4756, and I consider Norway to be a worst case. See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4761 for the details. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Montag, 7. Juni 2021 12:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map With the provided patch the speed is very poor for areas like Norway, probably twice the time. It is much slower because it does the complex multipolygon cutting for each level in the overview map. Probably too slow for complex coastal areas. This time will be the same for precomp-sea unless we can store sea polygons for each resolution. Performance will be no problem if I find a way to use Douglas-Peucker or similar before cutting. That was my original idea but DP produces self intersecting polygons and the MultipolygonCutter cannot cope with that. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Montag, 7. Juni 2021 11:55 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map Is it only much slower because of not using precomp sea? Or will it be much slower in general? And what is much slower for say Europe continent map? If a modern 4core/8thread processor needs 30 minutes more I would prefer the old way knowing it is worse (if the time difference is negligible with precomp-sea then that would be great). On Mon, 7 Jun 2021 at 12:26, Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>> wrote: Hi Gerd This is going to take some studying to work out the implications. Can't do much for the next few days however, but will look carefully at the end of the week. Ticker On Sun, 2021-06-06 at 14:02 +0000, Gerd Petermann wrote:
Hi,
the attached patch improves the overview map, but so far only when precomp-sea is NOT used. I tested it with --generate-sea=multipolygon,floodblocker so that mkgmap really has a multipolygon with the natual=sea data.
For each level in the overview map it uses the original multipolygon data to compute the rings which will might visible at the given resolution. This requires more time compared to the current code but the result is much better and some fine tuning is possible.
To be able to use this also with --precomp-sea we need some changes in the code which generates sea.zip so that one multipolygon relation for each tile is stored.
I've uploaded the results here: https://files.mkgmap.org.uk/download/511/compare.7z What do you think?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I guess that is a time for a full Norway map based on default style - so that is quite okay. Not a sea only Norway map... Well I hope that Thorsten Kukuk can adapt his sea files in the near future then... On Mon, 7 Jun 2021 at 19:37, Gerd Petermann <gpetermann_muenchen@hotmail.com> wrote:
OK, I think found a good solution. Speed is quite OK, I see 9 min 48 secs for map of norway and instead of 8 min 44 secs with r4756, and I consider Norway to be a worst case.
See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4761 for the details.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Montag, 7. Juni 2021 12:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
With the provided patch the speed is very poor for areas like Norway, probably twice the time. It is much slower because it does the complex multipolygon cutting for each level in the overview map. Probably too slow for complex coastal areas. This time will be the same for precomp-sea unless we can store sea polygons for each resolution.
Performance will be no problem if I find a way to use Douglas-Peucker or similar before cutting. That was my original idea but DP produces self intersecting polygons and the MultipolygonCutter cannot cope with that.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Montag, 7. Juni 2021 11:55 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Is it only much slower because of not using precomp sea? Or will it be much slower in general? And what is much slower for say Europe continent map? If a modern 4core/8thread processor needs 30 minutes more I would prefer the old way knowing it is worse (if the time difference is negligible with precomp-sea then that would be great).
On Mon, 7 Jun 2021 at 12:26, Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>> wrote: Hi Gerd
This is going to take some studying to work out the implications. Can't do much for the next few days however, but will look carefully at the end of the week.
Ticker
On Sun, 2021-06-06 at 14:02 +0000, Gerd Petermann wrote:
Hi,
the attached patch improves the overview map, but so far only when precomp-sea is NOT used. I tested it with --generate-sea=multipolygon,floodblocker so that mkgmap really has a multipolygon with the natual=sea data.
For each level in the overview map it uses the original multipolygon data to compute the rings which will might visible at the given resolution. This requires more time compared to the current code but the result is much better and some fine tuning is possible.
To be able to use this also with --precomp-sea we need some changes in the code which generates sea.zip so that one multipolygon relation for each tile is stored.
I've uploaded the results here: https://files.mkgmap.org.uk/download/511/compare.7z What do you think?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
Hi Felix, the map contained was without routing or index, so for a normal map the difference should be even smaller. There is no need to change sea.zip. You just have to use --improve-overview for now. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Montag, 7. Juni 2021 21:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map I guess that is a time for a full Norway map based on default style - so that is quite okay. Not a sea only Norway map... Well I hope that Thorsten Kukuk can adapt his sea files in the near future then... On Mon, 7 Jun 2021 at 19:37, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: OK, I think found a good solution. Speed is quite OK, I see 9 min 48 secs for map of norway and instead of 8 min 44 secs with r4756, and I consider Norway to be a worst case. See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4761 for the details. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> Gesendet: Montag, 7. Juni 2021 12:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map With the provided patch the speed is very poor for areas like Norway, probably twice the time. It is much slower because it does the complex multipolygon cutting for each level in the overview map. Probably too slow for complex coastal areas. This time will be the same for precomp-sea unless we can store sea polygons for each resolution. Performance will be no problem if I find a way to use Douglas-Peucker or similar before cutting. That was my original idea but DP produces self intersecting polygons and the MultipolygonCutter cannot cope with that. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Montag, 7. Juni 2021 11:55 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map Is it only much slower because of not using precomp sea? Or will it be much slower in general? And what is much slower for say Europe continent map? If a modern 4core/8thread processor needs 30 minutes more I would prefer the old way knowing it is worse (if the time difference is negligible with precomp-sea then that would be great). On Mon, 7 Jun 2021 at 12:26, Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>> wrote: Hi Gerd This is going to take some studying to work out the implications. Can't do much for the next few days however, but will look carefully at the end of the week. Ticker On Sun, 2021-06-06 at 14:02 +0000, Gerd Petermann wrote:
Hi,
the attached patch improves the overview map, but so far only when precomp-sea is NOT used. I tested it with --generate-sea=multipolygon,floodblocker so that mkgmap really has a multipolygon with the natual=sea data.
For each level in the overview map it uses the original multipolygon data to compute the rings which will might visible at the given resolution. This requires more time compared to the current code but the result is much better and some fine tuning is possible.
To be able to use this also with --precomp-sea we need some changes in the code which generates sea.zip so that one multipolygon relation for each tile is stored.
I've uploaded the results here: https://files.mkgmap.org.uk/download/511/compare.7z What do you think?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org
okay thanks for the clarifications. On Mon, 7 Jun 2021 at 22:06, Gerd Petermann <gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
the map contained was without routing or index, so for a normal map the difference should be even smaller. There is no need to change sea.zip. You just have to use --improve-overview for now.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Montag, 7. Juni 2021 21:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
I guess that is a time for a full Norway map based on default style - so that is quite okay. Not a sea only Norway map... Well I hope that Thorsten Kukuk can adapt his sea files in the near future then...
On Mon, 7 Jun 2021 at 19:37, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: OK, I think found a good solution. Speed is quite OK, I see 9 min 48 secs for map of norway and instead of 8 min 44 secs with r4756, and I consider Norway to be a worst case.
See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4761 for the details.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> Gesendet: Montag, 7. Juni 2021 12:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
With the provided patch the speed is very poor for areas like Norway, probably twice the time. It is much slower because it does the complex multipolygon cutting for each level in the overview map. Probably too slow for complex coastal areas. This time will be the same for precomp-sea unless we can store sea polygons for each resolution.
Performance will be no problem if I find a way to use Douglas-Peucker or similar before cutting. That was my original idea but DP produces self intersecting polygons and the MultipolygonCutter cannot cope with that.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Montag, 7. Juni 2021 11:55 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Is it only much slower because of not using precomp sea? Or will it be much slower in general? And what is much slower for say Europe continent map? If a modern 4core/8thread processor needs 30 minutes more I would prefer the old way knowing it is worse (if the time difference is negligible with precomp-sea then that would be great).
On Mon, 7 Jun 2021 at 12:26, Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>> wrote: Hi Gerd
This is going to take some studying to work out the implications. Can't do much for the next few days however, but will look carefully at the end of the week.
Ticker
On Sun, 2021-06-06 at 14:02 +0000, Gerd Petermann wrote:
Hi,
the attached patch improves the overview map, but so far only when precomp-sea is NOT used. I tested it with --generate-sea=multipolygon,floodblocker so that mkgmap really has a multipolygon with the natual=sea data.
For each level in the overview map it uses the original multipolygon data to compute the rings which will might visible at the given resolution. This requires more time compared to the current code but the result is much better and some fine tuning is possible.
To be able to use this also with --precomp-sea we need some changes in the code which generates sea.zip so that one multipolygon relation for each tile is stored.
I've uploaded the results here: https://files.mkgmap.org.uk/download/511/compare.7z What do you think?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
Hi all, I hoped for some positive feedback on this but got none so far. Did I miss something important? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Montag, 7. Juni 2021 21:05 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map Hi Felix, the map contained was without routing or index, so for a normal map the difference should be even smaller. There is no need to change sea.zip. You just have to use --improve-overview for now. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Montag, 7. Juni 2021 21:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map I guess that is a time for a full Norway map based on default style - so that is quite okay. Not a sea only Norway map... Well I hope that Thorsten Kukuk can adapt his sea files in the near future then... On Mon, 7 Jun 2021 at 19:37, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: OK, I think found a good solution. Speed is quite OK, I see 9 min 48 secs for map of norway and instead of 8 min 44 secs with r4756, and I consider Norway to be a worst case. See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4761 for the details. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> Gesendet: Montag, 7. Juni 2021 12:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map With the provided patch the speed is very poor for areas like Norway, probably twice the time. It is much slower because it does the complex multipolygon cutting for each level in the overview map. Probably too slow for complex coastal areas. This time will be the same for precomp-sea unless we can store sea polygons for each resolution. Performance will be no problem if I find a way to use Douglas-Peucker or similar before cutting. That was my original idea but DP produces self intersecting polygons and the MultipolygonCutter cannot cope with that. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Montag, 7. Juni 2021 11:55 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map Is it only much slower because of not using precomp sea? Or will it be much slower in general? And what is much slower for say Europe continent map? If a modern 4core/8thread processor needs 30 minutes more I would prefer the old way knowing it is worse (if the time difference is negligible with precomp-sea then that would be great). On Mon, 7 Jun 2021 at 12:26, Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>> wrote: Hi Gerd This is going to take some studying to work out the implications. Can't do much for the next few days however, but will look carefully at the end of the week. Ticker On Sun, 2021-06-06 at 14:02 +0000, Gerd Petermann wrote:
Hi,
the attached patch improves the overview map, but so far only when precomp-sea is NOT used. I tested it with --generate-sea=multipolygon,floodblocker so that mkgmap really has a multipolygon with the natual=sea data.
For each level in the overview map it uses the original multipolygon data to compute the rings which will might visible at the given resolution. This requires more time compared to the current code but the result is much better and some fine tuning is possible.
To be able to use this also with --precomp-sea we need some changes in the code which generates sea.zip so that one multipolygon relation for each tile is stored.
I've uploaded the results here: https://files.mkgmap.org.uk/download/511/compare.7z What do you think?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I just compiled the australia-oceania map with that option, and I think I must be missing something. It got substantially worse (it is identical until the overview map kicks in) - then I get some huge squares of sea missing. Compile time for all maps until that point before Compilation time is not up a lot: 0:12 - 9:46 = 9:34 one week before (except older mapdata no changes in compilation procedure and older mkgmap) 20:17 - 5:38 = 9:19 Anything I could be missing? I use the newest low-res branch build and added --improve-overview to the compilation process. in my polygons file I have: natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=2 } [0x10f1d resolution 10] On Fri, 11 Jun 2021 at 07:12, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi all,
I hoped for some positive feedback on this but got none so far. Did I miss something important?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Montag, 7. Juni 2021 21:05 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Hi Felix,
the map contained was without routing or index, so for a normal map the difference should be even smaller. There is no need to change sea.zip. You just have to use --improve-overview for now.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Montag, 7. Juni 2021 21:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
I guess that is a time for a full Norway map based on default style - so that is quite okay. Not a sea only Norway map... Well I hope that Thorsten Kukuk can adapt his sea files in the near future then...
On Mon, 7 Jun 2021 at 19:37, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: OK, I think found a good solution. Speed is quite OK, I see 9 min 48 secs for map of norway and instead of 8 min 44 secs with r4756, and I consider Norway to be a worst case.
See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4761 for the details.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> Gesendet: Montag, 7. Juni 2021 12:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
With the provided patch the speed is very poor for areas like Norway, probably twice the time. It is much slower because it does the complex multipolygon cutting for each level in the overview map. Probably too slow for complex coastal areas. This time will be the same for precomp-sea unless we can store sea polygons for each resolution.
Performance will be no problem if I find a way to use Douglas-Peucker or similar before cutting. That was my original idea but DP produces self intersecting polygons and the MultipolygonCutter cannot cope with that.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Montag, 7. Juni 2021 11:55 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Is it only much slower because of not using precomp sea? Or will it be much slower in general? And what is much slower for say Europe continent map? If a modern 4core/8thread processor needs 30 minutes more I would prefer the old way knowing it is worse (if the time difference is negligible with precomp-sea then that would be great).
On Mon, 7 Jun 2021 at 12:26, Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>> wrote: Hi Gerd
This is going to take some studying to work out the implications. Can't do much for the next few days however, but will look carefully at the end of the week.
Ticker
On Sun, 2021-06-06 at 14:02 +0000, Gerd Petermann wrote:
Hi,
the attached patch improves the overview map, but so far only when precomp-sea is NOT used. I tested it with --generate-sea=multipolygon,floodblocker so that mkgmap really has a multipolygon with the natual=sea data.
For each level in the overview map it uses the original multipolygon data to compute the rings which will might visible at the given resolution. This requires more time compared to the current code but the result is much better and some fine tuning is possible.
To be able to use this also with --precomp-sea we need some changes in the code which generates sea.zip so that one multipolygon relation for each tile is stored.
I've uploaded the results here: https://files.mkgmap.org.uk/download/511/compare.7z What do you think?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
compilation time includes splitting, and some other stuff. Loads of countries (9:34 / 9:21 (sorry dumb error 9:19) for all european single countries and a few continents (but not Europe continent) in hours. On Fri, 11 Jun 2021 at 11:08, Felix Hartmann <extremecarver@gmail.com> wrote:
I just compiled the australia-oceania map with that option, and I think I must be missing something. It got substantially worse (it is identical until the overview map kicks in) - then I get some huge squares of sea missing. Compile time for all maps until that point before Compilation time is not up a lot: 0:12 - 9:46 = 9:34 one week before (except older mapdata no changes in compilation procedure and older mkgmap) 20:17 - 5:38 = 9:19
Anything I could be missing? I use the newest low-res branch build and added --improve-overview to the compilation process.
in my polygons file I have: natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=2 } [0x10f1d resolution 10]
On Fri, 11 Jun 2021 at 07:12, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi all,
I hoped for some positive feedback on this but got none so far. Did I miss something important?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Montag, 7. Juni 2021 21:05 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Hi Felix,
the map contained was without routing or index, so for a normal map the difference should be even smaller. There is no need to change sea.zip. You just have to use --improve-overview for now.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Montag, 7. Juni 2021 21:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
I guess that is a time for a full Norway map based on default style - so that is quite okay. Not a sea only Norway map... Well I hope that Thorsten Kukuk can adapt his sea files in the near future then...
On Mon, 7 Jun 2021 at 19:37, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: OK, I think found a good solution. Speed is quite OK, I see 9 min 48 secs for map of norway and instead of 8 min 44 secs with r4756, and I consider Norway to be a worst case.
See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4761 for the details.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> Gesendet: Montag, 7. Juni 2021 12:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
With the provided patch the speed is very poor for areas like Norway, probably twice the time. It is much slower because it does the complex multipolygon cutting for each level in the overview map. Probably too slow for complex coastal areas. This time will be the same for precomp-sea unless we can store sea polygons for each resolution.
Performance will be no problem if I find a way to use Douglas-Peucker or similar before cutting. That was my original idea but DP produces self intersecting polygons and the MultipolygonCutter cannot cope with that.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Montag, 7. Juni 2021 11:55 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Is it only much slower because of not using precomp sea? Or will it be much slower in general? And what is much slower for say Europe continent map? If a modern 4core/8thread processor needs 30 minutes more I would prefer the old way knowing it is worse (if the time difference is negligible with precomp-sea then that would be great).
On Mon, 7 Jun 2021 at 12:26, Ticker Berkin <rwb-mkgmap@jagit.co.uk <mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>> wrote: Hi Gerd
This is going to take some studying to work out the implications. Can't do much for the next few days however, but will look carefully at the end of the week.
Ticker
On Sun, 2021-06-06 at 14:02 +0000, Gerd Petermann wrote:
Hi,
the attached patch improves the overview map, but so far only when precomp-sea is NOT used. I tested it with --generate-sea=multipolygon,floodblocker so that mkgmap really has a multipolygon with the natual=sea data.
For each level in the overview map it uses the original multipolygon data to compute the rings which will might visible at the given resolution. This requires more time compared to the current code but the result is much better and some fine tuning is possible.
To be able to use this also with --precomp-sea we need some changes in the code which generates sea.zip so that one multipolygon relation for each tile is stored.
I've uploaded the results here: https://files.mkgmap.org.uk/download/511/compare.7z What do you think?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
--generate-sea --precomp-sea=C:\openmtbmap\maps\sea.zip --order-by-decreasing-area --allow-reverse-merge I thought using precomp-sea is fine (I did not update the precomp-sea in between) On Fri, 11 Jun 2021 at 11:10, Felix Hartmann <extremecarver@gmail.com> wrote:
compilation time includes splitting, and some other stuff. Loads of countries (9:34 / 9:21 (sorry dumb error 9:19) for all european single countries and a few continents (but not Europe continent) in hours.
On Fri, 11 Jun 2021 at 11:08, Felix Hartmann <extremecarver@gmail.com> wrote:
I just compiled the australia-oceania map with that option, and I think I must be missing something. It got substantially worse (it is identical until the overview map kicks in) - then I get some huge squares of sea missing. Compile time for all maps until that point before Compilation time is not up a lot: 0:12 - 9:46 = 9:34 one week before (except older mapdata no changes in compilation procedure and older mkgmap) 20:17 - 5:38 = 9:19
Anything I could be missing? I use the newest low-res branch build and added --improve-overview to the compilation process.
in my polygons file I have: natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=2 } [0x10f1d resolution 10]
On Fri, 11 Jun 2021 at 07:12, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi all,
I hoped for some positive feedback on this but got none so far. Did I miss something important?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Montag, 7. Juni 2021 21:05 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Hi Felix,
the map contained was without routing or index, so for a normal map the difference should be even smaller. There is no need to change sea.zip. You just have to use --improve-overview for now.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Montag, 7. Juni 2021 21:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
I guess that is a time for a full Norway map based on default style - so that is quite okay. Not a sea only Norway map... Well I hope that Thorsten Kukuk can adapt his sea files in the near future then...
On Mon, 7 Jun 2021 at 19:37, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: OK, I think found a good solution. Speed is quite OK, I see 9 min 48 secs for map of norway and instead of 8 min 44 secs with r4756, and I consider Norway to be a worst case.
See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4761 for the details.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> Gesendet: Montag, 7. Juni 2021 12:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
With the provided patch the speed is very poor for areas like Norway, probably twice the time. It is much slower because it does the complex multipolygon cutting for each level in the overview map. Probably too slow for complex coastal areas. This time will be the same for precomp-sea unless we can store sea polygons for each resolution.
Performance will be no problem if I find a way to use Douglas-Peucker or similar before cutting. That was my original idea but DP produces self intersecting polygons and the MultipolygonCutter cannot cope with that.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Montag, 7. Juni 2021 11:55 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Is it only much slower because of not using precomp sea? Or will it be much slower in general? And what is much slower for say Europe continent map? If a modern 4core/8thread processor needs 30 minutes more I would prefer the old way knowing it is worse (if the time difference is negligible with precomp-sea then that would be great).
On Mon, 7 Jun 2021 at 12:26, Ticker Berkin <rwb-mkgmap@jagit.co.uk <mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>> wrote: Hi Gerd
This is going to take some studying to work out the implications. Can't do much for the next few days however, but will look carefully at the end of the week.
Ticker
On Sun, 2021-06-06 at 14:02 +0000, Gerd Petermann wrote:
Hi,
the attached patch improves the overview map, but so far only when precomp-sea is NOT used. I tested it with --generate-sea=multipolygon,floodblocker so that mkgmap really has a multipolygon with the natual=sea data.
For each level in the overview map it uses the original multipolygon data to compute the rings which will might visible at the given resolution. This requires more time compared to the current code but the result is much better and some fine tuning is possible.
To be able to use this also with --precomp-sea we need some changes in the code which generates sea.zip so that one multipolygon relation for each tile is stored.
I've uploaded the results here: https://files.mkgmap.org.uk/download/511/compare.7z What do you think?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
Hi Felix, Maybe you are using large values for the Douglas-Peucker filter at low resolutions? That's probably a bad idea with the new option. I always tested with the default 2.6 for all levels. The effect of the new option is that DP really can do its work. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Freitag, 11. Juni 2021 10:23 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map --generate-sea --precomp-sea=C:\openmtbmap\maps\sea.zip --order-by-decreasing-area --allow-reverse-merge I thought using precomp-sea is fine (I did not update the precomp-sea in between) On Fri, 11 Jun 2021 at 11:10, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> wrote: compilation time includes splitting, and some other stuff. Loads of countries (9:34 / 9:21 (sorry dumb error 9:19) for all european single countries and a few continents (but not Europe continent) in hours. On Fri, 11 Jun 2021 at 11:08, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> wrote: I just compiled the australia-oceania map with that option, and I think I must be missing something. It got substantially worse (it is identical until the overview map kicks in) - then I get some huge squares of sea missing. Compile time for all maps until that point before Compilation time is not up a lot: 0:12 - 9:46 = 9:34 one week before (except older mapdata no changes in compilation procedure and older mkgmap) 20:17 - 5:38 = 9:19 Anything I could be missing? I use the newest low-res branch build and added --improve-overview to the compilation process. in my polygons file I have: natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=2 } [0x10f1d resolution 10] On Fri, 11 Jun 2021 at 07:12, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi all, I hoped for some positive feedback on this but got none so far. Did I miss something important? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> Gesendet: Montag, 7. Juni 2021 21:05 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map Hi Felix, the map contained was without routing or index, so for a normal map the difference should be even smaller. There is no need to change sea.zip. You just have to use --improve-overview for now. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Montag, 7. Juni 2021 21:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map I guess that is a time for a full Norway map based on default style - so that is quite okay. Not a sea only Norway map... Well I hope that Thorsten Kukuk can adapt his sea files in the near future then... On Mon, 7 Jun 2021 at 19:37, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>> wrote: OK, I think found a good solution. Speed is quite OK, I see 9 min 48 secs for map of norway and instead of 8 min 44 secs with r4756, and I consider Norway to be a worst case. See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4761 for the details. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>> Gesendet: Montag, 7. Juni 2021 12:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map With the provided patch the speed is very poor for areas like Norway, probably twice the time. It is much slower because it does the complex multipolygon cutting for each level in the overview map. Probably too slow for complex coastal areas. This time will be the same for precomp-sea unless we can store sea polygons for each resolution. Performance will be no problem if I find a way to use Douglas-Peucker or similar before cutting. That was my original idea but DP produces self intersecting polygons and the MultipolygonCutter cannot cope with that. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> Gesendet: Montag, 7. Juni 2021 11:55 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map Is it only much slower because of not using precomp sea? Or will it be much slower in general? And what is much slower for say Europe continent map? If a modern 4core/8thread processor needs 30 minutes more I would prefer the old way knowing it is worse (if the time difference is negligible with precomp-sea then that would be great). On Mon, 7 Jun 2021 at 12:26, Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>>> wrote: Hi Gerd This is going to take some studying to work out the implications. Can't do much for the next few days however, but will look carefully at the end of the week. Ticker On Sun, 2021-06-06 at 14:02 +0000, Gerd Petermann wrote:
Hi,
the attached patch improves the overview map, but so far only when precomp-sea is NOT used. I tested it with --generate-sea=multipolygon,floodblocker so that mkgmap really has a multipolygon with the natual=sea data.
For each level in the overview map it uses the original multipolygon data to compute the rings which will might visible at the given resolution. This requires more time compared to the current code but the result is much better and some fine tuning is possible.
To be able to use this also with --precomp-sea we need some changes in the code which generates sea.zip so that one multipolygon relation for each tile is stored.
I've uploaded the results here: https://files.mkgmap.org.uk/download/511/compare.7z What do you think?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org
yes I was using: --x-simplify-filter-line-errors=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,16:8,14:9 --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9 --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20" levels = 0:24, 1:22, 2:21, 3:20, 4:19, 5:18 overview-levels = 6:17, 7:16, 8:15, 9:14, 10:13 As this only affects the overview map - I guess I should change it to: --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9,17:2.6 ?? The polygon-size-limits should not matter as I have the skip-size filter set for sea. I had worked quite a long time to optimize those settings with the old behaviour. On Fri, 11 Jun 2021 at 11:50, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
Maybe you are using large values for the Douglas-Peucker filter at low resolutions? That's probably a bad idea with the new option. I always tested with the default 2.6 for all levels. The effect of the new option is that DP really can do its work.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Freitag, 11. Juni 2021 10:23 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
--generate-sea --precomp-sea=C:\openmtbmap\maps\sea.zip --order-by-decreasing-area --allow-reverse-merge I thought using precomp-sea is fine (I did not update the precomp-sea in between)
On Fri, 11 Jun 2021 at 11:10, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com>> wrote: compilation time includes splitting, and some other stuff. Loads of countries (9:34 / 9:21 (sorry dumb error 9:19) for all european single countries and a few continents (but not Europe continent) in hours.
On Fri, 11 Jun 2021 at 11:08, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com>> wrote: I just compiled the australia-oceania map with that option, and I think I must be missing something. It got substantially worse (it is identical until the overview map kicks in) - then I get some huge squares of sea missing. Compile time for all maps until that point before Compilation time is not up a lot: 0:12 - 9:46 = 9:34 one week before (except older mapdata no changes in compilation procedure and older mkgmap) 20:17 - 5:38 = 9:19
Anything I could be missing? I use the newest low-res branch build and added --improve-overview to the compilation process.
in my polygons file I have: natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=2 } [0x10f1d resolution 10]
On Fri, 11 Jun 2021 at 07:12, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi all,
I hoped for some positive feedback on this but got none so far. Did I miss something important?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> Gesendet: Montag, 7. Juni 2021 21:05 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Hi Felix,
the map contained was without routing or index, so for a normal map the difference should be even smaller. There is no need to change sea.zip. You just have to use --improve-overview for now.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Montag, 7. Juni 2021 21:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
I guess that is a time for a full Norway map based on default style - so that is quite okay. Not a sea only Norway map... Well I hope that Thorsten Kukuk can adapt his sea files in the near future then...
On Mon, 7 Jun 2021 at 19:37, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>> wrote: OK, I think found a good solution. Speed is quite OK, I see 9 min 48 secs for map of norway and instead of 8 min 44 secs with r4756, and I consider Norway to be a worst case.
See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4761 for the details.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>> Gesendet: Montag, 7. Juni 2021 12:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
With the provided patch the speed is very poor for areas like Norway, probably twice the time. It is much slower because it does the complex multipolygon cutting for each level in the overview map. Probably too slow for complex coastal areas. This time will be the same for precomp-sea unless we can store sea polygons for each resolution.
Performance will be no problem if I find a way to use Douglas-Peucker or similar before cutting. That was my original idea but DP produces self intersecting polygons and the MultipolygonCutter cannot cope with that.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> Gesendet: Montag, 7. Juni 2021 11:55 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Is it only much slower because of not using precomp sea? Or will it be much slower in general? And what is much slower for say Europe continent map? If a modern 4core/8thread processor needs 30 minutes more I would prefer the old way knowing it is worse (if the time difference is negligible with precomp-sea then that would be great).
On Mon, 7 Jun 2021 at 12:26, Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>>> wrote: Hi Gerd
This is going to take some studying to work out the implications. Can't do much for the next few days however, but will look carefully at the end of the week.
Ticker
On Sun, 2021-06-06 at 14:02 +0000, Gerd Petermann wrote:
Hi,
the attached patch improves the overview map, but so far only when precomp-sea is NOT used. I tested it with --generate-sea=multipolygon,floodblocker so that mkgmap really has a multipolygon with the natual=sea data.
For each level in the overview map it uses the original multipolygon data to compute the rings which will might visible at the given resolution. This requires more time compared to the current code but the result is much better and some fine tuning is possible.
To be able to use this also with --precomp-sea we need some changes in the code which generates sea.zip so that one multipolygon relation for each tile is stored.
I've uploaded the results here: https://files.mkgmap.org.uk/download/511/compare.7z What do you think?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
Hi Felix, the polygon-size-limit also matters as it is used to determine which islands will not be visible. I used 2 for all levels, but I only looked at the overview map for now as the detail maps are not changed by the --improve-overview option. I suggest to experiment with a small set of tiles. australia-oceania is probably good. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Freitag, 11. Juni 2021 11:25 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map yes I was using: --x-simplify-filter-line-errors=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,16:8,14:9 --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9 --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20" levels = 0:24, 1:22, 2:21, 3:20, 4:19, 5:18 overview-levels = 6:17, 7:16, 8:15, 9:14, 10:13 As this only affects the overview map - I guess I should change it to: --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9,17:2.6 ?? The polygon-size-limits should not matter as I have the skip-size filter set for sea. I had worked quite a long time to optimize those settings with the old behaviour. On Fri, 11 Jun 2021 at 11:50, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix, Maybe you are using large values for the Douglas-Peucker filter at low resolutions? That's probably a bad idea with the new option. I always tested with the default 2.6 for all levels. The effect of the new option is that DP really can do its work. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Freitag, 11. Juni 2021 10:23 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map --generate-sea --precomp-sea=C:\openmtbmap\maps\sea.zip --order-by-decreasing-area --allow-reverse-merge I thought using precomp-sea is fine (I did not update the precomp-sea in between) On Fri, 11 Jun 2021 at 11:10, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> wrote: compilation time includes splitting, and some other stuff. Loads of countries (9:34 / 9:21 (sorry dumb error 9:19) for all european single countries and a few continents (but not Europe continent) in hours. On Fri, 11 Jun 2021 at 11:08, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> wrote: I just compiled the australia-oceania map with that option, and I think I must be missing something. It got substantially worse (it is identical until the overview map kicks in) - then I get some huge squares of sea missing. Compile time for all maps until that point before Compilation time is not up a lot: 0:12 - 9:46 = 9:34 one week before (except older mapdata no changes in compilation procedure and older mkgmap) 20:17 - 5:38 = 9:19 Anything I could be missing? I use the newest low-res branch build and added --improve-overview to the compilation process. in my polygons file I have: natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=2 } [0x10f1d resolution 10] On Fri, 11 Jun 2021 at 07:12, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>> wrote: Hi all, I hoped for some positive feedback on this but got none so far. Did I miss something important? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>> Gesendet: Montag, 7. Juni 2021 21:05 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map Hi Felix, the map contained was without routing or index, so for a normal map the difference should be even smaller. There is no need to change sea.zip. You just have to use --improve-overview for now. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> Gesendet: Montag, 7. Juni 2021 21:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map I guess that is a time for a full Norway map based on default style - so that is quite okay. Not a sea only Norway map... Well I hope that Thorsten Kukuk can adapt his sea files in the near future then... On Mon, 7 Jun 2021 at 19:37, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> wrote: OK, I think found a good solution. Speed is quite OK, I see 9 min 48 secs for map of norway and instead of 8 min 44 secs with r4756, and I consider Norway to be a worst case. See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4761 for the details. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> Gesendet: Montag, 7. Juni 2021 12:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map With the provided patch the speed is very poor for areas like Norway, probably twice the time. It is much slower because it does the complex multipolygon cutting for each level in the overview map. Probably too slow for complex coastal areas. This time will be the same for precomp-sea unless we can store sea polygons for each resolution. Performance will be no problem if I find a way to use Douglas-Peucker or similar before cutting. That was my original idea but DP produces self intersecting polygons and the MultipolygonCutter cannot cope with that. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> Gesendet: Montag, 7. Juni 2021 11:55 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map Is it only much slower because of not using precomp sea? Or will it be much slower in general? And what is much slower for say Europe continent map? If a modern 4core/8thread processor needs 30 minutes more I would prefer the old way knowing it is worse (if the time difference is negligible with precomp-sea then that would be great). On Mon, 7 Jun 2021 at 12:26, Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>>>> wrote: Hi Gerd This is going to take some studying to work out the implications. Can't do much for the next few days however, but will look carefully at the end of the week. Ticker On Sun, 2021-06-06 at 14:02 +0000, Gerd Petermann wrote:
Hi,
the attached patch improves the overview map, but so far only when precomp-sea is NOT used. I tested it with --generate-sea=multipolygon,floodblocker so that mkgmap really has a multipolygon with the natual=sea data.
For each level in the overview map it uses the original multipolygon data to compute the rings which will might visible at the given resolution. This requires more time compared to the current code but the result is much better and some fine tuning is possible.
To be able to use this also with --precomp-sea we need some changes in the code which generates sea.zip so that one multipolygon relation for each tile is stored.
I've uploaded the results here: https://files.mkgmap.org.uk/download/511/compare.7z What do you think?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org
Nope - that did not help. And I think the problem is a bit unrelated. Mkgmap with your new version and --improve-overview assumes there is an empty map - and puts those three square areas of missing anything. Maybe you give it a try and analyse what happens. I actually think this bug has been there before already - and it happened to me with contourlines only maps. Meaning mkgmap cuts the map area way too aggressively, and removes part of the map that actually even have content - or was it splitter. I think for contourlines only maps I had to use splitter with --keep-complete and --no-trim else there would be missing. areas in the map. (not on the outside but right in the middle in the ocean usually - but sometimes also e.g. northernmost parts of Norway in an Europe contourlines only map). So I split australia-oceania WITHOUT --no-trim. Are you assuming to split with --no-trim? Actually those grey boxes are each of its own separate tiles (with nearly no content - e.g. one has a riff polygon only). I guess there is lots of openseamap stuff so splitter creates those tiny tiles... Mkgmap should never trip on the overview map. The normal map should be trimmed aggressively - as we still cannot cut according to a bounding polygon and only using rectangles. But the overview map sea creation should not cut out sea or anything. I guess you never noticed that working on Norway - but it would be a good start to play around with australia-oceania (it is nice to work with - because it is relatively small in size so compiles fast). See attached screenshot of overview map. All the selected tiles were before showing sea (and do so once past the overview map too). The high DP filter was not the problem. For Australia-Oceania the --improve-overview right now is not a good example. The map was better before. Oh yeah - and --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20 looks better than small values. Actually I think even to rather increase more. Maybe that is why I had less problems right from the start - because I cut away tiny islands. C:\openmtbmap\maps>if yes NEQ no start /low /b /wait java -jar -XX:+AggressiveHeap -XX:StringTableSize=1000003 -Xms15000M -Xmx29000M C:\openmtbmap\mkgmap.jar --max-jobs=8 --order-by-decreasing-area "--generate-sea" --code-page=1252 "--precomp-sea=C:\openmtbmap\maps\sea.zip" "--style-file=C:\openmtbmap\openmtbmap_style" --improve-overview --add-boundary-nodes-at-admin-boundaries --drive-on=detect --allow-reverse-merge --line-types-with-direction=0x18,0x1f,0x10016,0x10101,0x10105,0x10401,0x10403,0x10405,0x10408,0x10409,0x1040b,0x1040d,0x1040e,0x10500,0x10501,0x10502,0x10503,0x10504,0x10505,0x10506,0x10507,0x10607,0x10609,0x1060b,0x10702,0x10703,0x10704,0x10705,0x10706,0x10707,0x10a00,0x10a02,0x10a04,0x10a05,0x10e1e,0x10e0f,0x10e0e,0x10e1e,0x10f0a,0x10f1c,0x10e1d --nsis --index --levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18" --overview-levels="7:17, 8:16, 9:15, 10:14, 11:13, 12:12" --add-pois-to-areas --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier=entrance --x-simplify-filter-line-errors=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,17:6,14:6 --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9,17:2.6 --add-boundary-nodes-at-admin-boundaries=2 --poi-excl-index=0x6405,0x4316,0x2f00 --copyright-file="C:\openmtbmap\openmtbmap_svn\copyrightopm.txt" --license-file="C:\openmtbmap\openmtbmap_svn\licenseopm.txt" --cycle-map --ignore-fixme-values --housenumbers --road-name-config=C:\openmtbmap\openmtbmap_svn\roadNameConfig.txt --split-name-index --link-pois-to-ways --ignore-turn-restrictions --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20" --description=omtb_auo --show-profiles=1 --location-autofill=bounds,is_in,nearest --bounds=C:\openmtbmap\maps\bounds.zip --mdr7-del=pri;sec;ter;cw;min;unsf,uncl;living;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1.;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;bridge;swing;aqueduct;viaduct;"ntnl bndry";admin_lv=4;"ntnl park";weir;dam;waterfall;rapids;stream;river;drain;ditch;"huge river";"hugest river";"medium river";"small river";"wide river";"hugest canal";"huge canal";"medium canal";"small canal";"big canal";canal;snowpark;Skitour-descent;Skipiste;Skislope;illuminated;Nordic-Skiing;skitour;platter;ropetow;tbar;chairlift;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath --mdr7-excl=pri;sec;ter;cw;min;unsf,uncl;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1.;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;"ntnl bndry";admin_lv=4;"ntnl park";"huge river";"hugest river";"medium river";"small river";"wide river";"hugest canal";"huge canal";"medium canal";"small canal";"big canal";canal;snowpark;Skitour-descent;illuminated;Nordic-Skiing;skitour;platter;ropetow;tbar;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath --route --country-abbr=auo --country-name=australia-oceania --mapname=65340000 --family-id=6534 --product-id=1 --series-name=omtb_australia-oceania_11.06.2021 --family-name=mtb_auo_11.06.2021 --tdbfile --gmapi --overview-mapname=mapsetc --keep-going --area-name="australia-oceania_11.06.2021_omtb" -c D:\openmtbmap\maps\template.australia-oceania C:\OpenMTBMap\contourlines20\australia-oceania\7*.img typauo.TYP On Fri, 11 Jun 2021 at 12:25, Felix Hartmann <extremecarver@gmail.com> wrote:
yes I was using:
--x-simplify-filter-line-errors=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,16:8,14:9 --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9 --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20"
levels = 0:24, 1:22, 2:21, 3:20, 4:19, 5:18 overview-levels = 6:17, 7:16, 8:15, 9:14, 10:13
As this only affects the overview map - I guess I should change it to: --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9,17:2.6 ??
The polygon-size-limits should not matter as I have the skip-size filter set for sea.
I had worked quite a long time to optimize those settings with the old behaviour.
On Fri, 11 Jun 2021 at 11:50, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
Maybe you are using large values for the Douglas-Peucker filter at low resolutions? That's probably a bad idea with the new option. I always tested with the default 2.6 for all levels. The effect of the new option is that DP really can do its work.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Freitag, 11. Juni 2021 10:23 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
--generate-sea --precomp-sea=C:\openmtbmap\maps\sea.zip --order-by-decreasing-area --allow-reverse-merge I thought using precomp-sea is fine (I did not update the precomp-sea in between)
On Fri, 11 Jun 2021 at 11:10, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com>> wrote: compilation time includes splitting, and some other stuff. Loads of countries (9:34 / 9:21 (sorry dumb error 9:19) for all european single countries and a few continents (but not Europe continent) in hours.
On Fri, 11 Jun 2021 at 11:08, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com>> wrote: I just compiled the australia-oceania map with that option, and I think I must be missing something. It got substantially worse (it is identical until the overview map kicks in) - then I get some huge squares of sea missing. Compile time for all maps until that point before Compilation time is not up a lot: 0:12 - 9:46 = 9:34 one week before (except older mapdata no changes in compilation procedure and older mkgmap) 20:17 - 5:38 = 9:19
Anything I could be missing? I use the newest low-res branch build and added --improve-overview to the compilation process.
in my polygons file I have: natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=2 } [0x10f1d resolution 10]
On Fri, 11 Jun 2021 at 07:12, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi all,
I hoped for some positive feedback on this but got none so far. Did I miss something important?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> Gesendet: Montag, 7. Juni 2021 21:05 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Hi Felix,
the map contained was without routing or index, so for a normal map the difference should be even smaller. There is no need to change sea.zip. You just have to use --improve-overview for now.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Montag, 7. Juni 2021 21:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
I guess that is a time for a full Norway map based on default style - so that is quite okay. Not a sea only Norway map... Well I hope that Thorsten Kukuk can adapt his sea files in the near future then...
On Mon, 7 Jun 2021 at 19:37, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>> wrote: OK, I think found a good solution. Speed is quite OK, I see 9 min 48 secs for map of norway and instead of 8 min 44 secs with r4756, and I consider Norway to be a worst case.
See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4761 for the details.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>> Gesendet: Montag, 7. Juni 2021 12:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
With the provided patch the speed is very poor for areas like Norway, probably twice the time. It is much slower because it does the complex multipolygon cutting for each level in the overview map. Probably too slow for complex coastal areas. This time will be the same for precomp-sea unless we can store sea polygons for each resolution.
Performance will be no problem if I find a way to use Douglas-Peucker or similar before cutting. That was my original idea but DP produces self intersecting polygons and the MultipolygonCutter cannot cope with that.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> Gesendet: Montag, 7. Juni 2021 11:55 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Is it only much slower because of not using precomp sea? Or will it be much slower in general? And what is much slower for say Europe continent map? If a modern 4core/8thread processor needs 30 minutes more I would prefer the old way knowing it is worse (if the time difference is negligible with precomp-sea then that would be great).
On Mon, 7 Jun 2021 at 12:26, Ticker Berkin <rwb-mkgmap@jagit.co.uk <mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>>> wrote: Hi Gerd
This is going to take some studying to work out the implications. Can't do much for the next few days however, but will look carefully at the end of the week.
Ticker
On Sun, 2021-06-06 at 14:02 +0000, Gerd Petermann wrote:
Hi,
the attached patch improves the overview map, but so far only when precomp-sea is NOT used. I tested it with --generate-sea=multipolygon,floodblocker so that mkgmap really has a multipolygon with the natual=sea data.
For each level in the overview map it uses the original multipolygon data to compute the rings which will might visible at the given resolution. This requires more time compared to the current code but the result is much better and some fine tuning is possible.
To be able to use this also with --precomp-sea we need some changes in the code which generates sea.zip so that one multipolygon relation for each tile is stored.
I've uploaded the results here: https://files.mkgmap.org.uk/download/511/compare.7z What do you think?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
Hi Felix, I don't yet understand what's going on. Please provide a link to your areas.list Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Freitag, 11. Juni 2021 12:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map Nope - that did not help. And I think the problem is a bit unrelated. Mkgmap with your new version and --improve-overview assumes there is an empty map - and puts those three square areas of missing anything. Maybe you give it a try and analyse what happens. I actually think this bug has been there before already - and it happened to me with contourlines only maps. Meaning mkgmap cuts the map area way too aggressively, and removes part of the map that actually even have content - or was it splitter. I think for contourlines only maps I had to use splitter with --keep-complete and --no-trim else there would be missing. areas in the map. (not on the outside but right in the middle in the ocean usually - but sometimes also e.g. northernmost parts of Norway in an Europe contourlines only map). So I split australia-oceania WITHOUT --no-trim. Are you assuming to split with --no-trim? Actually those grey boxes are each of its own separate tiles (with nearly no content - e.g. one has a riff polygon only). I guess there is lots of openseamap stuff so splitter creates those tiny tiles... Mkgmap should never trip on the overview map. The normal map should be trimmed aggressively - as we still cannot cut according to a bounding polygon and only using rectangles. But the overview map sea creation should not cut out sea or anything. I guess you never noticed that working on Norway - but it would be a good start to play around with australia-oceania (it is nice to work with - because it is relatively small in size so compiles fast). See attached screenshot of overview map. All the selected tiles were before showing sea (and do so once past the overview map too). The high DP filter was not the problem. For Australia-Oceania the --improve-overview right now is not a good example. The map was better before. Oh yeah - and --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20 looks better than small values. Actually I think even to rather increase more. Maybe that is why I had less problems right from the start - because I cut away tiny islands. C:\openmtbmap\maps>if yes NEQ no start /low /b /wait java -jar -XX:+AggressiveHeap -XX:StringTableSize=1000003 -Xms15000M -Xmx29000M C:\openmtbmap\mkgmap.jar --max-jobs=8 --order-by-decreasing-area "--generate-sea" --code-page=1252 "--precomp-sea=C:\openmtbmap\maps\sea.zip" "--style-file=C:\openmtbmap\openmtbmap_style" --improve-overview --add-boundary-nodes-at-admin-boundaries --drive-on=detect --allow-reverse-merge --line-types-with-direction=0x18,0x1f,0x10016,0x10101,0x10105,0x10401,0x10403,0x10405,0x10408,0x10409,0x1040b,0x1040d,0x1040e,0x10500,0x10501,0x10502,0x10503,0x10504,0x10505,0x10506,0x10507,0x10607,0x10609,0x1060b,0x10702,0x10703,0x10704,0x10705,0x10706,0x10707,0x10a00,0x10a02,0x10a04,0x10a05,0x10e1e,0x10e0f,0x10e0e,0x10e1e,0x10f0a,0x10f1c,0x10e1d --nsis --index --levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18" --overview-levels="7:17, 8:16, 9:15, 10:14, 11:13, 12:12" --add-pois-to-areas --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier=entrance --x-simplify-filter-line-errors=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,17:6,14:6 --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9,17:2.6 --add-boundary-nodes-at-admin-boundaries=2 --poi-excl-index=0x6405,0x4316,0x2f00 --copyright-file="C:\openmtbmap\openmtbmap_svn\copyrightopm.txt" --license-file="C:\openmtbmap\openmtbmap_svn\licenseopm.txt" --cycle-map --ignore-fixme-values --housenumbers --road-name-config=C:\openmtbmap\openmtbmap_svn\roadNameConfig.txt --split-name-index --link-pois-to-ways --ignore-turn-restrictions --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20" --description=omtb_auo --show-profiles=1 --location-autofill=bounds,is_in,nearest --bounds=C:\openmtbmap\maps\bounds.zip --mdr7-del=pri;sec;ter;cw;min;unsf,uncl;living;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1.;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;bridge;swing;aqueduct;viaduct;"ntnl bndry";admin_lv=4;"ntnl park";weir;dam;waterfall;rapids;stream;river;drain;ditch;"huge river";"hugest river";"medium river";"small river";"wide river";"hugest canal";"huge canal";"medium canal";"small canal";"big canal";canal;snowpark;Skitour-descent;Skipiste;Skislope;illuminated;Nordic-Skiing;skitour;platter;ropetow;tbar;chairlift;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath --mdr7-excl=pri;sec;ter;cw;min;unsf,uncl;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1.;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;"ntnl bndry";admin_lv=4;"ntnl park";"huge river";"hugest river";"medium river";"small river";"wide river";"hugest canal";"huge canal";"medium canal";"small canal";"big canal";canal;snowpark;Skitour-descent;illuminated;Nordic-Skiing;skitour;platter;ropetow;tbar;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath --route --country-abbr=auo --country-name=australia-oceania --mapname=65340000 --family-id=6534 --product-id=1 --series-name=omtb_australia-oceania_11.06.2021 --family-name=mtb_auo_11.06.2021 --tdbfile --gmapi --overview-mapname=mapsetc --keep-going --area-name="australia-oceania_11.06.2021_omtb" -c D:\openmtbmap\maps\template.australia-oceania C:\OpenMTBMap\contourlines20\australia-oceania\7*.img typauo.TYP On Fri, 11 Jun 2021 at 12:25, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> wrote: yes I was using: --x-simplify-filter-line-errors=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,16:8,14:9 --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9 --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20" levels = 0:24, 1:22, 2:21, 3:20, 4:19, 5:18 overview-levels = 6:17, 7:16, 8:15, 9:14, 10:13 As this only affects the overview map - I guess I should change it to: --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9,17:2.6 ?? The polygon-size-limits should not matter as I have the skip-size filter set for sea. I had worked quite a long time to optimize those settings with the old behaviour. On Fri, 11 Jun 2021 at 11:50, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix, Maybe you are using large values for the Douglas-Peucker filter at low resolutions? That's probably a bad idea with the new option. I always tested with the default 2.6 for all levels. The effect of the new option is that DP really can do its work. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Freitag, 11. Juni 2021 10:23 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map --generate-sea --precomp-sea=C:\openmtbmap\maps\sea.zip --order-by-decreasing-area --allow-reverse-merge I thought using precomp-sea is fine (I did not update the precomp-sea in between) On Fri, 11 Jun 2021 at 11:10, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> wrote: compilation time includes splitting, and some other stuff. Loads of countries (9:34 / 9:21 (sorry dumb error 9:19) for all european single countries and a few continents (but not Europe continent) in hours. On Fri, 11 Jun 2021 at 11:08, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> wrote: I just compiled the australia-oceania map with that option, and I think I must be missing something. It got substantially worse (it is identical until the overview map kicks in) - then I get some huge squares of sea missing. Compile time for all maps until that point before Compilation time is not up a lot: 0:12 - 9:46 = 9:34 one week before (except older mapdata no changes in compilation procedure and older mkgmap) 20:17 - 5:38 = 9:19 Anything I could be missing? I use the newest low-res branch build and added --improve-overview to the compilation process. in my polygons file I have: natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=2 } [0x10f1d resolution 10] On Fri, 11 Jun 2021 at 07:12, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>> wrote: Hi all, I hoped for some positive feedback on this but got none so far. Did I miss something important? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>> Gesendet: Montag, 7. Juni 2021 21:05 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map Hi Felix, the map contained was without routing or index, so for a normal map the difference should be even smaller. There is no need to change sea.zip. You just have to use --improve-overview for now. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> Gesendet: Montag, 7. Juni 2021 21:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map I guess that is a time for a full Norway map based on default style - so that is quite okay. Not a sea only Norway map... Well I hope that Thorsten Kukuk can adapt his sea files in the near future then... On Mon, 7 Jun 2021 at 19:37, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> wrote: OK, I think found a good solution. Speed is quite OK, I see 9 min 48 secs for map of norway and instead of 8 min 44 secs with r4756, and I consider Norway to be a worst case. See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4761 for the details. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> Gesendet: Montag, 7. Juni 2021 12:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map With the provided patch the speed is very poor for areas like Norway, probably twice the time. It is much slower because it does the complex multipolygon cutting for each level in the overview map. Probably too slow for complex coastal areas. This time will be the same for precomp-sea unless we can store sea polygons for each resolution. Performance will be no problem if I find a way to use Douglas-Peucker or similar before cutting. That was my original idea but DP produces self intersecting polygons and the MultipolygonCutter cannot cope with that. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> Gesendet: Montag, 7. Juni 2021 11:55 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map Is it only much slower because of not using precomp sea? Or will it be much slower in general? And what is much slower for say Europe continent map? If a modern 4core/8thread processor needs 30 minutes more I would prefer the old way knowing it is worse (if the time difference is negligible with precomp-sea then that would be great). On Mon, 7 Jun 2021 at 12:26, Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>>>> wrote: Hi Gerd This is going to take some studying to work out the implications. Can't do much for the next few days however, but will look carefully at the end of the week. Ticker On Sun, 2021-06-06 at 14:02 +0000, Gerd Petermann wrote:
Hi,
the attached patch improves the overview map, but so far only when precomp-sea is NOT used. I tested it with --generate-sea=multipolygon,floodblocker so that mkgmap really has a multipolygon with the natual=sea data.
For each level in the overview map it uses the original multipolygon data to compute the rings which will might visible at the given resolution. This requires more time compared to the current code but the result is much better and some fine tuning is possible.
To be able to use this also with --precomp-sea we need some changes in the code which generates sea.zip so that one multipolygon relation for each tile is stored.
I've uploaded the results here: https://files.mkgmap.org.uk/download/511/compare.7z What do you think?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org
the problem is - using improve-overview some tiles in the overview map miss sea. I am pretty sure this happens on default style too. But likely not if you use --no-trim and / or keep-complete for splitting. Attached is the areas.list On Sat, 12 Jun 2021 at 09:40, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
I don't yet understand what's going on. Please provide a link to your areas.list
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Freitag, 11. Juni 2021 12:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Nope - that did not help. And I think the problem is a bit unrelated. Mkgmap with your new version and --improve-overview assumes there is an empty map - and puts those three square areas of missing anything. Maybe you give it a try and analyse what happens.
I actually think this bug has been there before already - and it happened to me with contourlines only maps. Meaning mkgmap cuts the map area way too aggressively, and removes part of the map that actually even have content - or was it splitter. I think for contourlines only maps I had to use splitter with --keep-complete and --no-trim else there would be missing. areas in the map. (not on the outside but right in the middle in the ocean usually - but sometimes also e.g. northernmost parts of Norway in an Europe contourlines only map).
So I split australia-oceania WITHOUT --no-trim. Are you assuming to split with --no-trim? Actually those grey boxes are each of its own separate tiles (with nearly no content - e.g. one has a riff polygon only). I guess there is lots of openseamap stuff so splitter creates those tiny tiles... Mkgmap should never trip on the overview map. The normal map should be trimmed aggressively - as we still cannot cut according to a bounding polygon and only using rectangles. But the overview map sea creation should not cut out sea or anything.
I guess you never noticed that working on Norway - but it would be a good start to play around with australia-oceania (it is nice to work with - because it is relatively small in size so compiles fast). See attached screenshot of overview map. All the selected tiles were before showing sea (and do so once past the overview map too). The high DP filter was not the problem. For Australia-Oceania the --improve-overview right now is not a good example. The map was better before. Oh yeah - and --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20 looks better than small values. Actually I think even to rather increase more. Maybe that is why I had less problems right from the start - because I cut away tiny islands.
C:\openmtbmap\maps>if yes NEQ no start /low /b /wait java -jar -XX:+AggressiveHeap -XX:StringTableSize=1000003 -Xms15000M -Xmx29000M C:\openmtbmap\mkgmap.jar --max-jobs=8 --order-by-decreasing-area "--generate-sea" --code-page=1252 "--precomp-sea=C:\openmtbmap\maps\sea.zip" "--style-file=C:\openmtbmap\openmtbmap_style" --improve-overview --add-boundary-nodes-at-admin-boundaries --drive-on=detect --allow-reverse-merge --line-types-with-direction=0x18,0x1f,0x10016,0x10101,0x10105,0x10401,0x10403,0x10405,0x10408,0x10409,0x1040b,0x1040d,0x1040e,0x10500,0x10501,0x10502,0x10503,0x10504,0x10505,0x10506,0x10507,0x10607,0x10609,0x1060b,0x10702,0x10703,0x10704,0x10705,0x10706,0x10707,0x10a00,0x10a02,0x10a04,0x10a05,0x10e1e,0x10e0f,0x10e0e,0x10e1e,0x10f0a,0x10f1c,0x10e1d --nsis --index --levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18" --overview-levels="7:17, 8:16, 9:15, 10:14, 11:13, 12:12" --add-pois-to-areas --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier= entrance --x-simplify-filter-line-errors=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,17:6,14:6 --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9,17:2.6 --add-boundary-nodes-at-admin-boundaries=2 --poi-excl-index=0x6405,0x4316,0x2f00 --copyright-file="C:\openmtbmap\openmtbmap_svn\copyrightopm.txt" --license-file="C:\openmtbmap\openmtbmap_svn\licenseopm.txt" --cycle-map --ignore-fixme-values --housenumbers --road-name-config=C:\openmtbmap\openmtbmap_svn\roadNameConfig.txt --split-name-index --link-pois-to-ways --ignore-turn-restrictions --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20" --description=omtb_auo --show-profiles=1 --location-autofill=bounds,is_in,nearest --bounds=C:\openmtbmap\maps\bounds.zip --mdr7-del=pri;sec;ter;cw;min;unsf,uncl;living;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1 .;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;bridge;swing;aqueduct;viaduct;"ntnl bndry";admin_lv=4;"ntnl park";weir;dam;waterfall;rapids;stream;river;drain;ditch;"huge river";"hugest river";"medium river";"small river";"wide river";"hugest canal";"huge canal";"medium canal";"small canal";"big canal";canal;snowpark;Skitour-descent;Skipiste;Skislope;illuminated;Nordic-Skiing;skitour ;platter;ropetow;tbar;chairlift;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath --mdr7-excl=pri;sec;ter;cw;min;unsf,uncl;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1.;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx 4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;"ntnl bndry";admin_lv=4;"ntnl park";"huge river";"hugest river";"medium river";"small river";"wide river";"hugest canal";"huge canal";"medium canal";"small canal";"big canal";canal;snowpark;Skitour-descent;illuminated;Nordic-Skiing;skitour;platter;ropetow;tbar;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath --route --country-abbr=auo --country-name=australia-oceania --mapname=65340000 --family-id=6534 --product-id=1 --series-name=omtb_australia-oceania_11.06.2021 --family-name=mtb_auo_11.06.2021 --tdbfile --gmapi --overview-mapname=mapsetc --keep-going --area-name="australia-oceania_11.06.2021_omtb" -c D:\openmtbmap\maps\template.australia-oceania C:\OpenMTBMap\contourlines20\australia-oceania\7*.img typauo.TYP
On Fri, 11 Jun 2021 at 12:25, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com>> wrote: yes I was using:
--x-simplify-filter-line-errors=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,16:8,14:9 --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9 --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20"
levels = 0:24, 1:22, 2:21, 3:20, 4:19, 5:18 overview-levels = 6:17, 7:16, 8:15, 9:14, 10:13
As this only affects the overview map - I guess I should change it to: --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9,17:2.6 ??
The polygon-size-limits should not matter as I have the skip-size filter set for sea.
I had worked quite a long time to optimize those settings with the old behaviour.
On Fri, 11 Jun 2021 at 11:50, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix,
Maybe you are using large values for the Douglas-Peucker filter at low resolutions? That's probably a bad idea with the new option. I always tested with the default 2.6 for all levels. The effect of the new option is that DP really can do its work.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Freitag, 11. Juni 2021 10:23 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
--generate-sea --precomp-sea=C:\openmtbmap\maps\sea.zip --order-by-decreasing-area --allow-reverse-merge I thought using precomp-sea is fine (I did not update the precomp-sea in between)
On Fri, 11 Jun 2021 at 11:10, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>> wrote: compilation time includes splitting, and some other stuff. Loads of countries (9:34 / 9:21 (sorry dumb error 9:19) for all european single countries and a few continents (but not Europe continent) in hours.
On Fri, 11 Jun 2021 at 11:08, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>> wrote: I just compiled the australia-oceania map with that option, and I think I must be missing something. It got substantially worse (it is identical until the overview map kicks in) - then I get some huge squares of sea missing. Compile time for all maps until that point before Compilation time is not up a lot: 0:12 - 9:46 = 9:34 one week before (except older mapdata no changes in compilation procedure and older mkgmap) 20:17 - 5:38 = 9:19
Anything I could be missing? I use the newest low-res branch build and added --improve-overview to the compilation process.
in my polygons file I have: natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=2 } [0x10f1d resolution 10]
On Fri, 11 Jun 2021 at 07:12, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>> wrote: Hi all,
I hoped for some positive feedback on this but got none so far. Did I miss something important?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>> Gesendet: Montag, 7. Juni 2021 21:05 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Hi Felix,
the map contained was without routing or index, so for a normal map the difference should be even smaller. There is no need to change sea.zip. You just have to use --improve-overview for now.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> Gesendet: Montag, 7. Juni 2021 21:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
I guess that is a time for a full Norway map based on default style - so that is quite okay. Not a sea only Norway map... Well I hope that Thorsten Kukuk can adapt his sea files in the near future then...
On Mon, 7 Jun 2021 at 19:37, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> wrote: OK, I think found a good solution. Speed is quite OK, I see 9 min 48 secs for map of norway and instead of 8 min 44 secs with r4756, and I consider Norway to be a worst case.
See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4761 for the details.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>> im Auftrag von Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> Gesendet: Montag, 7. Juni 2021 12:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
With the provided patch the speed is very poor for areas like Norway, probably twice the time. It is much slower because it does the complex multipolygon cutting for each level in the overview map. Probably too slow for complex coastal areas. This time will be the same for precomp-sea unless we can store sea polygons for each resolution.
Performance will be no problem if I find a way to use Douglas-Peucker or similar before cutting. That was my original idea but DP produces self intersecting polygons and the MultipolygonCutter cannot cope with that.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> Gesendet: Montag, 7. Juni 2021 11:55 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Is it only much slower because of not using precomp sea? Or will it be much slower in general? And what is much slower for say Europe continent map? If a modern 4core/8thread processor needs 30 minutes more I would prefer the old way knowing it is worse (if the time difference is negligible with precomp-sea then that would be great).
On Mon, 7 Jun 2021 at 12:26, Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>>>> wrote: Hi Gerd
This is going to take some studying to work out the implications. Can't do much for the next few days however, but will look carefully at the end of the week.
Ticker
On Sun, 2021-06-06 at 14:02 +0000, Gerd Petermann wrote:
Hi,
the attached patch improves the overview map, but so far only when precomp-sea is NOT used. I tested it with --generate-sea=multipolygon,floodblocker so that mkgmap really has a multipolygon with the natual=sea data.
For each level in the overview map it uses the original multipolygon data to compute the rings which will might visible at the given resolution. This requires more time compared to the current code but the result is much better and some fine tuning is possible.
To be able to use this also with --precomp-sea we need some changes in the code which generates sea.zip so that one multipolygon relation for each tile is stored.
I've uploaded the results here: https://files.mkgmap.org.uk/download/511/compare.7z What do you think?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
Hi Felix, all your images show gaps between tiles, not only those with --improve-overview. That's what I don't understand. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Samstag, 12. Juni 2021 09:24 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map the problem is - using improve-overview some tiles in the overview map miss sea. I am pretty sure this happens on default style too. But likely not if you use --no-trim and / or keep-complete for splitting. Attached is the areas.list On Sat, 12 Jun 2021 at 09:40, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix, I don't yet understand what's going on. Please provide a link to your areas.list Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Freitag, 11. Juni 2021 12:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map Nope - that did not help. And I think the problem is a bit unrelated. Mkgmap with your new version and --improve-overview assumes there is an empty map - and puts those three square areas of missing anything. Maybe you give it a try and analyse what happens. I actually think this bug has been there before already - and it happened to me with contourlines only maps. Meaning mkgmap cuts the map area way too aggressively, and removes part of the map that actually even have content - or was it splitter. I think for contourlines only maps I had to use splitter with --keep-complete and --no-trim else there would be missing. areas in the map. (not on the outside but right in the middle in the ocean usually - but sometimes also e.g. northernmost parts of Norway in an Europe contourlines only map). So I split australia-oceania WITHOUT --no-trim. Are you assuming to split with --no-trim? Actually those grey boxes are each of its own separate tiles (with nearly no content - e.g. one has a riff polygon only). I guess there is lots of openseamap stuff so splitter creates those tiny tiles... Mkgmap should never trip on the overview map. The normal map should be trimmed aggressively - as we still cannot cut according to a bounding polygon and only using rectangles. But the overview map sea creation should not cut out sea or anything. I guess you never noticed that working on Norway - but it would be a good start to play around with australia-oceania (it is nice to work with - because it is relatively small in size so compiles fast). See attached screenshot of overview map. All the selected tiles were before showing sea (and do so once past the overview map too). The high DP filter was not the problem. For Australia-Oceania the --improve-overview right now is not a good example. The map was better before. Oh yeah - and --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20 looks better than small values. Actually I think even to rather increase more. Maybe that is why I had less problems right from the start - because I cut away tiny islands. C:\openmtbmap\maps>if yes NEQ no start /low /b /wait java -jar -XX:+AggressiveHeap -XX:StringTableSize=1000003 -Xms15000M -Xmx29000M C:\openmtbmap\mkgmap.jar --max-jobs=8 --order-by-decreasing-area "--generate-sea" --code-page=1252 "--precomp-sea=C:\openmtbmap\maps\sea.zip" "--style-file=C:\openmtbmap\openmtbmap_style" --improve-overview --add-boundary-nodes-at-admin-boundaries --drive-on=detect --allow-reverse-merge --line-types-with-direction=0x18,0x1f,0x10016,0x10101,0x10105,0x10401,0x10403,0x10405,0x10408,0x10409,0x1040b,0x1040d,0x1040e,0x10500,0x10501,0x10502,0x10503,0x10504,0x10505,0x10506,0x10507,0x10607,0x10609,0x1060b,0x10702,0x10703,0x10704,0x10705,0x10706,0x10707,0x10a00,0x10a02,0x10a04,0x10a05,0x10e1e,0x10e0f,0x10e0e,0x10e1e,0x10f0a,0x10f1c,0x10e1d --nsis --index --levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18" --overview-levels="7:17, 8:16, 9:15, 10:14, 11:13, 12:12" --add-pois-to-areas --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier= entrance --x-simplify-filter-line-errors=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,17:6,14:6 --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9,17:2.6 --add-boundary-nodes-at-admin-boundaries=2 --poi-excl-index=0x6405,0x4316,0x2f00 --copyright-file="C:\openmtbmap\openmtbmap_svn\copyrightopm.txt" --license-file="C:\openmtbmap\openmtbmap_svn\licenseopm.txt" --cycle-map --ignore-fixme-values --housenumbers --road-name-config=C:\openmtbmap\openmtbmap_svn\roadNameConfig.txt --split-name-index --link-pois-to-ways --ignore-turn-restrictions --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20" --description=omtb_auo --show-profiles=1 --location-autofill=bounds,is_in,nearest --bounds=C:\openmtbmap\maps\bounds.zip --mdr7-del=pri;sec;ter;cw;min;unsf,uncl;living;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1 .;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;bridge;swing;aqueduct;viaduct;"ntnl bndry";admin_lv=4;"ntnl park";weir;dam;waterfall;rapids;stream;river;drain;ditch;"huge river";"hugest river";"medium river";"small river";"wide river";"hugest canal";"huge canal";"medium canal";"small canal";"big canal";canal;snowpark;Skitour-descent;Skipiste;Skislope;illuminated;Nordic-Skiing;skitour ;platter;ropetow;tbar;chairlift;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath --mdr7-excl=pri;sec;ter;cw;min;unsf,uncl;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1.;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx 4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;"ntnl bndry";admin_lv=4;"ntnl park";"huge river";"hugest river";"medium river";"small river";"wide river";"hugest canal";"huge canal";"medium canal";"small canal";"big canal";canal;snowpark;Skitour-descent;illuminated;Nordic-Skiing;skitour;platter;ropetow;tbar;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath --route --country-abbr=auo --country-name=australia-oceania --mapname=65340000 --family-id=6534 --product-id=1 --series-name=omtb_australia-oceania_11.06.2021 --family-name=mtb_auo_11.06.2021 --tdbfile --gmapi --overview-mapname=mapsetc --keep-going --area-name="australia-oceania_11.06.2021_omtb" -c D:\openmtbmap\maps\template.australia-oceania C:\OpenMTBMap\contourlines20\australia-oceania\7*.img typauo.TYP On Fri, 11 Jun 2021 at 12:25, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> wrote: yes I was using: --x-simplify-filter-line-errors=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,16:8,14:9 --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9 --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20" levels = 0:24, 1:22, 2:21, 3:20, 4:19, 5:18 overview-levels = 6:17, 7:16, 8:15, 9:14, 10:13 As this only affects the overview map - I guess I should change it to: --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9,17:2.6 ?? The polygon-size-limits should not matter as I have the skip-size filter set for sea. I had worked quite a long time to optimize those settings with the old behaviour. On Fri, 11 Jun 2021 at 11:50, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>> wrote: Hi Felix, Maybe you are using large values for the Douglas-Peucker filter at low resolutions? That's probably a bad idea with the new option. I always tested with the default 2.6 for all levels. The effect of the new option is that DP really can do its work. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> Gesendet: Freitag, 11. Juni 2021 10:23 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map --generate-sea --precomp-sea=C:\openmtbmap\maps\sea.zip --order-by-decreasing-area --allow-reverse-merge I thought using precomp-sea is fine (I did not update the precomp-sea in between) On Fri, 11 Jun 2021 at 11:10, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> wrote: compilation time includes splitting, and some other stuff. Loads of countries (9:34 / 9:21 (sorry dumb error 9:19) for all european single countries and a few continents (but not Europe continent) in hours. On Fri, 11 Jun 2021 at 11:08, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> wrote: I just compiled the australia-oceania map with that option, and I think I must be missing something. It got substantially worse (it is identical until the overview map kicks in) - then I get some huge squares of sea missing. Compile time for all maps until that point before Compilation time is not up a lot: 0:12 - 9:46 = 9:34 one week before (except older mapdata no changes in compilation procedure and older mkgmap) 20:17 - 5:38 = 9:19 Anything I could be missing? I use the newest low-res branch build and added --improve-overview to the compilation process. in my polygons file I have: natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=2 } [0x10f1d resolution 10] On Fri, 11 Jun 2021 at 07:12, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> wrote: Hi all, I hoped for some positive feedback on this but got none so far. Did I miss something important? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> Gesendet: Montag, 7. Juni 2021 21:05 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map Hi Felix, the map contained was without routing or index, so for a normal map the difference should be even smaller. There is no need to change sea.zip. You just have to use --improve-overview for now. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> Gesendet: Montag, 7. Juni 2021 21:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map I guess that is a time for a full Norway map based on default style - so that is quite okay. Not a sea only Norway map... Well I hope that Thorsten Kukuk can adapt his sea files in the near future then... On Mon, 7 Jun 2021 at 19:37, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>> wrote: OK, I think found a good solution. Speed is quite OK, I see 9 min 48 secs for map of norway and instead of 8 min 44 secs with r4756, and I consider Norway to be a worst case. See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4761 for the details. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>> Gesendet: Montag, 7. Juni 2021 12:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map With the provided patch the speed is very poor for areas like Norway, probably twice the time. It is much slower because it does the complex multipolygon cutting for each level in the overview map. Probably too slow for complex coastal areas. This time will be the same for precomp-sea unless we can store sea polygons for each resolution. Performance will be no problem if I find a way to use Douglas-Peucker or similar before cutting. That was my original idea but DP produces self intersecting polygons and the MultipolygonCutter cannot cope with that. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>>> Gesendet: Montag, 7. Juni 2021 11:55 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map Is it only much slower because of not using precomp sea? Or will it be much slower in general? And what is much slower for say Europe continent map? If a modern 4core/8thread processor needs 30 minutes more I would prefer the old way knowing it is worse (if the time difference is negligible with precomp-sea then that would be great). On Mon, 7 Jun 2021 at 12:26, Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>>>>> wrote: Hi Gerd This is going to take some studying to work out the implications. Can't do much for the next few days however, but will look carefully at the end of the week. Ticker On Sun, 2021-06-06 at 14:02 +0000, Gerd Petermann wrote:
Hi,
the attached patch improves the overview map, but so far only when precomp-sea is NOT used. I tested it with --generate-sea=multipolygon,floodblocker so that mkgmap really has a multipolygon with the natual=sea data.
For each level in the overview map it uses the original multipolygon data to compute the rings which will might visible at the given resolution. This requires more time compared to the current code but the result is much better and some fine tuning is possible.
To be able to use this also with --precomp-sea we need some changes in the code which generates sea.zip so that one multipolygon relation for each tile is stored.
I've uploaded the results here: https://files.mkgmap.org.uk/download/511/compare.7z What do you think?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org
I use C:\openmtbmap\osmconvert.exe --drop-author --drop-version D:\openmtbmap\osmpbf_geofabrik\australia-oceania-latest.osm.pbf -o=C:\openmtbmap\osmpbf_geofabrik\australia-oceania.o5m then start /low /b /wait java -XX:+AggressiveHeap -Xms15000m -Xmx54000m -jar C:\openmtbmap\splitter.jar "--precomp-sea=C:\openmtbmap\maps\sea.zip" --max-nodes=1000000 --max-threads=8 --output=pbf "--keep-complete" --route-rel-values=mtb,bicycle,foot,hiking --max-areas=4000 --geonames-file=C:\OpenMTBMap\maps\cities5000.zip --description=australia-oceania --mapid=65340000 C:\openmtbmap\osmpbf_geofabrik\australia-oceania.o5m The highlighted tiles selected in Mapsource for sending to GPS device - are empty using improve-overview - but they are filled with sea without using it. They are only empty in overview map. I think those gaps also should not be there - so it is a wider problem that existed before already. For overview map mkgmap should use all the sea/land area for the full coverage - and not cut out areas. Actually cutting for sea/land should also not happen in the normal map. The reason for trimming is to have to maps not overlap itself with empty content - because mkgmap/splitter only cuts rectangles - not polygons. But sea/land will be identical in two country maps - so should not be trimmed On Sat, 12 Jun 2021 at 10:24, Felix Hartmann <extremecarver@gmail.com> wrote:
the problem is - using improve-overview some tiles in the overview map miss sea. I am pretty sure this happens on default style too. But likely not if you use --no-trim and / or keep-complete for splitting. Attached is the areas.list
On Sat, 12 Jun 2021 at 09:40, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
I don't yet understand what's going on. Please provide a link to your areas.list
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Freitag, 11. Juni 2021 12:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Nope - that did not help. And I think the problem is a bit unrelated. Mkgmap with your new version and --improve-overview assumes there is an empty map - and puts those three square areas of missing anything. Maybe you give it a try and analyse what happens.
I actually think this bug has been there before already - and it happened to me with contourlines only maps. Meaning mkgmap cuts the map area way too aggressively, and removes part of the map that actually even have content - or was it splitter. I think for contourlines only maps I had to use splitter with --keep-complete and --no-trim else there would be missing. areas in the map. (not on the outside but right in the middle in the ocean usually - but sometimes also e.g. northernmost parts of Norway in an Europe contourlines only map).
So I split australia-oceania WITHOUT --no-trim. Are you assuming to split with --no-trim? Actually those grey boxes are each of its own separate tiles (with nearly no content - e.g. one has a riff polygon only). I guess there is lots of openseamap stuff so splitter creates those tiny tiles... Mkgmap should never trip on the overview map. The normal map should be trimmed aggressively - as we still cannot cut according to a bounding polygon and only using rectangles. But the overview map sea creation should not cut out sea or anything.
I guess you never noticed that working on Norway - but it would be a good start to play around with australia-oceania (it is nice to work with - because it is relatively small in size so compiles fast). See attached screenshot of overview map. All the selected tiles were before showing sea (and do so once past the overview map too). The high DP filter was not the problem. For Australia-Oceania the --improve-overview right now is not a good example. The map was better before. Oh yeah - and --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20 looks better than small values. Actually I think even to rather increase more. Maybe that is why I had less problems right from the start - because I cut away tiny islands.
C:\openmtbmap\maps>if yes NEQ no start /low /b /wait java -jar -XX:+AggressiveHeap -XX:StringTableSize=1000003 -Xms15000M -Xmx29000M C:\openmtbmap\mkgmap.jar --max-jobs=8 --order-by-decreasing-area "--generate-sea" --code-page=1252 "--precomp-sea=C:\openmtbmap\maps\sea.zip" "--style-file=C:\openmtbmap\openmtbmap_style" --improve-overview --add-boundary-nodes-at-admin-boundaries --drive-on=detect --allow-reverse-merge --line-types-with-direction=0x18,0x1f,0x10016,0x10101,0x10105,0x10401,0x10403,0x10405,0x10408,0x10409,0x1040b,0x1040d,0x1040e,0x10500,0x10501,0x10502,0x10503,0x10504,0x10505,0x10506,0x10507,0x10607,0x10609,0x1060b,0x10702,0x10703,0x10704,0x10705,0x10706,0x10707,0x10a00,0x10a02,0x10a04,0x10a05,0x10e1e,0x10e0f,0x10e0e,0x10e1e,0x10f0a,0x10f1c,0x10e1d --nsis --index --levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18" --overview-levels="7:17, 8:16, 9:15, 10:14, 11:13, 12:12" --add-pois-to-areas --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier= entrance --x-simplify-filter-line-errors=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,17:6,14:6 --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9,17:2.6 --add-boundary-nodes-at-admin-boundaries=2 --poi-excl-index=0x6405,0x4316,0x2f00 --copyright-file="C:\openmtbmap\openmtbmap_svn\copyrightopm.txt" --license-file="C:\openmtbmap\openmtbmap_svn\licenseopm.txt" --cycle-map --ignore-fixme-values --housenumbers --road-name-config=C:\openmtbmap\openmtbmap_svn\roadNameConfig.txt --split-name-index --link-pois-to-ways --ignore-turn-restrictions --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20" --description=omtb_auo --show-profiles=1 --location-autofill=bounds,is_in,nearest --bounds=C:\openmtbmap\maps\bounds.zip --mdr7-del=pri;sec;ter;cw;min;unsf,uncl;living;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1 .;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;bridge;swing;aqueduct;viaduct;"ntnl bndry";admin_lv=4;"ntnl park";weir;dam;waterfall;rapids;stream;river;drain;ditch;"huge river";"hugest river";"medium river";"small river";"wide river";"hugest canal";"huge canal";"medium canal";"small canal";"big canal";canal;snowpark;Skitour-descent;Skipiste;Skislope;illuminated;Nordic-Skiing;skitour ;platter;ropetow;tbar;chairlift;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath --mdr7-excl=pri;sec;ter;cw;min;unsf,uncl;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1.;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx 4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;"ntnl bndry";admin_lv=4;"ntnl park";"huge river";"hugest river";"medium river";"small river";"wide river";"hugest canal";"huge canal";"medium canal";"small canal";"big canal";canal;snowpark;Skitour-descent;illuminated;Nordic-Skiing;skitour;platter;ropetow;tbar;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath --route --country-abbr=auo --country-name=australia-oceania --mapname=65340000 --family-id=6534 --product-id=1 --series-name=omtb_australia-oceania_11.06.2021 --family-name=mtb_auo_11.06.2021 --tdbfile --gmapi --overview-mapname=mapsetc --keep-going --area-name="australia-oceania_11.06.2021_omtb" -c D:\openmtbmap\maps\template.australia-oceania C:\OpenMTBMap\contourlines20\australia-oceania\7*.img typauo.TYP
On Fri, 11 Jun 2021 at 12:25, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com>> wrote: yes I was using:
--x-simplify-filter-line-errors=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,16:8,14:9 --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9 --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20"
levels = 0:24, 1:22, 2:21, 3:20, 4:19, 5:18 overview-levels = 6:17, 7:16, 8:15, 9:14, 10:13
As this only affects the overview map - I guess I should change it to: --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9,17:2.6 ??
The polygon-size-limits should not matter as I have the skip-size filter set for sea.
I had worked quite a long time to optimize those settings with the old behaviour.
On Fri, 11 Jun 2021 at 11:50, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix,
Maybe you are using large values for the Douglas-Peucker filter at low resolutions? That's probably a bad idea with the new option. I always tested with the default 2.6 for all levels. The effect of the new option is that DP really can do its work.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Freitag, 11. Juni 2021 10:23 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
--generate-sea --precomp-sea=C:\openmtbmap\maps\sea.zip --order-by-decreasing-area --allow-reverse-merge I thought using precomp-sea is fine (I did not update the precomp-sea in between)
On Fri, 11 Jun 2021 at 11:10, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>> wrote: compilation time includes splitting, and some other stuff. Loads of countries (9:34 / 9:21 (sorry dumb error 9:19) for all european single countries and a few continents (but not Europe continent) in hours.
On Fri, 11 Jun 2021 at 11:08, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>> wrote: I just compiled the australia-oceania map with that option, and I think I must be missing something. It got substantially worse (it is identical until the overview map kicks in) - then I get some huge squares of sea missing. Compile time for all maps until that point before Compilation time is not up a lot: 0:12 - 9:46 = 9:34 one week before (except older mapdata no changes in compilation procedure and older mkgmap) 20:17 - 5:38 = 9:19
Anything I could be missing? I use the newest low-res branch build and added --improve-overview to the compilation process.
in my polygons file I have: natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=2 } [0x10f1d resolution 10]
On Fri, 11 Jun 2021 at 07:12, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>> wrote: Hi all,
I hoped for some positive feedback on this but got none so far. Did I miss something important?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>> Gesendet: Montag, 7. Juni 2021 21:05 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Hi Felix,
the map contained was without routing or index, so for a normal map the difference should be even smaller. There is no need to change sea.zip. You just have to use --improve-overview for now.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> Gesendet: Montag, 7. Juni 2021 21:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
I guess that is a time for a full Norway map based on default style - so that is quite okay. Not a sea only Norway map... Well I hope that Thorsten Kukuk can adapt his sea files in the near future then...
On Mon, 7 Jun 2021 at 19:37, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> wrote: OK, I think found a good solution. Speed is quite OK, I see 9 min 48 secs for map of norway and instead of 8 min 44 secs with r4756, and I consider Norway to be a worst case.
See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4761 for the details.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
Gesendet: Montag, 7. Juni 2021 12:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
With the provided patch the speed is very poor for areas like Norway, probably twice the time. It is much slower because it does the complex multipolygon cutting for each level in the overview map. Probably too slow for complex coastal areas. This time will be the same for precomp-sea unless we can store sea polygons for each resolution.
Performance will be no problem if I find a way to use Douglas-Peucker or similar before cutting. That was my original idea but DP produces self intersecting polygons and the MultipolygonCutter cannot cope with that.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> Gesendet: Montag, 7. Juni 2021 11:55 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Is it only much slower because of not using precomp sea? Or will it be much slower in general? And what is much slower for say Europe continent map? If a modern 4core/8thread processor needs 30 minutes more I would prefer the old way knowing it is worse (if the time difference is negligible with precomp-sea then that would be great).
On Mon, 7 Jun 2021 at 12:26, Ticker Berkin <rwb-mkgmap@jagit.co.uk <mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>>>> wrote: Hi Gerd
This is going to take some studying to work out the implications. Can't do much for the next few days however, but will look carefully at the end of the week.
Ticker
On Sun, 2021-06-06 at 14:02 +0000, Gerd Petermann wrote:
Hi,
the attached patch improves the overview map, but so far only when precomp-sea is NOT used. I tested it with --generate-sea=multipolygon,floodblocker so that mkgmap really has a multipolygon with the natual=sea data.
For each level in the overview map it uses the original multipolygon data to compute the rings which will might visible at the given resolution. This requires more time compared to the current code but the result is much better and some fine tuning is possible.
To be able to use this also with --precomp-sea we need some changes in the code which generates sea.zip so that one multipolygon relation for each tile is stored.
I've uploaded the results here: https://files.mkgmap.org.uk/download/511/compare.7z What do you think?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
highlighted = pink. maybe that confused you. I should have explained better. But in general ll those gaps should not be there. On Sat, 12 Jun 2021 at 10:31, Felix Hartmann <extremecarver@gmail.com> wrote:
I use C:\openmtbmap\osmconvert.exe --drop-author --drop-version D:\openmtbmap\osmpbf_geofabrik\australia-oceania-latest.osm.pbf -o=C:\openmtbmap\osmpbf_geofabrik\australia-oceania.o5m then start /low /b /wait java -XX:+AggressiveHeap -Xms15000m -Xmx54000m -jar C:\openmtbmap\splitter.jar "--precomp-sea=C:\openmtbmap\maps\sea.zip" --max-nodes=1000000 --max-threads=8 --output=pbf "--keep-complete" --route-rel-values=mtb,bicycle,foot,hiking --max-areas=4000 --geonames-file=C:\OpenMTBMap\maps\cities5000.zip --description=australia-oceania --mapid=65340000 C:\openmtbmap\osmpbf_geofabrik\australia-oceania.o5m
The highlighted tiles selected in Mapsource for sending to GPS device - are empty using improve-overview - but they are filled with sea without using it. They are only empty in overview map. I think those gaps also should not be there - so it is a wider problem that existed before already. For overview map mkgmap should use all the sea/land area for the full coverage - and not cut out areas. Actually cutting for sea/land should also not happen in the normal map. The reason for trimming is to have to maps not overlap itself with empty content - because mkgmap/splitter only cuts rectangles - not polygons. But sea/land will be identical in two country maps - so should not be trimmed
On Sat, 12 Jun 2021 at 10:24, Felix Hartmann <extremecarver@gmail.com> wrote:
the problem is - using improve-overview some tiles in the overview map miss sea. I am pretty sure this happens on default style too. But likely not if you use --no-trim and / or keep-complete for splitting. Attached is the areas.list
On Sat, 12 Jun 2021 at 09:40, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
I don't yet understand what's going on. Please provide a link to your areas.list
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Freitag, 11. Juni 2021 12:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Nope - that did not help. And I think the problem is a bit unrelated. Mkgmap with your new version and --improve-overview assumes there is an empty map - and puts those three square areas of missing anything. Maybe you give it a try and analyse what happens.
I actually think this bug has been there before already - and it happened to me with contourlines only maps. Meaning mkgmap cuts the map area way too aggressively, and removes part of the map that actually even have content - or was it splitter. I think for contourlines only maps I had to use splitter with --keep-complete and --no-trim else there would be missing. areas in the map. (not on the outside but right in the middle in the ocean usually - but sometimes also e.g. northernmost parts of Norway in an Europe contourlines only map).
So I split australia-oceania WITHOUT --no-trim. Are you assuming to split with --no-trim? Actually those grey boxes are each of its own separate tiles (with nearly no content - e.g. one has a riff polygon only). I guess there is lots of openseamap stuff so splitter creates those tiny tiles... Mkgmap should never trip on the overview map. The normal map should be trimmed aggressively - as we still cannot cut according to a bounding polygon and only using rectangles. But the overview map sea creation should not cut out sea or anything.
I guess you never noticed that working on Norway - but it would be a good start to play around with australia-oceania (it is nice to work with - because it is relatively small in size so compiles fast). See attached screenshot of overview map. All the selected tiles were before showing sea (and do so once past the overview map too). The high DP filter was not the problem. For Australia-Oceania the --improve-overview right now is not a good example. The map was better before. Oh yeah - and --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20 looks better than small values. Actually I think even to rather increase more. Maybe that is why I had less problems right from the start - because I cut away tiny islands.
C:\openmtbmap\maps>if yes NEQ no start /low /b /wait java -jar -XX:+AggressiveHeap -XX:StringTableSize=1000003 -Xms15000M -Xmx29000M C:\openmtbmap\mkgmap.jar --max-jobs=8 --order-by-decreasing-area "--generate-sea" --code-page=1252 "--precomp-sea=C:\openmtbmap\maps\sea.zip" "--style-file=C:\openmtbmap\openmtbmap_style" --improve-overview --add-boundary-nodes-at-admin-boundaries --drive-on=detect --allow-reverse-merge --line-types-with-direction=0x18,0x1f,0x10016,0x10101,0x10105,0x10401,0x10403,0x10405,0x10408,0x10409,0x1040b,0x1040d,0x1040e,0x10500,0x10501,0x10502,0x10503,0x10504,0x10505,0x10506,0x10507,0x10607,0x10609,0x1060b,0x10702,0x10703,0x10704,0x10705,0x10706,0x10707,0x10a00,0x10a02,0x10a04,0x10a05,0x10e1e,0x10e0f,0x10e0e,0x10e1e,0x10f0a,0x10f1c,0x10e1d --nsis --index --levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18" --overview-levels="7:17, 8:16, 9:15, 10:14, 11:13, 12:12" --add-pois-to-areas --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier= entrance --x-simplify-filter-line-errors=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,17:6,14:6 --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9,17:2.6 --add-boundary-nodes-at-admin-boundaries=2 --poi-excl-index=0x6405,0x4316,0x2f00 --copyright-file="C:\openmtbmap\openmtbmap_svn\copyrightopm.txt" --license-file="C:\openmtbmap\openmtbmap_svn\licenseopm.txt" --cycle-map --ignore-fixme-values --housenumbers --road-name-config=C:\openmtbmap\openmtbmap_svn\roadNameConfig.txt --split-name-index --link-pois-to-ways --ignore-turn-restrictions --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20" --description=omtb_auo --show-profiles=1 --location-autofill=bounds,is_in,nearest --bounds=C:\openmtbmap\maps\bounds.zip --mdr7-del=pri;sec;ter;cw;min;unsf,uncl;living;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1 .;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;bridge;swing;aqueduct;viaduct;"ntnl bndry";admin_lv=4;"ntnl park";weir;dam;waterfall;rapids;stream;river;drain;ditch;"huge river";"hugest river";"medium river";"small river";"wide river";"hugest canal";"huge canal";"medium canal";"small canal";"big canal";canal;snowpark;Skitour-descent;Skipiste;Skislope;illuminated;Nordic-Skiing;skitour ;platter;ropetow;tbar;chairlift;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath --mdr7-excl=pri;sec;ter;cw;min;unsf,uncl;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1.;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx 4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;"ntnl bndry";admin_lv=4;"ntnl park";"huge river";"hugest river";"medium river";"small river";"wide river";"hugest canal";"huge canal";"medium canal";"small canal";"big canal";canal;snowpark;Skitour-descent;illuminated;Nordic-Skiing;skitour;platter;ropetow;tbar;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath --route --country-abbr=auo --country-name=australia-oceania --mapname=65340000 --family-id=6534 --product-id=1 --series-name=omtb_australia-oceania_11.06.2021 --family-name=mtb_auo_11.06.2021 --tdbfile --gmapi --overview-mapname=mapsetc --keep-going --area-name="australia-oceania_11.06.2021_omtb" -c D:\openmtbmap\maps\template.australia-oceania C:\OpenMTBMap\contourlines20\australia-oceania\7*.img typauo.TYP
On Fri, 11 Jun 2021 at 12:25, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com>> wrote: yes I was using:
--x-simplify-filter-line-errors=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,16:8,14:9 --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9 --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20"
levels = 0:24, 1:22, 2:21, 3:20, 4:19, 5:18 overview-levels = 6:17, 7:16, 8:15, 9:14, 10:13
As this only affects the overview map - I guess I should change it to: --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9,17:2.6 ??
The polygon-size-limits should not matter as I have the skip-size filter set for sea.
I had worked quite a long time to optimize those settings with the old behaviour.
On Fri, 11 Jun 2021 at 11:50, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix,
Maybe you are using large values for the Douglas-Peucker filter at low resolutions? That's probably a bad idea with the new option. I always tested with the default 2.6 for all levels. The effect of the new option is that DP really can do its work.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Freitag, 11. Juni 2021 10:23 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
--generate-sea --precomp-sea=C:\openmtbmap\maps\sea.zip --order-by-decreasing-area --allow-reverse-merge I thought using precomp-sea is fine (I did not update the precomp-sea in between)
On Fri, 11 Jun 2021 at 11:10, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>> wrote: compilation time includes splitting, and some other stuff. Loads of countries (9:34 / 9:21 (sorry dumb error 9:19) for all european single countries and a few continents (but not Europe continent) in hours.
On Fri, 11 Jun 2021 at 11:08, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>> wrote: I just compiled the australia-oceania map with that option, and I think I must be missing something. It got substantially worse (it is identical until the overview map kicks in) - then I get some huge squares of sea missing. Compile time for all maps until that point before Compilation time is not up a lot: 0:12 - 9:46 = 9:34 one week before (except older mapdata no changes in compilation procedure and older mkgmap) 20:17 - 5:38 = 9:19
Anything I could be missing? I use the newest low-res branch build and added --improve-overview to the compilation process.
in my polygons file I have: natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=2 } [0x10f1d resolution 10]
On Fri, 11 Jun 2021 at 07:12, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>> wrote: Hi all,
I hoped for some positive feedback on this but got none so far. Did I miss something important?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>> Gesendet: Montag, 7. Juni 2021 21:05 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Hi Felix,
the map contained was without routing or index, so for a normal map the difference should be even smaller. There is no need to change sea.zip. You just have to use --improve-overview for now.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> Gesendet: Montag, 7. Juni 2021 21:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
I guess that is a time for a full Norway map based on default style - so that is quite okay. Not a sea only Norway map... Well I hope that Thorsten Kukuk can adapt his sea files in the near future then...
On Mon, 7 Jun 2021 at 19:37, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> wrote: OK, I think found a good solution. Speed is quite OK, I see 9 min 48 secs for map of norway and instead of 8 min 44 secs with r4756, and I consider Norway to be a worst case.
See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4761 for the details.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>>> Gesendet: Montag, 7. Juni 2021 12:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
With the provided patch the speed is very poor for areas like Norway, probably twice the time. It is much slower because it does the complex multipolygon cutting for each level in the overview map. Probably too slow for complex coastal areas. This time will be the same for precomp-sea unless we can store sea polygons for each resolution.
Performance will be no problem if I find a way to use Douglas-Peucker or similar before cutting. That was my original idea but DP produces self intersecting polygons and the MultipolygonCutter cannot cope with that.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com
<mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com
<mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com <mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> Gesendet: Montag, 7. Juni 2021 11:55 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Is it only much slower because of not using precomp sea? Or will it be much slower in general? And what is much slower for say Europe continent map? If a modern 4core/8thread processor needs 30 minutes more I would prefer the old way knowing it is worse (if the time difference is negligible with precomp-sea then that would be great).
On Mon, 7 Jun 2021 at 12:26, Ticker Berkin <rwb-mkgmap@jagit.co.uk <mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>>>> wrote: Hi Gerd
This is going to take some studying to work out the implications. Can't do much for the next few days however, but will look carefully at the end of the week.
Ticker
On Sun, 2021-06-06 at 14:02 +0000, Gerd Petermann wrote:
Hi,
the attached patch improves the overview map, but so far only when precomp-sea is NOT used. I tested it with --generate-sea=multipolygon,floodblocker so that mkgmap really has a multipolygon with the natual=sea data.
For each level in the overview map it uses the original multipolygon data to compute the rings which will might visible at the given resolution. This requires more time compared to the current code but the result is much better and some fine tuning is possible.
To be able to use this also with --precomp-sea we need some changes in the code which generates sea.zip so that one multipolygon relation for each tile is stored.
I've uploaded the results here: https://files.mkgmap.org.uk/download/511/compare.7z What do you think?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
Hi Felix, I've just used splitter r604 with a freshly downloaded sea.zip and australia-oceania-latest.osm.pbf and your options and I get a completely different areas.list with only 88 tiles, but it also has gaps. They disappear when I remove the --precomp-sea option, so that's one big difference to my test environment. No idea why you get 274 tiles, and they cover a completely different area, even parts of Mexico. I try to find out why splitter creates those gaps now... Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Samstag, 12. Juni 2021 09:34 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map highlighted = pink. maybe that confused you. I should have explained better. But in general ll those gaps should not be there. On Sat, 12 Jun 2021 at 10:31, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> wrote: I use C:\openmtbmap\osmconvert.exe --drop-author --drop-version D:\openmtbmap\osmpbf_geofabrik\australia-oceania-latest.osm.pbf -o=C:\openmtbmap\osmpbf_geofabrik\australia-oceania.o5m then start /low /b /wait java -XX:+AggressiveHeap -Xms15000m -Xmx54000m -jar C:\openmtbmap\splitter.jar "--precomp-sea=C:\openmtbmap\maps\sea.zip" --max-nodes=1000000 --max-threads=8 --output=pbf "--keep-complete" --route-rel-values=mtb,bicycle,foot,hiking --max-areas=4000 --geonames-file=C:\OpenMTBMap\maps\cities5000.zip --description=australia-oceania --mapid=65340000 C:\openmtbmap\osmpbf_geofabrik\australia-oceania.o5m The highlighted tiles selected in Mapsource for sending to GPS device - are empty using improve-overview - but they are filled with sea without using it. They are only empty in overview map. I think those gaps also should not be there - so it is a wider problem that existed before already. For overview map mkgmap should use all the sea/land area for the full coverage - and not cut out areas. Actually cutting for sea/land should also not happen in the normal map. The reason for trimming is to have to maps not overlap itself with empty content - because mkgmap/splitter only cuts rectangles - not polygons. But sea/land will be identical in two country maps - so should not be trimmed On Sat, 12 Jun 2021 at 10:24, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> wrote: the problem is - using improve-overview some tiles in the overview map miss sea. I am pretty sure this happens on default style too. But likely not if you use --no-trim and / or keep-complete for splitting. Attached is the areas.list On Sat, 12 Jun 2021 at 09:40, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix, I don't yet understand what's going on. Please provide a link to your areas.list Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Freitag, 11. Juni 2021 12:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map Nope - that did not help. And I think the problem is a bit unrelated. Mkgmap with your new version and --improve-overview assumes there is an empty map - and puts those three square areas of missing anything. Maybe you give it a try and analyse what happens. I actually think this bug has been there before already - and it happened to me with contourlines only maps. Meaning mkgmap cuts the map area way too aggressively, and removes part of the map that actually even have content - or was it splitter. I think for contourlines only maps I had to use splitter with --keep-complete and --no-trim else there would be missing. areas in the map. (not on the outside but right in the middle in the ocean usually - but sometimes also e.g. northernmost parts of Norway in an Europe contourlines only map). So I split australia-oceania WITHOUT --no-trim. Are you assuming to split with --no-trim? Actually those grey boxes are each of its own separate tiles (with nearly no content - e.g. one has a riff polygon only). I guess there is lots of openseamap stuff so splitter creates those tiny tiles... Mkgmap should never trip on the overview map. The normal map should be trimmed aggressively - as we still cannot cut according to a bounding polygon and only using rectangles. But the overview map sea creation should not cut out sea or anything. I guess you never noticed that working on Norway - but it would be a good start to play around with australia-oceania (it is nice to work with - because it is relatively small in size so compiles fast). See attached screenshot of overview map. All the selected tiles were before showing sea (and do so once past the overview map too). The high DP filter was not the problem. For Australia-Oceania the --improve-overview right now is not a good example. The map was better before. Oh yeah - and --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20 looks better than small values. Actually I think even to rather increase more. Maybe that is why I had less problems right from the start - because I cut away tiny islands. C:\openmtbmap\maps>if yes NEQ no start /low /b /wait java -jar -XX:+AggressiveHeap -XX:StringTableSize=1000003 -Xms15000M -Xmx29000M C:\openmtbmap\mkgmap.jar --max-jobs=8 --order-by-decreasing-area "--generate-sea" --code-page=1252 "--precomp-sea=C:\openmtbmap\maps\sea.zip" "--style-file=C:\openmtbmap\openmtbmap_style" --improve-overview --add-boundary-nodes-at-admin-boundaries --drive-on=detect --allow-reverse-merge --line-types-with-direction=0x18,0x1f,0x10016,0x10101,0x10105,0x10401,0x10403,0x10405,0x10408,0x10409,0x1040b,0x1040d,0x1040e,0x10500,0x10501,0x10502,0x10503,0x10504,0x10505,0x10506,0x10507,0x10607,0x10609,0x1060b,0x10702,0x10703,0x10704,0x10705,0x10706,0x10707,0x10a00,0x10a02,0x10a04,0x10a05,0x10e1e,0x10e0f,0x10e0e,0x10e1e,0x10f0a,0x10f1c,0x10e1d --nsis --index --levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18" --overview-levels="7:17, 8:16, 9:15, 10:14, 11:13, 12:12" --add-pois-to-areas --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier= entrance --x-simplify-filter-line-errors=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,17:6,14:6 --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9,17:2.6 --add-boundary-nodes-at-admin-boundaries=2 --poi-excl-index=0x6405,0x4316,0x2f00 --copyright-file="C:\openmtbmap\openmtbmap_svn\copyrightopm.txt" --license-file="C:\openmtbmap\openmtbmap_svn\licenseopm.txt" --cycle-map --ignore-fixme-values --housenumbers --road-name-config=C:\openmtbmap\openmtbmap_svn\roadNameConfig.txt --split-name-index --link-pois-to-ways --ignore-turn-restrictions --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20" --description=omtb_auo --show-profiles=1 --location-autofill=bounds,is_in,nearest --bounds=C:\openmtbmap\maps\bounds.zip --mdr7-del=pri;sec;ter;cw;min;unsf,uncl;living;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1 .;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;bridge;swing;aqueduct;viaduct;"ntnl bndry";admin_lv=4;"ntnl park";weir;dam;waterfall;rapids;stream;river;drain;ditch;"huge river";"hugest river";"medium river";"small river";"wide river";"hugest canal";"huge canal";"medium canal";"small canal";"big canal";canal;snowpark;Skitour-descent;Skipiste;Skislope;illuminated;Nordic-Skiing;skitour ;platter;ropetow;tbar;chairlift;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath --mdr7-excl=pri;sec;ter;cw;min;unsf,uncl;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1.;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx 4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;"ntnl bndry";admin_lv=4;"ntnl park";"huge river";"hugest river";"medium river";"small river";"wide river";"hugest canal";"huge canal";"medium canal";"small canal";"big canal";canal;snowpark;Skitour-descent;illuminated;Nordic-Skiing;skitour;platter;ropetow;tbar;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath --route --country-abbr=auo --country-name=australia-oceania --mapname=65340000 --family-id=6534 --product-id=1 --series-name=omtb_australia-oceania_11.06.2021 --family-name=mtb_auo_11.06.2021 --tdbfile --gmapi --overview-mapname=mapsetc --keep-going --area-name="australia-oceania_11.06.2021_omtb" -c D:\openmtbmap\maps\template.australia-oceania C:\OpenMTBMap\contourlines20\australia-oceania\7*.img typauo.TYP On Fri, 11 Jun 2021 at 12:25, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> wrote: yes I was using: --x-simplify-filter-line-errors=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,16:8,14:9 --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9 --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20" levels = 0:24, 1:22, 2:21, 3:20, 4:19, 5:18 overview-levels = 6:17, 7:16, 8:15, 9:14, 10:13 As this only affects the overview map - I guess I should change it to: --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9,17:2.6 ?? The polygon-size-limits should not matter as I have the skip-size filter set for sea. I had worked quite a long time to optimize those settings with the old behaviour. On Fri, 11 Jun 2021 at 11:50, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>> wrote: Hi Felix, Maybe you are using large values for the Douglas-Peucker filter at low resolutions? That's probably a bad idea with the new option. I always tested with the default 2.6 for all levels. The effect of the new option is that DP really can do its work. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> Gesendet: Freitag, 11. Juni 2021 10:23 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map --generate-sea --precomp-sea=C:\openmtbmap\maps\sea.zip --order-by-decreasing-area --allow-reverse-merge I thought using precomp-sea is fine (I did not update the precomp-sea in between) On Fri, 11 Jun 2021 at 11:10, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> wrote: compilation time includes splitting, and some other stuff. Loads of countries (9:34 / 9:21 (sorry dumb error 9:19) for all european single countries and a few continents (but not Europe continent) in hours. On Fri, 11 Jun 2021 at 11:08, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> wrote: I just compiled the australia-oceania map with that option, and I think I must be missing something. It got substantially worse (it is identical until the overview map kicks in) - then I get some huge squares of sea missing. Compile time for all maps until that point before Compilation time is not up a lot: 0:12 - 9:46 = 9:34 one week before (except older mapdata no changes in compilation procedure and older mkgmap) 20:17 - 5:38 = 9:19 Anything I could be missing? I use the newest low-res branch build and added --improve-overview to the compilation process. in my polygons file I have: natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=2 } [0x10f1d resolution 10] On Fri, 11 Jun 2021 at 07:12, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> wrote: Hi all, I hoped for some positive feedback on this but got none so far. Did I miss something important? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> Gesendet: Montag, 7. Juni 2021 21:05 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map Hi Felix, the map contained was without routing or index, so for a normal map the difference should be even smaller. There is no need to change sea.zip. You just have to use --improve-overview for now. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> Gesendet: Montag, 7. Juni 2021 21:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map I guess that is a time for a full Norway map based on default style - so that is quite okay. Not a sea only Norway map... Well I hope that Thorsten Kukuk can adapt his sea files in the near future then... On Mon, 7 Jun 2021 at 19:37, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>> wrote: OK, I think found a good solution. Speed is quite OK, I see 9 min 48 secs for map of norway and instead of 8 min 44 secs with r4756, and I consider Norway to be a worst case. See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4761 for the details. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>> Gesendet: Montag, 7. Juni 2021 12:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map With the provided patch the speed is very poor for areas like Norway, probably twice the time. It is much slower because it does the complex multipolygon cutting for each level in the overview map. Probably too slow for complex coastal areas. This time will be the same for precomp-sea unless we can store sea polygons for each resolution. Performance will be no problem if I find a way to use Douglas-Peucker or similar before cutting. That was my original idea but DP produces self intersecting polygons and the MultipolygonCutter cannot cope with that. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>>> Gesendet: Montag, 7. Juni 2021 11:55 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map Is it only much slower because of not using precomp sea? Or will it be much slower in general? And what is much slower for say Europe continent map? If a modern 4core/8thread processor needs 30 minutes more I would prefer the old way knowing it is worse (if the time difference is negligible with precomp-sea then that would be great). On Mon, 7 Jun 2021 at 12:26, Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>>>>> wrote: Hi Gerd This is going to take some studying to work out the implications. Can't do much for the next few days however, but will look carefully at the end of the week. Ticker On Sun, 2021-06-06 at 14:02 +0000, Gerd Petermann wrote:
Hi,
the attached patch improves the overview map, but so far only when precomp-sea is NOT used. I tested it with --generate-sea=multipolygon,floodblocker so that mkgmap really has a multipolygon with the natual=sea data.
For each level in the overview map it uses the original multipolygon data to compute the rings which will might visible at the given resolution. This requires more time compared to the current code but the result is much better and some fine tuning is possible.
To be able to use this also with --precomp-sea we need some changes in the code which generates sea.zip so that one multipolygon relation for each tile is stored.
I've uploaded the results here: https://files.mkgmap.org.uk/download/511/compare.7z What do you think?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org
I`m still using splitter 602. I did not know 604 would behave differently - I will try it out because those tiny tiles without much information in australia-oceana are not that helpful. But the problem is not directly related to the version. Those gaps have been there a long time (well and the 4 missing/empty) tiles did not happen before using --improve-overview. As this surely is somehow related - and fits in the topic of improving the overview map - great that you are looking for a solution. Well everywhere on my screenshot where you see something red - (national border - I think level2) there is some content. That australia-oceana map has some parts of data kinda anywhere... Trimming the sea on one hand is nice - because the sea/land area using --precomp-sea is a bit confusing too - as when you zoom into some areas - they will not contain data. But I think that is less of a problem then the gaps - and it should be clear an australia-oceania map does not have detailed map data of Asia... On Sat, 12 Jun 2021 at 11:03, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
I've just used splitter r604 with a freshly downloaded sea.zip and australia-oceania-latest.osm.pbf and your options and I get a completely different areas.list with only 88 tiles, but it also has gaps. They disappear when I remove the --precomp-sea option, so that's one big difference to my test environment. No idea why you get 274 tiles, and they cover a completely different area, even parts of Mexico.
I try to find out why splitter creates those gaps now...
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Samstag, 12. Juni 2021 09:34 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
highlighted = pink. maybe that confused you. I should have explained better. But in general ll those gaps should not be there.
On Sat, 12 Jun 2021 at 10:31, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com>> wrote: I use C:\openmtbmap\osmconvert.exe --drop-author --drop-version D:\openmtbmap\osmpbf_geofabrik\australia-oceania-latest.osm.pbf -o=C:\openmtbmap\osmpbf_geofabrik\australia-oceania.o5m then start /low /b /wait java -XX:+AggressiveHeap -Xms15000m -Xmx54000m -jar C:\openmtbmap\splitter.jar "--precomp-sea=C:\openmtbmap\maps\sea.zip" --max-nodes=1000000 --max-threads=8 --output=pbf "--keep-complete" --route-rel-values=mtb,bicycle,foot,hiking --max-areas=4000 --geonames-file=C:\OpenMTBMap\maps\cities5000.zip --description=australia-oceania --mapid=65340000 C:\openmtbmap\osmpbf_geofabrik\australia-oceania.o5m
The highlighted tiles selected in Mapsource for sending to GPS device - are empty using improve-overview - but they are filled with sea without using it. They are only empty in overview map. I think those gaps also should not be there - so it is a wider problem that existed before already. For overview map mkgmap should use all the sea/land area for the full coverage - and not cut out areas. Actually cutting for sea/land should also not happen in the normal map. The reason for trimming is to have to maps not overlap itself with empty content - because mkgmap/splitter only cuts rectangles - not polygons. But sea/land will be identical in two country maps - so should not be trimmed
On Sat, 12 Jun 2021 at 10:24, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com>> wrote: the problem is - using improve-overview some tiles in the overview map miss sea. I am pretty sure this happens on default style too. But likely not if you use --no-trim and / or keep-complete for splitting. Attached is the areas.list
On Sat, 12 Jun 2021 at 09:40, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix,
I don't yet understand what's going on. Please provide a link to your areas.list
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Freitag, 11. Juni 2021 12:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Nope - that did not help. And I think the problem is a bit unrelated. Mkgmap with your new version and --improve-overview assumes there is an empty map - and puts those three square areas of missing anything. Maybe you give it a try and analyse what happens.
I actually think this bug has been there before already - and it happened to me with contourlines only maps. Meaning mkgmap cuts the map area way too aggressively, and removes part of the map that actually even have content - or was it splitter. I think for contourlines only maps I had to use splitter with --keep-complete and --no-trim else there would be missing. areas in the map. (not on the outside but right in the middle in the ocean usually - but sometimes also e.g. northernmost parts of Norway in an Europe contourlines only map).
So I split australia-oceania WITHOUT --no-trim. Are you assuming to split with --no-trim? Actually those grey boxes are each of its own separate tiles (with nearly no content - e.g. one has a riff polygon only). I guess there is lots of openseamap stuff so splitter creates those tiny tiles... Mkgmap should never trip on the overview map. The normal map should be trimmed aggressively - as we still cannot cut according to a bounding polygon and only using rectangles. But the overview map sea creation should not cut out sea or anything.
I guess you never noticed that working on Norway - but it would be a good start to play around with australia-oceania (it is nice to work with - because it is relatively small in size so compiles fast). See attached screenshot of overview map. All the selected tiles were before showing sea (and do so once past the overview map too). The high DP filter was not the problem. For Australia-Oceania the --improve-overview right now is not a good example. The map was better before. Oh yeah - and --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20 looks better than small values. Actually I think even to rather increase more. Maybe that is why I had less problems right from the start - because I cut away tiny islands.
C:\openmtbmap\maps>if yes NEQ no start /low /b /wait java -jar -XX:+AggressiveHeap -XX:StringTableSize=1000003 -Xms15000M -Xmx29000M C:\openmtbmap\mkgmap.jar --max-jobs=8 --order-by-decreasing-area "--generate-sea" --code-page=1252 "--precomp-sea=C:\openmtbmap\maps\sea.zip" "--style-file=C:\openmtbmap\openmtbmap_style" --improve-overview --add-boundary-nodes-at-admin-boundaries --drive-on=detect --allow-reverse-merge --line-types-with-direction=0x18,0x1f,0x10016,0x10101,0x10105,0x10401,0x10403,0x10405,0x10408,0x10409,0x1040b,0x1040d,0x1040e,0x10500,0x10501,0x10502,0x10503,0x10504,0x10505,0x10506,0x10507,0x10607,0x10609,0x1060b,0x10702,0x10703,0x10704,0x10705,0x10706,0x10707,0x10a00,0x10a02,0x10a04,0x10a05,0x10e1e,0x10e0f,0x10e0e,0x10e1e,0x10f0a,0x10f1c,0x10e1d --nsis --index --levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18" --overview-levels="7:17, 8:16, 9:15, 10:14, 11:13, 12:12" --add-pois-to-areas --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier= entrance --x-simplify-filter-line-errors=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,17:6,14:6 --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9,17:2.6 --add-boundary-nodes-at-admin-boundaries=2 --poi-excl-index=0x6405,0x4316,0x2f00 --copyright-file="C:\openmtbmap\openmtbmap_svn\copyrightopm.txt" --license-file="C:\openmtbmap\openmtbmap_svn\licenseopm.txt" --cycle-map --ignore-fixme-values --housenumbers --road-name-config=C:\openmtbmap\openmtbmap_svn\roadNameConfig.txt --split-name-index --link-pois-to-ways --ignore-turn-restrictions --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20" --description=omtb_auo --show-profiles=1 --location-autofill=bounds,is_in,nearest --bounds=C:\openmtbmap\maps\bounds.zip --mdr7-del=pri;sec;ter;cw;min;unsf,uncl;living;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1 .;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;bridge;swing;aqueduct;viaduct;"ntnl bndry";admin_lv=4;"ntnl park";weir;dam;waterfall;rapids;stream;river;drain;ditch;"huge river";"hugest river";"medium river";"small river";"wide river";"hugest canal";"huge canal";"medium canal";"small canal";"big canal";canal;snowpark;Skitour-descent;Skipiste;Skislope;illuminated;Nordic-Skiing;skitour ;platter;ropetow;tbar;chairlift;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath --mdr7-excl=pri;sec;ter;cw;min;unsf,uncl;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1.;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx 4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;"ntnl bndry";admin_lv=4;"ntnl park";"huge river";"hugest river";"medium river";"small river";"wide river";"hugest canal";"huge canal";"medium canal";"small canal";"big canal";canal;snowpark;Skitour-descent;illuminated;Nordic-Skiing;skitour;platter;ropetow;tbar;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath --route --country-abbr=auo --country-name=australia-oceania --mapname=65340000 --family-id=6534 --product-id=1 --series-name=omtb_australia-oceania_11.06.2021 --family-name=mtb_auo_11.06.2021 --tdbfile --gmapi --overview-mapname=mapsetc --keep-going --area-name="australia-oceania_11.06.2021_omtb" -c D:\openmtbmap\maps\template.australia-oceania C:\OpenMTBMap\contourlines20\australia-oceania\7*.img typauo.TYP
On Fri, 11 Jun 2021 at 12:25, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>> wrote: yes I was using:
--x-simplify-filter-line-errors=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,16:8,14:9 --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9 --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20"
levels = 0:24, 1:22, 2:21, 3:20, 4:19, 5:18 overview-levels = 6:17, 7:16, 8:15, 9:14, 10:13
As this only affects the overview map - I guess I should change it to: --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9,17:2.6 ??
The polygon-size-limits should not matter as I have the skip-size filter set for sea.
I had worked quite a long time to optimize those settings with the old behaviour.
On Fri, 11 Jun 2021 at 11:50, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>> wrote: Hi Felix,
Maybe you are using large values for the Douglas-Peucker filter at low resolutions? That's probably a bad idea with the new option. I always tested with the default 2.6 for all levels. The effect of the new option is that DP really can do its work.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> Gesendet: Freitag, 11. Juni 2021 10:23 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
--generate-sea --precomp-sea=C:\openmtbmap\maps\sea.zip --order-by-decreasing-area --allow-reverse-merge I thought using precomp-sea is fine (I did not update the precomp-sea in between)
On Fri, 11 Jun 2021 at 11:10, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>>> wrote: compilation time includes splitting, and some other stuff. Loads of countries (9:34 / 9:21 (sorry dumb error 9:19) for all european single countries and a few continents (but not Europe continent) in hours.
On Fri, 11 Jun 2021 at 11:08, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>>> wrote: I just compiled the australia-oceania map with that option, and I think I must be missing something. It got substantially worse (it is identical until the overview map kicks in) - then I get some huge squares of sea missing. Compile time for all maps until that point before Compilation time is not up a lot: 0:12 - 9:46 = 9:34 one week before (except older mapdata no changes in compilation procedure and older mkgmap) 20:17 - 5:38 = 9:19
Anything I could be missing? I use the newest low-res branch build and added --improve-overview to the compilation process.
in my polygons file I have: natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=2 } [0x10f1d resolution 10]
On Fri, 11 Jun 2021 at 07:12, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> wrote: Hi all,
I hoped for some positive feedback on this but got none so far. Did I miss something important?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>> im Auftrag von Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> Gesendet: Montag, 7. Juni 2021 21:05 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Hi Felix,
the map contained was without routing or index, so for a normal map the difference should be even smaller. There is no need to change sea.zip. You just have to use --improve-overview for now.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> Gesendet: Montag, 7. Juni 2021 21:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
I guess that is a time for a full Norway map based on default style - so that is quite okay. Not a sea only Norway map... Well I hope that Thorsten Kukuk can adapt his sea files in the near future then...
On Mon, 7 Jun 2021 at 19:37, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>>>> wrote: OK, I think found a good solution. Speed is quite OK, I see 9 min 48 secs for map of norway and instead of 8 min 44 secs with r4756, and I consider Norway to be a worst case.
See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4761 for the details.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpeterm ann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>>>>> Gesendet: Montag, 7. Juni 2021 12:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
With the provided patch the speed is very poor for areas like Norway, probably twice the time. It is much slower because it does the complex multipolygon cutting for each level in the overview map. Probably too slow for complex coastal areas. This time will be the same for precomp-sea unless we can store sea polygons for each resolution.
Performance will be no problem if I find a way to use Douglas-Peucker or similar before cutting. That was my original idea but DP produces self intersecting polygons and the MultipolygonCutter cannot cope with that.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@g mail.com<mailto:extremecarver@gmail.com>>><mailto:extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>>>> Gesendet: Montag, 7. Juni 2021 11:55 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Is it only much slower because of not using precomp sea? Or will it be much slower in general? And what is much slower for say Europe continent map? If a modern 4core/8thread processor needs 30 minutes more I would prefer the old way knowing it is worse (if the time difference is negligible with precomp-sea then that would be great).
On Mon, 7 Jun 2021 at 12:26, Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailt o:rwb-mkgmap@jagit.co.uk>>>>>> wrote: Hi Gerd
This is going to take some studying to work out the implications. Can't do much for the next few days however, but will look carefully at the end of the week.
Ticker
On Sun, 2021-06-06 at 14:02 +0000, Gerd Petermann wrote:
Hi,
the attached patch improves the overview map, but so far only when precomp-sea is NOT used. I tested it with --generate-sea=multipolygon,floodblocker so that mkgmap really has a multipolygon with the natual=sea data.
For each level in the overview map it uses the original multipolygon data to compute the rings which will might visible at the given resolution. This requires more time compared to the current code but the result is much better and some fine tuning is possible.
To be able to use this also with --precomp-sea we need some changes in the code which generates sea.zip so that one multipolygon relation for each tile is stored.
I've uploaded the results here: https://files.mkgmap.org.uk/download/511/compare.7z What do you think?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap. org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.or g.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
Hi Felix, r602 and r604 should do the same. looking at the splitter log I see Exact map coverage read from input file(s) is (-57.16482639312744,44.65547561645508) to (26.46477699279785,179.99469995498657) Rounded map coverage is (-57.1728515625,44.6484375) to (26.4990234375,180.0) This covers parts of India and Africa, but for sure not Mexico. I assume that your australia-oceania.areas.list was not produced with a file downloaded from geofabrik, maybe you updated it with a bad tool? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Samstag, 12. Juni 2021 10:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map I`m still using splitter 602. I did not know 604 would behave differently - I will try it out because those tiny tiles without much information in australia-oceana are not that helpful. But the problem is not directly related to the version. Those gaps have been there a long time (well and the 4 missing/empty) tiles did not happen before using --improve-overview. As this surely is somehow related - and fits in the topic of improving the overview map - great that you are looking for a solution. Well everywhere on my screenshot where you see something red - (national border - I think level2) there is some content. That australia-oceana map has some parts of data kinda anywhere... Trimming the sea on one hand is nice - because the sea/land area using --precomp-sea is a bit confusing too - as when you zoom into some areas - they will not contain data. But I think that is less of a problem then the gaps - and it should be clear an australia-oceania map does not have detailed map data of Asia... On Sat, 12 Jun 2021 at 11:03, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix, I've just used splitter r604 with a freshly downloaded sea.zip and australia-oceania-latest.osm.pbf and your options and I get a completely different areas.list with only 88 tiles, but it also has gaps. They disappear when I remove the --precomp-sea option, so that's one big difference to my test environment. No idea why you get 274 tiles, and they cover a completely different area, even parts of Mexico. I try to find out why splitter creates those gaps now... Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Samstag, 12. Juni 2021 09:34 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map highlighted = pink. maybe that confused you. I should have explained better. But in general ll those gaps should not be there. On Sat, 12 Jun 2021 at 10:31, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> wrote: I use C:\openmtbmap\osmconvert.exe --drop-author --drop-version D:\openmtbmap\osmpbf_geofabrik\australia-oceania-latest.osm.pbf -o=C:\openmtbmap\osmpbf_geofabrik\australia-oceania.o5m then start /low /b /wait java -XX:+AggressiveHeap -Xms15000m -Xmx54000m -jar C:\openmtbmap\splitter.jar "--precomp-sea=C:\openmtbmap\maps\sea.zip" --max-nodes=1000000 --max-threads=8 --output=pbf "--keep-complete" --route-rel-values=mtb,bicycle,foot,hiking --max-areas=4000 --geonames-file=C:\OpenMTBMap\maps\cities5000.zip --description=australia-oceania --mapid=65340000 C:\openmtbmap\osmpbf_geofabrik\australia-oceania.o5m The highlighted tiles selected in Mapsource for sending to GPS device - are empty using improve-overview - but they are filled with sea without using it. They are only empty in overview map. I think those gaps also should not be there - so it is a wider problem that existed before already. For overview map mkgmap should use all the sea/land area for the full coverage - and not cut out areas. Actually cutting for sea/land should also not happen in the normal map. The reason for trimming is to have to maps not overlap itself with empty content - because mkgmap/splitter only cuts rectangles - not polygons. But sea/land will be identical in two country maps - so should not be trimmed On Sat, 12 Jun 2021 at 10:24, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> wrote: the problem is - using improve-overview some tiles in the overview map miss sea. I am pretty sure this happens on default style too. But likely not if you use --no-trim and / or keep-complete for splitting. Attached is the areas.list On Sat, 12 Jun 2021 at 09:40, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>> wrote: Hi Felix, I don't yet understand what's going on. Please provide a link to your areas.list Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> Gesendet: Freitag, 11. Juni 2021 12:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map Nope - that did not help. And I think the problem is a bit unrelated. Mkgmap with your new version and --improve-overview assumes there is an empty map - and puts those three square areas of missing anything. Maybe you give it a try and analyse what happens. I actually think this bug has been there before already - and it happened to me with contourlines only maps. Meaning mkgmap cuts the map area way too aggressively, and removes part of the map that actually even have content - or was it splitter. I think for contourlines only maps I had to use splitter with --keep-complete and --no-trim else there would be missing. areas in the map. (not on the outside but right in the middle in the ocean usually - but sometimes also e.g. northernmost parts of Norway in an Europe contourlines only map). So I split australia-oceania WITHOUT --no-trim. Are you assuming to split with --no-trim? Actually those grey boxes are each of its own separate tiles (with nearly no content - e.g. one has a riff polygon only). I guess there is lots of openseamap stuff so splitter creates those tiny tiles... Mkgmap should never trip on the overview map. The normal map should be trimmed aggressively - as we still cannot cut according to a bounding polygon and only using rectangles. But the overview map sea creation should not cut out sea or anything. I guess you never noticed that working on Norway - but it would be a good start to play around with australia-oceania (it is nice to work with - because it is relatively small in size so compiles fast). See attached screenshot of overview map. All the selected tiles were before showing sea (and do so once past the overview map too). The high DP filter was not the problem. For Australia-Oceania the --improve-overview right now is not a good example. The map was better before. Oh yeah - and --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20 looks better than small values. Actually I think even to rather increase more. Maybe that is why I had less problems right from the start - because I cut away tiny islands. C:\openmtbmap\maps>if yes NEQ no start /low /b /wait java -jar -XX:+AggressiveHeap -XX:StringTableSize=1000003 -Xms15000M -Xmx29000M C:\openmtbmap\mkgmap.jar --max-jobs=8 --order-by-decreasing-area "--generate-sea" --code-page=1252 "--precomp-sea=C:\openmtbmap\maps\sea.zip" "--style-file=C:\openmtbmap\openmtbmap_style" --improve-overview --add-boundary-nodes-at-admin-boundaries --drive-on=detect --allow-reverse-merge --line-types-with-direction=0x18,0x1f,0x10016,0x10101,0x10105,0x10401,0x10403,0x10405,0x10408,0x10409,0x1040b,0x1040d,0x1040e,0x10500,0x10501,0x10502,0x10503,0x10504,0x10505,0x10506,0x10507,0x10607,0x10609,0x1060b,0x10702,0x10703,0x10704,0x10705,0x10706,0x10707,0x10a00,0x10a02,0x10a04,0x10a05,0x10e1e,0x10e0f,0x10e0e,0x10e1e,0x10f0a,0x10f1c,0x10e1d --nsis --index --levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18" --overview-levels="7:17, 8:16, 9:15, 10:14, 11:13, 12:12" --add-pois-to-areas --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier= entrance --x-simplify-filter-line-errors=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,17:6,14:6 --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9,17:2.6 --add-boundary-nodes-at-admin-boundaries=2 --poi-excl-index=0x6405,0x4316,0x2f00 --copyright-file="C:\openmtbmap\openmtbmap_svn\copyrightopm.txt" --license-file="C:\openmtbmap\openmtbmap_svn\licenseopm.txt" --cycle-map --ignore-fixme-values --housenumbers --road-name-config=C:\openmtbmap\openmtbmap_svn\roadNameConfig.txt --split-name-index --link-pois-to-ways --ignore-turn-restrictions --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20" --description=omtb_auo --show-profiles=1 --location-autofill=bounds,is_in,nearest --bounds=C:\openmtbmap\maps\bounds.zip --mdr7-del=pri;sec;ter;cw;min;unsf,uncl;living;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1 .;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;bridge;swing;aqueduct;viaduct;"ntnl bndry";admin_lv=4;"ntnl park";weir;dam;waterfall;rapids;stream;river;drain;ditch;"huge river";"hugest river";"medium river";"small river";"wide river";"hugest canal";"huge canal";"medium canal";"small canal";"big canal";canal;snowpark;Skitour-descent;Skipiste;Skislope;illuminated;Nordic-Skiing;skitour ;platter;ropetow;tbar;chairlift;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath --mdr7-excl=pri;sec;ter;cw;min;unsf,uncl;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1.;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx 4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;"ntnl bndry";admin_lv=4;"ntnl park";"huge river";"hugest river";"medium river";"small river";"wide river";"hugest canal";"huge canal";"medium canal";"small canal";"big canal";canal;snowpark;Skitour-descent;illuminated;Nordic-Skiing;skitour;platter;ropetow;tbar;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath --route --country-abbr=auo --country-name=australia-oceania --mapname=65340000 --family-id=6534 --product-id=1 --series-name=omtb_australia-oceania_11.06.2021 --family-name=mtb_auo_11.06.2021 --tdbfile --gmapi --overview-mapname=mapsetc --keep-going --area-name="australia-oceania_11.06.2021_omtb" -c D:\openmtbmap\maps\template.australia-oceania C:\OpenMTBMap\contourlines20\australia-oceania\7*.img typauo.TYP On Fri, 11 Jun 2021 at 12:25, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> wrote: yes I was using: --x-simplify-filter-line-errors=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,16:8,14:9 --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9 --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20" levels = 0:24, 1:22, 2:21, 3:20, 4:19, 5:18 overview-levels = 6:17, 7:16, 8:15, 9:14, 10:13 As this only affects the overview map - I guess I should change it to: --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9,17:2.6 ?? The polygon-size-limits should not matter as I have the skip-size filter set for sea. I had worked quite a long time to optimize those settings with the old behaviour. On Fri, 11 Jun 2021 at 11:50, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> wrote: Hi Felix, Maybe you are using large values for the Douglas-Peucker filter at low resolutions? That's probably a bad idea with the new option. I always tested with the default 2.6 for all levels. The effect of the new option is that DP really can do its work. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> Gesendet: Freitag, 11. Juni 2021 10:23 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map --generate-sea --precomp-sea=C:\openmtbmap\maps\sea.zip --order-by-decreasing-area --allow-reverse-merge I thought using precomp-sea is fine (I did not update the precomp-sea in between) On Fri, 11 Jun 2021 at 11:10, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>>> wrote: compilation time includes splitting, and some other stuff. Loads of countries (9:34 / 9:21 (sorry dumb error 9:19) for all european single countries and a few continents (but not Europe continent) in hours. On Fri, 11 Jun 2021 at 11:08, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>>> wrote: I just compiled the australia-oceania map with that option, and I think I must be missing something. It got substantially worse (it is identical until the overview map kicks in) - then I get some huge squares of sea missing. Compile time for all maps until that point before Compilation time is not up a lot: 0:12 - 9:46 = 9:34 one week before (except older mapdata no changes in compilation procedure and older mkgmap) 20:17 - 5:38 = 9:19 Anything I could be missing? I use the newest low-res branch build and added --improve-overview to the compilation process. in my polygons file I have: natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=2 } [0x10f1d resolution 10] On Fri, 11 Jun 2021 at 07:12, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>> wrote: Hi all, I hoped for some positive feedback on this but got none so far. Did I miss something important? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>> Gesendet: Montag, 7. Juni 2021 21:05 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map Hi Felix, the map contained was without routing or index, so for a normal map the difference should be even smaller. There is no need to change sea.zip. You just have to use --improve-overview for now. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>>> Gesendet: Montag, 7. Juni 2021 21:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map I guess that is a time for a full Norway map based on default style - so that is quite okay. Not a sea only Norway map... Well I hope that Thorsten Kukuk can adapt his sea files in the near future then... On Mon, 7 Jun 2021 at 19:37, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>>> wrote: OK, I think found a good solution. Speed is quite OK, I see 9 min 48 secs for map of norway and instead of 8 min 44 secs with r4756, and I consider Norway to be a worst case. See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4761 for the details. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpeterm<mailto:gpeterm> ann_muenchen@hotmail.com<mailto:ann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>>> Gesendet: Montag, 7. Juni 2021 12:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map With the provided patch the speed is very poor for areas like Norway, probably twice the time. It is much slower because it does the complex multipolygon cutting for each level in the overview map. Probably too slow for complex coastal areas. This time will be the same for precomp-sea unless we can store sea polygons for each resolution. Performance will be no problem if I find a way to use Douglas-Peucker or similar before cutting. That was my original idea but DP produces self intersecting polygons and the MultipolygonCutter cannot cope with that. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@g<mailto:extremecarver@g> mail.com<http://mail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>>>> Gesendet: Montag, 7. Juni 2021 11:55 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map Is it only much slower because of not using precomp sea? Or will it be much slower in general? And what is much slower for say Europe continent map? If a modern 4core/8thread processor needs 30 minutes more I would prefer the old way knowing it is worse (if the time difference is negligible with precomp-sea then that would be great). On Mon, 7 Jun 2021 at 12:26, Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>>>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailt o:rwb-mkgmap@jagit.co.uk<mailto:o%3Arwb-mkgmap@jagit.co.uk>>>>>>> wrote: Hi Gerd This is going to take some studying to work out the implications. Can't do much for the next few days however, but will look carefully at the end of the week. Ticker On Sun, 2021-06-06 at 14:02 +0000, Gerd Petermann wrote:
Hi,
the attached patch improves the overview map, but so far only when precomp-sea is NOT used. I tested it with --generate-sea=multipolygon,floodblocker so that mkgmap really has a multipolygon with the natual=sea data.
For each level in the overview map it uses the original multipolygon data to compute the rings which will might visible at the given resolution. This requires more time compared to the current code but the result is much better and some fine tuning is possible.
To be able to use this also with --precomp-sea we need some changes in the code which generates sea.zip so that one multipolygon relation for each tile is stored.
I've uploaded the results here: https://files.mkgmap.org.uk/download/511/compare.7z What do you think?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap<mailto:mkgmap-dev@lists.mkgmap>. org.uk<http://org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.or<mailto:mkgmap-dev@lists.mkgmap.or> g.uk<http://g.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org
I just updated australia-oceania from geofabrik again - old version was 09 June 2021. I have not updated osmconvert.exe a long time - but it cannot create data out of nowhere... D:\openmtbmap\osmpbf_geofabrik\australia-oceania-latest.osm.pbf C:\openmtbmap\osmconvert.exe --drop-author --drop-version D:\openmtbmap\osmpbf_geofabrik\australia-oceania-latest.osm.pbf -o=C:\openmtbmap\osmpbf_geofabrik\australia-oceania.o5m start /low /b /wait java -XX:+AggressiveHeap -Xms15000m -Xmx54000m -jar C:\openmtbmap\splitter.jar "--precomp-sea=C:\openmtbmap\maps\sea.zip" --max-nodes=1000000 --max-threads=8 --output=pbf "--keep-complete" --route-rel-values=mtb,bicycle,foot,hiking --max-areas=4000 --geonames-file=C:\OpenMTBMap\maps\cities5000.zip --description=australia-oceania --mapid=65340000 C:\openmtbmap\osmpbf_geofabrik\australia-oceania.o5m 1>NUL max-nodes value 1000000 is far above highest node count 209465 in single grid element, consider using a lower resolution And it is virtually identical... Maybe it is because I use precomp-sea also for splitter? On Sat, 12 Jun 2021 at 11:30, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
r602 and r604 should do the same. looking at the splitter log I see Exact map coverage read from input file(s) is (-57.16482639312744,44.65547561645508) to (26.46477699279785,179.99469995498657) Rounded map coverage is (-57.1728515625,44.6484375) to (26.4990234375,180.0)
This covers parts of India and Africa, but for sure not Mexico. I assume that your australia-oceania.areas.list was not produced with a file downloaded from geofabrik, maybe you updated it with a bad tool?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Samstag, 12. Juni 2021 10:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
I`m still using splitter 602. I did not know 604 would behave differently - I will try it out because those tiny tiles without much information in australia-oceana are not that helpful. But the problem is not directly related to the version. Those gaps have been there a long time (well and the 4 missing/empty) tiles did not happen before using --improve-overview. As this surely is somehow related - and fits in the topic of improving the overview map - great that you are looking for a solution.
Well everywhere on my screenshot where you see something red - (national border - I think level2) there is some content. That australia-oceana map has some parts of data kinda anywhere...
Trimming the sea on one hand is nice - because the sea/land area using --precomp-sea is a bit confusing too - as when you zoom into some areas - they will not contain data. But I think that is less of a problem then the gaps - and it should be clear an australia-oceania map does not have detailed map data of Asia...
On Sat, 12 Jun 2021 at 11:03, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix,
I've just used splitter r604 with a freshly downloaded sea.zip and australia-oceania-latest.osm.pbf and your options and I get a completely different areas.list with only 88 tiles, but it also has gaps. They disappear when I remove the --precomp-sea option, so that's one big difference to my test environment. No idea why you get 274 tiles, and they cover a completely different area, even parts of Mexico.
I try to find out why splitter creates those gaps now...
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Samstag, 12. Juni 2021 09:34 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
highlighted = pink. maybe that confused you. I should have explained better. But in general ll those gaps should not be there.
On Sat, 12 Jun 2021 at 10:31, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>> wrote: I use C:\openmtbmap\osmconvert.exe --drop-author --drop-version D:\openmtbmap\osmpbf_geofabrik\australia-oceania-latest.osm.pbf -o=C:\openmtbmap\osmpbf_geofabrik\australia-oceania.o5m then start /low /b /wait java -XX:+AggressiveHeap -Xms15000m -Xmx54000m -jar C:\openmtbmap\splitter.jar "--precomp-sea=C:\openmtbmap\maps\sea.zip" --max-nodes=1000000 --max-threads=8 --output=pbf "--keep-complete" --route-rel-values=mtb,bicycle,foot,hiking --max-areas=4000 --geonames-file=C:\OpenMTBMap\maps\cities5000.zip --description=australia-oceania --mapid=65340000 C:\openmtbmap\osmpbf_geofabrik\australia-oceania.o5m
The highlighted tiles selected in Mapsource for sending to GPS device - are empty using improve-overview - but they are filled with sea without using it. They are only empty in overview map. I think those gaps also should not be there - so it is a wider problem that existed before already. For overview map mkgmap should use all the sea/land area for the full coverage - and not cut out areas. Actually cutting for sea/land should also not happen in the normal map. The reason for trimming is to have to maps not overlap itself with empty content - because mkgmap/splitter only cuts rectangles - not polygons. But sea/land will be identical in two country maps - so should not be trimmed
On Sat, 12 Jun 2021 at 10:24, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>> wrote: the problem is - using improve-overview some tiles in the overview map miss sea. I am pretty sure this happens on default style too. But likely not if you use --no-trim and / or keep-complete for splitting. Attached is the areas.list
On Sat, 12 Jun 2021 at 09:40, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>> wrote: Hi Felix,
I don't yet understand what's going on. Please provide a link to your areas.list
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> Gesendet: Freitag, 11. Juni 2021 12:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Nope - that did not help. And I think the problem is a bit unrelated. Mkgmap with your new version and --improve-overview assumes there is an empty map - and puts those three square areas of missing anything. Maybe you give it a try and analyse what happens.
I actually think this bug has been there before already - and it happened to me with contourlines only maps. Meaning mkgmap cuts the map area way too aggressively, and removes part of the map that actually even have content - or was it splitter. I think for contourlines only maps I had to use splitter with --keep-complete and --no-trim else there would be missing. areas in the map. (not on the outside but right in the middle in the ocean usually - but sometimes also e.g. northernmost parts of Norway in an Europe contourlines only map).
So I split australia-oceania WITHOUT --no-trim. Are you assuming to split with --no-trim? Actually those grey boxes are each of its own separate tiles (with nearly no content - e.g. one has a riff polygon only). I guess there is lots of openseamap stuff so splitter creates those tiny tiles... Mkgmap should never trip on the overview map. The normal map should be trimmed aggressively - as we still cannot cut according to a bounding polygon and only using rectangles. But the overview map sea creation should not cut out sea or anything.
I guess you never noticed that working on Norway - but it would be a good start to play around with australia-oceania (it is nice to work with - because it is relatively small in size so compiles fast). See attached screenshot of overview map. All the selected tiles were before showing sea (and do so once past the overview map too). The high DP filter was not the problem. For Australia-Oceania the --improve-overview right now is not a good example. The map was better before. Oh yeah - and --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20 looks better than small values. Actually I think even to rather increase more. Maybe that is why I had less problems right from the start - because I cut away tiny islands.
C:\openmtbmap\maps>if yes NEQ no start /low /b /wait java -jar -XX:+AggressiveHeap -XX:StringTableSize=1000003 -Xms15000M -Xmx29000M C:\openmtbmap\mkgmap.jar --max-jobs=8 --order-by-decreasing-area "--generate-sea" --code-page=1252 "--precomp-sea=C:\openmtbmap\maps\sea.zip" "--style-file=C:\openmtbmap\openmtbmap_style" --improve-overview --add-boundary-nodes-at-admin-boundaries --drive-on=detect --allow-reverse-merge --line-types-with-direction=0x18,0x1f,0x10016,0x10101,0x10105,0x10401,0x10403,0x10405,0x10408,0x10409,0x1040b,0x1040d,0x1040e,0x10500,0x10501,0x10502,0x10503,0x10504,0x10505,0x10506,0x10507,0x10607,0x10609,0x1060b,0x10702,0x10703,0x10704,0x10705,0x10706,0x10707,0x10a00,0x10a02,0x10a04,0x10a05,0x10e1e,0x10e0f,0x10e0e,0x10e1e,0x10f0a,0x10f1c,0x10e1d --nsis --index --levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18" --overview-levels="7:17, 8:16, 9:15, 10:14, 11:13, 12:12" --add-pois-to-areas --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier= entrance --x-simplify-filter-line-errors=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,17:6,14:6 --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9,17:2.6 --add-boundary-nodes-at-admin-boundaries=2 --poi-excl-index=0x6405,0x4316,0x2f00 --copyright-file="C:\openmtbmap\openmtbmap_svn\copyrightopm.txt" --license-file="C:\openmtbmap\openmtbmap_svn\licenseopm.txt" --cycle-map --ignore-fixme-values --housenumbers --road-name-config=C:\openmtbmap\openmtbmap_svn\roadNameConfig.txt --split-name-index --link-pois-to-ways --ignore-turn-restrictions --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20" --description=omtb_auo --show-profiles=1 --location-autofill=bounds,is_in,nearest --bounds=C:\openmtbmap\maps\bounds.zip --mdr7-del=pri;sec;ter;cw;min;unsf,uncl;living;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1 .;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;bridge;swing;aqueduct;viaduct;"ntnl bndry";admin_lv=4;"ntnl park";weir;dam;waterfall;rapids;stream;river;drain;ditch;"huge river";"hugest river";"medium river";"small river";"wide river";"hugest canal";"huge canal";"medium canal";"small canal";"big canal";canal;snowpark;Skitour-descent;Skipiste;Skislope;illuminated;Nordic-Skiing;skitour ;platter;ropetow;tbar;chairlift;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath --mdr7-excl=pri;sec;ter;cw;min;unsf,uncl;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1.;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx 4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;"ntnl bndry";admin_lv=4;"ntnl park";"huge river";"hugest river";"medium river";"small river";"wide river";"hugest canal";"huge canal";"medium canal";"small canal";"big canal";canal;snowpark;Skitour-descent;illuminated;Nordic-Skiing;skitour;platter;ropetow;tbar;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath --route --country-abbr=auo --country-name=australia-oceania --mapname=65340000 --family-id=6534 --product-id=1 --series-name=omtb_australia-oceania_11.06.2021 --family-name=mtb_auo_11.06.2021 --tdbfile --gmapi --overview-mapname=mapsetc --keep-going --area-name="australia-oceania_11.06.2021_omtb" -c D:\openmtbmap\maps\template.australia-oceania C:\OpenMTBMap\contourlines20\australia-oceania\7*.img typauo.TYP
On Fri, 11 Jun 2021 at 12:25, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>>> wrote: yes I was using:
--x-simplify-filter-line-errors=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,16:8,14:9 --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9 --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20"
levels = 0:24, 1:22, 2:21, 3:20, 4:19, 5:18 overview-levels = 6:17, 7:16, 8:15, 9:14, 10:13
As this only affects the overview map - I guess I should change it to: --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9,17:2.6 ??
The polygon-size-limits should not matter as I have the skip-size filter set for sea.
I had worked quite a long time to optimize those settings with the old behaviour.
On Fri, 11 Jun 2021 at 11:50, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> wrote: Hi Felix,
Maybe you are using large values for the Douglas-Peucker filter at low resolutions? That's probably a bad idea with the new option. I always tested with the default 2.6 for all levels. The effect of the new option is that DP really can do its work.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> Gesendet: Freitag, 11. Juni 2021 10:23 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
--generate-sea --precomp-sea=C:\openmtbmap\maps\sea.zip --order-by-decreasing-area --allow-reverse-merge I thought using precomp-sea is fine (I did not update the precomp-sea in between)
On Fri, 11 Jun 2021 at 11:10, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>>>> wrote: compilation time includes splitting, and some other stuff. Loads of countries (9:34 / 9:21 (sorry dumb error 9:19) for all european single countries and a few continents (but not Europe continent) in hours.
On Fri, 11 Jun 2021 at 11:08, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>>>> wrote: I just compiled the australia-oceania map with that option, and I think I must be missing something. It got substantially worse (it is identical until the overview map kicks in) - then I get some huge squares of sea missing. Compile time for all maps until that point before Compilation time is not up a lot: 0:12 - 9:46 = 9:34 one week before (except older mapdata no changes in compilation procedure and older mkgmap) 20:17 - 5:38 = 9:19
Anything I could be missing? I use the newest low-res branch build and added --improve-overview to the compilation process.
in my polygons file I have: natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=2 } [0x10f1d resolution 10]
On Fri, 11 Jun 2021 at 07:12, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>>>> wrote: Hi all,
I hoped for some positive feedback on this but got none so far. Did I miss something important?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpeterm ann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>>>>> Gesendet: Montag, 7. Juni 2021 21:05 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Hi Felix,
the map contained was without routing or index, so for a normal map the difference should be even smaller. There is no need to change sea.zip. You just have to use --improve-overview for now.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@g mail.com<mailto:extremecarver@gmail.com>>><mailto:extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>>>> Gesendet: Montag, 7. Juni 2021 21:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
I guess that is a time for a full Norway map based on default style - so that is quite okay. Not a sea only Norway map... Well I hope that Thorsten Kukuk can adapt his sea files in the near future then...
On Mon, 7 Jun 2021 at 19:37, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>>><ma ilto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>>>>> wrote: OK, I think found a good solution. Speed is quite OK, I see 9 min 48 secs for map of norway and instead of 8 min 44 secs with r4756, and I consider Norway to be a worst case.
See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4761 for the details.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mail to:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto:gpeterm<mailto:gpeterm> ann_muenchen@hotmail.com<mailto:ann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
> Gesendet: Montag, 7. Juni 2021 12:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
With the provided patch the speed is very poor for areas like Norway, probably twice the time. It is much slower because it does the complex multipolygon cutting for each level in the overview map. Probably too slow for complex coastal areas. This time will be the same for precomp-sea unless we can store sea polygons for each resolution.
Performance will be no problem if I find a way to use Douglas-Peucker or similar before cutting. That was my original idea but DP produces self intersecting polygons and the MultipolygonCutter cannot cope with that.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mail to:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>>><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto: extremecarver@g<mailto:extremecarver@g> mail.com<http://mail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>>>>> Gesendet: Montag, 7. Juni 2021 11:55 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Is it only much slower because of not using precomp sea? Or will it be much slower in general? And what is much slower for say Europe continent map? If a modern 4core/8thread processor needs 30 minutes more I would prefer the old way knowing it is worse (if the time difference is negligible with precomp-sea then that would be great).
On Mon, 7 Jun 2021 at 12:26, Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailt o:rwb-mkgmap@jagit.co.uk>>>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailt o:rwb-mkgmap@jagit.co.uk<mailto:o%3Arwb-mkgmap@jagit.co.uk>>>>>>> wrote: Hi Gerd
This is going to take some studying to work out the implications. Can't do much for the next few days however, but will look carefully at the end of the week.
Ticker
On Sun, 2021-06-06 at 14:02 +0000, Gerd Petermann wrote:
Hi,
the attached patch improves the overview map, but so far only when precomp-sea is NOT used. I tested it with --generate-sea=multipolygon,floodblocker so that mkgmap really has a multipolygon with the natual=sea data.
For each level in the overview map it uses the original multipolygon data to compute the rings which will might visible at the given resolution. This requires more time compared to the current code but the result is much better and some fine tuning is possible.
To be able to use this also with --precomp-sea we need some changes in the code which generates sea.zip so that one multipolygon relation for each tile is stored.
I've uploaded the results here: https://files.mkgmap.org.uk/download/511/compare.7z What do you think?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap. org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap<mailto:mkgmap-dev@list s.mkgmap>. org.uk<http://org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.or g.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.or<mailto:mkgmap-dev@lis ts.mkgmap.or> g.uk<http://g.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.or g.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.or g.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
Hi Felix, I don't remember exactly why the --precom-sea option was added to splitter, but I think it makes no sense to use that option in combination with trimming. What's your reason to use this combination? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Samstag, 12. Juni 2021 10:30 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map Hi Felix, r602 and r604 should do the same. looking at the splitter log I see Exact map coverage read from input file(s) is (-57.16482639312744,44.65547561645508) to (26.46477699279785,179.99469995498657) Rounded map coverage is (-57.1728515625,44.6484375) to (26.4990234375,180.0) This covers parts of India and Africa, but for sure not Mexico. I assume that your australia-oceania.areas.list was not produced with a file downloaded from geofabrik, maybe you updated it with a bad tool? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Samstag, 12. Juni 2021 10:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map I`m still using splitter 602. I did not know 604 would behave differently - I will try it out because those tiny tiles without much information in australia-oceana are not that helpful. But the problem is not directly related to the version. Those gaps have been there a long time (well and the 4 missing/empty) tiles did not happen before using --improve-overview. As this surely is somehow related - and fits in the topic of improving the overview map - great that you are looking for a solution. Well everywhere on my screenshot where you see something red - (national border - I think level2) there is some content. That australia-oceana map has some parts of data kinda anywhere... Trimming the sea on one hand is nice - because the sea/land area using --precomp-sea is a bit confusing too - as when you zoom into some areas - they will not contain data. But I think that is less of a problem then the gaps - and it should be clear an australia-oceania map does not have detailed map data of Asia... On Sat, 12 Jun 2021 at 11:03, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix, I've just used splitter r604 with a freshly downloaded sea.zip and australia-oceania-latest.osm.pbf and your options and I get a completely different areas.list with only 88 tiles, but it also has gaps. They disappear when I remove the --precomp-sea option, so that's one big difference to my test environment. No idea why you get 274 tiles, and they cover a completely different area, even parts of Mexico. I try to find out why splitter creates those gaps now... Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Samstag, 12. Juni 2021 09:34 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map highlighted = pink. maybe that confused you. I should have explained better. But in general ll those gaps should not be there. On Sat, 12 Jun 2021 at 10:31, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> wrote: I use C:\openmtbmap\osmconvert.exe --drop-author --drop-version D:\openmtbmap\osmpbf_geofabrik\australia-oceania-latest.osm.pbf -o=C:\openmtbmap\osmpbf_geofabrik\australia-oceania.o5m then start /low /b /wait java -XX:+AggressiveHeap -Xms15000m -Xmx54000m -jar C:\openmtbmap\splitter.jar "--precomp-sea=C:\openmtbmap\maps\sea.zip" --max-nodes=1000000 --max-threads=8 --output=pbf "--keep-complete" --route-rel-values=mtb,bicycle,foot,hiking --max-areas=4000 --geonames-file=C:\OpenMTBMap\maps\cities5000.zip --description=australia-oceania --mapid=65340000 C:\openmtbmap\osmpbf_geofabrik\australia-oceania.o5m The highlighted tiles selected in Mapsource for sending to GPS device - are empty using improve-overview - but they are filled with sea without using it. They are only empty in overview map. I think those gaps also should not be there - so it is a wider problem that existed before already. For overview map mkgmap should use all the sea/land area for the full coverage - and not cut out areas. Actually cutting for sea/land should also not happen in the normal map. The reason for trimming is to have to maps not overlap itself with empty content - because mkgmap/splitter only cuts rectangles - not polygons. But sea/land will be identical in two country maps - so should not be trimmed On Sat, 12 Jun 2021 at 10:24, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> wrote: the problem is - using improve-overview some tiles in the overview map miss sea. I am pretty sure this happens on default style too. But likely not if you use --no-trim and / or keep-complete for splitting. Attached is the areas.list On Sat, 12 Jun 2021 at 09:40, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>> wrote: Hi Felix, I don't yet understand what's going on. Please provide a link to your areas.list Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> Gesendet: Freitag, 11. Juni 2021 12:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map Nope - that did not help. And I think the problem is a bit unrelated. Mkgmap with your new version and --improve-overview assumes there is an empty map - and puts those three square areas of missing anything. Maybe you give it a try and analyse what happens. I actually think this bug has been there before already - and it happened to me with contourlines only maps. Meaning mkgmap cuts the map area way too aggressively, and removes part of the map that actually even have content - or was it splitter. I think for contourlines only maps I had to use splitter with --keep-complete and --no-trim else there would be missing. areas in the map. (not on the outside but right in the middle in the ocean usually - but sometimes also e.g. northernmost parts of Norway in an Europe contourlines only map). So I split australia-oceania WITHOUT --no-trim. Are you assuming to split with --no-trim? Actually those grey boxes are each of its own separate tiles (with nearly no content - e.g. one has a riff polygon only). I guess there is lots of openseamap stuff so splitter creates those tiny tiles... Mkgmap should never trip on the overview map. The normal map should be trimmed aggressively - as we still cannot cut according to a bounding polygon and only using rectangles. But the overview map sea creation should not cut out sea or anything. I guess you never noticed that working on Norway - but it would be a good start to play around with australia-oceania (it is nice to work with - because it is relatively small in size so compiles fast). See attached screenshot of overview map. All the selected tiles were before showing sea (and do so once past the overview map too). The high DP filter was not the problem. For Australia-Oceania the --improve-overview right now is not a good example. The map was better before. Oh yeah - and --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20 looks better than small values. Actually I think even to rather increase more. Maybe that is why I had less problems right from the start - because I cut away tiny islands. C:\openmtbmap\maps>if yes NEQ no start /low /b /wait java -jar -XX:+AggressiveHeap -XX:StringTableSize=1000003 -Xms15000M -Xmx29000M C:\openmtbmap\mkgmap.jar --max-jobs=8 --order-by-decreasing-area "--generate-sea" --code-page=1252 "--precomp-sea=C:\openmtbmap\maps\sea.zip" "--style-file=C:\openmtbmap\openmtbmap_style" --improve-overview --add-boundary-nodes-at-admin-boundaries --drive-on=detect --allow-reverse-merge --line-types-with-direction=0x18,0x1f,0x10016,0x10101,0x10105,0x10401,0x10403,0x10405,0x10408,0x10409,0x1040b,0x1040d,0x1040e,0x10500,0x10501,0x10502,0x10503,0x10504,0x10505,0x10506,0x10507,0x10607,0x10609,0x1060b,0x10702,0x10703,0x10704,0x10705,0x10706,0x10707,0x10a00,0x10a02,0x10a04,0x10a05,0x10e1e,0x10e0f,0x10e0e,0x10e1e,0x10f0a,0x10f1c,0x10e1d --nsis --index --levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18" --overview-levels="7:17, 8:16, 9:15, 10:14, 11:13, 12:12" --add-pois-to-areas --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier= entrance --x-simplify-filter-line-errors=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,17:6,14:6 --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9,17:2.6 --add-boundary-nodes-at-admin-boundaries=2 --poi-excl-index=0x6405,0x4316,0x2f00 --copyright-file="C:\openmtbmap\openmtbmap_svn\copyrightopm.txt" --license-file="C:\openmtbmap\openmtbmap_svn\licenseopm.txt" --cycle-map --ignore-fixme-values --housenumbers --road-name-config=C:\openmtbmap\openmtbmap_svn\roadNameConfig.txt --split-name-index --link-pois-to-ways --ignore-turn-restrictions --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20" --description=omtb_auo --show-profiles=1 --location-autofill=bounds,is_in,nearest --bounds=C:\openmtbmap\maps\bounds.zip --mdr7-del=pri;sec;ter;cw;min;unsf,uncl;living;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1 .;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;bridge;swing;aqueduct;viaduct;"ntnl bndry";admin_lv=4;"ntnl park";weir;dam;waterfall;rapids;stream;river;drain;ditch;"huge river";"hugest river";"medium river";"small river";"wide river";"hugest canal";"huge canal";"medium canal";"small canal";"big canal";canal;snowpark;Skitour-descent;Skipiste;Skislope;illuminated;Nordic-Skiing;skitour ;platter;ropetow;tbar;chairlift;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath --mdr7-excl=pri;sec;ter;cw;min;unsf,uncl;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1.;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx 4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;"ntnl bndry";admin_lv=4;"ntnl park";"huge river";"hugest river";"medium river";"small river";"wide river";"hugest canal";"huge canal";"medium canal";"small canal";"big canal";canal;snowpark;Skitour-descent;illuminated;Nordic-Skiing;skitour;platter;ropetow;tbar;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath --route --country-abbr=auo --country-name=australia-oceania --mapname=65340000 --family-id=6534 --product-id=1 --series-name=omtb_australia-oceania_11.06.2021 --family-name=mtb_auo_11.06.2021 --tdbfile --gmapi --overview-mapname=mapsetc --keep-going --area-name="australia-oceania_11.06.2021_omtb" -c D:\openmtbmap\maps\template.australia-oceania C:\OpenMTBMap\contourlines20\australia-oceania\7*.img typauo.TYP On Fri, 11 Jun 2021 at 12:25, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> wrote: yes I was using: --x-simplify-filter-line-errors=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,16:8,14:9 --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9 --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20" levels = 0:24, 1:22, 2:21, 3:20, 4:19, 5:18 overview-levels = 6:17, 7:16, 8:15, 9:14, 10:13 As this only affects the overview map - I guess I should change it to: --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9,17:2.6 ?? The polygon-size-limits should not matter as I have the skip-size filter set for sea. I had worked quite a long time to optimize those settings with the old behaviour. On Fri, 11 Jun 2021 at 11:50, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> wrote: Hi Felix, Maybe you are using large values for the Douglas-Peucker filter at low resolutions? That's probably a bad idea with the new option. I always tested with the default 2.6 for all levels. The effect of the new option is that DP really can do its work. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> Gesendet: Freitag, 11. Juni 2021 10:23 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map --generate-sea --precomp-sea=C:\openmtbmap\maps\sea.zip --order-by-decreasing-area --allow-reverse-merge I thought using precomp-sea is fine (I did not update the precomp-sea in between) On Fri, 11 Jun 2021 at 11:10, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>>> wrote: compilation time includes splitting, and some other stuff. Loads of countries (9:34 / 9:21 (sorry dumb error 9:19) for all european single countries and a few continents (but not Europe continent) in hours. On Fri, 11 Jun 2021 at 11:08, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>>> wrote: I just compiled the australia-oceania map with that option, and I think I must be missing something. It got substantially worse (it is identical until the overview map kicks in) - then I get some huge squares of sea missing. Compile time for all maps until that point before Compilation time is not up a lot: 0:12 - 9:46 = 9:34 one week before (except older mapdata no changes in compilation procedure and older mkgmap) 20:17 - 5:38 = 9:19 Anything I could be missing? I use the newest low-res branch build and added --improve-overview to the compilation process. in my polygons file I have: natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=2 } [0x10f1d resolution 10] On Fri, 11 Jun 2021 at 07:12, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>> wrote: Hi all, I hoped for some positive feedback on this but got none so far. Did I miss something important? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpeterm ann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>> Gesendet: Montag, 7. Juni 2021 21:05 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map Hi Felix, the map contained was without routing or index, so for a normal map the difference should be even smaller. There is no need to change sea.zip. You just have to use --improve-overview for now. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@g mail.com<mailto:extremecarver@gmail.com>>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>>> Gesendet: Montag, 7. Juni 2021 21:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map I guess that is a time for a full Norway map based on default style - so that is quite okay. Not a sea only Norway map... Well I hope that Thorsten Kukuk can adapt his sea files in the near future then... On Mon, 7 Jun 2021 at 19:37, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><ma ilto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>>> wrote: OK, I think found a good solution. Speed is quite OK, I see 9 min 48 secs for map of norway and instead of 8 min 44 secs with r4756, and I consider Norway to be a worst case. See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4761 for the details. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mail to:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpeterm<mailto:gpeterm> ann_muenchen@hotmail.com<mailto:ann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>>> Gesendet: Montag, 7. Juni 2021 12:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map With the provided patch the speed is very poor for areas like Norway, probably twice the time. It is much slower because it does the complex multipolygon cutting for each level in the overview map. Probably too slow for complex coastal areas. This time will be the same for precomp-sea unless we can store sea polygons for each resolution. Performance will be no problem if I find a way to use Douglas-Peucker or similar before cutting. That was my original idea but DP produces self intersecting polygons and the MultipolygonCutter cannot cope with that. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mail to:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@g<mailto:extremecarver@g> mail.com<http://mail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>>>> Gesendet: Montag, 7. Juni 2021 11:55 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map Is it only much slower because of not using precomp sea? Or will it be much slower in general? And what is much slower for say Europe continent map? If a modern 4core/8thread processor needs 30 minutes more I would prefer the old way knowing it is worse (if the time difference is negligible with precomp-sea then that would be great). On Mon, 7 Jun 2021 at 12:26, Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailt o:rwb-mkgmap@jagit.co.uk>>>>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailt o:rwb-mkgmap@jagit.co.uk<mailto:o%3Arwb-mkgmap@jagit.co.uk>>>>>>> wrote: Hi Gerd This is going to take some studying to work out the implications. Can't do much for the next few days however, but will look carefully at the end of the week. Ticker On Sun, 2021-06-06 at 14:02 +0000, Gerd Petermann wrote:
Hi,
the attached patch improves the overview map, but so far only when precomp-sea is NOT used. I tested it with --generate-sea=multipolygon,floodblocker so that mkgmap really has a multipolygon with the natual=sea data.
For each level in the overview map it uses the original multipolygon data to compute the rings which will might visible at the given resolution. This requires more time compared to the current code but the result is much better and some fine tuning is possible.
To be able to use this also with --precomp-sea we need some changes in the code which generates sea.zip so that one multipolygon relation for each tile is stored.
I've uploaded the results here: https://files.mkgmap.org.uk/download/511/compare.7z What do you think?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap. org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap<mailto:mkgmap-dev@list s.mkgmap>. org.uk<http://org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.or g.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.or<mailto:mkgmap-dev@lis ts.mkgmap.or> g.uk<http://g.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.or g.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.or g.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I also do not know anymore. I guess I should drop it. I tried googling it - but could not find anything. Well I am going to drop it now. I still get 268 tiles however - and not 88 On Sat, 12 Jun 2021 at 12:19, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
I don't remember exactly why the --precom-sea option was added to splitter, but I think it makes no sense to use that option in combination with trimming. What's your reason to use this combination?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Samstag, 12. Juni 2021 10:30 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Hi Felix,
r602 and r604 should do the same. looking at the splitter log I see Exact map coverage read from input file(s) is (-57.16482639312744,44.65547561645508) to (26.46477699279785,179.99469995498657) Rounded map coverage is (-57.1728515625,44.6484375) to (26.4990234375,180.0)
This covers parts of India and Africa, but for sure not Mexico. I assume that your australia-oceania.areas.list was not produced with a file downloaded from geofabrik, maybe you updated it with a bad tool?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Samstag, 12. Juni 2021 10:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
I`m still using splitter 602. I did not know 604 would behave differently - I will try it out because those tiny tiles without much information in australia-oceana are not that helpful. But the problem is not directly related to the version. Those gaps have been there a long time (well and the 4 missing/empty) tiles did not happen before using --improve-overview. As this surely is somehow related - and fits in the topic of improving the overview map - great that you are looking for a solution.
Well everywhere on my screenshot where you see something red - (national border - I think level2) there is some content. That australia-oceana map has some parts of data kinda anywhere...
Trimming the sea on one hand is nice - because the sea/land area using --precomp-sea is a bit confusing too - as when you zoom into some areas - they will not contain data. But I think that is less of a problem then the gaps - and it should be clear an australia-oceania map does not have detailed map data of Asia...
On Sat, 12 Jun 2021 at 11:03, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix,
I've just used splitter r604 with a freshly downloaded sea.zip and australia-oceania-latest.osm.pbf and your options and I get a completely different areas.list with only 88 tiles, but it also has gaps. They disappear when I remove the --precomp-sea option, so that's one big difference to my test environment. No idea why you get 274 tiles, and they cover a completely different area, even parts of Mexico.
I try to find out why splitter creates those gaps now...
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Samstag, 12. Juni 2021 09:34 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
highlighted = pink. maybe that confused you. I should have explained better. But in general ll those gaps should not be there.
On Sat, 12 Jun 2021 at 10:31, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>> wrote: I use C:\openmtbmap\osmconvert.exe --drop-author --drop-version D:\openmtbmap\osmpbf_geofabrik\australia-oceania-latest.osm.pbf -o=C:\openmtbmap\osmpbf_geofabrik\australia-oceania.o5m then start /low /b /wait java -XX:+AggressiveHeap -Xms15000m -Xmx54000m -jar C:\openmtbmap\splitter.jar "--precomp-sea=C:\openmtbmap\maps\sea.zip" --max-nodes=1000000 --max-threads=8 --output=pbf "--keep-complete" --route-rel-values=mtb,bicycle,foot,hiking --max-areas=4000 --geonames-file=C:\OpenMTBMap\maps\cities5000.zip --description=australia-oceania --mapid=65340000 C:\openmtbmap\osmpbf_geofabrik\australia-oceania.o5m
The highlighted tiles selected in Mapsource for sending to GPS device - are empty using improve-overview - but they are filled with sea without using it. They are only empty in overview map. I think those gaps also should not be there - so it is a wider problem that existed before already. For overview map mkgmap should use all the sea/land area for the full coverage - and not cut out areas. Actually cutting for sea/land should also not happen in the normal map. The reason for trimming is to have to maps not overlap itself with empty content - because mkgmap/splitter only cuts rectangles - not polygons. But sea/land will be identical in two country maps - so should not be trimmed
On Sat, 12 Jun 2021 at 10:24, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>> wrote: the problem is - using improve-overview some tiles in the overview map miss sea. I am pretty sure this happens on default style too. But likely not if you use --no-trim and / or keep-complete for splitting. Attached is the areas.list
On Sat, 12 Jun 2021 at 09:40, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>> wrote: Hi Felix,
I don't yet understand what's going on. Please provide a link to your areas.list
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> Gesendet: Freitag, 11. Juni 2021 12:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Nope - that did not help. And I think the problem is a bit unrelated. Mkgmap with your new version and --improve-overview assumes there is an empty map - and puts those three square areas of missing anything. Maybe you give it a try and analyse what happens.
I actually think this bug has been there before already - and it happened to me with contourlines only maps. Meaning mkgmap cuts the map area way too aggressively, and removes part of the map that actually even have content - or was it splitter. I think for contourlines only maps I had to use splitter with --keep-complete and --no-trim else there would be missing. areas in the map. (not on the outside but right in the middle in the ocean usually - but sometimes also e.g. northernmost parts of Norway in an Europe contourlines only map).
So I split australia-oceania WITHOUT --no-trim. Are you assuming to split with --no-trim? Actually those grey boxes are each of its own separate tiles (with nearly no content - e.g. one has a riff polygon only). I guess there is lots of openseamap stuff so splitter creates those tiny tiles... Mkgmap should never trip on the overview map. The normal map should be trimmed aggressively - as we still cannot cut according to a bounding polygon and only using rectangles. But the overview map sea creation should not cut out sea or anything.
I guess you never noticed that working on Norway - but it would be a good start to play around with australia-oceania (it is nice to work with - because it is relatively small in size so compiles fast). See attached screenshot of overview map. All the selected tiles were before showing sea (and do so once past the overview map too). The high DP filter was not the problem. For Australia-Oceania the --improve-overview right now is not a good example. The map was better before. Oh yeah - and --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20 looks better than small values. Actually I think even to rather increase more. Maybe that is why I had less problems right from the start - because I cut away tiny islands.
C:\openmtbmap\maps>if yes NEQ no start /low /b /wait java -jar -XX:+AggressiveHeap -XX:StringTableSize=1000003 -Xms15000M -Xmx29000M C:\openmtbmap\mkgmap.jar --max-jobs=8 --order-by-decreasing-area "--generate-sea" --code-page=1252 "--precomp-sea=C:\openmtbmap\maps\sea.zip" "--style-file=C:\openmtbmap\openmtbmap_style" --improve-overview --add-boundary-nodes-at-admin-boundaries --drive-on=detect --allow-reverse-merge --line-types-with-direction=0x18,0x1f,0x10016,0x10101,0x10105,0x10401,0x10403,0x10405,0x10408,0x10409,0x1040b,0x1040d,0x1040e,0x10500,0x10501,0x10502,0x10503,0x10504,0x10505,0x10506,0x10507,0x10607,0x10609,0x1060b,0x10702,0x10703,0x10704,0x10705,0x10706,0x10707,0x10a00,0x10a02,0x10a04,0x10a05,0x10e1e,0x10e0f,0x10e0e,0x10e1e,0x10f0a,0x10f1c,0x10e1d --nsis --index --levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18" --overview-levels="7:17, 8:16, 9:15, 10:14, 11:13, 12:12" --add-pois-to-areas --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier= entrance --x-simplify-filter-line-errors=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,17:6,14:6 --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9,17:2.6 --add-boundary-nodes-at-admin-boundaries=2 --poi-excl-index=0x6405,0x4316,0x2f00 --copyright-file="C:\openmtbmap\openmtbmap_svn\copyrightopm.txt" --license-file="C:\openmtbmap\openmtbmap_svn\licenseopm.txt" --cycle-map --ignore-fixme-values --housenumbers --road-name-config=C:\openmtbmap\openmtbmap_svn\roadNameConfig.txt --split-name-index --link-pois-to-ways --ignore-turn-restrictions --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20" --description=omtb_auo --show-profiles=1 --location-autofill=bounds,is_in,nearest --bounds=C:\openmtbmap\maps\bounds.zip --mdr7-del=pri;sec;ter;cw;min;unsf,uncl;living;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1 .;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;bridge;swing;aqueduct;viaduct;"ntnl bndry";admin_lv=4;"ntnl park";weir;dam;waterfall;rapids;stream;river;drain;ditch;"huge river";"hugest river";"medium river";"small river";"wide river";"hugest canal";"huge canal";"medium canal";"small canal";"big canal";canal;snowpark;Skitour-descent;Skipiste;Skislope;illuminated;Nordic-Skiing;skitour ;platter;ropetow;tbar;chairlift;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath --mdr7-excl=pri;sec;ter;cw;min;unsf,uncl;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1.;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx 4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;"ntnl bndry";admin_lv=4;"ntnl park";"huge river";"hugest river";"medium river";"small river";"wide river";"hugest canal";"huge canal";"medium canal";"small canal";"big canal";canal;snowpark;Skitour-descent;illuminated;Nordic-Skiing;skitour;platter;ropetow;tbar;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath --route --country-abbr=auo --country-name=australia-oceania --mapname=65340000 --family-id=6534 --product-id=1 --series-name=omtb_australia-oceania_11.06.2021 --family-name=mtb_auo_11.06.2021 --tdbfile --gmapi --overview-mapname=mapsetc --keep-going --area-name="australia-oceania_11.06.2021_omtb" -c D:\openmtbmap\maps\template.australia-oceania C:\OpenMTBMap\contourlines20\australia-oceania\7*.img typauo.TYP
On Fri, 11 Jun 2021 at 12:25, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>>> wrote: yes I was using:
--x-simplify-filter-line-errors=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,16:8,14:9 --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9 --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20"
levels = 0:24, 1:22, 2:21, 3:20, 4:19, 5:18 overview-levels = 6:17, 7:16, 8:15, 9:14, 10:13
As this only affects the overview map - I guess I should change it to: --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9,17:2.6 ??
The polygon-size-limits should not matter as I have the skip-size filter set for sea.
I had worked quite a long time to optimize those settings with the old behaviour.
On Fri, 11 Jun 2021 at 11:50, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> wrote: Hi Felix,
Maybe you are using large values for the Douglas-Peucker filter at low resolutions? That's probably a bad idea with the new option. I always tested with the default 2.6 for all levels. The effect of the new option is that DP really can do its work.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> Gesendet: Freitag, 11. Juni 2021 10:23 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
--generate-sea --precomp-sea=C:\openmtbmap\maps\sea.zip --order-by-decreasing-area --allow-reverse-merge I thought using precomp-sea is fine (I did not update the precomp-sea in between)
On Fri, 11 Jun 2021 at 11:10, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>>>> wrote: compilation time includes splitting, and some other stuff. Loads of countries (9:34 / 9:21 (sorry dumb error 9:19) for all european single countries and a few continents (but not Europe continent) in hours.
On Fri, 11 Jun 2021 at 11:08, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>>>> wrote: I just compiled the australia-oceania map with that option, and I think I must be missing something. It got substantially worse (it is identical until the overview map kicks in) - then I get some huge squares of sea missing. Compile time for all maps until that point before Compilation time is not up a lot: 0:12 - 9:46 = 9:34 one week before (except older mapdata no changes in compilation procedure and older mkgmap) 20:17 - 5:38 = 9:19
Anything I could be missing? I use the newest low-res branch build and added --improve-overview to the compilation process.
in my polygons file I have: natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=2 } [0x10f1d resolution 10]
On Fri, 11 Jun 2021 at 07:12, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>>>> wrote: Hi all,
I hoped for some positive feedback on this but got none so far. Did I miss something important?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpeterm ann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>>>>> Gesendet: Montag, 7. Juni 2021 21:05 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Hi Felix,
the map contained was without routing or index, so for a normal map the difference should be even smaller. There is no need to change sea.zip. You just have to use --improve-overview for now.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@g mail.com<mailto:extremecarver@gmail.com>>><mailto:extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>>>> Gesendet: Montag, 7. Juni 2021 21:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
I guess that is a time for a full Norway map based on default style - so that is quite okay. Not a sea only Norway map... Well I hope that Thorsten Kukuk can adapt his sea files in the near future then...
On Mon, 7 Jun 2021 at 19:37, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>>><ma ilto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>>>>> wrote: OK, I think found a good solution. Speed is quite OK, I see 9 min 48 secs for map of norway and instead of 8 min 44 secs with r4756, and I consider Norway to be a worst case.
See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4761 for the details.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mail to:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto:gpeterm<mailto:gpeterm> ann_muenchen@hotmail.com<mailto:ann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
> Gesendet: Montag, 7. Juni 2021 12:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
With the provided patch the speed is very poor for areas like Norway, probably twice the time. It is much slower because it does the complex multipolygon cutting for each level in the overview map. Probably too slow for complex coastal areas. This time will be the same for precomp-sea unless we can store sea polygons for each resolution.
Performance will be no problem if I find a way to use Douglas-Peucker or similar before cutting. That was my original idea but DP produces self intersecting polygons and the MultipolygonCutter cannot cope with that.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mail to:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>>><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto: extremecarver@g<mailto:extremecarver@g> mail.com<http://mail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>>>>> Gesendet: Montag, 7. Juni 2021 11:55 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Is it only much slower because of not using precomp sea? Or will it be much slower in general? And what is much slower for say Europe continent map? If a modern 4core/8thread processor needs 30 minutes more I would prefer the old way knowing it is worse (if the time difference is negligible with precomp-sea then that would be great).
On Mon, 7 Jun 2021 at 12:26, Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailt o:rwb-mkgmap@jagit.co.uk>>>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailt o:rwb-mkgmap@jagit.co.uk<mailto:o%3Arwb-mkgmap@jagit.co.uk>>>>>>> wrote: Hi Gerd
This is going to take some studying to work out the implications. Can't do much for the next few days however, but will look carefully at the end of the week.
Ticker
On Sun, 2021-06-06 at 14:02 +0000, Gerd Petermann wrote:
Hi,
the attached patch improves the overview map, but so far only when precomp-sea is NOT used. I tested it with --generate-sea=multipolygon,floodblocker so that mkgmap really has a multipolygon with the natual=sea data.
For each level in the overview map it uses the original multipolygon data to compute the rings which will might visible at the given resolution. This requires more time compared to the current code but the result is much better and some fine tuning is possible.
To be able to use this also with --precomp-sea we need some changes in the code which generates sea.zip so that one multipolygon relation for each tile is stored.
I've uploaded the results here: https://files.mkgmap.org.uk/download/511/compare.7z What do you think?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap. org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap<mailto:mkgmap-dev@list s.mkgmap>. org.uk<http://org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.or g.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.or<mailto:mkgmap-dev@lis ts.mkgmap.or> g.uk<http://g.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.or g.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.or g.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
Hi Gerd hmm - maybe I should keep it... Without it I know get a SEVERE (global): The RGN section of the map or tile is too big. The maximum size is 16777215 bytes. Try splitting the map into smaller tiles or reducing the amount of information included in the map. error. I guess that means the address search will be partly broken? That error message is a bit confusing. And I get the following problem - mkgmap trims to aggressively actually deleting part of the map. Something in this whole process is seriously broken... Same process as above, not using --improve-overview yet. Just without precomp-sea On Sat, 12 Jun 2021 at 12:42, Felix Hartmann <extremecarver@gmail.com> wrote:
I also do not know anymore. I guess I should drop it. I tried googling it - but could not find anything. Well I am going to drop it now. I still get 268 tiles however - and not 88
On Sat, 12 Jun 2021 at 12:19, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
I don't remember exactly why the --precom-sea option was added to splitter, but I think it makes no sense to use that option in combination with trimming. What's your reason to use this combination?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Samstag, 12. Juni 2021 10:30 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Hi Felix,
r602 and r604 should do the same. looking at the splitter log I see Exact map coverage read from input file(s) is (-57.16482639312744,44.65547561645508) to (26.46477699279785,179.99469995498657) Rounded map coverage is (-57.1728515625,44.6484375) to (26.4990234375,180.0)
This covers parts of India and Africa, but for sure not Mexico. I assume that your australia-oceania.areas.list was not produced with a file downloaded from geofabrik, maybe you updated it with a bad tool?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Samstag, 12. Juni 2021 10:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
I`m still using splitter 602. I did not know 604 would behave differently - I will try it out because those tiny tiles without much information in australia-oceana are not that helpful. But the problem is not directly related to the version. Those gaps have been there a long time (well and the 4 missing/empty) tiles did not happen before using --improve-overview. As this surely is somehow related - and fits in the topic of improving the overview map - great that you are looking for a solution.
Well everywhere on my screenshot where you see something red - (national border - I think level2) there is some content. That australia-oceana map has some parts of data kinda anywhere...
Trimming the sea on one hand is nice - because the sea/land area using --precomp-sea is a bit confusing too - as when you zoom into some areas - they will not contain data. But I think that is less of a problem then the gaps - and it should be clear an australia-oceania map does not have detailed map data of Asia...
On Sat, 12 Jun 2021 at 11:03, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix,
I've just used splitter r604 with a freshly downloaded sea.zip and australia-oceania-latest.osm.pbf and your options and I get a completely different areas.list with only 88 tiles, but it also has gaps. They disappear when I remove the --precomp-sea option, so that's one big difference to my test environment. No idea why you get 274 tiles, and they cover a completely different area, even parts of Mexico.
I try to find out why splitter creates those gaps now...
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Samstag, 12. Juni 2021 09:34 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
highlighted = pink. maybe that confused you. I should have explained better. But in general ll those gaps should not be there.
On Sat, 12 Jun 2021 at 10:31, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>> wrote: I use C:\openmtbmap\osmconvert.exe --drop-author --drop-version D:\openmtbmap\osmpbf_geofabrik\australia-oceania-latest.osm.pbf -o=C:\openmtbmap\osmpbf_geofabrik\australia-oceania.o5m then start /low /b /wait java -XX:+AggressiveHeap -Xms15000m -Xmx54000m -jar C:\openmtbmap\splitter.jar "--precomp-sea=C:\openmtbmap\maps\sea.zip" --max-nodes=1000000 --max-threads=8 --output=pbf "--keep-complete" --route-rel-values=mtb,bicycle,foot,hiking --max-areas=4000 --geonames-file=C:\OpenMTBMap\maps\cities5000.zip --description=australia-oceania --mapid=65340000 C:\openmtbmap\osmpbf_geofabrik\australia-oceania.o5m
The highlighted tiles selected in Mapsource for sending to GPS device - are empty using improve-overview - but they are filled with sea without using it. They are only empty in overview map. I think those gaps also should not be there - so it is a wider problem that existed before already. For overview map mkgmap should use all the sea/land area for the full coverage - and not cut out areas. Actually cutting for sea/land should also not happen in the normal map. The reason for trimming is to have to maps not overlap itself with empty content - because mkgmap/splitter only cuts rectangles - not polygons. But sea/land will be identical in two country maps - so should not be trimmed
On Sat, 12 Jun 2021 at 10:24, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>> wrote: the problem is - using improve-overview some tiles in the overview map miss sea. I am pretty sure this happens on default style too. But likely not if you use --no-trim and / or keep-complete for splitting. Attached is the areas.list
On Sat, 12 Jun 2021 at 09:40, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>> wrote: Hi Felix,
I don't yet understand what's going on. Please provide a link to your areas.list
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> Gesendet: Freitag, 11. Juni 2021 12:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Nope - that did not help. And I think the problem is a bit unrelated. Mkgmap with your new version and --improve-overview assumes there is an empty map - and puts those three square areas of missing anything. Maybe you give it a try and analyse what happens.
I actually think this bug has been there before already - and it happened to me with contourlines only maps. Meaning mkgmap cuts the map area way too aggressively, and removes part of the map that actually even have content - or was it splitter. I think for contourlines only maps I had to use splitter with --keep-complete and --no-trim else there would be missing. areas in the map. (not on the outside but right in the middle in the ocean usually - but sometimes also e.g. northernmost parts of Norway in an Europe contourlines only map).
So I split australia-oceania WITHOUT --no-trim. Are you assuming to split with --no-trim? Actually those grey boxes are each of its own separate tiles (with nearly no content - e.g. one has a riff polygon only). I guess there is lots of openseamap stuff so splitter creates those tiny tiles... Mkgmap should never trip on the overview map. The normal map should be trimmed aggressively - as we still cannot cut according to a bounding polygon and only using rectangles. But the overview map sea creation should not cut out sea or anything.
I guess you never noticed that working on Norway - but it would be a good start to play around with australia-oceania (it is nice to work with - because it is relatively small in size so compiles fast). See attached screenshot of overview map. All the selected tiles were before showing sea (and do so once past the overview map too). The high DP filter was not the problem. For Australia-Oceania the --improve-overview right now is not a good example. The map was better before. Oh yeah - and --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20 looks better than small values. Actually I think even to rather increase more. Maybe that is why I had less problems right from the start - because I cut away tiny islands.
C:\openmtbmap\maps>if yes NEQ no start /low /b /wait java -jar -XX:+AggressiveHeap -XX:StringTableSize=1000003 -Xms15000M -Xmx29000M C:\openmtbmap\mkgmap.jar --max-jobs=8 --order-by-decreasing-area "--generate-sea" --code-page=1252 "--precomp-sea=C:\openmtbmap\maps\sea.zip" "--style-file=C:\openmtbmap\openmtbmap_style" --improve-overview --add-boundary-nodes-at-admin-boundaries --drive-on=detect --allow-reverse-merge --line-types-with-direction=0x18,0x1f,0x10016,0x10101,0x10105,0x10401,0x10403,0x10405,0x10408,0x10409,0x1040b,0x1040d,0x1040e,0x10500,0x10501,0x10502,0x10503,0x10504,0x10505,0x10506,0x10507,0x10607,0x10609,0x1060b,0x10702,0x10703,0x10704,0x10705,0x10706,0x10707,0x10a00,0x10a02,0x10a04,0x10a05,0x10e1e,0x10e0f,0x10e0e,0x10e1e,0x10f0a,0x10f1c,0x10e1d --nsis --index --levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18" --overview-levels="7:17, 8:16, 9:15, 10:14, 11:13, 12:12" --add-pois-to-areas --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier= entrance --x-simplify-filter-line-errors=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,17:6,14:6 --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9,17:2.6 --add-boundary-nodes-at-admin-boundaries=2 --poi-excl-index=0x6405,0x4316,0x2f00 --copyright-file="C:\openmtbmap\openmtbmap_svn\copyrightopm.txt" --license-file="C:\openmtbmap\openmtbmap_svn\licenseopm.txt" --cycle-map --ignore-fixme-values --housenumbers --road-name-config=C:\openmtbmap\openmtbmap_svn\roadNameConfig.txt --split-name-index --link-pois-to-ways --ignore-turn-restrictions --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20" --description=omtb_auo --show-profiles=1 --location-autofill=bounds,is_in,nearest --bounds=C:\openmtbmap\maps\bounds.zip --mdr7-del=pri;sec;ter;cw;min;unsf,uncl;living;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1 .;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;bridge;swing;aqueduct;viaduct;"ntnl bndry";admin_lv=4;"ntnl park";weir;dam;waterfall;rapids;stream;river;drain;ditch;"huge river";"hugest river";"medium river";"small river";"wide river";"hugest canal";"huge canal";"medium canal";"small canal";"big canal";canal;snowpark;Skitour-descent;Skipiste;Skislope;illuminated;Nordic-Skiing;skitour ;platter;ropetow;tbar;chairlift;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath --mdr7-excl=pri;sec;ter;cw;min;unsf,uncl;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1.;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx 4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;"ntnl bndry";admin_lv=4;"ntnl park";"huge river";"hugest river";"medium river";"small river";"wide river";"hugest canal";"huge canal";"medium canal";"small canal";"big canal";canal;snowpark;Skitour-descent;illuminated;Nordic-Skiing;skitour;platter;ropetow;tbar;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath --route --country-abbr=auo --country-name=australia-oceania --mapname=65340000 --family-id=6534 --product-id=1 --series-name=omtb_australia-oceania_11.06.2021 --family-name=mtb_auo_11.06.2021 --tdbfile --gmapi --overview-mapname=mapsetc --keep-going --area-name="australia-oceania_11.06.2021_omtb" -c D:\openmtbmap\maps\template.australia-oceania C:\OpenMTBMap\contourlines20\australia-oceania\7*.img typauo.TYP
On Fri, 11 Jun 2021 at 12:25, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>>> wrote: yes I was using:
--x-simplify-filter-line-errors=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,16:8,14:9 --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9 --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20"
levels = 0:24, 1:22, 2:21, 3:20, 4:19, 5:18 overview-levels = 6:17, 7:16, 8:15, 9:14, 10:13
As this only affects the overview map - I guess I should change it to: --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9,17:2.6 ??
The polygon-size-limits should not matter as I have the skip-size filter set for sea.
I had worked quite a long time to optimize those settings with the old behaviour.
On Fri, 11 Jun 2021 at 11:50, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> wrote: Hi Felix,
Maybe you are using large values for the Douglas-Peucker filter at low resolutions? That's probably a bad idea with the new option. I always tested with the default 2.6 for all levels. The effect of the new option is that DP really can do its work.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> Gesendet: Freitag, 11. Juni 2021 10:23 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
--generate-sea --precomp-sea=C:\openmtbmap\maps\sea.zip --order-by-decreasing-area --allow-reverse-merge I thought using precomp-sea is fine (I did not update the precomp-sea in between)
On Fri, 11 Jun 2021 at 11:10, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>>>> wrote: compilation time includes splitting, and some other stuff. Loads of countries (9:34 / 9:21 (sorry dumb error 9:19) for all european single countries and a few continents (but not Europe continent) in hours.
On Fri, 11 Jun 2021 at 11:08, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>>>> wrote: I just compiled the australia-oceania map with that option, and I think I must be missing something. It got substantially worse (it is identical until the overview map kicks in) - then I get some huge squares of sea missing. Compile time for all maps until that point before Compilation time is not up a lot: 0:12 - 9:46 = 9:34 one week before (except older mapdata no changes in compilation procedure and older mkgmap) 20:17 - 5:38 = 9:19
Anything I could be missing? I use the newest low-res branch build and added --improve-overview to the compilation process.
in my polygons file I have: natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=2 } [0x10f1d resolution 10]
On Fri, 11 Jun 2021 at 07:12, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>>>> wrote: Hi all,
I hoped for some positive feedback on this but got none so far. Did I miss something important?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpeterm ann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>>>>> Gesendet: Montag, 7. Juni 2021 21:05 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Hi Felix,
the map contained was without routing or index, so for a normal map the difference should be even smaller. There is no need to change sea.zip. You just have to use --improve-overview for now.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@g mail.com<mailto:extremecarver@gmail.com>>><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>>> Gesendet: Montag, 7. Juni 2021 21:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
I guess that is a time for a full Norway map based on default style - so that is quite okay. Not a sea only Norway map... Well I hope that Thorsten Kukuk can adapt his sea files in the near future then...
On Mon, 7 Jun 2021 at 19:37, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <ma ilto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>>>>> wrote: OK, I think found a good solution. Speed is quite OK, I see 9 min 48 secs for map of norway and instead of 8 min 44 secs with r4756, and I consider Norway to be a worst case.
See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4761 for the details.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mail to:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto:gpeterm<mailto:gpeterm> ann_muenchen@hotmail.com<mailto:ann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>>>>> Gesendet: Montag, 7. Juni 2021 12:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
With the provided patch the speed is very poor for areas like Norway, probably twice the time. It is much slower because it does the complex multipolygon cutting for each level in the overview map. Probably too slow for complex coastal areas. This time will be the same for precomp-sea unless we can store sea polygons for each resolution.
Performance will be no problem if I find a way to use Douglas-Peucker or similar before cutting. That was my original idea but DP produces self intersecting polygons and the MultipolygonCutter cannot cope with that.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mail to:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>>><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto: extremecarver@g<mailto:extremecarver@g> mail.com<http://mail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>>>>> Gesendet: Montag, 7. Juni 2021 11:55 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Is it only much slower because of not using precomp sea? Or will it be much slower in general? And what is much slower for say Europe continent map? If a modern 4core/8thread processor needs 30 minutes more I would prefer the old way knowing it is worse (if the time difference is negligible with precomp-sea then that would be great).
On Mon, 7 Jun 2021 at 12:26, Ticker Berkin <rwb-mkgmap@jagit.co.uk <mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailt o:rwb-mkgmap@jagit.co.uk>>>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailt o:rwb-mkgmap@jagit.co.uk<mailto:o%3Arwb-mkgmap@jagit.co.uk>>>>>>> wrote: Hi Gerd
This is going to take some studying to work out the implications. Can't do much for the next few days however, but will look carefully at the end of the week.
Ticker
On Sun, 2021-06-06 at 14:02 +0000, Gerd Petermann wrote:
Hi,
the attached patch improves the overview map, but so far only when precomp-sea is NOT used. I tested it with --generate-sea=multipolygon,floodblocker so that mkgmap really has a multipolygon with the natual=sea data.
For each level in the overview map it uses the original multipolygon data to compute the rings which will might visible at the given resolution. This requires more time compared to the current code but the result is much better and some fine tuning is possible.
To be able to use this also with --precomp-sea we need some changes in the code which generates sea.zip so that one multipolygon relation for each tile is stored.
I've uploaded the results here: https://files.mkgmap.org.uk/download/511/compare.7z What do you think?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap. org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap<mailto:mkgmap-dev@list s.mkgmap>. org.uk<http://org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk >> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.or g.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.or<mailto:mkgmap-dev@lis ts.mkgmap.or> g.uk<http://g.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk >> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.or g.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.or g.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
oh sorry did not see your message. But yeah I hope you can solve that trimming problem. It should not happen that mkgmap (or is it splitter) deletes part of the map on the borders (I guess it is all related). Just play around with australia-oceania and try to get something useful... I feel this is way more disturbing than the tiny white stripes (though they in some versions were really annoying to - but that was rarer than those huge white blocks). On Sat, 12 Jun 2021 at 13:33, Felix Hartmann <extremecarver@gmail.com> wrote:
Hi Gerd
hmm - maybe I should keep it... Without it I know get a SEVERE (global): The RGN section of the map or tile is too big. The maximum size is 16777215 bytes. Try splitting the map into smaller tiles or reducing the amount of information included in the map.
error. I guess that means the address search will be partly broken? That error message is a bit confusing.
And I get the following problem - mkgmap trims to aggressively actually deleting part of the map. Something in this whole process is seriously broken... Same process as above, not using --improve-overview yet. Just without precomp-sea
On Sat, 12 Jun 2021 at 12:42, Felix Hartmann <extremecarver@gmail.com> wrote:
I also do not know anymore. I guess I should drop it. I tried googling it - but could not find anything. Well I am going to drop it now. I still get 268 tiles however - and not 88
On Sat, 12 Jun 2021 at 12:19, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi Felix,
I don't remember exactly why the --precom-sea option was added to splitter, but I think it makes no sense to use that option in combination with trimming. What's your reason to use this combination?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Samstag, 12. Juni 2021 10:30 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Hi Felix,
r602 and r604 should do the same. looking at the splitter log I see Exact map coverage read from input file(s) is (-57.16482639312744,44.65547561645508) to (26.46477699279785,179.99469995498657) Rounded map coverage is (-57.1728515625,44.6484375) to (26.4990234375,180.0)
This covers parts of India and Africa, but for sure not Mexico. I assume that your australia-oceania.areas.list was not produced with a file downloaded from geofabrik, maybe you updated it with a bad tool?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Samstag, 12. Juni 2021 10:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
I`m still using splitter 602. I did not know 604 would behave differently - I will try it out because those tiny tiles without much information in australia-oceana are not that helpful. But the problem is not directly related to the version. Those gaps have been there a long time (well and the 4 missing/empty) tiles did not happen before using --improve-overview. As this surely is somehow related - and fits in the topic of improving the overview map - great that you are looking for a solution.
Well everywhere on my screenshot where you see something red - (national border - I think level2) there is some content. That australia-oceana map has some parts of data kinda anywhere...
Trimming the sea on one hand is nice - because the sea/land area using --precomp-sea is a bit confusing too - as when you zoom into some areas - they will not contain data. But I think that is less of a problem then the gaps - and it should be clear an australia-oceania map does not have detailed map data of Asia...
On Sat, 12 Jun 2021 at 11:03, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix,
I've just used splitter r604 with a freshly downloaded sea.zip and australia-oceania-latest.osm.pbf and your options and I get a completely different areas.list with only 88 tiles, but it also has gaps. They disappear when I remove the --precomp-sea option, so that's one big difference to my test environment. No idea why you get 274 tiles, and they cover a completely different area, even parts of Mexico.
I try to find out why splitter creates those gaps now...
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann < extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Samstag, 12. Juni 2021 09:34 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
highlighted = pink. maybe that confused you. I should have explained better. But in general ll those gaps should not be there.
On Sat, 12 Jun 2021 at 10:31, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>> wrote: I use C:\openmtbmap\osmconvert.exe --drop-author --drop-version D:\openmtbmap\osmpbf_geofabrik\australia-oceania-latest.osm.pbf -o=C:\openmtbmap\osmpbf_geofabrik\australia-oceania.o5m then start /low /b /wait java -XX:+AggressiveHeap -Xms15000m -Xmx54000m -jar C:\openmtbmap\splitter.jar "--precomp-sea=C:\openmtbmap\maps\sea.zip" --max-nodes=1000000 --max-threads=8 --output=pbf "--keep-complete" --route-rel-values=mtb,bicycle,foot,hiking --max-areas=4000 --geonames-file=C:\OpenMTBMap\maps\cities5000.zip --description=australia-oceania --mapid=65340000 C:\openmtbmap\osmpbf_geofabrik\australia-oceania.o5m
The highlighted tiles selected in Mapsource for sending to GPS device - are empty using improve-overview - but they are filled with sea without using it. They are only empty in overview map. I think those gaps also should not be there - so it is a wider problem that existed before already. For overview map mkgmap should use all the sea/land area for the full coverage - and not cut out areas. Actually cutting for sea/land should also not happen in the normal map. The reason for trimming is to have to maps not overlap itself with empty content - because mkgmap/splitter only cuts rectangles - not polygons. But sea/land will be identical in two country maps - so should not be trimmed
On Sat, 12 Jun 2021 at 10:24, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>> wrote: the problem is - using improve-overview some tiles in the overview map miss sea. I am pretty sure this happens on default style too. But likely not if you use --no-trim and / or keep-complete for splitting. Attached is the areas.list
On Sat, 12 Jun 2021 at 09:40, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>> wrote: Hi Felix,
I don't yet understand what's going on. Please provide a link to your areas.list
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> Gesendet: Freitag, 11. Juni 2021 12:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Nope - that did not help. And I think the problem is a bit unrelated. Mkgmap with your new version and --improve-overview assumes there is an empty map - and puts those three square areas of missing anything. Maybe you give it a try and analyse what happens.
I actually think this bug has been there before already - and it happened to me with contourlines only maps. Meaning mkgmap cuts the map area way too aggressively, and removes part of the map that actually even have content - or was it splitter. I think for contourlines only maps I had to use splitter with --keep-complete and --no-trim else there would be missing. areas in the map. (not on the outside but right in the middle in the ocean usually - but sometimes also e.g. northernmost parts of Norway in an Europe contourlines only map).
So I split australia-oceania WITHOUT --no-trim. Are you assuming to split with --no-trim? Actually those grey boxes are each of its own separate tiles (with nearly no content - e.g. one has a riff polygon only). I guess there is lots of openseamap stuff so splitter creates those tiny tiles... Mkgmap should never trip on the overview map. The normal map should be trimmed aggressively - as we still cannot cut according to a bounding polygon and only using rectangles. But the overview map sea creation should not cut out sea or anything.
I guess you never noticed that working on Norway - but it would be a good start to play around with australia-oceania (it is nice to work with - because it is relatively small in size so compiles fast). See attached screenshot of overview map. All the selected tiles were before showing sea (and do so once past the overview map too). The high DP filter was not the problem. For Australia-Oceania the --improve-overview right now is not a good example. The map was better before. Oh yeah - and --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20 looks better than small values. Actually I think even to rather increase more. Maybe that is why I had less problems right from the start - because I cut away tiny islands.
C:\openmtbmap\maps>if yes NEQ no start /low /b /wait java -jar -XX:+AggressiveHeap -XX:StringTableSize=1000003 -Xms15000M -Xmx29000M C:\openmtbmap\mkgmap.jar --max-jobs=8 --order-by-decreasing-area "--generate-sea" --code-page=1252 "--precomp-sea=C:\openmtbmap\maps\sea.zip" "--style-file=C:\openmtbmap\openmtbmap_style" --improve-overview --add-boundary-nodes-at-admin-boundaries --drive-on=detect --allow-reverse-merge --line-types-with-direction=0x18,0x1f,0x10016,0x10101,0x10105,0x10401,0x10403,0x10405,0x10408,0x10409,0x1040b,0x1040d,0x1040e,0x10500,0x10501,0x10502,0x10503,0x10504,0x10505,0x10506,0x10507,0x10607,0x10609,0x1060b,0x10702,0x10703,0x10704,0x10705,0x10706,0x10707,0x10a00,0x10a02,0x10a04,0x10a05,0x10e1e,0x10e0f,0x10e0e,0x10e1e,0x10f0a,0x10f1c,0x10e1d --nsis --index --levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18" --overview-levels="7:17, 8:16, 9:15, 10:14, 11:13, 12:12" --add-pois-to-areas --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier= entrance --x-simplify-filter-line-errors=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,17:6,14:6 --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9,17:2.6 --add-boundary-nodes-at-admin-boundaries=2 --poi-excl-index=0x6405,0x4316,0x2f00 --copyright-file="C:\openmtbmap\openmtbmap_svn\copyrightopm.txt" --license-file="C:\openmtbmap\openmtbmap_svn\licenseopm.txt" --cycle-map --ignore-fixme-values --housenumbers --road-name-config=C:\openmtbmap\openmtbmap_svn\roadNameConfig.txt --split-name-index --link-pois-to-ways --ignore-turn-restrictions --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20" --description=omtb_auo --show-profiles=1 --location-autofill=bounds,is_in,nearest --bounds=C:\openmtbmap\maps\bounds.zip --mdr7-del=pri;sec;ter;cw;min;unsf,uncl;living;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1 .;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;bridge;swing;aqueduct;viaduct;"ntnl bndry";admin_lv=4;"ntnl park";weir;dam;waterfall;rapids;stream;river;drain;ditch;"huge river";"hugest river";"medium river";"small river";"wide river";"hugest canal";"huge canal";"medium canal";"small canal";"big canal";canal;snowpark;Skitour-descent;Skipiste;Skislope;illuminated;Nordic-Skiing;skitour ;platter;ropetow;tbar;chairlift;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath --mdr7-excl=pri;sec;ter;cw;min;unsf,uncl;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1.;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx 4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;"ntnl bndry";admin_lv=4;"ntnl park";"huge river";"hugest river";"medium river";"small river";"wide river";"hugest canal";"huge canal";"medium canal";"small canal";"big canal";canal;snowpark;Skitour-descent;illuminated;Nordic-Skiing;skitour;platter;ropetow;tbar;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath --route --country-abbr=auo --country-name=australia-oceania --mapname=65340000 --family-id=6534 --product-id=1 --series-name=omtb_australia-oceania_11.06.2021 --family-name=mtb_auo_11.06.2021 --tdbfile --gmapi --overview-mapname=mapsetc --keep-going --area-name="australia-oceania_11.06.2021_omtb" -c D:\openmtbmap\maps\template.australia-oceania C:\OpenMTBMap\contourlines20\australia-oceania\7*.img typauo.TYP
On Fri, 11 Jun 2021 at 12:25, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>>> wrote: yes I was using:
--x-simplify-filter-line-errors=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,16:8,14:9 --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9 --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20"
levels = 0:24, 1:22, 2:21, 3:20, 4:19, 5:18 overview-levels = 6:17, 7:16, 8:15, 9:14, 10:13
As this only affects the overview map - I guess I should change it to: --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9,17:2.6 ??
The polygon-size-limits should not matter as I have the skip-size filter set for sea.
I had worked quite a long time to optimize those settings with the old behaviour.
On Fri, 11 Jun 2021 at 11:50, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> wrote: Hi Felix,
Maybe you are using large values for the Douglas-Peucker filter at low resolutions? That's probably a bad idea with the new option. I always tested with the default 2.6 for all levels. The effect of the new option is that DP really can do its work.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com
<mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com
<mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com <mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> Gesendet: Freitag, 11. Juni 2021 10:23 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
--generate-sea --precomp-sea=C:\openmtbmap\maps\sea.zip --order-by-decreasing-area --allow-reverse-merge I thought using precomp-sea is fine (I did not update the precomp-sea in between)
On Fri, 11 Jun 2021 at 11:10, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>>>> wrote: compilation time includes splitting, and some other stuff. Loads of countries (9:34 / 9:21 (sorry dumb error 9:19) for all european single countries and a few continents (but not Europe continent) in hours.
On Fri, 11 Jun 2021 at 11:08, Felix Hartmann <extremecarver@gmail.com <mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>>>> wrote: I just compiled the australia-oceania map with that option, and I think I must be missing something. It got substantially worse (it is identical until the overview map kicks in) - then I get some huge squares of sea missing. Compile time for all maps until that point before Compilation time is not up a lot: 0:12 - 9:46 = 9:34 one week before (except older mapdata no changes in compilation procedure and older mkgmap) 20:17 - 5:38 = 9:19
Anything I could be missing? I use the newest low-res branch build and added --improve-overview to the compilation process.
in my polygons file I have: natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=2 } [0x10f1d resolution 10]
On Fri, 11 Jun 2021 at 07:12, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>>>> wrote: Hi all,
I hoped for some positive feedback on this but got none so far. Did I miss something important?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpeterm ann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
>> Gesendet: Montag, 7. Juni 2021 21:05 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Hi Felix,
the map contained was without routing or index, so for a normal map the difference should be even smaller. There is no need to change sea.zip. You just have to use --improve-overview for now.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com
<mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com
<mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com <mailto:extremecarver@g mail.com<mailto:extremecarver@gmail.com>>><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto: extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>>> Gesendet: Montag, 7. Juni 2021 21:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
I guess that is a time for a full Norway map based on default style - so that is quite okay. Not a sea only Norway map... Well I hope that Thorsten Kukuk can adapt his sea files in the near future then...
On Mon, 7 Jun 2021 at 19:37, Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <ma ilto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>>>>> wrote: OK, I think found a good solution. Speed is quite OK, I see 9 min 48 secs for map of norway and instead of 8 min 44 secs with r4756, and I consider Norway to be a worst case.
See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4761 for the details.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mail to:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpeterm<mailto:gpeterm> ann_muenchen@hotmail.com<mailto:ann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com
<mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>><mailto: gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com<mailto: gpetermann_muenchen@hotmail.com>>>>>> Gesendet: Montag, 7. Juni 2021 12:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
With the provided patch the speed is very poor for areas like Norway, probably twice the time. It is much slower because it does the complex multipolygon cutting for each level in the overview map. Probably too slow for complex coastal areas. This time will be the same for precomp-sea unless we can store sea polygons for each resolution.
Performance will be no problem if I find a way to use Douglas-Peucker or similar before cutting. That was my original idea but DP produces self intersecting polygons and the MultipolygonCutter cannot cope with that.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mail to:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto: mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com
<mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com
<mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com <mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com
<mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com <mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com <mailto:extremecarver@g<mailto:extremecarver@g> mail.com<http://mail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto: extremecarver@gmail.com>>>>>> Gesendet: Montag, 7. Juni 2021 11:55 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Is it only much slower because of not using precomp sea? Or will it be much slower in general? And what is much slower for say Europe continent map? If a modern 4core/8thread processor needs 30 minutes more I would prefer the old way knowing it is worse (if the time difference is negligible with precomp-sea then that would be great).
On Mon, 7 Jun 2021 at 12:26, Ticker Berkin <rwb-mkgmap@jagit.co.uk <mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailt o:rwb-mkgmap@jagit.co.uk>>>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto: rwb-mkgmap@jagit.co.uk><mailt o:rwb-mkgmap@jagit.co.uk<mailto:o%3Arwb-mkgmap@jagit.co.uk>>>>>>> wrote: Hi Gerd
This is going to take some studying to work out the implications. Can't do much for the next few days however, but will look carefully at the end of the week.
Ticker
On Sun, 2021-06-06 at 14:02 +0000, Gerd Petermann wrote:
Hi,
the attached patch improves the overview map, but so far only when precomp-sea is NOT used. I tested it with --generate-sea=multipolygon,floodblocker so that mkgmap really has a multipolygon with the natual=sea data.
For each level in the overview map it uses the original multipolygon data to compute the rings which will might visible at the given resolution. This requires more time compared to the current code but the result is much better and some fine tuning is possible.
To be able to use this also with --precomp-sea we need some changes in the code which generates sea.zip so that one multipolygon relation for each tile is stored.
I've uploaded the results here: https://files.mkgmap.org.uk/download/511/compare.7z What do you think?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap. org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk >><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap<mailto:mkgmap-dev@list s.mkgmap>. org.uk<http://org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk >>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.or g.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk >><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.or<mailto:mkgmap-dev@lis ts.mkgmap.or> g.uk<http://g.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk >>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.or g.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk >> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.or g.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk >> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
<mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto: mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
-- Felix Hartman - Openmtbmap.org & VeloMap.org
Hi Felix, forget my comment about the combination of precomp-sea and trimming. I refreshed my memory, see http://gis.19327.n8.nabble.com/splitter-r273-with-precomp-sea-parameter-td57... I think I know now what's going wrong with splitter. Gerd ________________________________________ Von: Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Samstag, 12. Juni 2021 11:19 An: Development list for mkgmap Betreff: AW: [mkgmap-dev] Proof of concept for better sea in overview map Hi Felix, I don't remember exactly why the --precom-sea option was added to splitter, but I think it makes no sense to use that option in combination with trimming. What's your reason to use this combination? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Samstag, 12. Juni 2021 10:30 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map Hi Felix, r602 and r604 should do the same. looking at the splitter log I see Exact map coverage read from input file(s) is (-57.16482639312744,44.65547561645508) to (26.46477699279785,179.99469995498657) Rounded map coverage is (-57.1728515625,44.6484375) to (26.4990234375,180.0) This covers parts of India and Africa, but for sure not Mexico. I assume that your australia-oceania.areas.list was not produced with a file downloaded from geofabrik, maybe you updated it with a bad tool? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver@gmail.com> Gesendet: Samstag, 12. Juni 2021 10:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map I`m still using splitter 602. I did not know 604 would behave differently - I will try it out because those tiny tiles without much information in australia-oceana are not that helpful. But the problem is not directly related to the version. Those gaps have been there a long time (well and the 4 missing/empty) tiles did not happen before using --improve-overview. As this surely is somehow related - and fits in the topic of improving the overview map - great that you are looking for a solution. Well everywhere on my screenshot where you see something red - (national border - I think level2) there is some content. That australia-oceana map has some parts of data kinda anywhere... Trimming the sea on one hand is nice - because the sea/land area using --precomp-sea is a bit confusing too - as when you zoom into some areas - they will not contain data. But I think that is less of a problem then the gaps - and it should be clear an australia-oceania map does not have detailed map data of Asia... On Sat, 12 Jun 2021 at 11:03, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi Felix, I've just used splitter r604 with a freshly downloaded sea.zip and australia-oceania-latest.osm.pbf and your options and I get a completely different areas.list with only 88 tiles, but it also has gaps. They disappear when I remove the --precomp-sea option, so that's one big difference to my test environment. No idea why you get 274 tiles, and they cover a completely different area, even parts of Mexico. I try to find out why splitter creates those gaps now... Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com>> Gesendet: Samstag, 12. Juni 2021 09:34 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map highlighted = pink. maybe that confused you. I should have explained better. But in general ll those gaps should not be there. On Sat, 12 Jun 2021 at 10:31, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> wrote: I use C:\openmtbmap\osmconvert.exe --drop-author --drop-version D:\openmtbmap\osmpbf_geofabrik\australia-oceania-latest.osm.pbf -o=C:\openmtbmap\osmpbf_geofabrik\australia-oceania.o5m then start /low /b /wait java -XX:+AggressiveHeap -Xms15000m -Xmx54000m -jar C:\openmtbmap\splitter.jar "--precomp-sea=C:\openmtbmap\maps\sea.zip" --max-nodes=1000000 --max-threads=8 --output=pbf "--keep-complete" --route-rel-values=mtb,bicycle,foot,hiking --max-areas=4000 --geonames-file=C:\OpenMTBMap\maps\cities5000.zip --description=australia-oceania --mapid=65340000 C:\openmtbmap\osmpbf_geofabrik\australia-oceania.o5m The highlighted tiles selected in Mapsource for sending to GPS device - are empty using improve-overview - but they are filled with sea without using it. They are only empty in overview map. I think those gaps also should not be there - so it is a wider problem that existed before already. For overview map mkgmap should use all the sea/land area for the full coverage - and not cut out areas. Actually cutting for sea/land should also not happen in the normal map. The reason for trimming is to have to maps not overlap itself with empty content - because mkgmap/splitter only cuts rectangles - not polygons. But sea/land will be identical in two country maps - so should not be trimmed On Sat, 12 Jun 2021 at 10:24, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> wrote: the problem is - using improve-overview some tiles in the overview map miss sea. I am pretty sure this happens on default style too. But likely not if you use --no-trim and / or keep-complete for splitting. Attached is the areas.list On Sat, 12 Jun 2021 at 09:40, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>> wrote: Hi Felix, I don't yet understand what's going on. Please provide a link to your areas.list Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>> Gesendet: Freitag, 11. Juni 2021 12:14 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map Nope - that did not help. And I think the problem is a bit unrelated. Mkgmap with your new version and --improve-overview assumes there is an empty map - and puts those three square areas of missing anything. Maybe you give it a try and analyse what happens. I actually think this bug has been there before already - and it happened to me with contourlines only maps. Meaning mkgmap cuts the map area way too aggressively, and removes part of the map that actually even have content - or was it splitter. I think for contourlines only maps I had to use splitter with --keep-complete and --no-trim else there would be missing. areas in the map. (not on the outside but right in the middle in the ocean usually - but sometimes also e.g. northernmost parts of Norway in an Europe contourlines only map). So I split australia-oceania WITHOUT --no-trim. Are you assuming to split with --no-trim? Actually those grey boxes are each of its own separate tiles (with nearly no content - e.g. one has a riff polygon only). I guess there is lots of openseamap stuff so splitter creates those tiny tiles... Mkgmap should never trip on the overview map. The normal map should be trimmed aggressively - as we still cannot cut according to a bounding polygon and only using rectangles. But the overview map sea creation should not cut out sea or anything. I guess you never noticed that working on Norway - but it would be a good start to play around with australia-oceania (it is nice to work with - because it is relatively small in size so compiles fast). See attached screenshot of overview map. All the selected tiles were before showing sea (and do so once past the overview map too). The high DP filter was not the problem. For Australia-Oceania the --improve-overview right now is not a good example. The map was better before. Oh yeah - and --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20 looks better than small values. Actually I think even to rather increase more. Maybe that is why I had less problems right from the start - because I cut away tiny islands. C:\openmtbmap\maps>if yes NEQ no start /low /b /wait java -jar -XX:+AggressiveHeap -XX:StringTableSize=1000003 -Xms15000M -Xmx29000M C:\openmtbmap\mkgmap.jar --max-jobs=8 --order-by-decreasing-area "--generate-sea" --code-page=1252 "--precomp-sea=C:\openmtbmap\maps\sea.zip" "--style-file=C:\openmtbmap\openmtbmap_style" --improve-overview --add-boundary-nodes-at-admin-boundaries --drive-on=detect --allow-reverse-merge --line-types-with-direction=0x18,0x1f,0x10016,0x10101,0x10105,0x10401,0x10403,0x10405,0x10408,0x10409,0x1040b,0x1040d,0x1040e,0x10500,0x10501,0x10502,0x10503,0x10504,0x10505,0x10506,0x10507,0x10607,0x10609,0x1060b,0x10702,0x10703,0x10704,0x10705,0x10706,0x10707,0x10a00,0x10a02,0x10a04,0x10a05,0x10e1e,0x10e0f,0x10e0e,0x10e1e,0x10f0a,0x10f1c,0x10e1d --nsis --index --levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18" --overview-levels="7:17, 8:16, 9:15, 10:14, 11:13, 12:12" --add-pois-to-areas --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier= entrance --x-simplify-filter-line-errors=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,17:6,14:6 --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9,17:2.6 --add-boundary-nodes-at-admin-boundaries=2 --poi-excl-index=0x6405,0x4316,0x2f00 --copyright-file="C:\openmtbmap\openmtbmap_svn\copyrightopm.txt" --license-file="C:\openmtbmap\openmtbmap_svn\licenseopm.txt" --cycle-map --ignore-fixme-values --housenumbers --road-name-config=C:\openmtbmap\openmtbmap_svn\roadNameConfig.txt --split-name-index --link-pois-to-ways --ignore-turn-restrictions --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20" --description=omtb_auo --show-profiles=1 --location-autofill=bounds,is_in,nearest --bounds=C:\openmtbmap\maps\bounds.zip --mdr7-del=pri;sec;ter;cw;min;unsf,uncl;living;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1 .;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;bridge;swing;aqueduct;viaduct;"ntnl bndry";admin_lv=4;"ntnl park";weir;dam;waterfall;rapids;stream;river;drain;ditch;"huge river";"hugest river";"medium river";"small river";"wide river";"hugest canal";"huge canal";"medium canal";"small canal";"big canal";canal;snowpark;Skitour-descent;Skipiste;Skislope;illuminated;Nordic-Skiing;skitour ;platter;ropetow;tbar;chairlift;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath --mdr7-excl=pri;sec;ter;cw;min;unsf,uncl;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1.;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx 4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;"ntnl bndry";admin_lv=4;"ntnl park";"huge river";"hugest river";"medium river";"small river";"wide river";"hugest canal";"huge canal";"medium canal";"small canal";"big canal";canal;snowpark;Skitour-descent;illuminated;Nordic-Skiing;skitour;platter;ropetow;tbar;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath --route --country-abbr=auo --country-name=australia-oceania --mapname=65340000 --family-id=6534 --product-id=1 --series-name=omtb_australia-oceania_11.06.2021 --family-name=mtb_auo_11.06.2021 --tdbfile --gmapi --overview-mapname=mapsetc --keep-going --area-name="australia-oceania_11.06.2021_omtb" -c D:\openmtbmap\maps\template.australia-oceania C:\OpenMTBMap\contourlines20\australia-oceania\7*.img typauo.TYP On Fri, 11 Jun 2021 at 12:25, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> wrote: yes I was using: --x-simplify-filter-line-errors=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,16:8,14:9 --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9 --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20, 17:20, 16:20, 15:20, 14:20, 13:20, 12:20, 11:20, 10:20" levels = 0:24, 1:22, 2:21, 3:20, 4:19, 5:18 overview-levels = 6:17, 7:16, 8:15, 9:14, 10:13 As this only affects the overview map - I guess I should change it to: --x-simplify-filter-polygon-errors=23:3.6,22:7,21:6,20:9,17:2.6 ?? The polygon-size-limits should not matter as I have the skip-size filter set for sea. I had worked quite a long time to optimize those settings with the old behaviour. On Fri, 11 Jun 2021 at 11:50, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>> wrote: Hi Felix, Maybe you are using large values for the Douglas-Peucker filter at low resolutions? That's probably a bad idea with the new option. I always tested with the default 2.6 for all levels. The effect of the new option is that DP really can do its work. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>> Gesendet: Freitag, 11. Juni 2021 10:23 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map --generate-sea --precomp-sea=C:\openmtbmap\maps\sea.zip --order-by-decreasing-area --allow-reverse-merge I thought using precomp-sea is fine (I did not update the precomp-sea in between) On Fri, 11 Jun 2021 at 11:10, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>>> wrote: compilation time includes splitting, and some other stuff. Loads of countries (9:34 / 9:21 (sorry dumb error 9:19) for all european single countries and a few continents (but not Europe continent) in hours. On Fri, 11 Jun 2021 at 11:08, Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>>> wrote: I just compiled the australia-oceania map with that option, and I think I must be missing something. It got substantially worse (it is identical until the overview map kicks in) - then I get some huge squares of sea missing. Compile time for all maps until that point before Compilation time is not up a lot: 0:12 - 9:46 = 9:34 one week before (except older mapdata no changes in compilation procedure and older mkgmap) 20:17 - 5:38 = 9:19 Anything I could be missing? I use the newest low-res branch build and added --improve-overview to the compilation process. in my polygons file I have: natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=2 } [0x10f1d resolution 10] On Fri, 11 Jun 2021 at 07:12, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>> wrote: Hi all, I hoped for some positive feedback on this but got none so far. Did I miss something important? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpeterm ann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>> Gesendet: Montag, 7. Juni 2021 21:05 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map Hi Felix, the map contained was without routing or index, so for a normal map the difference should be even smaller. There is no need to change sea.zip. You just have to use --improve-overview for now. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@g mail.com<mailto:extremecarver@gmail.com>>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>>> Gesendet: Montag, 7. Juni 2021 21:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map I guess that is a time for a full Norway map based on default style - so that is quite okay. Not a sea only Norway map... Well I hope that Thorsten Kukuk can adapt his sea files in the near future then... On Mon, 7 Jun 2021 at 19:37, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><ma ilto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>>> wrote: OK, I think found a good solution. Speed is quite OK, I see 9 min 48 secs for map of norway and instead of 8 min 44 secs with r4756, and I consider Norway to be a worst case. See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4761 for the details. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mail to:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>>> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpeterm<mailto:gpeterm> ann_muenchen@hotmail.com<mailto:ann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>>>>> Gesendet: Montag, 7. Juni 2021 12:11 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map With the provided patch the speed is very poor for areas like Norway, probably twice the time. It is much slower because it does the complex multipolygon cutting for each level in the overview map. Probably too slow for complex coastal areas. This time will be the same for precomp-sea unless we can store sea polygons for each resolution. Performance will be no problem if I find a way to use Douglas-Peucker or similar before cutting. That was my original idea but DP produces self intersecting polygons and the MultipolygonCutter cannot cope with that. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mail to:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>>>>> im Auftrag von Felix Hartmann <extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@g<mailto:extremecarver@g> mail.com<http://mail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com><mailto:extremecarver@gmail.com<mailto:extremecarver@gmail.com>>>>>> Gesendet: Montag, 7. Juni 2021 11:55 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map Is it only much slower because of not using precomp sea? Or will it be much slower in general? And what is much slower for say Europe continent map? If a modern 4core/8thread processor needs 30 minutes more I would prefer the old way knowing it is worse (if the time difference is negligible with precomp-sea then that would be great). On Mon, 7 Jun 2021 at 12:26, Ticker Berkin <rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailt o:rwb-mkgmap@jagit.co.uk>>>>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>><mailto:rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailt o:rwb-mkgmap@jagit.co.uk<mailto:o%3Arwb-mkgmap@jagit.co.uk>>>>>>> wrote: Hi Gerd This is going to take some studying to work out the implications. Can't do much for the next few days however, but will look carefully at the end of the week. Ticker On Sun, 2021-06-06 at 14:02 +0000, Gerd Petermann wrote:
Hi,
the attached patch improves the overview map, but so far only when precomp-sea is NOT used. I tested it with --generate-sea=multipolygon,floodblocker so that mkgmap really has a multipolygon with the natual=sea data.
For each level in the overview map it uses the original multipolygon data to compute the rings which will might visible at the given resolution. This requires more time compared to the current code but the result is much better and some fine tuning is possible.
To be able to use this also with --precomp-sea we need some changes in the code which generates sea.zip so that one multipolygon relation for each tile is stored.
I've uploaded the results here: https://files.mkgmap.org.uk/download/511/compare.7z What do you think?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap. org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap<mailto:mkgmap-dev@list s.mkgmap>. org.uk<http://org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.or g.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.or<mailto:mkgmap-dev@lis ts.mkgmap.or> g.uk<http://g.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.or g.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.or g.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Felix Hartman - Openmtbmap.org & VeloMap.org _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd I'm having trouble building GB with low-res-opt (+updated shapeSplitter), my style and options getting this error: Exception in thread "main" java.lang.AssertionError at uk.me.parabola.mkgmap.filters.ShapeMergeFilter.addWithConnectedHoles(Sh apeMergeFilter.java:352) at uk.me.parabola.mkgmap.filters.ShapeMergeFilter.tryMerge(ShapeMergeFilte r.java:252) at uk.me.parabola.mkgmap.filters.ShapeMergeFilter.mergeSimilar(ShapeMergeF ilter.java:147) at uk.me.parabola.mkgmap.filters.ShapeMergeFilter.merge(ShapeMergeFilter.j ava:99) at uk.me.parabola.mkgmap.build.MapBuilder.makeSubdivision(MapBuilder.java: 940) at uk.me.parabola.mkgmap.build.MapBuilder.makeMapAreas(MapBuilder.java:838 ) at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:333) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:114) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:70) at uk.me.parabola.mkgmap.main.Main.lambda$processFilename$1(Main.java:290) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.ja va:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.j ava:617) at java.lang.Thread.run(Thread.java:745) and quite a few tiles empty, but the matching ovm_ are generated. I'll try and reproduce in simpler environment. Ticker
Hi Gerd I've found this problem - a very flat polygon became a line. Ticker On Fri, 2021-06-11 at 10:33 +0100, Ticker Berkin wrote:
Hi Gerd
I'm having trouble building GB with low-res-opt (+updated shapeSplitter), my style and options
getting this error:
Exception in thread "main" java.lang.AssertionError at uk.me.parabola.mkgmap.filters.ShapeMergeFilter.addWithConnectedHoles( Sh apeMergeFilter.java:352) at uk.me.parabola.mkgmap.filters.ShapeMergeFilter.tryMerge(ShapeMergeFil te r.java:252) at uk.me.parabola.mkgmap.filters.ShapeMergeFilter.mergeSimilar(ShapeMerg eF ilter.java:147) at uk.me.parabola.mkgmap.filters.ShapeMergeFilter.merge(ShapeMergeFilter .j ava:99) at uk.me.parabola.mkgmap.build.MapBuilder.makeSubdivision(MapBuilder.jav a: 940) at uk.me.parabola.mkgmap.build.MapBuilder.makeMapAreas(MapBuilder.java:8 38 ) at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:333) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:114) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:70) at uk.me.parabola.mkgmap.main.Main.lambda$processFilename$1(Main.java:29 0) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor. ja va:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor .j ava:617) at java.lang.Thread.run(Thread.java:745)
and quite a few tiles empty, but the matching ovm_ are generated.
I'll try and reproduce in simpler environment.
Ticker
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ticker, yes, that's what I guessed. Where does it go wrong? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 11. Juni 2021 15:47 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map Hi Gerd I've found this problem - a very flat polygon became a line. Ticker On Fri, 2021-06-11 at 10:33 +0100, Ticker Berkin wrote:
Hi Gerd
I'm having trouble building GB with low-res-opt (+updated shapeSplitter), my style and options
getting this error:
Exception in thread "main" java.lang.AssertionError at uk.me.parabola.mkgmap.filters.ShapeMergeFilter.addWithConnectedHoles( Sh apeMergeFilter.java:352) at uk.me.parabola.mkgmap.filters.ShapeMergeFilter.tryMerge(ShapeMergeFil te r.java:252) at uk.me.parabola.mkgmap.filters.ShapeMergeFilter.mergeSimilar(ShapeMerg eF ilter.java:147) at uk.me.parabola.mkgmap.filters.ShapeMergeFilter.merge(ShapeMergeFilter .j ava:99) at uk.me.parabola.mkgmap.build.MapBuilder.makeSubdivision(MapBuilder.jav a: 940) at uk.me.parabola.mkgmap.build.MapBuilder.makeMapAreas(MapBuilder.java:8 38 ) at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:333) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:114) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:70) at uk.me.parabola.mkgmap.main.Main.lambda$processFilename$1(Main.java:29 0) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor. ja va:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor .j ava:617) at java.lang.Thread.run(Thread.java:745)
and quite a few tiles empty, but the matching ovm_ are generated.
I'll try and reproduce in simpler environment.
Ticker
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd Testing when two ends of a shape are close enough together on the split line that the last point can be replaced by the first to be the closing point. Ticker On Fri, 2021-06-11 at 13:48 +0000, Gerd Petermann wrote:
Hi Ticker,
yes, that's what I guessed. Where does it go wrong?
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 11. Juni 2021 15:47 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Proof of concept for better sea in overview map
Hi Gerd
I've found this problem - a very flat polygon became a line.
Ticker
On Fri, 2021-06-11 at 10:33 +0100, Ticker Berkin wrote:
Hi Gerd
I'm having trouble building GB with low-res-opt (+updated shapeSplitter), my style and options
getting this error:
Exception in thread "main" java.lang.AssertionError at uk.me.parabola.mkgmap.filters.ShapeMergeFilter.addWithConnectedHole s( Sh apeMergeFilter.java:352) at uk.me.parabola.mkgmap.filters.ShapeMergeFilter.tryMerge(ShapeMergeF il te r.java:252) at uk.me.parabola.mkgmap.filters.ShapeMergeFilter.mergeSimilar(ShapeMe rg eF ilter.java:147) at uk.me.parabola.mkgmap.filters.ShapeMergeFilter.merge(ShapeMergeFilt er .j ava:99) at uk.me.parabola.mkgmap.build.MapBuilder.makeSubdivision(MapBuilder.j av a: 940) at uk.me.parabola.mkgmap.build.MapBuilder.makeMapAreas(MapBuilder.java :8 38 ) at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:333) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:114) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:70) at uk.me.parabola.mkgmap.main.Main.lambda$processFilename$1(Main.java: 29 0) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecuto r. ja va:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecut or .j ava:617) at java.lang.Thread.run(Thread.java:745)
and quite a few tiles empty, but the matching ovm_ are generated.
I'll try and reproduce in simpler environment.
Ticker
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (4)
-
Felix Hartmann -
Gerd Petermann -
Gerd Petermann
-
Ticker Berkin