Hi, Gerd,

well, it's indeed not so easy to find an example. In most cases you won't see any difference because almost no existent filter uses the second parameter in the filter()/doFilter() method. The only one using it, besides the proposed new filter, is the 'not-equal' filter. The example I found for using it inside the apply{} block is a bit artificial and probably not really meaningful, but I hope, it gives the idea.

Assume, you want to find and visualize a specifical type of errors in data, namely streets being part of an associatedStreet relation but having a different name than the relation itself. To get this, you could do in relations file something like:

type=associatedStreet & name=* {
   apply {
       set nameInRelation='${name|not-equal:name}';
   }
}

where you want to compare the relation's name with the street's name and to remember the relation's name if it's different.

Then, in lines file, you could write something like

highway=* & nameInRelation=* [...]

<finalize>
name=* { name '${name}/${nameInRelation}' }

to highlight the differences. So, and now, with the current mkgmap code both "name"s referenced in the 'set' command are the same, namely it's the name of the relation. You cannot pass the current street's name to the filter. After running mkgmap you get a map without any street as for every street holds name=name and so nameInRelation is not set.

You could also try to pass a differently named tag to the filter by saving the street's name in a temporary tag, like:

type=associatedStreet & name=* {
apply {

       set myname='$(name)';
       set nameInRelation='${name|not-equal:myname}';
   }
}

But in this case, the tag 'myname' would also be looked for in the relation, not in the street's tags, and as the relation doesn't have such a tag, nameInRelation is always set to the relation's name and so you see in your map all the streets, not only the erroneous ones. So, either all or no at all.

With the proposed change, however, the filter gets a local element as a second parameter in doFilter(), so in both cases the name of the relation would be compared to the (local) tags of the current street (either name or myname) and you would get only streets with errors in the map.

The new filter is specifically designed for using in the apply{} block, so it necessarily needs an access to the local object.

So, to summarize my reasoning: the functionality of no existent filter would break after the patch (almost all filters would not see any difference, one would potentially benefit from the change and one requires it). Writers of new filters would not, in my opinion, have any troubles with it, too. If they would need a local element, they get it for free. If they would need a global element, one can always save global tags in the local element and then call the filter with the local element.

What do you think about it now? Could I convince you? :)

Max

Gesendet: Donnerstag, 29. Januar 2015 um 23:31 Uhr
Von: GerdP <gpetermann_muenchen@hotmail.com>
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Patch: New filter "not-contained"

Hi Maxim,

I tried to find out if the patch has a side effect, but
I failed. From your description I understand that
I should be able to produce different results (not
using the new filter, just something that workded before)

Can you give an example where I should find a difference?

Gerd

"Maxim Düster" wrote
> Hi, Gerd,
>
>  
>
> I think, there shouldn't be a problem. Actually, if you are using a
> filter inside of the apply{} block, you would presumably like to be able
> to access the current element from the filter. At the moment you don't
> have such a possibility at all.
>
> If though there will be need to pass a tag from the global relation to the
> filter, one can always assign a global tag to a temporary local tag before
> calling the filter with this local tag.
>
> So, in my mind, nothing should go wrong here. Perhaps someone else can say
> something more regarding this issue.
>
>  
>
> Max
>
>  
>
> Gesendet: Donnerstag, 29. Januar 2015 um 18:30 Uhr
> Von: GerdP <

> gpetermann_muenchen@

> >
> An: 

> mkgmap-dev@.org

