Ticker Berkin <rwb-mkgmap@jagit.co.uk> writes: (I'm a long-term mkgamp user, sometimes contributor, mostly lurking lately.)
I don't think having:
BRANCH: default-typ
makes sense because I don't think there will ever be a single, ideal file. So better to accept now that it will be a collection of files, and, as nothing exists at the moment, they might as well go in 'trunk'.
As I see it, branches are useful for protecting trunk from changes that are in-progress or controversial. Adding some typ sources doesn't seem to rise to that. But if so, then surely we'd have a branch until it's reviewed, and then merge it and delete the branch. I'm unclear on if that's the choice, or if there is some other suggestion that I don't understand.
I don't know what the best visual effect should be either, but, having tried a complex example I found somewhere, the raw Garmin device rendering (with just a _drawOrder section in the TYP file) looked much, much better.
Having a bunch of examples sounds good. I would like to head to a default typ file that is integrated with the default style, so that rendering is more or less aligned with mapnik, but perhaps a bit more detailed at high zoom. I used to use cferrero's style/typ and really liked it, but with mkgmap improvements over the years it was no longer usable without more clue than I had. The big thing over no-typ was showing traffic lights. Semi-related, I am carrying a diff to render "boundary=parcel"; I include state parcel boundary data with osm data in splitter. I have no idea how many others want this, but given that parcel data is not in OSM, merging while mapbuilding (or a separate transparent parcel map) seems pretty useful. What I'm doing is not really ok, but I'm just mentioning the concept. # 0x23 is depth countour - thin. Wacky but useful. 0x1c is too heavy boundary=parcel [0x23 resolution 20]