[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
- Previous message: [mkgmap-dev] access=no//access=private on short lines vs long lines
- Next message: [mkgmap-dev] access=no//access=private on short lines vs long lines
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list