[mkgmap-dev] White stripes in the sea

Thu Jan 3 19:00:19 GMT 2013

> WanMil wrote
>> As a result we maybe have to break out an idea from the beginning of the
>> mp implementation. It would be possible to do the cutting at a later
>> position in the mkgmap chain. At the moment the cutting is done once for
>> all resolutions. It would be better to do the cutting separate for each
>> resolution. This would enable that in lower resolutions small inner
>> polygons could be removed from the mp cutting because the inner area is
>> so small that it is not displayed at that resolution.
>>
>> That's an interesting idea and I guess it would improve the look of the
>> mkgmap generated maps quite a lot. At the same time I guess that it
>> doesn't make much sense trying to improve the mp cut algorithm because
>> you will reach similar problems again (one exception: the non
>> java.awt.geom.Area compatible algorithm might work because it does not
>> change the bounding box size of each polygon)
>
> I agrree in all points. Do you have a concrete idea how we could change the
> mkgmap chain? All the filter algorithms do only see type and sub-type values
> and points,
> but no information like sea or land.
> I don't see an easy way to do the cutting of inner polygons with this
> information.

I see many possible solutions.
Two of them are:

1. At the moment multipolygons are cut into pieces just after reading 
from the input file. The first solution would not move that but the 
multipolygon code does the cutting for each resolution and tags the 
result with mkgmap:resolution=N. So there will be a copy of each polygon 
for each resolution.
The style converter checks this tag and filters out the objects that 
does not match this resolution.
The mp cutting code is changed in such a way that it uses the 
RoundCoordsFilter to check if a polygon is visible in the given 
resolution. If not it is not used in this resolution.

This variant seems to be quite easy to implement and gives a good 
impression if that improves the whole story. It is not optimal due to 
the high number of additional polygons that must be kept in memory. But 
for a prototyping test it seems to be great.

2. The mp cut algorithm could be moved to the resolution dependant 
processing of mkgmap. That's somewhere between the StyledConverter and 
the subdivision splitting. This is a bit cleaner but I am not sure how 
many effort this needs.

> If we read the TYP file we know the drawing order, maybe that is enough?
>
> Would it be possible to define a TYP for a sea area that has many small
> islands and then
> automatically detect this for areas like the baltic sea? Else we have to
> find an algo to decide
> whether such a mixed area should be displayed as sea or land, esp. for the
> low resulutions.

I have no idea how to use a TYP file to avoid such problems.
The algorithm to decide if a mixed are should be displayed as sea or 
land is the resolution dependant mp cut algorithm as described above.

WanMil

>
> Gerd
>