September 2010 - mkgmap-dev - The mkgmap lists

[PATCH] support of DEM subfile for Displayer
by Ronny Klier 23 Sep '10

23 Sep '10

This patch enables the display tool to read the known parts of DEM subfiles. Please refer to http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/DEM_Subfile_Format for a description. Notes: - Using the discovered parts it is possible to read the coordinates of the covered areas, their minimum and maximum heights and the data which builds the real elevation model. - The encryption of this data is still unknown. IMHO it is normalized (using the difference between minimum and maximum height and perhaps an additional field) and compressed. But I'm not an expert on data encrytion ;-)

1 0

Splitting the entire planet in one pass.
by Scott Crosby 22 Sep '10

22 Sep '10

Well, technically two passes; the first pass is needed to figure out where to split. A new set of patches and line of development in my tree. Features: About 1/3 of the RAM usage. An entire planet can be split into 1200 areas in one pass with -Xmx5000m --max-nodes=1000000 in one hour. No upper bound on how many areas a node/way/relation can occur in. I've tested large overlaps with nodes in >10 regions. Generate up to 6700 areas in a single pass. (Yes, -Xmx5000m --max-nodes=50000 --max-regions=6700 on a 8gb machine generates 20,000 regions in three passes in 4 hours!) If areas.list says so, areas can overlap. The underlying algorithm can also handle non-rectangular areas. Quite a bit faster RAM usage proportional to the total number of nodes in the output files, at about 4 bytes per output node. Issues: 1. Two passes may be needed for a whole planet with 4gb of physical RAM. 2. Scaling to thousands of areas/output files in one pass can cause problems. a. There may be a system limit on number of open files. b. Per-file memory overhead of Java's IO layer and GzipOutputStream can cause unexpectedly high memory usage. On my machine, this limits me from doing >=10,000 areas per pass. c. The current threading code behaves badly, causing >300k context switches/second. My previous threading code also behaves badly, requiring one thread per output stream. I have new threading code that overcomes both problems and is 15% faster. 3. Dependencies on fastutils and dsiutils jars. 4. Depends on the refactoring I did to support the binary format. 5. Splitter does not find good splits with --max-nodes =< 50000 in the default resolution. Changes: The main memory overhead in the splitter is to track which nodes are in which area. It formerly used a custom IntIntMap. I refactored it to use an Int2ShortMultiMap, then implemented that MutiMap by composing two underlying Int2ShortMap implementations with different space efficiency tradeoffs, a custom sparsearray implementation based on http://google-sparsehash.googlecode.com/svn/trunk/doc/implementation.html, and one imported from a library of java collections specialized to primitive types. The hybrid has a memory overhead of about 4 bytes per output, storing 750m keys with 800m vals in 3.2gb of heap. Testing: I split the cloudmade extract of NY into 160 areas of --max-nodes=100000 and compared my integration branch 'dev' versus SVN trunk. I then compared 3 of the area files. Files have minor differences. My branch reorders the tags within each node compared to trunk. Also, my XML output routines *always* output 7 degrees of precision, even if the data has only 6 degrees of precision (i.e. '123.1234560' instead of '123.123456'). Other notes: I just found out about a curious option -XX:+UseCompressedOops for recent Java VM's. It lets 32-bit pointers be used in a 64-bit VM, which can, for pointer-heavy uses, cut down on memory usage, cache pressure, memory bandwidth, etc. My SparseInt2ShortMap is fairly heavy on pointers and that option appears to offer a 10% memory reduction. Code is in branch 'perf/multiregion'. Code integrating all of my patches is currently available in branch 'dev' in my git repository on github and will be in SVN within a few weeks. Scott

3 6

Commit: r1701: Modify DEM.java so that contours are always created in the same direction:
by svn commit 20 Sep '10

20 Sep '10

Version 1701 was commited by steve on 2010-09-20 23:07:21 +0100 (Mon, 20 Sep 2010) Modify DEM.java so that contours are always created in the same direction: http://koti.kapsi.fi/jpa/stuff/other/patch-contour-direction -- Petteri Aimonen

1 0

