[mkgmap-dev] overview2 branch -- sea not rendered at resolution 12

Fri May 10 18:15:49 BST 2013

Hi Felix,

ok, please post the complete default style as a zip file and I will commit
it.

Gerd

Felix Hartmann-2 wrote
> Well I'm still very positive about the rules I posted. Add the skip filter
> for sea, and it should be good. It's pretty safe regarding an .img getting
> too large (would only happen on a worldmap - but worldmaps are not really
> supported by Mapsource/Basecamp anyhow...)..
> and good enough for orientation.
> 
> 
> On 10 May 2013 12:04, GerdP &lt;

> gpetermann_muenchen@

> &gt; wrote:
> 
>> I've committed r2597 in the overview2 branch.
>> This adds the mkgmap:skipSizeFilter feature and it is used by the default
>> style like this:
>> natural=sea { add mkgmap:skipSizeFilter=true } [0x32 resolution 10]
>>
>> I would be happy if someone else could take care about the style rules
>> for
>> the overview2 branch, I don't yet feel familiar them.
>>
>> Gerd
>>
>>
>> GerdP wrote
>> > I see different ways to implement a special case handling:
>> > 1) The style can add a tag like mkgmap:skipSizeFilter to an object
>> > 2) The SeaGenerator can add such a tag (and the style might remove it)
>> >
>> > I'd prefer 1) as it offers more flexibility.
>> >
>> > Gerd
>> >
>> >> Date: Wed, 8 May 2013 12:53:31 -0400
>> >> From:
>>
>> > extremecarver@
>>
>> >> To:
>>
>> > mkgmap-dev at .org
>>
>> >> Subject: Re: [mkgmap-dev] overview2 branch -- sea not rendered at
>> >> resolution 12
>> >>
>> >> well, I use 12, it makes the map smaller and faster --
>> >> for the overview map however - theese are the max usable numbers. So
>> >> either skip this filter for all polygons created by the sea generator
>> >> for the overview map (that would be a good solution), or reduce the
>> >> filter value by resolution with the values I posted below.
>> >>
>> >> I think either is fine
>> >> (also skip the filter in general for the sea generator).
>> >>
>> >> also a value of 8 as by default - will as you can see - not work for
>> >> resolution 12... (and I'm not sure if it will still work 100% for
>> >> resolution 13 - could be that it already drops some polygons at that
>> >> resolution).
>> >> On 08.05.2013 11:35, GerdP wrote:
>> >> > Hi Felix,
>> >> >
>> >> > quite a few numbers, I am not srure how to handle your results.
>> >> > The current processing in mkgmap is this:
>> >> > the min-size-polygon value is multiplied by 2 ^(24-resolution), e.g.
>> a
>> >> value
>> >> > of 8 will give 32 on resolution 22. This value is compared with the
>> >> width
>> >> > and height of the polygon in map units. If both values are smaller,
>> the
>> >> > object is dropped.
>> >> > I am not sure why one wants a rather large value, I guess it makes
>> the
>> >> img
>> >> > size smaller. The default
>> >> > value is 8.
>> >> > A possible solution could be to skip this filter for all polygons
>> >> created by
>> >> > the SeaGenerator.
>> >> >
>> >> > Gerd
>> >> >
>> >> >
>> >> > Felix Hartmann-2 wrote
>> >> >> No, they are already missing.
>> >> >> ---Changing --min-size-polygon=12 to --min-size-polygon=1 and they
>> >> >> appear. I think the problem is the size of the sea tiles as they
>> are
>> >> cut
>> >> >> down into smaller polygons by mkgmap itself - because in the input
>> >> data
>> >> >> they are big enough... However therefore I tried around all
>> min-sizes
>> >> >> regarding the resolution to see what works!
>> >> >>
>> >> >> So here is a list of the biggest min-size-polygon usable currently:
>> >> >> 1=good for resolution 10...
>> >> >> 2=good for resolution 11, variable output on resolution 10
>> >> >> 3=good for resolution 12, variable output on resolution 11
>> >> >> 4=good for resolution 12, nearly no output on resolution 11
>> >> >> 5=good for resolution 13, variable output on resolution 12, no more
>> >> >> output on resolution 11.
>> >> >> 6=good for resolution 13, variable output on resolution 12
>> >> >> 7=good for resolution 13, variable output on resolution 12
>> >> >> 8=good for resolution 13, nearly no output on resolution 12
>> >> >> 9=good for resolution 14, variable output on resolution 13
>> >> >> 10=good for resolution 14, variable output on resolution 13
>> >> >> 11=good for resolution 14, variable output on resolution 13, no
>> more
>> >> >> output on resolution 12..
>> >> >> 12=good for resolution 14, variable output on resolution 13, no
>> more
>> >> >> output on resolution 12..
>> >> >>
>> >> >>
>> >> >> The strange thing about this is, that the sea in the input data is
>> >> large
>> >> >> enough - I think the problem happens when splitting for
>> >> subdivisions...
>> >> >>
>> >> >> Overview2 branch - before multiple level overview map --
>> >> >> min-size-polygon=12 was fine. GpsMapedit says the resolution is 13.
>> I
>> >> >> assume the min-size was not respected because the input data just
>> got
>> >> >> carried forward from the last level in the maps - (and
>> >> >> --min-size-polygon=12 worked fine for resolution 14!)?
>> >> >> In that case mkgmap overview2 should take the following min-sizes -
>> no
>> >> >> matter what is actually defined:
>> >> >>
>> >> >> max min-size by resolution:
>> >> >> 1- resolution 10 or lower (10 is working still in Mapsource, dunno
>> >> about
>> >> >> 9 or lower - I think not)
>> >> >> 2- resolution 11
>> >> >> 3- resolution 12
>> >> >> 6- resolution 13
>> >> >> 12- resolution 14
>> >> >> 24- resolution 15
>> >> >> 48- resolution 16
>> >> >> 96- resolution 17
>> >> >> 192-resolution 18
>> >> >> ..... don't think anything that high makes sense, but better
>> continue
>> >> >> upwards so it causes no problems. As the results are not really
>> >> >> consistent - I would rather take 3 for resolution 12, and not 4 -
>> as
>> >> >> maybe closer/further away from the equator results may differ a
>> bit!
>> >> >> Theese values above, are definitely safe - I never saw missing see
>> >> >> anywhere worldwide while using- min-size-polygon=12 at resolution
>> >> 14...
>> >> >>
>> >> >>
>> >> >>
>> >> >> On 08.05.2013 07:51, GerdP wrote:
>> >> >>> Hi Felix,
>> >> >>>
>> >> >>> do you see the see in the ovm_*.img files? If yes, the problem is
>> in
>> >> the
>> >> >>> part that reads back these files.
>> >> >>>
>> >> >>> Gerd
>> >> >>>
>> >> >>>
>> >> >>> Felix Hartmann-2 wrote
>> >> >>>> On 08.05.2013 02:15, Gerd Petermann wrote:
>> >> >>>>> Hi all,
>> >> >>>>>
>> >> >>>>>> Well, I first thought it would be a Mapsource/Basecamp bug, but
>> >> >>>>> actually
>> >> >>>>>> mkgmap overview2 is not rendering the sea tiles down to
>> resolution
>> >> 12.
>> >> >>>>>> The lowest resolution working is resolution 14... -- at 13 some
>> >> sea is
>> >> >>>>>> rendered, at 12 no sea at all is rendered. I think unlike in my
>> >> >>>>>> earlier
>> >> >>>>>> reply to Henning - that this is some internal bug (maybe
>> related
>> >> to
>> >> >>>>> that
>> >> >>>>>> before 13 was the resolution of the overview map)
>> >> >>>>> I assume the polygons generated by SeaGenerator are too small,
>> >> means,
>> >> >>>>> they are all filtered
>> >> >>>>> in the low resolution levels. Maybe we can implement a
>> >> merge-polygons
>> >> >>>>> function to solve this
>> >> >>>>> problem. Anyway, this is probably not directly related to the
>> >> overview
>> >> >>>>> stuff.
>> >> >>>> that's what I first thought too. But then I looked at a map
>> created
>> >> with
>> >> >>>> the same settings using the old overview2 branch (before multiple
>> >> >>>> levels) - which was done at resolution 13. And there no sea at
>> all
>> >> was
>> >> >>>> missing - while now at 13 it is mostly gone. So I guessed that
>> there
>> >> >>>> must be some other problem...
>> >> >>>>>> Else I really think that the branch can be merged. It is really
>> >> >>>>>> working
>> >> >>>>>> well now... - and I played around a lot with it.
>> >> >>>>> :-)
>> >> >>>>> Please post a diff for the default style (or a zip file
>> containing
>> >> all
>> >> >>>>> files). I do not fully
>> >> >>>>> understand the changes.
>> >> >>>>>
>> >> >>>>>> Only other thing is maybe to have an option to delete / not
>> delete
>> >> the
>> >> >>>>>> ovm*.img files after creation.
>> >> >>>>> Yes, I think an option is ok. I prefer to have the files as it
>> >> helps
>> >> >>>>> debugging.
>> >> >>>>>
>> >> >>>>>> Resolution 12 is great for continent maps like Europe (not
>> fully
>> >> >>>>>> needed
>> >> >>>>>> - 14 could do), or Asia (13 is a must, 12 would be much
>> better).
>> >> >>>>> Please place that knowledge as a comment in the style options
>> file.
>> >> >>>>> Maybe you can also add something to the doc files?
>> >> >>>>>
>> >> >>>>> Gerd
>> >> >>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> _______________________________________________
>> >> >>>>> mkgmap-dev mailing list
>> >> >>>>>
>> >> >>>> mkgmap-dev at .org
>> >> >>>>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>> >> >>>> _______________________________________________
>> >> >>>> mkgmap-dev mailing list
>> >> >>>> mkgmap-dev at .org
>> >> >>>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> --
>> >> >>> View this message in context:
>> >> >>>
>> >>
>> http://gis.19327.n5.nabble.com/overview2-branch-sea-not-rendered-at-resolution-12-tp5760065p5760170.html
>> >> >>> Sent from the Mkgmap Development mailing list archive at
>> Nabble.com.
>> >> >>> _______________________________________________
>> >> >>> mkgmap-dev mailing list
>> >> >>>
>> >> >> mkgmap-dev at .org
>> >> >>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>> >> >> _______________________________________________
>> >> >> mkgmap-dev mailing list
>> >> >> mkgmap-dev at .org
>> >> >> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > View this message in context:
>> >>
>> http://gis.19327.n5.nabble.com/overview2-branch-sea-not-rendered-at-resolution-12-tp5760065p5760224.html
>> >> > Sent from the Mkgmap Development mailing list archive at Nabble.com.
>> >> > _______________________________________________
>> >> > mkgmap-dev mailing list
>> >> >
>>
>> > mkgmap-dev at .org
>>
>> >> > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>> >>
>> >> _______________________________________________
>> >> mkgmap-dev mailing list
>> >>
>>
>> > mkgmap-dev at .org
>>
>> >> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>> >
>> > _______________________________________________
>> > mkgmap-dev mailing list
>>
>> > mkgmap-dev at .org
>>
>> > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://gis.19327.n5.nabble.com/overview2-branch-sea-not-rendered-at-resolution-12-tp5760065p5760508.html
>> Sent from the Mkgmap Development mailing list archive at Nabble.com.
>> _______________________________________________
>> mkgmap-dev mailing list
>> 

> mkgmap-dev at .org

>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
> 
> _______________________________________________
> mkgmap-dev mailing list

> mkgmap-dev at .org

> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

--
View this message in context: http://gis.19327.n5.nabble.com/overview2-branch-sea-not-rendered-at-resolution-12-tp5760065p5760520.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.