Patch: New filter "not-contained"
Am Mittwoch, 28. Januar 2015, 12:12:25 schrieb Maxim Düster:
Hello!
type=route & route=bus & ref=* { apply { set route_ref='$(route_ref),${ref|not-contained:,:route_ref}' | '$(route_ref)' | '${ref}'; } }
This should possibly answer my question from January, 7th thank you Bernd -- amarok2 now playing: artist: Ike & Tina Turner title: The Things I Used To Do album: The Soul Anthology
Hi Max, I like your idea, but application in style doesn't look good for me. Wouldn't your rule add a superfluous comma, if name repeats? What I really would like to have, are conditional statements inside apply{} block. This could be used not only to parse name, but for example to examine member's role in relation. -- Best regards, Andrzej
Hi Max, from your explanation I get, that presence of a tag value is tested after processing with your filter. If this is the case, then there is no problem with comma. -- Best regards, Andrzej
Hi Maxim, please can you explain the reason for the change in ValueItem? Gerd From: maxc@gmx.de To: mkgmap-dev@lists.mkgmap.org.uk Date: Wed, 28 Jan 2015 12:12:25 +0100 Subject: [mkgmap-dev] Patch: New filter "not-contained" Hello! I'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 "1,1,2,2,2" (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 "not-equal" filter, but it doesn't just compare two values; instead it looks if the tag'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. Simple example for relations file: type=route & route=bus & ref=* { apply { set route_ref='$(route_ref),${ref|not-contained:,:route_ref}' | '$(route_ref)' | '${ref}'; } } Here, ref value is only added to route_ref if it is not already contained in that list (with separator ','). Otherwise, the value of route_ref is unchanged. Cheers! Max _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Max, not sure. What will happen if one uses another filter in the relations file? Gerd "Maxim Düster" wrote
Hi, Gerd,
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: "value = filter.filter(tagval,el);", 'el' being the parent relation the way is in. That is, in the filter I only have an access to the (global) relation's tags, but what I actually need are the tags of the (local) element being currently processed.
While applying filters to "plain" elements (those not inside a relation, e.g. in points or lines files), 'local_el' and 'el' are equal, so my change should not corrupt anything.
Max
Gesendet: Donnerstag, 29. Januar 2015 um 11:20 Uhr Von: "Gerd Petermann" <
gpetermann_muenchen@
> An: "
mkgmap-dev@.org
" <
mkgmap-dev@.org
> Betreff: Re: [mkgmap-dev] Patch: New filter "not-contained"
Hi Maxim,
please can you explain the reason for the change in ValueItem?
Gerd
From:
maxc@
To:
mkgmap-dev@.org
Date: Wed, 28 Jan 2015 12:12:25 +0100 Subject: [mkgmap-dev] Patch: New filter "not-contained"
Hello! I'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 "1,1,2,2,2" (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 "not-equal" filter, but it doesn't just compare two values; instead it looks if the tag'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.
Simple example for relations file:
type=route & route=bus & ref=* { apply { set route_ref='$(route_ref),${ref|not-contained:,:route_ref}' | '$(route_ref)' | '${ref}'; } }
Here, ref value is only added to route_ref if it is not already contained in that list (with separator ','). Otherwise, the value of route_ref is unchanged. 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
-- View this message in context: http://gis.19327.n5.nabble.com/Patch-New-filter-not-contained-tp5831668p5831... Sent from the Mkgmap Development mailing list archive at Nabble.com.
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
"Maxim Düster" wrote > Hi, Gerd, > > > > 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: "value = > filter.filter(tagval,el);", 'el' being the parent relation > the way is in. That is, in the filter I only have an access to the > (global) relation's tags, but what I actually need are the tags of the > (local) element being currently processed. > > While applying filters to "plain" elements (those not inside a > relation, e.g. in points or lines files), 'local_el' and > 'el' are equal, so my change should not corrupt anything. > > > > Max > > > > Gesendet: Donnerstag, 29. Januar 2015 um 11:20 Uhr > Von: "Gerd Petermann" <
> gpetermann_muenchen@
> > > An: "
> mkgmap-dev@.org
> " <
> mkgmap-dev@.org
> > > Betreff: Re: [mkgmap-dev] Patch: New filter "not-contained" > > > > Hi Maxim, > > please can you explain the reason for the change in ValueItem? > > Gerd > > > From:
> maxc@
> > To:
> mkgmap-dev@.org
> > Date: Wed, 28 Jan 2015 12:12:25 +0100 > Subject: [mkgmap-dev] Patch: New filter "not-contained" > > > Hello! > > I'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 "1,1,2,2,2" (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 "not-equal" filter, > but it doesn't just compare two values; instead it looks if the > tag'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. > > > > Simple example for relations file: > > > > type=route & route=bus & ref=* { > apply { > set > route_ref='$(route_ref),${ref|not-contained:,:route_ref}' > | '$(route_ref)' | '${ref}'; > } > } > > > > Here, ref value is only added to route_ref if it is not already contained > in that list (with separator ','). Otherwise, the value of > route_ref is unchanged. > > 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-tp5831668p5831... 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
-- View this message in context: http://gis.19327.n5.nabble.com/Patch-New-filter-not-contained-tp5831668p5831... Sent from the Mkgmap Development mailing list archive at Nabble.com.
I have a bus stop POI where the label produced by mkgmap includes (1;2;3;4;5,4,4,3,3). https://www.openstreetmap.org/node/1424432523 This happens with the default style. The part 1;2;3;4;5 comes from the route_ref tag on the node. The part ,4,4,3,3 comes from four route relations which include the node. Will the patch fix this? (Excuse the strange appearance of my name. I had to open a new email account because of the Yahoo! problem. http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2014q4/022207.html The live/outlook web interface requires my name to comprise two words. I have not tested whether using an email client would get round this problem.)
Hi Adrian, no, up to now the default style doesn't use the new filter. Gerd
From: ar2988-os@outlook.com To: mkgmap-dev@lists.mkgmap.org.uk Date: Fri, 30 Jan 2015 00:00:42 +0000 Subject: Re: [mkgmap-dev] Patch: New filter "not-contained"
I have a bus stop POI where the label produced by mkgmap includes (1;2;3;4;5,4,4,3,3). https://www.openstreetmap.org/node/1424432523 This happens with the default style. The part 1;2;3;4;5 comes from the route_ref tag on the node. The part ,4,4,3,3 comes from four route relations which include the node. Will the patch fix this?
(Excuse the strange appearance of my name. I had to open a new email account because of the Yahoo! problem. http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2014q4/022207.html The live/outlook web interface requires my name to comprise two words. I have not tested whether using an email client would get round this problem.)
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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
"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-tp5831668p5831... > 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-tp5831668p5831... 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
-- View this message in context: http://gis.19327.n5.nabble.com/Patch-New-filter-not-contained-tp5831668p5831... Sent from the Mkgmap Development mailing list archive at Nabble.com.
participants (6)
-
"Maxim Düster" -
A drian -
Andrzej Popowski -
Bernd Weigelt -
Gerd Petermann -
GerdP