[mkgmap-dev] Cutting down the default style

Thu Nov 10 05:28:26 GMT 2011

Greg Troxel (gdt at ir.bbn.com) wrote:

>
> I've been using Charlie Ferrero's TYP file.  Generally I really like it,
> and I can't imagine going back.
> But I have two issues:
>
>   There isn't open source code to create TYP files from representations
>   that are reasonable to edit with free tools and store in version
>   control systems (and be diffable, etc.).  Fixing this would let us
>   bring a TYP file into the mkgmap source sanely, and then have a style
>   that matches it.
>
>   Style files get edited for multiple reasons; one is to match TYP
>   files, and another is catching up with tag usage.  I'm not suren if
>   Charlie's style files are be a bit out of date (not complaining; what
>   I have to use for free is awesome), but structurally it would be hard
>   to keep them in sync; I think what's needed is a merger of those and
>   the modern mkgmap style, but I haven't spent the time to really dig in
>   (which is a clue that just using what Charlie publishes is very good -
>   I think my big issue is town boundaries being missing, but even that
>   I'm not sure of).

I'm not sure my style files are *that* out of date. ;)  The only thing  
I haven't incorporated is the tweaks necessary to make use of  
--location-autofill=bounds as there are no usable bounds in my part of  
the world.

>
> So, besides the Free text<>TYP converter, one path forward could be (and
> I'm really curious what Charlie thinks here):
>
>   Check in a TYP file that is intended to provide lots of drawing
>   primitives, and Charlie's TYP is probably a good choice (or at least
>   starting place).  Hold our noses while editing it (with the web
>   tools).   Have a text file that documents what the codes do alongside
>   it.

>   Have a style file that is aimed at this checked-in TYP, and use the
>   various perl programs (or probably easy to redo in java) to poke the
>   family id into the TYP.
>

I would revive the suggestion made a few months (years?) ago that  
mkgmap ship with a variety of styles and (if necessary) TYP files  
donated and maintained by individual "style maintainers".  Then a  
given mkgmap user can choose which style is applied at compile-time.   
To make this more foolproof, you could add a tag to the options part  
of the style file that told mkgmap that an associated TYP file is  
required, or else to abort the compilation of the map.  But I would  
leave the default style TYP-free, for simplicity.  The default style  
should, insofar as possible, "just work" and so avoiding TYPs by  
default is imho a better idea.

In terms of TYP->Text, both TYPViewer and TYPWiz can convert from one  
format to the other, so the style maintainers can submit a text  
version and a binary version of the TYP to the codebase.  I guess in  
an ideal world the text version would be the master, and a binary  
version could be compiled either by the user using mkgmap as needed,  
or by the toolchain on the mkgmap server for subsequent distribution  
in the mkgmap.zip.  Nick Willink: would you be willing to contribute  
your code from TYPWiz to make that happen?

As you say, a TYP goes hand in hand with a style file and both have to  
be maintained in synchrony for the system to work.  I would be happy  
to donate my style and TYP (or text equivalent) to the mkgmap trunk  
and then maintain it, but would first need to remove some POIs that I  
adapted from Garmin originals (I had no idea anyone used my TYP so  
never bothered to clear them up).  It's by no means the best or most  
complete TYP/style though:  Minko/Liegfietser has also been developing  
a separate TYP and style and Felix is the master here.

--
Charlie