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

Thu Aug 30 10:48:04 BST 2012

Am 30.08.2012 11:26, schrieb Felix Hartmann:
>
> 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

I have no example for it yet but I think functions should be able to 
store complex results that do not fit into one tag. A function might 
also decide itself if its result should be put into a tag or not.

If you have two lines with the function call ::length.m the first call 
will calculate the value and store it in a tag. The second function call 
checks if the tag exists and returns its value without recalculation.

>
>> - 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.

It's an mkgmap internal requirement. The OSM or PBF loader loads only 
tags that are used in the style file. If you don't use the tag natural 
in your style file it is not loaded for performance reasons. Therefore 
it must be ensured that the tags required by functions are loaded.

>> - 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.

I think so. All functions require a flag if they support points, lines, 
polygons and relations. If the ::length function implement the 
calculation of a route length then the relation flag would be true. 
Anyhow I expect a lots of cases with specialised handling. e.g. a route 
relation might have members tagged with forward/backward. A simple 
implementation would count the length of all members which might be 
twice the real route length.

WanMil