[
https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16095888#comment-16095888
]
Karl Wright commented on LUCENE-7906:
-------------------------------------
{quote}
The problem with convex polygons is that the whole plane is within the shape
and therefore if you try to bound the intersection with the convex polygon you
get OVERLAP when the shape is actually WITHIN. What it holds true is that the
bounds for an intersection for convex polygons are the ones defined by the
convex counter part. Therefore I need to invert the shape to bound the
intersection. The class variable is to cash the object so it is only created
once. Does it make sense?
{quote}
Yes, I understand the limitations. I'm not, however, thrilled with the
lazy-init part of this since it gives us some thread safety concerns, and the
"inverse shape" way of doing things has problems as I described earlier. If
all you are trying to do is model the bounds for each edge plane, you're
probably better off, and safer too, computing and saving those bounds when the
polygon is constructed. You'll especially need to worry about almost-coplanar
adjacent polygon edges; it may be better to construct a pair of perpendicular
planes for each edge if you need a good bound. Or, you can use the adjoining
edges but just invert their sidedness; there's a SidedPlane constructor that
does that. Let me look carefully at the code for both kinds of polygon and
give you my recommendation.
The above concerns are exactly why randomized tests are so valuable, by the
way, and why they really need to be there before we can have assurance that
your implementation is not going to generate a slew of bug reports when it hits
the real world.
The randomized tests I pointed you at earlier construct mainly GeoBBox shapes
to intersect against. You'd want almost the same test but with random (but
regular and not self-overlapping) GeoPolygons. You'll need to put some thought
into how to construct a random, non-degenerate GeoConvexPolygon or
GeoConcavePolygon, especially with holes. There are IllegalArgumentException
conditions thrown by the constructors when shapes are found to be illegal for
some reason, but I believe we removed some of these in the polygon constructors
because of their cost. Other randomized tests that construct GeoPolygons use a
center point, and walk around the center point N times with a random angle each
time and a random arc distance; that guarantees non-self-intersecting but
doesn't prevent concavity/convexity. You could use the GeoPolygonFactory
method, though, to create a composite polygon from this consisting of multiple
child shapes and that is guaranteed to work and be legal. So I encourage you
to look at how polygon construction is done in the existing tests.
Thanks!
> Spatial relationship between Geoshapes
> --------------------------------------
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial3d
> Reporter: Ignacio Vera
> Assignee: Karl Wright
> Attachments: LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between
> them I came accross a big limitation when trying to solve the relationship
> between two geopolygons. This object does not expose the internal structure.
> In particular at some point, it is necessary to check if one polygon
> intersects the edges of the other polygon which currently is not possible as
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the
> edges) adding getters in the GeoPolygon interface. Easy to implement and
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make
> the spatial relationship.
> 3) Extends GeoShape interface so all shapes can infer the spatial
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there
> might be some cases which what I propose cannot be implemented or are againts
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
