logo separator

[mkgmap-dev] [PATCH v2] - styling for the power user

From Felix Hartmann extremecarver at googlemail.com on Thu Aug 6 10:49:49 BST 2009

Hi Mark, I still don't really understand the advantage.

1. maxres, can we really specify this, I was not aware that this is

2. So the only advantage is that it is shorter to tpye and that
preprocessing becomes possible?

thanks for clarifying a bit here


2009/8/6 Mark Burton <markb at ordern.com>

> v2
> now supports ~[0x??] syntax within name to specify highway shields
> to reduce the number of tags required, you can now specify all the
> values in the mkgmap:gtype tag like this example:
> mkgmap:gtype="0x20,19,,1,2"
> type = 0x20
> minres = 19
> maxres not specified
> roadclass = 1
> roadspeed = 2
> The one tag per value scheme is still supported (for the moment at
> least)
> --------------
> Are you a heavy duty styler? If so, read on:
> I notice that quite a lot of postings on the list are from people who
> are having problems with complex style files. This little patch won't
> (directly) solve those problems but it does provide a useful capability
> that could be part of a solution for those people who have complex
> styling requirements and are willing to do some coding.
> What the patch does is allow elements (nodes, ways) to specify their
> garmin type (and a few other things) explicitly using these tags:
> mkgmap:gtype  the element's type (integer constant)
> mkgmap:kind   one of "node", "polyline", "polygon" (only polygon is used
> at this time to differentiate polygons from lines).
> mkgmap:minres the element's minimum resolution (needed to make element
> visible)
> mkgmap:maxres the element's maximum resolution (not required)
> mkgmap:roadclass the element's road class (needed for roads)
> mkgmap:roadspeed the element's road speed (needed for roads)
> If the mkgmap:gtype tag is present, the element will not be passed
> through the normal style file process at all.
> So how do these tags get added to the OSM data? Well, you could just
> add them with an editor but that would get boring pretty quickly so
> what I would expect to see is some kind of external filter program that
> reads the OSM file and outputs a new OSM file with the appropriate tags
> added.
> That filter program could be written in any language that has some XML
> processing support.
> Current issues to be sorted out are handling of the highway shields
> (not currently implemented) and also this feature is not compatible with
> the cycleway faking code.
> All feedback welcome.
> Cheers,
> Mark
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20090806/a673954b/attachment.html 

More information about the mkgmap-dev mailing list