logo separator

[mkgmap-dev] Patch: New filter "not-contained"

From GerdP gpetermann_muenchen at hotmail.com on Fri Jan 30 13:35:29 GMT 2015 

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 at .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 at .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 at .org 
> > 
> > > " < 
> > 
> > > mkgmap-dev at .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 at .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 at .org 
> > 
> > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev 
> > > 
> > > _______________________________________________ mkgmap-dev
> mailing 
> > list 
> > 
> > > mkgmap-dev at .org 
> > 
> > > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > _______________________________________________ 
> > > mkgmap-dev mailing list 
> > 
> > > mkgmap-dev at .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 at .org 
> 
> > 
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev 
> > 
> > 
> > 
> > 
> > _______________________________________________ 
> > mkgmap-dev mailing list 
> 
> > mkgmap-dev at .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 at .org

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

> mkgmap-dev at .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.

More information about the mkgmap-dev mailing list