>
> Betreff: Re: [mkgmap-dev] Patch: New filter "not-contained"
>
> Hi Max,
>
> not sure. What will happen if one uses another filter in the relations
> file?
>
> Gerd
>
>
> &quot;Maxim Düster&quot; wrote
> > Hi, Gerd,
> >
> > &nbsp;
> >
> > the change is caused by the fact that the filter was thought
> primarily for
> > working in relations file inside of the apply{} block and needs that
> the
> > tag given as last parameter is a local tag of the element being
> processed
> > (e.g. a way). But the old code line says: &quot;value =
> > filter.filter(tagval,el);&quot;, &#39;el&#39; being the
> parent relation
> > the way is in. That is, in the filter I only have an access to the
> > (global) relation&#39;s tags, but what I actually need are the
> tags of the
> > (local) element being currently processed.
> >
> > While applying filters to &quot;plain&quot; elements (those
> not inside a
> > relation, e.g. in points or lines files), &#39;local_el&#39;
> and
> > &#39;el&#39; are equal, so my change should not corrupt
> anything.
> >
> > &nbsp;
> >
> > Max
> >
> > &nbsp;
> >
> > Gesendet:&nbsp;Donnerstag, 29. Januar 2015 um 11:20 Uhr
> > Von:&nbsp;&quot;Gerd Petermann&quot; &lt;
>
> > gpetermann_muenchen@
>
> > &gt;
> > An:&nbsp;&quot;
>
> > mkgmap-dev@.org
>
> > &quot; &lt;
>
> > mkgmap-dev@.org
>
> > &gt;
> > Betreff:&nbsp;Re: [mkgmap-dev] Patch: New filter
> &quot;not-contained&quot;
> >
> >
> >
> > Hi Maxim,
> >
> > please can you explain the reason for the change in ValueItem?
> >
> > Gerd
> > &nbsp;
> >
> > From:
>
> > maxc@
>
> >
> > To:
>
> > mkgmap-dev@.org
>
> >
> > Date: Wed, 28 Jan 2015 12:12:25 +0100
> > Subject: [mkgmap-dev] Patch: New filter
> &quot;not-contained&quot;
> > &nbsp;
> >
> > Hello!
> > &nbsp;
> > I&#39;ve attached a patch with a new filter that helps while
> processing,
> > for example, public transport relations. The reason: there can be
> multiple
> > route relations with the same ref attribute (for example, one for the
> > forward direction, one for the return direction), combined to a
> > route_master relation.
> >
> > If you want a name for a way to contain the refs of all of the routes
> > going through that way, you have a problem that some refs will be
> present
> > more than once, similar to &quot;1,1,2,2,2&quot; (if we
> assume that route
> > 1 has two instances, and route 2 - three instances).
> >
> > The new filter helps to circumvent this. It takes 2 parameters: a
> > delimiter (a comma in the example above) and the name of a tag
> containg
> > the list. The filter works a bit like the
> &quot;not-equal&quot; filter,
> > but it doesn&#39;t just compare two values; instead it looks if
> the
> > tag&#39;s value (to which the filter is being applied) is
> contained in the
> > list from the (other) given tag. If it is not the case, the value can
> be
> > added to the list, otherwise the tag is considered unset.
> >
> > &nbsp;
> >
> > Simple example for relations file:
> >
> > &nbsp;
> >
> > type=route &amp; route=bus &amp; ref=* {
> > &nbsp;&nbsp; apply {
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; set
> >
> route_ref=&#39;&#36;(route_ref),&#36;{ref&#124;not-contained:,:route_ref}&#39;
> > &#124; &#39;&#36;(route_ref)&#39; &#124;
> &#39;&#36;{ref}&#39;;
> > &nbsp;&nbsp; }
> > }
> >
> > &nbsp;
> >
> > Here, ref value is only added to route_ref if it is not already
> contained
> > in that list (with separator &#39;,&#39;). Otherwise, the
> value of
> > route_ref is unchanged.
> > &nbsp;
> > Cheers!
> > Max
> >
> >
> > _______________________________________________ mkgmap-dev mailing
> list
>
> > mkgmap-dev@.org
>
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> >
> > _______________________________________________ mkgmap-dev mailing
> list
>
> > mkgmap-dev@.org
>
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> >
> >
> >
> >
> >
> > _______________________________________________
> > mkgmap-dev mailing list
>
> > mkgmap-dev@.org
>
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
>
>
>
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Patch-New-filter-not-contained-tp5831668p5831841.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> _______________________________________________
> mkgmap-dev mailing list

> mkgmap-dev@.org

>
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
>
>
> _______________________________________________
> mkgmap-dev mailing list

> mkgmap-dev@.org

> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

--
View this message in context: http://gis.19327.n5.nabble.com/Patch-New-filter-not-contained-tp5831668p5831869.html
Sent from the Mkgmap Development mailing list archive at Nabble.com.
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev