> I've been using the style-functions branch over the last ~5 weeks
> without any probs, could it be merged into trunk?
>
Hi Felix,
there are a some things missing (optimizer integration, some coding
style changes) that I want to implement before merging back.
WanMil
I've been using the style-functions branch over the last ~5 weeks
without any probs, could it be merged into trunk?
--
keep on biking and discovering new trails
Felix
openmtbmap.org & www.velomap.org
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgma
Hi, I am also doing this. In addition, there is an undocumented tag
"dest_ref" (sometimes "destination_ref") used to contain the ref of the
road that the exit leads to. I override the "ref" of the ramp with
"dest_ref" as the ref of the ramp is usually either the exit number or the
ref of the motorw
Am 05.10.2012 11:07, schrieb Torsten Leistikow:
>> For all _link ways which have a destination-Tag copy the
>> tag to the following non-link way (motorway or trunk).
>
> I think, a better solution would be the splitting of the concerned link ways
> in
> two parts. The first part could get the ty
In Germany most roads with construction=minor have maxspeed=..
set.
In this case the default mkgmap rule:
# Lower the road speed of ways under some construction.
highway=* & construction=* { add mkgmap:road-speed = '-1' }
is acting to strong.
So I suggest:
# Lower the road speed of ways under
Moin,
Chris66 schrieb am 05.10.2012 10:22:
> When using the Garmin Types 0x08 and 0x09 (Ramp), Garmin is
> evaluating the first way behind all the _link ways.
...
> So the idea is a new mkgmap option --process-destination
> which does following pre-processing:
>
> For all _link ways which have a
Hi,
I added following lines to my style file in order to display the
"destination"-Tag on motorway-junctions:
--
# Set the routing direction
(highway=motorway|highway=motorway_link) & destination=* { add
display_name = '${ref} (${destination})' }
(highway=trunk|highway=trunk_link) &
