Index: doc/options.txt =================================================================== --- doc/options.txt (revision 4602) +++ doc/options.txt (working copy) @@ -615,66 +615,8 @@ This generator uses ESRI shapefiles as its source data. It is not included in the standard mkgmap build due to its dependencies on external libraries. -=== Miscellaneous options === +=== Diagnostic options === -;--max-jobs[=integer] -: Specify the number of threads to be used for concurrent processing. -Increasing max-jobs will reduce the execution time, providing sufficient -memory is available and the value is not greater than the number of cores -in the CPU. If no value is specified, the limit is set to the number of CPU -cores. The default is for the limit to be automatically set to a reasonable -value based on the amount of memory allocated to the Java runtime and the -amount used in processing the first tile. - -;--keep-going -: Don't quit whole application if an exception occurs while -processing a map - continue to process the other maps. - -;--block-size=integer -: Changes the block size that is used in the generated map. This -option is not usually needed, but sometimes an error message -will ask you to try a value for this option. - -;--net -: Tells mkgmap to write NET data, which is needed for address search -and routing. Use this option if you want address search, but do -not need a map that supports routing or house number search. - -;--route -: Tells mkgmap to write NET and NOD data, which are needed in maps -that support routing. If you specify this option, you do not need -to specify --net and --no-net is ignored. - -;--add-boundary-nodes-at-admin-boundaries=NUM -: This option controls how mkgmap calculates special routing nodes which -are needed by Garmin software to allow routing between different map tiles. -These nodes are written to section 3 and 4 in the NOD file. -When a road crosses the tile boundary (bbox), the road is split at this -point and such a special node is written. This allows routing between -one set of tiles produced by splitter.jar. However, if you create a map -from different sets of tiles, those tiles are likely to overlap. -For the overlapping tiles, none of the entries in NOD3 match and thus -routing across tile border doesn't work when the route is not fully -covered by one of the tiles. -The option tells mkgmap to add special nodes wherever a road touches or -crosses an administrative boundary. The NUM parameter specifies a filter -for the admin_level. Boundaries with a higher admin_level value are ignored. -The default value is 2 (country borders). Another reasonable value might -be 4. A value less or equal to 0 tells mkgmap to ignore intersections at -administrative boundaries. - -;--drive-on=left|right|detect|detect,left|detect,right -: Explicitly specify which side of the road vehicles are -expected to drive on. -If the first option is detect, the program tries -to find out the proper flag. If that detection -fails, the second value is used (or right if none is given). -With OSM data as input, the detection tries to find out -the country each road is in and compares the number -of drive-on-left roads with the rest. -Use the --bounds option to make sure that the detection -finds the correct country. - ;--check-roundabouts : Check that roundabouts have the expected direction (clockwise when vehicles drive on the left). Roundabouts that are complete @@ -714,27 +656,6 @@ : See also option --add-boundary-nodes-at-admin-boundaries. : This option seems to cause routing problems in BaseCamp. -;--ignore-turn-restrictions -: When reading OSM files, ignore any "restriction" relations. - -;--ignore-osm-bounds -: When reading OSM files, ignore any "bounds" elements. -With this option selected generate-sea sometimes works better, -but routing across tiles will not work. - -;--preserve-element-order -: Process the map elements (nodes, ways, relations) in the order -in which they appear in the OSM input. Without this option, -the order in which the elements are processed is not defined. - -;--cycle-map -: Tells mkgmap that the map is for cyclists. This assumes that -different vehicles are different kinds of bicycles, e.g. a way -with mkgmap:car=yes and mkgmap:bicycle=no may be a road that is -good for racing bikes, but not for other cyclists. -This allows the optimisation of sharp angles at junctions of those roads. -Don't use with the default style as that is a general style! - ;--report-similar-arcs : Issue a warning when more than one arc connects two nodes and the ways that the arcs are derived from contain identical @@ -756,6 +677,8 @@ If no value or * is specified for value then presence of the key alone will cause the dead end check to be skipped. The default is --dead-ends=fixme,FIXME. +=== POI options === + ;--add-pois-to-lines[=all|start|end|mid|other] : Generate nodes that may be used by the points file to produce POIs at various positions of non-closed lines. The option expects a comma separated list that @@ -797,6 +720,149 @@ : Generate a POI index in each map tile. Probably not used by modern devices, but still supported. +;--poi-address +: Enable address / phone information to POIs. Address info is +read according to the "Karlsruhe" tagging schema. Automatic +filling of missing information could be enabled using the --location-autofill option. +Default is enabled, use --no-poi-address to disable. + +;--nearby-poi-rules=type[-type][/all|named|unnamed]:distance[:delete-poi|delete-name][,...] +: Defines a set of rules to follow when a POI is near to another of the +same type and label. Each rule consists of three parts separated by colons. The +first two parts must be provided; the last part can be defaulted. + +: The first part of the rule is a Garmin POI type code or range of type codes, +with an optional suffix; it determines when the rule is triggered. A type code may be +specified in decimal or hexadecimal (e.g. 0x2c0b). A rule is triggered +when processing a POI if the type code of the POI matches the rule type +or falls within the range of type codes, +providing there is also a match in the POI name and the first part +suffix. If the suffix is '/all' (the default) then the match is only made +on the type. If the suffix is '/named' then the rule is only triggered if +the POI has a name. If the suffix is '/unnamed' then the rule is only +triggered if the POI has no name. A wildcard of an asterisk character may +be used to match any type code. The wildcard may also be combined with a +suffix to allow separate processing of named and unnamed POIs. + +: The second part of the rule is the distance in metres which an already +processed POI must be within for it to be considered to be nearby and +hence trigger the action part of the rule. + +: The third part of the rule is the action part and provides two options: + +:: delete-poi - the POIS are considered to be duplicates and the +duplicate is deleted. This is the default. +:: delete-name - the POIS are not duplicates, but only a single +name needs to be displayed. + +: Wildcard rules are only applied if no other rule is applicable. + +: For example: +: --nearby-poi-rules=*/named:10,*/unnamed:25,0x2f17-0x2f1f:30 + +: This has the following effect: +: If no other rule applies, a POI with the same name and type and + within 10m of one already processed will be deleted. +: If no other rule applies, a POI having no name and of the same type + and within 25m of one already processed will be deleted. +: A POI of any type between 0x2f17 and 0x2f1f that is within 30m of + another POI with the same type will be deleted. + +: If you have a lot of rules, the --nearby-poi-rules-config option is likely to +be easier to use. + +: Note: a POI that matches another in type, name and exact location is always +considered a duplicate and deleted. + +;--nearby-poi-rules-config=filename +:Allows you to specify the nearby POI rules as described in the --nearby-poi-rules option +in a configuration file. +The format of the rules is the same as in --nearby-poi-rules, except that each rule is +specified on a separate line, rather than separated by commas. This format makes it easier +to view and maintain the rules when you have a lot of them. If you just have one or two rules, +it is simpler to use the --nearby-poi-rules option. + +=== Miscellaneous options === + +;--max-jobs[=integer] +: Specify the number of threads to be used for concurrent processing. +Increasing max-jobs will reduce the execution time, providing sufficient +memory is available and the value is not greater than the number of cores +in the CPU. If no value is specified, the limit is set to the number of CPU +cores. The default is for the limit to be automatically set to a reasonable +value based on the amount of memory allocated to the Java runtime and the +amount used in processing the first tile. + +;--keep-going +: Don't quit whole application if an exception occurs while +processing a map - continue to process the other maps. + +;--block-size=integer +: Changes the block size that is used in the generated map. This +option is not usually needed, but sometimes an error message +will ask you to try a value for this option. + +;--net +: Tells mkgmap to write NET data, which is needed for address search +and routing. Use this option if you want address search, but do +not need a map that supports routing or house number search. + +;--route +: Tells mkgmap to write NET and NOD data, which are needed in maps +that support routing. If you specify this option, you do not need +to specify --net and --no-net is ignored. + +;--add-boundary-nodes-at-admin-boundaries=NUM +: This option controls how mkgmap calculates special routing nodes which +are needed by Garmin software to allow routing between different map tiles. +These nodes are written to section 3 and 4 in the NOD file. +When a road crosses the tile boundary (bbox), the road is split at this +point and such a special node is written. This allows routing between +one set of tiles produced by splitter.jar. However, if you create a map +from different sets of tiles, those tiles are likely to overlap. +For the overlapping tiles, none of the entries in NOD3 match and thus +routing across tile border doesn't work when the route is not fully +covered by one of the tiles. +The option tells mkgmap to add special nodes wherever a road touches or +crosses an administrative boundary. The NUM parameter specifies a filter +for the admin_level. Boundaries with a higher admin_level value are ignored. +The default value is 2 (country borders). Another reasonable value might +be 4. A value less or equal to 0 tells mkgmap to ignore intersections at +administrative boundaries. + +;--drive-on=left|right|detect|detect,left|detect,right +: Explicitly specify which side of the road vehicles are +expected to drive on. +If the first option is detect, the program tries +to find out the proper flag. If that detection +fails, the second value is used (or right if none is given). +With OSM data as input, the detection tries to find out +the country each road is in and compares the number +of drive-on-left roads with the rest. +Use the --bounds option to make sure that the detection +finds the correct country. + +;--ignore-turn-restrictions +: When reading OSM files, ignore any "restriction" relations. + +;--ignore-osm-bounds +: When reading OSM files, ignore any "bounds" elements. +With this option selected generate-sea sometimes works better, +but routing across tiles will not work. + +;--preserve-element-order +: Process the map elements (nodes, ways, relations) in the order +in which they appear in the OSM input. Without this option, +the order in which the elements are processed is not defined. + +;--cycle-map +: Tells mkgmap that the map is for cyclists. This assumes that +different vehicles are different kinds of bicycles, e.g. a way +with mkgmap:car=yes and mkgmap:bicycle=no may be a road that is +good for racing bikes, but not for other cyclists. +This allows the optimisation of sharp angles at junctions of those roads. +Don't use with the default style as that is a general style! + ;--nsis : Write a .nsi file that can be used with the Nullsoft Scriptable Install System (NSIS) to create a Windows Installer for using the map in BaseCamp. @@ -905,12 +971,6 @@ already installed on the PC and therefore there is no need to read it from the device. -;--poi-address -: Enable address / phone information to POIs. Address info is -read according to the "Karlsruhe" tagging schema. Automatic -filling of missing information could be enabled using the --location-autofill option. -Default is enabled, use --no-poi-address to disable. - ;--verbose : Makes some operations more verbose. Mostly used with --list-styles. @@ -921,62 +981,6 @@ The tag mkgmap:drawLevel can be used to override the natural area of a polygon, so forcing changes to the rendering order. -;--nearby-poi-rules=type[-type][/all|named|unnamed]:distance[:delete-poi|delete-name][,...] -: Defines a set of rules to follow when a POI is near to another of the -same type and label. Each rule consists of three parts separated by colons. The -first two parts must be provided; the last part can be defaulted. - -: The first part of the rule is a Garmin POI type code or range of type codes, -with an optional suffix; it determines when the rule is triggered. A type code may be -specified in decimal or hexadecimal (e.g. 0x2c0b). A rule is triggered -when processing a POI if the type code of the POI matches the rule type -or falls within the range of type codes, -providing there is also a match in the POI name and the first part -suffix. If the suffix is '/all' (the default) then the match is only made -on the type. If the suffix is '/named' then the rule is only triggered if -the POI has a name. If the suffix is '/unnamed' then the rule is only -triggered if the POI has no name. A wildcard of an asterisk character may -be used to match any type code. The wildcard may also be combined with a -suffix to allow separate processing of named and unnamed POIs. - -: The second part of the rule is the distance in metres which an already -processed POI must be within for it to be considered to be nearby and -hence trigger the action part of the rule. - -: The third part of the rule is the action part and provides two options: - -:: delete-poi - the POIS are considered to be duplicates and the -duplicate is deleted. This is the default. -:: delete-name - the POIS are not duplicates, but only a single -name needs to be displayed. - -: Wildcard rules are only applied if no other rule is applicable. - -: For example: -: --nearby-poi-rules=*/named:10,*/unnamed:25,0x2f17-0x2f1f:30 - -: This has the following effect: -: If no other rule applies, a POI with the same name and type and - within 10m of one already processed will be deleted. -: If no other rule applies, a POI having no name and of the same type - and within 25m of one already processed will be deleted. -: A POI of any type between 0x2f17 and 0x2f1f that is within 30m of - another POI with the same type will be deleted. - -: If you have a lot of rules, the --nearby-poi-rules-config option is likely to -be easier to use. - -: Note: a POI that matches another in type, name and exact location is always -considered a duplicate and deleted. - -;--nearby-poi-rules-config=filename -:Allows you to specify the nearby POI rules as described in the --nearby-poi-rules option -in a configuration file. -The format of the rules is the same as in --nearby-poi-rules, except that each rule is -specified on a separate line, rather than separated by commas. This format makes it easier -to view and maintain the rules when you have a lot of them. If you just have one or two rules, -it is simpler to use the --nearby-poi-rules option. - === Deprecated and Obsolete Options === ;--drive-on-left