[mkgmap-dev] New branch for default typ file

Tue Nov 27 17:21:17 GMT 2018

Ticker Berkin <rwb-mkgmap at 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]