Work on is_in branch

classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Work on is_in branch

Gerd Petermann
Hi all,

sorry, something is broken in the mail system.
The latest posts don't appear on nabble (1) and my answers to existing threads are rejected.

@Ticker: I'd prefer to do the merge and I think it should be done in IsInUtil. Your patch is_in-function_v7.patch goes in the opposite direction.
Not sure what you plan to do now?

Gerd

(1) http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Work on is_in branch

Ticker Berkin
Hi Gerd

To take advantage of efficiency gains based on knowing what is being
asked for, ie:

- do the polygons need to be merged or can we do one-by-one.
- can we answer correctly even of !W.isComplete().
- can we stop early, eg ANY as soon as part is IN, ALL as soon as part
is OUT, etc

the top layers of code need to be with the method and its associated
knowledge. I don't see any point in simply moving this into IsInUtil.

I was going to take calcInsideness next and divide it into some library
bits remaining in IsInUtil, and logic equivalent to the rest in
IsInFunction.

If you consider this is not the way to proceed, then I'd still like
patch applied anyway, firstly because it contains other changes
unrelated to this, secondly so that the code exists in SVN. I'll then
immediately do another patch that removes the canStop logic etc and the
POINT code that migrated here and restore it to just testing the
composite flags.

Ticker

On Tue, 2020-02-11 at 14:11 +0000, Gerd Petermann wrote:

> Hi all,
>
> sorry, something is broken in the mail system.
> The latest posts don't appear on nabble (1) and my answers to
> existing threads are rejected.
>
> @Ticker: I'd prefer to do the merge and I think it should be done in
> IsInUtil. Your patch is_in-function_v7.patch goes in the opposite
> direction.
> Not sure what you plan to do now?
>
> Gerd
>
> (1) http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
> _______________________________________________
> 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: Work on is_in branch

Gerd Petermann
Hi Ticker,

okay, let's see where this goes...

Gerd

________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Ticker Berkin <[hidden email]>
Gesendet: Dienstag, 11. Februar 2020 16:36
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Work on is_in branch

Hi Gerd

To take advantage of efficiency gains based on knowing what is being
asked for, ie:

- do the polygons need to be merged or can we do one-by-one.
- can we answer correctly even of !W.isComplete().
- can we stop early, eg ANY as soon as part is IN, ALL as soon as part
is OUT, etc

the top layers of code need to be with the method and its associated
knowledge. I don't see any point in simply moving this into IsInUtil.

I was going to take calcInsideness next and divide it into some library
bits remaining in IsInUtil, and logic equivalent to the rest in
IsInFunction.

If you consider this is not the way to proceed, then I'd still like
patch applied anyway, firstly because it contains other changes
unrelated to this, secondly so that the code exists in SVN. I'll then
immediately do another patch that removes the canStop logic etc and the
POINT code that migrated here and restore it to just testing the
composite flags.

Ticker

On Tue, 2020-02-11 at 14:11 +0000, Gerd Petermann wrote:

> Hi all,
>
> sorry, something is broken in the mail system.
> The latest posts don't appear on nabble (1) and my answers to
> existing threads are rejected.
>
> @Ticker: I'd prefer to do the merge and I think it should be done in
> IsInUtil. Your patch is_in-function_v7.patch goes in the opposite
> direction.
> Not sure what you plan to do now?
>
> Gerd
>
> (1) http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
> _______________________________________________
> 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: Work on is_in branch

Ticker Berkin
Hi Gerd

I assume you mean towards moving some logic from IsInUtil to
IsInFunction.

Ticker

On Tue, 2020-02-11 at 15:41 +0000, Gerd Petermann wrote:

> Hi Ticker,
>
> okay, let's see where this goes...
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <[hidden email]> im Auftrag
> von Ticker Berkin <[hidden email]>
> Gesendet: Dienstag, 11. Februar 2020 16:36
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
>
> Hi Gerd
>
> To take advantage of efficiency gains based on knowing what is being
> asked for, ie:
>
> - do the polygons need to be merged or can we do one-by-one.
> - can we answer correctly even of !W.isComplete().
> - can we stop early, eg ANY as soon as part is IN, ALL as soon as
> part
> is OUT, etc
>
> the top layers of code need to be with the method and its associated
> knowledge. I don't see any point in simply moving this into IsInUtil.
>
> I was going to take calcInsideness next and divide it into some
> library
> bits remaining in IsInUtil, and logic equivalent to the rest in
> IsInFunction.
>
> If you consider this is not the way to proceed, then I'd still like
> patch applied anyway, firstly because it contains other changes
> unrelated to this, secondly so that the code exists in SVN. I'll then
> immediately do another patch that removes the canStop logic etc and
> the
> POINT code that migrated here and restore it to just testing the
> composite flags.
>
> Ticker
>
> On Tue, 2020-02-11 at 14:11 +0000, Gerd Petermann wrote:
> > Hi all,
> >
> > sorry, something is broken in the mail system.
> > The latest posts don't appear on nabble (1) and my answers to
> > existing threads are rejected.
> >
> > @Ticker: I'd prefer to do the merge and I think it should be done
> > in
> > IsInUtil. Your patch is_in-function_v7.patch goes in the opposite
> > direction.
> > Not sure what you plan to do now?
> >
> > Gerd
> >
> > (1) http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
> > _______________________________________________
> > 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: Work on is_in branch

Gerd Petermann
Hi Ticker,

whatever you plan to do. I moved the code to the lib because it is easier to write a unit test.
I would not invest much time to avoid a few tests which only happen in very rare cases. Makes testing more complicated and code less readable.

Gerd

