- mkgmap-dev - The mkgmap lists

zero length arc
by frmas 23 Aug '09

23 Aug '09

Hello, Compiling a map of Italy, I got these warning messages : GRAVE (RoadNetwork): Road null (OSM id 36913306) contains zero length arc GRAVE (RoadNetwork): http://www.openstreetmap.org/?lat=44.33355&lon=9.34585&zoom=17 The parameters I use are : -ea \ -Xmx896M \ -jar $FILEDIR/mkgmap.jar \ --country-name=$COUNTRY_NAME \ --country-abbr=$COUNTRY_ABBR \ --family-id=148 \ --gmapsupp \ --ignore-maxspeeds \ --ignore-turn-restrictions \ --latin1 \ --location-autofill=1 \ --lower-case \ --overview-mapnumber=$PREFIX_CARTE$INDEX_CARTE"00" \ --preserve-element-order \ --product-id=$INDEX_CARTE \ --remove-short-arcs \ --road-name-pois \ --route \ --style-file=$FILEDIR/styles/arvernes \ --tdbfile \ --transparent \ -c $CARTESDIR/template.args \ The "remove-short-arcs" parameter is used. Is it just a message to tell me that mkgmap has removed the zero length arc or a problem ? Thanks. Francois --

3 4

Regression causing Heap space exhaustion?
by Morten Kjeldgaard 23 Aug '09

23 Aug '09

Hi, The default version of mkgmap distributed with Ubuntu 9.04 (jaunty) is svn630. I tried upgrading to version svn1067 which has recently appeared in Debian unstable, but now I get a Java heap space exception on the _same_ .osm file that worked before. The map I was working with is the latest denmark.osm from geofabrik. The command I used was: mkgmap --gmasupp --latin1 --route --make-all-cycleways denmark.osm I tried omitting "--route" but that didn't change things. Cheers, Morten -- Morten Kjeldgaard <mok0(a)ubuntu.com> Ubuntu MOTU Developer GPG Key ID: 404825E7

5 15

[PATCH v2] - support for extended type attributes
by Mark Burton 23 Aug '09

23 Aug '09

v2 - moving swiftly on. Added support for lights and reworked a few things. mkgmap:xt-foundation-colour is now just mkgmap:xt-colour mkgmap:xt-light-colour has been replaced with mkgmap:xt-light (more on this below) mkgmap:xt-light-type is now just mkgmap:xt-type Light colour, range (in nm) and angle is now specified with the mkgmap:xt-light tag - the values are just separated with commas, and only the colour is required for simple lights. All angles are in degrees. So, for example: mkgmap:xt-light=red (a red light) mkgmap:xt-light=red,5 (... visible at up to 5 nm) mkgmap:xt-light=red,5,172 (... sector starts at 172 degrees) The sector start angle only makes sense if you have multiple lights defined (separate light defs with one of /;:) - for example: mkgmap:xt-light=red,5,172/green,5,230/unlit,,300 you can add a text note, international designator or local designator to a buoy or light with: mkgmap:xt-note=hello world mkgmap:xt-int-desig=ABC mkgmap:xt-local-desig=XYZ These show up in the POI properties window in mapsource. There is also: mkgmap:xt-height-above-foundation (a height) mkgmap:xt-height-above-datum (a height) mkgmap:xt-leading-angle (an angle) you can now specify multiple period values to give a flash sequence but, unfortunately, it only encodes 2 values at the moment, the encoding for more than 2 values is yet to be discovered. The full range of light colours is now supported: "unlit", "red", "green", "white", "blue", "yellow", "violet", "amber" So, lights, buoys, obstructions are now fairly well catered for so it's probably time to look at lines and areas. ------------------------------------------------ Yo Landlubbers, Here's the first cut at encoding support for extended type attributes. This is mostly concerned with marine entities like (wreck depths, buoy types, light types, colours, etc.) As there is quite a lot of it and I haven't sussed it all out yet, I thought it would make sense to post patches as I go along so that people can try it out and find the bugs sooner rather than later. The attribute values are supplied as special tags with a mkgmap:xt- prefix. So, for example, mkgmap:xt-depth=40.6m specifies the depth of something (in metres). This first tranche supports: Point types 0x0102xx (buoys/beacons) can have: mkgmap:xt-foundation-colour (a colour name from list FC below) mkgmap:xt-light-colour (a colour name from list LC below) mkgmap:xt-light-type (a type name from list LT below) mkgmap:xt-period (optional period in secs (not limited to integer) Point types 0x0103xx (entities with depth/height) and 0x0104xx (obstructions) mkgmap:xt-depth (a depth with optional units (ft or m) default is m) mkgmap:xt-height (alias for, and mutually exclusive to, xt-depth) mkgmap:xt-position (an optional position from list P below) These attributes are turned into a sequence of bytes that are embodied in the map object. For testing purposes you can also specify those bytes explicitly as a sequence of hex digits using the mkgmap:xt-extra-bytes tag but you won't want to use that unless you are working on attribute value encoding (like me!) Next up will be lights which I understand how to encode except for multiple lights and angles - still working on that. Then will come lines and areas. All feedback welcome. BTW a good source of info is the cgpsmapper manual which is readily available on the net. It has a chapter on marine types. --------------------------------- List FC "red", "green", "yellow", "white", "black", "black-yellow", "white-red", "black-red", "white-green", "red-yellow", "red-green", "orange", "black-yellow-black", "yellow-black", "yellow-black-yellow", "red-white", "green-red-green", "red-green-red", "black-red-black", "yellow-red-yellow", "green-red", "black-white", "white-orange", "orange-white", "green-white" List LC "unlit", "red", "green", "white", There is possibly some more light colours but I don't yet know how to encode them so we should stick with these for the moment. List LT "fixed", "isophase", "flashing", "group flashing", "composite group flashing", "occulting", "group occulting", "composite group occulting", "long flashing", "group long flashing", "morse", "quick", "group quick", "group quick and long flashing", "interrupted quick", "very quick", "group very quick", "group very quick and long flashing", "interrupted very quick", "ultra quick", "interrupted ultra quick", "fixed and occulting", "fixed and group occulting", "fixed and isophase", "fixed and flashing", "fixed and group flashing", "fixed and long flashing", "alternating", "alternating occulting", "alternating flashing", "alternating group flashing" The morse type takes a letter argument but I don't know how to encode that yet. List P "unknown", "doubtful", "existence doubtful", "approximate", "reported"

