[mkgmap-dev] New branch is-in for experiments on style function is_in

Thu Jan 2 13:42:28 GMT 2020

Hi Jan

--is-in-landuse only existed in revision 4397 (15th - 18th December),
when it replaced and generalised --residential-hook, which was then
restored.

The new style function will be able to perform the functionality of
both of the above and more and should eventually replace them.

The function parameters are still in the process of being defined, but
expected to be
1: tagName
2: tagValue
3: keyword indicating inclusiveness

ie, a rule in style / polygons:

building=* & building!=no & is_in(landuse,residential,any)=false [0x..]

meaning if any part of a building polygon is not with a
landuse=residential polygon, it will be rendered.

The 3rd parameter/keywords are still being considered. 'any'/'all' are
well defined for polygon in polygons, but the cases of lines in
polygons are much more complicated, as per Gerd's is-in-hook-samples
-v2.osm questions, and we hope to have different keywords to cover the
cases that users want to be able to distinguish.

Ticker

On Mon, 2019-12-30 at 14:16 +0100, jan meisters wrote:
> Hi Gerd,
> 
> is the function still invoked with —is-in-hook=landuse…,  as before?
> Or is it now just to be defined in the Style?
> And which are the three parameters you mentioned?
> 
> Jan
> 
> > Am 30.12.2019 um 11:47 schrieb Gerd Petermann <
> > gpetermann_muenchen at hotmail.com>:
> > 
> > Hi all,
> > 
> > with the help of Ticker I see a way to implement an is_in style
> > function 
> > I've created branch is-in to experiment with this. Sorry for the
> > different spelling is-in in the branch name!
> > 
> > Unfortunately I got no response regarding the contents of the file
> > is-in-hook-samples-v2.osm  posted here:
> > http://gis.19327.n8.nabble.com/Test-cases-for-possible-is-in-hook-t
> > p5954103.html
> > So, Ticker and I have to guess what the function should do when a
> > way or polygon crosses or touches the boundary of
> > a polygon with the given attribute.
> > 
> > The code in r4400 implements a function is_in with three parameters
> > which returns either true or false.
> > It allows a rule like this in the lines file:
> > highway=* & bicycle!=* & (is_in(landuse,cemetery,all) = true |
> > is_in(amenity,grave_yard,all) = true) {add bicycle=dismount}
> > 
> > or this one in the polygons file:
> > # render building only when completely outside of a residential
> > area
> > building=* & building!=no & is_in(landuse,residential,any)=false
> > [0x13 resolution 24]
> > 
> > A BIG question mark is the handling of rules which change the tags
> > of polygons. 
> > Assume you have a rule like this in polygons:
> > landuse=residential | landuse=commercial {set mylanduse=xyz}
> > and somewhere else
> > building=* & building!=no & is_in(mylanduse,xyz,any)=false [0x13
> > resolution 24]
> > 
> > It might not be obvious but this could produce more or less
> > unpredictable results as it depends on the 
> > order in which elements are processed. 
> > 
> > So, Ticker suggested to say "results of the is_in function are
> > undefined when tags of polygons are changed".
> > I hope we can change this to something like "changing tags of
> > polygons in the style rules has no effect on the results of the
> > is_in function"
> > by creating copies of elements before the style rules are applied.
> > 
> > Gerd
> > _______________________________________________
> > mkgmap-dev mailing list
> > mkgmap-dev at lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> 
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev