- mkgmap-dev - The mkgmap lists

[mp: PATCH] Multipolygon handling - decomposed polygons
by WanMil 10 Jan '10

10 Jan '10

I have made some improvements to the multipolygon branch. Changes: * Polygons with inner polygons are now divided into several polygons. It's much faster and the PolygonSplitter cannot destroy them any more. * Improved tag handling. The tags from original ways are removed. This has the disadvantage that non polygon tags like highway are destroyed. This must be fixed within one of the next patches. * Added a FakeIdGenerator that creates unique fake ids for elements created by mkgmap. The Osm5XmlHandler has been adapted to that. As before I am happy about any (good and bad) feedback!! WanMil Note: The code is not ready for the trunk. Some documentation and better method naming will be applied in one of the next patch.

7 17

Multipolygons and bounding box / bounding shape
by WanMil 10 Jan '10

10 Jan '10

I am trying to close polygons that are divided by the splitter or that are located on the border of the OSM dumps. The OSM dumps are a problem for me as they don't have a rectangular bounding box. The bbox variable of the Osm5XmlHandler gives a rectangular boundig box only. Is there any possibility to get the more or less exact bounding shape of an OSM dump? Otherwise I don't see any chance to close polygons reasonable. WanMil

1 0

Inter tile routing
by Stefan 09 Jan '10

09 Jan '10

Hello, in the archive (september 2009) I saw that there were some discussion about inter tile routing problems. I use version 1445 and have the same problem when doing a routing in Mapsource over 4 interceptions. 3 interceptions working fine. Are there some news about that issue? Another question: Is there a possibility to see the changes in the current mkgmap version? Thanks! Regards Stefan

4 3

Feedback on --generate-sea
by Charlie Ferrero 09 Jan '10

09 Jan '10

Firstly, Mark, many thanks for working on the sea polygon issue. I've found two problems with --generate-sea. One is relatively minor, the other a bit more of a problem. 1 (minor). If you use an options file via the mgkmap -c switch, the comma separated list of generate-sea sub-options cannot have any spaces, or you get an error generate-sea:polygons,no-sea-sectors works fine, but generate-sea:polygons, no-sea-sectors results in the error: Unknown sea generation option ' no-sea-sectors' Known sea generation options are: multipolygon use a multipolygon (default) polygons | no-mp use polygons rather than a multipolygon no-sea-sectors disable use of "sea sectors" land-tag=TAG=VAL tag to use for land polygons (default natural=land) 2 (major). If an island border has the tags natural=coastline boundary=administrative Then, using Mark Burton's style (or even the default style) these islands get flooded. Attached is a screenshot taken from the Geofabrik Italy extract showing the whole of Sicily flooded. Other islands that don't have a coastline containing a boundary=administrative tag are fine. The only way to stop the flooding is to remove the boundary=administrative rule completely. This is strange because as the natural=coastline rule occurs first (in both the default and in Mark's style) then the coastline should be set before any administrative boundary rule matches. -- Charlie

2 1

Re: [mkgmap-dev] Suggestion - Make Douglas Peucker Algorithm more Configurable
by Johann Gail 08 Jan '10

08 Jan '10

