logo separator

[mkgmap-dev] Commit: r2314: Ignore access=permissive|designated|official just like access=yes.

From aighes osm at aighes.de on Thu Aug 16 11:07:14 BST 2012

Of course it's possible to make some access-changes in style-file. The 
"problem" is, that mkgmap does something "unknown" afterwards. It would 
be more transparent for style-devs, if there are only 2 values (yes and 
no) accepted by mkgmap and Garmin.

Now I have to do something, to ignore an access-value. This is a little 
bit strange. ;)

Henning

Am 16.08.2012 12:01, schrieb Marko Mäkelä:
> On Thu, Aug 16, 2012 at 11:08:01AM +0200, aighes wrote:
>> Won't it be better to leave this part completely in style-file? mkgmap
>> just looks to mkgmap:access=yes|no and some other mkgmap:*=yes|no (which
>> are understood) and in which case someone set one of this parameter is
>> completely in style-file.
>>
>> Advantage would be, that stlye-creator can set access, as he would like
>> to and is not surprised/confused about changes made by mkgmap afterwards.
> That advantage would still exist. What I am proposing is:
>
> (1) style file can set or delete access/motorcar/foot/bicycle/whatever tags
> (2) mkgmap core will map the following access tag values:
>     no,private,destination => no, yes,permissive,official,designated = yes
>
> I am not entirely sure about the 'destination'; this is something I
> understood between the lines in the recent discussions.
>
> The mapping of the values in the mkgmap core would allow the style file
> to be simple.
>
> But, the style file could still do some mapping on its own. Here are
> some examples. They are not very sensible, but I hope you got the idea.
> I guess you would only have one of these in the style file:
>
> foot=private|foot=destination { delete foot; }
> foot=private|foot=destination { set foot=yes; }
> foot=official { set foot=no; }
>
> The mkgmap core would see the foot=* values after this mapping, so you
> could override the internal mapping.
>
> 	Marko
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>




More information about the mkgmap-dev mailing list