- mkgmap-dev - The mkgmap lists

Do we have a memory leak in mkgmap recently introduced?
by Felix Hartmann 02 Jan '10

02 Jan '10

I noticed that mkgmap since a few revistions memory requiresments at least doubled. Two weeks ago everything was still okay, rev >=1350 is however consuming a lot more memory. The thing that makes me think that there is a big leak however is that the memory builds up tile after tile. When rendering Germany with max-jobs=2 I needed 5GB of java heap. Some month ago I did fine with 3GB on max-jobs=3 (without any big changes to either my style, nor an increase in the max-nodes for the splitter). I'll try to find some time to find out if there was a specific revision from which onwards the memory requirements increased.

1 0

Snapshot of style rules for seamark points
by Mark Burton 01 Jan '10

01 Jan '10

I've just committed some Java support for seamark marine lights. If you want to create maps with seamark objects you also need some style rules in the points file. I append a snapshot of what I am currently using. At some future time, it could be merged into the default style or be in a special marine style. I know that there is an alternative tag set for marine objects but I'm ignoring it for the moment as the marine map I am working on is for the Open Sea Map people (who are a bit miffed that someone has come up with an alternative tag set). Examples of seamark usage can be found in the Baltic area, especially near Rostock and Kiel. ############################################################################ # begin seamark marine objects ################################################ # add mkgmap:xt- tags seamark:light:ref=* { add mkgmap:xt-int-desig='${seamark:light:ref}'; } seamark:beacon_lateral:ref=* { add mkgmap:xt-int-desig='${seamark:beacon_lateral:ref}'; } seamark:buoy_lateral:ref=* { add mkgmap:xt-int-desig='${seamark:buoy_lateral:ref}'; } seamark:light:height=* { add mkgmap:xt-height-above-datum='${seamark:light:height}'; } seamark:light:colour=* { add mkgmap:xt-light='${seamark:light:colour}'; } seamark:light:period=* { add mkgmap:xt-period='${seamark:light:period}'; } seamark:light:sequence=* { add mkgmap:xt-note='Sequence: ${seamark:light:sequence}'; } seamark:light:group=* { add mkgmap:xt-note='Group: ${seamark:light:group}'; } # deprecated seamark:light:signal:period=* { add mkgmap:xt-period='${seamark:light:signal:period}'; } seamark:light:signal:sequence=* { add mkgmap:xt-note='${seamark:light:signal:sequence}'; } seamark:buoy_special_purpose:colour=* { add mkgmap:xt-colour='${seamark:buoy_special_purpose:colour}'; } seamark:buoy_lateral:colour=* { add mkgmap:xt-colour='${seamark:buoy_lateral:colour}'; } seamark:buoy_lateral:category=port { add mkgmap:xt-colour='red'; } seamark:buoy_lateral:category=starboard { add mkgmap:xt-colour='green'; } seamark:buoy_lateral:category=preferred_channel_port { add mkgmap:xt-colour='green-red-green'; } seamark:buoy_lateral:category=preferred_channel_starboard { add mkgmap:xt-colour='red-green-red'; } seamark:buoy_safe_water:colour='red,white,red' { add mkgmap:xt-colour='red-white'; } seamark:buoy_safe_water:colour=* { add mkgmap:xt-colour='${seamark:buoy_safe_water:colour}'; } seamark:buoy_race:colour=* { add mkgmap:xt-colour='${seamark:buoy_race:colour}'; } seamark:beacon_special_purpose:colour=* { add mkgmap:xt-colour='${seamark:beacon_special_purpose:colour}'; } ###### # define types seamark:buoy_lateral:shape=spar [0x010207 resolution 20] seamark:buoy_lateral:category=port [0x010209 resolution 20] seamark:buoy_lateral:category=starboard [0x01020a resolution 20] seamark:buoy_lateral:shape=* [0x010200 resolution 20] seamark:buoy_lateral:category=* [0x010200 resolution 20] seamark:buoy_cardinal:category=north { add mkgmap:xt-colour='black-yellow'; } [0x010202 resolution 20] seamark:buoy_cardinal:category=south { add mkgmap:xt-colour='yellow-black'; } [0x010203 resolution 20] seamark:buoy_cardinal:category=east { add mkgmap:xt-colour='black-yellow-black'; } [0x010204 resolution 20] seamark:buoy_cardinal:category=west { add mkgmap:xt-colour='yellow-black-yellow'; } [0x010205 resolution 20] seamark:buoy_special_purpose:shape=pillar [0x010207 resolution 20] seamark:buoy_special_purpose:shape=spar [0x010207 resolution 20] seamark:buoy_special_purpose:shape=barrel [0x01020d resolution 20] seamark:buoy_special_purpose:shape=* [0x01020b resolution 20] seamark:buoy_safe_water:shape=* [0x01020c resolution 20] seamark:buoy_race:shape=* { add xt-note='Race Buoy' } [0x010200 resolution 20] seamark=lighthouse & seamark:light:colour='red' { } [0x010107 resolution 20] seamark=lighthouse & seamark:light:colour='green' { } [0x010108 resolution 20] seamark=lighthouse [0x010100 resolution 20] seamark:beacon_cardinal:category=north { add mkgmap:xt-colour='black-yellow'; } [0x01020e resolution 20] seamark:beacon_cardinal:category=south { add mkgmap:xt-colour='yellow-black'; } [0x01020f resolution 20] seamark:beacon_cardinal:category=east { add mkgmap:xt-colour='black-yellow-black'; } [0x010210 resolution 20] seamark:beacon_cardinal:category=west { add mkgmap:xt-colour='yellow-black-yellow'; } [0x010211 resolution 20] seamark:beacon:category=port [0x010213 resolution 20] seamark:beacon:category=starboard [0x010214 resolution 20] seamark:beacon:category=* [0x010206 resolution 20] seamark:beacon_lateral:category=* [0x010206 resolution 20] seamark:beacon_lateral:shape=* [0x010206 resolution 20] seamark:beacon_special_purpose:colour=* [0x010215 resolution 20] seamark:light:1=* [0x010100 resolution 20] waterway=depth & name=* { name '${name|subst:,=>.}' } [ 0x6200 resolution 22] waterway=wreck [ 0x010402 resolution 22 ] historic=wreck [ 0x010402 resolution 22 ] # end seamark marine objects ############################################################################

