logo separator

[mkgmap-dev] White stripes in the sea

From WanMil wmgcnfg at web.de on Thu Jan 3 20:12:56 GMT 2013

>  > So in ASCII art it's the following situation:
>  > (s = sea polygon, each l = single small land polygon)
>  >
>  > ssssssssssssssssss
>  > slllllllllllllllls
>  > slllllllllllllllls
>  > slllllllllllllllls
>  > ssssssssssssssssss
>  >
>  > In the end it is also a problem of the resolution dependant mp cut
>  > algorithm. At first it would remove all small single land polygons. But
>  > in an improved algorithm it could try to merge the land polygons.
>  >
>  > I guess merging will be quite complex:
>  > - What should be done if two small mergable polygons have some tags in
>  > common but also some different tags? How is the merged polygon tagged?
>  > - How should the algorithm detect that two polygons can be merged when
>  > they are not connected to each other? It could calculate fractions for
>  > each resolution dependant "pixel". So on one pixel the sea might be 30%
>  > and land 70% and therefore land wins and the pixel is assigned as land.
>  > This requires a good merging algorithm for pixels...
>  > - ???
>
> Well, let's postpone this for now, if it can be done we can do it later.
> I've just realized that cutOutInnerPolygons() is called before
> the StyledConverter. Will the style system be able to
> handle data that is repeated for each resolution?

That's what I tried to explain some posts ago with the 
mkgmap:resolution=N tag.
Some more details about that:

You have two resolutions, e.g. 18 and 24.
So as an example mp might create the following polygons
p1 [mkgmap:resolution=18;natural=sea]
p2 [mkgmap:resolution=24;natural=sea]
p3 [mkgmap:resolution=24;natural=sea]
p4 [mkgmap:resolution=24;natural=land]

There are three polygons for resolution 24 but only one for resolution 
18 because the inner land polygon p4 would not be visible in resolution 18.

The style has the two rules: (Don't know if 0x31 is a good code for land 
but it's just an example)
natural=land [0x31 resolution 10]
natural=sea [0x32 resolution 10]


p1 to p4 is processed by the style and therefore you would get four 
internal GType objects:
g1 0x32 minResolution=10; maxResolution=24
g2 0x32 minResolution=10; maxResolution=24
g3 0x32 minResolution=10; maxResolution=24
g4 0x31 minResolution=10; maxResolution=24

But mkgmap:resolution is set therefore the given resolution is used as 
mask on the GType resolutions:
g1 0x32 minResolution=18; maxResolution=18
g2 0x32 minResolution=24; maxResolution=24
g3 0x32 minResolution=24; maxResolution=24
g4 0x31 minResolution=24; maxResolution=24


>
> I wonder if the coastline data is really a good reason to change
> the program logic that much. I think it is a special case and maybe
> it would be better not to pass the data through the same routines?
>

It is a general problem of the mp cutting so I think it should be solved 
there. Anyhow I think it's good idea to define an interface for the cut 
method within the MultipolygonRelation. That makes it easier to play 
with different cut algorithms and if required one could use different 
cut algorithms for sea and normal mps.

I have created a branch mp_cut to start with the work.

WanMil


More information about the mkgmap-dev mailing list