Hi Vuki, flooded lakes are typically caused by incomplete multipolygons. Another reason can be that the OSM data itself is wrong. Do you use splitter with the keep-complete option enabled? Best way to verify is to load a tile that contains a part of the lake in JOSM (use the pbf or o5m plugin). If JOSM shows a problem than mkgmap cannot be blamed. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Vuki <vuki77@gmail.com> Gesendet: Dienstag, 20. Oktober 2020 11:17 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: [mkgmap-dev] Polygon fill Hello Guys, I am brewing custom maps for my Garmin zumo 396. - get the OSM data from the overpass api (0.5 by 0.5 degree bounding box) - use splitter to split too large parts - use mkgmap to build the maps. The generated garmin maps have wrong filled polygons, lakes are filled with land and vice versa. Here are two examples (lake Balatom and lake Geneva) http://www.informatik.hu/balaton.jpg http://www.informatik.hu/geneva.jpg When I download the lake Balaton in one bounding box the artefacts are disappearing, thus there must be something merging the files. I have tried various mkgmap settings but could not solve the issues. Curret config is: levels: 0:24, 1:22, 2:20, 3:18, 4:16, 5:14, 6:12, 7:10 add-pois-to-areas add-pois-to-lines adjust-turn-headings bounds: ../bounds-latest.zip check-roundabout-flares check-roundabouts copyright-message: Map data © Openstreetmap.org drive-on=detect,right generate-sea: land-tag=natural=background gmapi gmapsupp housenumbers ignore-maxspeeds index keep-going latin1 link-pois-to-ways location-autofill: is_in,nearest make-opposite-cycleways merge-lines name-tag-list: int_name,name:en,name:hu,name,place_name #nsis order-by-decreasing-area precomp-sea: ../sea-latest.zip preserve-element-order process-destination process-exits reduce-point-density-polygon=8 reduce-point-density=3 remove-ovm-work-files remove-short-arcs road-name-pois route # show-profiles: 1 style-file: ../styles style: default tdbfile x-split-name-index verbose Do you have any ideas what can cause the issue? -- Br, Vuki
Hi Vuki, the question is if the multipolygon for the lake is complete. Your screen shot shows an imcomplete area. Check relation 1638031. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Vuki <vuki77@gmail.com> Gesendet: Dienstag, 20. Oktober 2020 20:38 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Polygon fill Hi Gerd, the OSM comes directly from overpass API, this is small enough not to split. It also looks good for me. 18.00x46.50 by 18.50x47.00 The arifact is somehow connected to the bounding box borders? Example: http://www.informatik.hu/balaton2.jpg Köszi: Vuki On 2020.10.20. 11:32, Gerd Petermann wrote: Hi Vuki, flooded lakes are typically caused by incomplete multipolygons. Another reason can be that the OSM data itself is wrong. Do you use splitter with the keep-complete option enabled? Best way to verify is to load a tile that contains a part of the lake in JOSM (use the pbf or o5m plugin). If JOSM shows a problem than mkgmap cannot be blamed. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Vuki <vuki77@gmail.com><mailto:vuki77@gmail.com> Gesendet: Dienstag, 20. Oktober 2020 11:17 An: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> Betreff: [mkgmap-dev] Polygon fill Hello Guys, I am brewing custom maps for my Garmin zumo 396. - get the OSM data from the overpass api (0.5 by 0.5 degree bounding box) - use splitter to split too large parts - use mkgmap to build the maps. The generated garmin maps have wrong filled polygons, lakes are filled with land and vice versa. Here are two examples (lake Balatom and lake Geneva) http://www.informatik.hu/balaton.jpg http://www.informatik.hu/geneva.jpg When I download the lake Balaton in one bounding box the artefacts are disappearing, thus there must be something merging the files. I have tried various mkgmap settings but could not solve the issues. Curret config is: levels: 0:24, 1:22, 2:20, 3:18, 4:16, 5:14, 6:12, 7:10 add-pois-to-areas add-pois-to-lines adjust-turn-headings bounds: ../bounds-latest.zip check-roundabout-flares check-roundabouts copyright-message: Map data © Openstreetmap.org drive-on=detect,right generate-sea: land-tag=natural=background gmapi gmapsupp housenumbers ignore-maxspeeds index keep-going latin1 link-pois-to-ways location-autofill: is_in,nearest make-opposite-cycleways merge-lines name-tag-list: int_name,name:en,name:hu,name,place_name #nsis order-by-decreasing-area precomp-sea: ../sea-latest.zip preserve-element-order process-destination process-exits reduce-point-density-polygon=8 reduce-point-density=3 remove-ovm-work-files remove-short-arcs road-name-pois route # show-profiles: 1 style-file: ../styles style: default tdbfile x-split-name-index verbose Do you have any ideas what can cause the issue? -- Br, Vuki _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi. I noted a similar thing with Sweden (Stockholm area) where the sea floods the land. The only change that i recall i have made is to update the sea data file. Earlier i had one from the beginning of october, and only one or two days ago (18'th or 19th of october) i updated the sea file. The map data was not updated so i don't think i have introduced other issues. i went back to an earlier version of the sea file http://osm.thkukuk.de/data/ sea-20200921001501.zip This at least resolved my issue. It's hard to say if your problem is identical, but you may want to try. Karl On tisdag 20 oktober 2020 kl. 11:17:14 CEST Vuki wrote:
Hello Guys,
I am brewing custom maps for my Garmin zumo 396.
- get the OSM data from the overpass api (0.5 by 0.5 degree bounding box) - use splitter to split too large parts - use mkgmap to build the maps.
The generated garmin maps have wrong filled polygons, lakes are filled with land and vice versa. Here are two examples (lake Balatom and lake Geneva)
http://www.informatik.hu/balaton.jpg http://www.informatik.hu/geneva.jpg
When I download the lake Balaton in one bounding box the artefacts are disappearing, thus there must be something merging the files. I have tried various mkgmap settings but could not solve the issues. Curret config is:
levels: 0:24, 1:22, 2:20, 3:18, 4:16, 5:14, 6:12, 7:10 add-pois-to-areas add-pois-to-lines adjust-turn-headings bounds: ../bounds-latest.zip check-roundabout-flares check-roundabouts copyright-message: Map data © Openstreetmap.org drive-on=detect,right generate-sea: land-tag=natural=background gmapi gmapsupp housenumbers ignore-maxspeeds index keep-going latin1 link-pois-to-ways location-autofill: is_in,nearest make-opposite-cycleways merge-lines name-tag-list: int_name,name:en,name:hu,name,place_name #nsis order-by-decreasing-area precomp-sea: ../sea-latest.zip preserve-element-order process-destination process-exits reduce-point-density-polygon=8 reduce-point-density=3 remove-ovm-work-files remove-short-arcs road-name-pois route # show-profiles: 1 style-file: ../styles style: default tdbfile x-split-name-index verbose
Do you have any ideas what can cause the issue?
Hi Karl, not related. These lakes are not handled by the precomp-sea data. You are right whenever the problem is related to coastline data. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von 7770 <7770@foskan.eu> Gesendet: Dienstag, 20. Oktober 2020 13:30 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Polygon fill Hi. I noted a similar thing with Sweden (Stockholm area) where the sea floods the land. The only change that i recall i have made is to update the sea data file. Earlier i had one from the beginning of october, and only one or two days ago (18'th or 19th of october) i updated the sea file. The map data was not updated so i don't think i have introduced other issues. i went back to an earlier version of the sea file http://osm.thkukuk.de/data/ sea-20200921001501.zip This at least resolved my issue. It's hard to say if your problem is identical, but you may want to try. Karl On tisdag 20 oktober 2020 kl. 11:17:14 CEST Vuki wrote:
Hello Guys,
I am brewing custom maps for my Garmin zumo 396.
- get the OSM data from the overpass api (0.5 by 0.5 degree bounding box) - use splitter to split too large parts - use mkgmap to build the maps.
The generated garmin maps have wrong filled polygons, lakes are filled with land and vice versa. Here are two examples (lake Balatom and lake Geneva)
http://www.informatik.hu/balaton.jpg http://www.informatik.hu/geneva.jpg
When I download the lake Balaton in one bounding box the artefacts are disappearing, thus there must be something merging the files. I have tried various mkgmap settings but could not solve the issues. Curret config is:
levels: 0:24, 1:22, 2:20, 3:18, 4:16, 5:14, 6:12, 7:10 add-pois-to-areas add-pois-to-lines adjust-turn-headings bounds: ../bounds-latest.zip check-roundabout-flares check-roundabouts copyright-message: Map data © Openstreetmap.org drive-on=detect,right generate-sea: land-tag=natural=background gmapi gmapsupp housenumbers ignore-maxspeeds index keep-going latin1 link-pois-to-ways location-autofill: is_in,nearest make-opposite-cycleways merge-lines name-tag-list: int_name,name:en,name:hu,name,place_name #nsis order-by-decreasing-area precomp-sea: ../sea-latest.zip preserve-element-order process-destination process-exits reduce-point-density-polygon=8 reduce-point-density=3 remove-ovm-work-files remove-short-arcs road-name-pois route # show-profiles: 1 style-file: ../styles style: default tdbfile x-split-name-index verbose
Do you have any ideas what can cause the issue?
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Vuki Various possibilities / questions: Do you do anything particular with natural=background in your style. The default is natural=land and the default style doesn't need to generate anything for it because the device default background isn't sea. Do you have a typ file? Does it assign assign a hierarchy of [_drawOrder] levels to the different types of polygons. With --order-by-decreasing-area, it is assumed that you give everything except the background (0x4a/0x4b) the same value and that the device renders polygons in the the order they appear in the .img file. It is possible that your device doesn't do this. In your examples, I only see parts of lakes not showing as water. As far as I'm aware, these are not represented with coastline and sea processing. They should have natural=water tags and generate standard blue polygons (maybe 0x3c). It is possible that the resolution these lakes appear at is too high, but this is unlikely because it is showing the rivers within the lake. Regards Ticker On Tue, 2020-10-20 at 11:17 +0200, Vuki wrote:
Hello Guys, I am brewing custom maps for my Garmin zumo 396. - get the OSM data from the overpass api (0.5 by 0.5 degree bounding box) - use splitter to split too large parts - use mkgmap to build the maps. The generated garmin maps have wrong filled polygons, lakes are filled with land and vice versa. Here are two examples (lake Balatom and lake Geneva) http://www.informatik.hu/balaton.jpg http://www.informatik.hu/geneva.jpg When I download the lake Balaton in one bounding box the artefacts are disappearing, thus there must be something merging the files. I have tried various mkgmap settings but could not solve the issues. Curret config is: levels: 0:24, 1:22, 2:20, 3:18, 4:16, 5:14, 6:12, 7:10 add-pois-to-areas add-pois-to-lines adjust-turn-headings bounds: ../bounds-latest.zip check-roundabout-flares check-roundabouts copyright-message: Map data © Openstreetmap.org drive-on=detect,right generate-sea: land-tag=natural=background gmapi gmapsupp housenumbers ignore-maxspeeds index keep-going latin1 link-pois-to-ways location-autofill: is_in,nearest make-opposite-cycleways merge-lines name-tag-list: int_name,name:en,name:hu,name,place_name #nsis order-by-decreasing-area precomp-sea: ../sea-latest.zip preserve-element-order process-destination process-exits reduce-point-density-polygon=8 reduce-point-density=3 remove-ovm-work-files remove-short-arcs road-name-pois route # show-profiles: 1 style-file: ../styles style: default tdbfile x-split-name-index verbose Do you have any ideas what can cause the issue?
-- Br, Vuki
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Vuki Looking at OSM, the latest change for one of your problem areas is: Relation: Lake Geneva (332617) Version #235 Trying to fix the lake (4) Edited 12 days ago by MFlamm Changeset #92217016 So most likely you've picked up an incorrect polygon. Probably unrelated are my comments about --order-by-decreasing-area and TYP file [_drawOrder]. Having different [_drawOrder] levels will negate the effect of the option; it needs them all to be the same. Without a TYP file most are the same for devices I've encountered - see distribution file mkgmap-rNNNN/examples/typ-files/sameOrder.txt Ticker
Hi Vuki, a general comment regarding the use of overpass in batch for mkgmap input: If you do this only once for a single small tile that's OK. If you do it in a loop to produce multiple tiles you risk to download different versions of the same object in different tiles. Think of a situation where a mapper uploads a move of node of a longer road while your batch program is downloading. You see all kinds of weired effects when this happens, from visual distortion to bad routing. So, for a large map with many tiles this is a bad idea. The extracts from e.g. http://download.geofabrik.de/ are the better choice for this. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Dienstag, 20. Oktober 2020 23:56 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Polygon fill Hi Vuki Looking at OSM, the latest change for one of your problem areas is: Relation: Lake Geneva (332617) Version #235 Trying to fix the lake (4) Edited 12 days ago by MFlamm Changeset #92217016 So most likely you've picked up an incorrect polygon. Probably unrelated are my comments about --order-by-decreasing-area and TYP file [_drawOrder]. Having different [_drawOrder] levels will negate the effect of the option; it needs them all to be the same. Without a TYP file most are the same for devices I've encountered - see distribution file mkgmap-rNNNN/examples/typ-files/sameOrder.txt Ticker _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (4)
-
7770 -
Gerd Petermann -
Ticker Berkin -
Vuki