Branch is_in ready for a first test

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Branch is_in ready for a first test

Gerd Petermann
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
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Branch is_in ready for a first test

nwillink
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
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Branch is_in ready for a first test

Gerd Petermann
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 <[hidden email]> im Auftrag von Pinns UK <[hidden email]>
Gesendet: Donnerstag, 9. Januar 2020 14:50
An: [hidden email]
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
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Branch is_in ready for a first test

nwillink
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}
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Branch is_in ready for a first test

Gerd Petermann
Hi Nick,

yes, no extra option needed.

Gerd

________________________________________
Von: Pinns UK <[hidden email]>
Gesendet: Donnerstag, 9. Januar 2020 14:56
An: Gerd Petermann; [hidden email]
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}
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Branch is_in ready for a first test

nwillink
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 <[hidden email]>
> Gesendet: Donnerstag, 9. Januar 2020 14:56
> An: Gerd Petermann; [hidden email]
> 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}
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Branch is_in ready for a first test

Gerd Petermann
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 <[hidden email]>
Gesendet: Donnerstag, 9. Januar 2020 15:07
An: Gerd Petermann; [hidden email]
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 <[hidden email]>
> Gesendet: Donnerstag, 9. Januar 2020 14:56
> An: Gerd Petermann; [hidden email]
> 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}
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Branch is_in ready for a first test

nwillink
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 <[hidden email]>
> Gesendet: Donnerstag, 9. Januar 2020 15:07
> An: Gerd Petermann; [hidden email]
> 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 <[hidden email]>
>> Gesendet: Donnerstag, 9. Januar 2020 14:56
>> An: Gerd Petermann; [hidden email]
>> 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}
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Branch is_in ready for a first test

Gerd Petermann
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 <[hidden email]>
Gesendet: Donnerstag, 9. Januar 2020 15:24
An: Gerd Petermann; [hidden email]
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 <[hidden email]>
> Gesendet: Donnerstag, 9. Januar 2020 15:07
> An: Gerd Petermann; [hidden email]
> 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 <[hidden email]>
>> Gesendet: Donnerstag, 9. Januar 2020 14:56
>> An: Gerd Petermann; [hidden email]
>> 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}
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Branch is_in ready for a first test

nwillink
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 <[hidden email]>
> Gesendet: Donnerstag, 9. Januar 2020 15:24
> An: Gerd Petermann; [hidden email]
> 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 <[hidden email]>
>> Gesendet: Donnerstag, 9. Januar 2020 15:07
>> An: Gerd Petermann; [hidden email]
>> 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 <[hidden email]>
>>> Gesendet: Donnerstag, 9. Januar 2020 14:56
>>> An: Gerd Petermann; [hidden email]
>>> 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}
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Branch is_in ready for a first test

Gerd Petermann
Hi Nick,

did you really use some? The code expects either "any" or "all", but doesn't yet check this.

Gerd

________________________________________
Von: Pinns UK <[hidden email]>
Gesendet: Donnerstag, 9. Januar 2020 15:55
An: Gerd Petermann; [hidden email]
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 <[hidden email]>
> Gesendet: Donnerstag, 9. Januar 2020 15:24
> An: Gerd Petermann; [hidden email]
> 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 <[hidden email]>
>> Gesendet: Donnerstag, 9. Januar 2020 15:07
>> An: Gerd Petermann; [hidden email]
>> 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 <[hidden email]>
>>> Gesendet: Donnerstag, 9. Januar 2020 14:56
>>> An: Gerd Petermann; [hidden email]
>>> 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}
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Branch is_in ready for a first test

nwillink
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 <[hidden email]>
> Gesendet: Donnerstag, 9. Januar 2020 15:55
> An: Gerd Petermann; [hidden email]
> 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 <[hidden email]>
>> Gesendet: Donnerstag, 9. Januar 2020 15:24
>> An: Gerd Petermann; [hidden email]
>> 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 <[hidden email]>
>>> Gesendet: Donnerstag, 9. Januar 2020 15:07
>>> An: Gerd Petermann; [hidden email]
>>> 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 <[hidden email]>
>>>> Gesendet: Donnerstag, 9. Januar 2020 14:56
>>>> An: Gerd Petermann; [hidden email]
>>>> 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}
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Branch is_in ready for a first test