1 0

Commit: r1455: Encode 9th bit of period for lights.
by svn commit 01 Jan '10

01 Jan '10

Version 1455 was commited by markb on 2010-01-01 23:08:02 +0000 (Fri, 01 Jan 2010) Encode 9th bit of period for lights.

1 0

Commit: r1454: Swap order order of int-desig and local-desig bits.
by svn commit 01 Jan '10

01 Jan '10

Version 1454 was commited by markb on 2010-01-01 23:07:58 +0000 (Fri, 01 Jan 2010) Swap order order of int-desig and local-desig bits. Mapsource 6.13.7 thinks this is the right order - to be confirmed.

1 0

Commit: r1453: Add support for seamark tags (mostly light attributes).
by svn commit 01 Jan '10

01 Jan '10

Version 1453 was commited by markb on 2010-01-01 23:07:55 +0000 (Fri, 01 Jan 2010) Add support for seamark tags (mostly light attributes).

1 0

Commit: r1452: Include tags with seamark: prefix in XT attributes.
by svn commit 01 Jan '10

01 Jan '10

Version 1452 was commited by markb on 2010-01-01 23:07:52 +0000 (Fri, 01 Jan 2010) Include tags with seamark: prefix in XT attributes.

1 0

Generate-sea oddities
by Marko Mäkelä 01 Jan '10

01 Jan '10

