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/prod13827... 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*40000000*COS(newpoint.x*PI()/180) //in meters d_y=(newpoint.y-oldpoint.y)/360*40000000 //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?
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/prod13827... 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*40000000*COS(newpoint.x*PI()/180) //in meters d_y=(newpoint.y-oldpoint.y)/360*40000000 //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
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/prod13827...
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*40000000*COS(newpoint.x*PI()/180) //in meters d_y=(newpoint.y-oldpoint.y)/360*40000000 //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
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 <wmgcnfg@web.de> An: "Development list for mkgmap" <mkgmap-dev@lists.mkgmap.org.uk> 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/prod13827... 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*40000000*COS(newpoint.x*PI()/180) //in meters d_y=(newpoint.y-oldpoint.y)/360*40000000 //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
I forgot to clean before build... Here is the new version: http://files.mkgmap.org.uk/detail/216
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 <wmgcnfg@web.de> An: "Development list for mkgmap" <mkgmap-dev@lists.mkgmap.org.uk> 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/prod13827... 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*40000000*COS(newpoint.x*PI()/180) //in meters d_y=(newpoint.y-oldpoint.y)/360*40000000 //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
Hi WanMil, great work! A quick test shows that sometimes negative values for curviness() are appearing. As there is the abs() statement, there should be no negative values Please find the result attached. Almost straight roads show a high curviness value. There must be some bug. Unfortunately I'm lost in finding the right position in the source code, so I rely on you :-) Cheers Manfred
Gesendet: Donnerstag, 03. Juli 2014 um 20:49 Uhr Von: WanMil <wmgcnfg@web.de> An: "Development list for mkgmap" <mkgmap-dev@lists.mkgmap.org.uk> Betreff: Re: [mkgmap-dev] Curvy routing support: new function?
I forgot to clean before build... Here is the new version: http://files.mkgmap.org.uk/detail/216
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 <wmgcnfg@web.de> An: "Development list for mkgmap" <mkgmap-dev@lists.mkgmap.org.uk> 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/prod13827... 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*40000000*COS(newpoint.x*PI()/180) //in meters d_y=(newpoint.y-oldpoint.y)/360*40000000 //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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil, unfortunately the curviness() function does not work as expected yet. I can try to help to analyse it, may I have a look at the source code anywhere? The function alone would be enough Thanks and cheers Manfred PS: please find detailed analysis in my mail from July 3
Gesendet: Donnerstag, 03. Juli 2014 um 20:49 Uhr Von: WanMil <wmgcnfg@web.de> An: "Development list for mkgmap" <mkgmap-dev@lists.mkgmap.org.uk> Betreff: Re: [mkgmap-dev] Curvy routing support: new function?
I forgot to clean before build... Here is the new version: http://files.mkgmap.org.uk/detail/216
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 <wmgcnfg@web.de> An: "Development list for mkgmap" <mkgmap-dev@lists.mkgmap.org.uk> 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/prod13827... 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*40000000*COS(newpoint.x*PI()/180) //in meters d_y=(newpoint.y-oldpoint.y)/360*40000000 //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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Manfred, I do not have time to have a look on it within the next weeks. So please help yourself or wait... Sorry :-) WanMil
Hi WanMil,
unfortunately the curviness() function does not work as expected yet. I can try to help to analyse it, may I have a look at the source code anywhere? The function alone would be enough
Thanks and cheers Manfred
PS: please find detailed analysis in my mail from July 3
Gesendet: Donnerstag, 03. Juli 2014 um 20:49 Uhr Von: WanMil <wmgcnfg@web.de> An: "Development list for mkgmap" <mkgmap-dev@lists.mkgmap.org.uk> Betreff: Re: [mkgmap-dev] Curvy routing support: new function?
I forgot to clean before build... Here is the new version: http://files.mkgmap.org.uk/detail/216
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 <wmgcnfg@web.de> An: "Development list for mkgmap" <mkgmap-dev@lists.mkgmap.org.uk> 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/prod13827... 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*40000000*COS(newpoint.x*PI()/180) //in meters d_y=(newpoint.y-oldpoint.y)/360*40000000 //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
_______________________________________________ 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
Hi WanMil, sorry I did not want to create pressure - it's holiday time :-) Just thought it drowned below noise level If I can help by looking at the source code, please let me know Cheers Manfred
Hi Manfred,
I do not have time to have a look on it within the next weeks. So please help yourself or wait... Sorry :-)
WanMil
Hi WanMil,
unfortunately the curviness() function does not work as expected yet. I can try to help to analyse it, may I have a look at the source code anywhere? The function alone would be enough
Thanks and cheers Manfred
PS: please find detailed analysis in my mail from July 3
Gesendet: Donnerstag, 03. Juli 2014 um 20:49 Uhr Von: WanMil <wmgcnfg@web.de> An: "Development list for mkgmap" <mkgmap-dev@lists.mkgmap.org.uk> Betreff: Re: [mkgmap-dev] Curvy routing support: new function?
I forgot to clean before build... Here is the new version: http://files.mkgmap.org.uk/detail/216
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 <wmgcnfg@web.de> An: "Development list for mkgmap" <mkgmap-dev@lists.mkgmap.org.uk> 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/prod13827... 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*40000000*COS(newpoint.x*PI()/180) //in meters d_y=(newpoint.y-oldpoint.y)/360*40000000 //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
_______________________________________________ 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
Hi Manfred, it seems you did not notice the patch which was attached in WanMils 1st post: http://gis.19327.n5.nabble.com/attachment/5810047/0/curviness_v1.patch Gerd Manfred Brenneisen-2 wrote
Hi WanMil,
sorry I did not want to create pressure - it's holiday time :-) Just thought it drowned below noise level
If I can help by looking at the source code, please let me know
Cheers Manfred
Hi Manfred,
I do not have time to have a look on it within the next weeks. So please help yourself or wait... Sorry :-)
WanMil
Hi WanMil,
unfortunately the curviness() function does not work as expected yet. I can try to help to analyse it, may I have a look at the source code anywhere? The function alone would be enough
Thanks and cheers Manfred
PS: please find detailed analysis in my mail from July 3
Gesendet: Donnerstag, 03. Juli 2014 um 20:49 Uhr Von: WanMil <
wmgcnfg@
>
An: "Development list for mkgmap" <
mkgmap-dev@.org
>
Betreff: Re: [mkgmap-dev] Curvy routing support: new function?
I forgot to clean before build... Here is the new version: http://files.mkgmap.org.uk/detail/216
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 <
wmgcnfg@
>
An: "Development list for mkgmap" <
mkgmap-dev@.org
>
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/prod13827... > 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*40000000*COS(newpoint.x*PI()/180) //in meters > d_y=(newpoint.y-oldpoint.y)/360*40000000 //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@.org
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Curvy-routing-support-new-function-tp5810044p... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Ah, thanks a lot, Gerd. And I think I got it: + for (Coord c3 : w.getPoints()) { + if (c1 != null && c2 != null) { + angle += Utils.getAngle(c1, c2, c3); + } + c1 = c2; + c2 = c3; + } The simple addition of angle values cannot work. It needs a) an absolute abs() value. For curviness in its meaning, it does not matter into which direction (left or right turn) the way bends b) a correction for angles that are almost, or alternating around north-south direction due to the fact that a change from 359 degrees to 2 degrees is not a full 357 degreees turn, but a very slight turn. (or, a correction for east-west roads, depending on where the transition from + to - of the Utils.getAngle() function currently is) For both, after several tests I have found a solution which works well, please see my first mail. But I don't know ow the getAngle function works, where the +- transition is. I think we'll wait till WanMil has more time. I don't want to pull more and more people into that. Cheers Manfred
Hi Manfred,
it seems you did not notice the patch which was attached in WanMils 1st post: http://gis.19327.n5.nabble.com/attachment/5810047/0/curviness_v1.patch
Gerd
Manfred Brenneisen-2 wrote
Hi WanMil,
sorry I did not want to create pressure - it's holiday time :-) Just thought it drowned below noise level
If I can help by looking at the source code, please let me know
Cheers Manfred
Hi Manfred,
I do not have time to have a look on it within the next weeks. So please help yourself or wait... Sorry :-)
WanMil
Hi WanMil,
unfortunately the curviness() function does not work as expected yet. I can try to help to analyse it, may I have a look at the source code anywhere? The function alone would be enough
Thanks and cheers Manfred
PS: please find detailed analysis in my mail from July 3
Gesendet: Donnerstag, 03. Juli 2014 um 20:49 Uhr Von: WanMil <
wmgcnfg@
An: "Development list for mkgmap" <
mkgmap-dev@.org
Betreff: Re: [mkgmap-dev] Curvy routing support: new function?
I forgot to clean before build... Here is the new version: http://files.mkgmap.org.uk/detail/216
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 <
wmgcnfg@
> An: "Development list for mkgmap" <
mkgmap-dev@.org
> 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/prod13827... >> 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*40000000*COS(newpoint.x*PI()/180) //in meters >> d_y=(newpoint.y-oldpoint.y)/360*40000000 //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@.org
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> > > _______________________________________________ > mkgmap-dev mailing list >
mkgmap-dev@.org
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/Curvy-routing-support-new-function-tp5810044p... 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
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
Hi all,
Gesendet: Mittwoch, 02. Juli 2014 um 08:46 Uhr Von: "Felix Hartmann" <extremecarver@gmail.com> An: mkgmap-dev@lists.mkgmap.org.uk Betreff: 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...
I devised myself a day to think about it. To be not too enthusiastic or conservative, as the future will be NT maps as you state correctly. Finally, I think: mkgmap could translate the physical shape of a road into different categories, e.g. by setting mkgmap:road-speed parameters. This is more analog than digital "curvy" or "not curvy" setting by just setting single bits (which are not widespread yet, NT only). One might want to differentiate between this way: http://www.openstreetmap.org/way/186500650 and that way: http://www.openstreetmap.org/way/106597772 Which one is faster? Would you like to add the (highly unwanted!) maxspeed:practical tag to OSM data? Car map designers might want to lower speeds for curvy roads, motorcycle map makers would go the other way (knowing that the calculated travel time is incorrect) Adding style rules like highway=primary & curviness() > 50 {add mkgmap:road-speed-max=5} would not influence the map, only curvy roads are affected. Nobody is forced to use the new function (knowing that it slows down map generation if used). But as it is not a really big thing you might give it a try. I'll test, and report when it works correctly (for me :-)) Cheers Manfred
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
You are missing a big big point here! The higher you put the speed, the bigger the time penalties for sharp turns. So the only thing reasonable to do is ramp up the road_class, and keep or back down the road-speed.. But best give it some tries yourself by creating a sample map where you increase speed for some curvy roads based on name filters. You will likely notice that the result is rather the opposite. Especially if there are crossings... Felix On 03.07.2014 19:49, Manfred Brenneisen wrote:
Hi all,
Gesendet: Mittwoch, 02. Juli 2014 um 08:46 Uhr Von: "Felix Hartmann" <extremecarver@gmail.com> An: mkgmap-dev@lists.mkgmap.org.uk Betreff: 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...
I devised myself a day to think about it. To be not too enthusiastic or conservative, as the future will be NT maps as you state correctly. Finally, I think: mkgmap could translate the physical shape of a road into different categories, e.g. by setting mkgmap:road-speed parameters. This is more analog than digital "curvy" or "not curvy" setting by just setting single bits (which are not widespread yet, NT only). One might want to differentiate between this way: http://www.openstreetmap.org/way/186500650 and that way: http://www.openstreetmap.org/way/106597772 Which one is faster? Would you like to add the (highly unwanted!) maxspeed:practical tag to OSM data? Car map designers might want to lower speeds for curvy roads, motorcycle map makers would go the other way (knowing that the calculated travel time is incorrect) Adding style rules like highway=primary & curviness() > 50 {add mkgmap:road-speed-max=5} would not influence the map, only curvy roads are affected.
Nobody is forced to use the new function (knowing that it slows down map generation if used). But as it is not a really big thing you might give it a try. I'll test, and report when it works correctly (for me :-))
Cheers Manfred
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
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Oh - actually there is one thing that could be done - but I'm not sure if it is possible and even if might lead to big fuckups.. That is - display the road as is, but manipulate the counters so it appears shorter on calculations. Maybe this is possible. I mean there must be a way to make it longer - to account for altitude - so is it possible to shorten the road but display it longer? That would of course give you wrong kilometers and distances on every possible setting... On 03.07.2014 20:32, Felix Hartmann wrote:
You are missing a big big point here!
The higher you put the speed, the bigger the time penalties for sharp turns. So the only thing reasonable to do is ramp up the road_class, and keep or back down the road-speed..
But best give it some tries yourself by creating a sample map where you increase speed for some curvy roads based on name filters. You will likely notice that the result is rather the opposite. Especially if there are crossings...
Felix On 03.07.2014 19:49, Manfred Brenneisen wrote:
Hi all,
Gesendet: Mittwoch, 02. Juli 2014 um 08:46 Uhr Von: "Felix Hartmann" <extremecarver@gmail.com> An: mkgmap-dev@lists.mkgmap.org.uk Betreff: 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...
I devised myself a day to think about it. To be not too enthusiastic or conservative, as the future will be NT maps as you state correctly. Finally, I think: mkgmap could translate the physical shape of a road into different categories, e.g. by setting mkgmap:road-speed parameters. This is more analog than digital "curvy" or "not curvy" setting by just setting single bits (which are not widespread yet, NT only). One might want to differentiate between this way: http://www.openstreetmap.org/way/186500650 and that way: http://www.openstreetmap.org/way/106597772 Which one is faster? Would you like to add the (highly unwanted!) maxspeed:practical tag to OSM data? Car map designers might want to lower speeds for curvy roads, motorcycle map makers would go the other way (knowing that the calculated travel time is incorrect) Adding style rules like highway=primary & curviness() > 50 {add mkgmap:road-speed-max=5} would not influence the map, only curvy roads are affected.
Nobody is forced to use the new function (knowing that it slows down map generation if used). But as it is not a really big thing you might give it a try. I'll test, and report when it works correctly (for me :-))
Cheers Manfred
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
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Felix, as far as I understand the Garmin algo, these penalties only take effect if you turn from one street into another (sharp edge > some deg, Garmin says "turn"). For straightly connected roads or road pieces, this does not appear (AFAIK) In my bicycle maps, therefore I use only road_speeds of 2 or less so that turning penalties show little effect. If used with car routing, curviness should only be used for lowering road_speed, e.g. on curvy roads without speed limit. With motorcycle maps, I'd like to increase road_speed for curvy road. Yes, penalties show more effect then. Then it is a question, how often you make use of the function. Of course curviness should not be used that much so that every light curvy road gets a road_speed of 7. It should be used that only very curvy roads get a bonus, and thus preferred better than with standard settings. As long as the other non-curvy or little-curvy roads get no benefit, the curvy ones will be preferred. It's likely the same with road_class. Only ca. 5% of roads should be road_class 4, so a reduced main routing network exists. Cheers Manfred
Gesendet: Donnerstag, 03. Juli 2014 um 20:39 Uhr Von: "Felix Hartmann" <extremecarver@gmail.com> An: "Development list for mkgmap" <mkgmap-dev@lists.mkgmap.org.uk> Betreff: Re: [mkgmap-dev] Fw: Re: Curvy routing support: new function?
Oh - actually there is one thing that could be done - but I'm not sure if it is possible and even if might lead to big fuckups..
That is - display the road as is, but manipulate the counters so it appears shorter on calculations. Maybe this is possible. I mean there must be a way to make it longer - to account for altitude - so is it possible to shorten the road but display it longer? That would of course give you wrong kilometers and distances on every possible setting... On 03.07.2014 20:32, Felix Hartmann wrote:
You are missing a big big point here!
The higher you put the speed, the bigger the time penalties for sharp turns. So the only thing reasonable to do is ramp up the road_class, and keep or back down the road-speed..
But best give it some tries yourself by creating a sample map where you increase speed for some curvy roads based on name filters. You will likely notice that the result is rather the opposite. Especially if there are crossings...
Felix On 03.07.2014 19:49, Manfred Brenneisen wrote:
Hi all,
Gesendet: Mittwoch, 02. Juli 2014 um 08:46 Uhr Von: "Felix Hartmann" <extremecarver@gmail.com> An: mkgmap-dev@lists.mkgmap.org.uk Betreff: 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...
I devised myself a day to think about it. To be not too enthusiastic or conservative, as the future will be NT maps as you state correctly. Finally, I think: mkgmap could translate the physical shape of a road into different categories, e.g. by setting mkgmap:road-speed parameters. This is more analog than digital "curvy" or "not curvy" setting by just setting single bits (which are not widespread yet, NT only). One might want to differentiate between this way: http://www.openstreetmap.org/way/186500650 and that way: http://www.openstreetmap.org/way/106597772 Which one is faster? Would you like to add the (highly unwanted!) maxspeed:practical tag to OSM data? Car map designers might want to lower speeds for curvy roads, motorcycle map makers would go the other way (knowing that the calculated travel time is incorrect) Adding style rules like highway=primary & curviness() > 50 {add mkgmap:road-speed-max=5} would not influence the map, only curvy roads are affected.
Nobody is forced to use the new function (knowing that it slows down map generation if used). But as it is not a really big thing you might give it a try. I'll test, and report when it works correctly (for me :-))
Cheers Manfred
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
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
participants (5)
-
Felix Hartmann -
GerdP -
Manfred Brenneisen -
Manfred Brenneisen -
WanMil