overview2 branch -- sea not rendered at resolution 12
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) Else I really think that the branch can be merged. It is really working well now... - and I played around a lot with it. Only other thing is maybe to have an option to delete / not delete the ovm*.img files after creation. 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). Great stuff!
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.
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
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@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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
-- 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.
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@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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
-- 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.
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
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@gmail.com To: mkgmap-dev@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@.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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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).
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
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: 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
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
_______________________________________________ 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.
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@hotmail.com> 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).
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
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: 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
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
_______________________________________________ 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@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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@
> 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).
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
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: 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
_______________________________________________ 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
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.
Here you go - all individual files / diff based on the current overview2
branch - default style.
On 10 May 2013 13:15, GerdP <gpetermann_muenchen@hotmail.com> 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@
>
> > > 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
> 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
> >> >> >>>>> 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-resolution-12-tp5760065p5760170.html
> >> >> >>> 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-resolution-12-tp5760065p5760224.html
> >> >> > 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
> >> >
> >> > _______________________________________________
> >> > 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-resolution-12-tp5760065p5760508.html
> >> 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-resolution-12-tp5760065p5760520.html
> 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
>
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.
Hi,
Only other thing is maybe to have an option to delete / not delete the ovm*.img files after creation. I've implemented an option in r2594: --remove-ovm-work-files If overview-levels is used, mkgmap creates one additional file with the prefix ovm_ for each map (*.img) file. These files are used to create the overview map. With option --remove-ovm-work-files=true the files are removed after the overview map was created. The default is to keep the files.
Gerd
Hi Gerd, Maybe it is better to remove them by default. Most people won't need those files.
I've implemented an option in r2594: --remove-ovm-work-files If overview-levels is used, mkgmap creates one additional file with the prefix ovm_ for each map (*.img) file. These files are used to create the overview map. With option --remove-ovm-work-files=true the files are removed after the overview map was created. The default is to keep the files.
Gerd
Hi Minko, it that case I think the option should be --keep-ovm-work-files with the default "false". Gerd
Date: Wed, 8 May 2013 10:35:30 +0200 From: ligfietser@online.nl To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] overview2 branch -- sea not rendered at resolution 12
Hi Gerd, Maybe it is better to remove them by default. Most people won't need those files.
I've implemented an option in r2594: --remove-ovm-work-files If overview-levels is used, mkgmap creates one additional file with the prefix ovm_ for each map (*.img) file. These files are used to create the overview map. With option --remove-ovm-work-files=true the files are removed after the overview map was created. The default is to keep the files.
Gerd
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (5)
-
Felix Hartmann -
Gerd Petermann -
GerdP
-
Minko -
WanMil