New branch is-in for experiments on style function is_in
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-tp5954103.... 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
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@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-tp5954103.... 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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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@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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (3)
-
Gerd Petermann -
jan meisters -
Ticker Berkin