[ https://issues.apache.org/jira/browse/LUCENE7906?page=com.atlassian.jira.plugin.system.issuetabpanels:commenttabpanel&focusedCommentId=16095888#comment16095888
]
Karl Wright commented on LUCENE7906:

{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 lazyinit 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 almostcoplanar 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 selfoverlapping)
GeoPolygons. You'll need to put some thought into how to construct a random, nondegenerate
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
nonselfintersecting 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: LUCENE7906
> URL: https://issues.apache.org/jira/browse/LUCENE7906
> Project: Lucene  Core
> Issue Type: Improvement
> Components: modules/spatial3d
> Reporter: Ignacio Vera
> Assignee: Karl Wright
> Attachments: LUCENE7906.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, email: devunsubscribe@lucene.apache.org
For additional commands, email: devhelp@lucene.apache.org
