Re: [mkgmap-dev] how does subst work?
Hi Karl
It is 4.3.6 in the style manual.
Ticker
On Sun, 2022-01-02 at 21:27 +0100, 7770 wrote:
> 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}'}
>
> 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 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@lists.mkgmap.org.uk
> > > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> >
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
>
>
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] how does subst work?
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 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@lists.mkgmap.org.uk
> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] how does subst work?
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 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@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