________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Ticker Berkin <[hidden email]>
Gesendet: Dienstag, 11. Februar 2020 16:43
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Work on is_in branch

Hi Gerd

I assume you mean towards moving some logic from IsInUtil to
IsInFunction.

Ticker

On Tue, 2020-02-11 at 15:41 +0000, Gerd Petermann wrote:

> Hi Ticker,
>
> okay, let's see where this goes...
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <[hidden email]> im Auftrag
> von Ticker Berkin <[hidden email]>
> Gesendet: Dienstag, 11. Februar 2020 16:36
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
>
> Hi Gerd
>
> To take advantage of efficiency gains based on knowing what is being
> asked for, ie:
>
> - do the polygons need to be merged or can we do one-by-one.
> - can we answer correctly even of !W.isComplete().
> - can we stop early, eg ANY as soon as part is IN, ALL as soon as
> part
> is OUT, etc
>
> the top layers of code need to be with the method and its associated
> knowledge. I don't see any point in simply moving this into IsInUtil.
>
> I was going to take calcInsideness next and divide it into some
> library
> bits remaining in IsInUtil, and logic equivalent to the rest in
> IsInFunction.
>
> If you consider this is not the way to proceed, then I'd still like
> patch applied anyway, firstly because it contains other changes
> unrelated to this, secondly so that the code exists in SVN. I'll then
> immediately do another patch that removes the canStop logic etc and
> the
> POINT code that migrated here and restore it to just testing the
> composite flags.
>
> Ticker
>
> On Tue, 2020-02-11 at 14:11 +0000, Gerd Petermann wrote:
> > Hi all,
> >
> > sorry, something is broken in the mail system.
> > The latest posts don't appear on nabble (1) and my answers to
> > existing threads are rejected.
> >
> > @Ticker: I'd prefer to do the merge and I think it should be done
> > in
> > IsInUtil. Your patch is_in-function_v7.patch goes in the opposite
> > direction.
> > Not sure what you plan to do now?
> >
> > Gerd
> >
> > (1) http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
> > _______________________________________________
> > 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
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Work on is_in branch

Ticker Berkin
Hi Gerd

Here it is - changes are:

- Some restructuring with early stopping where possible.

- Merging polygons for POINT IN/ON test so a point on shared boundary
becomes IN rather than ON.

- Not merging polygons when no need.

- Make the function cacheable, so that there is negligible cost to the
second call:
highway=path & is_in(landuse, residential, all)=true [0xAA]
highway=path & is_in(landuse, residential, all)=false [0xBB]

- Improved the layout of documentation in the Style Manual.

- Fixed quite a few problems.

I've left quite a lot of debug in for the moment, I think there will
still be work to do.

It gives correct answers to 'point-on.osm'. I haven't worked through is
-in-hook-sample-v3.osm yet because I wanted to get this revision out to
replace faults in the previous versions.

Ticker
 
On Tue, 2020-02-11 at 15:49 +0000, Gerd Petermann wrote:
> Hi Ticker,
>
> whatever you plan to do. I moved the code to the lib because it is easier to write a unit test.
> I would not invest much time to avoid a few tests which only happen in very rare cases. Makes testing more complicated and code less readable.
>
> Gerd

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

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

Re: Work on is_in branch

Gerd Petermann
Hi Ticker,

did you run the unit tests? This should download a newer version of the samples.

Gerd

________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Ticker Berkin <[hidden email]>
Gesendet: Mittwoch, 12. Februar 2020 16:23
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Work on is_in branch

Hi Gerd

Here it is - changes are:

- Some restructuring with early stopping where possible.

- Merging polygons for POINT IN/ON test so a point on shared boundary
becomes IN rather than ON.

- Not merging polygons when no need.

- Make the function cacheable, so that there is negligible cost to the
second call:
highway=path & is_in(landuse, residential, all)=true [0xAA]
highway=path & is_in(landuse, residential, all)=false [0xBB]

- Improved the layout of documentation in the Style Manual.

- Fixed quite a few problems.

I've left quite a lot of debug in for the moment, I think there will
still be work to do.

It gives correct answers to 'point-on.osm'. I haven't worked through is
-in-hook-sample-v3.osm yet because I wanted to get this revision out to
replace faults in the previous versions.

Ticker

On Tue, 2020-02-11 at 15:49 +0000, Gerd Petermann wrote:
> Hi Ticker,
>
> whatever you plan to do. I moved the code to the lib because it is easier to write a unit test.
> I would not invest much time to avoid a few tests which only happen in very rare cases. Makes testing more complicated and code less readable.
>
> 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: Work on is_in branch

Ticker Berkin
Hi Gerd

The re-structuring makes this difficult.

I propose a function in IsInUtilTest with the same interface as
calcInsideness from IsInUtil that somehow drives the real function IsIn
Function to collect and build the IN/ON/OUT intflag.

Ticker

On Wed, 2020-02-12 at 15:28 +0000, Gerd Petermann wrote:

