Re: [mkgmap-dev] Flooded islands
Hi Karl, I suspect the reason is that Eckerö and other smaller islands are not included in the MP Gulf of Bothnia with an inner role, the MP is a bay, Fasta Åland is included with role inner. This would mean that the bay will technically over lay the islands, apart from Fasta Åland, they would be submerged. I presume on the GPS unit the islands are showing because the order-by-decreasing-area option has been used so the smaller islands are rendered on top of the bay Regards, Dave -Original Message- From: mkgmap-dev On Behalf Of 7770 Sent: 14 March 2021 21:28 To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] Flooded islands Hi. I noted that many of the islands in the Åland archipalago (between Sweden and Finland) are flooded. On a GPS unit (gpsmap 66st) the land looks like land, but when howering the pointer over the area it shows the name of the sea, not the name if the island. In qmapshack the islands look flooded. I checked one of the islands (Eckerö, which is westernmost) in JOSM, i could not find any disconnected section nor any self crossing lines or similar issues. I do use the pre-made sea data when i run mkgmap. I also tried running without the pre-made sea data, but it did not change the flooding of these islands. Two screenshots from qmapshack added to the file upload: http://files.mkgmap.org.uk/detail/503 http://files.mkgmap.org.uk/detail/504 What could be the reason for the flooding? regards Karl ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Flooded islands
Hi. I noted that many of the islands in the Åland archipalago (between Sweden and Finland) are flooded. On a GPS unit (gpsmap 66st) the land looks like land, but when howering the pointer over the area it shows the name of the sea, not the name if the island. In qmapshack the islands look flooded. I checked one of the islands (Eckerö, which is westernmost) in JOSM, i could not find any disconnected section nor any self crossing lines or similar issues. I do use the pre-made sea data when i run mkgmap. I also tried running without the pre-made sea data, but it did not change the flooding of these islands. Two screenshots from qmapshack added to the file upload: http://files.mkgmap.org.uk/detail/503 http://files.mkgmap.org.uk/detail/504 What could be the reason for the flooding? regards Karl ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] tile takes very long time to generate
Hi all, I've started a new branch called faster-mp, see http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4609 and the corresponding download link on the bottom of http://www.mkgmap.org.uk/download/mkgmap.html So far I've only started to remove "old-style MP" support. There are still some parts of the code that I don't fullly understand, so I think I have to create a functional unit test next, containing all the special cases like incomplete data , MP which are only partly inside of a tile or covering a complete tile and maybe also incorrect MP which should still be rendered somehow. Gerd Von: mkgmap-dev im Auftrag von Gerd Petermann Gesendet: Sonntag, 14. März 2021 09:47 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] tile takes very long time to generate Hi Ticker, the handling of the inner/outer role is indeed strange. The program calculates the "real" roles first, based on geometry. Later it checks if the given roles from the relation and may ignore the MP if no way has an empty role or role outer. This test should be done first or not at all. I think it is a good idea to calculate the roles based on geometry, for empty roles we need the code for this calculation anyway. I just think that mkgmap shouldn't care too much about invalid geometries when data is complete. I have to think again about those cases where data is not complete. Even with splitter and --keep-complete this can happen, e.g. when the input for splitter already contains incomplete relations. Maybe mkgmap can simply ignore incomplete MP after logging a warning. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Samstag, 13. März 2021 12:21 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] tile takes very long time to generate Hi Gerd I think the extra testing should be removed and the logic should work on the assumption of correct data; just emitting warning/errors when problems are found during the normal processing. It also has extra complexity due to early versions of the splitter not keeping relations/polygons complete. Presumably this can be simplified now. role=inner/outer handling is strange, it looks like it totally ignores it! Going with "assuming correct data", conflicting "inner" and "outer" in a JoinedWay should be flagged, otherwise any "inner" or "outer" should be believed, with all null being considered "outer". Ticker On Sat, 2021-03-13 at 08:32 +, Gerd Petermann wrote: > Hi all, > > most of the time that is needed to process complex multipolygons (MP) > is spent in compex tests which try to detect invalid geometries like > "inner" ring is not inside outer or overlapping /crossing rings. I > wonder if it really makes sense to perform those tests in mkgmap. In > JOSM, the strategy is like this: > The renderer is optimistic and assumes that the geometry is correct, > for invalid geometries "garbage in -> garbage out" is used. The > validator performs a lot more tests and should find all the special > cases mkgmap is looking for. This test is slow but still much faster > than that in mkgmap (maybe 30 secs in JOSM, many minutes in mkgmap). > If mkgmap finds invalid geometries the behaviour is still rather > unpredictable. I've used JOSM to create some test cases with "inner" > overlapping "outer" and sometimes the inner is completely ignores, > sometimes not. So, I really wonder what all the complex code is > doing. > > I've attached my test file > I am not sure if I should try to improve the test code > 1) to be faster or > 2) to be more predictable or > 3) both 1+2 or > 4) if I should just remove all code that isn't needed to produce good > results with correct data > > Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] tile takes very long time to generate
Hi Ticker, the handling of the inner/outer role is indeed strange. The program calculates the "real" roles first, based on geometry. Later it checks if the given roles from the relation and may ignore the MP if no way has an empty role or role outer. This test should be done first or not at all. I think it is a good idea to calculate the roles based on geometry, for empty roles we need the code for this calculation anyway. I just think that mkgmap shouldn't care too much about invalid geometries when data is complete. I have to think again about those cases where data is not complete. Even with splitter and --keep-complete this can happen, e.g. when the input for splitter already contains incomplete relations. Maybe mkgmap can simply ignore incomplete MP after logging a warning. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Samstag, 13. März 2021 12:21 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] tile takes very long time to generate Hi Gerd I think the extra testing should be removed and the logic should work on the assumption of correct data; just emitting warning/errors when problems are found during the normal processing. It also has extra complexity due to early versions of the splitter not keeping relations/polygons complete. Presumably this can be simplified now. role=inner/outer handling is strange, it looks like it totally ignores it! Going with "assuming correct data", conflicting "inner" and "outer" in a JoinedWay should be flagged, otherwise any "inner" or "outer" should be believed, with all null being considered "outer". Ticker On Sat, 2021-03-13 at 08:32 +, Gerd Petermann wrote: > Hi all, > > most of the time that is needed to process complex multipolygons (MP) > is spent in compex tests which try to detect invalid geometries like > "inner" ring is not inside outer or overlapping /crossing rings. I > wonder if it really makes sense to perform those tests in mkgmap. In > JOSM, the strategy is like this: > The renderer is optimistic and assumes that the geometry is correct, > for invalid geometries "garbage in -> garbage out" is used. The > validator performs a lot more tests and should find all the special > cases mkgmap is looking for. This test is slow but still much faster > than that in mkgmap (maybe 30 secs in JOSM, many minutes in mkgmap). > If mkgmap finds invalid geometries the behaviour is still rather > unpredictable. I've used JOSM to create some test cases with "inner" > overlapping "outer" and sometimes the inner is completely ignores, > sometimes not. So, I really wonder what all the complex code is > doing. > > I've attached my test file > I am not sure if I should try to improve the test code > 1) to be faster or > 2) to be more predictable or > 3) both 1+2 or > 4) if I should just remove all code that isn't needed to produce good > results with correct data > > Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
