February 2010 - mkgmap-dev - The mkgmap lists

Anti-island check confused; defined a monster multipolygon
by Marko Mäkelä 06 Feb '10

06 Feb '10

Mark, WanMil, It seems that the anti-island check got the piecewise defined coast line of Inarinjärvi (Lake Inari) wrong. I now defined a multipolygon for the lake and its about 700 islands, hopefully making no mistake in the process: http://www.openstreetmap.org/browse/relation/402543 Some islands contain lakes, and according to the wiki should include those in the relation as well. Here is an example: http://www.openstreetmap.org/browse/way/31257120 http://www.openstreetmap.org/?mlat=68.8415&mlon=27.5145&zoom=13 The coastline of Lake Inari is to the west of that lake. I will have to check if these lakes look fine, and also that these lakes or patches of water will not inherit the name from the relation. I will add the lakes on that island to the multipolygon, as a test case. JOSM is getting slow at this. Does anyone know a JOSM trick that would allow me to select exactly everything that is bounded by the current selection? There is natural=water near the coastline, on the mainland, and I do not want to add those as role=outer. Marko

2 5

generate-sea problem : to Wanmil
by David 06 Feb '10

06 Feb '10

Hello Wanmil, Here are the facts : I downloaded the latest Ireland.osm from geofabrik (yesterday was 2010/02/05) and the latest one from Cloudmade.com (2010/01/26). Ireland coastlines data are complete. I tried with same options all versions from 1560 to 1494 and splitter version 105 only. Ireland map is in one area. I made my tests with multipolygon with close-gap option set to 1000 and 10000, and also the no-mp option with funny result : Ireland became a sea. As I thought it could be a problem with my style files, I made also all my tests with default styles provided with mkgmap and the results were the same : after version 1512, mkgmap is not able to produce multipolygon sea, despite "generate-sea=multipolygon,close-gap.=1000" works fine with v1512 for Ireland. I know how hard it is to develop a software such mkgmap (which is really good), but the problem may be not the data. Here is another vicous bug : when "merge-lines" is used, when you try to define a waypoint in route edition mode on a road in Mapsource, it is located far from your choice. You can also watch the problem with automatic popup which are not displayed under the mouse pointer, but elsewhere, sometimes out of the visible map area. Cheers, David

2 1

Commit: r1555: Ignore multipolygons with fewer than 2 resolved elements.
by svn commit 06 Feb '10

06 Feb '10

Version 1555 was commited by marko on 2010-02-03 11:41:06 +0000 (Wed, 03 Feb 2010) Ignore multipolygons with fewer than 2 resolved elements.

5 8

[PATCH v1] generate-sea code cleanup
by WanMil 06 Feb '10

06 Feb '10

Attached patch makes the code of the generate-sea feature a bit more readable. Results should not be changed otherwise this is a bug. I want to reuse some parts of this code for mulitpolygon tile bounds handling. So this is a preliminary work to extract some parts of the generate-sea code from the Osm5XmlHandler. WanMil

1 0

Commit: r1563: Ignore left:*, right:* when naming boundaries.
by svn commit 06 Feb '10

06 Feb '10

Version 1563 was commited by marko on 2010-02-06 12:12:23 +0000 (Sat, 06 Feb 2010) Ignore left:*,right:* when naming boundaries.

1 0

some comments on mkgmap default style
by maning sambale 06 Feb '10

06 Feb '10

Hi, some observation about the default style: 1. Coastlines are shown as thin blue lines, is it possible to render coastline as polygon, where sea areas are shaded as blue. A work around I did before is to manually edit all sea-areas and then add a natural=water tag (bad data edit) . 2. Administrative boundaries clutter the map. They appear like roads and can be confusing while driving. Suggestion is to make the admin boundaries thinner. Hope it helps improving the default stylesheet. -- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------

5 8

Commit: r1553: Using StyleImpl to print out a style now
by svn commit 06 Feb '10

06 Feb '10

Version 1553 was commited by steve on 2010-02-02 14:08:52 +0000 (Tue, 02 Feb 2010) BRANCH: style-speed Using StyleImpl to print out a style now gives something that is a valid style which can be read in and, on printing, will be identical to the input.

3 2

[PATCH v1] head the through_route relation when adjusting turn headings
by Mark Burton 06 Feb '10

06 Feb '10

This new relation (type through_route) specifies which 2 ways are the "through route" at a junction. The relation requires 2 ways (no role required) and a node with role = junction. It should only be used at those junctions where the through route cannot be reliably inferred from the ways' names and/or refs. Here's an example from my local town: | 1 | / | / |/ A | | | | B /| / | / | 2 | The vertical road is the "through route", i.e. you can drive from one end to the other without crossing any white lines. But, from point 1 to point 2 is a B road so ways 1-A, A-B, and B-2 all have some ref, say, B1234. Without the through_route relation, mkgmap assumes (erroneously) that the through route is 1-2 because all of the ways in that route have the ref B1234. By adding 2 through_route relations (one at A and the other at B), mkgmap is informed of the real through route and will take that into account when adjusting the turn headings. The end result is that the quality of the routing directions is improved (we hope). In this example, we need to have 2 relations because the B road joins/leaves the through route at two places. So if you know of any junctions that would benefit from this relation, please add it to the map data and try this patch to see if it improves the routing instructions. Mark

1 0

Commit: r1562: The current speed optimisations from the style-speed
by svn commit 05 Feb '10

05 Feb '10

Version 1562 was commited by steve on 2010-02-05 15:36:26 +0000 (Fri, 05 Feb 2010) The current speed optimisations from the style-speed branch. There are no bug fixes, so any change in the maps produced is likely to be a bug. An index is created into the rules based on the first term in the match expression. A list of rules that might be matched is constructed based on the tags present on each element and the possible rules are looked up. As rules can themselves add and modify tags, this is moderately complex to get right.

1 0

Commit: r1561: Remove debugging in preparation for merge
by svn commit 05 Feb '10

05 Feb '10

Version 1561 was commited by steve on 2010-02-05 15:17:41 +0000 (Fri, 05 Feb 2010) BRANCH: style-speed Remove debugging in preparation for merge to trunk.

1 0