> Hi Ticker,
>
> did you run the unit tests? This should download a newer version of
> the samples.
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <[hidden email]> im Auftrag
> von Ticker Berkin <[hidden email]>
> Gesendet: Mittwoch, 12. Februar 2020 16:23
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
>
> Hi Gerd
>
> Here it is - changes are:
>
> - Some restructuring with early stopping where possible.
>
> - Merging polygons for POINT IN/ON test so a point on shared boundary
> becomes IN rather than ON.
>
> - Not merging polygons when no need.
>
> - Make the function cacheable, so that there is negligible cost to
> the
> second call:
> highway=path & is_in(landuse, residential, all)=true [0xAA]
> highway=path & is_in(landuse, residential, all)=false [0xBB]
>
> - Improved the layout of documentation in the Style Manual.
>
> - Fixed quite a few problems.
>
> I've left quite a lot of debug in for the moment, I think there will
> still be work to do.
>
> It gives correct answers to 'point-on.osm'. I haven't worked through
> is
> -in-hook-sample-v3.osm yet because I wanted to get this revision out
> to
> replace faults in the previous versions.
>
> Ticker
>
> On Tue, 2020-02-11 at 15:49 +0000, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > whatever you plan to do. I moved the code to the lib because it is
> > easier to write a unit test.
> > I would not invest much time to avoid a few tests which only happen
> > in very rare cases. Makes testing more complicated and code less
> > readable.
> >
> > 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: Work on is_in branch

Gerd Petermann
Hi Ticker,

I found it difficult to test the real style function, that's why I moved all the logic out of it.
I am looking forward to your solution.

Gerd

________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Ticker Berkin <[hidden email]>
Gesendet: Mittwoch, 12. Februar 2020 16:47
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Work on is_in branch

Hi Gerd

The re-structuring makes this difficult.

I propose a function in IsInUtilTest with the same interface as
calcInsideness from IsInUtil that somehow drives the real function IsIn
Function to collect and build the IN/ON/OUT intflag.

Ticker

On Wed, 2020-02-12 at 15:28 +0000, Gerd Petermann wrote:

> Hi Ticker,
>
> did you run the unit tests? This should download a newer version of
> the samples.
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <[hidden email]> im Auftrag
> von Ticker Berkin <[hidden email]>
> Gesendet: Mittwoch, 12. Februar 2020 16:23
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
>
> Hi Gerd
>
> Here it is - changes are:
>
> - Some restructuring with early stopping where possible.
>
> - Merging polygons for POINT IN/ON test so a point on shared boundary
> becomes IN rather than ON.
>
> - Not merging polygons when no need.
>
> - Make the function cacheable, so that there is negligible cost to
> the
> second call:
> highway=path & is_in(landuse, residential, all)=true [0xAA]
> highway=path & is_in(landuse, residential, all)=false [0xBB]
>
> - Improved the layout of documentation in the Style Manual.
>
> - Fixed quite a few problems.
>
> I've left quite a lot of debug in for the moment, I think there will
> still be work to do.
>
> It gives correct answers to 'point-on.osm'. I haven't worked through
> is
> -in-hook-sample-v3.osm yet because I wanted to get this revision out
> to
> replace faults in the previous versions.
>
> Ticker
>
> On Tue, 2020-02-11 at 15:49 +0000, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > whatever you plan to do. I moved the code to the lib because it is
> > easier to write a unit test.
> > I would not invest much time to avoid a few tests which only happen
> > in very rare cases. Makes testing more complicated and code less
> > readable.
> >
> > 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: Work on is_in branch

Ticker Berkin
Hi Gerd

Here is the start of it + a couple of changes to the interface of
IsInFunction to make life easier.

I won't be able to finish this tonight so I've fixed the IsInUnitTest
to run using a copied version of calcInsideness, but the start of the
'reverse' version is there, called dev_calcInsideness.

Attached patch supersedes is_in-function_v8b.patch and it would be good
if it can be applied soon so that, for instance, Arndt, could see if it
fixes his problem with context and parameters.

Ticker

On Wed, 2020-02-12 at 15:55 +0000, Gerd Petermann wrote:

> Hi Ticker,
>
> I found it difficult to test the real style function, that's why I
> moved all the logic out of it.
> I am looking forward to your solution.
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <[hidden email]> im Auftrag
> von Ticker Berkin <[hidden email]>
> Gesendet: Mittwoch, 12. Februar 2020 16:47
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
>
> Hi Gerd
>
> The re-structuring makes this difficult.
>
> I propose a function in IsInUtilTest with the same interface as
> calcInsideness from IsInUtil that somehow drives the real function
> IsIn
> Function to collect and build the IN/ON/OUT intflag.
>
> Ticker
>
> On Wed, 2020-02-12 at 15:28 +0000, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > did you run the unit tests? This should download a newer version of
> > the samples.
> >
> > Gerd
> >
> > ________________________________________
> > Von: mkgmap-dev <[hidden email]> im Auftrag
> > von Ticker Berkin <[hidden email]>
> > Gesendet: Mittwoch, 12. Februar 2020 16:23
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Work on is_in branch
> >
> > Hi Gerd
> >
> > Here it is - changes are:
> >
> > - Some restructuring with early stopping where possible.
> >
> > - Merging polygons for POINT IN/ON test so a point on shared
> > boundary
> > becomes IN rather than ON.
> >
> > - Not merging polygons when no need.
> >
> > - Make the function cacheable, so that there is negligible cost to
> > the
> > second call:
> > highway=path & is_in(landuse, residential, all)=true [0xAA]
> > highway=path & is_in(landuse, residential, all)=false [0xBB]
> >
> > - Improved the layout of documentation in the Style Manual.
> >
> > - Fixed quite a few problems.
> >
> > I've left quite a lot of debug in for the moment, I think there
> > will
> > still be work to do.
> >
> > It gives correct answers to 'point-on.osm'. I haven't worked
> > through
> > is
> > -in-hook-sample-v3.osm yet because I wanted to get this revision
> > out
> > to
> > replace faults in the previous versions.
> >
> > Ticker
> >
> > On Tue, 2020-02-11 at 15:49 +0000, Gerd Petermann wrote:
> > > Hi Ticker,
> > >
> > > whatever you plan to do. I moved the code to the lib because it
> > > is
> > > easier to write a unit test.
> > > I would not invest much time to avoid a few tests which only
> > > happen
> > > in very rare cases. Makes testing more complicated and code less
> > > readable.
> > >
> > > 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

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

