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@.org
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
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@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev