Nope, also against clean trunk the patch does not compile for me:
prepare:
[mkdir] Created dir: d:\Garmin\mkgmap_svn_trunk\build\classes
compile:
[javac] Compiling 317 source files to
d:\Garmin\mkgmap_svn_trunk\build\classes
[javac]
d:\Garmin\mkgmap_svn_trunk\src\uk\me\parabola\mkgmap\osmstyle\StyledConverter.java:1431:
illegal start of expression
[javac] if(way.isBoolTag("unpaved") ||
way.isNotBoolTag("paved")))
[javac]
^
[javac] 1 error
BUILD FAILED
d:\Garmin\mkgmap_svn_trunk\build.xml:71: Compile failed; see the
compiler error output for details.
On 07.12.2009 22:36, Mark Burton wrote:
Bloody typical, you wait around for ages hoping for a new routing
capability to be added to mkgmap and then two come along on
the same day.
I've been trying to discover how unpavedness is encoded for at least 6
months. Every now and again, I return to think about it some more.
Check and re-check the same old data structures. Very
frustrating, no progress. Damn those cunning bastards at Garmin....
However, a month or two ago, I discovered that Table C contains more
than just turn restrictions. I still don't know many of it's little
secrets but, today, having exhausted all other possibilities, I finally
twigged that Table C contains the key to understanding "unpavedness".
Gotcha!
The attached patch allows you to add either unpaved=yes/true/1 or
paved=no/false/0 to a way and then it will be ignored for routing
purposes when the GPS has been told to avoid unpaved roads.
Not sure if those are the best tags to use - any thoughts?
BTW - the unpaved road line type 0x0a has nothing to do with
unpavedness, it's just a routable way that gets drawn as a dashed line
(default rendering).
Feedback, etc.
Mark
_______________________________________________
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
