Branch is_in ready for a first test
Hi all, the branch version r4408 implements the style function is_in with three parameters tag-key,tag-value,method - tag-key can be something like landuse or natural or amenity - tag-value would be the expected value for that tag-key - method has to be "any" or "all". Example usage in lines: # no cycling within a cemetery highway=* & bicycle!=* & is_in(landuse,cemetery,all) {add bicycle=dismount} Before any style rule is evaluated the function evaluates the list of all ways found in the input file. When a way matches the given tag (key+value) and is closed and complete the shape geometry is stored in a spatial index. With the current implementation this index is created for appearance of the is_in function in a style rule (subject to optimization) When the style function is called it retrieves the stored shape(s) which intersect the boundary of the element. If none is found "false" is returned. If there are multiple such shapes the are merged where possible, so that overlapping or touching shapes are combined to a single shape which may include holes. The list of (outer) shapes is then tested one after the other until one shape is found which either contains the element completely or - when "any" is used as method - partially. If none is found the value "false" is returned. If a match is found and the combined shapes have holes, a final test is done to find out if the element is within the hole. If method "any" is used and the shape is completey within one hole "false" is returned. If method "all" is used and the shape is partly within one hole "false" is returned. If we get here true is "returned" I've also slightly changed the behaviour of the LocationHook and the ResidentialHook. The results should be a bit more predictable now as searches are done with higher precsion. Still, both try to find a nearby boundary(shape) if none is found at the exact position. The ResidentialHook is now automatically disabled when the style doesn't use mkgmap:residential anywhere. TODO: - various possible special cases need more testing - maybe add more methods for cases where parts of the tested element touch the boundary of the shape. - tuning - unit tests As always with branch version the binary can be found at the bottom of the download page. http://www.mkgmap.org.uk/download/mkgmap.html I've tested this with the example file posted before, accept for b18 all cases work as expected. Gerd
Hi Gerd I used the latest http://www.mkgmap.org.uk/download/mkgmap-is-in-r4408.zip I added highway=* & bicycle!=* & is_in(landuse,cemetery,all) {add bicycle=dismount} & get Error in style: Error: (lines:22): Value 'is_in()[landuse, cemetery, all]' is not part of an expression Error in style: Error: (lines:22): Value 'is_in()[landuse, cemetery, all]' is not part of an expression Error in style: Error: (lines:22): Value 'is_in()[landuse, cemetery, all]' is not part of an expression Am I missing something ? I'm confused about which option if any is required If I use --is-in-hook=landuse I get an invalid option error r Nick On 09/01/2020 11:43, Gerd Petermann wrote:
Hi all,
the branch version r4408 implements the style function is_in with three parameters tag-key,tag-value,method - tag-key can be something like landuse or natural or amenity - tag-value would be the expected value for that tag-key - method has to be "any" or "all".
Example usage in lines: # no cycling within a cemetery highway=* & bicycle!=* & is_in(landuse,cemetery,all) {add bicycle=dismount}
Before any style rule is evaluated the function evaluates the list of all ways found in the input file. When a way matches the given tag (key+value) and is closed and complete the shape geometry is stored in a spatial index. With the current implementation this index is created for appearance of the is_in function in a style rule (subject to optimization)
When the style function is called it retrieves the stored shape(s) which intersect the boundary of the element. If none is found "false" is returned. If there are multiple such shapes the are merged where possible, so that overlapping or touching shapes are combined to a single shape which may include holes. The list of (outer) shapes is then tested one after the other until one shape is found which either contains the element completely or - when "any" is used as method - partially. If none is found the value "false" is returned. If a match is found and the combined shapes have holes, a final test is done to find out if the element is within the hole. If method "any" is used and the shape is completey within one hole "false" is returned. If method "all" is used and the shape is partly within one hole "false" is returned. If we get here true is "returned"
I've also slightly changed the behaviour of the LocationHook and the ResidentialHook. The results should be a bit more predictable now as searches are done with higher precsion. Still, both try to find a nearby boundary(shape) if none is found at the exact position. The ResidentialHook is now automatically disabled when the style doesn't use mkgmap:residential anywhere.
TODO: - various possible special cases need more testing - maybe add more methods for cases where parts of the tested element touch the boundary of the shape. - tuning - unit tests
As always with branch version the binary can be found at the bottom of the download page. http://www.mkgmap.org.uk/download/mkgmap.html
I've tested this with the example file posted before, accept for b18 all cases work as expected.
Gerd _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Nick, sorry, my example was wrong. Here is the corrected version: highway=* & bicycle!=* & is_in(landuse,cemetery,all)=true {add bicycle=dismount} The function returns a value (true or false) which has to be tested. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Pinns UK <osm@pinns.co.uk> Gesendet: Donnerstag, 9. Januar 2020 14:50 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test Hi Gerd I used the latest http://www.mkgmap.org.uk/download/mkgmap-is-in-r4408.zip I added highway=* & bicycle!=* & is_in(landuse,cemetery,all) {add bicycle=dismount} & get Error in style: Error: (lines:22): Value 'is_in()[landuse, cemetery, all]' is not part of an expression Error in style: Error: (lines:22): Value 'is_in()[landuse, cemetery, all]' is not part of an expression Error in style: Error: (lines:22): Value 'is_in()[landuse, cemetery, all]' is not part of an expression Am I missing something ? I'm confused about which option if any is required If I use --is-in-hook=landuse I get an invalid option error r Nick On 09/01/2020 11:43, Gerd Petermann wrote:
Hi all,
the branch version r4408 implements the style function is_in with three parameters tag-key,tag-value,method - tag-key can be something like landuse or natural or amenity - tag-value would be the expected value for that tag-key - method has to be "any" or "all".
Example usage in lines: # no cycling within a cemetery highway=* & bicycle!=* & is_in(landuse,cemetery,all) {add bicycle=dismount}
Before any style rule is evaluated the function evaluates the list of all ways found in the input file. When a way matches the given tag (key+value) and is closed and complete the shape geometry is stored in a spatial index. With the current implementation this index is created for appearance of the is_in function in a style rule (subject to optimization)
When the style function is called it retrieves the stored shape(s) which intersect the boundary of the element. If none is found "false" is returned. If there are multiple such shapes the are merged where possible, so that overlapping or touching shapes are combined to a single shape which may include holes. The list of (outer) shapes is then tested one after the other until one shape is found which either contains the element completely or - when "any" is used as method - partially. If none is found the value "false" is returned. If a match is found and the combined shapes have holes, a final test is done to find out if the element is within the hole. If method "any" is used and the shape is completey within one hole "false" is returned. If method "all" is used and the shape is partly within one hole "false" is returned. If we get here true is "returned"
I've also slightly changed the behaviour of the LocationHook and the ResidentialHook. The results should be a bit more predictable now as searches are done with higher precsion. Still, both try to find a nearby boundary(shape) if none is found at the exact position. The ResidentialHook is now automatically disabled when the style doesn't use mkgmap:residential anywhere.
TODO: - various possible special cases need more testing - maybe add more methods for cases where parts of the tested element touch the boundary of the shape. - tuning - unit tests
As always with branch version the binary can be found at the bottom of the download page. http://www.mkgmap.org.uk/download/mkgmap.html
I've tested this with the example file posted before, accept for b18 all cases work as expected.
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
Hi Nick, yes, no extra option needed. Gerd ________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Donnerstag, 9. Januar 2020 14:56 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: [mkgmap-dev] Branch is_in ready for a first test Thanks Gerd That works So no extra --is-in options required? r Nick On 09/01/2020 13:53, Gerd Petermann wrote:
highway=* & bicycle!=* & is_in(landuse,cemetery,all)=true {add bicycle=dismount}
Hi Gerd It works a treat ! Am using it with natural=wood/scrub which now enables me to make the colour of footpaths lighter and easier to see on a gps r Nick On 09/01/2020 13:57, Gerd Petermann wrote:
Hi Nick,
yes, no extra option needed.
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Donnerstag, 9. Januar 2020 14:56 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: [mkgmap-dev] Branch is_in ready for a first test
Thanks Gerd
That works
So no extra --is-in options required?
r
Nick
On 09/01/2020 13:53, Gerd Petermann wrote:
highway=* & bicycle!=* & is_in(landuse,cemetery,all)=true {add bicycle=dismount}
Hi Nick, thanks for the quick feedback :) Interesting use case. Did not even think about this. Means you create overlay lines with different types for the routable way? Gerd ________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Donnerstag, 9. Januar 2020 15:07 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: AW: [mkgmap-dev] Branch is_in ready for a first test Hi Gerd It works a treat ! Am using it with natural=wood/scrub which now enables me to make the colour of footpaths lighter and easier to see on a gps r Nick On 09/01/2020 13:57, Gerd Petermann wrote:
Hi Nick,
yes, no extra option needed.
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Donnerstag, 9. Januar 2020 14:56 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: [mkgmap-dev] Branch is_in ready for a first test
Thanks Gerd
That works
So no extra --is-in options required?
r
Nick
On 09/01/2020 13:53, Gerd Petermann wrote:
highway=* & bicycle!=* & is_in(landuse,cemetery,all)=true {add bicycle=dismount}
Hi Gerd Yes indeed, and also make streams etc lighter, so it opens up a host of new possibilities. Many thanks again for all your ( and Ticker's) hard work! Nick On 09/01/2020 14:21, Gerd Petermann wrote:
Hi Nick,
thanks for the quick feedback :)
Interesting use case. Did not even think about this. Means you create overlay lines with different types for the routable way?
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Donnerstag, 9. Januar 2020 15:07 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: AW: [mkgmap-dev] Branch is_in ready for a first test
Hi Gerd
It works a treat !
Am using it with natural=wood/scrub which now enables me to make the colour of footpaths lighter and easier to see on a gps
r
Nick
On 09/01/2020 13:57, Gerd Petermann wrote:
Hi Nick,
yes, no extra option needed.
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Donnerstag, 9. Januar 2020 14:56 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: [mkgmap-dev] Branch is_in ready for a first test
Thanks Gerd
That works
So no extra --is-in options required?
r
Nick
On 09/01/2020 13:53, Gerd Petermann wrote:
highway=* & bicycle!=* & is_in(landuse,cemetery,all)=true {add bicycle=dismount}
Hi Nick, river in wood polygon is probably a "good" worse case scenario for performance tests ;-) Don't know how it is today, but a few years ago Japan was full of very complex wood MP (> 30.000 nodes) and long waterways... I have no idea yet how that will perform... Gerd ________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Donnerstag, 9. Januar 2020 15:24 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: AW: AW: [mkgmap-dev] Branch is_in ready for a first test Hi Gerd Yes indeed, and also make streams etc lighter, so it opens up a host of new possibilities. Many thanks again for all your ( and Ticker's) hard work! Nick On 09/01/2020 14:21, Gerd Petermann wrote:
Hi Nick,
thanks for the quick feedback :)
Interesting use case. Did not even think about this. Means you create overlay lines with different types for the routable way?
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Donnerstag, 9. Januar 2020 15:07 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: AW: [mkgmap-dev] Branch is_in ready for a first test
Hi Gerd
It works a treat !
Am using it with natural=wood/scrub which now enables me to make the colour of footpaths lighter and easier to see on a gps
r
Nick
On 09/01/2020 13:57, Gerd Petermann wrote:
Hi Nick,
yes, no extra option needed.
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Donnerstag, 9. Januar 2020 14:56 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: [mkgmap-dev] Branch is_in ready for a first test
Thanks Gerd
That works
So no extra --is-in options required?
r
Nick
On 09/01/2020 13:53, Gerd Petermann wrote:
highway=* & bicycle!=* & is_in(landuse,cemetery,all)=true {add bicycle=dismount}
Hi Gerd I had to replace 'all' with 'some' as it very cleverly picked out some small stretches of stream uniquely confined to a wood but it looked odd just to highlight these small waterways. 'some' doesn't do a bad job ! Nick On 09/01/2020 14:30, Gerd Petermann wrote:
Hi Nick,
river in wood polygon is probably a "good" worse case scenario for performance tests ;-) Don't know how it is today, but a few years ago Japan was full of very complex wood MP (> 30.000 nodes) and long waterways... I have no idea yet how that will perform...
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Donnerstag, 9. Januar 2020 15:24 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: AW: AW: [mkgmap-dev] Branch is_in ready for a first test
Hi Gerd
Yes indeed, and also make streams etc lighter, so it opens up a host of new possibilities.
Many thanks again for all your ( and Ticker's) hard work!
Nick
On 09/01/2020 14:21, Gerd Petermann wrote:
Hi Nick,
thanks for the quick feedback :)
Interesting use case. Did not even think about this. Means you create overlay lines with different types for the routable way?
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Donnerstag, 9. Januar 2020 15:07 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: AW: [mkgmap-dev] Branch is_in ready for a first test
Hi Gerd
It works a treat !
Am using it with natural=wood/scrub which now enables me to make the colour of footpaths lighter and easier to see on a gps
r
Nick
On 09/01/2020 13:57, Gerd Petermann wrote:
Hi Nick,
yes, no extra option needed.
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Donnerstag, 9. Januar 2020 14:56 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: [mkgmap-dev] Branch is_in ready for a first test
Thanks Gerd
That works
So no extra --is-in options required?
r
Nick
On 09/01/2020 13:53, Gerd Petermann wrote:
highway=* & bicycle!=* & is_in(landuse,cemetery,all)=true {add bicycle=dismount}
Hi Nick, did you really use some? The code expects either "any" or "all", but doesn't yet check this. Gerd ________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Donnerstag, 9. Januar 2020 15:55 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: AW: AW: AW: [mkgmap-dev] Branch is_in ready for a first test Hi Gerd I had to replace 'all' with 'some' as it very cleverly picked out some small stretches of stream uniquely confined to a wood but it looked odd just to highlight these small waterways. 'some' doesn't do a bad job ! Nick On 09/01/2020 14:30, Gerd Petermann wrote:
Hi Nick,
river in wood polygon is probably a "good" worse case scenario for performance tests ;-) Don't know how it is today, but a few years ago Japan was full of very complex wood MP (> 30.000 nodes) and long waterways... I have no idea yet how that will perform...
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Donnerstag, 9. Januar 2020 15:24 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: AW: AW: [mkgmap-dev] Branch is_in ready for a first test
Hi Gerd
Yes indeed, and also make streams etc lighter, so it opens up a host of new possibilities.
Many thanks again for all your ( and Ticker's) hard work!
Nick
On 09/01/2020 14:21, Gerd Petermann wrote:
Hi Nick,
thanks for the quick feedback :)
Interesting use case. Did not even think about this. Means you create overlay lines with different types for the routable way?
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Donnerstag, 9. Januar 2020 15:07 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: AW: [mkgmap-dev] Branch is_in ready for a first test
Hi Gerd
It works a treat !
Am using it with natural=wood/scrub which now enables me to make the colour of footpaths lighter and easier to see on a gps
r
Nick
On 09/01/2020 13:57, Gerd Petermann wrote:
Hi Nick,
yes, no extra option needed.
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Donnerstag, 9. Januar 2020 14:56 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: [mkgmap-dev] Branch is_in ready for a first test
Thanks Gerd
That works
So no extra --is-in options required?
r
Nick
On 09/01/2020 13:53, Gerd Petermann wrote:
highway=* & bicycle!=* & is_in(landuse,cemetery,all)=true {add bicycle=dismount}
Hi Gerd Yes I did It must have defaulted to 'any' Nick On 09/01/2020 14:58, Gerd Petermann wrote:
Hi Nick,
did you really use some? The code expects either "any" or "all", but doesn't yet check this.
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Donnerstag, 9. Januar 2020 15:55 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: AW: AW: AW: [mkgmap-dev] Branch is_in ready for a first test
Hi Gerd
I had to replace 'all' with 'some' as it very cleverly picked out some small stretches of stream uniquely confined to a wood but it looked odd just to highlight these small waterways.
'some' doesn't do a bad job !
Nick
On 09/01/2020 14:30, Gerd Petermann wrote:
Hi Nick,
river in wood polygon is probably a "good" worse case scenario for performance tests ;-) Don't know how it is today, but a few years ago Japan was full of very complex wood MP (> 30.000 nodes) and long waterways... I have no idea yet how that will perform...
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Donnerstag, 9. Januar 2020 15:24 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: AW: AW: [mkgmap-dev] Branch is_in ready for a first test
Hi Gerd
Yes indeed, and also make streams etc lighter, so it opens up a host of new possibilities.
Many thanks again for all your ( and Ticker's) hard work!
Nick
On 09/01/2020 14:21, Gerd Petermann wrote:
Hi Nick,
thanks for the quick feedback :)
Interesting use case. Did not even think about this. Means you create overlay lines with different types for the routable way?
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Donnerstag, 9. Januar 2020 15:07 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: AW: [mkgmap-dev] Branch is_in ready for a first test
Hi Gerd
It works a treat !
Am using it with natural=wood/scrub which now enables me to make the colour of footpaths lighter and easier to see on a gps
r
Nick
On 09/01/2020 13:57, Gerd Petermann wrote:
Hi Nick,
yes, no extra option needed.
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Donnerstag, 9. Januar 2020 14:56 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: [mkgmap-dev] Branch is_in ready for a first test
Thanks Gerd
That works
So no extra --is-in options required?
r
Nick
On 09/01/2020 13:53, Gerd Petermann wrote:
highway=* & bicycle!=* & is_in(landuse,cemetery,all)=true {add bicycle=dismount}
Hi Nick, yes and no. With r4008 the result is probably the same but performance can be worse compared to 'any' as the algorithm doesn't stop early. The code contains e.g. if (statusFirst == Status.IN && "any".equals(mode)) return true; which means "if the first point of the way is in we can return true" without checking any further. I did not yet add checks regarding the correctness of the method parameter because they might change again. Will do this now. Gerd ________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Donnerstag, 9. Januar 2020 15:59 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: AW: AW: AW: AW: [mkgmap-dev] Branch is_in ready for a first test Hi Gerd Yes I did It must have defaulted to 'any' Nick On 09/01/2020 14:58, Gerd Petermann wrote:
Hi Nick,
did you really use some? The code expects either "any" or "all", but doesn't yet check this.
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Donnerstag, 9. Januar 2020 15:55 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: AW: AW: AW: [mkgmap-dev] Branch is_in ready for a first test
Hi Gerd
I had to replace 'all' with 'some' as it very cleverly picked out some small stretches of stream uniquely confined to a wood but it looked odd just to highlight these small waterways.
'some' doesn't do a bad job !
Nick
On 09/01/2020 14:30, Gerd Petermann wrote:
Hi Nick,
river in wood polygon is probably a "good" worse case scenario for performance tests ;-) Don't know how it is today, but a few years ago Japan was full of very complex wood MP (> 30.000 nodes) and long waterways... I have no idea yet how that will perform...
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Donnerstag, 9. Januar 2020 15:24 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: AW: AW: [mkgmap-dev] Branch is_in ready for a first test
Hi Gerd
Yes indeed, and also make streams etc lighter, so it opens up a host of new possibilities.
Many thanks again for all your ( and Ticker's) hard work!
Nick
On 09/01/2020 14:21, Gerd Petermann wrote:
Hi Nick,
thanks for the quick feedback :)
Interesting use case. Did not even think about this. Means you create overlay lines with different types for the routable way?
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Donnerstag, 9. Januar 2020 15:07 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: AW: [mkgmap-dev] Branch is_in ready for a first test
Hi Gerd
It works a treat !
Am using it with natural=wood/scrub which now enables me to make the colour of footpaths lighter and easier to see on a gps
r
Nick
On 09/01/2020 13:57, Gerd Petermann wrote:
Hi Nick,
yes, no extra option needed.
Gerd
________________________________________ Von: Pinns UK <osm@pinns.co.uk> Gesendet: Donnerstag, 9. Januar 2020 14:56 An: Gerd Petermann; mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: AW: [mkgmap-dev] Branch is_in ready for a first test
Thanks Gerd
That works
So no extra --is-in options required?
r
Nick
On 09/01/2020 13:53, Gerd Petermann wrote:
highway=* & bicycle!=* & is_in(landuse,cemetery,all)=true {add bicycle=dismount}
Hi Gerd I think the logic still needs to know if it is handling a closed way as a polygon rule or as a line rule. Firstly to be able to correctly handle the case where the rule.way runs around a hole in the target.polygon - all of the rule.line is in the target, but only part of the rule.polygon is in the target. Also there might be different method keywords for the two. For polygon rules, "any" and "all" are adequate, but for line rules others might be required. I've just svn updated the is_in branch. Is there still work to do on non-closed ways? Otherwise amazing. Ticker On Thu, 2020-01-09 at 11:43 +0000, Gerd Petermann wrote:
Hi all,
the branch version r4408 implements the style function is_in with three parameters tag-key,tag-value,method - tag-key can be something like landuse or natural or amenity - tag-value would be the expected value for that tag-key - method has to be "any" or "all".
Example usage in lines: # no cycling within a cemetery highway=* & bicycle!=* & is_in(landuse,cemetery,all) {add bicycle=dismount}
Before any style rule is evaluated the function evaluates the list of all ways found in the input file. When a way matches the given tag (key+value) and is closed and complete the shape geometry is stored in a spatial index. With the current implementation this index is created for appearance of the is_in function in a style rule (subject to optimization)
When the style function is called it retrieves the stored shape(s) which intersect the boundary of the element. If none is found "false" is returned. If there are multiple such shapes the are merged where possible, so that overlapping or touching shapes are combined to a single shape which may include holes. The list of (outer) shapes is then tested one after the other until one shape is found which either contains the element completely or - when "any" is used as method - partially. If none is found the value "false" is returned. If a match is found and the combined shapes have holes, a final test is done to find out if the element is within the hole. If method "any" is used and the shape is completey within one hole "false" is returned. If method "all" is used and the shape is partly within one hole "false" is returned. If we get here true is "returned"
I've also slightly changed the behaviour of the LocationHook and the ResidentialHook. The results should be a bit more predictable now as searches are done with higher precsion. Still, both try to find a nearby boundary(shape) if none is found at the exact position. The ResidentialHook is now automatically disabled when the style doesn't use mkgmap:residential anywhere.
TODO: - various possible special cases need more testing - maybe add more methods for cases where parts of the tested element touch the boundary of the shape. - tuning - unit tests
As always with branch version the binary can be found at the bottom of the download page. http://www.mkgmap.org.uk/download/mkgmap.html
I've tested this with the example file posted before, accept for b18 all cases work as expected.
Gerd _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ticker, yes, it would probably be better to know if the function is for a polyline or polygon. A patch would be welcomed. And yes, the expected result for the case you describe is not yet clear. See b13 and b14 in my example file. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 10. Januar 2020 09:59 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test Hi Gerd I think the logic still needs to know if it is handling a closed way as a polygon rule or as a line rule. Firstly to be able to correctly handle the case where the rule.way runs around a hole in the target.polygon - all of the rule.line is in the target, but only part of the rule.polygon is in the target. Also there might be different method keywords for the two. For polygon rules, "any" and "all" are adequate, but for line rules others might be required. I've just svn updated the is_in branch. Is there still work to do on non-closed ways? Otherwise amazing. Ticker On Thu, 2020-01-09 at 11:43 +0000, Gerd Petermann wrote:
Hi all,
the branch version r4408 implements the style function is_in with three parameters tag-key,tag-value,method - tag-key can be something like landuse or natural or amenity - tag-value would be the expected value for that tag-key - method has to be "any" or "all".
Example usage in lines: # no cycling within a cemetery highway=* & bicycle!=* & is_in(landuse,cemetery,all) {add bicycle=dismount}
Before any style rule is evaluated the function evaluates the list of all ways found in the input file. When a way matches the given tag (key+value) and is closed and complete the shape geometry is stored in a spatial index. With the current implementation this index is created for appearance of the is_in function in a style rule (subject to optimization)
When the style function is called it retrieves the stored shape(s) which intersect the boundary of the element. If none is found "false" is returned. If there are multiple such shapes the are merged where possible, so that overlapping or touching shapes are combined to a single shape which may include holes. The list of (outer) shapes is then tested one after the other until one shape is found which either contains the element completely or - when "any" is used as method - partially. If none is found the value "false" is returned. If a match is found and the combined shapes have holes, a final test is done to find out if the element is within the hole. If method "any" is used and the shape is completey within one hole "false" is returned. If method "all" is used and the shape is partly within one hole "false" is returned. If we get here true is "returned"
I've also slightly changed the behaviour of the LocationHook and the ResidentialHook. The results should be a bit more predictable now as searches are done with higher precsion. Still, both try to find a nearby boundary(shape) if none is found at the exact position. The ResidentialHook is now automatically disabled when the style doesn't use mkgmap:residential anywhere.
TODO: - various possible special cases need more testing - maybe add more methods for cases where parts of the tested element touch the boundary of the shape. - tuning - unit tests
As always with branch version the binary can be found at the bottom of the download page. http://www.mkgmap.org.uk/download/mkgmap.html
I've tested this with the example file posted before, accept for b18 all cases work as expected.
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
Hi Gerd Here is patch that sets isLineRule in the package on the augmentsWith call. I've also used default method for the augmentsWith... in Rule, Op, OsmConverter and backed out the changes that have now become unnecessary. Ticker On Fri, 2020-01-10 at 09:15 +0000, Gerd Petermann wrote:
Hi Ticker,
yes, it would probably be better to know if the function is for a polyline or polygon. A patch would be welcomed. And yes, the expected result for the case you describe is not yet clear. See b13 and b14 in my example file.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 10. Januar 2020 09:59 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test
Hi Gerd
I think the logic still needs to know if it is handling a closed way as a polygon rule or as a line rule.
Firstly to be able to correctly handle the case where the rule.way runs around a hole in the target.polygon - all of the rule.line is in the target, but only part of the rule.polygon is in the target.
Also there might be different method keywords for the two. For polygon rules, "any" and "all" are adequate, but for line rules others might be required.
I've just svn updated the is_in branch. Is there still work to do on non-closed ways?
Otherwise amazing.
Ticker
On Thu, 2020-01-09 at 11:43 +0000, Gerd Petermann wrote:
Hi all,
the branch version r4408 implements the style function is_in with three parameters tag-key,tag-value,method - tag-key can be something like landuse or natural or amenity - tag-value would be the expected value for that tag-key - method has to be "any" or "all".
Example usage in lines: # no cycling within a cemetery highway=* & bicycle!=* & is_in(landuse,cemetery,all) {add bicycle=dismount}
Before any style rule is evaluated the function evaluates the list of all ways found in the input file. When a way matches the given tag (key+value) and is closed and complete the shape geometry is stored in a spatial index. With the current implementation this index is created for appearance of the is_in function in a style rule (subject to optimization)
When the style function is called it retrieves the stored shape(s) which intersect the boundary of the element. If none is found "false" is returned. If there are multiple such shapes the are merged where possible, so that overlapping or touching shapes are combined to a single shape which may include holes. The list of (outer) shapes is then tested one after the other until one shape is found which either contains the element completely or - when "any" is used as method - partially. If none is found the value "false" is returned. If a match is found and the combined shapes have holes, a final test is done to find out if the element is within the hole. If method "any" is used and the shape is completey within one hole "false" is returned. If method "all" is used and the shape is partly within one hole "false" is returned. If we get here true is "returned"
I've also slightly changed the behaviour of the LocationHook and the ResidentialHook. The results should be a bit more predictable now as searches are done with higher precsion. Still, both try to find a nearby boundary(shape) if none is found at the exact position. The ResidentialHook is now automatically disabled when the style doesn't use mkgmap:residential anywhere.
TODO: - various possible special cases need more testing - maybe add more methods for cases where parts of the tested element touch the boundary of the shape. - tuning - unit tests
As always with branch version the binary can be found at the bottom of the download page. http://www.mkgmap.org.uk/download/mkgmap.html
I've tested this with the example file posted before, accept for b18 all cases work as expected.
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
Hi Ticker, thanks, see r4412 : http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4412 Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 10. Januar 2020 11:29 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test Hi Gerd Here is patch that sets isLineRule in the package on the augmentsWith call. I've also used default method for the augmentsWith... in Rule, Op, OsmConverter and backed out the changes that have now become unnecessary. Ticker On Fri, 2020-01-10 at 09:15 +0000, Gerd Petermann wrote:
Hi Ticker,
yes, it would probably be better to know if the function is for a polyline or polygon. A patch would be welcomed. And yes, the expected result for the case you describe is not yet clear. See b13 and b14 in my example file.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Freitag, 10. Januar 2020 09:59 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test
Hi Gerd
I think the logic still needs to know if it is handling a closed way as a polygon rule or as a line rule.
Firstly to be able to correctly handle the case where the rule.way runs around a hole in the target.polygon - all of the rule.line is in the target, but only part of the rule.polygon is in the target.
Also there might be different method keywords for the two. For polygon rules, "any" and "all" are adequate, but for line rules others might be required.
I've just svn updated the is_in branch. Is there still work to do on non-closed ways?
Otherwise amazing.
Ticker
On Thu, 2020-01-09 at 11:43 +0000, Gerd Petermann wrote:
Hi all,
the branch version r4408 implements the style function is_in with three parameters tag-key,tag-value,method - tag-key can be something like landuse or natural or amenity - tag-value would be the expected value for that tag-key - method has to be "any" or "all".
Example usage in lines: # no cycling within a cemetery highway=* & bicycle!=* & is_in(landuse,cemetery,all) {add bicycle=dismount}
Before any style rule is evaluated the function evaluates the list of all ways found in the input file. When a way matches the given tag (key+value) and is closed and complete the shape geometry is stored in a spatial index. With the current implementation this index is created for appearance of the is_in function in a style rule (subject to optimization)
When the style function is called it retrieves the stored shape(s) which intersect the boundary of the element. If none is found "false" is returned. If there are multiple such shapes the are merged where possible, so that overlapping or touching shapes are combined to a single shape which may include holes. The list of (outer) shapes is then tested one after the other until one shape is found which either contains the element completely or - when "any" is used as method - partially. If none is found the value "false" is returned. If a match is found and the combined shapes have holes, a final test is done to find out if the element is within the hole. If method "any" is used and the shape is completey within one hole "false" is returned. If method "all" is used and the shape is partly within one hole "false" is returned. If we get here true is "returned"
I've also slightly changed the behaviour of the LocationHook and the ResidentialHook. The results should be a bit more predictable now as searches are done with higher precsion. Still, both try to find a nearby boundary(shape) if none is found at the exact position. The ResidentialHook is now automatically disabled when the style doesn't use mkgmap:residential anywhere.
TODO: - various possible special cases need more testing - maybe add more methods for cases where parts of the tested element touch the boundary of the shape. - tuning - unit tests
As always with branch version the binary can be found at the bottom of the download page. http://www.mkgmap.org.uk/download/mkgmap.html
I've tested this with the example file posted before, accept for b18 all cases work as expected.
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
Hi all, the message "SCHWERWIEGEND (IsInFunction): .\Baustelle\Speiche_Kanaren_Splitter\88002007.osm.pbf: rounding error? first point is on line but status of first point is not ON" was produced for this node: https://www.openstreetmap.org/node/640552250#map=18/28.14036/-16.52529 The node is extremely close to the landuse=residential way 255452457. In OSM precision the node is inside the residential area, but in mkgmap precision it is outside. These special cases really cause trouble. To improve performance, the code first tests the result for the first point. If this result is IN and method is 'any' or when result is OUT and method is 'all' there should be no need to test any further nodes or edges, thus the corresponding result is returned. Now, with these special cases the quick result may be wrong. With r4116 I've disabled the quick test. The result is more likely to be correct but performance can be poor when complex areas are involved. For normal cases the difference should be small, maybe a second per tile. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Arndt Röhrig <arndt@speichenkarte.de> Gesendet: Samstag, 11. Januar 2020 12:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test Good morning, so far i used "mkgmap:residential" to draw some highways thinner in citys. I replaced it with the is_in function and added some other polys like "school", "industrial" etc. It works fine, great. I added also a "bicycle=no" on "cemetarys", "schools", "landfills", "quarry" etc. Thank you all for this work! Problem #1: is_in(landuse,residential,any)=true will not work in "Wuppertal". mkmap:residential also no work there either. I suspect the reason in the osm-data, but i don´t see why. Have anybody an idea? https://fotos.rennrad-news.de/f3/4/494/494184-sm3yb9gt4tjr-test-medium.png Problem, #2: r-4412 report: SCHWERWIEGEND (IsInFunction): .\Baustelle\Speiche_Kanaren_Splitter\88002007.osm.pbf: rounding error? first point is on line but status of first point is not ON https://speichenkarte.de/88002007.osm.pbf greetings Arndt Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> hat am 10. Januar 2020 um 12:07 geschrieben: Hi Ticker, thanks, see r4412 : http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4412 Gerd ________________________________________ Von: mkgmap-dev < mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Ticker Berkin < rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>> Gesendet: Freitag, 10. Januar 2020 11:29 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test Hi Gerd Here is patch that sets isLineRule in the package on the augmentsWith call. I've also used default method for the augmentsWith... in Rule, Op, OsmConverter and backed out the changes that have now become unnecessary. Ticker On Fri, 2020-01-10 at 09:15 +0000, Gerd Petermann wrote: Hi Ticker, yes, it would probably be better to know if the function is for a polyline or polygon. A patch would be welcomed. And yes, the expected result for the case you describe is not yet clear. See b13 and b14 in my example file. Gerd ________________________________________ Von: mkgmap-dev < mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Ticker Berkin < rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk>> Gesendet: Freitag, 10. Januar 2020 09:59 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test Hi Gerd I think the logic still needs to know if it is handling a closed way as a polygon rule or as a line rule. Firstly to be able to correctly handle the case where the rule.way runs around a hole in the target.polygon - all of the rule.line is in the target, but only part of the rule.polygon is in the target. Also there might be different method keywords for the two. For polygon rules, "any" and "all" are adequate, but for line rules others might be required. I've just svn updated the is_in branch. Is there still work to do on non-closed ways? Otherwise amazing. Ticker On Thu, 2020-01-09 at 11:43 +0000, Gerd Petermann wrote: Hi all, the branch version r4408 implements the style function is_in with three parameters tag-key,tag-value,method - tag-key can be something like landuse or natural or amenity - tag-value would be the expected value for that tag-key - method has to be "any" or "all". Example usage in lines: # no cycling within a cemetery highway=* & bicycle!=* & is_in(landuse,cemetery,all) {add bicycle=dismount} Before any style rule is evaluated the function evaluates the list of all ways found in the input file. When a way matches the given tag (key+value) and is closed and complete the shape geometry is stored in a spatial index. With the current implementation this index is created for appearance of the is_in function in a style rule (subject to optimization) When the style function is called it retrieves the stored shape(s) which intersect the boundary of the element. If none is found "false" is returned. If there are multiple such shapes the are merged where possible, so that overlapping or touching shapes are combined to a single shape which may include holes. The list of (outer) shapes is then tested one after the other until one shape is found which either contains the element completely or - when "any" is used as method - partially. If none is found the value "false" is returned. If a match is found and the combined shapes have holes, a final test is done to find out if the element is within the hole. If method "any" is used and the shape is completey within one hole "false" is returned. If method "all" is used and the shape is partly within one hole "false" is returned. If we get here true is "returned" I've also slightly changed the behaviour of the LocationHook and the ResidentialHook. The results should be a bit more predictable now as searches are done with higher precsion. Still, both try to find a nearby boundary(shape) if none is found at the exact position. The ResidentialHook is now automatically disabled when the style doesn't use mkgmap:residential anywhere. TODO: - various possible special cases need more testing - maybe add more methods for cases where parts of the tested element touch the boundary of the shape. - tuning - unit tests As always with branch version the binary can be found at the bottom of the download page. http://www.mkgmap.org.uk/download/mkgmap.html I've tested this with the example file posted before, accept for b18 all cases work as expected. Gerd _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto: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<mailto: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<mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, hi Ticker, sorry for the delay, until the weekend I didn´t found time to test the new versions. I´m very impressed, my results now are so precise that I could revert all the gaps I created for the first hook. Many thanks for all your efforts to realize this accuracy! Still I´m only on lines inside cemetery/allotments, so I have no clue about the buildings in v4 samples, sorry. I check for „all“ and for „any“, giving two new values and then reduce them to one if another match, ie: highway=* & ... & is_in(landuse,allotments,all)=true {add isin=1} highway=* & ... & is_in(landuse,allotments,any)=true {add isin=2} highway=* & isin=1 {set highway=path} highway=* & isin=2 bicyle=no {set highway=path} That works as I expect: reduce all-in, and any-in only if specified. I didn´t understood yet : could ON still be a value to ask for, beside IN and OUT? Or has it become obsolete? In anyway, with my rule above I see no complaint about it. Only one unclear example so far I found - probably caused by the multipolygon? The first line is not matched by the any-rule, but the second is. Both should match according to style: https://www.openstreetmap.org/way/117416117 https://www.openstreetmap.org/way/117416120 As said, only one. With is_in render time is increased by only 5-10%, pretty cheap. Thanks to all for the ideas read here how to play with this wonderful new option. Jan
Am 12.01.2020 um 09:58 schrieb Gerd Petermann <gpetermann_muenchen@hotmail.com>:
Hi all,
the message "SCHWERWIEGEND (IsInFunction): .\Baustelle\Speiche_Kanaren_Splitter\88002007.osm.pbf: rounding error? first point is on line but status of first point is not ON" was produced for this node: https://www.openstreetmap.org/node/640552250#map=18/28.14036/-16.52529 <https://www.openstreetmap.org/node/640552250#map=18/28.14036/-16.52529>
The node is extremely close to the landuse=residential way 255452457. In OSM precision the node is inside the residential area, but in mkgmap precision it is outside. These special cases really cause trouble. To improve performance, the code first tests the result for the first point. If this result is IN and method is 'any' or when result is OUT and method is 'all' there should be no need to test any further nodes or edges, thus the corresponding result is returned. Now, with these special cases the quick result may be wrong. With r4116 I've disabled the quick test. The result is more likely to be correct but performance can be poor when complex areas are involved.
For normal cases the difference should be small, maybe a second per tile.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk <mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Arndt Röhrig <arndt@speichenkarte.de <mailto:arndt@speichenkarte.de>> Gesendet: Samstag, 11. Januar 2020 12:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test
Good morning,
so far i used "mkgmap:residential" to draw some highways thinner in citys. I replaced it with the is_in function and added some other polys like "school", "industrial" etc. It works fine, great.
I added also a "bicycle=no" on "cemetarys", "schools", "landfills", "quarry" etc.
Thank you all for this work!
Problem #1: is_in(landuse,residential,any)=true will not work in "Wuppertal". mkmap:residential also no work there either. I suspect the reason in the osm-data, but i don´t see why. Have anybody an idea? https://fotos.rennrad-news.de/f3/4/494/494184-sm3yb9gt4tjr-test-medium.png
Problem, #2: r-4412 report: SCHWERWIEGEND (IsInFunction): .\Baustelle\Speiche_Kanaren_Splitter\88002007.osm.pbf: rounding error? first point is on line but status of first point is not ON https://speichenkarte.de/88002007.osm.pbf
greetings
Arndt
Gerd Petermann < gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>>> hat am 10. Januar 2020 um 12:07 geschrieben:
Hi Ticker,
thanks, see r4412 : http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4412 <http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4412>
Gerd
________________________________________ Von: mkgmap-dev < mkgmap-dev-bounces@lists.mkgmap.org.uk <mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk <mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Ticker Berkin < rwb-mkgmap@jagit.co.uk <mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk <mailto:rwb-mkgmap@jagit.co.uk>>> Gesendet: Freitag, 10. Januar 2020 11:29 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test
Hi Gerd
Here is patch that sets isLineRule in the package on the augmentsWith call.
I've also used default method for the augmentsWith... in Rule, Op, OsmConverter and backed out the changes that have now become unnecessary.
Ticker
On Fri, 2020-01-10 at 09:15 +0000, Gerd Petermann wrote: Hi Ticker, yes, it would probably be better to know if the function is for a polyline or polygon. A patch would be welcomed. And yes, the expected result for the case you describe is not yet clear. See b13 and b14 in my example file. Gerd ________________________________________ Von: mkgmap-dev < mkgmap-dev-bounces@lists.mkgmap.org.uk <mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk <mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Ticker Berkin < rwb-mkgmap@jagit.co.uk <mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk <mailto:rwb-mkgmap@jagit.co.uk>>> Gesendet: Freitag, 10. Januar 2020 09:59 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test Hi Gerd I think the logic still needs to know if it is handling a closed way as a polygon rule or as a line rule. Firstly to be able to correctly handle the case where the rule.way runs around a hole in the target.polygon - all of the rule.line is in the target, but only part of the rule.polygon is in the target. Also there might be different method keywords for the two. For polygon rules, "any" and "all" are adequate, but for line rules others might be required. I've just svn updated the is_in branch. Is there still work to do on non-closed ways? Otherwise amazing. Ticker On Thu, 2020-01-09 at 11:43 +0000, Gerd Petermann wrote: Hi all, the branch version r4408 implements the style function is_in with three parameters tag-key,tag-value,method - tag-key can be something like landuse or natural or amenity - tag-value would be the expected value for that tag-key - method has to be "any" or "all". Example usage in lines: # no cycling within a cemetery highway=* & bicycle!=* & is_in(landuse,cemetery,all) {add bicycle=dismount} Before any style rule is evaluated the function evaluates the list of all ways found in the input file. When a way matches the given tag (key+value) and is closed and complete the shape geometry is stored in a spatial index. With the current implementation this index is created for appearance of the is_in function in a style rule (subject to optimization) When the style function is called it retrieves the stored shape(s) which intersect the boundary of the element. If none is found "false" is returned. If there are multiple such shapes the are merged where possible, so that overlapping or touching shapes are combined to a single shape which may include holes. The list of (outer) shapes is then tested one after the other until one shape is found which either contains the element completely or - when "any" is used as method - partially. If none is found the value "false" is returned. If a match is found and the combined shapes have holes, a final test is done to find out if the element is within the hole. If method "any" is used and the shape is completey within one hole "false" is returned. If method "all" is used and the shape is partly within one hole "false" is returned. If we get here true is "returned" I've also slightly changed the behaviour of the LocationHook and the ResidentialHook. The results should be a bit more predictable now as searches are done with higher precsion. Still, both try to find a nearby boundary(shape) if none is found at the exact position. The ResidentialHook is now automatically disabled when the style doesn't use mkgmap:residential anywhere. TODO: - various possible special cases need more testing - maybe add more methods for cases where parts of the tested element touch the boundary of the shape. - tuning - unit tests As always with branch version the binary can be found at the bottom of the download page. http://www.mkgmap.org.uk/download/mkgmap.html <http://www.mkgmap.org.uk/download/mkgmap.html> I've tested this with the example file posted before, accept for b18 all cases work as expected. Gerd _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev <http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev> _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev <http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev> _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev <http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev> _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev <http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev>
Hi Jan, thanks for testing. Reg. the ways: Yes, that's an error. I'll have a look at it. Reg. your rules: I would add the clause & isin!=* in the 2nd rule to avoid a 2nd execution of the is_in function. Reg. ON: The current implementation of is_in accepts only 'all' or 'any'. I think we can also detect the cases 2 and 3 on Tickers list (1) but I didn't like the suggested method 'all-on' in combination with the function name is_in and I did not yet find a better alternative. An alternative I was thinking about is to implement a 'details' option which might return one of the values in Tickers list. We just have to define values for points and polygons, as Tickers list is only for rules in lines. Gerd (1) http://gis.19327.n8.nabble.com/Test-cases-for-possible-is-in-hook-tp5954103p... ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@gmx.net> Gesendet: Dienstag, 14. Januar 2020 23:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test Hi Gerd, hi Ticker, sorry for the delay, until the weekend I didn´t found time to test the new versions. I´m very impressed, my results now are so precise that I could revert all the gaps I created for the first hook. Many thanks for all your efforts to realize this accuracy! Still I´m only on lines inside cemetery/allotments, so I have no clue about the buildings in v4 samples, sorry. I check for „all“ and for „any“, giving two new values and then reduce them to one if another match, ie: highway=* & ... & is_in(landuse,allotments,all)=true {add isin=1} highway=* & ... & is_in(landuse,allotments,any)=true {add isin=2} highway=* & isin=1 {set highway=path} highway=* & isin=2 bicyle=no {set highway=path} That works as I expect: reduce all-in, and any-in only if specified. I didn´t understood yet : could ON still be a value to ask for, beside IN and OUT? Or has it become obsolete? In anyway, with my rule above I see no complaint about it. Only one unclear example so far I found - probably caused by the multipolygon? The first line is not matched by the any-rule, but the second is. Both should match according to style: https://www.openstreetmap.org/way/117416117 https://www.openstreetmap.org/way/117416120 As said, only one. With is_in render time is increased by only 5-10%, pretty cheap. Thanks to all for the ideas read here how to play with this wonderful new option. Jan Am 12.01.2020 um 09:58 schrieb Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>>: Hi all, the message "SCHWERWIEGEND (IsInFunction): .\Baustelle\Speiche_Kanaren_Splitter\88002007.osm.pbf: rounding error? first point is on line but status of first point is not ON" was produced for this node: https://www.openstreetmap.org/node/640552250#map=18/28.14036/-16.52529 The node is extremely close to the landuse=residential way 255452457. In OSM precision the node is inside the residential area, but in mkgmap precision it is outside. These special cases really cause trouble. To improve performance, the code first tests the result for the first point. If this result is IN and method is 'any' or when result is OUT and method is 'all' there should be no need to test any further nodes or edges, thus the corresponding result is returned. Now, with these special cases the quick result may be wrong. With r4116 I've disabled the quick test. The result is more likely to be correct but performance can be poor when complex areas are involved. For normal cases the difference should be small, maybe a second per tile. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Arndt Röhrig <arndt@speichenkarte.de<mailto:arndt@speichenkarte.de>> Gesendet: Samstag, 11. Januar 2020 12:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test Good morning, so far i used "mkgmap:residential" to draw some highways thinner in citys. I replaced it with the is_in function and added some other polys like "school", "industrial" etc. It works fine, great. I added also a "bicycle=no" on "cemetarys", "schools", "landfills", "quarry" etc. Thank you all for this work! Problem #1: is_in(landuse,residential,any)=true will not work in "Wuppertal". mkmap:residential also no work there either. I suspect the reason in the osm-data, but i don´t see why. Have anybody an idea? https://fotos.rennrad-news.de/f3/4/494/494184-sm3yb9gt4tjr-test-medium.png Problem, #2: r-4412 report: SCHWERWIEGEND (IsInFunction): .\Baustelle\Speiche_Kanaren_Splitter\88002007.osm.pbf: rounding error? first point is on line but status of first point is not ON https://speichenkarte.de/88002007.osm.pbf greetings Arndt Gerd Petermann < gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com>> hat am 10. Januar 2020 um 12:07 geschrieben: Hi Ticker, thanks, see r4412 : http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4412 Gerd ________________________________________ Von: mkgmap-dev < mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Ticker Berkin < rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk>> Gesendet: Freitag, 10. Januar 2020 11:29 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test Hi Gerd Here is patch that sets isLineRule in the package on the augmentsWith call. I've also used default method for the augmentsWith... in Rule, Op, OsmConverter and backed out the changes that have now become unnecessary. Ticker On Fri, 2020-01-10 at 09:15 +0000, Gerd Petermann wrote: Hi Ticker, yes, it would probably be better to know if the function is for a polyline or polygon. A patch would be welcomed. And yes, the expected result for the case you describe is not yet clear. See b13 and b14 in my example file. Gerd ________________________________________ Von: mkgmap-dev < mkgmap-dev-bounces@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Ticker Berkin < rwb-mkgmap@jagit.co.uk<mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk>> Gesendet: Freitag, 10. Januar 2020 09:59 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test Hi Gerd I think the logic still needs to know if it is handling a closed way as a polygon rule or as a line rule. Firstly to be able to correctly handle the case where the rule.way runs around a hole in the target.polygon - all of the rule.line is in the target, but only part of the rule.polygon is in the target. Also there might be different method keywords for the two. For polygon rules, "any" and "all" are adequate, but for line rules others might be required. I've just svn updated the is_in branch. Is there still work to do on non-closed ways? Otherwise amazing. Ticker On Thu, 2020-01-09 at 11:43 +0000, Gerd Petermann wrote: Hi all, the branch version r4408 implements the style function is_in with three parameters tag-key,tag-value,method - tag-key can be something like landuse or natural or amenity - tag-value would be the expected value for that tag-key - method has to be "any" or "all". Example usage in lines: # no cycling within a cemetery highway=* & bicycle!=* & is_in(landuse,cemetery,all) {add bicycle=dismount} Before any style rule is evaluated the function evaluates the list of all ways found in the input file. When a way matches the given tag (key+value) and is closed and complete the shape geometry is stored in a spatial index. With the current implementation this index is created for appearance of the is_in function in a style rule (subject to optimization) When the style function is called it retrieves the stored shape(s) which intersect the boundary of the element. If none is found "false" is returned. If there are multiple such shapes the are merged where possible, so that overlapping or touching shapes are combined to a single shape which may include holes. The list of (outer) shapes is then tested one after the other until one shape is found which either contains the element completely or - when "any" is used as method - partially. If none is found the value "false" is returned. If a match is found and the combined shapes have holes, a final test is done to find out if the element is within the hole. If method "any" is used and the shape is completey within one hole "false" is returned. If method "all" is used and the shape is partly within one hole "false" is returned. If we get here true is "returned" I've also slightly changed the behaviour of the LocationHook and the ResidentialHook. The results should be a bit more predictable now as searches are done with higher precsion. Still, both try to find a nearby boundary(shape) if none is found at the exact position. The ResidentialHook is now automatically disabled when the style doesn't use mkgmap:residential anywhere. TODO: - various possible special cases need more testing - maybe add more methods for cases where parts of the tested element touch the boundary of the shape. - tuning - unit tests As always with branch version the binary can be found at the bottom of the download page. http://www.mkgmap.org.uk/download/mkgmap.html I've tested this with the example file posted before, accept for b18 all cases work as expected. Gerd _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: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<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: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<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: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<mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi My earlier postings were to get an idea of what was wanted regarding combinations of IN/ON/OUT for 'lines' and also what was reasonable to implement. I didn't like some of the method keywords that I had suggested either. The advantages of the keyword, even if ugly/unwieldy, to say what is wanted for the different 'line' cases, over a 'details' option are that: - for many methods, optimisation is possible (ie can stop early, handle the target polygons one-by-one, etc) - the result of the 'details' would probably have to be some ugly composite string, maybe requiring a regex test to decipher. My summary: For 'polygons', methods 'all' and 'any' cover the requirements. 'points' hasn't been discussed. Are methods for IN, IN or ON, ON needed? If so, what keywords to use; 'any' and 'all' are wrong... 'lines', as per 04-Jan posting with Jan's alternative. a) some-in-none-out IN and not OUT b) all-in-or-on (IN or ON) and not OUT c) all-on ON and not (OUT or IN) d) any-in IN e) any-in-or-on IN or ON So, are all cases required and what keywords to use? 'all' could be used for a) or b), but with the function being called is -in, it would more naturally apply to a). Likewise 'any' for d) rather than e). Ticker On Wed, 2020-01-15 at 06:38 +0000, Gerd Petermann wrote:
Hi Jan,
thanks for testing. Reg. the ways: Yes, that's an error. I'll have a look at it. Reg. your rules: I would add the clause & isin!=* in the 2nd rule to avoid a 2nd execution of the is_in function. Reg. ON: The current implementation of is_in accepts only 'all' or 'any'. I think we can also detect the cases 2 and 3 on Tickers list (1) but I didn't like the suggested method 'all-on' in combination with the function name is_in and I did not yet find a better alternative. An alternative I was thinking about is to implement a 'details' option which might return one of the values in Tickers list. We just have to define values for points and polygons, as Tickers list is only for rules in lines.
Gerd (1) http://gis.19327.n8.nabble.com/Test-cases-for-possible-is-in-hook -tp5954103p5954828.html
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@gmx.net> Gesendet: Dienstag, 14. Januar 2020 23:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test
Hi Gerd, hi Ticker,
sorry for the delay, until the weekend I didn´t found time to test the new versions.
I´m very impressed, my results now are so precise that I could revert all the gaps I created for the first hook. Many thanks for all your efforts to realize this accuracy!
Still I´m only on lines inside cemetery/allotments, so I have no clue about the buildings in v4 samples, sorry.
I check for „all“ and for „any“, giving two new values and then reduce them to one if another match, ie: highway=* & ... & is_in(landuse,allotments,all)=true {add isin=1} highway=* & ... & is_in(landuse,allotments,any)=true {add isin=2} highway=* & isin=1 {set highway=path} highway=* & isin=2 bicyle=no {set highway=path}
That works as I expect: reduce all-in, and any-in only if specified. I didn´t understood yet : could ON still be a value to ask for, beside IN and OUT? Or has it become obsolete? In anyway, with my rule above I see no complaint about it.
Only one unclear example so far I found - probably caused by the multipolygon? The first line is not matched by the any-rule, but the second is. Both should match according to style: https://www.openstreetmap.org/way/117416117 https://www.openstreetmap.org/way/117416120
As said, only one. With is_in render time is increased by only 5-10%, pretty cheap. Thanks to all for the ideas read here how to play with this wonderful new option.
Jan
Hi all, For a single point we can compute 'inside', 'on boundary', or 'outside'. reg. the results and the method options I thought about a very different alternative: Instead of true or false the function might return a bit string containing three digits, e.g. 001 - 1st (leftmost) bit 0 means "no point inside found", 1 means "at least one point inside found" - 2nd bit 0 means "no point on boundary found", 1 means "at least one point on boundary found" - 3rd bit 0 means "no point outside found", 1 means "at least one point outside" found We can describe 2^3 combinations with that, but obviously the combinations 000 and 101 are impossible, so we have the 6 cases on Tickers list as 1: all of the line is outside the polygon -> 001 2: some of the line is outside and the rest touches or runs along the polygon edge -> 011 3: all of the line runs along the polygon edge -> 010 4: some of the line is inside and the rest touches or runs along -> 110 5: all of the line is inside the polygon 100 6: some is inside and some outside the polygon. Obviously some point is on -> 111 This would allow to remove the 3rd parameter, but user has to remember the order of the bits when writing the style rules. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 16. Januar 2020 10:48 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test Hi My earlier postings were to get an idea of what was wanted regarding combinations of IN/ON/OUT for 'lines' and also what was reasonable to implement. I didn't like some of the method keywords that I had suggested either. The advantages of the keyword, even if ugly/unwieldy, to say what is wanted for the different 'line' cases, over a 'details' option are that: - for many methods, optimisation is possible (ie can stop early, handle the target polygons one-by-one, etc) - the result of the 'details' would probably have to be some ugly composite string, maybe requiring a regex test to decipher. My summary: For 'polygons', methods 'all' and 'any' cover the requirements. 'points' hasn't been discussed. Are methods for IN, IN or ON, ON needed? If so, what keywords to use; 'any' and 'all' are wrong... 'lines', as per 04-Jan posting with Jan's alternative. a) some-in-none-out IN and not OUT b) all-in-or-on (IN or ON) and not OUT c) all-on ON and not (OUT or IN) d) any-in IN e) any-in-or-on IN or ON So, are all cases required and what keywords to use? 'all' could be used for a) or b), but with the function being called is -in, it would more naturally apply to a). Likewise 'any' for d) rather than e). Ticker On Wed, 2020-01-15 at 06:38 +0000, Gerd Petermann wrote:
Hi Jan,
thanks for testing. Reg. the ways: Yes, that's an error. I'll have a look at it. Reg. your rules: I would add the clause & isin!=* in the 2nd rule to avoid a 2nd execution of the is_in function. Reg. ON: The current implementation of is_in accepts only 'all' or 'any'. I think we can also detect the cases 2 and 3 on Tickers list (1) but I didn't like the suggested method 'all-on' in combination with the function name is_in and I did not yet find a better alternative. An alternative I was thinking about is to implement a 'details' option which might return one of the values in Tickers list. We just have to define values for points and polygons, as Tickers list is only for rules in lines.
Gerd (1) http://gis.19327.n8.nabble.com/Test-cases-for-possible-is-in-hook -tp5954103p5954828.html
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@gmx.net> Gesendet: Dienstag, 14. Januar 2020 23:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test
Hi Gerd, hi Ticker,
sorry for the delay, until the weekend I didn´t found time to test the new versions.
I´m very impressed, my results now are so precise that I could revert all the gaps I created for the first hook. Many thanks for all your efforts to realize this accuracy!
Still I´m only on lines inside cemetery/allotments, so I have no clue about the buildings in v4 samples, sorry.
I check for „all“ and for „any“, giving two new values and then reduce them to one if another match, ie: highway=* & ... & is_in(landuse,allotments,all)=true {add isin=1} highway=* & ... & is_in(landuse,allotments,any)=true {add isin=2} highway=* & isin=1 {set highway=path} highway=* & isin=2 bicyle=no {set highway=path}
That works as I expect: reduce all-in, and any-in only if specified. I didn´t understood yet : could ON still be a value to ask for, beside IN and OUT? Or has it become obsolete? In anyway, with my rule above I see no complaint about it.
Only one unclear example so far I found - probably caused by the multipolygon? The first line is not matched by the any-rule, but the second is. Both should match according to style: https://www.openstreetmap.org/way/117416117 https://www.openstreetmap.org/way/117416120
As said, only one. With is_in render time is increased by only 5-10%, pretty cheap. Thanks to all for the ideas read here how to play with this wonderful new option.
Jan
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, although quiet on this thread so far, I think that returning a coded bitstring would be less than ideal. I suggest using something like the following: is_in(all_inside) -> return true only if the whole object is inside the area is_in(touching) -> return true if the object is either all inside, or some of it is inside and some of it is touching is_in(all_touching) -> return true if the object is all inside, or some inside and some touching, or all touching is_in(some_inside) -> return true if any of the object is inside is_in(some_touching) -> return true if any of the object is inside or touching As you can see, the return values are cumulative, with a keyword returning true for the preceding keywords and adding some extra, so for example all_touching returns true for an object that has all its points touching the area, as well as for an object that would return true for all_inside or for touching. The inverses might also be required as in: is_out(all_outside) -> return true only if the whole object is outside the area is_out(touching) -> return true if the object is either all outside, or some of it is outside and some of it is touching is_out(all_touching) -> return true if the object is all outside, or some outside and some touching, or all touching is_out(some_outside) -> return true if any of the object is outside is_out(some_touching) -> return true if any of the object is outside or touching I can't see any use for non-cumulative use (e.g. return true only if some of it is inside and some of it is touching) , except for one case that possibly might be useful: is_in(coincident) -> returns true only if all points of the object match all points of the area However, if really required, one could always use something like is_in(touching) & !is_in(all_inside) to handle very obscure cases. I think this approach would give more useful functionality. Regards, Mike -----Original Message----- From: Gerd Petermann [mailto:gpetermann_muenchen@hotmail.com] Sent: 16 January 2020 10:22 To: Ticker Berkin <rwb-mkgmap@jagit.co.uk>; Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Subject: Re: [mkgmap-dev] Branch is_in ready for a first test Hi all, For a single point we can compute 'inside', 'on boundary', or 'outside'. reg. the results and the method options I thought about a very different alternative: Instead of true or false the function might return a bit string containing three digits, e.g. 001 - 1st (leftmost) bit 0 means "no point inside found", 1 means "at least one point inside found" - 2nd bit 0 means "no point on boundary found", 1 means "at least one point on boundary found" - 3rd bit 0 means "no point outside found", 1 means "at least one point outside" found We can describe 2^3 combinations with that, but obviously the combinations 000 and 101 are impossible, so we have the 6 cases on Tickers list as 1: all of the line is outside the polygon -> 001 2: some of the line is outside and the rest touches or runs along the polygon edge -> 011 3: all of the line runs along the polygon edge -> 010 4: some of the line is inside and the rest touches or runs along -> 110 5: all of the line is inside the polygon 100 6: some is inside and some outside the polygon. Obviously some point is on -> 111 This would allow to remove the 3rd parameter, but user has to remember the order of the bits when writing the style rules. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 16. Januar 2020 10:48 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test Hi My earlier postings were to get an idea of what was wanted regarding combinations of IN/ON/OUT for 'lines' and also what was reasonable to implement. I didn't like some of the method keywords that I had suggested either. The advantages of the keyword, even if ugly/unwieldy, to say what is wanted for the different 'line' cases, over a 'details' option are that: - for many methods, optimisation is possible (ie can stop early, handle the target polygons one-by-one, etc) - the result of the 'details' would probably have to be some ugly composite string, maybe requiring a regex test to decipher. My summary: For 'polygons', methods 'all' and 'any' cover the requirements. 'points' hasn't been discussed. Are methods for IN, IN or ON, ON needed? If so, what keywords to use; 'any' and 'all' are wrong... 'lines', as per 04-Jan posting with Jan's alternative. a) some-in-none-out IN and not OUT b) all-in-or-on (IN or ON) and not OUT c) all-on ON and not (OUT or IN) d) any-in IN e) any-in-or-on IN or ON So, are all cases required and what keywords to use? 'all' could be used for a) or b), but with the function being called is -in, it would more naturally apply to a). Likewise 'any' for d) rather than e). Ticker On Wed, 2020-01-15 at 06:38 +0000, Gerd Petermann wrote:
Hi Jan,
thanks for testing. Reg. the ways: Yes, that's an error. I'll have a look at it. Reg. your rules: I would add the clause & isin!=* in the 2nd rule to avoid a 2nd execution of the is_in function. Reg. ON: The current implementation of is_in accepts only 'all' or 'any'. I think we can also detect the cases 2 and 3 on Tickers list (1) but I didn't like the suggested method 'all-on' in combination with the function name is_in and I did not yet find a better alternative. An alternative I was thinking about is to implement a 'details' option which might return one of the values in Tickers list. We just have to define values for points and polygons, as Tickers list is only for rules in lines.
Gerd (1) http://gis.19327.n8.nabble.com/Test-cases-for-possible-is-in-hook -tp5954103p5954828.html
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@gmx.net> Gesendet: Dienstag, 14. Januar 2020 23:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test
Hi Gerd, hi Ticker,
sorry for the delay, until the weekend I didn´t found time to test the new versions.
I´m very impressed, my results now are so precise that I could revert all the gaps I created for the first hook. Many thanks for all your efforts to realize this accuracy!
Still I´m only on lines inside cemetery/allotments, so I have no clue about the buildings in v4 samples, sorry.
I check for all and for any, giving two new values and then reduce them to one if another match, ie: highway=* & ... & is_in(landuse,allotments,all)=true {add isin=1} highway=* & ... & is_in(landuse,allotments,any)=true {add isin=2} highway=* & isin=1 {set highway=path} highway=* & isin=2 bicyle=no {set highway=path}
That works as I expect: reduce all-in, and any-in only if specified. I didn´t understood yet : could ON still be a value to ask for, beside IN and OUT? Or has it become obsolete? In anyway, with my rule above I see no complaint about it.
Only one unclear example so far I found - probably caused by the multipolygon? The first line is not matched by the any-rule, but the second is. Both should match according to style: https://www.openstreetmap.org/way/117416117 https://www.openstreetmap.org/way/117416120
As said, only one. With is_in render time is increased by only 5-10%, pretty cheap. Thanks to all for the ideas read here how to play with this wonderful new option.
Jan
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi all, so far I got no further feedback reg. is_in results for nodes or polygons :( Arndt wrote in a private mail that he would prefer a solution where the line or polygon is split so that the parts do not cross the boundary. If that's not possible he would be happy with the 001...111 solution. Instead of is_in(x,y,any)=true you would write is_in(x,y) ~ '1..' Instead of is_in(x,y,any)=false you would write is_in(x,y) ~ '0..' Instead of is_in(x,y,all)=true you would write is_in(x,y) ~ '1.0' Instead of is_in(x,y,all)=false you would write is_in(x,y) ~ '0..' Or should I use y and n (yes/no) instead of 1 and 0 to make clear that these are flags and not numbers? Probably easier to understand. The problem regarding polygons which are inners of multipolygons would remain unsolved: is_in(landuse,residential)='010' doesn't tell you if your polygon is on the outer ring or on the inner ring of a multipolygon, although inner is more likely. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <gpetermann_muenchen@hotmail.com> Gesendet: Donnerstag, 16. Januar 2020 11:21 An: Ticker Berkin; Development list for mkgmap Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test Hi all, For a single point we can compute 'inside', 'on boundary', or 'outside'. reg. the results and the method options I thought about a very different alternative: Instead of true or false the function might return a bit string containing three digits, e.g. 001 - 1st (leftmost) bit 0 means "no point inside found", 1 means "at least one point inside found" - 2nd bit 0 means "no point on boundary found", 1 means "at least one point on boundary found" - 3rd bit 0 means "no point outside found", 1 means "at least one point outside" found We can describe 2^3 combinations with that, but obviously the combinations 000 and 101 are impossible, so we have the 6 cases on Tickers list as 1: all of the line is outside the polygon -> 001 2: some of the line is outside and the rest touches or runs along the polygon edge -> 011 3: all of the line runs along the polygon edge -> 010 4: some of the line is inside and the rest touches or runs along -> 110 5: all of the line is inside the polygon 100 6: some is inside and some outside the polygon. Obviously some point is on -> 111 This would allow to remove the 3rd parameter, but user has to remember the order of the bits when writing the style rules. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Donnerstag, 16. Januar 2020 10:48 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test Hi My earlier postings were to get an idea of what was wanted regarding combinations of IN/ON/OUT for 'lines' and also what was reasonable to implement. I didn't like some of the method keywords that I had suggested either. The advantages of the keyword, even if ugly/unwieldy, to say what is wanted for the different 'line' cases, over a 'details' option are that: - for many methods, optimisation is possible (ie can stop early, handle the target polygons one-by-one, etc) - the result of the 'details' would probably have to be some ugly composite string, maybe requiring a regex test to decipher. My summary: For 'polygons', methods 'all' and 'any' cover the requirements. 'points' hasn't been discussed. Are methods for IN, IN or ON, ON needed? If so, what keywords to use; 'any' and 'all' are wrong... 'lines', as per 04-Jan posting with Jan's alternative. a) some-in-none-out IN and not OUT b) all-in-or-on (IN or ON) and not OUT c) all-on ON and not (OUT or IN) d) any-in IN e) any-in-or-on IN or ON So, are all cases required and what keywords to use? 'all' could be used for a) or b), but with the function being called is -in, it would more naturally apply to a). Likewise 'any' for d) rather than e). Ticker On Wed, 2020-01-15 at 06:38 +0000, Gerd Petermann wrote:
Hi Jan,
thanks for testing. Reg. the ways: Yes, that's an error. I'll have a look at it. Reg. your rules: I would add the clause & isin!=* in the 2nd rule to avoid a 2nd execution of the is_in function. Reg. ON: The current implementation of is_in accepts only 'all' or 'any'. I think we can also detect the cases 2 and 3 on Tickers list (1) but I didn't like the suggested method 'all-on' in combination with the function name is_in and I did not yet find a better alternative. An alternative I was thinking about is to implement a 'details' option which might return one of the values in Tickers list. We just have to define values for points and polygons, as Tickers list is only for rules in lines.
Gerd (1) http://gis.19327.n8.nabble.com/Test-cases-for-possible-is-in-hook -tp5954103p5954828.html
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@gmx.net> Gesendet: Dienstag, 14. Januar 2020 23:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test
Hi Gerd, hi Ticker,
sorry for the delay, until the weekend I didn´t found time to test the new versions.
I´m very impressed, my results now are so precise that I could revert all the gaps I created for the first hook. Many thanks for all your efforts to realize this accuracy!
Still I´m only on lines inside cemetery/allotments, so I have no clue about the buildings in v4 samples, sorry.
I check for „all“ and for „any“, giving two new values and then reduce them to one if another match, ie: highway=* & ... & is_in(landuse,allotments,all)=true {add isin=1} highway=* & ... & is_in(landuse,allotments,any)=true {add isin=2} highway=* & isin=1 {set highway=path} highway=* & isin=2 bicyle=no {set highway=path}
That works as I expect: reduce all-in, and any-in only if specified. I didn´t understood yet : could ON still be a value to ask for, beside IN and OUT? Or has it become obsolete? In anyway, with my rule above I see no complaint about it.
Only one unclear example so far I found - probably caused by the multipolygon? The first line is not matched by the any-rule, but the second is. Both should match according to style: https://www.openstreetmap.org/way/117416117 https://www.openstreetmap.org/way/117416120
As said, only one. With is_in render time is increased by only 5-10%, pretty cheap. Thanks to all for the ideas read here how to play with this wonderful new option.
Jan
_______________________________________________ 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
Hi all, thanks for the ongoing development. I like the abstraction that Gerd has given, be it with digits or letters; and its implementation of all Tickers 6 cases. With his explanation I could easily reproduce my simple but satisfying cemetery results as by 4418. On Tickers argumentation my idea is limited, as I´m not able to understand all code internals he might has in mind. Despite this - and if I got him correctly that it´s this logic we have now - it sounds adequate as well for what I can overlook. Regarding the splitting proposed by Arndt I think it´s not always useful. To handle improper drawings in OSM I´d prefer such a behaviour to be definable then. Don´t know if I could need it. Jan
Hi all I'm still of the opinion that it is better to specify a 'method' parameter rather than return 3 flags for the following reasons: - for polygons, it is only meaningful to need to know if ANY or ALL of the rule polygon is in the target. - for lines, it was thought better for the 'ALL' case to allow/ignore the line touching the edge, as long as the rest was IN. This tuning ability is lost unless keywords are used. - for points, I agree that returning one of the 3 flags seems to make sense, but I still maintain it is clearer to have methods that ask in/in-or-on/on rather than the equivalent test with a regexp for the on -or-on case. - for many methods, optimisation is possible, eg. 1/ the processing can stop as soon an element is found that determines the result. 2/ The target polygons can be processed one-by-one instead of joined together. - to express the line question any-in-or-on with a regexp is messy and obscure. In the java coding of the function, I expect it to use flags like IN/ON/OUT, and it is trivial for the Java to convert these, in conjunction with the 'method', to a boolean result that is easily handled at the rule level. - negation of the function is trivial when it returns a boolean. - method keyword is more readable (and writeable) than bitstring regex test. - the method keyword allows extendability, eg 1/ different accuracy requirements, 2/ magic keywords that could split the rule object into the parts that return true and the parts that return false. - Mike's idea of 'coincident' - see later. I don't thing we should consider line/polygon splitting at the moment. @jan, With my table: simplified a) some-in-none-out(all) IN and not OUT b) all-in-or-on (IN or ON) and not OUT not OUT c) all-on ON and not (OUT or IN) not (OUT or IN) d) any-in(any) IN e) any-in-or-on IN or ON I was attempting to show precisely the meaningful line cases in terms of the flags, which I hoped to remain hidden. Without the method keyword, you'd have to implement the equivalent for the cases you required with a regexp to test the flags. Mike Baggaley, on 16th Jan, suggested the following keywords; I've added a transliteration of his description of how these correspond to the flags: all_inside IN and not (ON or OUT) a) touching IN and not OUT b) all_touching not OUT d) some_inside IN e) some_touching IN or ON coincident all points of rule object match the target polygon I think the use of 'touching' here is confusing and it is best to cover all possibilities with a suitable method in 1 call to the function. @gerd, if I haven't convinced you that method keywords are better, it is probably better to use a single letter Y/N or T/F. Ticker On Wed, 2020-02-05 at 00:49 +0100, jan meisters wrote:
Hi all,
thanks for the ongoing development.
I like the abstraction that Gerd has given, be it with digits or letters; and its implementation of all Tickers 6 cases. With his explanation I could easily reproduce my simple but satisfying cemetery results as by 4418.
On Tickers argumentation my idea is limited, as I´m not able to understand all code internals he might has in mind. Despite this - and if I got him correctly that it´s this logic we have now - it sounds adequate as well for what I can overlook.
Regarding the splitting proposed by Arndt I think it´s not always useful. To handle improper drawings in OSM I´d prefer such a behaviour to be definable then. Don´t know if I could need it.
Jan
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ticker, I am lost in alternatives. I don't like the current solution and I also don't like my "three bit flags" solution. With the current code we can only distinguish 4 cases, your original list contained 6 cases, the newer 5. What should be changed in current code (r4228)? More or other method parameters? Please ignore the tuning idea. Most of this is only true in theory as rounding problems don't allow stop early unless a a real crossing (in-out or out-in) is detected. In reality the internal rounding of coordinates create something like a halo along the polygon edges. Results are unpredictable when a tested point is inside that halo unless it is exactly at the same position of a polygon node. Same position means it is either the identical node or has identical OSM coordinates. With polygons we have the special case shown with b13 and b14 in my example file is-in-hook-samples-v4.osm. I forgot to add cases where the target polygon is inside the tested polygon. Typically those would be tagging errors, e.g. landuse=residential inside a building=yes or a closed way with both tags. If I got you right you suggest to introduce more methods? As a reminder, these are the 6 different cases for a line: L1: all of the line is outside the polygon L2: some of the line is outside and the rest touches or runs along the polygon edge L3: all of the line runs along the polygon edge L4: some of the line is inside and the rest touches or runs along. L5: all of the line is inside the polygon L6: some is inside and some outside the polygon. Obviously some point is on the polygon edge but we don't care if runs along the edge. For case L3 the results of is_in(x,y,any) and is_in(x,y,all) are rather unpredictable, but more likely "false" is returned. For points we have - in theory - just three states: P1: point is inside polygon P2: point is on the edge of a polygon P3 point is outside The current code ignores the method parameter and the halo problem and returns true for P1 and P2 and false for P3. The current code treats polygons like lines but case L3 may return different results as the code tries to find out if the tested polygon is inside a hole. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 5. Februar 2020 07:58 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test Hi all I'm still of the opinion that it is better to specify a 'method' parameter rather than return 3 flags for the following reasons: - for polygons, it is only meaningful to need to know if ANY or ALL of the rule polygon is in the target. - for lines, it was thought better for the 'ALL' case to allow/ignore the line touching the edge, as long as the rest was IN. This tuning ability is lost unless keywords are used. - for points, I agree that returning one of the 3 flags seems to make sense, but I still maintain it is clearer to have methods that ask in/in-or-on/on rather than the equivalent test with a regexp for the on -or-on case. - for many methods, optimisation is possible, eg. 1/ the processing can stop as soon an element is found that determines the result. 2/ The target polygons can be processed one-by-one instead of joined together. - to express the line question any-in-or-on with a regexp is messy and obscure. In the java coding of the function, I expect it to use flags like IN/ON/OUT, and it is trivial for the Java to convert these, in conjunction with the 'method', to a boolean result that is easily handled at the rule level. - negation of the function is trivial when it returns a boolean. - method keyword is more readable (and writeable) than bitstring regex test. - the method keyword allows extendability, eg 1/ different accuracy requirements, 2/ magic keywords that could split the rule object into the parts that return true and the parts that return false. - Mike's idea of 'coincident' - see later. I don't thing we should consider line/polygon splitting at the moment. @jan, With my table: simplified a) some-in-none-out(all) IN and not OUT b) all-in-or-on (IN or ON) and not OUT not OUT c) all-on ON and not (OUT or IN) not (OUT or IN) d) any-in(any) IN e) any-in-or-on IN or ON I was attempting to show precisely the meaningful line cases in terms of the flags, which I hoped to remain hidden. Without the method keyword, you'd have to implement the equivalent for the cases you required with a regexp to test the flags. Mike Baggaley, on 16th Jan, suggested the following keywords; I've added a transliteration of his description of how these correspond to the flags: all_inside IN and not (ON or OUT) a) touching IN and not OUT b) all_touching not OUT d) some_inside IN e) some_touching IN or ON coincident all points of rule object match the target polygon I think the use of 'touching' here is confusing and it is best to cover all possibilities with a suitable method in 1 call to the function. @gerd, if I haven't convinced you that method keywords are better, it is probably better to use a single letter Y/N or T/F. Ticker On Wed, 2020-02-05 at 00:49 +0100, jan meisters wrote:
Hi all,
thanks for the ongoing development.
I like the abstraction that Gerd has given, be it with digits or letters; and its implementation of all Tickers 6 cases. With his explanation I could easily reproduce my simple but satisfying cemetery results as by 4418.
On Tickers argumentation my idea is limited, as I´m not able to understand all code internals he might has in mind. Despite this - and if I got him correctly that it´s this logic we have now - it sounds adequate as well for what I can overlook.
Regarding the splitting proposed by Arndt I think it´s not always useful. To handle improper drawings in OSM I´d prefer such a behaviour to be definable then. Don´t know if I could need it.
Jan
_______________________________________________ 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
Hi Gerd My idea would be have a list of methods per rule-context, eg: POLYGON: any, all LINE: all, all_in_or_on, all_on, any, any_in_or_on POINT: in, in_or_on, on until someone comes up with clearer names. These should be an enumeration in Java so they can be changed, aliased etc without needing to change the main code and checked as the function is parsed. The main logic operates as it does now, except LINE and POLYGON handling probably need to diverge, setting the 3 internal booleans IN/ON/OUT. Then, at the end, these are converted to a single boolean result according to requested method and the table a)..e) for LINEs in my previous mail POLYGON results should be based on: is ALL/ANY of the area of rule polygon in matching polygon(s). The issue of polygons with holes, esp. if the rule polygon is the hole in the target polygon are impossible to decide. I think one of your examples had a residential area where some of the major buildings where cut out from this area with a multi-polygon relation. Is the building in the residential area? Logical answer is no - there is no area shared between the two. Expected answer - yes if you know what a residential area and a building are. Optimisation can be performed for, eg, the any... methods, stopping as soon as the relevant IN or ON flag is set. Regarding cases L1-L6 for lines: L1 OUT L2 OUT ON L3 ON L4 ON IN L5 IN L6 OUT ON IN My intention was to phrase the query, via the method, in terms like: Is any part of this line in the matching polygons? Is all of this line in matching polygons? Is this line an edge of matching polygons? rather than the 3 flags defining the relationship the particular line to the polygon, so is_in(any) matches L4/L5/L6 and is_in(all) matches L4/L5, etc (here, for LINEs, method 'any' is 'any-in' and 'all' is 'some-in-none-out') Also, at the same time, ignore the cases where an inner line touches the edge or an outer line touches the edge. This gives the 5 cases a) to e) Handling the question this way gets around problems like:
For case L3 the results of is_in(x,y,any) and is_in(x,y,all) are rather unpredictable, but more likely "false" is returned. If the rule wants to do something with a line that bounds the polygon, it asks for is_in(all_on)
For POINTs, the same rational applies, the rule asks for what it want to handle, eg is_in(in_or_on)=false to match a POI that outside the polygon. Ticker On Wed, 2020-02-05 at 08:51 +0000, Gerd Petermann wrote:
Hi Ticker,
I am lost in alternatives. I don't like the current solution and I also don't like my "three bit flags" solution. With the current code we can only distinguish 4 cases, your original list contained 6 cases, the newer 5. What should be changed in current code (r4228)? More or other method parameters?
Please ignore the tuning idea. Most of this is only true in theory as rounding problems don't allow stop early unless a a real crossing (in -out or out-in) is detected. In reality the internal rounding of coordinates create something like a halo along the polygon edges. Results are unpredictable when a tested point is inside that halo unless it is exactly at the same position of a polygon node. Same position means it is either the identical node or has identical OSM coordinates.
With polygons we have the special case shown with b13 and b14 in my example file is-in-hook-samples-v4.osm. I forgot to add cases where the target polygon is inside the tested polygon. Typically those would be tagging errors, e.g. landuse=residential inside a building=yes or a closed way with both tags.
If I got you right you suggest to introduce more methods? As a reminder, these are the 6 different cases for a line: L1: all of the line is outside the polygon L2: some of the line is outside and the rest touches or runs along the polygon edge L3: all of the line runs along the polygon edge L4: some of the line is inside and the rest touches or runs along. L5: all of the line is inside the polygon L6: some is inside and some outside the polygon. Obviously some point is on the polygon edge but we don't care if runs along the edge.
For case L3 the results of is_in(x,y,any) and is_in(x,y,all) are rather unpredictable, but more likely "false" is returned.
For points we have - in theory - just three states: P1: point is inside polygon P2: point is on the edge of a polygon P3 point is outside The current code ignores the method parameter and the halo problem and returns true for P1 and P2 and false for P3.
The current code treats polygons like lines but case L3 may return different results as the code tries to find out if the tested polygon is inside a hole.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@jagit.co.uk> Gesendet: Mittwoch, 5. Februar 2020 07:58 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test
Hi all
I'm still of the opinion that it is better to specify a 'method' parameter rather than return 3 flags for the following reasons:
- for polygons, it is only meaningful to need to know if ANY or ALL of the rule polygon is in the target.
- for lines, it was thought better for the 'ALL' case to allow/ignore the line touching the edge, as long as the rest was IN. This tuning ability is lost unless keywords are used.
- for points, I agree that returning one of the 3 flags seems to make sense, but I still maintain it is clearer to have methods that ask in/in-or-on/on rather than the equivalent test with a regexp for the on -or-on case.
- for many methods, optimisation is possible, eg. 1/ the processing can stop as soon an element is found that determines the result. 2/ The target polygons can be processed one-by-one instead of joined together.
- to express the line question any-in-or-on with a regexp is messy and obscure. In the java coding of the function, I expect it to use flags like IN/ON/OUT, and it is trivial for the Java to convert these, in conjunction with the 'method', to a boolean result that is easily handled at the rule level.
- negation of the function is trivial when it returns a boolean.
- method keyword is more readable (and writeable) than bitstring regex test.
- the method keyword allows extendability, eg 1/ different accuracy requirements, 2/ magic keywords that could split the rule object into the parts that return true and the parts that return false.
- Mike's idea of 'coincident' - see later.
I don't thing we should consider line/polygon splitting at the moment.
@jan, With my table: simplified a) some-in-none-out(all) IN and not OUT b) all-in-or-on (IN or ON) and not OUT not OUT c) all-on ON and not (OUT or IN) not (OUT or IN) d) any-in(any) IN e) any-in-or-on IN or ON I was attempting to show precisely the meaningful line cases in terms of the flags, which I hoped to remain hidden. Without the method keyword, you'd have to implement the equivalent for the cases you required with a regexp to test the flags.
Mike Baggaley, on 16th Jan, suggested the following keywords; I've added a transliteration of his description of how these correspond to the flags: all_inside IN and not (ON or OUT) a) touching IN and not OUT b) all_touching not OUT d) some_inside IN e) some_touching IN or ON coincident all points of rule object match the target polygon
I think the use of 'touching' here is confusing and it is best to cover all possibilities with a suitable method in 1 call to the function.
@gerd, if I haven't convinced you that method keywords are better, it is probably better to use a single letter Y/N or T/F.
Ticker
On Wed, 2020-02-05 at 00:49 +0100, jan meisters wrote:
Hi all,
thanks for the ongoing development.
I like the abstraction that Gerd has given, be it with digits or letters; and its implementation of all Tickers 6 cases. With his explanation I could easily reproduce my simple but satisfying cemetery results as by 4418.
On Tickers argumentation my idea is limited, as I´m not able to understand all code internals he might has in mind. Despite this - and if I got him correctly that it´s this logic we have now - it sounds adequate as well for what I can overlook.
Regarding the splitting proposed by Arndt I think it´s not always useful. To handle improper drawings in OSM I´d prefer such a behaviour to be definable then. Don´t know if I could need it.
Jan
_______________________________________________ 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
Hi Gerd, mkgmap.org.uk seems to be defect - there is no download for the latest and latest branches available. Unfortunately I haven´t downloaded the r4418 source to patch it myself. Regarding your hint: do you mean highway=* & ... & is_in(landuse,allotments,any)=true & isin!=* {add isin=2} I tried this, without visible difference in output or rendertime. But the map is a tiny bit smaller. Jan
Am 14.01.2020 um 23:38 schrieb jan meisters <jan_m23@gmx.net>:
Hi Gerd, hi Ticker,
sorry for the delay, until the weekend I didn´t found time to test the new versions.
I´m very impressed, my results now are so precise that I could revert all the gaps I created for the first hook. Many thanks for all your efforts to realize this accuracy!
Still I´m only on lines inside cemetery/allotments, so I have no clue about the buildings in v4 samples, sorry.
I check for „all“ and for „any“, giving two new values and then reduce them to one if another match, ie: highway=* & ... & is_in(landuse,allotments,all)=true {add isin=1} highway=* & ... & is_in(landuse,allotments,any)=true {add isin=2} highway=* & isin=1 {set highway=path} highway=* & isin=2 bicyle=no {set highway=path}
That works as I expect: reduce all-in, and any-in only if specified. I didn´t understood yet : could ON still be a value to ask for, beside IN and OUT? Or has it become obsolete? In anyway, with my rule above I see no complaint about it.
Only one unclear example so far I found - probably caused by the multipolygon? The first line is not matched by the any-rule, but the second is. Both should match according to style: https://www.openstreetmap.org/way/117416117 <https://www.openstreetmap.org/way/117416117> https://www.openstreetmap.org/way/117416120 <https://www.openstreetmap.org/way/117416120>
As said, only one. With is_in render time is increased by only 5-10%, pretty cheap. Thanks to all for the ideas read here how to play with this wonderful new option.
Jan
Am 12.01.2020 um 09:58 schrieb Gerd Petermann <gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>>:
Hi all,
the message "SCHWERWIEGEND (IsInFunction): .\Baustelle\Speiche_Kanaren_Splitter\88002007.osm.pbf: rounding error? first point is on line but status of first point is not ON" was produced for this node: https://www.openstreetmap.org/node/640552250#map=18/28.14036/-16.52529 <https://www.openstreetmap.org/node/640552250#map=18/28.14036/-16.52529>
The node is extremely close to the landuse=residential way 255452457. In OSM precision the node is inside the residential area, but in mkgmap precision it is outside. These special cases really cause trouble. To improve performance, the code first tests the result for the first point. If this result is IN and method is 'any' or when result is OUT and method is 'all' there should be no need to test any further nodes or edges, thus the corresponding result is returned. Now, with these special cases the quick result may be wrong. With r4116 I've disabled the quick test. The result is more likely to be correct but performance can be poor when complex areas are involved.
For normal cases the difference should be small, maybe a second per tile.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk <mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Arndt Röhrig <arndt@speichenkarte.de <mailto:arndt@speichenkarte.de>> Gesendet: Samstag, 11. Januar 2020 12:02 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test
Good morning,
so far i used "mkgmap:residential" to draw some highways thinner in citys. I replaced it with the is_in function and added some other polys like "school", "industrial" etc. It works fine, great.
I added also a "bicycle=no" on "cemetarys", "schools", "landfills", "quarry" etc.
Thank you all for this work!
Problem #1: is_in(landuse,residential,any)=true will not work in "Wuppertal". mkmap:residential also no work there either. I suspect the reason in the osm-data, but i don´t see why. Have anybody an idea? https://fotos.rennrad-news.de/f3/4/494/494184-sm3yb9gt4tjr-test-medium.png <https://fotos.rennrad-news.de/f3/4/494/494184-sm3yb9gt4tjr-test-medium.png>
Problem, #2: r-4412 report: SCHWERWIEGEND (IsInFunction): .\Baustelle\Speiche_Kanaren_Splitter\88002007.osm.pbf: rounding error? first point is on line but status of first point is not ON https://speichenkarte.de/88002007.osm.pbf <https://speichenkarte.de/88002007.osm.pbf>
greetings
Arndt
Gerd Petermann < gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com><mailto:gpetermann_muenchen@hotmail.com <mailto:gpetermann_muenchen@hotmail.com>>> hat am 10. Januar 2020 um 12:07 geschrieben:
Hi Ticker,
thanks, see r4412 : http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4412 <http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4412>
Gerd
________________________________________ Von: mkgmap-dev < mkgmap-dev-bounces@lists.mkgmap.org.uk <mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk <mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Ticker Berkin < rwb-mkgmap@jagit.co.uk <mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk <mailto:rwb-mkgmap@jagit.co.uk>>> Gesendet: Freitag, 10. Januar 2020 11:29 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test
Hi Gerd
Here is patch that sets isLineRule in the package on the augmentsWith call.
I've also used default method for the augmentsWith... in Rule, Op, OsmConverter and backed out the changes that have now become unnecessary.
Ticker
On Fri, 2020-01-10 at 09:15 +0000, Gerd Petermann wrote: Hi Ticker, yes, it would probably be better to know if the function is for a polyline or polygon. A patch would be welcomed. And yes, the expected result for the case you describe is not yet clear. See b13 and b14 in my example file. Gerd ________________________________________ Von: mkgmap-dev < mkgmap-dev-bounces@lists.mkgmap.org.uk <mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk><mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk <mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>>> im Auftrag von Ticker Berkin < rwb-mkgmap@jagit.co.uk <mailto:rwb-mkgmap@jagit.co.uk><mailto:rwb-mkgmap@jagit.co.uk <mailto:rwb-mkgmap@jagit.co.uk>>> Gesendet: Freitag, 10. Januar 2020 09:59 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test Hi Gerd I think the logic still needs to know if it is handling a closed way as a polygon rule or as a line rule. Firstly to be able to correctly handle the case where the rule.way runs around a hole in the target.polygon - all of the rule.line is in the target, but only part of the rule.polygon is in the target. Also there might be different method keywords for the two. For polygon rules, "any" and "all" are adequate, but for line rules others might be required. I've just svn updated the is_in branch. Is there still work to do on non-closed ways? Otherwise amazing. Ticker On Thu, 2020-01-09 at 11:43 +0000, Gerd Petermann wrote: Hi all, the branch version r4408 implements the style function is_in with three parameters tag-key,tag-value,method - tag-key can be something like landuse or natural or amenity - tag-value would be the expected value for that tag-key - method has to be "any" or "all". Example usage in lines: # no cycling within a cemetery highway=* & bicycle!=* & is_in(landuse,cemetery,all) {add bicycle=dismount} Before any style rule is evaluated the function evaluates the list of all ways found in the input file. When a way matches the given tag (key+value) and is closed and complete the shape geometry is stored in a spatial index. With the current implementation this index is created for appearance of the is_in function in a style rule (subject to optimization) When the style function is called it retrieves the stored shape(s) which intersect the boundary of the element. If none is found "false" is returned. If there are multiple such shapes the are merged where possible, so that overlapping or touching shapes are combined to a single shape which may include holes. The list of (outer) shapes is then tested one after the other until one shape is found which either contains the element completely or - when "any" is used as method - partially. If none is found the value "false" is returned. If a match is found and the combined shapes have holes, a final test is done to find out if the element is within the hole. If method "any" is used and the shape is completey within one hole "false" is returned. If method "all" is used and the shape is partly within one hole "false" is returned. If we get here true is "returned" I've also slightly changed the behaviour of the LocationHook and the ResidentialHook. The results should be a bit more predictable now as searches are done with higher precsion. Still, both try to find a nearby boundary(shape) if none is found at the exact position. The ResidentialHook is now automatically disabled when the style doesn't use mkgmap:residential anywhere. TODO: - various possible special cases need more testing - maybe add more methods for cases where parts of the tested element touch the boundary of the shape. - tuning - unit tests As always with branch version the binary can be found at the bottom of the download page. http://www.mkgmap.org.uk/download/mkgmap.html <http://www.mkgmap.org.uk/download/mkgmap.html> I've tested this with the example file posted before, accept for b18 all cases work as expected. Gerd _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev <http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev> _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev <http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev> _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev <http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev> _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev <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
Hi all
mkgmap.org.uk <http://mkgmap.org.uk> seems to be defect - there is no
Sorry about that; it should be OK again now. Let me know if anything is not working. ..Steve
participants (8)
-
Arndt Röhrig -
Gerd Petermann -
Gerd Petermann
-
jan meisters -
Mike Baggaley -
Pinns UK -
Steve Ratcliffe -
Ticker Berkin