the attached java classes together with the patch enables mkgmap to create contour lines directly from digital elevation model (DEM) data. This may be useful for those who don't want to ceate contour lines with other tools and store them in huge(!) files. That seems very cool, and I look forward to trying it. It would be nice to have a few intermediate abilities (I've read most the rest of the thread by now): output osm format data from the DEM (for other use, or later use, or for intermediate reprocessing) make an img that's transparent with the DEM data, not only for licensing reasons but also because it really seems like something the user would want to flip off sometimes. For the first point, my immediate reaction was that it was too bad this was in mkgmap instead of a standalone utility, but I see the intermediate storage issue. Having the code in mkgmap is not a big deal, and it enables the nice behavior of an internal pipeline. This isn't really related to your work, but it seems to me that mkgmap has grown tons of options, and modern recommended usage is to have a lot of them on. It would be nice if every option had a negative form and there was a --best-practice option that enabled all the ones that are recommended for making the best garmin maps (complete with tdb etc. for turning into gmapi, and everything else one would need). Right now it seems a little hard to use, where everyone has to chase down those options and write a script. I can certainly see where at one time each of these options might have caused trouble and thus was not default, and the notion that behavior shouldn't change for compatibility. But I also wonder how many users really want that rather than just to make a img file for their receiver.