logo separator

[mkgmap-dev] access=no//access=private on short lines vs long lines

From Felix Hartmann extremecarver at gmail.com on Thu Aug 30 10:26:57 BST 2012

On 30.08.2012 11:03, WanMil wrote:
>> Mkgmap has some filters that allow for example not putting small areas
>> into the map.
>>
>> It would be great, to have a very simple filter for highways too, called
>> via the style-file. I would imagine the following command to be very useful:
>>
>> highway=service & ( access=private | access=no ) &
>> mkgmap:filter:length<100m {delete highway; delete oneway; delete tunnel;
>> delete bridge}
>>
>>
>> It does not need to be meters, it can be Garmin units,  so one can
>> quickly experiment with it. This would come very handy so one could make
>> clean maps without showing the private garden micromapping that is
>> getting more and more common. Excluding all highways with
>> access=no/access=private, however often runs into problems with faulty
>> tagging. Having a length check should get rid of annoying for general
>> use not usable micromapping. As the mkgmap filter would only be called
>> upon request from the style-file, it should not harm performance
>> (checking length of every way would of course).
>>
> Two things come into my mind:
>
> 1. Highways are often divided into several parts due to tagging bridges,
> maxspeed, lanes etc. So in your example all bridges tagged with
> access=private|no will disappear although they might belong to mucher
> longer highways. Is that ok for you? Do you have an idea for a solution
> how to avoid that?
yes of course. But I don't think that's too often the case. Currently I 
simply delete all ways. a length filter would allow me to delete less 
ways, and to be a bit more flexible. It's too bad that we don't have an 
access value
>
> 2. You want to introduce some kind of functions in the style system.
> mkgmap:filter:length is no tag but would call a function that calculates
> the length on request. That sounds good to me but we should plan
> carefully how to implement functions.
> - Do we need a special notation in the style files? e.g. functions start
> with two colons ::length.km<100
that's okay. I first thought about mkgmap:length alone, then thought, 
well that might cause confusion, let's call it mkgmap:filter:length
mkgmap::length.m<100 would be easier and a clearer distinction.
> - Do we have to avoid that functions are called more than once so the
> result is cached? e.g. the result might be stored in a tag or a seperate
> data structure
I think storing the result in a tag is most flexible so consequent 
actions can be easily taken. Caching might have the performance edge if 
you query for more than one lenght e.g. 50<100<500

> - Functions might require some tags. So their implementation must signal
> the style system which ones these are so that the loader of the input
> file does not ignore these tags.
I'm not sure what you mean by this.
> - The results of a function might be numeric or a text.
> - ...?
Well if we store it in a tag. the resulting tag of the query 
mkgmap::lenght>100 for subsequent actions could be mkgmap:length=150 
(for a way that is 150m long).

What comes to my mind is, if the above is easily calculated, could there 
be a calculation for the length of a route too? That would allow much 
better classification of routes than currently possible (which relies on 
not always present tags such as network=RCN for Regional Cycle Routes, 
or RWN for Regional Walking Routes). In that case the calculation needs 
to be triggered and effectuated in the relations style-file of course, 
and then handed over as tag to the lines file.
>
> WanMil
>
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-- 
keep on biking and discovering new trails

Felix
openmtbmap.org & www.velomap.org




More information about the mkgmap-dev mailing list