Clinton Gladstone wrote:
The attached patch is an attempt to improve the reliability and
flexibility for displaying highway shields. It does the following:
1. Removes the alpha balancing coding. (This coding checked that
values for signs were primarily numeric, and therefore prevented refs
such as "QEW" from being displayed as highway shields.)
2. Removes ALL spaces from refs, so that the complete ref will be
displayed in the shield. (Previously only the first space was removed,
which caused refs like "B 1 2" to be displayed as "B1" in the shield.)
3. Checks, after spaces have been removed, if the ref is too long to
be displayed in a shield. If the ref is too long, the shield code will
not be added; the road label will displayed normally. The maximum
length of the ref is determined in the following manner:
3.1. The default of 8 characters is used. This is the previous behaviour.
3.2. If a colon character (":") followed by a number is appended to
the highway symbol in the style file, that number will override the
maximum length. Example: "highway-symbol:box:6" sets the maximum to 6
characters.
3.3. If an additional colon character followed by a number is appended
to the highway symbol, this second number will be used as the maximum
length for alpha only refs. Example: "highway-symbol:box:6:4" sets the
maximum to 6 for numeric and alphanumeric refs, but 4 for alpha only
refs.
I use the following in my style file:
'${ref|highway-symbol:box:6:4}'
This sets the maximum length of alphanumeric shields to be 6 (e.g.,
M1234a, or 123456), and alpha only shields to be 4 (e.g., ABCD). Such
a setting works well for me in the areas I am interested in. It
prevents labels such as "Südring" from being displayed as shields, but
catches most other refs which can reasonably be displayed in shields.
The approach of this patch allows creative mappers to have a certain
amount of control over shield display, but still preserves the default
behaviour of the
Great - solves many problems (especially the differences between
hbox/box and oval and others...
Have not found any bug.
------------------------------------------------------------------------
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