Re: Work on is_in branch

Ticker Berkin
In reply to this post by Gerd Petermann
Hi Gerd

Here is patch with:
- IsInUtilTest driver using the is_in function with methods.
- a slight re-formulation to the 'any_in_or_in' method.
- updates to style manual for above.
- some fixes and improvements relating to holes, ON etc.

There is one more bit of logic that is needed for polygons: after the
polygon has been found to be fully within a shape, and it isn't in a
hole, check that a hole isn't within it. I'll so this in the next day
or so.

I'm having trouble with b14 (building is inner to a multi-polygon):
Without merging the cut outer, isLineInShape for the b14 polygon
returns IN/ON/OUT for the first component - I was expecting ON/OUT.
With merging, it returns IN for the merged shape (good), but IN/ON for
the hole - I was expecting ON.

Ticker

On Wed, 2020-02-12 at 15:55 +0000, Gerd Petermann wrote:

> Hi Ticker,
>
> I found it difficult to test the real style function, that's why I
> moved all the logic out of it.
> I am looking forward to your solution.
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <[hidden email]> im Auftrag
> von Ticker Berkin <[hidden email]>
> Gesendet: Mittwoch, 12. Februar 2020 16:47
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
>
> Hi Gerd
>
> The re-structuring makes this difficult.
>
> I propose a function in IsInUtilTest with the same interface as
> calcInsideness from IsInUtil that somehow drives the real function
> IsIn
> Function to collect and build the IN/ON/OUT intflag.
>
> Ticker
>
> On Wed, 2020-02-12 at 15:28 +0000, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > did you run the unit tests? This should download a newer version of
> > the samples.
> >
> > Gerd
> >
> > ________________________________________
> > Von: mkgmap-dev <[hidden email]> im Auftrag
> > von Ticker Berkin <[hidden email]>
> > Gesendet: Mittwoch, 12. Februar 2020 16:23
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Work on is_in branch
> >
> > Hi Gerd
> >
> > Here it is - changes are:
> >
> > - Some restructuring with early stopping where possible.
> >
> > - Merging polygons for POINT IN/ON test so a point on shared
> > boundary
> > becomes IN rather than ON.
> >
> > - Not merging polygons when no need.
> >
> > - Make the function cacheable, so that there is negligible cost to
> > the
> > second call:
> > highway=path & is_in(landuse, residential, all)=true [0xAA]
> > highway=path & is_in(landuse, residential, all)=false [0xBB]
> >
> > - Improved the layout of documentation in the Style Manual.
> >
> > - Fixed quite a few problems.
> >
> > I've left quite a lot of debug in for the moment, I think there
> > will
> > still be work to do.
> >
> > It gives correct answers to 'point-on.osm'. I haven't worked
> > through
> > is
> > -in-hook-sample-v3.osm yet because I wanted to get this revision
> > out
> > to
> > replace faults in the previous versions.
> >
> > Ticker
> >
> > On Tue, 2020-02-11 at 15:49 +0000, Gerd Petermann wrote:
> > > Hi Ticker,
> > >
> > > whatever you plan to do. I moved the code to the lib because it
> > > is
> > > easier to write a unit test.
> > > I would not invest much time to avoid a few tests which only
> > > happen
> > > in very rare cases. Makes testing more complicated and code less
> > > readable.
> > >
> > > 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

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

Re: Work on is_in branch

Gerd Petermann
Hi Ticker,

I don't understand the new meaning of any_in_or_on. Why can't you stop early when ON was found?

I still think that the "stop early" code is just adding complexity. Do you have a sample that shows how this improves performance?

Reg. unexpected results when joining shapes: Welcome to the club! Some not so obvious things:
- The java area code sometimes removes points which are on straight lines.
- a node calculated with e.g. makeBetweenPoint is only very close to the place where it should be

Gerd

________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Ticker Berkin <[hidden email]>
Gesendet: Montag, 17. Februar 2020 11:31
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Work on is_in branch

Hi Gerd

Here is patch with:
- IsInUtilTest driver using the is_in function with methods.
- a slight re-formulation to the 'any_in_or_in' method.
- updates to style manual for above.
- some fixes and improvements relating to holes, ON etc.

There is one more bit of logic that is needed for polygons: after the
polygon has been found to be fully within a shape, and it isn't in a
hole, check that a hole isn't within it. I'll so this in the next day
or so.

I'm having trouble with b14 (building is inner to a multi-polygon):
Without merging the cut outer, isLineInShape for the b14 polygon
returns IN/ON/OUT for the first component - I was expecting ON/OUT.
With merging, it returns IN for the merged shape (good), but IN/ON for
the hole - I was expecting ON.

Ticker

On Wed, 2020-02-12 at 15:55 +0000, Gerd Petermann wrote:

> Hi Ticker,
>
> I found it difficult to test the real style function, that's why I
> moved all the logic out of it.
> I am looking forward to your solution.
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <[hidden email]> im Auftrag
> von Ticker Berkin <[hidden email]>
> Gesendet: Mittwoch, 12. Februar 2020 16:47
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
>
> Hi Gerd
>
> The re-structuring makes this difficult.
>
> I propose a function in IsInUtilTest with the same interface as
> calcInsideness from IsInUtil that somehow drives the real function
> IsIn
> Function to collect and build the IN/ON/OUT intflag.
>
> Ticker
>
> On Wed, 2020-02-12 at 15:28 +0000, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > did you run the unit tests? This should download a newer version of
> > the samples.
> >
> > Gerd
> >
> > ________________________________________
> > Von: mkgmap-dev <[hidden email]> im Auftrag
> > von Ticker Berkin <[hidden email]>
> > Gesendet: Mittwoch, 12. Februar 2020 16:23
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Work on is_in branch
> >
> > Hi Gerd
> >
> > Here it is - changes are:
> >
> > - Some restructuring with early stopping where possible.
> >
> > - Merging polygons for POINT IN/ON test so a point on shared
> > boundary
> > becomes IN rather than ON.
> >
> > - Not merging polygons when no need.
> >
> > - Make the function cacheable, so that there is negligible cost to
> > the
> > second call:
> > highway=path & is_in(landuse, residential, all)=true [0xAA]
> > highway=path & is_in(landuse, residential, all)=false [0xBB]
> >
> > - Improved the layout of documentation in the Style Manual.
> >
> > - Fixed quite a few problems.
> >
> > I've left quite a lot of debug in for the moment, I think there
> > will
> > still be work to do.
> >
> > It gives correct answers to 'point-on.osm'. I haven't worked
> > through
> > is
> > -in-hook-sample-v3.osm yet because I wanted to get this revision
> > out
> > to
> > replace faults in the previous versions.
> >
> > Ticker
> >
> > On Tue, 2020-02-11 at 15:49 +0000, Gerd Petermann wrote:
> > > Hi Ticker,
> > >
> > > whatever you plan to do. I moved the code to the lib because it
> > > is
> > > easier to write a unit test.
> > > I would not invest much time to avoid a few tests which only
> > > happen
> > > in very rare cases. Makes testing more complicated and code less
> > > readable.
> > >
> > > 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: Work on is_in branch

Ticker Berkin
Hi Gerd

The new meaning of any_in_or_on is for handing a line where some is
OUT, none is IN and touching the edge is irrelevant and is tested as
()=false, with the +ve logic being "some-IN or all-ON". Can't stop on
ON because need to have IN component.

This was the the meaning I had originally intended, but at some point
forgot. It is the reciprocal of the method for a line where some is IN
and touching the edge makes no difference.

Various timing tests on a 2 tile area with max-jobs=1, my normal
options and a function invocation in lines.

These are with my latest code:

highway=* & length()<200 {add maxspeed="20 mph"}
Total time taken: 1 minute 12 seconds

highway=* & is_in(landuse,residential,any)=true {add maxspeed="20 mph"}
Total time taken: 1 minute 14 seconds

..., all)...
Total time taken: 1 minute 23 seconds

..., on)...
Total time taken: 1 minute 21 seconds


Taking out the automatic "stop early" code, timings are:

highway=* & is_in(landuse,residential,any)=true {add maxspeed="20 mph"}

Total time taken: 1 minute 17 seconds

..., all)...
Total time taken: 1 minute 24 seconds

..., on)...
Total time taken: 1 minute 23 seconds

ie the "stop-early" gives a slight improvement for "all"/"on" and a bigger improvement for "any"

I feel the "stop-early" mechanism is well hidden from the much more complex coding of isLineInShape() and how the results of this should be interpreted with multiple shapes and holes, etc, and so it is worth-while.

I'm getting strange results for b14 just from the 2 parts of the outer after MP cutting, without the Java2D logic in mergePolygons being invoked. I'll investigate.

Ticker

On Mon, 2020-02-17 at 11:33 +0000, Gerd Petermann wrote:

> Hi Ticker,
>
> I don't understand the new meaning of any_in_or_on. Why can't you
> stop early when ON was found?
>
> I still think that the "stop early" code is just adding complexity.
> Do you have a sample that shows how this improves performance?
>
> Reg. unexpected results when joining shapes: Welcome to the club!
> Some not so obvious things:
> - The java area code sometimes removes points which are on straight
> lines.
> - a node calculated with e.g. makeBetweenPoint is only very close to
> the place where it should be
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <[hidden email]> im Auftrag
> von Ticker Berkin <[hidden email]>
> Gesendet: Montag, 17. Februar 2020 11:31
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
>
> Hi Gerd
>
> Here is patch with:
> - IsInUtilTest driver using the is_in function with methods.
> - a slight re-formulation to the 'any_in_or_in' method.
> - updates to style manual for above.
> - some fixes and improvements relating to holes, ON etc.
>
> There is one more bit of logic that is needed for polygons: after the
> polygon has been found to be fully within a shape, and it isn't in a
> hole, check that a hole isn't within it. I'll so this in the next day
> or so.
>
> I'm having trouble with b14 (building is inner to a multi-polygon):
> Without merging the cut outer, isLineInShape for the b14 polygon
> returns IN/ON/OUT for the first component - I was expecting ON/OUT.
> With merging, it returns IN for the merged shape (good), but IN/ON
> for
> the hole - I was expecting ON.
>
> Ticker
>
> On Wed, 2020-02-12 at 15:55 +0000, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > I found it difficult to test the real style function, that's why I
> > moved all the logic out of it.
> > I am looking forward to your solution.
> >
> > Gerd
> >
> > ________________________________________
> > Von: mkgmap-dev <[hidden email]> im Auftrag
> > von Ticker Berkin <[hidden email]>
> > Gesendet: Mittwoch, 12. Februar 2020 16:47
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Work on is_in branch
> >
> > Hi Gerd
> >
> > The re-structuring makes this difficult.
> >
> > I propose a function in IsInUtilTest with the same interface as
> > calcInsideness from IsInUtil that somehow drives the real function
> > IsIn
> > Function to collect and build the IN/ON/OUT intflag.
> >
> > Ticker
> >
> > On Wed, 2020-02-12 at 15:28 +0000, Gerd Petermann wrote:
> > > Hi Ticker,
> > >
> > > did you run the unit tests? This should download a newer version
> > > of
> > > the samples.
> > >
> > > Gerd
> > >
> > > ________________________________________
> > > Von: mkgmap-dev <[hidden email]> im
> > > Auftrag
> > > von Ticker Berkin <[hidden email]>
> > > Gesendet: Mittwoch, 12. Februar 2020 16:23
> > > An: Development list for mkgmap
> > > Betreff: Re: [mkgmap-dev] Work on is_in branch
> > >
> > > Hi Gerd
> > >
> > > Here it is - changes are:
> > >
> > > - Some restructuring with early stopping where possible.
> > >
> > > - Merging polygons for POINT IN/ON test so a point on shared
> > > boundary
> > > becomes IN rather than ON.
> > >
> > > - Not merging polygons when no need.
> > >
> > > - Make the function cacheable, so that there is negligible cost
> > > to
> > > the
> > > second call:
> > > highway=path & is_in(landuse, residential, all)=true [0xAA]
> > > highway=path & is_in(landuse, residential, all)=false [0xBB]
> > >
> > > - Improved the layout of documentation in the Style Manual.
> > >
> > > - Fixed quite a few problems.
> > >
> > > I've left quite a lot of debug in for the moment, I think there
> > > will
> > > still be work to do.
> > >
> > > It gives correct answers to 'point-on.osm'. I haven't worked
> > > through
> > > is
> > > -in-hook-sample-v3.osm yet because I wanted to get this revision
> > > out
> > > to
> > > replace faults in the previous versions.
> > >
> > > Ticker
> > >
> > > On Tue, 2020-02-11 at 15:49 +0000, Gerd Petermann wrote:
> > > > Hi Ticker,
> > > >
> > > > whatever you plan to do. I moved the code to the lib because it
> > > > is
> > > > easier to write a unit test.
> > > > I would not invest much time to avoid a few tests which only
> > > > happen
> > > > in very rare cases. Makes testing more complicated and code
> > > > less
> > > > readable.
> > > >
> > > > 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: Work on is_in branch

Gerd Petermann
Hi Ticker,

reg. result:
Please find a better explanation for this:
"This is useful for the negative - is_in(...,any_in_or_on)=false - for processing a line that is outside the polgon(s) but might touch an edge."
For me this sounds plain wrong. It would be okay without "but might touch an edge".

reg. performance:
I did not mean to remove early stop completely, I just don't believe that it is worth to distinguish the different methods.
My original code also stops early when result is 7 (IN+ON+OUT).

reg. special case b14: one reason why I don't like my code. It's frustrating. OTOH nobody seems to care about the results for polygons.

Gerd

________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Ticker Berkin <[hidden email]>
Gesendet: Montag, 17. Februar 2020 15:57
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Work on is_in branch

Hi Gerd

The new meaning of any_in_or_on is for handing a line where some is
OUT, none is IN and touching the edge is irrelevant and is tested as
()=false, with the +ve logic being "some-IN or all-ON". Can't stop on
ON because need to have IN component.

This was the the meaning I had originally intended, but at some point
forgot. It is the reciprocal of the method for a line where some is IN
and touching the edge makes no difference.

Various timing tests on a 2 tile area with max-jobs=1, my normal
options and a function invocation in lines.

These are with my latest code:

highway=* & length()<200 {add maxspeed="20 mph"}
Total time taken: 1 minute 12 seconds

highway=* & is_in(landuse,residential,any)=true {add maxspeed="20 mph"}
Total time taken: 1 minute 14 seconds

..., all)...
Total time taken: 1 minute 23 seconds

..., on)...
Total time taken: 1 minute 21 seconds


Taking out the automatic "stop early" code, timings are:

highway=* & is_in(landuse,residential,any)=true {add maxspeed="20 mph"}

Total time taken: 1 minute 17 seconds

..., all)...
Total time taken: 1 minute 24 seconds

..., on)...
Total time taken: 1 minute 23 seconds

ie the "stop-early" gives a slight improvement for "all"/"on" and a bigger improvement for "any"

I feel the "stop-early" mechanism is well hidden from the much more complex coding of isLineInShape() and how the results of this should be interpreted with multiple shapes and holes, etc, and so it is worth-while.

I'm getting strange results for b14 just from the 2 parts of the outer after MP cutting, without the Java2D logic in mergePolygons being invoked. I'll investigate.

Ticker

On Mon, 2020-02-17 at 11:33 +0000, Gerd Petermann wrote:

> Hi Ticker,
>
> I don't understand the new meaning of any_in_or_on. Why can't you
> stop early when ON was found?
>
> I still think that the "stop early" code is just adding complexity.
> Do you have a sample that shows how this improves performance?
>
> Reg. unexpected results when joining shapes: Welcome to the club!
> Some not so obvious things:
> - The java area code sometimes removes points which are on straight
> lines.
> - a node calculated with e.g. makeBetweenPoint is only very close to
> the place where it should be
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <[hidden email]> im Auftrag
> von Ticker Berkin <[hidden email]>
> Gesendet: Montag, 17. Februar 2020 11:31
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Work on is_in branch
>
> Hi Gerd
>
> Here is patch with:
> - IsInUtilTest driver using the is_in function with methods.
> - a slight re-formulation to the 'any_in_or_in' method.
> - updates to style manual for above.
> - some fixes and improvements relating to holes, ON etc.
>
> There is one more bit of logic that is needed for polygons: after the
> polygon has been found to be fully within a shape, and it isn't in a
> hole, check that a hole isn't within it. I'll so this in the next day
> or so.
>
> I'm having trouble with b14 (building is inner to a multi-polygon):
> Without merging the cut outer, isLineInShape for the b14 polygon
> returns IN/ON/OUT for the first component - I was expecting ON/OUT.
> With merging, it returns IN for the merged shape (good), but IN/ON
> for
> the hole - I was expecting ON.
>
> Ticker
>
> On Wed, 2020-02-12 at 15:55 +0000, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > I found it difficult to test the real style function, that's why I
> > moved all the logic out of it.
> > I am looking forward to your solution.
> >
> > Gerd
> >
> > ________________________________________
> > Von: mkgmap-dev <[hidden email]> im Auftrag
> > von Ticker Berkin <[hidden email]>
> > Gesendet: Mittwoch, 12. Februar 2020 16:47
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Work on is_in branch
> >
> > Hi Gerd
> >
> > The re-structuring makes this difficult.
> >
> > I propose a function in IsInUtilTest with the same interface as
> > calcInsideness from IsInUtil that somehow drives the real function
> > IsIn
> > Function to collect and build the IN/ON/OUT intflag.
> >
> > Ticker
> >
> > On Wed, 2020-02-12 at 15:28 +0000, Gerd Petermann wrote:
> > > Hi Ticker,
> > >
> > > did you run the unit tests? This should download a newer version
> > > of
> > > the samples.
> > >
> > > Gerd
> > >
> > > ________________________________________
> > > Von: mkgmap-dev <[hidden email]> im
> > > Auftrag
> > > von Ticker Berkin <[hidden email]>
> > > Gesendet: Mittwoch, 12. Februar 2020 16:23
> > > An: Development list for mkgmap
> > > Betreff: Re: [mkgmap-dev] Work on is_in branch
> > >
> > > Hi Gerd
> > >
> > > Here it is - changes are:
> > >
> > > - Some restructuring with early stopping where possible.
> > >
> > > - Merging polygons for POINT IN/ON test so a point on shared
> > > boundary
> > > becomes IN rather than ON.
> > >
> > > - Not merging polygons when no need.
> > >
> > > - Make the function cacheable, so that there is negligible cost
> > > to
> > > the
> > > second call:
> > > highway=path & is_in(landuse, residential, all)=true [0xAA]
> > > highway=path & is_in(landuse, residential, all)=false [0xBB]
> > >
> > > - Improved the layout of documentation in the Style Manual.
> > >
> > > - Fixed quite a few problems.
> > >
> > > I've left quite a lot of debug in for the moment, I think there
> > > will
> > > still be work to do.
> > >
> > > It gives correct answers to 'point-on.osm'. I haven't worked
> > > through
> > > is
> > > -in-hook-sample-v3.osm yet because I wanted to get this revision
> > > out
> > > to
> > > replace faults in the previous versions.
> > >
> > > Ticker
> > >
> > > On Tue, 2020-02-11 at 15:49 +0000, Gerd Petermann wrote:
> > > > Hi Ticker,
> > > >
> > > > whatever you plan to do. I moved the code to the lib because it
> > > > is
> > > > easier to write a unit test.
> > > > I would not invest much time to avoid a few tests which only
> > > > happen
> > > > in very rare cases. Makes testing more complicated and code
> > > > less
> > > > readable.
> > > >
> > > > 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: Work on is_in branch

Ticker Berkin
Hi Gerd

A simpler way of expressing it in the Style Manual would be:

 +any_in_or_on+ - if is_in(...,any_in_or_on)=false, part is outside,
none is inside.

What do you think? An alternative would be to re-phrase the keyword as
something like 'some-out-none-in', testing for =true instead. But, with
the function being called 'is_in', I wanted to have the methods
expressing IN'ness as far as possible.

Rec. early-stop. It has ~4% improvement for 'any' in my scenario, ~2.5%
for 'on' and ~1% for all.
It just seems easy and sensible to stop when, if asking for 'any', a
part is found IN, or, if asking for 'all', a part is found OUT, etc

Ticker

On Mon, 2020-02-17 at 17:13 +0000, Gerd Petermann wrote:

> Hi Ticker,
>
> reg. result:
> Please find a better explanation for this:
> "This is useful for the negative - is_in(...,any_in_or_on)=false -
> for processing a line that is outside the polgon(s) but might touch
> an edge."
> For me this sounds plain wrong. It would be okay without "but might
> touch an edge".
>
> reg. performance:
> I did not mean to remove early stop completely, I just don't believe
> that it is worth to distinguish the different methods.
> My original code also stops early when result is 7 (IN+ON+OUT).
>
> reg. special case b14: one reason why I don't like my code. It's
> frustrating. OTOH nobody seems to care about the results for
> polygons.
>
> 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: Work on is_in branch

Gerd Petermann
Hi Ticker,

I would except
 +any_in_or_on+ - if is_in(...,any_in_or_on)=false, all is outside, none is in or on the edge.

Or name it
+all_out+ - if is_in(...,all_out)=true, all is outside, none is in or on the edge.

A method that returns true when all is either out or on the edge could be called
+out-or-on+

Gerd

________________________________________
Von: mkgmap-dev <[hidden email]> im Auftrag von Ticker Berkin <[hidden email]>
Gesendet: Montag, 17. Februar 2020 19:11
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Work on is_in branch

Hi Gerd

A simpler way of expressing it in the Style Manual would be:

 +any_in_or_on+ - if is_in(...,any_in_or_on)=false, part is outside,