1 0

Sea Polygons and java 1.6
by Steve Ratcliffe 22 Aug '09

22 Aug '09

Hi The sea polygon patch uses a feature from java 1.6 (NavigableSet), whereas mkgmap is currently released for java 1.5. Perhaps there is a different way to do it that avoids the use, but it could be time to consider going to 1.6. Now I don't personally mind going to 1.6 and in fact I announced that this would 'happen soon' over a year ago. The only problem is people with Macs. As I have experienced with splitter (which always has required 1.6) there were quite a few queries to the mailing list and to my own email address from people not being able to run it. As there are many more downloads of mkgmap than splitter, I expect that there would be far more queries generated for mkgmap. Now as far as I know, it is no longer a problem getting 1.6 for all Macs, so I don't think anyone will be unable to run it, it is just a case of knowing what to download from where for which Mac 32/64 bit etc. So if we were to start requiring 1.6 I would like to prepare by adding a specific error message to mkgmap stating the version requirements, rather than just a stack trace that you would currently see, and to get a description of how to obtain 1.6 for the different Macs that can be placed on the wiki and web site etc. What do you think? ..Steve

6 7

Commit: r1143: Include secondary and tertiary link roads.
by svn commit 22 Aug '09

22 Aug '09

Version 1143 was commited by steve on 2009-08-22 19:15:21 +0100 (Sat, 22 Aug 2009) Include secondary and tertiary link roads. - Greg Troxel

1 0

secondary_links, tertiary_links
by Greg Troxel 22 Aug '09

22 Aug '09

While driving a while ago, I noticed highway ramps missing from my Vista HCx. Now, they are present but dashed lines. The problem is a combination of two things: a road that should be a motorway tagged as secondary (state highway), and mkgmap's default style not having rules for secondary_link and tertiary_link. I built maps with the following patch, and in RoadTrip the ramps now show up as ramps. Note that I used 0x09 insetad of 0x08 since that seems to be the lesser ramp class. Index: resources/styles/default/lines =================================================================== --- resources/styles/default/lines (revision 1122) +++ resources/styles/default/lines (working copy) @@ -45,10 +45,12 @@ highway=primary_link [0x08 road_class=3 road_speed=3 resolution 19] highway=residential | highway=living_street [0x06 road_class=0 road_speed=2 resolution 23] highway=secondary [0x04 road_class=2 road_speed=3 resolution 20] +highway=secondary_link [0x09 road_class=2 road_speed=2 resolution 20] highway=path {add access = no; add bicycle = yes; add foot = yes} [0x16 road_class=0 road_speed=0 resolution 23] highway=service [0x07 road_class=0 road_speed=1 resolution 22] highway=steps {add access = no; add foot = yes} [0x16 road_class=0 road_speed=0 resolution 23] highway=tertiary [0x05 road_class=1 road_speed=3 resolution 20] +highway=tertiary_link [0x09 road_class=1 road_speed=2 resolution 20] highway=track [0x0a road_class=0 road_speed=1 resolution 21] highway=trunk [0x02 road_class=3 road_speed=5 resolution 16] highway=trunk_link [0x08 road_class=3 road_speed=3 resolution 16]

