November 2009 - mkgmap-dev - The mkgmap lists

Multipolygon incorrectly rendered
by Felix Hartmann 05 Nov '09

05 Nov '09

In general Multipolygons have rendered correctly in mkgmap since quite a bit of time. Today I discovered one that is rendered incorrectly (maybe this is related to the fact that the tags belonging to it were only written on the relation not on the ways itself so I had to include it via the relations file by adding: "landuse=forest { apply { add landuse=forest; add name='${name}'; add ref='${ref}' } } " http://www.openstreetmap.org/?lat=48.2533&lon=16.2278&zoom=13&layers=B000FTF See the incorrect white square on the screenshot (north-east of Vienna) (actually I tried this with patch v1 and patch v2 of the "fix routing problems caused by way's bbox being too large) and saw no change.

2 1

highway shields in label occasionally dropped
by Gert Münzel 05 Nov '09

05 Nov '09

Hi, I found that at some of the ways (which have a filled REF-field) the highway-symbol is dropped and only the content of "REF" is shown. some examples(i used r1344). I write "_" instead of "real" spaces just to make it easier to read: if "B" is given the result is "B" "B1" instead results in "~[0x06]B1" (where ~[0x06] represents the highway shield) "_B_" surprisingly ends up in "~[0x06]_B_" "BW" results in "BW" "BW1" results in "BW1" "B_W1" results in "~[0x06]BW1" "BW;1 " results in "~[0x06]BW;1" "BW_1" results in "~[0x06]BW1" (ok, afaik intermediate spaces has to be removed, otherwise only the first part is visible in highway shield) I (like also people do in OSM database i saw) use the REF in combination with the highway shield also as marker for trails (in hiking/biking overlays) and therefore this behaviour disturbs. I have looked in the code and found in the HighwaySymbolFilter.java this "alpha_balance" which is the reason for. Simply changing "return value" to "return prefix + value" stops this. Looking at the examples, the results of the filter is a bit strange to me. I can't get the intention. Do we really need this filter ? cheers Gert

6 12

--generate-sea: Flooded islands and MultiPolygonRelation
by Ivan Kostoski 05 Nov '09

05 Nov '09

Hello, I found several posible problems why MuliPolygonRelation produces flooded islands. 1. Inner ways are added to outer in order they come from osm data. If you add natural=sea to lines instead of polygons you will get the idea why this is possible problem. Should allways first add the closest inner way to outer way and repeat until there no more inner ways. This will prevent lines running over allready added landmass and self-intersecting outer polygon. 2. Winding of inner ways. If inner way has different winding (i.e. counter-clockwise) to the outer way, you will get self-intersecting polygon as InsertPoints in MultiPolygonRelation does not take care of this. Reversing the coastline way should hopefully have no other impact. 3. Adding the last point of inner way (which should (?) be the same as the first) I attached modified MultiPolygonRelation.java (from r1340), however I have very very limited Java skills so this needs a complete rework as it is painfully (unusably) slow (i.e. calculating the closest way over and over again). My tests with this modification reduced number of flooded islands (i.e. on Croatian coastline) at least when zoomed in. Some islands still get flooded when zooming out. I am not able to find out why this happens, but some islands notriously like to flood more than others (i.e. OSM id 8838012) .. Actually, usually it is a whole chain that gets 'cut off' from the land-mass. If one island gets 'flooded', all islands linked to it also get flooded, i.e. polygon is broken... This might or might not have to do something with the polygon splitter. I think the proper way of solving this might be the polygon splitter as in that case we might be able to add points without delta shift which will reduce artifacts (linking lines). Or maybe it would be much easier to simply add the islands as i.e. natural=land without subtracting them from the sea polygon and draw over the sea (via .typ polygon draw-order) ? Hope this is useful and somebody more skilled will be able to address above issues. Thanks, Ivan

1 0

[PATCH v2] - fix routing problems caused by way's bbox being too large
by Mark Burton 05 Nov '09

05 Nov '09

v2 - added some assertions to catch out of bound line start coordinates - Increased size of line bbox - reduced size of polygon bbox. I can process the whole of the UK with this patch without errors - please test this on as much map data as possible and report any assertions or SEVERE messages. The reduction in size of the polygon bbox could possibly make a difference to some large polygons (could this help with the sea areas?) ------ Ok, I think I know what's been going wrong with some people's maps where the routing goes zig-zaggy when the way is longish. However, it's not the number of points in the way or even the length of the way that's wrong. It's because the bounding box becomes sufficiently large that it causes the line to be split by the LineSizeSplitterFilter. This ancient bit of code splits the line so that it doesn't have a bigger bounding box than it thinks is acceptable. Well, that may be OK for plain lines but for routable stuff like roads, it's bad news because there's no node between the two parts of the split line. If, by chance, the point at where the way was split was actually a node anyway, it probably worked OK but for other points, anything could happen! So the attached patch checks the way's bounding box earlier on when it's doing all that boring way size/arc size/node count checking and if the BB gets too large it snips the way in the accustomed fashion. Anyway, please try the attached patch and see if it works OK - (no new bad routing, no assertions, etc.) Bloody hell, another long evening spent hacking mkgmap...

4 15

Commit: r1351: Halve the allowed height of the shape's bounding box.
by svn commit 05 Nov '09

05 Nov '09

Version 1351 was commited by markb on 2009-11-05 11:24:23 +0000 (Thu, 05 Nov 2009) Halve the allowed height of the shape's bounding box. This stopped the map area rectangle (type 0x4b) having a origin that was offset from the centre of a subdivision area by more than 32767 map units.

1 0

Commit: r1350: Added assertions to trap deltaLat and deltaLong values that are too big.
by svn commit 05 Nov '09

05 Nov '09

Version 1350 was commited by markb on 2009-11-05 11:24:21 +0000 (Thu, 05 Nov 2009) Added assertions to trap deltaLat and deltaLong values that are too big.

1 0

Commit: r1349: write() now reports assertions caught when constructing LinePreparer.
by svn commit 05 Nov '09

05 Nov '09

Version 1349 was commited by markb on 2009-11-05 11:24:18 +0000 (Thu, 05 Nov 2009) write() now reports assertions caught when constructing LinePreparer. If LinePreparer has a problem, report it and then return rather than letting the assertion terminate the program.

1 0

Commit: r1348: Demote some messages from info to debug level to reduce the noise level.
by svn commit 05 Nov '09

05 Nov '09

Version 1348 was commited by markb on 2009-11-05 11:24:15 +0000 (Thu, 05 Nov 2009) Demote some messages from info to debug level to reduce the noise level.

1 0

Commit: r1347: Now splits routable ways earlier if their bounding box becomes too large.
by svn commit 05 Nov '09

05 Nov '09

Version 1347 was commited by markb on 2009-11-05 11:24:12 +0000 (Thu, 05 Nov 2009) Now splits routable ways earlier if their bounding box becomes too large. LineSizeSplitterFilter will split a way if it deems that its bounding box is too large. Unfortunately, this breaks routable ways so now we split them in StyledConverter so that the points where the ways are split become nodes. Includes some minor bug fixes in LineSizeSplitterFilter.

1 0

Commit: r1346: Don't split if line has exactly MAX_POINTS_IN_LINE points.
by svn commit 05 Nov '09

05 Nov '09

Version 1346 was commited by markb on 2009-11-05 11:24:09 +0000 (Thu, 05 Nov 2009) Don't split if line has exactly MAX_POINTS_IN_LINE points.

1 0