[mkgmap-dev] Still problems with lakes

Thu Sep 20 09:10:40 BST 2012

Hi,

I did never think about calculating the size of the area. My understanding of the problem 
is that 
1) mkgmap sometimes fails to handle incomplete (closed) polygons 
2) splitter sometimes causes incomplete polygons, esp. for large polygons that cross tile borders

My approach to solve the problem:
1) detect polygons that cross tile borders (I call them multi-tile-polygons mtp). 
This is not so difficult and is already implemented in my version: you just have to note 
polygons that have points in more than one tile.
2) detect those tiles that are (or maybe) crossed or enclosed by an mtp, because mkgmap should see the complete data of them, 
but it doesn't with splitters (r200) implementation. 
This is were I got stuck. I tried to keep the precise coordinates of all points belonging to all mtp, 
but that is far too much data, so splitter would no longer work on 32 bit machines, and I wanted to avoid that.
So, I started to implement filters for mtp that are not able to cause problems, which reduced the amount of 
data to maybe 50%, but still my algorithm is keeping too many false candidates and therefor requires 
too much heap. 
Just to make this clear: beause of the structure of the OSM data, splitter first sees all points, than all ways, than the relation definitions.
Up to now, splitter can keep the information to what tiles a given point was written, but it can't save details about coordinates. 
It is not possible to calculate the size of an area without having the coordinates (no matter how precise), so this can't help.

If you open the kml file produced by splitter (using the --write-kml  parm) with e.g. google earth, you see the tiles. 
Any polygon which is near the border of two tiles is likely to be a mtp, but obviously most of them are houses or small 
areas, and only a very small amount is interesting for us. The problem is: You can't tell before you know the coordinates,
because splitter just knows that a mtp contains points in two or more tiles, it doesn't know anything about the position of 
these points whithin the tiles. Even this bit of information requires a lot of heap (r200 keeps more or less the same data and is 
already highly optimized)

So, what I have until now is a splitter program that doesn't write incomplete polygon data to 
the tiles (if the source data is complete), but it still doesn't write mtp data to tiles 
that do not contain any point of the polygon. 
If input is in o5m format, this version performs quite well
and doesn't require much more heap memory, the values are almost equal if I remember correctly.

Ciao,
Gerd

> Date: Wed, 19 Sep 2012 07:25:10 -0700
> From: easyclasspage at googlemail.com
> To: mkgmap-dev at lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] Still problems with lakes
> 
> @GerdP:
> 
> Some ideas concerning the "huge polygon problem":
> - huge polygons are rare
> - a broken polygon leads to an ugly (amateur like) map
> - it's hard to find all broken polygons in a map manually
> 
> Some questions concerning a solution:
> - is it possible to implement a "huge polygon" parameter ?
> - the parameter acts as threshold and triggers splitter for extra processing
> - the parameter could be the area (e.g. 2000 sqkm) or circumference (e.g.
> 1000 km) of an "huge" polygon
> 
> If the calculating of all polygons has a large negative performance impact:
> - is it possible to identify the huge polygons in an extra (on demand)
> splitter run ?
> - the result could be a list with all identified huge polygons (generated
> only once)
> - this list is than the input for the essential splitter run
> 
> What do you think ?
> 
> Regards Klaus
> 
> PS: What is the exactly influence of the overlapping parameter concerning
> the splitting of (huge) polyons ?
> 
> 
> 
> --
> View this message in context: http://gis.19327.n5.nabble.com/Still-problems-with-lakes-tp5725668p5726209.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20120920/b865f059/attachment.html 