January 2010 - mkgmap-dev - The mkgmap lists

Style file tester
by Steve Ratcliffe 26 Jan '10

26 Jan '10

Hi I have written a utility that can be used for demonstrating style bugs and requests. See the attached patch. It allows you to create a file containing ways with tags and a set of style rules. You can then run this file and see what elements would be produced. If this is wrong or you disagree with the results you can post the whole result along with what you wanted to happen. It also attempts to calculate what would happen if the rules were run in order from the top to the bottom on the way. If the result is different, then this is printed out as a failure after the actual results. Anything that depends on the order that actions are executed in is likely to fail on trunk, so any such example will just be collected and used to ensure that the style branch is working OK. Anyway, here is an example of it in use. Create a file called example1 with the following contents. WAY 1 highway=primary type=good aa=5 name=Main Street <<<lines>>> highway=* & type=good & aa=5 {set aa=6; } highway=primary & aa=6 [0x26 ] highway=* & aa=6 [0x27 ] Then run as (with the correct location of mkgmap.jar if different): java -cp dist/mkgmap.jar uk.me.parabola.mkgmap.main.StyleTester example1 This will print out the input file followed by a results section: <<<results>>> WAY 1: Line 0x27, name=<Main Street>, ref=<null>, res=24-24 (1/1),(2/2), FAIL. If rules were run strictly in order this would be: Line 0x26, name=<Main Street>, ref=<null>, res=24-24 (1/1),(2/2), This shows that the trunk code will select the last rule, but it should have selected the previous one. More notes * If more than one element is produced, as a result of using continue say, then they are all printed. * Ways are created with two points (1,1) and (2,2) so you can see reversals * You can have any number of WAY definitions, each of which must be ended with a blank line * You can put a number after the WAY so that you can tell them apart in the results. ..Steve

3 6

Re: [mkgmap-dev] Bogus warnings about intersected ways in multipolygons
by Adrian 25 Jan '10

25 Jan '10

> It is the point of view to say "the OSM data is OK". I ran r1475, r1502 and r1507 against exactly the same input files (the Geofabrik extract split into two tiles by splitter). r1475 produced no error messages at all. I admit I don't know whether r1475 might have done less error checking, but r1475 rendered the vineyards around Pinet correctly. I have seen plenty of bad quality data in OSM. For example, one of the multipolygon relationships which provoked an error message in r1502 and r1507, contained two outer ways, both with the same landuse tag. One way was closed, the other way was open and duplicated about half of the closed way. There is an ongoing debate about how much mkgmap should do in the way of cleaning-up the OSM data.

1 0

Re: [mkgmap-dev] Bogus warnings about intersected ways in multipolygons
by Adrian 25 Jan '10

25 Jan '10

WanMil, > Adrian: I want to check the tile from Lambertus. Can you give the > download link? I haven't found it. http://planetosm.oxilion.nl/~lambertus/garmin/routable/20-01-2010/63240406.… To find it, visit http://garmin.na1400.info/routable.php, zoom in to the south of France, click on the checkbox "enable manual tile selection", click on the tile containing Montpellier, and the link will appear to the left.

1 0

[PATCH v1 + v1] fix overview bounding box rounding + splitter rounding
by Mark Burton 25 Jan '10

25 Jan '10

v1 + v1 - OK, here's the matched pair - patches for both the splitter and mkgmap. With these in place, the mapsource mouse works as expected across all tile boundaries right up to the outer boundaries. No weird overlap of tile and overview map. Spot on. Please could some others give this a test and confirm that the rounding is now correct. ----------------- Thinking some more about what I was seeing in mapsource when mousing around the Baltic map, I came to the conclusion that the edges of the overview map bounding boxes where in the wrong place so I took a look at mkgmap where it rounds those coords and came up with the attached fix. No great theory here, I just dicked around until it worked as I expected. For the Baltic map, the mouse now works right up to each boundary in both lat and lon directions whereas before it would only work right on one side of each boundary. Please try the patch, especially for maps that are W of Greenwich and S of the equator and see if the overview boxes are right. Cheers, Mark

2 5

Re: [mkgmap-dev] Bogus warnings about intersected ways in multipolygons
by Adrian 25 Jan '10

25 Jan '10

> The new MP code has a problem with inner polygons that touch the outer. > > What you say makes me think that whenever the splitter splits an inner > polygon it's going to cause trouble because it splits outers/inners > along the same line so they will always intersect then. There is more to it than that, because these hollow buildings in Montpellier http://www.openstreetmap.org/?lat=43.60807&lon=3.89275&zoom=17&layers=B000F… also provoke the error message. They do not straddle the tile boundary and the inner and outer do not touch. They do, however, appear to be rendered correctly. I say "appear" because this cannot be seen in RoadTrip because it draws buildings and the background in exactly the same colour, and even on my GPSr it is very hard to see because buildings and background come out almost the same.

1 0

Splitter resolution and mapsource mouseover behaviour
by Mark Burton 25 Jan '10

25 Jan '10

Can someone please either explain or point me at some doc that explains the meaning of the splitter --resolution option: --resolution The resolution of the overview map to be produced by mkgmap. Default is 13 Does this force the tile boundaries to be rounded (not round in shape, but coords rounded to match the overview resolution). Is that how it works? I ask because I have noticed that on the Baltic map, the popup blurb you get when the mouse is over a map feature goes away near some tile edges and I suspect that having fooled around with the tile sizes, I have somehow borked the relationship between the tiles and the overview map. Thanks, Mark

2 7

[PATCH v1] fix overview bounding box rounding
by Mark Burton 25 Jan '10

25 Jan '10

Thinking some more about what I was seeing in mapsource when mousing around the Baltic map, I came to the conclusion that the edges of the overview map bounding boxes where in the wrong place so I took a look at mkgmap where it rounds those coords and came up with the attached fix. No great theory here, I just dicked around until it worked as I expected. For the Baltic map, the mouse now works right up to each boundary in both lat and lon directions whereas before it would only work right on one side of each boundary. Please try the patch, especially for maps that are W of Greenwich and S of the equator and see if the overview boxes are right. Cheers, Mark

2 16

[PATCH v1] don't split background rectangle
by Mark Burton 25 Jan '10

25 Jan '10

Here's something from last year that I forgot to push out. I noticed that a RGM (Real Garmin Map) only contained a single background rectangle (0x4b) for each layer. i.e. the rectangle was not split like normal polys are. The attached patch makes our maps the same so you just get one 0x4b poly per level. I have not found any noticeable difference in mapsource behaviour with this patch but it's probably worth using if it has no issues simply because "that's how they do it". Mark

1 0

Commit: r1514: Pull EQUALS terms to the front ahead of EXISTS and everything
by svn commit 25 Jan '10

25 Jan '10

Version 1514 was commited by steve on 2010-01-25 15:31:36 +0000 (Mon, 25 Jan 2010) BRANCH: style Pull EQUALS terms to the front ahead of EXISTS and everything else. The idea being that the earlier we can tell that the expression is false the better. All other things being the same, a=b is more likely to do this than a=* This is much more complete than what happens in trunk.

1 0

Commit: r1513: Apply the term rearrangement patch that was reverted from
by svn commit 25 Jan '10

25 Jan '10

Version 1513 was commited by steve on 2010-01-25 13:17:11 +0000 (Mon, 25 Jan 2010) BRANCH: style Apply the term rearrangement patch that was reverted from trunk. Prevents a syntax error being reported when the expression could simply be re-ordered to be in the correct form. TODO: arrange in order of selectivity.

1 0