Hi Felix, thanks, they are committed. I'll try to update the doc files over the weekend. If that works well, I think the merge to trunk is near. Gerd Felix Hartmann-2 wrote
Here you go - all individual files / diff based on the current overview2 branch - default style.
On 10 May 2013 13:15, GerdP <
gpetermann_muenchen@
> wrote:
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 <
gpetermann_muenchen@
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@.org >>>>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >>>> _______________________________________________ >>>> mkgmap-dev mailing list >>>> mkgmap-dev@.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-resoluti...
>>> Sent from the Mkgmap Development mailing list archive at Nabble.com. >>> _______________________________________________ >>> mkgmap-dev mailing list >>> >> mkgmap-dev@.org >>> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> _______________________________________________ >> mkgmap-dev mailing list >> mkgmap-dev@.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-resoluti...
> Sent from the Mkgmap Development mailing list archive at Nabble.com. > _______________________________________________ > mkgmap-dev mailing list >
mkgmap-dev@.org
> http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context:
http://gis.19327.n5.nabble.com/overview2-branch-sea-not-rendered-at-resoluti...
Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
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
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
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@.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
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/overview2-branch-sea-not-rendered-at-resoluti... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
overview2_default_style_adaptions.zip (11K) <http://gis.19327.n5.nabble.com/attachment/5760524/0/overview2_default_style_...;
-- View this message in context: http://gis.19327.n5.nabble.com/overview2-branch-sea-not-rendered-at-resoluti... Sent from the Mkgmap Development mailing list archive at Nabble.com.