- mkgmap-dev - The mkgmap lists

Algorithm for rendering sea
by Clifford Nolan 25 Aug '09

25 Aug '09

In the last message, I meant to say grow the "sea" not the "coastline"!

1 0

[PATCH v1] - add support for turn restriction 'except' tag
by Mark Burton 25 Aug '09

25 Aug '09

As per OSM Wiki, it expects vehicle classes to be separated with ';' Works in mapsource, not tried on a real GPS. Doesn't appear to work for either pedestrians or emergency vehicles.

1 0

About buoys and lighthouses
by David 24 Aug '09

24 Aug '09

It may be a surprise but colored lighthouses and morse code worked on Etrex Vista HCx before you added extended types. I used only style rules to obtain this map (see the capture).

2 1

[PATCH v4] - support for extended type attributes
by Mark Burton 24 Aug '09

24 Aug '09

v4 - no functional change, just reworked slightly to improve efficiency. I've tested this stuff with noddy examples but as I don't expect anyone is in a great rush to use it big time, we will have to wait to see what issues emerge (from the deep?) Anyway, as all of this code should have no effect on map elements without extended types, I reckon it should be safe to commit. So unless anyone has any problems with that, I shall commit it later this week and then at least it's there for people to dabble with. If you do try it out, please report results. --------------------------- v3 - more tweaks to lights + lines & areas "morse" light type now takes the morse letter to flash, e.g. "morse A" lights can be tagged as having a "racon" (you'll have to google it like I did!) by setting mkgmap:xt-racon to yes. Depth areas (type 0x0103xx) can have the depth attribute and lines 0x010105 to 0x010107 (contour, overhead cable, bridge) can have height. There is a new mkgmap:xt-style attribute that takes a 16 bit value. The bottom 4 bits specify a colour and bits 8-14 specify a line style. See the cgpsmapper manual for the supported colours and styles. As an example, a value of 0x3004 means red line like this +++++++ This can be used on lines with types 0x0104xx, 0x0105xx and 0x0106xx. You can also use the xt-style (colour part only) attribute on points of type 0x010500 which are labels with coloured text. The point's name tag is shown on the map in the colour you specify. Could be useful. There's still a bit more that could be done on on the light flash sequence encoding but as it's rather unlikely that anyone will every want to use that, I'm not bothering for the moment. So, the job is pretty much done. As usual, all feedback is welcome. -------------------------- 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

mkgmap build process: how to apply patches
by Torsten Leistikow 24 Aug '09

24 Aug '09

Moin, I am trying to attend the mkgmap devellopment, but I have still some trouble with the build process, partly because I am also not familiar with the Linux environment. As a start I installed Suse Linux and the Eclipse IDE. First step was downloading the source package from the mkgmap download page, extracting this package into a folder, creating an ANT-project in Eclipse and finally building mkgmap. Ok, this worked. Second step was using kdesvn and retrieving the sources from svn-trunk via subversion instead of downloading the source package. On this working copy I was again able to build mkgmap via an ANT-Eclipse-Project. But I haven't figured out yet, how to integrate a patch provided via this list into my build process. Can anybody give me some advise, how to use the patches? Gruss Torsten

4 7

Commit: r1144: For overlays only add the first one as a road.
by svn commit 24 Aug '09

24 Aug '09

Version 1144 was commited by steve on 2009-08-24 20:53:24 +0100 (Mon, 24 Aug 2009) For overlays only add the first one as a road. All the rest are added as regular lines. - Thilo Hannemann

1 0

Overlays and routing
by MarkS 24 Aug '09

24 Aug '09

I've just discovered the overlays file but eveytime I use it routing breaks for any road where an overlay is used (mapsource either crashes or it just draws a straight line). These are very short routes (a few hundred meters) and work if I turn the overlay off. I'm confident the overlay is working because I can see the extra way in mapsource and GPSMapedit. Should routing work with an overlay or am I wasting my time? Details: Mkgmap version: 1122 overlays file contains just this: 0x123: 0x23, 0x02 the lines file contains (amongst lots of other non overlay things): highway=trunk & oneway=yes [0x123 road_class=3 road_speed=5 resolution 16] I've tried values other than 0x23 in the overlays, all produce the same result but values over about 0x2c don't display in mapsource.

3 4

[PATCH] Don't show not constructed highway on map
by Ondrej Novy 24 Aug '09

24 Aug '09

Hi, i think we don't want to have not finished highwayes on map, so this attached patch fixies it. Thanks. -- S pozdravem/Best regards Bc. Ondrej Novy Email: novy(a)ondrej.org Jabber: onovy(a)njs.netlab.cz ICQ: 115-674-713 Tel/Cell: +420 777 963 207

2 2

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

23 Aug '09

v3 - more tweaks to lights + lines & areas "morse" light type now takes the morse letter to flash, e.g. "morse A" lights can be tagged as having a "racon" (you'll have to google it like I did!) by setting mkgmap:xt-racon to yes. Depth areas (type 0x0103xx) can have the depth attribute and lines 0x010105 to 0x010107 (contour, overhead cable, bridge) can have height. There is a new mkgmap:xt-style attribute that takes a 16 bit value. The bottom 4 bits specify a colour and bits 8-14 specify a line style. See the cgpsmapper manual for the supported colours and styles. As an example, a value of 0x3004 means red line like this +++++++ This can be used on lines with types 0x0104xx, 0x0105xx and 0x0106xx. You can also use the xt-style (colour part only) attribute on points of type 0x010500 which are labels with coloured text. The point's name tag is shown on the map in the colour you specify. Could be useful. There's still a bit more that could be done on on the light flash sequence encoding but as it's rather unlikely that anyone will every want to use that, I'm not bothering for the moment. So, the job is pretty much done. As usual, all feedback is welcome. -------------------------- 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

Splitter and description
by frmas 23 Aug '09

23 Aug '09

Hello, According to the web site, I can change the description given in the template.args file for each file created. Is it possible to give an option to the command line to tell the splitter to write a specific description in the template.args file. That way it's possible to run the splitter, then mkgmapp without intervention. Something like : java -jar splitter.jar --Description="bla bla bla" would result in the template.args file : mapname: 63240501 description: bla bla bla input-file: 63240501.osm.gz mapname: 63240502 description: bla bla bla input-file: 63240502.osm.gz I also noticed that "java -jar splitter.jar --help=options" doesn't give me any information about the splitter options. Is it not implemented, or is it me? Thank you. Francois

3 4