1 1

[PATCH v1] - support for extended type attributes
by Mark Burton 22 Aug '09

22 Aug '09

Yo Landlubbers, Here's the first cut at encoding support for extended type attributes. This is mostly concerned with marine entities like (wreck depths, buoy types, light types, colours, etc.) As there is quite a lot of it and I haven't sussed it all out yet, I thought it would make sense to post patches as I go along so that people can try it out and find the bugs sooner rather than later. The attribute values are supplied as special tags with a mkgmap:xt- prefix. So, for example, mkgmap:xt-depth=40.6m specifies the depth of something (in metres). This first tranche supports: Point types 0x0102xx (buoys/beacons) can have: mkgmap:xt-foundation-colour (a colour name from list FC below) mkgmap:xt-light-colour (a colour name from list LC below) mkgmap:xt-light-type (a type name from list LT below) mkgmap:xt-period (optional period in secs (not limited to integer) Point types 0x0103xx (entities with depth/height) and 0x0104xx (obstructions) mkgmap:xt-depth (a depth with optional units (ft or m) default is m) mkgmap:xt-height (alias for, and mutually exclusive to, xt-depth) mkgmap:xt-position (an optional position from list P below) These attributes are turned into a sequence of bytes that are embodied in the map object. For testing purposes you can also specify those bytes explicitly as a sequence of hex digits using the mkgmap:xt-extra-bytes tag but you won't want to use that unless you are working on attribute value encoding (like me!) Next up will be lights which I understand how to encode except for multiple lights and angles - still working on that. Then will come lines and areas. All feedback welcome. BTW a good source of info is the cgpsmapper manual which is readily available on the net. It has a chapter on marine types. --------------------------------- List FC "red", "green", "yellow", "white", "black", "black-yellow", "white-red", "black-red", "white-green", "red-yellow", "red-green", "orange", "black-yellow-black", "yellow-black", "yellow-black-yellow", "red-white", "green-red-green", "red-green-red", "black-red-black", "yellow-red-yellow", "green-red", "black-white", "white-orange", "orange-white", "green-white" List LC "unlit", "red", "green", "white", There is possibly some more light colours but I don't yet know how to encode them so we should stick with these for the moment. List LT "fixed", "isophase", "flashing", "group flashing", "composite group flashing", "occulting", "group occulting", "composite group occulting", "long flashing", "group long flashing", "morse", "quick", "group quick", "group quick and long flashing", "interrupted quick", "very quick", "group very quick", "group very quick and long flashing", "interrupted very quick", "ultra quick", "interrupted ultra quick", "fixed and occulting", "fixed and group occulting", "fixed and isophase", "fixed and flashing", "fixed and group flashing", "fixed and long flashing", "alternating", "alternating occulting", "alternating flashing", "alternating group flashing" The morse type takes a letter argument but I don't know how to encode that yet. List P "unknown", "doubtful", "existence doubtful", "approximate", "reported"

1 0

Commit: r1142: Always
by svn commit 21 Aug '09

21 Aug '09

Version 1142 was commited by steve on 2009-08-21 19:32:36 +0100 (Fri, 21 Aug 2009) BRANCH: multipolygon Always

1 0

Overflowed directory error
by Carlos Dávila 21 Aug '09

21 Aug '09

Hello all While compiling a map from 6 tiles obtained with splitter (manually adjusted areas.list) I get the following error: GRAVE (BlockManager): overflowed directory with max block 65534, current=65535 There is not enough room in a single garmin map for all the input data The .osm file should be split into smaller pieces first. I guess I must split some of the tiles but, how to know which one? Does it depend on the size (in MB) of the resulting maps? Regards Carlos

3 5

Strange issue when searching for POI
by Nakor 21 Aug '09

21 Aug '09

Hello, I own a Garmin Vista HCx and I have generated a map around my area from SOM using mkgmap. When I search for a POI I see a strange behavior: if I use "Nearest containing..." or "Select Category", the POIs show up correctly. If I use "Find by name" no POI show up in the list. Is there something I should chaange in the way I use mkgmap to solve this? Thanks in advance, N.

1 0