[Git][debian-gis-team/mkgmap][upstream] New upstream version 0.0.0+svn4604
Bas Couwenberg
gitlab at salsa.debian.org
Mon Mar 1 15:40:58 GMT 2021
Bas Couwenberg pushed to branch upstream at Debian GIS Project / mkgmap
Commits:
23e99217 by Bas Couwenberg at 2021-03-01T16:32:56+01:00
New upstream version 0.0.0+svn4604
- - - - -
6 changed files:
- doc/options.txt
- resources/help/en/options
- resources/mkgmap-version.properties
- src/uk/me/parabola/mkgmap/osmstyle/housenumber/HousenumberGenerator.java
- src/uk/me/parabola/mkgmap/osmstyle/housenumber/HousenumberRoad.java
- src/uk/me/parabola/mkgmap/reader/osm/SeaGenerator.java
Changes:
=====================================
doc/options.txt
=====================================
@@ -197,7 +197,7 @@ only the words in the important part are indexed.
:: - On the PC, when zooming out, the name 'Rue de la Concorde' is only
rendered as 'Concorde'.
:: - The index for road names only contains the important part of the name.
-You can search for road name Conc to find road names like 'Rue de la Concorde'.
+You can search for road name 'Conc' to find road names like 'Rue de la Concorde'.
However, a search for 'Rue' will not list 'Rue de la Concorde' or 'Rue du Moulin'.
It may list 'Rueben Brookins Road' if that is in the map.
@@ -537,65 +537,85 @@ Reasonable values depend on the size of the area and the lowest resolution
used for the single tiles, good compromises are somewhere between 55000
and 276160.
-=== 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.
+=== Sea Processing options ===
-;--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.
+If your map contains sea areas then you will need to use --generate-sea to generate
+the sea areas from the OSM files or --precomp-sea to use separate precompiled sea tiles.
-;--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.
+;--generate-sea[=VALUE[,...]]
+: Generate sea polygons. When this option is specified, the sea is generated using a
+multipolygon unless the polygons value is specified. The coastline data can be read from
+the input OSM files, separate files containing coastline data if --coastlinefile
+is specified or precompiled sea data if --precomp-sea is specified. The VALUEs are as follows:
+:;multipolygon
+:: generate the sea using a multipolygon. This is the default value.
+:;polygons | no-mp
+:: don't generate the sea using a multipolygon - instead,
+generate a background sea polygon plus individual land
+polygons (see land-tag value).
+:;land-tag=TAG=VAL
+:: tag to use for land polygons (default natural=land) created by the polygons option.
+For these to be visible in the Garmin map, a suitable land polygon type must
+be defined in the TYP file (suggested type is 0x010100 or 0x54), the polygon must
+have a higher drawing level than the sea polygon type and the style file must link
+TAG=VAL to the land polygon type defined in the TYP file.
+:;no-sea-sectors
+:: disable the generation of "sea sectors" when the
+coastline fails to reach the tile's boundary.
+Under some conditions land sectors are generated instead and these use land-tag.
+:;extend-sea-sectors
+:: Adds a point so coastline reaches the nearest tile boundary.
+This implies no-sea-sectors.
+:;close-gaps=NUM
+:: close gaps in coastline that are less than this distance (metres)
+:;floodblocker
+:: enable the flood blocker that prevents a flooding of
+land by checking if the sea polygons contain streets
+(works only with multipolygon processing)
+:;fbgap=NUM
+:: flood blocker gap in metre (default 40)
+points that are closer to the sea polygon do not block
+:;fbthres=NUM
+:: at least so many highway points must be contained in
+a sea polygon so that it may be removed by the flood
+blocker (default 20)
+:;fbratio=NUM
+:: only sea polygons with a higher ratio
+(highway points x 100000 / polygon size) are removed
+(default 0.5)
+:;fbdebug
+:: switches on the debugging of the flood blocker
+generates GPX files for each polygon checked by
+the flood blocker
+:;check
+:: check whether the coastline data contains sea within sea or land
+within land
-;--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.
+;--coastlinefile=filename[,filename...]
+: Defines a comma separated list of OSM or PBF format files that contain
+coastline data to be used instead of extracting the data from the input files.
+If you specify --coastlinefile you must also specify --generate-sea.
-;--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.
+;--precomp-sea=directory|zipfile
+: Defines the directory or a zip file that contains precompiled sea data.
+Sea data in a zip file must be located in the zip file's root directory or in
+a sub directory named sea. When this option is defined, natural=coastline tags
+from the input OSM files are ignored, the --coastlinefile option is ignored
+and the precompiled data is used instead.
+You can use the multipolygon, polygon and land-tag values of the --generate-sea
+option in conjunction with --precomp-sea to control the way the sea is built,
+but the other --generate-sea values are not available.
+If --generate-sea is not specified, the --precomp-sea option sets --generate-sea=multipolygon.
+
+You can download procompiled sea data for the whole world from the mkgmap download page at
+http://www.mkgmap.org.uk/download/mkgmap.html
+
+If you want to build your own precompiled sea data, you will need to build a copy
+of mkgmap from the source, with the optional PrecompSeaGenerator source included.
+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.
+
+=== Diagnostic options ===
;--check-roundabouts
: Check that roundabouts have the expected direction (clockwise
@@ -636,27 +656,6 @@ a different tile.
: 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
@@ -678,27 +677,29 @@ nodes matching any of the items in the list will not be reported as dead ends.
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 POIs for lines. The option expects a comma separated list that
-specifies the positions for which are POI should be generated. The default is
-to create all possible POI. For each line (must not be closed) POIs are
-created at several points of the line. Each POI is tagged with the
-same tags like the line and additional tags added by mkgmap:
-mkgmap:line2poi=true and tag mkgmap:line2poitype having
-the following values:
+: 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
+specifies the positions at which a node should be generated. The default is all.
+If the inner or all values are used, a lot of points are likely to be generated and
+these are likely to need filtering in the points file.
+Each node is tagged with the same tags as the line plus mkgmap generated tags
+mkgmap:line2poi=true and mkgmap:line2poitype with one of the following values:
:* start - The first point of the line
:* end - The last point of the line
:* inner - Each point of the line except the first and the last
-:* mid - The middle point
+:* mid - An extra point added by mkgmap at the middle of the line
;--add-pois-to-areas
-: Generate a POI for each polygon and multipolygon. The POIs are created
-after the relation style but before the other styles are applied. Each
-POI is tagged with the same tags of
-the area/multipolygon. Additionally the tag mkgmap:area2poi=true is
-set so that it is possible to use that information in the points style
-file. Artificial polygons created by multipolyon processing are not used.
-The POIs are created at the following positions:
+: For each polygon and multipolygon, generate a node that may be used by the
+points file to produce a POI.
+The nodes are created after the relation style but before the other styles are applied.
+Each node is tagged with the same tags of the area/multipolygon, plus mkgmap generated
+tag mkgmap:area2poi=true.
+Artificial polygons created by multipolyon processing are not used.
+The nodes are created at the following positions:
:;polygons: the first rule that applies of:
::* the first node tagged with a tag defined by the --pois-to-areas-placement option
::* the centre point
@@ -707,75 +708,161 @@ The POIs are created at the following positions:
::* the centre point of the biggest area
;--pois-to-areas-placement=tag=value[;tag=value...]
-: A POI is placed at the first node of the polygon tagged with the first tag/value
+: A node is placed at the first node of the polygon tagged with the first tag/value
pair. If none of the nodes are tagged with the first tag-value pair the first node
tagged with the second tag-value pair is used and so on. If none of the tag-value pairs
-matches or the taglist is empty, the centre of the polygon is used.
+matches or no tag-value pairs are supplied, the centre of the polygon is used.
It is possible to define wildcards for tag values like entrance=*.
<p>
Default: entrance=main;entrance=yes;building=entrance
-;--precomp-sea=directory|zipfile
-: Defines the directory or a zip file that contains precompiled sea tiles.
-Sea files in a zip file must be located in the zip file's root directory or in
-a sub directory sea. When this option is defined, natural=coastline tags
-from the input OSM tiles are ignored and the precompiled data is used instead.
-This option can be combined with the generate-sea options multipolygon, polygons
-and land-tag. The --coastlinefile option is ignored if --precomp-sea is set.
-
-;--coastlinefile=filename[,filename...]
-: Defines a comma separated list of files that contain coastline
-data. The coastline data from the input files is ignored if
-this option is set. Files must have OSM or PBF file format.
-
-;--generate-sea[=ValueList]
-: Generate sea polygons. ValueList is 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 land-tag (see following).
-:;no-sea-sectors
-:: disable the generation of "sea sectors" when the
-coastline fails to reach the tile's boundary.
-Under some conditions land sectors are generated instead and these use land-tag.
-:;extend-sea-sectors
-:: Adds a point so coastline reaches the nearest tile boundary.
-This implies no-sea-sectors.
-:;land-tag=TAG=VAL
-:: tag to use for land polygons (default natural=land).
-If not using "multipolygon" or land sectors are being generated, then
-a suitable land polygon type needs to be defined in the style
-file (suggested type is 0x010100 or 0x54) and the polygon must
-be defined in the TYP file as having a higher drawing
-level than the sea polygon type.
-:;close-gaps=NUM
-:: close gaps in coastline that are less than this distance (metres)
-:;floodblocker
-:: enable the flood blocker that prevents a flooding of
-land by checking if the sea polygons contain streets
-(works only with multipolygon processing)
-:;fbgap=NUM
-:: flood blocker gap in metre (default 40)
-points that are closer to the sea polygon do not block
-:;fbthres=NUM
-:: at least so many highway points must be contained in
-a sea polygon so that it may be removed by the flood
-blocker (default 20)
-:;fbratio=NUM
-:: only sea polygons with a higher ratio
-(highway points x 100000 / polygon size) are removed
-(default 0.5)
-:;fbdebug
-:: switches on the debugging of the flood blocker
-generates GPX files for each polygon checked by
-the flood blocker
-
;--make-poi-index
: 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.
@@ -884,12 +971,6 @@ The default value is 25.
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.
@@ -900,62 +981,6 @@ that smaller features are rendered over larger ones
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
=====================================
resources/help/en/options
=====================================
@@ -194,8 +194,8 @@ filename
- On the PC, when zooming out, the name 'Rue de la Concorde' is only
rendered as 'Concorde'.
- The index for road names only contains the important part of the
- name. You can search for road name Conc to find road names like 'Rue de
- la Concorde'. However, a search for 'Rue' will not list 'Rue de la
+ name. You can search for road name 'Conc' to find road names like 'Rue
+ de la Concorde'. However, a search for 'Rue' will not list 'Rue de la
Concorde' or 'Rue du Moulin'. It may list 'Rueben Brookins Road' if
that is in the map.
@@ -527,61 +527,86 @@ filename
resolution used for the single tiles, good compromises are somewhere
between 55000 and 276160.
-=== 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.
+=== Sea Processing options ===
---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.
+If your map contains sea areas then you will need to use --generate-sea to
+generate the sea areas from the OSM files or --precomp-sea to use separate
+precompiled sea tiles.
---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.
+--generate-sea[=VALUE[,...]]
+ Generate sea polygons. When this option is specified, the sea is generated
+ using a multipolygon unless the polygons value is specified. The coastline
+ data can be read from the input OSM files, separate files containing
+ coastline data if --coastlinefile is specified or precompiled sea data if
+ --precomp-sea is specified. The VALUEs are as follows:
+ multipolygon
+ generate the sea using a multipolygon. This is the default value.
+ polygons | no-mp
+ don't generate the sea using a multipolygon - instead, generate a
+ background sea polygon plus individual land polygons (see land-tag
+ value).
+ land-tag=TAG=VAL
+ tag to use for land polygons (default natural=land) created by the
+ polygons option. For these to be visible in the Garmin map, a suitable
+ land polygon type must be defined in the TYP file (suggested type is
+ 0x010100 or 0x54), the polygon must have a higher drawing level than
+ the sea polygon type and the style file must link TAG=VAL to the land
+ polygon type defined in the TYP file.
+ no-sea-sectors
+ disable the generation of "sea sectors" when the coastline fails to
+ reach the tile's boundary. Under some conditions land sectors are
+ generated instead and these use land-tag.
+ extend-sea-sectors
+ Adds a point so coastline reaches the nearest tile boundary. This
+ implies no-sea-sectors.
+ close-gaps=NUM
+ close gaps in coastline that are less than this distance (metres)
+ floodblocker
+ enable the flood blocker that prevents a flooding of land by checking
+ if the sea polygons contain streets (works only with multipolygon
+ processing)
+ fbgap=NUM
+ flood blocker gap in metre (default 40) points that are closer to the
+ sea polygon do not block
+ fbthres=NUM
+ at least so many highway points must be contained in a sea polygon so
+ that it may be removed by the flood blocker (default 20)
+ fbratio=NUM
+ only sea polygons with a higher ratio (highway points x 100000 /
+ polygon size) are removed (default 0.5)
+ fbdebug
+ switches on the debugging of the flood blocker generates GPX files for
+ each polygon checked by the flood blocker
+ check
+ check whether the coastline data contains sea within sea or land within
+ land
---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.
+--coastlinefile=filename[,filename...]
+ Defines a comma separated list of OSM or PBF format files that contain
+ coastline data to be used instead of extracting the data from the input
+ files. If you specify --coastlinefile you must also specify --generate-sea.
---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.
+--precomp-sea=directory|zipfile
+ Defines the directory or a zip file that contains precompiled sea data. Sea
+ data in a zip file must be located in the zip file's root directory or in a
+ sub directory named sea. When this option is defined, natural=coastline
+ tags from the input OSM files are ignored, the --coastlinefile option is
+ ignored and the precompiled data is used instead. You can use the
+ multipolygon, polygon and land-tag values of the --generate-sea option in
+ conjunction with --precomp-sea to control the way the sea is built, but the
+ other --generate-sea values are not available. If --generate-sea is not
+ specified, the --precomp-sea option sets --generate-sea=multipolygon.
+
+You can download procompiled sea data for the whole world from the mkgmap
+download page at http://www.mkgmap.org.uk/download/mkgmap.html
+
+If you want to build your own precompiled sea data, you will need to build a
+copy of mkgmap from the source, with the optional PrecompSeaGenerator source
+included. 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.
+
+=== Diagnostic options ===
--check-roundabouts
Check that roundabouts have the expected direction (clockwise when vehicles
@@ -621,27 +646,6 @@ filename
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 points. It doesn't make sense
@@ -662,26 +666,29 @@ filename
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 POIs for lines. The option expects a comma separated list that
- specifies the positions for which are POI should be generated. The default
- is to create all possible POI. For each line (must not be closed) POIs are
- created at several points of the line. Each POI is tagged with the same
- tags like the line and additional tags added by mkgmap:
- mkgmap:line2poi=true and tag mkgmap:line2poitype having the following
- values:
+ 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 specifies the positions at which a node should be generated. The
+ default is all. If the inner or all values are used, a lot of points are
+ likely to be generated and these are likely to need filtering in the points
+ file. Each node is tagged with the same tags as the line plus mkgmap
+ generated tags mkgmap:line2poi=true and mkgmap:line2poitype with one of the
+ following values:
* start - The first point of the line
* end - The last point of the line
* inner - Each point of the line except the first and the last
- * mid - The middle point
+ * mid - An extra point added by mkgmap at the middle of the line
--add-pois-to-areas
- Generate a POI for each polygon and multipolygon. The POIs are created
- after the relation style but before the other styles are applied. Each POI
- is tagged with the same tags of the area/multipolygon. Additionally the tag
- mkgmap:area2poi=true is set so that it is possible to use that information
- in the points style file. Artificial polygons created by multipolyon
- processing are not used. The POIs are created at the following positions:
+ For each polygon and multipolygon, generate a node that may be used by the
+ points file to produce a POI. The nodes are created after the relation
+ style but before the other styles are applied. Each node is tagged with the
+ same tags of the area/multipolygon, plus mkgmap generated tag
+ mkgmap:area2poi=true. Artificial polygons created by multipolyon processing
+ are not used. The nodes are created at the following positions:
polygons: the first rule that applies of:
* the first node tagged with a tag defined by the
--pois-to-areas-placement option
@@ -691,74 +698,159 @@ filename
* the centre point of the biggest area
--pois-to-areas-placement=tag=value[;tag=value...]
- A POI is placed at the first node of the polygon tagged with the first
+ A node is placed at the first node of the polygon tagged with the first
tag/value pair. If none of the nodes are tagged with the first tag-value
pair the first node tagged with the second tag-value pair is used and so
- on. If none of the tag-value pairs matches or the taglist is empty, the
- centre of the polygon is used. It is possible to define wildcards for tag
- values like entrance=*.
+ on. If none of the tag-value pairs matches or no tag-value pairs are
+ supplied, the centre of the polygon is used. It is possible to define
+ wildcards for tag values like entrance=*.
Default: entrance=main;entrance=yes;building=entrance
---precomp-sea=directory|zipfile
- Defines the directory or a zip file that contains precompiled sea tiles.
- Sea files in a zip file must be located in the zip file's root directory or
- in a sub directory sea. When this option is defined, natural=coastline tags
- from the input OSM tiles are ignored and the precompiled data is used
- instead. This option can be combined with the generate-sea options
- multipolygon, polygons and land-tag. The --coastlinefile option is ignored
- if --precomp-sea is set.
-
---coastlinefile=filename[,filename...]
- Defines a comma separated list of files that contain coastline data. The
- coastline data from the input files is ignored if this option is set. Files
- must have OSM or PBF file format.
-
---generate-sea[=ValueList]
- Generate sea polygons. ValueList is 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 land-tag (see
- following).
- no-sea-sectors
- disable the generation of "sea sectors" when the coastline fails to
- reach the tile's boundary. Under some conditions land sectors are
- generated instead and these use land-tag.
- extend-sea-sectors
- Adds a point so coastline reaches the nearest tile boundary. This
- implies no-sea-sectors.
- land-tag=TAG=VAL
- tag to use for land polygons (default natural=land). If not using
- "multipolygon" or land sectors are being generated, then a suitable
- land polygon type needs to be defined in the style file (suggested type
- is 0x010100 or 0x54) and the polygon must be defined in the TYP file as
- having a higher drawing level than the sea polygon type.
- close-gaps=NUM
- close gaps in coastline that are less than this distance (metres)
- floodblocker
- enable the flood blocker that prevents a flooding of land by checking
- if the sea polygons contain streets (works only with multipolygon
- processing)
- fbgap=NUM
- flood blocker gap in metre (default 40) points that are closer to the
- sea polygon do not block
- fbthres=NUM
- at least so many highway points must be contained in a sea polygon so
- that it may be removed by the flood blocker (default 20)
- fbratio=NUM
- only sea polygons with a higher ratio (highway points x 100000 /
- polygon size) are removed (default 0.5)
- fbdebug
- switches on the debugging of the flood blocker generates GPX files for
- each polygon checked by the flood blocker
-
--make-poi-index
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.
@@ -864,12 +956,6 @@ filename
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.
@@ -879,63 +965,6 @@ filename
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
=====================================
resources/mkgmap-version.properties
=====================================
@@ -1,2 +1,2 @@
-svn.version: 4600
-build.timestamp: 2021-01-25T19:13:35+0000
+svn.version: 4604
+build.timestamp: 2021-02-28T07:50:49+0000
=====================================
src/uk/me/parabola/mkgmap/osmstyle/housenumber/HousenumberGenerator.java
=====================================
@@ -638,7 +638,7 @@ public class HousenumberGenerator {
while (iter.hasNext()) {
HousenumberRoad hnr = iter.next();
- List<HousenumberMatch> lostHouses = hnr.checkStreetName(road2HousenumberRoadMap, nodeId2RoadLists);
+ List<HousenumberMatch> lostHouses = hnr.checkStreetName(nodeId2RoadLists);
for (HousenumberMatch house : lostHouses) {
MapRoad r = house.getRoad();
if (r != null) {
@@ -1181,7 +1181,7 @@ public class HousenumberGenerator {
if (house.getRoad() != null && !house.isIgnored()) {
HousenumberRoad hnr = road2HousenumberRoadMap.get(house.getRoad());
if (hnr == null) {
- log.error("internal error: found no housenumber road for interpolated house",house.toBrowseURL());
+ log.error("internal error: found no housenumber road for interpolated house number", house.getHousenumber(),house.toBrowseURL());
continue;
}
hnr.addHouse(house);
=====================================
src/uk/me/parabola/mkgmap/osmstyle/housenumber/HousenumberRoad.java
=====================================
@@ -13,8 +13,6 @@
package uk.me.parabola.mkgmap.osmstyle.housenumber;
-import it.unimi.dsi.fastutil.ints.Int2ObjectOpenHashMap;
-
import java.util.ArrayList;
import java.util.Arrays;
import java.util.Collections;
@@ -23,9 +21,9 @@ import java.util.HashSet;
import java.util.Iterator;
import java.util.LinkedHashSet;
import java.util.List;
-import java.util.Map;
import java.util.Map.Entry;
+import it.unimi.dsi.fastutil.ints.Int2ObjectOpenHashMap;
import uk.me.parabola.imgfmt.app.Coord;
import uk.me.parabola.log.Logger;
import uk.me.parabola.mkgmap.general.CityInfo;
@@ -651,12 +649,10 @@ public class HousenumberRoad {
* Identify those houses which are assigned to this road because it was the closest,
* but can't be correct because street name doesn't match.
*
- * @param road2HousenumberRoadMap maps {@link MapRoad} instances to corresponding
- * {@link HousenumberRoad} instances
* @param nodeId2RoadLists maps node ids to the {@link MapRoad} that use the corresponding nodes.
* @return
*/
- public List<HousenumberMatch> checkStreetName(Map<MapRoad, HousenumberRoad> road2HousenumberRoadMap, Int2ObjectOpenHashMap<HashSet<MapRoad>> nodeId2RoadLists) {
+ public List<HousenumberMatch> checkStreetName(Int2ObjectOpenHashMap<HashSet<MapRoad>> nodeId2RoadLists) {
List<HousenumberMatch> noWrongHouses = Collections.emptyList();
List<HousenumberMatch> wrongHouses = Collections.emptyList();
double minDist = Double.MAX_VALUE;
=====================================
src/uk/me/parabola/mkgmap/reader/osm/SeaGenerator.java
=====================================
@@ -70,6 +70,7 @@ public class SeaGenerator implements OsmReadingHooks {
private double fbRatio = 0.5d;
private int fbThreshold = 20;
private boolean fbDebug;
+ private boolean checkCoastline = false;
private ElementSaver saver;
@@ -187,6 +188,8 @@ public class SeaGenerator implements OsmReadingHooks {
fbThreshold = (int) Double.parseDouble(option.substring("fbthres=".length()));
} else if ("fbdebug".equals(option)) {
fbDebug = true;
+ } else if ("check".equals(option)) {
+ checkCoastline = true;
} else {
printOptionHelpMsg(forPrecompSea, option);
}
@@ -286,6 +289,7 @@ public class SeaGenerator implements OsmReadingHooks {
System.err.println(" land-tag=TAG=VAL tag to use for land polygons (default natural=land)");
if (forPrecompSea)
return;
+
System.err.println(" no-sea-sectors disable use of \"sea sectors\"");
System.err.println(" extend-sea-sectors extend coastline to reach border");
System.err.println(" close-gaps=NUM close gaps in coastline that are less than this distance (metres)");
@@ -293,8 +297,9 @@ public class SeaGenerator implements OsmReadingHooks {
System.err.println(" fbgap=NUM points closer to the coastline are ignored for flood blocking (default 40)");
System.err.println(" fbthres=NUM min points contained in a polygon to be flood blocked (default 20)");
System.err.println(" fbratio=NUM min ratio (points/area size) for flood blocking (default 0.5)");
+ System.err.println(" check check for sea polygons within sea and land within land");
}
-
+
/**
* Read the index from stream and populate the index grid.
* @param fileStream already opened stream
@@ -586,7 +591,7 @@ public class SeaGenerator implements OsmReadingHooks {
List<Way> seaWays = new ArrayList<>();
// get the index with assignment key => sea/land/tilename
- distinctTilesOnly = loadLandAndSee(landWays, seaWays);
+ distinctTilesOnly = loadLandAndSea(landWays, seaWays);
if (generateSeaUsingMP || distinctTilesOnly) {
// when using multipolygons use the data directly from the precomp files
@@ -602,9 +607,9 @@ public class SeaGenerator implements OsmReadingHooks {
}
// check if the land tags need to be changed
- boolean changeLadTag = landTag != null && ("natural".equals(landTag[0]) && !"land".equals(landTag[1]));
+ boolean changeLandTag = landTag != null && ("natural".equals(landTag[0]) && !"land".equals(landTag[1]));
for (Way w : landWays) {
- if (changeLadTag) {
+ if (changeLandTag) {
w.deleteTag("natural");
w.addTag(landTag[0], landTag[1]);
}
@@ -613,7 +618,7 @@ public class SeaGenerator implements OsmReadingHooks {
}
- private boolean loadLandAndSee(List<Way> landWays, List<Way> seaWays) {
+ private boolean loadLandAndSea(List<Way> landWays, List<Way> seaWays) {
boolean distinctTilesOnly = true;
List<java.awt.geom.Area> seaOnlyAreas = new ArrayList<>();
List<java.awt.geom.Area> landOnlyAreas = new ArrayList<>();
@@ -760,7 +765,7 @@ public class SeaGenerator implements OsmReadingHooks {
} else if (w.getPoints().size() > 1){
beginMap.put(w.getFirstPoint(), w);
} else {
- log.info("Discarding coastline way", w.getId(), "because it consists of less than 2 points");
+ log.info("Discarding coastline", w.getBasicLogInformation(), "because it consists of less than 2 points");
}
}
segments.clear();
@@ -785,7 +790,7 @@ public class SeaGenerator implements OsmReadingHooks {
// merge the ways and maintain maps and list
private static void merge(Map<Coord, Way> beginMap, List<Way> joined, Way w1, Way w2) {
- log.info("merging: ", beginMap.size(), w1.getId(), w2.getId());
+ log.info("merging:", beginMap.size(), w1.getBasicLogInformation(), "with", w2.getBasicLogInformation());
Way wm;
if (FakeIdGenerator.isFakeId(w1.getId())) {
wm = w1;
@@ -831,7 +836,7 @@ public class SeaGenerator implements OsmReadingHooks {
}
// clip all shoreline segments
- clipShorlineSegments();
+ clipShorelineSegments();
if(shoreline.isEmpty()) {
// No sea required
@@ -877,18 +882,18 @@ public class SeaGenerator implements OsmReadingHooks {
createLandPolygons(hitMap);
processIslands(seaRelation);
- processAntiIslands(true);
+ checkIslands(true);
Way sea = createSeaWay(true);
- log.info("sea: ", sea);
+ log.info("sea:", sea);
saver.addWay(sea);
if(seaRelation != null)
seaRelation.addElement("outer", sea);
} else {
// background is land
createSeaPolygons(hitMap);
- processAntiIslands(false);
+ checkIslands(false);
// generate a land polygon so that the tile's
// background colour will match the land colour on the
@@ -931,26 +936,63 @@ public class SeaGenerator implements OsmReadingHooks {
}
/**
- * These are bits of sea have been generated as polygons.
- * if the tile is also sea based, then check that surrounded by an island
- * @param seaRelation if set, add as inner
+ * Check whether land is enclosed in land or sea within sea.
* @param seaBased true if the tile is also sea with land [multi-]polygons
*/
- private void processAntiIslands(boolean seaBased) {
+ private void checkIslands(boolean seaBased) {
+ if (!checkCoastline)
+ return;
+
for (Way ai : antiIslands) {
- if (seaBased) {
- boolean containedByLand = false;
- for (Way i : islands) {
- if (i.containsPointsOf(ai)) {
- containedByLand = true;
- break;
- }
+ Way containingLand = null;
+ Way containingSea = null;
+ for (Way i : islands) {
+ if (i.containsPointsOf(ai) && ((containingLand == null) || (containingLand.containsPointsOf(i))))
+ containingLand = i;
+ }
+ for (Way ai2 : antiIslands) {
+ if ((ai2 != ai) && ai2.containsPointsOf(ai) && ((containingSea == null) || containingSea.containsPointsOf(ai2)))
+ containingSea = ai2;
+ }
+ if ((containingSea != null) && (containingLand != null)) {
+ if (containingSea.containsPointsOf(containingLand))
+ containingSea = null;
+ else if (containingLand.containsPointsOf(containingSea))
+ containingLand = null;
+ else {
+ log.warn("inner sea", ai, "is surrounded by both water", containingSea, "and land", containingLand);
+ containingSea = null;
+ containingLand = null;
}
- if (!containedByLand) {
- // found an anti-island that is not contained by land
- log.warn("inner sea", ai , "is surrounded by water");
+ }
+ if ((containingLand == null) && (seaBased || (containingSea != null)))
+ log.error("inner sea", ai, "is surrounded by water", containingSea == null ? "" : containingSea);
+ }
+
+ for (Way i : islands) {
+ Way containingLand = null;
+ Way containingSea = null;
+ for (Way ai : antiIslands) {
+ if (ai.containsPointsOf(i) && ((containingSea == null) || containingSea.containsPointsOf(ai)))
+ containingSea = ai;
+ }
+ for (Way i2 : islands) {
+ if ((i2 != i) && i2.containsPointsOf(i) && ((containingLand == null) || (containingLand.containsPointsOf(i2))))
+ containingLand = i2;
+ }
+ if ((containingSea != null) && (containingLand != null)) {
+ if (containingSea.containsPointsOf(containingLand))
+ containingSea = null;
+ else if (containingLand.containsPointsOf(containingSea))
+ containingLand = null;
+ else {
+ log.warn("island", i, "is surrounded by both water", containingSea, "and land", containingLand);
+ containingSea = null;
+ containingLand = null;
}
}
+ if ((containingSea == null) && (containingLand != null))
+ log.error("island", i, "is surrounded by land", containingLand);
}
}
@@ -988,7 +1030,7 @@ public class SeaGenerator implements OsmReadingHooks {
/**
* Clip the shoreline ways to the bounding box of the map.
*/
- private void clipShorlineSegments() {
+ private void clipShorelineSegments() {
List<Way> toBeRemoved = new ArrayList<>();
List<Way> toBeAdded = new ArrayList<>();
for (Way segment : shoreline) {
@@ -1110,7 +1152,7 @@ public class SeaGenerator implements OsmReadingHooks {
if (Way.clockwise(w.getPoints()))
addAsSea(w);
else
- addAsLand(w);
+ addAsLand(w);
}
private void addAsSea(Way w) {
@@ -1136,9 +1178,10 @@ public class SeaGenerator implements OsmReadingHooks {
private void createLandPolygons(NavigableMap<Double, Way> hitMap) {
NavigableSet<Double> hits = hitMap.navigableKeySet();
while (!hits.isEmpty()) {
- Way w = new Way(FakeIdGenerator.makeFakeId());
Double hFirst = hits.first();
Double hStart = hFirst, hEnd;
+ Way w = new Way(hitMap.get(hFirst).getOriginalId());
+ w.markAsGeneratedFrom(hitMap.get(hFirst));
boolean finished = false;
do {
Way segment = hitMap.get(hStart);
@@ -1174,9 +1217,10 @@ public class SeaGenerator implements OsmReadingHooks {
private void createSeaPolygons(NavigableMap<Double, Way> hitMap) {
NavigableSet<Double> hits = hitMap.navigableKeySet();
while (!hits.isEmpty()) {
- Way w = new Way(FakeIdGenerator.makeFakeId());
Double hFirst = hits.last();
Double hStart = hFirst, hEnd;
+ Way w = new Way(hitMap.get(hFirst).getOriginalId());
+ w.markAsGeneratedFrom(hitMap.get(hFirst));
boolean finished = false;
do {
Way segment = hitMap.get(hStart);
@@ -1245,7 +1289,7 @@ public class SeaGenerator implements OsmReadingHooks {
Double hEnd = getEdgeHit(tileBounds, pEnd);
if (hStart != null && hEnd != null) {
// nice case: both ends touch the boundary
- log.debug("hits: ", hStart, hEnd);
+ log.debug("hits:", hStart, hEnd);
hitMap.put(hStart, w);
hitMap.put(hEnd, null); // put this for verifyHits which then deletes it
} else {
@@ -1268,7 +1312,8 @@ public class SeaGenerator implements OsmReadingHooks {
*/
List<Coord> points = w.getPoints();
if (allowSeaSectors) {
- Way seaOrLand = new Way(FakeIdGenerator.makeFakeId());
+ Way seaOrLand = new Way(w.getOriginalId());
+ seaOrLand.markAsGeneratedFrom(w);
seaOrLand.getPoints().addAll(points);
int startLat = pStart.getHighPrecLat();
int startLon = pStart.getHighPrecLon();
@@ -1291,7 +1336,7 @@ public class SeaGenerator implements OsmReadingHooks {
}
seaOrLand.addPoint(Coord.makeHighPrecCoord(cornerLat, cornerLon));
seaOrLand.addPoint(pStart);
- log.info("seaSector: ", generateSeaBackground, startLatIsCorner, Way.clockwise(seaOrLand.getPoints()), seaOrLand);
+ log.info("seaSector:", generateSeaBackground, startLatIsCorner, Way.clockwise(seaOrLand.getPoints()), seaOrLand.getBasicLogInformation());
} else if (extendSeaSectors) {
// join to nearest tile border
if (null == hStart) {
@@ -1302,7 +1347,7 @@ public class SeaGenerator implements OsmReadingHooks {
hEnd = getNextEdgeHit(tileBounds, pEnd);
w.getPoints().add(getPoint(tileBounds, hEnd));
}
- log.debug("hits (second try): ", hStart, hEnd);
+ log.debug("hits (second try):", hStart, hEnd);
hitMap.put(hStart, w);
hitMap.put(hEnd, null); // put this for verifyHits which then deletes it
} else {
@@ -1328,6 +1373,7 @@ public class SeaGenerator implements OsmReadingHooks {
NavigableSet<Double> hits = hitMap.navigableKeySet();
Iterator<Double> iter = hits.iterator();
int lastStatus = 0, thisStatus;
+ Double lastHit = 0.0;
while (iter.hasNext()) {
Double aHit = iter.next();
Way segment = hitMap.get(aHit);
@@ -1339,14 +1385,15 @@ public class SeaGenerator implements OsmReadingHooks {
thisStatus = +1;
}
if (thisStatus == lastStatus)
- log.error("Adjacent coastlines hit tile edge in same direction", aHit, segment);
+ log.error("Adjacent coastlines hit tile edge in same direction at", getPoint(tileBounds, lastHit).toDegreeString(), "and", getPoint(tileBounds, aHit).toDegreeString(), segment);
lastStatus = thisStatus;
+ lastHit = aHit;
}
}
// create the point where the shoreline hits the sea bounds
private static Coord getPoint(Area a, double edgePos) {
- log.info("getPoint: ", a, edgePos);
+ log.info("getPoint:", a, edgePos);
int aMinLongHP = a.getMinLong() << Coord.DELTA_SHIFT;
int aMaxLongHP = a.getMaxLong() << Coord.DELTA_SHIFT;
int aMinLatHP = a.getMinLat() << Coord.DELTA_SHIFT;
View it on GitLab: https://salsa.debian.org/debian-gis-team/mkgmap/-/commit/23e99217bab1ad85bbf9c2de7efa1c2baf8320d1
--
View it on GitLab: https://salsa.debian.org/debian-gis-team/mkgmap/-/commit/23e99217bab1ad85bbf9c2de7efa1c2baf8320d1
You're receiving this email because of your account on salsa.debian.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-grass-devel/attachments/20210301/230b0dfb/attachment-0001.htm>
More information about the Pkg-grass-devel
mailing list