Gerd Petermann
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 <[hidden email]>
Gesendet: Donnerstag, 9. Januar 2020 15:59
An: Gerd Petermann; [hidden email]
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 <[hidden email]>
> Gesendet: Donnerstag, 9. Januar 2020 15:55
> An: Gerd Petermann; [hidden email]
> 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 <[hidden email]>
>> Gesendet: Donnerstag, 9. Januar 2020 15:24
>> An: Gerd Petermann; [hidden email]
>> 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 <[hidden email]>
>>> Gesendet: Donnerstag, 9. Januar 2020 15:07
>>> An: Gerd Petermann; [hidden email]
>>> 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 <[hidden email]>
>>>> Gesendet: Donnerstag, 9. Januar 2020 14:56
>>>> An: Gerd Petermann; [hidden email]
>>>> 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}
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Branch is_in ready for a first test

Arndt Röhrig
In reply to this post by Gerd Petermann
Hi Gerd,

thank you for your work!

My Test:
in "lines" i wrote 
highway=* & bicycle!=* & is_in(landuse,cemetery,all)=true { name'${LangBez}'} [0x10100 resolution 24 ]
0x10100 is motorway :) (purple line)
i test it also with "any", same result.

Some ways on cementary are motorways, some not. 
For example:
N51° 10.939' E7° 11.712'



greets

Arndt
Gerd Petermann < [hidden email]> hat am 9. Januar 2020 um 14:53 geschrieben:


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 < [hidden email]> im Auftrag von Pinns UK < [hidden email]>
Gesendet: Donnerstag, 9. Januar 2020 14:50
Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test

Hi Gerd


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.
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 mailing list
_______________________________________________
mkgmap-dev mailing list

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Branch is_in ready for a first test

Arndt Röhrig
2. try to send this. first time, there was a too big picture....
Arndt Röhrig <[hidden email]> hat am 9. Januar 2020 um 16:29 geschrieben:

Hi Gerd,

thank you for your work!

My Test:
in "lines" i wrote 
highway=* & bicycle!=* & is_in(landuse,cemetery,all)=true { name'${LangBez}'} [0x10100 resolution 24 ]
0x10100 is motorway :) (purple line)
i test it also with "any", same result.

Some ways on cementary are motorways, some not. 
For example:
N51° 10.939' E7° 11.712'
https://fotos.rennrad-news.de/f3/4/494/494117-1f4njnpzrdsn-test-large.png


greets

Arndt
Gerd Petermann < [hidden email]> hat am 9. Januar 2020 um 14:53 geschrieben:


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 < [hidden email]> im Auftrag von Pinns UK < [hidden email]>
Gesendet: Donnerstag, 9. Januar 2020 14:50
Betreff: Re: [mkgmap-dev] Branch is_in ready for a first test

Hi Gerd


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.
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 mailing list
_______________________________________________
mkgmap-dev mailing list

 

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Branch is_in ready for a first test

Ticker Berkin
In reply to this post by Gerd Petermann
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
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Branch is_in ready for a first test

Gerd Petermann
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 <[hidden email]> im Auftrag von Ticker Berkin <[hidden email]>
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
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Branch is_in ready for a first test

Ticker Berkin
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 <[hidden email]> im Auftrag
> von Ticker Berkin <[hidden email]>
> 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
> > [hidden email]
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

is_in-function_v4.patch (12K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Branch is_in ready for a first test

Gerd Petermann
Hi Ticker,

thanks, see r4412 : http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4412

Gerd

________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Ticker Berkin <[hidden email]>
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 <[hidden email]> im Auftrag
> von Ticker Berkin <[hidden email]>
> 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
> > [hidden email]
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> [hidden email]
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Branch is_in ready for a first test

Arndt Röhrig
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?

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


greetings

Arndt



  
Gerd Petermann < [hidden email]> hat am 10. Januar 2020 um 12:07 geschrieben:


Hi Ticker,


Gerd

________________________________________
Von: mkgmap-dev < [hidden email]> im Auftrag von Ticker Berkin < [hidden email]>
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 < [hidden email]> im Auftrag
von Ticker Berkin < [hidden email]>
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.
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 mailing list
_______________________________________________
mkgmap-dev mailing list

_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
12