Configurable flood blocker
I have committed an improved version of the flood blocker to the coast branch. It is configurable in some parts (please refer to the help file to the exact config options). What are the improvements now ? 1. I observed that in many good sea polygons there are some highways which are located very close to the edge of the polygon (e.g. a street that ends in the sea). It is now possible to set a gap to ignore these points during the flood blocking algorithm. (Parameter fbgap=NUM (meter)) 2. Now I count the number of land points and sea points in the sea polygon. Given n(bad) = (n(land)-n(sea)) the flood blocker ignores all sea polygons where n(bad) < fbthres (Parameter fbthres=NUM) 3. At least the number of n(bad)/size of polygon gives a ratio. The polygon is removed if the ratio is higher than fbratio. (Default fbratio=0.5) Current rules which coords are used for flood blocking evaluation: Land: highway=* or and not highway=construction not layer!=0 not man_made=pier not man_made=dam not bridge=yes/true/1 not tunnel=yes/true/1 Sea: route=ferry or boundary=administrative and maritime=yes Next I want to add a configuration file for the flood blocking rules. Please try the current version and play a little bit with the options and tell me what you think and if it fits your needs. WanMil
I committed r1746 to the coast branch. The floodblocker rules which OSM elements are used to detect land and as sea areas can now be configured in the special style resources/styles/floodblocker. If this style marks a ways as garmin type 0x01 the way is on land whereas 0x02 is used for sea. Now you can configure your own rules which tag combinations should be used for the flood blocking algorithm. Have fun! WanMil
I have committed an improved version of the flood blocker to the coast branch.
It is configurable in some parts (please refer to the help file to the exact config options).
What are the improvements now ? 1. I observed that in many good sea polygons there are some highways which are located very close to the edge of the polygon (e.g. a street that ends in the sea). It is now possible to set a gap to ignore these points during the flood blocking algorithm. (Parameter fbgap=NUM (meter))
2. Now I count the number of land points and sea points in the sea polygon. Given n(bad) = (n(land)-n(sea)) the flood blocker ignores all sea polygons where n(bad)< fbthres (Parameter fbthres=NUM)
3. At least the number of n(bad)/size of polygon gives a ratio. The polygon is removed if the ratio is higher than fbratio. (Default fbratio=0.5)
Current rules which coords are used for flood blocking evaluation: Land: highway=* or and not highway=construction not layer!=0 not man_made=pier not man_made=dam not bridge=yes/true/1 not tunnel=yes/true/1
Sea: route=ferry or boundary=administrative and maritime=yes
Next I want to add a configuration file for the flood blocking rules.
Please try the current version and play a little bit with the options and tell me what you think and if it fits your needs.
WanMil _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 05.12.2010 15:48, WanMil wrote:
I committed r1746 to the coast branch. The floodblocker rules which OSM elements are used to detect land and as sea areas can now be configured in the special style resources/styles/floodblocker. If this style marks a ways as garmin type 0x01 the way is on land whereas 0x02 is used for sea. Now you can configure your own rules which tag combinations should be used for the flood blocking algorithm.
Have fun! WanMil
I have used it without problems, however currently all geofabrik extracts I had used (even Australia/Oceania or Lower Saxony) worked on the old version without problems too, while often these extracts caused severe flooding (haven't got any broken extracts saved however)... Also not really sure if my command line makes sense: /generate-sea=--generate-sea=extend-sea-sectors,close-gaps=6000,floodblocker,fbgap=50,fbthres=500,fbratio=5/ (until now I have been using: /generate-sea=--generate-sea=polygons,extend-sea-sectors,close-gaps=6000/ ) I think it is safe to commit the coast branch to trunk (and maybe include some defaults in the help file, especially I have no clue about a sensible fbration value), I could not note any problems.....
On 05.12.2010 15:48, WanMil wrote:
I committed r1746 to the coast branch. The floodblocker rules which OSM elements are used to detect land and as sea areas can now be configured in the special style resources/styles/floodblocker. If this style marks a ways as garmin type 0x01 the way is on land whereas 0x02 is used for sea. Now you can configure your own rules which tag combinations should be used for the flood blocking algorithm.
Have fun! WanMil
I have used it without problems, however currently all geofabrik extracts I had used (even Australia/Oceania or Lower Saxony) worked on the old version without problems too, while often these extracts caused severe flooding (haven't got any broken extracts saved however)... Also not really sure if my command line makes sense: /generate-sea=--generate-sea=extend-sea-sectors,close-gaps=6000,floodblocker,fbgap=50,fbthres=500,fbratio=5/
(until now I have been using: /generate-sea=--generate-sea=polygons,extend-sea-sectors,close-gaps=6000/ )
I think it is safe to commit the coast branch to trunk (and maybe include some defaults in the help file, especially I have no clue about a sensible fbration value), I could not note any problems.....
Felix, thanks for testing! Yesterday I have committed that the multipolygon sea generation also creates land polygons. This should fix a shortcoming which prevented some users from using the mulitpolygon sea generation. What I am interested in at the moment: Does the external coastline file loading fit your needs? I am a bit concerned about memory requirements and would like to decrease its memory footprint. The following things should be done before merging back the branch to trunk: * Improve multipolygon processing performance for sea polygons. The mp algorithm can count on the "outer" and "inner" tags so the matrix which polygon is contained by which polygon should be less complex to create * @Steve: Can you check if my changes to the ElementSaver class and my coastfile loading mechanism feels good for you? Maybe you want to simplify some things? * Decrease memory footprint of the coastline file loading. (Maybe this could also be done after merging back). Have fun! WanMil
On 08.12.2010 20:50, WanMil wrote:
On 05.12.2010 15:48, WanMil wrote:
I committed r1746 to the coast branch. The floodblocker rules which OSM elements are used to detect land and as sea areas can now be configured in the special style resources/styles/floodblocker. If this style marks a ways as garmin type 0x01 the way is on land whereas 0x02 is used for sea. Now you can configure your own rules which tag combinations should be used for the flood blocking algorithm.
Have fun! WanMil
I have used it without problems, however currently all geofabrik extracts I had used (even Australia/Oceania or Lower Saxony) worked on the old version without problems too, while often these extracts caused severe flooding (haven't got any broken extracts saved however)... Also not really sure if my command line makes sense: /generate-sea=--generate-sea=extend-sea-sectors,close-gaps=6000,floodblocker,fbgap=50,fbthres=500,fbratio=5/
(until now I have been using: /generate-sea=--generate-sea=polygons,extend-sea-sectors,close-gaps=6000/ )
I think it is safe to commit the coast branch to trunk (and maybe include some defaults in the help file, especially I have no clue about a sensible fbration value), I could not note any problems.....
Felix,
thanks for testing!
Yesterday I have committed that the multipolygon sea generation also creates land polygons. This should fix a shortcoming which prevented some users from using the mulitpolygon sea generation.
okay great, I prefer multipolygon mode (makes maps without land/sea overlap if --transparent is used).
What I am interested in at the moment: Does the external coastline file loading fit your needs? I am a bit concerned about memory requirements and would like to decrease its memory footprint. I have not tried that out yet - I usually only compile single geofabrik country extracts (and Africa, South-America and Australia-Oceania Extracts). For external coastlines to be useful, I'ld need them handy to mix with the geofabrik extracts... Suppose if coastlines for the extracts were available, that would be the best thing... -- Where can one get coastline extracts - anyone providing them?
The following things should be done before merging back the branch to trunk: * Improve multipolygon processing performance for sea polygons. The mp algorithm can count on the "outer" and "inner" tags so the matrix which polygon is contained by which polygon should be less complex to create * @Steve: Can you check if my changes to the ElementSaver class and my coastfile loading mechanism feels good for you? Maybe you want to simplify some things? * Decrease memory footprint of the coastline file loading. (Maybe this could also be done after merging back).
Have fun! WanMil
On 05.12.2010 15:48, WanMil wrote:
I committed r1746 to the coast branch. The floodblocker rules which OSM elements are used to detect land and as sea areas can now be configured in the special style resources/styles/floodblocker. If this style marks a ways as garmin type 0x01 the way is on land whereas 0x02 is used for sea. Now you can configure your own rules which tag combinations should be used for the flood blocking algorithm.
Have fun! WanMil
I have used it without problems, however currently all geofabrik extracts I had used (even Australia/Oceania or Lower Saxony) worked on the old version without problems too, while often these extracts caused severe flooding (haven't got any broken extracts saved however)... Also not really sure if my command line makes sense: /generate-sea=--generate-sea=extend-sea-sectors,close-gaps=6000,floodblocker,fbgap=50,fbthres=500,fbratio=5/
(until now I have been using: /generate-sea=--generate-sea=polygons,extend-sea-sectors,close-gaps=6000/ )
I think it is safe to commit the coast branch to trunk (and maybe include some defaults in the help file, especially I have no clue about a sensible fbration value), I could not note any problems.....
Felix,
thanks for testing!
Yesterday I have committed that the multipolygon sea generation also creates land polygons. This should fix a shortcoming which prevented some users from using the mulitpolygon sea generation.
What I am interested in at the moment: Does the external coastline file loading fit your needs? I am a bit concerned about memory requirements and would like to decrease its memory footprint.
The following things should be done before merging back the branch to trunk: * Improve multipolygon processing performance for sea polygons. The mp algorithm can count on the "outer" and "inner" tags so the matrix which polygon is contained by which polygon should be less complex to create * @Steve: Can you check if my changes to the ElementSaver class and my coastfile loading mechanism feels good for you? Maybe you want to simplify some things? * Decrease memory footprint of the coastline file loading. (Maybe this could also be done after merging back).
Have fun! WanMil
The performance improvement does not work. So from my point of view the coast branch can be merged back to trunk. Any objections to this? WanMil
* @Steve: Can you check if my changes to the ElementSaver class and my coastfile loading mechanism feels good for you? Maybe you want to simplify some things?
Yes it looks fine to me. Anyway it is more important to get useful features working for people. I'd merge it back, seems everyone is happy with it so far. You can always continue with more changes on the branch or re-create it for more stuff. Thanks ..Steve
On 08.12.2010 20:50, WanMil wrote:
On 05.12.2010 15:48, WanMil wrote:
I committed r1746 to the coast branch. The floodblocker rules which OSM elements are used to detect land and as sea areas can now be configured in the special style resources/styles/floodblocker. If this style marks a ways as garmin type 0x01 the way is on land whereas 0x02 is used for sea. Now you can configure your own rules which tag combinations should be used for the flood blocking algorithm.
Have fun! WanMil
I have used it without problems, however currently all geofabrik extracts I had used (even Australia/Oceania or Lower Saxony) worked on the old version without problems too, while often these extracts caused severe flooding (haven't got any broken extracts saved however)... Also not really sure if my command line makes sense: /generate-sea=--generate-sea=extend-sea-sectors,close-gaps=6000,floodblocker,fbgap=50,fbthres=500,fbratio=5/
(until now I have been using: /generate-sea=--generate-sea=polygons,extend-sea-sectors,close-gaps=6000/ )
I think it is safe to commit the coast branch to trunk (and maybe include some defaults in the help file, especially I have no clue about a sensible fbration value), I could not note any problems.....
Felix,
thanks for testing!
Yesterday I have committed that the multipolygon sea generation also creates land polygons. This should fix a shortcoming which prevented some users from using the mulitpolygon sea generation.
Hi WanMil, I just noted, the multipolygon mode does not work. The floodblocker does not seem to show any effect. Do you need a testfile for this? (I had a 2 tiles in Germany flooded, even though using values that should have blocked the sea easily, hence I thought let's try out what it gives taking "polygons" out of the commandline, and bang, the flooding disappeared!
I tested the floodblocker on the Benelux abstract from http://planet.openstreetmap.nl/ The options in my mkgmap args file were: generate-sea: multipolygon,floodblocker,land-tag=natural=background The parameter fbgab gives an error (I'm using java under windows). I tried different settings for fbthres,fbratio but no sea came back on my map. See the results here: http://img155.imageshack.us/img155/2873/bnlj.jpg Only one tile where the sea remained, the rest was completely gone. This is how it looked without the floodblocker: http://img33.imageshack.us/img33/8382/52519932.jpg Mkgmap settings are generate-sea: no-mp,extend-sea-sectors,close-gaps=1000,land-tag=natural=background Not good either but still the sea is there (too much sea though). Usually I use the europe.osm.pbf extract and split it, without problems of flooding. Since a few weeks there are problems with the europe pbf file under windows, so I have to find an alternative. The Benelux abstract from http://planet.openstreetmap.nl/ shows flooding because it lacks some German coastline, in particular this way is not part of it: http://www.openstreetmap.org/browse/way/4102027 I hoped that Wanmils floodblocker could solve this but it unfortunately it couldn't. Is there another way to merge this coastline to the splitted osm tile? Cheers, Minko
On 17.12.2010 11:54, Minko wrote:
I tested the floodblocker on the Benelux abstract from http://planet.openstreetmap.nl/ The options in my mkgmap args file were: generate-sea: multipolygon,floodblocker,land-tag=natural=background
The parameter fbgab gives an error (I'm using java under windows). I tried different settings for fbthres,fbratio but no sea came back on my map.
See the results here: http://img155.imageshack.us/img155/2873/bnlj.jpg
Only one tile where the sea remained, the rest was completely gone.
This is how it looked without the floodblocker: http://img33.imageshack.us/img33/8382/52519932.jpg
Mkgmap settings are generate-sea: no-mp,extend-sea-sectors,close-gaps=1000,land-tag=natural=background
Not good either but still the sea is there (too much sea though). Usually I use the europe.osm.pbf extract and split it, without problems of flooding. Since a few weeks there are problems with the europe pbf file under windows, so I have to find an alternative. The Benelux abstract from http://planet.openstreetmap.nl/ shows flooding because it lacks some German coastline, in particular this way is not part of it: http://www.openstreetmap.org/browse/way/4102027
I hoped that Wanmils floodblocker could solve this but it unfortunately it couldn't. Is there another way to merge this coastline to the splitted osm tile?
You did not read my message, and on top you put two times different mkgmap options. Multipolygon is the opposite of no-mp/polygons. "generate-sea: no-mp,extend-sea-sectors,close-gaps=1000,land-tag=natural=background" is broken. Use "generate-sea: extend-sea-sectors,close-gaps=1000,land-tag=natural=background" instead, which will work.
Cheers, Minko
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Sorry Felix, but I have read your message. you wrote: "I just noted, the multipolygon mode does not work. The floodblocker does not seem to show any effect" I used multipolygon, because Wanmil adviced me to do so, because otherwise the floodblocker didn't work. So, I did, and I noticed the floodblocker did his job very well. All the sea except one tile disappeared. Thanks for your advice, I will test it now without the floodblocker option and with extend-sea-sectors (without no-mp). Minko
On 17.12.2010 12:09, Minko wrote:
Sorry Felix, but I have read your message.
you wrote: "I just noted, the multipolygon mode does not work. The floodblocker does not seem to show any effect"
I used multipolygon, because Wanmil adviced me to do so, because otherwise the floodblocker didn't work. So, I did, and I noticed the floodblocker did his job very well. All the sea except one tile disappeared.
Thanks for your advice, I will test it now without the floodblocker option and with extend-sea-sectors (without no-mp).
Minko _______________________________________________
The floodblocker is independatnt of extend-sea-sectors, and has to be used as well. At least for my understanding. In effect the polygons // no-mp mode does not work, I mixed it up in the description, as I put down the first text without thinking too much due to the above quote (before only the multipolygon worked, and after too - polygons or no-mp has not yet worked in any revision).
Thanks Felix, I tested it now with: extend-sea-sectors,close-gaps=6000,floodblocker,fbgap=60,fbthres=200,fbratio=0.6,land-tag=natural=background No errors and sea polygons came back, but the floodblocker blocks still too much. I've tried it with other fb numbers but it still gives the same picture: http://img404.imageshack.us/img404/3702/nogroningen.jpg The tested tile you can download at http://mijndev.openstreetmap.nl/~ligfietser/diverse/Test.zip
On 17.12.2010 13:19, Minko wrote:
Thanks Felix, I tested it now with: extend-sea-sectors,close-gaps=6000,floodblocker,fbgap=60,fbthres=200,fbratio=0.6,land-tag=natural=background
No errors and sea polygons came back, but the floodblocker blocks still too much. I've tried it with other fb numbers but it still gives the same picture:
Nope it does not block too much. It blocks one tile, that's what it's supposed to do. There cannot be remove see only from where there are streets, else it would put see into areas where there is no clue about sea or land.
Thanks Felix, I tested it now with: extend-sea-sectors,close-gaps=6000,floodblocker,fbgap=60,fbthres=200,fbratio=0.6,land-tag=natural=background
No errors and sea polygons came back, but the floodblocker blocks still too much. I've tried it with other fb numbers but it still gives the same picture:
http://img404.imageshack.us/img404/3702/nogroningen.jpg
The tested tile you can download at http://mijndev.openstreetmap.nl/~ligfietser/diverse/Test.zip
Minko, I will download your test data and give it a try. If you want to get detailed information what the flood blocker is doing, you should enable an appropriate logging. See http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg02381.html how the logging.properties file can be configured and add the line uk.me.parabola.mkgmap.reader.osm.SeaPolygonRelation.level=INFO to the logging.properties file. You might also add the parameter fbdebug to the sea-generation options. In this case the flood blocker creates GPX files for each checked polygon and the pro blocking (highways) and the contra blocking (ferry routes) points. Opening these files with JOSM makes it easier to understand why the flood blocker fails. WanMil
Thanks Felix, I tested it now with: extend-sea-sectors,close-gaps=6000,floodblocker,fbgap=60,fbthres=200,fbratio=0.6,land-tag=natural=background
No errors and sea polygons came back, but the floodblocker blocks still too much. I've tried it with other fb numbers but it still gives the same picture:
http://img404.imageshack.us/img404/3702/nogroningen.jpg
The tested tile you can download at http://mijndev.openstreetmap.nl/~ligfietser/diverse/Test.zip
Minko,
I will download your test data and give it a try.
If you want to get detailed information what the flood blocker is doing, you should enable an appropriate logging. See http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg02381.html how the logging.properties file can be configured and add the line uk.me.parabola.mkgmap.reader.osm.SeaPolygonRelation.level=INFO to the logging.properties file.
You might also add the parameter fbdebug to the sea-generation options. In this case the flood blocker creates GPX files for each checked polygon and the pro blocking (highways) and the contra blocking (ferry routes) points. Opening these files with JOSM makes it easier to understand why the flood blocker fails.
WanMil
Ok, I have tested the tile with your parameters. The sea generator created one big sea polygon (sea_polygon.png). As you can see the polygon is erroneous because it intersects itself. This is caused by the incomplete coast data in the tile which squeezes the sea generator to guess how the real sea polygon looks like. I must admit that a check could be added if the polygon intersects itself and in this case the sea sector extension could try some other completion strategies. (But that's not a task of the flood blocker and I guess it would be a performance problem.) Without the flood blocker large areas near the german border would be flooded. The flood blocker detects that (see sea_polygon_contra.png) by checking how many blocking points are contained in the polygon. In this case there were 26602 points within the sea polygon and therefore the polygon was converted from sea to land polygon. As a result the flood blocker worked perfectly! You can see the result of the flood blocker in the logfile: Flood blocker for sea polygon 4611686018427390756 area 476449303,0000 sea 125 land 26602 ratio 5,5571 Polygon 4611686018427390756 type sea seems to be wrong. Changing it to land So from my point of view this was a good test case for the flood blocker and it worked as expected. Have fun! WanMil
On 17.12.2010 16:45, WanMil wrote:
Thanks Felix, I tested it now with: extend-sea-sectors,close-gaps=6000,floodblocker,fbgap=60,fbthres=200,fbratio=0.6,land-tag=natural=background
No errors and sea polygons came back, but the floodblocker blocks still too much. I've tried it with other fb numbers but it still gives the same picture:
http://img404.imageshack.us/img404/3702/nogroningen.jpg
The tested tile you can download at http://mijndev.openstreetmap.nl/~ligfietser/diverse/Test.zip
Minko,
I will download your test data and give it a try.
If you want to get detailed information what the flood blocker is doing, you should enable an appropriate logging. See http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg02381.html how the logging.properties file can be configured and add the line uk.me.parabola.mkgmap.reader.osm.SeaPolygonRelation.level=INFO to the logging.properties file.
You might also add the parameter fbdebug to the sea-generation options. In this case the flood blocker creates GPX files for each checked polygon and the pro blocking (highways) and the contra blocking (ferry routes) points. Opening these files with JOSM makes it easier to understand why the flood blocker fails.
WanMil
Ok, I have tested the tile with your parameters. The sea generator created one big sea polygon (sea_polygon.png). As you can see the polygon is erroneous because it intersects itself. This is caused by the incomplete coast data in the tile which squeezes the sea generator to guess how the real sea polygon looks like. I must admit that a check could be added if the polygon intersects itself and in this case the sea sector extension could try some other completion strategies. (But that's not a task of the flood blocker and I guess it would be a performance problem.)
Without the flood blocker large areas near the german border would be flooded. The flood blocker detects that (see sea_polygon_contra.png) by checking how many blocking points are contained in the polygon. In this case there were 26602 points within the sea polygon and therefore the polygon was converted from sea to land polygon. As a result the flood blocker worked perfectly!
You can see the result of the flood blocker in the logfile: Flood blocker for sea polygon 4611686018427390756 area 476449303,0000 sea 125 land 26602 ratio 5,5571 Polygon 4611686018427390756 type sea seems to be wrong. Changing it to land
So from my point of view this was a good test case for the flood blocker and it worked as expected.
Have fun! WanMil Well can you check why it does not work when giving "polygons" or "no-mp" as command? Multipolygon mode is not really the best solution....
Am 17.12.2010 16:49, schrieb Felix Hartmann:
On 17.12.2010 16:45, WanMil wrote:
Thanks Felix, I tested it now with: extend-sea-sectors,close-gaps=6000,floodblocker,fbgap=60,fbthres=200,fbratio=0.6,land-tag=natural=background
No errors and sea polygons came back, but the floodblocker blocks still too much. I've tried it with other fb numbers but it still gives the same picture:
http://img404.imageshack.us/img404/3702/nogroningen.jpg
The tested tile you can download at http://mijndev.openstreetmap.nl/~ligfietser/diverse/Test.zip
Minko,
I will download your test data and give it a try.
If you want to get detailed information what the flood blocker is doing, you should enable an appropriate logging. See http://www.mail-archive.com/mkgmap-dev@lists.mkgmap.org.uk/msg02381.html how the logging.properties file can be configured and add the line uk.me.parabola.mkgmap.reader.osm.SeaPolygonRelation.level=INFO to the logging.properties file.
You might also add the parameter fbdebug to the sea-generation options. In this case the flood blocker creates GPX files for each checked polygon and the pro blocking (highways) and the contra blocking (ferry routes) points. Opening these files with JOSM makes it easier to understand why the flood blocker fails.
WanMil
Ok, I have tested the tile with your parameters. The sea generator created one big sea polygon (sea_polygon.png). As you can see the polygon is erroneous because it intersects itself. This is caused by the incomplete coast data in the tile which squeezes the sea generator to guess how the real sea polygon looks like. I must admit that a check could be added if the polygon intersects itself and in this case the sea sector extension could try some other completion strategies. (But that's not a task of the flood blocker and I guess it would be a performance problem.)
Without the flood blocker large areas near the german border would be flooded. The flood blocker detects that (see sea_polygon_contra.png) by checking how many blocking points are contained in the polygon. In this case there were 26602 points within the sea polygon and therefore the polygon was converted from sea to land polygon. As a result the flood blocker worked perfectly!
You can see the result of the flood blocker in the logfile: Flood blocker for sea polygon 4611686018427390756 area 476449303,0000 sea 125 land 26602 ratio 5,5571 Polygon 4611686018427390756 type sea seems to be wrong. Changing it to land
So from my point of view this was a good test case for the flood blocker and it worked as expected.
Have fun! WanMil Well can you check why it does not work when giving "polygons" or "no-mp" as command? Multipolygon mode is not really the best solution....
Felix, there is nothing to check. The flood blocker works only in multipolygon mode. It is not possible to implement that for the polygon mode. Where do you think is the advantage of the polygon mode? WanMil
Felix,
there is nothing to check. The flood blocker works only in multipolygon mode. It is not possible to implement that for the polygon mode.
Where do you think is the advantage of the polygon mode?
WanMil The advantage is:
a) Speed (if you use --transparent and then gmt to set the transparency to no) you can have for land one polygon (only land area) for sea one polygon (only sea area) and NO background polygon. b) overlapping maps - using --transparent there is less chance that a land polygon from one map, overlaps sea from another map (on GPS as only there can be several maps active at the same time). --- in principal there is no speed advantage - but only as long as one does not attribute a color to 0x4b, however as one colors the background/land to be say white, it is much quicker to have white land background only, otherwise the GPS has to read much more data, and on older generation GPS when panning the map, there is a notable speed difference on top of flahing up background color, until it is overdrawn by the real landuse/natural/... polygon.
Felix Hartmann (extremecarver@gmail.com) wrote:
[snip]
--- in principal there is no speed advantage - [snip]
Maybe it's just me, but I find the polygon version of generate-sea much faster than the multipolygon version - at least twice as fast if not more.
The multipolygon version increases the time needed for map creation. The question in this thread is if the rendering on the GPS device is quicker or not. WanMil
Felix,
there is nothing to check. The flood blocker works only in multipolygon mode. It is not possible to implement that for the polygon mode.
Where do you think is the advantage of the polygon mode?
WanMil The advantage is:
a) Speed (if you use --transparent and then gmt to set the transparency to no) you can have for land one polygon (only land area) for sea one polygon (only sea area) and NO background polygon. b) overlapping maps - using --transparent there is less chance that a land polygon from one map, overlaps sea from another map (on GPS as only there can be several maps active at the same time).
--- in principal there is no speed advantage - but only as long as one does not attribute a color to 0x4b, however as one colors the background/land to be say white, it is much quicker to have white land background only, otherwise the GPS has to read much more data, and on older generation GPS when panning the map, there is a notable speed difference on top of flahing up background color, until it is overdrawn by the real landuse/natural/... polygon.
I don't want to put into question your final observation (polygon renders quicker on GPS device) but I cannot follow your arguments. Let's try to sort it out. Please correct me at any point if I am wrong. I have added a picture for both sea generation methods. It shows the resulting tile and all polygons contained in the tile. * First of all the new mp code in the coast branch generates land polygons. This is a new feature. So land+sea polygons=tile. * The polygon code creates one sea polygon covering the whole tile and adds all land polygons. The style implementor must ensure that land is drawn over sea. Otherwise the tile is flooded. * For tiles that don't contain any see one land polygon covering the whole tile is created (both for polygon and multipolygon processing). => a): For both variants you don't need a background polygon. The whole tile is covered by sea or land. => b): I don't understand where there should be the difference between polygon and multipolygon processing. => in principal: Do you mean that you don't want to paint land polygons but instead the background polygon? Ok, but in this case you can ignore the land polygon in the multipolgon variant but not in the polygon variant. Otherwise the background is painted and after that the sea is painted over it and you get flooded tiles. So you need to color the land polygons. The multipolygon processing generates much more complex polygons. I think that's the reason why it is rendered more slowly on GPS devices. WanMil
On 19.12.2010 18:17, WanMil wrote:
Felix,
there is nothing to check. The flood blocker works only in multipolygon mode. It is not possible to implement that for the polygon mode.
Where do you think is the advantage of the polygon mode?
WanMil The advantage is:
a) Speed (if you use --transparent and then gmt to set the transparency to no) you can have for land one polygon (only land area) for sea one polygon (only sea area) and NO background polygon. b) overlapping maps - using --transparent there is less chance that a land polygon from one map, overlaps sea from another map (on GPS as only there can be several maps active at the same time).
--- in principal there is no speed advantage - but only as long as one does not attribute a color to 0x4b, however as one colors the background/land to be say white, it is much quicker to have white land background only, otherwise the GPS has to read much more data, and on older generation GPS when panning the map, there is a notable speed difference on top of flahing up background color, until it is overdrawn by the real landuse/natural/... polygon.
I don't want to put into question your final observation (polygon renders quicker on GPS device) but I cannot follow your arguments. Let's try to sort it out. Please correct me at any point if I am wrong.
I have added a picture for both sea generation methods. It shows the resulting tile and all polygons contained in the tile.
* First of all the new mp code in the coast branch generates land polygons. This is a new feature. So land+sea polygons=tile. * The polygon code creates one sea polygon covering the whole tile and adds all land polygons. The style implementor must ensure that land is drawn over sea. Otherwise the tile is flooded. * For tiles that don't contain any see one land polygon covering the whole tile is created (both for polygon and multipolygon processing).
=> a): For both variants you don't need a background polygon. The whole tile is covered by sea or land. => b): I don't understand where there should be the difference between polygon and multipolygon processing. => in principal: Do you mean that you don't want to paint land polygons but instead the background polygon? Ok, but in this case you can ignore the land polygon in the multipolgon variant but not in the polygon variant. Otherwise the background is painted and after that the sea is painted over it and you get flooded tiles. So you need to color the land polygons.
The multipolygon processing generates much more complex polygons. I think that's the reason why it is rendered more slowly on GPS devices.
WanMil I have not checked the speed after the change on GPS. I'll do that and then report back. Before definitely the quickest was --transparent and --polygons. (as I set the opqaque switch with gmaptool afterwards, I of course colored the land polygon - but the maps had no background polygon at all).
Thanks Wanmil, Those images explained very well what exactly happens. So what I can do is to add more coastline to the benelux osm data to prevent that this coastline is intercepting itself. I have to merge osm data (German coastline) to the osm data from the Benelux extract. How does this work with osmosis? Or is it possible with mkgmap to combine the coastline with osm tiles?
Thanks Wanmil, Those images explained very well what exactly happens.
So what I can do is to add more coastline to the benelux osm data to prevent that this coastline is intercepting itself. I have to merge osm data (German coastline) to the osm data from the Benelux extract. How does this work with osmosis? Or is it possible with mkgmap to combine the coastline with osm tiles?
You can load a separate coastline file using the option coastlinefile=coastlines1.osm.pbf,coastlines2.osm.pbf When using this option the coastlines of your tiles are ignored and are only taken from the given file(s). The file(s) need not contain only coastlines but I think using the complete original benelux and german files here will not be possible due to memory problems. You can use osmosis (please read the osmosis documentation!) to extract the coastlines. The osmosis call might look like: osmosis.bat -rb europe.osm.pbf -tf accept-ways natural=coastline -tf reject-relations --used-node -wb europe_coasts.osm.pbf WanMil
That will be great! I suppose somebody already uses this option? Is there a German coastline available?
Hi Wanmil, Just letting you know I solved the floodings problem. My tile borders stretched too far east, far beyond the extract. By ending it more to the west, the sea disappeared :-) I even didn't have to use a floodblocker. Thanks for your help! Minko ----- Oorspronkelijk bericht ----- Van: "WanMil" <wmgcnfg@web.de> Aan: "Development list for mkgmap" <mkgmap-dev@lists.mkgmap.org.uk> Verzonden: Vrijdag 17 december 2010 18:30:48 Onderwerp: Re: [mkgmap-dev] Configurable flood blocker
Thanks Wanmil, Those images explained very well what exactly happens.
So what I can do is to add more coastline to the benelux osm data to prevent that this coastline is intercepting itself. I have to merge osm data (German coastline) to the osm data from the Benelux extract. How does this work with osmosis? Or is it possible with mkgmap to combine the coastline with osm tiles?
You can load a separate coastline file using the option coastlinefile=coastlines1.osm.pbf,coastlines2.osm.pbf When using this option the coastlines of your tiles are ignored and are only taken from the given file(s). The file(s) need not contain only coastlines but I think using the complete original benelux and german files here will not be possible due to memory problems. You can use osmosis (please read the osmosis documentation!) to extract the coastlines. The osmosis call might look like: osmosis.bat -rb europe.osm.pbf -tf accept-ways natural=coastline -tf reject-relations --used-node -wb europe_coasts.osm.pbf WanMil _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (5)
-
charlie＠cferrero.net -
Felix Hartmann -
Minko -
Steve Ratcliffe -
WanMil