[mkgmap-dev] problem with --generate-sea near Toronto, Canada

Sun Jan 30 20:42:00 GMT 2011

On Sun, Jan 30, 2011 at 08:53:09PM +0100, Ben Konrath wrote:
>I've run into a strange problem with --generate-sea while generating a
>map of Canada. Here's a screenshot of the problem I'm seeing:
>
>http://bagu.org/scratch/generate-sea-problem-lake-ontario.bmp

You seem to have have a vertical band of inverted land/sea west from 
Oakville. I would guess that the NW or NE corner of the inverted box is 
at a tile border. I would suspect some error at the spot where one of 
the vertical lines intersects with the real coastline.

Hmm, I was almost going to believe that the ocean starts right south of 
Canada, but then I remembered that there is some piece of land called 
the United States in between. :-)

I would guess two possible causes for your problem. Either your tile 
boundaries are chosen badly, so that some multipolygons are severed by 
them, or the input data is bad. splitter.jar will leave some 'safety 
margin' around the tiles, but it may not be enough. When the Lake 
Päijänne in Finland was defined in a single multipolygon (it used to be 
natural=coastline), I got some errors that I fixed by moving my tile 
boundaries so that the entire lake fits in a single tile.

If you want generate-sea to work on a non-rectangular map extract (and 
if the Great Lakes have been defined as natural=coastline), you may have 
to apply some black magic when choosing the tile borders.  For my 
Finland map, I extracted the natural=coastline from the Geofabrik 
finland.osm.pbf with Osmosis, and loaded the result in JOSM. Then I 
figured out how to choose the tile borders so that the missing sections 
of natural=coastline would be outside the tile borders. Only in the 
north, I had to use extend-sea-sectors to augment a missing bit, because 
I did not want to create lots of tiny tiles near the Swedish/Finnish 
land border.

>I'm using mkgmap version r1783 with these options:
>
>java -Xmx400M -Dlog.config=/home/ben/osm/mkgmap/resources/logging.properties

400M could be a bit scarce, but probably not causing this. I run with 
-Xmx1024m. If your logging.properties is like the one I have at 
http://www.polkupyoraily.net/osm/, you should have some mkgmap.log.* 
files. The most recent one should be mkgmap.log.0.

>Does anybody know what's going on? What's the best way to debug a 
>problem like this?

Search mkgmap.log.0 for 'MultiPolygon' or 'coastline'. Or, if you are 
ambitious, take and adapt my logging.ignore, and grep -vf logging.ignore 
mkgmap.log.0, and fix all errors. That is doable for a small country, 
such as Finland. I update my public map only when there are no serious 
errors (such as multipolygon issues or dead-end oneways other than some 
driveway).

For what it is worth, yesterday I found out that 
http://www.openstreetmap.org/browse/relation/1201329 contained some 
minor puddles in Mikkeli, Finland in role=outer and exactly one lake and 
island (role=outer, role=inner) somewhere in Canada. After I removed the 
bogus role=outer puddles, JOSM warned that the remaining multipolygon 
had unclosed polygons. I did not try to fix that.

(I guess that there should be a validator that complains about 
multipolygons whose members are far apart. In the recent days, I have 
also come across Finnish-German and Finnish-Spanish multipolygons.)

Best regards,

	Marko