Commit: r1700: Fixes exception when there are no outer polygons.
by svn commit 20 Sep '10

20 Sep '10

Version 1700 was commited by steve on 2010-09-20 22:25:06 +0100 (Mon, 20 Sep 2010) Fixes exception when there are no outer polygons. -WanMil

1 0

--transpatent not work
by Maks Vasilev 20 Sep '10

20 Sep '10

Hi! I create map (contour) with: mkgmap --gmapsupp --tdbfile \ --family-name="NASA-SRTM-Topo" \ --product-id=9 \ --family-id=99 \ --series-name="Vyatka-topo" \ --description="Centae" \ --country-name="RUSSIA" --country-abbr="RU" \ --charset=cp1251 --lower-case \ --style-file=stranger/ \ --output-dir=elev/ \ --draw-priority=31 \ --transpatent \ elev/*.osm \ topo.TYP But map not transparent. In GMapTool i see that map not have T flag. I test in in 1673 and 1699.

5 5

STOP signs and routing
by Hendrik Oesterlin 20 Sep '10

20 Sep '10

Hello, Does mkgmap support STOP or GIVE-Way signs for routing? It is acutally interesting to know if the calculated route will bring you in front of a STOP... If the sings are tagged like described here http://wiki.openstreetmap.org/wiki/Tag:highway%3Dstop "As nodes on the ways approaching intersections" it would be possible to create two ways in opposite direction, both with oneway=yes, and different values for maxspeed. The way in direction of the main road could be set to 1 or 2 km/h, so it will cost a couple of extra seconds for the routing algorithm. If the original road is already oneway=yes, no opposite way has to be created, otherwise the original oneway=yes will loose its effect... What do you thing about this? Kindly Hendrik

3 4

Show direction in contours (patch)
by Petteri Aimonen 19 Sep '10

19 Sep '10

Hi, I had an idea to show the direction of the slope in elevation data contours. To implement this, I made a small modification in DEM.java so that contours are always created in the same direction: http://koti.kapsi.fi/jpa/stuff/other/patch-contour-direction Then I just used the bitmap mode in the TYP editor to make small arrows that point downwards: http://koti.kapsi.fi/jpa/stuff/pix/contours.jpg This patch could be added to the main branch, and the TYP file then specifies whether to use arrows or not. Currently the contours start in random direction depending on the shape of the area. -- Petteri Aimonen PS: Thanks for the great program!

1 0

Commit: r1699: Translate natural=waterfall and waterway=waterfall.
by svn commit 17 Sep '10

17 Sep '10

Version 1699 was commited by marko on 2010-09-17 21:41:29 +0100 (Fri, 17 Sep 2010) Translate natural=waterfall and waterway=waterfall. Suggested by Maning Sambale.

1 0

please add waterfall to the styles
by maning sambale 17 Sep '10

17 Sep '10

2 tags exist for waterfalls: natural=waterfall: 183 nodes, 8 ways waterway=waterfall: 2183 nodes, 162 ways, 2 relations I added them in my point styles natural=waterfall [0x6508 resolution 21] waterway=waterfall [0x6508 resolution 21] Might be good to add them in default styles as well. IMO, the two separate tags should be unified (but that should be in tagging mailinglist). -- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------

1 0

Commit: r1694: This patch enables mkgmap to make use of real multipolygons and of multipolygons where only the members should be tagged (e.g. country boundaries) without any change on the style rules.
by svn commit 17 Sep '10

17 Sep '10

Version 1694 was commited by steve on 2010-09-15 14:11:45 +0100 (Wed, 15 Sep 2010) This patch enables mkgmap to make use of real multipolygons and of multipolygons where only the members should be tagged (e.g. country boundaries) without any change on the style rules. It adds a copy of each original line of a multipolygon with an outer role, tags them with the mp tags and an additional mkgmap:stylefilter=polyline. The generated polygon elements are tagged with mkgmap:stylefilter=polygon. The style system evaluates the mkgmap:stylefilter tag and processes such tagged elements only with the appropriate style rules. The --process-boundary-relations option is no longer neccessary and has been removed. - WanMil

2 1