logo separator

[mkgmap-dev] how does subst work?

From 7770 7770 at foskan.eu on Sun Jan 2 20:27:35 GMT 2022

Hi Ticker.

For 3.
I will try to remove that code in the finalize and try again in a few days.
The code present is:
name=* {name '${name}'}

This pattern is not exactly explained in the style manual and i don't 
understand how it works. if name is set to anything, what will  {name '$
{name}'} actually do?

add and set are described in the style manual, but not the case without add or 
set (or i don't understand where to look for it).


Regards
Karl


On söndag 2 januari 2022 21:09:29 CET Ticker Berkin wrote:
> Hi Karl
> 
> 1. include inc/name processing happens at the point of inclusion
> 
> 2. I don't think variable expansion works within the context of filter
> parameters - your difficulties suggest it really doesn't.
> 
> 3. {set name= ... probably works correctly, but it is the
>     {name ...} statement that sets mkgmap:label:1..4 which are what are
> actually used. There is one of these in the <finalise> section
> 
> Hope this helps
> Ticker
> 
> On Sun, 2022-01-02 at 19:52 +0100, 7770 wrote:
> > Hi.
> > Apologize forthis long email, there are three parts to make it easier
> > to read.
> > Mkgmap version 4839 is used.
> > 
> > I am trying to replace a portion of a name.
> > All of this happens for points and after the a line (same as in
> > default style)
> > that includes:
> > include 'inc/name';
> > 
> > 1.
> > First one question, are all the lines in the included file processed
> > at the
> > point of include 'inc/name'; or are they processed last?
> > 
> > 
> > 2.
> > In my case i have points which have the operator tag and a name tag.
> > so they are affected by the include, by this code:
> > 
> > operator=* & brand!=* {
> >  name '${operator}: ${ref} ${name}' |
> >       '${operator}: ${name}' |
> >       '${operator}: ${ref}' |
> >       '${operator}' |
> >       '${ref}'
> > }
> > 
> > in my case the name is set as '${operator}: ${name}'.
> > 
> > For a few scenarios, where the operator string is too long to make
> > good sense,
> > i am trying to later (after the place of the include line) remove the
> > opreator
> > part, but i can't get it working wery well.
> > 
> > The rule i try looks like this:
> > amenity=shelter & shelter_type=basic_hut & (access!=private &
> > access!=no)
> > {set name='${name|subst:"${operator} =>"}'} [0x3913 resolution 20]
> > 
> > Say the name is TheWildernessHut
> > If the ${operator} tag is empty, the result becomes:
> > TheWildernessHut  =>"}  
> > (which is not good looking).
> > 
> > If there is some value in the ${operator} tag the action block does
> > not seem
> > replace anything.
> > 
> > 
> > Even more strangely, i tested make a replacement of some fixed value,
> > it will
> > not update the name in case the name was altered by the include
> > section, only
> > name tags that were not previously altered seem to be updated.
> > 
> > Exmaple (will not update if the name was altered earlier):
> > amenity=shelter & shelter_type=basic_hut & (access!=private &
> > access!=no)
> > {set name='${name|subst:"The=>"}'} [0x3913 resolution 20]
> > 
> > 
> > I have checked that there isn't any rule earlier that will pick up
> > the
> > amenity=shelter & shelter_type=basic_hut & (access!=private &
> > access!=no) ,
> > and the type 0x3913 is set correctly and shown when apply the TYP
> > file.
> > I also tried hardcoding a name for these patterns, that also works
> > just well.
> > 
> > Did i miss something else?
> > 
> > 
> > 
> > 3.
> > i use --add-pois-to-areas.
> > Points which are generated from areas, does not seem to be affected
> > by any
> > action block for points, but the TYP is set properly.
> > Is this how it is intended to work?
> > 
> > Example:
> > I have a amenity=shelter & shelter_type=basic_hut, this is drawn as a
> > polygon.
> > The rules for this particular structure are only applied in the
> > points style.
> > The TYP is set just well for the point added by --add-pois-to-areas,
> > but it
> > seems i can not alter the name with an action block.
> > 
> > 
> > Regards
> > Karl
> > 
> > 
> > 
> > _______________________________________________
> > mkgmap-dev mailing list
> > mkgmap-dev at lists.mkgmap.org.uk
> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> 
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev






More information about the mkgmap-dev mailing list