abeLayerTouch result question

Hi,

Here is my solution for 1) and 2)

It might be faster than yours and is one step closer to the ABE only realm

(defun abe_layer_connect (abe_l0 abe_l1 abe_out)
    "Add ABE_L0 islands that touch (completely overlap, partially overlap or abut) ABE_L1 to ABE_OUT"
    (let ((abe_touch  (abeNewLayer))
          (abe_island (abeNewLayer))
          (abe_tmp    (abeNewLayer))
          )
    ;; First we compile the touching shapes using the default ABE function
    ;; Then we browse abe_l0 islands and keep the ones overlapping pre-compiled touching shapes
    (abeLayerTouch abe_l0 abe_l1 abe_touch)
    (let ((iter (abeIslandIterator abe_l0)))
      (while (setq island iter->next)
        (abeClearLayer abe_island)
        (abeClearLayer abe_tmp)
        (abeLayerOrPtArray island abe_island)
        (abeLayerAnd abe_island abe_touch abe_tmp)
        (unless (zerop abe_tmp->numTiles) (abeLayerOrPtArray island abe_out))
        ))
    ;; Delete useless layers and return the desired one
    (abeRemoveLayer abe_touch)
    (abeRemoveLayer abe_island)
    (abeRemoveLayer abe_tmp)
    abe_out))

Hope this helps

Cheers

Aurélien

3. Are the islands in geoLayer OR abeIslandIterator sorted by default for number of points?

To the best of my knowledge, the island iterator does not do any kind of sorting - it is designed to deal with millions of shapes as fast as possible, and any kind of sorting would basically kill performance.

For question 4, I would maybe use geometrical algorithm based on dot product to check if a point belong to a segment or not. Then there is classical algorithm to determine whether a point is inside a polygon or not, based on the sign value of the sum of angles from point to all adjacent pairs on point in polygon [it does not work if point is exactly on boundary, so I complement it with first part of answer]

Then as a general comment, it is generally more efficient in SKILL[++] to write a "specific language: based on list than based on strings, because list parsing is immediate in SKILL.

Instead of

"PC touch CA touch M1 touch (...)"

I generally  prefer to write

(touch PC CA M1 ... (and ... (or ... ) )

Which is must easier to parse [use lineread !]

And then for example create a SKILL++ object from the layers (PC, CA...) and method to assemble your objects [which in the end point to geoLayer of course]

This is actually what we did in our company (write a SKILL++ class system on top of ABE, then write a "boolean language parser" - we encapsulate and "augment" all ABE functions into methods working on our objects.

I cannot share the code here for obvious legal reasons, but this may be a way you want to pursue - at least, I can tell you this is working very fine for us, and people seem happy with this SKILL++ layer on top of ABE (I guess Aurelien can confirm ;-) )

Sebastien

Hi Aurel,

 Thank you for your input! I've tested your approach but I hit a hard show stopper with abeLayerOrPtArray() function, which appears to have a limit for maximum size of list of points per polygon (l_points) and throws an error for invalid list. I could not find the exact number, however from experiments it appears to be somewhere between 3K and 6K points. This limitation prevents the code from executing on mesh like (chocolate bar) shapes, because of sheer number of points as it threated as polygon. In some scenarios I have as much as 12K points. 
 I obviously cannot arbitrary slice the list of points to allowed size and process them in turns (or can I ?). So using abeLayerOrPtArray() is a no go and invalidates both yours and mine solutions for for such polygons... 

On a side note: have you noticed performance improvement when you explicitly use abeRemoveLayer() call when you are done with certain geoLayer?

Hey Sebastian,

 Thanks for chiming in. This is pretty much exactly what I am also trying to do. I do leverage SKILL++ class system, but I use strings instead of lists because A) this would be main way to supply input to the code and B) I personally think infix notation (A+B) is easier on the eyes for people not familiar with Lisp than prefix notation (+AB)  : )
 I am not familiar in details with the algorithm you are referring to, but I can search around the web for more detailed explanation and try it as alternative for mine.

 From few experiments, I couldn't conclusively conclude whether abeIslandIterator() (or how geoLayer data is presented) doesn't at least follow some logic when you go over the islands. In my test, the polygon with most points was never last in the list. This is just me thinking if I can reap any benefit from choosing reverse order of traversing in case I have to keep with my solution.

About abeRemoveLayer I haven't noticed anything but I haven't try neither...

I guess you could use the profilers to check if it increases the performances. It might be interesting to do but should require meaningful testcases (your layouts seem complex enough though)

To me the behaviour I expect is just for Virtuoso to make the generated layers available for the garbage collector to clear them when memory is required

And from my developer point of view I want my function to act as a black box which just does what is defined in its docstring and does not pollute its environment