[mkgmap-dev] My involvement in mkgmap and the default style

Fri Jul 27 14:43:30 BST 2012

Marko Mäkelä <marko.makela at iki.fi> writes:

> Long time ago, I got the impression from Extremecarver that each Garmin 
> unit can have a different built-in "TYP file", which is used when no TYP 
> file is included in the map-set. My experience is limited to the Edge 
> 705 and the GPSMap 60CSx. I do not care that much about the map 
> presentation, because I rarely go off-road. POI search is more important 
> to me.

I have the impression there is a default TYP-type style for various
families of units (etrex vista HCx is different from oregon 450, for
instance) for mkgmap maps w/o a TYP file.   So I agree with the above.

>>Let me know if this testing is helpful or I should test different way.
>
> Well, I think it could be useful to introduce a TYP file that goes with 
> the default style. What do you think?

Agreed.

People talk about styles and TYP for specific purposes.  I think a good
plan is to have a main style that tries to be comprehensive (hikers
don't care so much how the roads look and drivers don't care so much
about trails, so each can be optimized) and then to see where we are.
Issues that I see are:

  licensing: given ODbL and the complexity of license compatibility, CC0
  makes sense for style and TYP.  I don't think we as a community have
  any worry about someone taking styles private and spiffing them up and
  providing proprietary builds.  I think the big point is that we have
  to be careful about only including things with consent from copyright
  holders.

  style/TYP interface: TYP can describe a rendering for elements that
  are already normal, and it can describe rendering for line and point
  types that are not normally in use.   Ideally we could mix/match style
  and TYP, and I think that means having a plan for which codepoints
  have which meaning.  That will allow decoupling of figuring out the
  mapping from osm to codepoints (not just which, but whether to include
  and at what scale), and display of codepoints.

  TYP can be beyond-style: it seems fine to have a TYP define lots of
  things that a style doesn't use.  So a lot of people can use the same
  TYP.

  multiple codepoints for a reason: it's possible we could define a
  range of codepoints for the same semantics, and have multiple
  renderings in one file, so that the style could be changed to make the
  output change, without changing the TYP.  But maybe we should see how
  much conflict there is.

So I'm advocating:

  a definition of codepoints

  a default TYP file with a rough consensus render for those codepoints

  a default style that expects the default TYP file

  perhaps a 'basic' style that works w/o a TYP

I've been using Charlie's TYP file (and style) and think it's a great
improvement.  I wonder if it makes sense for everyone who is maintaining
a TYP to convert it to mkgmap input format and trim things for which
they can't grant CC0, and publish that.  I suspect that it would not be
too contentious to try to merge the best of the existing TYPs.

Other approaches are possible - I'm just rambling about how to manage
complexity and get the best maps with the least total brain time.

Greg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
Url : http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20120727/86e3dfed/attachment.bin 