logo separator

[mkgmap-dev] default style lines enhancements

From nick osm at pinns.co.uk on Sat Jul 25 11:11:56 BST 2020

Hi Ticker,

I agree with Gerd that creating a route around all car parks may not be 

I fear that in most of the cases it will create extra lines when they 
aren't necessary .

When an osm mapper is not concerned about  routing across car parks ,   
it seems only in certain cases paths stop on the outline of a car park 
and in my experience some 'ends'  just get plonked on top of the carpark !

However, as with pedestrian areas, unfortunately , there are other 
polygons, ie parks ,golf courses, grass lands, which are equally 

Some plot highway=virtual to ensure some routing - although this gets 
frowned upon by some.

Ideally mkgmap  identifies ends of highways inside a polygon and joins 
them, but that might also be unsatisfactory.

Anyway, thanks for your great efforts to bring this style  up  to date !


On 25/07/2020 09:28, Gerd Petermann wrote:
> Hi Ticker,
> ok, most of the changes look plausible to me, but I see no need to add the lines for razed / disued / abandoned etc. railways. I would comment these two lines:
> abandoned:railway=* | demolished:railway=* | removed:railway=* | razed:railway=* | was:railway=* | historic:railway=* {add railway=lifecyclePrefix}
> railway=* & railway!=miniature & railway!=proposed & tunnel!=yes & highway!=* & is_closed()=false [0x19 resolution 22]
> I am also not sure about the routable lines for amenity=parking. Even with the test reg. connected this probably creates lots of routing islands. As a mapper, I've never cared to connect those areas to the road network, but I know that other mappers do this. Is it meant to improve pedestrian routing?
> Gerd
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> Gesendet: Donnerstag, 23. Juli 2020 17:46
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] default style lines enhancements
> Hi Gerd
> It can only be:
>    ${tagname|filter:args}
> or
>    ${tagname|filter1:"arg with spaces"}
> and, for the subst filter, the from=>to counts as a single arg.
> In the example:
>    ... '${ref|subst: =>} ${mkgmap:dest_hint|subst:;=> |subst:/=> }'
> spaces are insignificant either side of the first | and before the :
> but are significant after the : and before subsequent |.
> The style manual says:
>   If the argument contains spaces or symbols it should be quoted.
>     For backward compatibility, most cases where you have spaces or
>   symbols do not actually need to be quoted, however we would
>   recommend that you do for clarity.  If you need a pipe symbol
>   or a closing curly backet, then you must use quotes.
> Ticker
> On Thu, 2020-07-23 at 10:40 +0000, Gerd Petermann wrote:
>> Hi Ticker,
>> I am not a style guru, but I think the quotes for the subst function
>> are even more confusing. If you use quotes I would suggest something
>> like
>> ${destination:ref|subst:" " => ""}
>> instead of
>> ${destination:ref|subst: =>}
>> if that really gives the same result.
>> Gerd
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> 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