Greg Troxel (gdt@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