Ticker Berkin <[email protected]> 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]
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
