Re: [mkgmap-dev] Sea Polygons and java 1.6
Am 22.08.2009 13:18 Uhr schrieb Dermot McNally: 2009/8/22 Steve Ratcliffe st...@parabola.me.uk: Agreed, so I am especially looking for Mac users to give advice and/or offer to help. In particular SoyLatte is often suggested, but this requires that you be a research licensee. The openJDK release from the same source has recently appeared and is GPL of course and so has no such restriction, but it is marked beta and although I would be surprised if there were any problem with a command line app it would be good to have it confirmed. I'm a mac user and the Java 1.6 requirement of the splitter caused me to look into this a bit. After a lot of messing around, including with Soylatte (which worked, BTW), I reached the conclusion that on MacOS Leopard at least, 1.6 is already available and many Mac users will already have it sitting silently on their machines: http://www.apple.com/downloads/macosx/apple/application_updates/javaformacosx105update1.html The Java preferences application will allow you to switch which version of Java is used by default. Indeed, Mac OS X 10.5 and later support Java 1.6 on 64-bit hardware (though, as you say, it needs to be activated in the Java preference app). A few older Macs, before they shipped with 64 bit Intel processors, still cannot run it. However, if I recall correctly, there were only very few early Apples that were shipped with 32bit only processors. The exact java version on my machine with the official Apple build is: java version 1.6.0_13 Java(TM) SE Runtime Environment (build 1.6.0_13-b03-211) Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02-83, mixed mode) Considering that (a) Mac OS 10.6 is due really soon now(TM) and (b) all recent (last two years?) Apples have 64bit processors, I think it should be no problem to switch to Java 6 on Mac. It would be really nice if, for some transition period, mkgmap would still be able to run in a limited functionality mode with a 1.5 runtime, disabling features that require 1.6. But I'm not a Java programmer, so I don't know how hard that would be. Alexander ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Magic highway symbols on Vista CX failing
Am 02.08.2009 15:16 Uhr schrieb Steve Ratcliffe: I did not. If I do, the symbols appear correctly. I'm not familiar with neither the Garmin encoding nor mkgmap's handling of it, but would it be possible to add the codes for the symbols to the names in a way that they work with both 6bit and 8bit encoding? Sure it just looks like a bug. I've just commited a fix, try version r1116 and see if that is any better. Great, thanks. Now it works with and without --latin1. Alexander ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Magic highway symbols on Vista CX failing
Hello I seem to have a problem with the default style and the highway tagging on my Garmin Vista CX with mkgmap rev. 1114. When I tag highway=secondary, name=Grand River and ref=MI 123, the result is a road with name Road. It works as expected, however, with highway=primary. So I did some research and I think the problem is that not all of the magic symbols in src/uk/me/parabola/mkgmap/osmstyle/actions/HighwaySymbolFilter.java are available on the unit. Also they are named wrongly for this unit. I made an OSM test file[1] to check all symbol names given in the above source file. It contains parallel road segments with ref=MI 43 name=Grand River I-VI and highway tags of motorway,trunk,primary,secondary,tertiary,residential respectively. Then I used a slightly modified default line style[2] (which assigns one highway symbol to each of the above road types) to generate a map[3] with the --gmapsupp command switch. After uploading the result to my Vista CX, it renders like in this picture[4]. The styles are (from bottom to top): interstate,shield,round,hbox,box,oval. Some remarks: * Styles interstate and shield look exactly like hbox and box but they prepend US and Hwy. to the reference (only appears when hovering the pointer over the street). This is not so useful for OSM data, since the US tagging scheme in the Wiki says those should be included in the ref tag (i.e. ref=I 94 or ref=US 127). * Style box is misnamed, as it produces an oval * Style oval does not work, it seems to break the entire name of the road * Style round is misnamed, it produces a framed box I don't know how other units render these symbols, so I can't say whether the names should be changed or not. But I do think that oval should at least not be used in the default style for secondary roads, as it actually breaks the name display on my (not quite uncommon) unit. If you need more information or want me to run more tests, please let me know. Alexander [1] http://alex.wittig.name/sonstiges/mkgmap/test.osm [2] http://alex.wittig.name/sonstiges/mkgmap/lines [3] http://alex.wittig.name/sonstiges/mkgmap/gmapsupp.img [4] http://alex.wittig.name/sonstiges/mkgmap/P1020125.JPG ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
