- mkgmap-dev - The mkgmap lists

Commit: r1486: Lots of fixes of multipolygon issues.
by svn commit 17 Jan '10

17 Jan '10

Version 1486 was commited by steve on 2010-01-17 23:08:26 +0000 (Sun, 17 Jan 2010) BRANCH: mp Lots of fixes of multipolygon issues. I have also added some more javadoc and code comments, renamed methods and variables and removed not very useful logging statements. - WanMil

1 0

Splitter details question
by WanMil 17 Jan '10

17 Jan '10

At the moment I try to understand how the splitter works to make the mulitpolygon code splitter compatible. I have taken the OSM dump of austria from Jan 8th and run splitter on it (with the default settings). Splitter generated 6 tiles. So far so good. To get a visual feeling I wrote a simple gpx dump at the entry point of Osm5XmlHandler.endDocument(). That makes it easy to visualize the data (e.g. with JOSM). Attached you find the files: bbox.gpx: this is the bounding box of one tile 39612875.gpx, 45656928.gpx and 456456929.gpx: three ways taken from the tile. *.png : visualization of the ways including the bbox. The splitter homepage (http://www.mkgmap.org.uk/page/tile-splitter) tells me "Tiles join exactly with no overlap or gaps." Now my questions: * Why does the tile contain points of way 45656928 and 45656929? They don't intersect the bounding box and they are contained in the adjacent tiles. For me this does not comply to the splitter homepage statement. * Why does 39612875 contain some points within the bbox and some out of the bbox? I think because the points are exported for the two other ways? * But why are the points of way 39612875 (point 474857138 and 474857142) that lie next to but in the bounding box are not contained in the tile? The described behaviour of the tile splitter makes it complicated to implement a reasonable behaviour of the mulitpolygon code on the borders of the tiles. WanMil

5 17

Commit: r1485: Polish RuleFileReader.optimiseAndSaveBinaryOp() a little.
by svn commit 17 Jan '10

17 Jan '10

Version 1485 was commited by marko on 2010-01-17 20:03:29 +0000 (Sun, 17 Jan 2010) Polish RuleFileReader.optimiseAndSaveBinaryOp() a little.

1 0

[PATCH v1] preserve edges introduced by clipping and splitting
by Mark Burton 17 Jan '10

17 Jan '10

This patch stops the DP filter from discarding points at either end of a horizontal or vertical line segment (such segments are created by the clipper and also by the polygon splitter and, of course, could occur naturally in the OSM data but I'd guess they are relatively rare). The benefit is that polygons lose those ugly artifacts (e.g. weird thin triangles) that sometimes occur at tile boundaries or where they have been split (when zooming out in mapsource). For me, mapsource still displays the odd spurious horizontal or vertical line but as it goes away when the screen is scrolled, I am assuming it is a mapsource bug rather than ours. Please try it out and report. Mark

2 2

[PATCH] Allow ~ and friends at top level
by Marko Mäkelä 17 Jan '10

17 Jan '10

Steve, This patch seems to work for me, but as I am not familiar with the pattern matching in the mkgmap style engine, I would like to ask for review and approval. Best regards, Marko

3 7

[PATCH v2] Mp merge: generate-sea: bugfix for generate-sea=multipolygon
by WanMil 17 Jan '10

17 Jan '10

The flodded areas was a reason of the attitude of the mp code: mp does not recognize that polygon pi is in polygon po if they share a line or a point. The attached patch contains an easy workaround. The sea background area (which is the outer area in the mp) is increased by 1 so that it does not share any lines and points with any of the inner areas. WanMil

2 1

Updated Baltic Maps
by Mark Burton 16 Jan '10

16 Jan '10

If anyone is interested, the latest version of the Baltic map can be found at: http://www.smartavionics.com/OSM/baltic.zip (37M gmapsupp.img) http://www.smartavionics.com/OSM/OSM-Baltic.exe (35M mapsource installer) I think it's looking pretty good now but any suggestions as to how it could be improved are welcome. If Markus and his pals put more marine widgets into the OSM database it could be quite a useful thing. Mark

1 0

[PATCH v1] Merge from the mp branch
by WanMil 16 Jan '10

16 Jan '10

The attached patch contains a merge from the mp branch and fixes lots of multipolygon issues. I have also added some more javadoc and code comments, renamed methods and variables and removed not very useful logging statements. The mp branch is no longer needed. WanMil

2 5

Commit: r1484: Add missing RegexOp constructor.
by svn commit 16 Jan '10

16 Jan '10

Version 1484 was commited by marko on 2010-01-16 19:34:27 +0000 (Sat, 16 Jan 2010) Add missing RegexOp constructor.

1 0

Map redraw speed
by Mark Burton 16 Jan '10

16 Jan '10

While, we're in the Baltic, I should tell you this: Markus sent me a sample of the Baltic map that had been created by someone else by converting from OSM to MP and then processing it with cgpsmapper. It looks nice but one thing I noticed is that the redraw speed (in mapsource) is terrible. For the same area, the mkgmap generated map redraws in 1/2 second or less but the cgpsmapper generated map is taking at least 2 (maybe 3) seconds to redraw when scrolled. The .img file doesn't look particularly big so I don't know what the problem is (but it's not our problem!) Cheers, Mark

1 0