Re: [mkgmap-dev] Configurable flood blocker

2010-12-19 Thread 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
attachment: seagen_modes.svg___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Configurable flood blocker

2010-12-19 Thread WanMil
 Felix Hartmann (extremecar...@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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Configurable flood blocker

2010-12-19 Thread Felix Hartmann


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


Re: [mkgmap-dev] Configurable flood blocker

2010-12-18 Thread WanMil
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,
 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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Configurable flood blocker

2010-12-18 Thread Felix Hartmann

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


Re: [mkgmap-dev] Configurable flood blocker

2010-12-18 Thread charlie
Felix Hartmann (extremecar...@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.

-- 
Charlie

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Configurable flood blocker

2010-12-17 Thread Felix Hartmann


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


Re: [mkgmap-dev] Configurable flood blocker

2010-12-17 Thread Minko
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



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Configurable flood blocker

2010-12-17 Thread Felix Hartmann


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


Re: [mkgmap-dev] Configurable flood blocker

2010-12-17 Thread Minko
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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Configurable flood blocker

2010-12-17 Thread Felix Hartmann


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


Re: [mkgmap-dev] Configurable flood blocker

2010-12-17 Thread Minko
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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Configurable flood blocker

2010-12-17 Thread Felix Hartmann


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


Re: [mkgmap-dev] Configurable flood blocker

2010-12-17 Thread WanMil

 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.


Minko,
the parameter is fbgap instead of fbgab. Sorry for the misspelling!

WanMil
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Configurable flood blocker

2010-12-17 Thread 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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Configurable flood blocker

2010-12-17 Thread 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,
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
attachment: sea_polygon.pngattachment: sea_polygon_contra.png___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Configurable flood blocker

2010-12-17 Thread 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,
 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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Configurable flood blocker

2010-12-17 Thread Minko
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?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Configurable flood blocker

2010-12-17 Thread Minko
That will be great! I suppose somebody already uses this option?
Is there a German coastline available?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Configurable flood blocker

2010-12-17 Thread Minko
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 wmgc...@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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Configurable flood blocker

2010-12-13 Thread Steve Ratcliffe

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


Re: [mkgmap-dev] Configurable flood blocker

2010-12-11 Thread 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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Configurable flood blocker

2010-12-08 Thread 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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Configurable flood blocker

2010-12-08 Thread Felix Hartmann


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


Re: [mkgmap-dev] Configurable flood blocker

2010-12-07 Thread Felix Hartmann



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

Re: [mkgmap-dev] Configurable flood blocker

2010-12-05 Thread 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


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


[mkgmap-dev] Configurable flood blocker

2010-12-01 Thread 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