Happy new year to all! I begin it by looking in the gift horse's mouth, trying to generate sea polygons for Finland. Some oddities: First, without --generate-sea, the lake at http://www.openstreetmap.org/?mlat=60.620864&mlon=25.087002&zoom=14 is visible at all zoom levels from 5m to 2km. With --generate-sea, it is not visible between 5m and 500m but visible between 800m and 2km. This could apply to all lakes; initially I did not find any nearby lakes in the map. Second, the coast line of the Åland archipelago is missing (it is all yellow). Third, much of the land and sea is inverted. (i) At around lat=60.515400 lon=21.172457 there is the NW corner of a rectangle that covers the SE corner of the southmost map tile. Inside this box, the land and sea are reversed. (ii) At around lat=60.515421 [same as (i)] lon=25.140496 there is the NW corner of a rectangle. West of the longitude, the background is initially drawn as sea but later filled with yellow when the Edge 705 completes drawing. East of the longitude, the background is initially drawn as land but later filled as sea (light blue). (iii) Further corners of magic rectangles are at lat=62.578126 [tile border] lon=21.172456 [same as (i)] and at lat=64.819337 [tile border] lon=24.128254 The options are as at http://www.polkupyoraily.net/osm/, with one addition: generate-sea: polygons,land-tag=natural=scrub I can provide the gmapsupp.img if needed. It looks the same in QLandKarteGT: only the west coast north of (i) is OK in the north and south tiles, and the middle tile is completely flooded. The tiles are as follows: 63240001: 2768896,890880 to 2916352,1472512 # : 59.414063,19.116211 to 62.578125,31.596680 63240002: 2916352,890880 to 3020800,1472512 # : 62.578125,19.116211 to 64.819336,31.596680 63240003: 3020800,890880 to 3266560,1472512 # : 64.819336,19.116211 to 70.092773,31.596680 Best regards, Marko

1 0

Multipolygons code rewritten (1st try)
by WanMil 01 Jan '10

01 Jan '10

Hi, I have rewritten the MultiPoloygonRelation class regarding the algorithm described in http://wiki.openstreetmap.org/wiki/Relation:multipolygon/Algorithm. This is a first (very early and not very well tested) implementation of this algorithm. I don't have time to go on with it within the next days. Multipolygons are a big discussion in the mailing list at the moment so maybe someone likes to review the code and gives some helpful comments on it. (Any comment is very welcome!!) These are the open points: * Tagged inner polygons are not considered yet! This a big open point which must be implemented next. (Some comments point to the place where to do this) * The code currently does not remove any inner or outer polygon segment. This must be changed in future. But at the moment I have no solution how to decide which segment should be removed and which segment must remain for map generation. (To be honest I did not think about it for long ;-) * The inner and outer tags in the polygon are not used at the moment. This must also be changed. * The code is completely unoptimized. It's just an early study if this can improve the multipolygon code. I am happy about any improvements! * The old insertPoints method does not consider the direction of the polygons. This can result in self intersecting polygons. I don't know if that matters but it can easily be improved. I am happy if someone can explain me if that matters than I can implement a fix (hopefully :-). * I don't know if my synthetic ids are generated well. I think there should be one synthetic generator for whole mkgmap? Have a happy new year (with the multipolygons case fixed :-))) WanMil

3 2

Commit: r1449: Provide an alternative to using a multipolygon when generating the sea.
by svn commit 31 Dec '09

31 Dec '09

Version 1449 was commited by markb on 2009-12-31 12:00:01 +0000 (Thu, 31 Dec 2009) Provide an alternative to using a multipolygon when generating the sea. The --generate-sea option can now take a comma separated list of values: multipolygon - generate the sea using a multipolygon (the default behaviour so this really doesn't need to be specified). polygons | no-mp - don't generate the sea using a multipolygon - instead, generate a background sea polygon plus individual land polygons with tag natural=land. This requires a suitable land polygon type to be defined in the style file (suggested type is 0x010100) and the polygon must be defined in the TYP file as having a higher drawing level than the sea polygon type. no-sea-sectors - disable the generation of "sea sectors" when the coastline fails to reach the tile's boundary. An unrecognised option value or the value "help" will cause some help blurb to be printed. For backwards compatibility, with no values specified, the --generate-sea option should behave as it did before.

3 7

Commit: r1451: Allow tag used for land polygons to be specified (default is natural=land).
by svn commit 31 Dec '09

31 Dec '09

Version 1451 was commited by markb on 2009-12-31 18:01:40 +0000 (Thu, 31 Dec 2009) Allow tag used for land polygons to be specified (default is natural=land). This is done with a new generate-sea sub-option, usage is land-tag=TAG=VAL. For example, --generate-sea=polygons,land-tag=foo=bah

1 0