MapInfo Pro Developers User Group

Expand all | Collapse all

Order of Object Variables for Spatial Operators

  • 1.  Order of Object Variables for Spatial Operators

    Posted 06-24-2019 07:19
    Hi

    This is a performance question that could be of interest of other users, mostly developers as the real difference may lie in repeated use.

    Image you have two objects a simple object and a complex object, for example a hexagon and an administrative boundary or similar.
    Which of these two spatial comparisons would be faster:

    oHexagon Intersects oAdminBoundary
    or
    oAdminBoundary Intersects oHexagon

    My current, very non-scientific, finding is that the later is a bit faster. It's a matter of 2-4 seconds when doing maybe 500-1000 comparisons.

    If there is a small difference, does that depend on the MBR? Is the difference not always leaning towards the later as it really depends more of the form of the complex polygon than the number of nodes?

    Would we find similar differences - if there actually is any performance difference - when using the Entirely Within or Contains Entire operators?

    Thanks

    ------------------------------
    Peter Horsbøll Møller
    Pitney Bowes
    ------------------------------


  • 2.  RE: Order of Object Variables for Spatial Operators

    Pitney Bowes
    Posted 07-01-2019 15:06
    ​Peter,
    The possible  performance differences in the ordering of intersects operators would be hard to predict.
    In your example, one polygon has only 6 nodes and the municipal boundary something substantially larger.
    The code works like this:

    First of all, if the minimum bounding rectangles (MBR) of the two objects ​are always compared. If they do not overlap then no other processing is performed. In these cases  there should be no difference regarding the number of nodes other than loading from disk, if being read from a table.
    However, if the MBRs do overlap, it is possible the 2 geometries intersect and node/segment level processing has to happen.
    The code first looks at nodes of the second operand region checking if one is inside the first operand region. It stops declaring an intersect if it finds a point within.
    In your case it looks at a maximum of 6 nodes in a point in polygon algorithm against the larger polygon. There are fewer nodes to look at this way but each point in polygon is more complex. Switching the operands around would mean more tests against a simpler (6 node) polygon.  Clearly the order of the nodes within the polygon could be a factor.

    There is still the possibility of an intersect when no nodes are inside. An additional test is done to see if any segment cross each other again using the same order.
    If still no intersection the one last possibility is that the second operand encompasses the first region meaning that no nodes from it are inside the smaller polygon nor do any of its segments intersect.  For this case, the first node of the smaller polygon is tested for being inside the potentially encompassing one.

    Pictures might help.
    Finally, if still no intersection

    ------------------------------
    Eric Blasenheim
    Spectrum Spatial Technical Product Manager
    Troy, NY
    ------------------------------