problems with rendering of long riverbank (multipolygons)
Recently someone noticed flooding on the openmtbmap in Belgium south of Maastricht: http://forum.gps.nl/viewtopic.php?f=109&t=34597&p=277200#p277200 I have noticed related issues with floodings west of Maastricht on Lambertus' maps and on my own Openfietsmap parts of the same Albertcanal are "dry". Main cause seems a very long multipolygon relation of the Albertcanal: http://www.openstreetmap.org/browse/relation/1424029 On places where the tile borders are crossing this multipolygon mkgmap has problems with rendering (because the ends of the multipolgygon are way outside the tiles). Splitting up the multipolygon in smaller parts in osm seems not the way to solve these rendering problems because I think it's a bug in mkgmap that should be solved here instead of on osm. Any ideas?
On Thu, May 19, 2011 at 10:33:14AM +0200, Minko wrote:
On places where the tile borders are crossing this multipolygon mkgmap has problems with rendering (because the ends of the multipolgygon are way outside the tiles). Splitting up the multipolygon in smaller parts in osm seems not the way to solve these rendering problems because I think it's a bug in mkgmap that should be solved here instead of on osm. Any ideas?
I have understood that it is a splitter problem, not a mkgmap problem. I do not know the splitter. How many nodes are there along the multipolygon lines? Any nodes relatively near to the tile border? In Finland, I had a similar problem with Lake Päijänne, which is a single huge multipolygon. I have worked around this problem by moving my tile borders so that they do not cut through the lake. Best regards, Marko
I haven't count them ;-) The multipoolygon stretches out on my map along three tiles (roughly 100km wide). Since this area is mapped quite well, moving the tiles wont help. And I'm talking about different maps that shows issues there (with different tiles) so I think it can only be solved by improving the splitter? Marko wrote: I have understood that it is a splitter problem, not a mkgmap problem. I do not know the splitter. How many nodes are there along the multipolygon lines? Any nodes relatively near to the tile border? In Finland, I had a similar problem with Lake Päijänne, which is a single huge multipolygon. I have worked around this problem by moving my tile borders so that they do not cut through the lake. Best regards, Marko
On Thu, May 19, 2011 at 01:57:43PM +0200, Minko wrote:
I haven't count them ;-) The multipoolygon stretches out on my map along three tiles (roughly 100km wide). Since this area is mapped quite well, moving the tiles wont help. And I'm talking about different maps that shows issues there (with different tiles) so I think it can only be solved by improving the splitter?
From past discussions I have understood that there is a configureable "split radius" in the splitter. The splitter would include all nodes and ways within the tile, and near the tile borders within the split radius. Again, as far as I understand, what it really should do is close closed polygons along the tile borders, by adding imaginary nodes at the tile border. Marko
How do I configure this split radius? I have examined the nodes close to the tile borders, they are within 500 m outside of the tile borders. I have splitted my maps with an overlap=3000.
Am 19.05.2011 16:43, schrieb Minko:
How do I configure this split radius? I have examined the nodes close to the tile borders, they are within 500 m outside of the tile borders. I have splitted my maps with an overlap=3000. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi --overlap is the parameter, which influence the split radius. But this wont help you solving your problem. I also think, that this problem have to be fixed in the splitter. E.g. process MP and other huge polygons in splitter and not in mkgmap. splitter should have all needed information. Another solution would be to keep all nodes and ways inside one tile, which belong to an objekte which has at least one node in the area. Henning
Recently someone noticed flooding on the openmtbmap in Belgium south of Maastricht: http://forum.gps.nl/viewtopic.php?f=109&t=34597&p=277200#p277200
I have noticed related issues with floodings west of Maastricht on Lambertus' maps and on my own Openfietsmap parts of the same Albertcanal are "dry". Main cause seems a very long multipolygon relation of the Albertcanal: http://www.openstreetmap.org/browse/relation/1424029
On places where the tile borders are crossing this multipolygon mkgmap has problems with rendering (because the ends of the multipolgygon are way outside the tiles). Splitting up the multipolygon in smaller parts in osm seems not the way to solve these rendering problems because I think it's a bug in mkgmap that should be solved here instead of on osm. Any ideas?
If you assume that the multipolygon algorithm has a problem you should change the log level of the Multipolygon class: uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation.level=FINE Enabling the logging is described at http://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging You can search the logfiles for the relation id and check what the multipolygon code is doing. The logfiles get big so it might be good to compile the relevant tiles only. If you have questions just send the logfile. WanMil
Hi Wanmil, I've enabled logging and I see now 4 files with mkgmap.log.0, 1, 2 and 3 without any relations in it: http://mijndev.openstreetmap.nl/~ligfietser/diverse/mkgmap.log.zip Maybe my logging.properties parameters are not correct? # The default level FINE, WARNING, INFO, SEVERE .level=FINE #handlers: java.util.logging.ConsoleHandler handlers: java.util.logging.FileHandler # package or class name with .level appended and then the level uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation.level=FINE # For ConsoleHandler java.util.logging.ConsoleHandler.level=WARNING java.util.logging.ConsoleHandler.formatter=uk.me.parabola.log.UsefulFormatter # For FileHandler java.util.logging.FileHandler.level=FINE java.util.logging.FileHandler.formatter=uk.me.parabola.log.UsefulFormatter java.util.logging.FileHandler.limit=5000000 java.util.logging.FileHandler.count=4 java.util.logging.FileHandler.pattern=mkgmap.log java.util.logging.FileHandler.append=false ---------- Wanmil wrote: If you assume that the multipolygon algorithm has a problem you should change the log level of the Multipolygon class: uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation.level=FINE Enabling the logging is described at http://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging You can search the logfiles for the relation id and check what the multipolygon code is doing. The logfiles get big so it might be good to compile the relevant tiles only. If you have questions just send the logfile. WanMil _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Your logging parameters log too much. .level=FINE activates all loggers with the maximum log level so your 4 files contain only messages of how the img files are created. Change the following lines: .level=SEVERE java.util.logging.FileHandler.limit=100000000 This means: default setting: log errors only max log file size 100MB. Your setting 5MB is a bit too small :-) WanMil
Hi Wanmil,
I've enabled logging and I see now 4 files with mkgmap.log.0, 1, 2 and 3 without any relations in it: http://mijndev.openstreetmap.nl/~ligfietser/diverse/mkgmap.log.zip
Maybe my logging.properties parameters are not correct?
# The default level FINE, WARNING, INFO, SEVERE .level=FINE
#handlers: java.util.logging.ConsoleHandler handlers: java.util.logging.FileHandler
# package or class name with .level appended and then the level uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation.level=FINE
# For ConsoleHandler java.util.logging.ConsoleHandler.level=WARNING java.util.logging.ConsoleHandler.formatter=uk.me.parabola.log.UsefulFormatter # For FileHandler java.util.logging.FileHandler.level=FINE java.util.logging.FileHandler.formatter=uk.me.parabola.log.UsefulFormatter java.util.logging.FileHandler.limit=5000000 java.util.logging.FileHandler.count=4 java.util.logging.FileHandler.pattern=mkgmap.log java.util.logging.FileHandler.append=false
---------- Wanmil wrote:
If you assume that the multipolygon algorithm has a problem you should change the log level of the Multipolygon class: uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation.level=FINE
Enabling the logging is described at http://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging
You can search the logfiles for the relation id and check what the multipolygon code is doing. The logfiles get big so it might be good to compile the relevant tiles only.
If you have questions just send the logfile.
WanMil _______________________________________________ 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
Thanks Wanmil, I got this message in the log file: c:\Downloads\Benelux\10010046.osm.gz: Cannot join the following ways to closed polygons. Multipolygon http://www.openstreetmap.org/browse/relation/1424029 On my map the Albert canal looks empty, except for the river in the centre. On the adjacent tiles west and east of tile 10010046, the Albert canal is filled with water again, because there the ends of the multipolygon are detected. I put the log file here: http://mijndev.openstreetmap.nl/~ligfietser/diverse/mkgmap.log.zip
Ps you can see my tiles here: http://www.gpsvisualizer.com/display/1305916509-00480-83.85.222.55.html The areas_bnl.kml and areas_bnl.list area lists are in here: http://mijndev.openstreetmap.nl/~ligfietser/openfietsmap/Scripts/
Thanks for your investigations. I have an idea. The automatic closing of polygons only closes single ways but does not check if the way could be closed by connecting it to another way. This is a bit tricky and I fear that there might be some side effects. But possibly it works. I will try to implement a patch. WanMil
Thanks Wanmil, I got this message in the log file: c:\Downloads\Benelux\10010046.osm.gz: Cannot join the following ways to closed polygons. Multipolygon http://www.openstreetmap.org/browse/relation/1424029
On my map the Albert canal looks empty, except for the river in the centre. On the adjacent tiles west and east of tile 10010046, the Albert canal is filled with water again, because there the ends of the multipolygon are detected.
I put the log file here: http://mijndev.openstreetmap.nl/~ligfietser/diverse/mkgmap.log.zip
Minko, can you please test the patch I've posted? WanMil
Thanks for your investigations.
I have an idea.
The automatic closing of polygons only closes single ways but does not check if the way could be closed by connecting it to another way. This is a bit tricky and I fear that there might be some side effects. But possibly it works.
I will try to implement a patch.
WanMil
Thanks Wanmil, I got this message in the log file: c:\Downloads\Benelux\10010046.osm.gz: Cannot join the following ways to closed polygons. Multipolygon http://www.openstreetmap.org/browse/relation/1424029
On my map the Albert canal looks empty, except for the river in the centre. On the adjacent tiles west and east of tile 10010046, the Albert canal is filled with water again, because there the ends of the multipolygon are detected.
I put the log file here: http://mijndev.openstreetmap.nl/~ligfietser/diverse/mkgmap.log.zip
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Thanks Wanmil, I'd like to test it, but don't know how to use those patches. Do you have a mkgmap.jar file? Wanmil wrote: Minko, can you please test the patch I've posted? WanMil
You can download the patched (v2) mkgmap from http://files.mkgmap.org.uk/download/19/mkgmap.jar WanMil
Thanks Wanmil, I'd like to test it, but don't know how to use those patches. Do you have a mkgmap.jar file?
Wanmil wrote:
Minko,
can you please test the patch I've posted?
WanMil
Thanks Wanmil! Your patch solves the problems with the Albert Canal (water is back). It also solves another issue with rendering a very large multipolygon farmland in NW France: http://www.openstreetmap.org/browse/relation/1067268 I have tested it on about 10 tiles in Belgium/N-France/SW NL and I haven't discovered any side effects (yet).
Hello, I've a problem with a riverbank (http://www.openstreetmap.org/?lat=52.82591&lon=12.07255&zoom=16&layers=M) When looking at my map on the Garmin or Basecamp I can see the islands (http://img820.imageshack.us/img820/1363/931.png), but when zooming in, they are gone(http://img202.imageshack.us/img202/6453/926.png). Also when I point to the island I get the name, but after zooming I get the name of the river. What's wrong?! Cheers, Martin Am 20.05.2011 um 20:57 schrieb WanMil:
Thanks for your investigations.
I have an idea.
The automatic closing of polygons only closes single ways but does not check if the way could be closed by connecting it to another way. This is a bit tricky and I fear that there might be some side effects. But possibly it works.
I will try to implement a patch.
WanMil
Thanks Wanmil, I got this message in the log file: c:\Downloads\Benelux\10010046.osm.gz: Cannot join the following ways to closed polygons. Multipolygon http://www.openstreetmap.org/browse/relation/1424029
On my map the Albert canal looks empty, except for the river in the centre. On the adjacent tiles west and east of tile 10010046, the Albert canal is filled with water again, because there the ends of the multipolygon are detected.
I put the log file here: http://mijndev.openstreetmap.nl/~ligfietser/diverse/mkgmap.log.zip
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Both islands and the riverbank should be part of a multipolygon relation, not one big way like here. The islands have to be tagged as inner member of that relation (without any further tags) and the riverbank itself is the outer member (without tags). The whole relation should get the tag waterway=riverbank Martin wrote: Hello, I've a problem with a riverbank ( http://www.openstreetmap.org/?lat=52.82591&lon=12.07255&zoom=16&layers=M ) When looking at my map on the Garmin or Basecamp I can see the islands ( http://img820.imageshack.us/img820/1363/931.png ), but when zooming in, they are gone( http://img202.imageshack.us/img202/6453/926.png ). Also when I point to the island I get the name, but after zooming I get the name of the river. What's wrong?! Cheers, Martin
Info i hope, i have correctly changed the Havelberg Islands mapping. Now the havel-river has two new islands in a multipolygon=riverbank Relation. i hope it works proper :-) greetings ludwich Am 06.09.2011 um 09:05 schrieb Minko:
Both islands and the riverbank should be part of a multipolygon relation, not one big way like here. The islands have to be tagged as inner member of that relation (without any further tags) and the riverbank itself is the outer member (without tags). The whole relation should get the tag waterway=riverbank
Martin wrote:
Hello,
I've a problem with a riverbank ( http://www.openstreetmap.org/?lat=52.82591&lon=12.07255&zoom=16&layers=M ) When looking at my map on the Garmin or Basecamp I can see the islands ( http://img820.imageshack.us/img820/1363/931.png ), but when zooming in, they are gone( http://img202.imageshack.us/img202/6453/926.png ). Also when I point to the island I get the name, but after zooming I get the name of the river. What's wrong?!
Cheers, Martin _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (6)
-
Henning Scholland -
ludwich -
Marko Mäkelä -
Martin -
Minko -
WanMil