[mkgmap-dev] Work on is_in branch

Mon Feb 17 14:57:31 GMT 2020

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 <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> 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 <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> > von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> > 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 <mkgmap-dev-bounces at lists.mkgmap.org.uk> im
> > > Auftrag
> > > von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> > > 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
> > mkgmap-dev at lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev