Hello all, I have the following rule in my polygons style: surface=sand [0x1b resolution 20] The problem is the following multipolygon: http://www.openstreetmap.org/browse/relation/1221199 This is a complex multipolygon which, in certain sections, uses the coastline to define the outer. Parts of the coastline (and therefore parts of the multipolygon) have the key/tag pair surface=sand The result is that mkgmap attempts to build a multipolygon for Port Philip Bay and fill it with sand, which is not ideal: http://www.cferrero.net/maps/img/1.png What I can't figure out is how to adjust my polygon style rules to avoid this happening. Or tell mkgmap not to process multipolygons of type natural=bay Neither of the following two variations of the rule makes any difference: surface=sand & natural!=coastline [0x1b resolution 20] surface=sand & type=!multipolygon [0x1b resolution 20] Nor does natural=coastline & surface=sand {delete surface} make any difference whether I put it in the lines file or the polygons file Does anyone have a suggestion on how to fix this? Thanks! -- Charlie
Moin, I think the problem is not the multipolygon, but that some of the outer ways are tagged with surface=sand. These tags are not considered for the multipolygon, but for these ways mkgmap creates single surface=sand polygons. But if you change your polygon style from surface=sand [0x1b resolution 20] to surface=sand & natural!=coastline [0x1b resolution 20] this shouldn't happen any more. Just for a try: What happens, if you remove the surface=sand lines from your polygon styles completely? And one other thing: There was once a patch, which limited the polygon creation to closed ways. Does anybody know, what happened to this patch? I really liked it. Gruss Torsten
On 08/01/2011 13:02, Torsten Leistikow wrote:
Moin,
I think the problem is not the multipolygon, but that some of the outer ways are tagged with surface=sand. These tags are not considered for the multipolygon, but for these ways mkgmap creates single surface=sand polygons.
But if you change your polygon style from
surface=sand [0x1b resolution 20]
to
surface=sand& natural!=coastline [0x1b resolution 20]
this shouldn't happen any more.
Just for a try: What happens, if you remove the surface=sand lines from your polygon styles completely?
And one other thing: There was once a patch, which limited the polygon creation to closed ways. Does anybody know, what happened to this patch? I really liked it.
Gruss Torsten Hi Torsten,
You may be right - it might just be that the polygon rule makes mkgmap create a surface=sand polygon for coastline ways tagged with surface=sand. Unfortunately it is legitimate to tag a way as surface=sand so I cannot correct the OSM data. I need some way of telling mkgmap not to create a surface=sand polygon when it is associated with a coastline. Unfortunately surface=sand& natural!=coastline [0x1b resolution 20] does not solve the problem. I think this may be because the natural=coastline tag is being removed during the --generate-sea processing, so it is no longer there when the polygon code starts. The only way I can currently solve it is to remove the surface=sand rule completely, which I don't want to have to do. Charlie
I have attached that patch to limit polygon creation to closed ways. It's untested and I assume there are some unwanted effects at tile borders. Please check and if you (and others) find it usefull it can be committed. WanMil
Moin,
I think the problem is not the multipolygon, but that some of the outer ways are tagged with surface=sand. These tags are not considered for the multipolygon, but for these ways mkgmap creates single surface=sand polygons.
But if you change your polygon style from
surface=sand [0x1b resolution 20]
to
surface=sand& natural!=coastline [0x1b resolution 20]
this shouldn't happen any more.
Just for a try: What happens, if you remove the surface=sand lines from your polygon styles completely?
And one other thing: There was once a patch, which limited the polygon creation to closed ways. Does anybody know, what happened to this patch? I really liked it.
Gruss Torsten _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
WanMil schrieb am 08.01.2011 11:44:
I have attached that patch to limit polygon creation to closed ways. It's untested and I assume there are some unwanted effects at tile borders. Please check and if you (and others) find it usefull it can be committed.
Did anybody else try this patch? I haven't noticed any problems and would like to see this patch comitted. Gruss Torsten
Torsten, I have no time at the moment to perform a deep check of that patch. So unless some people on the list confirm that it doesn't harm I don't want to commit that. I hope that's ok?!? WanMil
WanMil schrieb am 08.01.2011 11:44:
I have attached that patch to limit polygon creation to closed ways. It's untested and I assume there are some unwanted effects at tile borders. Please check and if you (and others) find it usefull it can be committed.
Did anybody else try this patch? I haven't noticed any problems and would like to see this patch comitted.
Gruss Torsten
On 25/02/2011 00:39, WanMil wrote:
Torsten,
I have no time at the moment to perform a deep check of that patch. So unless some people on the list confirm that it doesn't harm I don't want to commit that. I hope that's ok?!?
WanMil
I have limited ability to compile patched versions of mkgmap. If you can share a jar file I can give it a test. -- Charlie
Torsten,
I have no time at the moment to perform a deep check of that patch. So unless some people on the list confirm that it doesn't harm I don't want to commit that. I hope that's ok?!?
WanMil
I have limited ability to compile patched versions of mkgmap. If you can share a jar file I can give it a test.
-- Charlie
I have bad news. Today I stumbled again over the problems of the PolygonSplitter which left some polygons unclosed. I posted a patch for this which did some cody tidy around polygons and fixed this. But I also found out that some polygons that crosses the tile border which are closed in the OSM data are not neccessarily closed in the tiles. This has to be investigated. Does the splitter ensure that all closed ways in the OSM dump are also closed in the splitted tiles? Unless this can be ensured I think it is no good to commit this patch. WanMil
On Fri, Feb 25, 2011 at 11:36:39PM +0100, WanMil wrote:
But I also found out that some polygons that crosses the tile border which are closed in the OSM data are not neccessarily closed in the tiles. This has to be investigated. Does the splitter ensure that all closed ways in the OSM dump are also closed in the splitted tiles?
Could mkgmap be aware of the tile borders when closing polygons? When the open endpoints are within the current tile, do not close the polygon, and possibly emit a complaint to the error log. When the endpoints are outside the current tile borders, close by adding lines along the tile borders? On a somewhat related note, there is some natural=coastline problem in Finland that JOSM cannot find in the natural=coastline extract of finland.osm.pbf. The error message only mentions generated relation and way IDs: 63240006: 2916352,960000 to 3014656,1474560 # : 62.578125,20.599365 to 64.687500,31.640625 2011/02/26 11:13:04 WARNING (MultiPolygonRelation): 63240006.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/4611686018427480001 contains errors. 2011/02/26 11:13:04 WARNING (MultiPolygonRelation): 63240006.osm.gz: Polygon 4611686018427486852(8P)(4611686018427483429[8P]) carries role inner but lies inside an inner polygon. Potentially its role should be outer. It would be helpful to see a coordinate of one of the ways. I guess that this is being caused by two islands being on top of each other. Apparently, JOSM could only catch that if the coastlines intersected. Marko
On Fri, Feb 25, 2011 at 11:36:39PM +0100, WanMil wrote:
But I also found out that some polygons that crosses the tile border which are closed in the OSM data are not neccessarily closed in the tiles. This has to be investigated. Does the splitter ensure that all closed ways in the OSM dump are also closed in the splitted tiles?
Could mkgmap be aware of the tile borders when closing polygons? When the open endpoints are within the current tile, do not close the polygon, and possibly emit a complaint to the error log. When the endpoints are outside the current tile borders, close by adding lines along the tile borders?
That should be no problem.
On a somewhat related note, there is some natural=coastline problem in Finland that JOSM cannot find in the natural=coastline extract of finland.osm.pbf. The error message only mentions generated relation and way IDs:
63240006: 2916352,960000 to 3014656,1474560 # : 62.578125,20.599365 to 64.687500,31.640625
2011/02/26 11:13:04 WARNING (MultiPolygonRelation): 63240006.osm.gz: Multipolygon http://www.openstreetmap.org/browse/relation/4611686018427480001 contains errors. 2011/02/26 11:13:04 WARNING (MultiPolygonRelation): 63240006.osm.gz: Polygon 4611686018427486852(8P)(4611686018427483429[8P]) carries role inner but lies inside an inner polygon. Potentially its role should be outer.
It would be helpful to see a coordinate of one of the ways. I guess that this is being caused by two islands being on top of each other. Apparently, JOSM could only catch that if the coastlines intersected.
Ok, sounds good as a first solution. I'll post a patch.
Marko
2011/2/26 WanMil <wmgcnfg@web.de>:
Could mkgmap be aware of the tile borders when closing polygons? When the open endpoints are within the current tile, do not close the polygon, and possibly emit a complaint to the error log. When the endpoints are outside the current tile borders, close by adding lines along the tile borders?
That should be no problem.
That would be a really cool feature! I used to create height relief maps from srtm contour lines with mkgmap (see http://img30.imageshack.us/img30/9595/img0854oj.jpg) but I had to close all lines around the tile borders manually in josm... If this worked, we could create height relief maps for any place automatically! -Martin
2011/2/26 WanMil<wmgcnfg@web.de>:
Could mkgmap be aware of the tile borders when closing polygons? When the open endpoints are within the current tile, do not close the polygon, and possibly emit a complaint to the error log. When the endpoints are outside the current tile borders, close by adding lines along the tile borders?
That should be no problem.
That would be a really cool feature!
I used to create height relief maps from srtm contour lines with mkgmap (see http://img30.imageshack.us/img30/9595/img0854oj.jpg) but I had to close all lines around the tile borders manually in josm...
If this worked, we could create height relief maps for any place automatically!
-Martin
Martin, I don't know for sure if that solves your problem. The fix closes lines for which are only polygon rules available in the style files. I don't know how the contour lines are defined. Just try it and let use know. WanMil
2011/2/26 WanMil <wmgcnfg@web.de>:
Martin,
I don't know for sure if that solves your problem. The fix closes lines for which are only polygon rules available in the style files. I don't know how the contour lines are defined.
Just try it and let use know.
Hi! This sounds like exactly the thing needed, as I create these Polygons seperately. :-) I tried to build the patched mkgmap from source but this failed. But as the patch is committed now, I'll simply try with the next automatically buit version from the website. -Martin
2011/2/27 Martin Simon <grenzdebil@gmail.com>:
Hi!
This sounds like exactly the thing needed, as I create these Polygons seperately. :-)
I tried to build the patched mkgmap from source but this failed. But as the patch is committed now, I'll simply try with the next automatically buit version from the website.
OK, I was wrong; I now tried to build a map with contour lines generated by GroundTruth (commands: "GroundTruth.exe contours --gridlat=1 --gridlon=1 -b=50,6,51,7 -o=50-6.ibf" and "GroundTruth.exe ibf2osm -i=50-6.ibf"). Then I built a map from the resulting .osm file with a mkgmap style just for polygons. The Lines were closed, but unfortunately, not around the corners of the source file (the contour lines' start and end points are exactly at 50/51 degree latitude and 6/7 degree longitude). GroundTruth doesn't add "bounds" to the osm file, but adding it manually doesn't change the result. As the contour lines generated by Groundtruth are always running clockwise around a hill, what needed to be done is closing them from a lines' endpoint clockwise around the tile edges until the startpoint is reached *or* the startpoint of another contour line with the same tags is reached, merging them, and continue. I don't know at all how much work would need to done to implement this behaviour... --Martin
On Mon, Feb 28, 2011 at 01:53:50PM +0100, Martin Simon wrote:
GroundTruth doesn't add "bounds" to the osm file, but adding it manually doesn't change the result.
The default style has the contour lines in the "lines" file, not in the "polygons" file. What if you added something like this to the "polygons" file? contour=elevation | contour_ext=* { continue } Would it trigger the polygon-closing code? Marko
2011/2/28 Marko Mäkelä <marko.makela@iki.fi>:
The default style has the contour lines in the "lines" file, not in the "polygons" file. What if you added something like this to the "polygons" file?
contour=elevation | contour_ext=* { continue }
Would it trigger the polygon-closing code?
Marko
Hi Marko, I just tried that, there is no difference in the resulting map - the used style normally only has a "polygons" file, no points and no lines. -Martin
I am not sure why surface=sand really needs to be on the ways. But even if surface=sand is on the ways mkgmap shouldn't be creating polygons from it if the ways aren't closed. As surface=sand can be used for ways or areas. I might send a message to the original creator of the ways to ask if they mind If I remove the surface=sand as it isn't fully accurate anyway. Markus_g -----Original Message----- From: mkgmap-dev-bounces@lists.mkgmap.org.uk [mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk] On Behalf Of Charlie Ferrero Sent: Saturday, 8 January 2011 6:58 PM To: Development list for mkgmap Subject: [mkgmap-dev] Multipolygon problem Hello all, I have the following rule in my polygons style: surface=sand [0x1b resolution 20] The problem is the following multipolygon: http://www.openstreetmap.org/browse/relation/1221199 This is a complex multipolygon which, in certain sections, uses the coastline to define the outer. Parts of the coastline (and therefore parts of the multipolygon) have the key/tag pair surface=sand The result is that mkgmap attempts to build a multipolygon for Port Philip Bay and fill it with sand, which is not ideal: http://www.cferrero.net/maps/img/1.png What I can't figure out is how to adjust my polygon style rules to avoid this happening. Or tell mkgmap not to process multipolygons of type natural=bay Neither of the following two variations of the rule makes any difference: surface=sand & natural!=coastline [0x1b resolution 20] surface=sand & type=!multipolygon [0x1b resolution 20] Nor does natural=coastline & surface=sand {delete surface} make any difference whether I put it in the lines file or the polygons file Does anyone have a suggestion on how to fix this? Thanks! -- Charlie _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (6)
-
Charlie Ferrero -
Marko Mäkelä -
Markus_g -
Martin Simon -
Torsten Leistikow -
WanMil