Hi Andrzej, On Mon, May 12, 2014 at 03:15:46PM +0200, Andrzej Popowski wrote:
Hi Colin,
Users can customise the program and styles or develop their own, but there is no mechanism to support sharing the nuances of each type of device within the distribution.
I understand the problem but I don't think mkgmap code or default style is a right place to solve it. We could expect more flexibility to create conditional styles from mkgamp, but any hardcoded dependency on Garmin hardware would be a nightmare to maintain.
Well, I think that we could solve it in the default style to some extent. The default style could add one layer of abstraction by using symbolic names instead of numeric type codes in the actions, and the user would take advantage of this if needed. The solution would be parameterized or conditional styles and something similar to what the C preprocessor supports with the -D and -include options. Something like this: java -jar mkgmap.jar -D campsite=0x1234 ... or java -jar mkgmap.jar -include edge705.h ... where edge705.h would contain stuff like #define campsite 0x1234 (or something equivalent in a syntax that is not too different from the current mkgmap style language) Myself, I am not interested in device-specific rules, but I would like to have some parameters that would allow unnecessary detail to be pruned. There could be parameters for minimum size for landuse=* or natural=* or building=* polygons, or the minimum length of highway=service to render in each resolution level. The parameters could also include the list of resolutions to generate. I am not sure if the mkgmap core language should include a parameter substitution mechanism or a macro language. Perhaps we could leverage an external tool, such as http://pmp.sourceforge.net/ which implements the m4 macro language in Java, including ant integration. The mkgmap distribution could include a parameterized build.xml for compiling a map with ant. Marko