Marko Mäkelä <marko.makela@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