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

Thu May 9 08:15:53 BST 2013

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 at gmail.com
> To: mkgmap-dev at lists.mkgmap.org.uk
> 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 lists.mkgmap.org.uk
> > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> 
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20130509/9a8e391a/attachment-0001.html 