Re: [mkgmap-dev] Why is there a code-page in the .typ-file? And - is there a code-page a gmapsupp.img?
On 30.06.2014 23:00, Steve Ratcliffe wrote: Hi Felix 1. Switching to unicode I ask myself If I should also change the typ-file to code-page=65001 I don't think you need to unless you want you labels to be in more than one character set eg Greek and Cyrilic. Well I'm not sure. The Garmin Winter activity map (only unicode map I know that's free) only has latin1 characters in the .typ-file (languages French, English, German) - yet they use Unicode for it. But I don't know if this is any sort of requirement. 2. I couldn't notice any change on compiling a gmapsupp.img regarding a code-page set. Is there actually a code-page for a gmapsupp.img? Especially regarding address index. Or is the code-page only for the map.img files themselves? There is not a separate code-page for the gmapsupp - it is just a container for other files. There is a code page for the individual .img files and also for the global address index (MDR) and the sort order file (SRT). okay thanks a lot for the clarification... So for the case that you have a mapset/gmapsupp that contains both unicode and another code .img files - I'm pretty sure this is fine as long as the MDR and SRT are in unicode... ..Steve -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Unicode maps showing locked or not found on GPS units
On 30.06.2014 22:42, Steve Ratcliffe wrote: Hi even German Umlauts (ÖÄÜ or "french" accents like é) are not displayed correctly anymore (instead split into two funky looking characters). Therefore for old units --latin1 is still the better option for old devices for most european countries. Garmin Vista HCx - FID=6365 I would be suprised if older units that do not contain more than one character set support unicode. From your description it sounds as if the unicode characters are just being displayed as latin1. If you have: ä é á instead of ä é á that would be it. That*s the case. Also for address search it therefore gets problematic to find addresses using any of theese "special" characters.. As long as you use 1252 they display fine, if one switches to Unicode they show up as above "scrambled" like above... ..Steve -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Unicode maps showing locked or not found on GPS units
On 30.06.2014 13:35, Andrzej Popowski wrote: Hi, Garmin is changing something in their map locking system. I think this is connected with Unicode maps. Please check if original Garmin maps work with these device, for example Winter Activity Map: http://www.garmin.com/uk/maps/onthetrail#apps And please report any problem to Garmin support. No problem for the free winter activity map. It loads on Edge 1000 So only mkgmap created Unicode maps are showing up as locked... I'll still report back if the maps using .typ-file also in unicode work - but yes I doubt that this small change will make them work. -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Unicode maps showing locked or not found on GPS units
Hi Steve, thanks a lot. I think this should be committed... Unicode and latin1 will be the most used code-pages. And except the locking and creating of gmapsupp.img - mkgmap produced unicode maps work fine. On 30.06.2014 22:45, Steve Ratcliffe wrote: On 30/06/14 11:30, Felix Hartmann wrote: BTW 2. -- It would be great if there is a short-code like --latin1 for unicode too! E.g. --unicode instead of --code-page=65001, just for simplicity... Patch attached. ..Steve -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r3312: Add --unicode option as abbreviation for --code-page=65001.
Version mkgmap-r3312 was committed by steve on Tue, 01 Jul 2014 Add --unicode option as abbreviation for --code-page=65001. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Unicode maps showing locked or not found on GPS units
Having the .typ-file changed by gmaptool to unicode doesn't change anything for map authentication So - the error is not related to the .typ-file as expected... On 01.07.2014 09:14, Felix Hartmann wrote: On 30.06.2014 13:35, Andrzej Popowski wrote: Hi, Garmin is changing something in their map locking system. I think this is connected with Unicode maps. Please check if original Garmin maps work with these device, for example Winter Activity Map: http://www.garmin.com/uk/maps/onthetrail#apps And please report any problem to Garmin support. No problem for the free winter activity map. It loads on Edge 1000 So only mkgmap created Unicode maps are showing up as locked... I'll still report back if the maps using .typ-file also in unicode work - but yes I doubt that this small change will make them work. -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address boundary rules for South Africa
Hey guys, Just wondering if somebody can commit this so that other people can benefit from having the address search setup correctly in South Africa. Thanks, Ben On Tue, Jun 24, 2014 at 2:39 PM, Ben Konrath wrote: > Hi, > > Here's a patch to add address boundary rules for South Africa. > > Thanks, Ben > ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r3313: Add address boundary rules for South Africa.
Version mkgmap-r3313 was committed by steve on Tue, 01 Jul 2014 Add address boundary rules for South Africa. -Ben Konrath ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Address boundary rules for South Africa
On 01/07/14 17:11, Ben Konrath wrote: Just wondering if somebody can commit this so that other people can benefit from having the address search setup correctly in South Africa. OK done. Thanks for the patch. ..Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Why is there a code-page in the .typ-file? And - is there a code-page a gmapsupp.img?
Hi Felix Code Pages & TYP files Unicode only affects text associated with an element - in fact Garmin has 'recently' extended the languages to &2e (Irish) . I'm not sure if Steve has allowed for this in the TYP compiler. r Nick -- View this message in context: http://gis.19327.n5.nabble.com/Why-is-there-a-code-page-in-the-typ-file-And-is-there-a-code-page-a-gmapsupp-img-tp5809880p5810027.html Sent from the Mkgmap Development mailing list archive at Nabble.com. ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Curvy routing support: new function?
Hi all,
Garmin offers "curvy roads" preferences for their zümo 390 and 590 devices.
https://buy.garmin.com/en-US/US/on-the-road/motorcycles/zumo-390lm/prod138275.html
I'm thinking about creating motorcycle maps for old 200 series.
Might it be useful to integrate a curviness() function so that mkgmap can
optimize for curvy roads too? It might also help do determine a better default
speed for curvy roads for use with car routing.
The curviness() value might be the overall absolute turning angle (in degrees)
of a road segment divided by the segment's length.
What's your opinion?
Cheers
Manfred
Pseudo code might look like this:
function curviness()
{
oldpoint=points(0)
foreach (point of a way segment as newpoint)
{
d_x=(newpoint.x-oldpoint.x)/360*4000*COS(newpoint.x*PI()/180) //in meters
d_y=(newpoint.y-oldpoint.y)/360*4000 //in meters
length+=sqrt(d_x**2+d_y**2)
angle=arctan(d_y/d_x)
d_angle=abs(angle-old_angle)
sgn_x=sgn(d_x)
sgn_y=sgn(d_y)
if ((sgn_x*sgn_y*old_sgn_x*old_sgn_y)=-1 && (sgn_x!=old_sgn_x))
d_angle=pi-d_angle // 180 degrees correction, otherwise north-south roads show
strange results
if (point>1) sum_angle+=d_angle
old_angle=angle
oldpoint=newpoint
old_sgn_x=sgn_x
old_sgn_y=sgn_y
}
return sum_angle/length
}
// perhaps simple multiplication is faster than 4 times sgn() functions?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Routing speeds on Oregon 600/400
Chapter 4.6.5 of the style manual shwos a table with road speeds and its corresponding "highest speeds". I created a small test map with roads of ca. 100 km length of all 5 road_types and added speed limits which translate into the 8 different road_speed codes with the current (v3310) default style. Following table shows my car navigation results on an Oregon 600 with current firmware (3.90): Roadspeed DistanceTimeSpeed Simulationspeed 7 99,900:53:27112,14 254 6 99,700:56:41105,53 130 5 100 01:00 100,00 100 4 99,501:16 78,55 90 3 100 01:34 63,83 70 2 99,902:03 48,73 50 1 99,603:06 32,13 30 0 100 06:09 16,26 16 The "Speed" is calculated by dividing the distance to destination by the time to destination; the "Simulationspeed" is the speed shown on the device when you select the simulation option. The speeds do not depend on the road_type value. The speeds for classes 0, 1, 2, 3, and 7 are multiples of 10mph. When using a different routing type (e.g. pedestrian), the simulation speed did not change (i.e. a pedestrian "walking" at 50 km/h...), but the calculated time to destination changed (i.e. a pedestrian was doing ca 5 km/h, a cyclist ca. 25 km/h). With an Oregon 400 with old firmware (4.20), values are slightly different: Roadspeed DistanceTimeSpeed Simulationspeed 7 99,900:45:20132,22 129 6 99,700:51:51115,37 113 5 100 00:56 105,63 103 4 99,501:07 89,10 87 3 100 01:32 65,22 64 2 99,902:03 48,73 48 1 99,503:06 32,10 32 0 100 10:16 9,749 The main difference is in faster speed for higher road_speed types, but lower simulation speed. This means that Garmin uses different speeds for calculating the time to destination between different device types! I hope this information helps the creators of maps, and helps to clarify questions on why this route was taken instead of that... ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Curvy routing support: new function?
Hi,
I remember that it is on my Todo-List :-)
So I performed a quick implementation following your suggestion. You can
find in the attached patch so that you can play a little bit with it.
(Attention: it is completely untested!!)
You can find a patched mkgmap.jar at http://files.mkgmap.org.uk/detail/215.
I think curviness should to be defined in a different way.
1. Calculate the distance of each point Dmiddle to the virtual line from
first to the last point.
2. curviness()=standard mean(Dmiddle/(length to next point + length to
previous point)
I think this gives a better indication how curviness a road is. But it
need to be implemented and tested later on :-)
WanMil
Hi all,
Garmin offers "curvy roads" preferences for their zümo 390 and 590 devices.
https://buy.garmin.com/en-US/US/on-the-road/motorcycles/zumo-390lm/prod138275.html
I'm thinking about creating motorcycle maps for old 200 series.
Might it be useful to integrate a curviness() function so that mkgmap can
optimize for curvy roads too? It might also help do determine a better default
speed for curvy roads for use with car routing.
The curviness() value might be the overall absolute turning angle (in degrees)
of a road segment divided by the segment's length.
What's your opinion?
Cheers
Manfred
Pseudo code might look like this:
function curviness()
{
oldpoint=points(0)
foreach (point of a way segment as newpoint)
{
d_x=(newpoint.x-oldpoint.x)/360*4000*COS(newpoint.x*PI()/180) //in meters
d_y=(newpoint.y-oldpoint.y)/360*4000 //in meters
length+=sqrt(d_x**2+d_y**2)
angle=arctan(d_y/d_x)
d_angle=abs(angle-old_angle)
sgn_x=sgn(d_x)
sgn_y=sgn(d_y)
if ((sgn_x*sgn_y*old_sgn_x*old_sgn_y)=-1 && (sgn_x!=old_sgn_x))
d_angle=pi-d_angle // 180 degrees correction, otherwise north-south roads show strange
results
if (point>1) sum_angle+=d_angle
old_angle=angle
oldpoint=newpoint
old_sgn_x=sgn_x
old_sgn_y=sgn_y
}
return sum_angle/length
}
// perhaps simple multiplication is faster than 4 times sgn() functions?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Index: src/uk/me/parabola/mkgmap/osmstyle/function/FunctionFactory.java
===
--- src/uk/me/parabola/mkgmap/osmstyle/function/FunctionFactory.java (revision 3313)
+++ src/uk/me/parabola/mkgmap/osmstyle/function/FunctionFactory.java (working copy)
@@ -28,27 +28,40 @@
* @return the style function instance or {@code null} if there is no such function
*/
public static StyleFunction createFunction(String name) {
- if ("length".equals(name))
+ if (name == null) {
+ return null;
+ }
+
+ switch (name) {
+ case "length":
return new LengthFunction();
- //} else if ("get_tag".equals(name))
- // return new GetTagFunction(tag);
- if ("is_closed".equals(name)) {
+ case "curviness":
+ return new CurvinessFunction();
+
+ case "is_closed":
return new IsClosedFunction();
- }
- if ("is_complete".equals(name)) {
+
+ case "is_complete":
return new IsCompleteFunction();
- }
- if ("area_size".equals(name))
+ case "area_size":
return new AreaSizeFunction();
- if ("maxspeedkmh".equals(name))
+
+ case "maxspeedkmh":
return new MaxSpeedFunction(SpeedUnit.KMH);
- if ("maxspeedmph".equals(name))
+ case "maxspeedmph":
return new MaxSpeedFunction(SpeedUnit.MPH);
- if ("type".equals(name))
+
+ case "type":
return new TypeFunction();
- if ("osmid".equals(name))
+ case "osmid":
return new OsmIdFunction();
+
+ default:
+ // function is not known
+ return null;
+ }
- return null;
+
+
}
}
Index: src/uk/me/parabola/mkgmap/osmstyle/function/CurvinessFunction.java
===
--- src/uk/me/parabola/mkgmap/osmstyle/function/CurvinessFunction.java (revision 0)
+++ src/uk/me/parabola/mkgmap/osmstyle/function/CurvinessFunction.java (revision 0)
@@ -0,0 +1,67 @@
+package uk.me.parabola.mkgmap.osmstyle.function;
+
+import java.text.DecimalFormat;
+import java.text.DecimalFormatSymbols;
+import java.util.Locale;
+
+import uk.me.parabola.imgfmt.Utils;
+import uk.me.parabola.imgfmt.app.Coord;
+import uk.me.parabola.log.Logger;
+import uk.me.parabola.mkgmap.reader.osm.Element;
+import uk.me.parabola.mkgmap.reader.osm.Way;
+
+public class CurvinessFunction extends CachedFunction {
+ private static final Logger log = Logger.getLogger(LengthFunction.class);
+
+ private final DecimalFormat nf = new DecimalFormat("0.0#", DecimalFormatSymbols.getInstance(Locale.US));
+
+ private final LengthFunction length;
+
+ public CurvinessFunction() {
+ super(null);
+ this.length = new LengthFunction();
+ }
+
+ protected String calcImpl(Element el) {
+ if (el instanceof Way) {
+ Way w = (Way)el;
+ String lengthStr = length.value(w);
+ if (len
Re: [mkgmap-dev] Curvy routing support: new function?
One correction:
in 2. I ment standard deviation instead of standard mean.
WanMil
Hi,
I remember that it is on my Todo-List :-)
So I performed a quick implementation following your suggestion. You can
find in the attached patch so that you can play a little bit with it.
(Attention: it is completely untested!!)
You can find a patched mkgmap.jar at http://files.mkgmap.org.uk/detail/215.
I think curviness should to be defined in a different way.
1. Calculate the distance of each point Dmiddle to the virtual line from
first to the last point.
2. curviness()=standard mean(Dmiddle/(length to next point + length to
previous point)
I think this gives a better indication how curviness a road is. But it
need to be implemented and tested later on :-)
WanMil
Hi all,
Garmin offers "curvy roads" preferences for their zümo 390 and 590
devices.
https://buy.garmin.com/en-US/US/on-the-road/motorcycles/zumo-390lm/prod138275.html
I'm thinking about creating motorcycle maps for old 200 series.
Might it be useful to integrate a curviness() function so that mkgmap
can optimize for curvy roads too? It might also help do determine a
better default speed for curvy roads for use with car routing.
The curviness() value might be the overall absolute turning angle (in
degrees) of a road segment divided by the segment's length.
What's your opinion?
Cheers
Manfred
Pseudo code might look like this:
function curviness()
{
oldpoint=points(0)
foreach (point of a way segment as newpoint)
{
d_x=(newpoint.x-oldpoint.x)/360*4000*COS(newpoint.x*PI()/180)
//in meters
d_y=(newpoint.y-oldpoint.y)/360*4000 //in meters
length+=sqrt(d_x**2+d_y**2)
angle=arctan(d_y/d_x)
d_angle=abs(angle-old_angle)
sgn_x=sgn(d_x)
sgn_y=sgn(d_y)
if ((sgn_x*sgn_y*old_sgn_x*old_sgn_y)=-1 && (sgn_x!=old_sgn_x))
d_angle=pi-d_angle // 180 degrees correction, otherwise north-south
roads show strange results
if (point>1) sum_angle+=d_angle
old_angle=angle
oldpoint=newpoint
old_sgn_x=sgn_x
old_sgn_y=sgn_y
}
return sum_angle/length
}
// perhaps simple multiplication is faster than 4 times sgn() functions?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Curvy routing support: new function?
Hi WanMil,
you are very fast, thank you very much for this!
However I'm facing some expectations, log:
java.lang.NoSuchMethodError: uk.me.parabola.mkgmap.reader.osm.Way.deleteTag(Ljav
a/lang/String;)V
at uk.me.parabola.mkgmap.reader.osm.MultiPolygonFinishHook.end(MultiPoly
gonFinishHook.java:50)
at uk.me.parabola.mkgmap.reader.osm.OsmReadingHooksChain.end(OsmReadingH
ooksChain.java:79)
at uk.me.parabola.mkgmap.reader.osm.o5m.O5mBinMapDataSource.load(O5mBinM
apDataSource.java:49)
at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSour
ce.java:127)
at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:167)
at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:63)
at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:253)
at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:249)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
(I have installed r3310 which works ok, and then replaced mkgmap.jar by your
build)
I'm open to any suggestions for other logic. A curviness function can only be a
virtual value, not physical. However it may probably sufficient to say,
curviness=length()/distance(first_point, last_point)? May be I'm thinking too
complex :-)
Cheers
Manfred
> Gesendet: Dienstag, 01. Juli 2014 um 22:32 Uhr
> Von: WanMil
> An: "Development list for mkgmap"
> Betreff: Re: [mkgmap-dev] Curvy routing support: new function?
>
> Hi,
>
> I remember that it is on my Todo-List :-)
>
> So I performed a quick implementation following your suggestion. You can
> find in the attached patch so that you can play a little bit with it.
> (Attention: it is completely untested!!)
> You can find a patched mkgmap.jar at http://files.mkgmap.org.uk/detail/215.
>
> I think curviness should to be defined in a different way.
> 1. Calculate the distance of each point Dmiddle to the virtual line from
> first to the last point.
> 2. curviness()=standard mean(Dmiddle/(length to next point + length to
> previous point)
>
> I think this gives a better indication how curviness a road is. But it
> need to be implemented and tested later on :-)
>
> WanMil
>
> > Hi all,
> >
> > Garmin offers "curvy roads" preferences for their zümo 390 and 590 devices.
> > https://buy.garmin.com/en-US/US/on-the-road/motorcycles/zumo-390lm/prod138275.html
> > I'm thinking about creating motorcycle maps for old 200 series.
> > Might it be useful to integrate a curviness() function so that mkgmap can
> > optimize for curvy roads too? It might also help do determine a better
> > default speed for curvy roads for use with car routing.
> >
> > The curviness() value might be the overall absolute turning angle (in
> > degrees) of a road segment divided by the segment's length.
> >
> > What's your opinion?
> >
> > Cheers
> > Manfred
> >
> >
> >
> >
> > Pseudo code might look like this:
> >
> > function curviness()
> > {
> > oldpoint=points(0)
> > foreach (point of a way segment as newpoint)
> >{
> >d_x=(newpoint.x-oldpoint.x)/360*4000*COS(newpoint.x*PI()/180) //in
> > meters
> >d_y=(newpoint.y-oldpoint.y)/360*4000 //in meters
> >length+=sqrt(d_x**2+d_y**2)
> >angle=arctan(d_y/d_x)
> >d_angle=abs(angle-old_angle)
> >sgn_x=sgn(d_x)
> >sgn_y=sgn(d_y)
> >if ((sgn_x*sgn_y*old_sgn_x*old_sgn_y)=-1 && (sgn_x!=old_sgn_x))
> > d_angle=pi-d_angle // 180 degrees correction, otherwise north-south roads
> > show strange results
> >if (point>1) sum_angle+=d_angle
> >old_angle=angle
> >oldpoint=newpoint
> >old_sgn_x=sgn_x
> >old_sgn_y=sgn_y
> >}
> > return sum_angle/length
> > }
> >
> > // perhaps simple multiplication is faster than 4 times sgn() functions?
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> >
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Curvy routing support: new function?
Well I have thought about this too - also new Basecamp has a curvy roads preference - but what should mkgmap do about it? You can calculate if a road is curvy or not, but what then? The only thing you can do until mkgmap knows NT format maps which I think has a special "tag" for this, is to increase the road-class. Increasing the road-speed would be against your intentions - as the higher the road-speed - the more garmin algo will punish you for curvy roads... So until we know how Garmin maps tell Basecamp/the GPS Unit to exclude a road from curvyness punishment - the only thing you can do is to increase the road-class... I'm 100% sure the prefer curvy roads switch, works like avoidance - looking for the curvy road indicator inside the map. There is absolutely no change in routing in Basecamp if I set it or not with non NT maps... On 01.07.2014 22:02, Manfred Brenneisen wrote: Hi all, Garmin offers "curvy roads" preferences for their zümo 390 and 590 devices. -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