none is inside.

What do you think? An alternative would be to re-phrase the keyword as
something like 'some-out-none-in', testing for =true instead. But, with
the function being called 'is_in', I wanted to have the methods
expressing IN'ness as far as possible.

Rec. early-stop. It has ~4% improvement for 'any' in my scenario, ~2.5%
for 'on' and ~1% for all.
It just seems easy and sensible to stop when, if asking for 'any', a
part is found IN, or, if asking for 'all', a part is found OUT, etc

Ticker

On Mon, 2020-02-17 at 17:13 +0000, Gerd Petermann wrote:

> Hi Ticker,
>
> reg. result:
> Please find a better explanation for this:
> "This is useful for the negative - is_in(...,any_in_or_on)=false -
> for processing a line that is outside the polgon(s) but might touch
> an edge."
> For me this sounds plain wrong. It would be okay without "but might
> touch an edge".
>
> reg. performance:
> I did not mean to remove early stop completely, I just don't believe
> that it is worth to distinguish the different methods.
> My original code also stops early when result is 7 (IN+ON+OUT).
>
> reg. special case b14: one reason why I don't like my code. It's
> frustrating. OTOH nobody seems to care about the results for
> polygons.
>
> 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: Work on is_in branch

Ticker Berkin
Hi Gerd

The two most common cases that I imagine users will want to match are
lines inside the polygon(s) and lines outside.

Inside lines will frequently meet the edge, and I don't think these
should fail the inside test.

Outside lines will, less frequently, meet the edge, and I don't think
these should fail the outside test.

Often there will be 2 lines, joining at edge of the polygon, that make
a continuous highway that is the entrance to the polygon. Both of these
will have an ON component.

So, the flag test for inside lines should be "hasIn && !hasOut" and for
outside lines should be "hasOut && !hasIn".

Expressing the outside test as the negative, in keeping with the
is_in() methods expressing in-ness, it becomes "hasIn || !hasOut".
I had expressed this as "hasIn || !(hasIn || hasOut)", because "!(hasIn
|| hasOut)" is all_ON, and this matches the method being called,
ambiguously, ANY_IN_OR_ON (ON_OR_ANY_IN would have been better) but
they are logically equivalent.

This expressing as in-ness seems to be the cause of these problems we
are discussing and maybe now is the time to abandon it.

I suggest replacing ANY_IN_OR_ON with SOME_OUT_NONE_IN, giving it the
method string "none", like SOME_IN_NONE_OUT is referenced as "all".

Ticker

On Mon, 2020-02-17 at 19:16 +0000, Gerd Petermann wrote:

> Hi Ticker,
>
> I would except
>  +any_in_or_on+ - if is_in(...,any_in_or_on)=false, all is outside,
> none is in or on the edge.
>
> Or name it
> +all_out+ - if is_in(...,all_out)=true, all is outside, none is in or
> on the edge.
>
> A method that returns true when all is either out or on the edge
> could be called
> +out-or-on+
>
> 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: Work on is_in branch

Gerd Petermann
Ticker Berkin wrote
> I suggest replacing ANY_IN_OR_ON with SOME_OUT_NONE_IN, giving it the
> method string "none", like SOME_IN_NONE_OUT is referenced as "all".

Yes, much better.

Gerd




--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Work on is_in branch

Gerd Petermann
Gerd Petermann wrote
> Ticker Berkin wrote
>> I suggest replacing ANY_IN_OR_ON with SOME_OUT_NONE_IN, giving it the
>> method string "none", like SOME_IN_NONE_OUT is referenced as "all".
>
> Yes, much better.

Thinking again about it. What would be the difference between
is_in(..all)=true and is_in(..none)=false?

My understanding is that we want to distinguish 5 or 6 cases. Three methods
returning true or false should be enough for that.

Gerd



--
Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
_______________________________________________
mkgmap-dev mailing list
[hidden email]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Work on is_in branch

Ticker Berkin
Hi Gerd

Part of the reason for the methods is to group the IN/ON/OUT cases
together in various combinations for meaningful usability.

In IsInUtilTest.java is the table (for the sake of brevity, using
'camel' notation rather than underscores as in the actual method
keyword):
/* all=someInNoneOut, any=anyIn, none=someOutNoneIn
a) IN        all allInOrOn    any
b) IN ON     all allInOrOn    any
c) IN ON OUT                  any
d)    ON         allInOrOn on
e)    ON OUT                      none
f)       OUT                      none
*/

So the difference between ..,all)=true and ..,none)=false is what
happens to cases c) and d).

The methods "any", "on" and "allInOrOn" include these cases. Obvious
and sensible for the meaning of "any" and "on", "allInOrOn" is a bit
arbritary, but the idea is that a perimeter line can be picked up along
with the inside lines in one test if that is what is wanted. I didn't
think there was a need to pick up a perimeter line with the outside
lines, but this could be added easily.

Ticker

On Tue, 2020-02-18 at 00:28 -0700, Gerd Petermann wrote:

> Gerd Petermann wrote
> > Ticker Berkin wrote
> > > I suggest replacing ANY_IN_OR_ON with SOME_OUT_NONE_IN, giving it
> > > the
> > > method string "none", like SOME_IN_NONE_OUT is referenced as
> > > "all".
> >
> > Yes, much better.
>
> Thinking again about it. What would be the difference between
> is_in(..all)=true and is_in(..none)=false?
>
> My understanding is that we want to distinguish 5 or 6 cases. Three
> methods
> returning true or false should be enough for that.
>
> Gerd
>
>
>
> --
> Sent from:
> http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html
> _______________________________________________
> 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
123