>>> That patch works pretty nice. I upped the value to 40 and that gave >>> nice results when zoomed far out. >>> Here is the settings that I would find optimal >>> resolution 24 == 4 (I think 4 is anyhow the minimum because if less >>> than 4 pixels than it ain't an area) >>> resolution 23 == 6 ( resolution 23 is not used by all GPS devices if >>> resolution 24 and 22 are present) >>> resolution 22 == 6 >>> resolution 21 == 20 >>> resolution 20 == 40 >>> resolution 19 == 80 >>> resolution >18 == 120 >>> >> Just to be sure there is no missunderstanding: You are not able to >> set minsizes for each resolution. You haven't set them, or have you? > No of course I couldnt >> >> The SizeFilter itself should shift the minsize according to the >> resolution. I.e. if you init it with number 2 the following minsizes >> should be uesed: >> >> resolution 24 = 2 >> resolution 23 = 4 >> resolution 22 = 8 >> resolution 21 = 16 >> resolution 20 = 32 >> resolution 19 = 64 >> resolution 18 = 128 >> >> which matches roughly your demands. > No my demands were with the current code. I tried out different values > and looked at what I seemed to give best results. So according to your > system the following values seem well to me: > resolution 24 == 1 > resolution 23 == 8 > resolution 22 == 48 > resolution 21 == 320 > resolution 20 == 1280 > resolution 19 == 5120 > resolution 18 == 15360 > resolution 17 == 30720 ( I doubt anyone will display polygons other > than sea at this resolution - so there is not much need here anymore > to have the filter - I would not want to have sea polygons being dropped) > Sorry, I'm a little confused by the nonlinearity of the values. This means that on low resolutions mostly of the polygons will disappear (e.g. res 18, all polygons smaller than 15360 garmin units), while on higher resolutions there will be nearly no visible effects. resolution 24 == 1 resolution 23 == 8 (2*4) resolution 22 == 48 (6*8) resolution 21 == 320 (20*16) resolution 20 == 1280 (40*32) resolution 19 == 5120 (80*64) resolution 18 == 15360 (120*128) I had expected the internal power of two from the SizeFilter to be quite sensible. But on the other hand it depends on the assignments between resolutions and zoom levels. In general I had the idea in mind, that with usefull resolutions one garmin unit means roughly one pixel at display. So with a set value of 8 all objects smaller then 8 pixels should be filtered. > The advantage would be that one can confidently increase the > resolution for polygons inside the style-file without getting huge > performance drops. Directly going for very high levels in resolution > 24/23/22 however did not improve visual quality of my maps, nor make > big differences in rendering speed. Very high numbers at low level will DEcrease visual quality, as some visible objects will disappear. > Only when zoomed out far (e.g. resolution 20 and using high min_size) > performance differences became notable - and also very small areas got > dropped that would not be displayed in a "hand drawn" map either). > I haven't tried myself, but this would mean, that at resolution 20, 40 garmin units will be only a few pixels (your words: very small areas). This seems a waste of encoding bits to me. Do you have some special assignment of zoom levels to resolution levels or are you using the default settings? Regards, Johann

2 1

Multipolygons and bounding box
by WanMil 08 Jan '10

08 Jan '10

I am thinking about how to close polygons that are clipped by the bounding box of the OSM file and are therefore not complete and not closed? At the moment these ways are not handled by multipolygon code in the mp branch. This causes lots of areas to disappear next to the bounding box of the OSM files (example: Lake Neusiedel) I have found the field bbox in Osm5XmlHandler. Does this field contain the complete bounding box of the processed OSM file? Do I have to consider anything special using this bbox? I want to use this bbox to close polygons that are located near the border of the processed OSM file. WanMil

2 1

Suggestion - Make Douglas Peucker Algorithm more Configurable
by Felix Hartmann 08 Jan '10

08 Jan '10

Essentially the best option for drawing Polygons would be to determine their "resolution" based on size. So make large forests appearing at lower resolutions than small forests (well I think we all know that best would be if resolution of any element were adapted to map density, but I think that is even more complicated). I don't think this would be an easy task. Depending on the area or country (e.g. France with the Corine land cover import) putting forests at low resolutions really slows down map panning. An "easy" compromise could be to put "stronger" douglas peucker filter on polygons than on roads (I currently use 5.4, because 10 seems to be too strong on roads). However for Polygons a value of 10 works pretty well. It would be great if there would be support for that (I don't know if the douglas peucker filter is applied after or before the style-file, if before of course the above will not be "easy"). The better mapped countries are getting, the more importance choosing the proper resolutions will have. The changes to the default style over the last weeks were already a good step forward, but outside of cities OSM rarely has more than 20-30% of ways and landuse covered (I dare people in future will not draw few big forests, but split up more and more detailed) so the solely based on tags approach will become more and more difficult... (well at least I hope the difference between countryside and cities will flatten out a bit).

3 15

Understanding the sea
by Mark Burton 08 Jan '10

08 Jan '10

Hi, I'm trying to understand how the --generate-sea stuff works. I want to know how it decides whether an "island" is water or land. The code does not really contain sufficient comments for me to work out what it's doing. I would expect it to close coastline segments that reach the tile boundary in a direction that is consistent with the "water on the right" convention but I can't see that in the code. Can anyone help please? I hesitate to whine about contributions to mkgmap as I don't want to stop them arriving but if we can't easily work out how the code works then it doesn't bode well for maintenance and bug fixing when the original author has moved on. I have agreed to help produce a marine map of the Baltic so it would be really nice if the sea was filled in without any really major problems (flooded land, etc.) I realise that this is dependent on the performance of the MP stuff but it seems to me that generating the right polygons in the first place would be a good start. I guess that the Baltic area is probably rather a challenge for the current state of the art. Thanks, Mark

9 12

mkgmap version
by Carlos Dávila 08 Jan '10

08 Jan '10

Running java -jar mkgmap.jar --version on my compiled mkgmap gives me just "svn". Shouldn't it show the svn revision? Regards, Carlos

1 0

Assertion when removing name/ref from way
by Mark Burton 08 Jan '10

08 Jan '10

I want to show bridges on my map but would like to remove their names so that when you mouseover them, it shows A5/Bridge rather than A5/A5 (assuming the road's ref is A5). However, if I try the following rule: highway=* & bridge=yes { delete 'name'; delete 'ref'; } [0x010107 continue resolution 24] I get an assertion: java.lang.AssertionError at uk.me.parabola.mkgmap.reader.osm.Tags.put(Tags.java:102) at uk.me.parabola.mkgmap.reader.osm.Tags.addExtraItems(Tags.java:299) at uk.me.parabola.mkgmap.reader.osm.Tags.access$300(Tags.java:41) at uk.me.parabola.mkgmap.reader.osm.Tags$1.hasNext(Tags.java:223) at uk.me.parabola.mkgmap.osmstyle.RuleSet.resolveType(RuleSet.java:72) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.convertWay(StyledConverter.java:281) ... Is this a sensible way to remove the names? If not, what is? If the rule is good, why is it blowing up? Cheers, Mark

2 5