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