[
https://issues.apache.org/jira/browse/LUCENE-7936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16136470#comment-16136470
]
Karl Wright edited comment on LUCENE-7936 at 8/22/17 9:33 AM:
--------------------------------------------------------------
{quote}
For what I see there, the classes in the package only handle points in Planet
model WGS84. I am interested in the SPHERE, indexing polygons as well as
points. My approach is more similar to the class in spatial-extras Geo3DShape
but creating my custom spatial context which wraps the Geo3dArea shapes.
{quote}
Adding planet model as an enum selector to the existing Lucene integration, or
even as a set of parallel classes, would be a reasonable approach. Robert Muir
wanted to "keep things simple" and very much limit the public API of the
integration. It might be worth looking at the current spatial3d integration as
a model. We certainly do *not* want users to have to understand details of the
PlanetModel class, though. Hope this makes sense.
The spatial-extras module cannot be the way we do this because of the
dependency on spatial-4j. We cannot include that dependency and remain in
lucene-core. You might be able to use it as a model only but for reasons of
API consistency it would be better to look at the integration in spatial3d as
the model.
As for indexing polygons -- adding that is OK to, but please do note that, for
the Lucene integration, the way we specify polygons for the integration uses
Robert's Polygon class, which has no relation at all to GeoPolygon as it is
defined in spatial3d.geom.
{quote}
This is true for generic polygons but the polygons I am working with expand as
much as a few degrees. I made an experiment tonight creating random polygons
that expand less than Math.PI with many points. It was never decomposed using
concave polygons. I do think the library does what I need for my use case.
{quote}
You are correct to state that, for any polygon less that Math.PI in extent, it
will be decomposed solely as GeoConvexPolygon objects. So let's presume that
if you had the right iterator you could inspect the GeoComposite and do the
right thing. Unfortunately, the variants of GeoPolygon are all package-local,
and that's not going to change, so you would need to add something to
GeoPolygon itself to allow you to walk over the individual components in a way
that does not reference any package-private classes in geom. This hints at a
specialized iterator that you'd need to add to GeoPolygon. It's OK to add it
at that level since all polygons are defined by points, and MAY be tiled. For
example:
{code}
TileIterator decompose();
interface TileIterator {
Tile next();
}
interface Tile {
boolean isConvex();
ComponentIterator points();
}
interface ComponentIterator {
GeoPoint next();
}
{code}
That way you can iterate over everything within and not know anything about how
it is put together from the outside.
What do you think?
was (Author: kwri...@metacarta.com):
{quote}
For what I see there, the classes in the package only handle points in Planet
model WGS84. I am interested in the SPHERE, indexing polygons as well as
points. My approach is more similar to the class in spatial-extras Geo3DShape
but creating my custom spatial context which wraps the Geo3dArea shapes.
{quote}
Adding planet model as an enum selector to the existing Lucene integration, or
even as a set of parallel classes, would be a reasonable approach. Robert Muir
wanted to "keep things simple" and very much limit the public API of the
integration. It might be worth looking at the current spatial3d integration as
a model. We certainly do *not* want users to have to understand details of the
PlanetModel class, though. Hope this makes sense.
The spatial-extras module cannot be the way we do this because of the
dependency on spatial-4j. We cannot include that dependency and remain in
lucene-core. You might be able to use it as a model only but for reasons of
API consistency it would be better to look at the integration in spatial3d as
the model.
As for indexing polygons -- adding that is OK to, but please do note that, for
the Lucene integration, the way we specify polygons for the integration uses
Robert's Polygon class, which has no relation at all to GeoPolygon as it is
defined in spatial3d.geom.
{quote}
This is true for generic polygons but the polygons I am working with expand as
much as a few degrees. I made an experiment tonight creating random polygons
that expand less than Math.PI with many points. It was never decomposed using
concave polygons. I do think the library does what I need for my use case.
{quote}
You are correct to state that, for any polygon less that Math.PI in extent, it
will be decomposed solely as GeoConvexPolygon objects. So let's presume that
if you had the right iterator you could inspect the GeoComposite and do the
right thing. Unfortunately, the variants of GeoPolygon are all package-local,
and that's not going to change, so you would need to add something to
GeoPolygon itself to allow you to walk over the individual components in a way
that does not reference any package-private classes in geom. This hints at a
specialized iterator that you'd need to add to GeoPolygon. It's OK to add it
at that level since all polygons are defined by points, and MAY be tiled. For
example:
{code}
TileIterator decompose();
interface TileIterator {
Tile next();
}
interface Tile {
GeoPoint next();
}
{code}
That way you can iterate over everything within and not know anything about how
it is put together from the outside.
What do you think?
> Extend Geoshape interfaces so objects can be copied/serialized
> --------------------------------------------------------------
>
> Key: LUCENE-7936
> URL: https://issues.apache.org/jira/browse/LUCENE-7936
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial3d
> Reporter: Ignacio Vera
> Assignee: Karl Wright
> Attachments: LUCENE-7936.patch
>
>
> Hi [~david.wri...@bksv.com],
> I would like to propose to extends the GeoShape interfaces to be able to
> copy/serialized the objects. The current status and propose change is as
> following:
> GeoPoint: It can be serialized by using x, y, z
> GeoCircle: It can be serialized by using getCenter() and getRadius() and
> getPlanetModel()
> GeoCompositeShape: It can be serialized by accesing shapes using size() and
> GetShape(int index)
> GeoPath: add methods to the interface getPoints() and getCutoffAngle()
> GeoPolygon: This is the most complicated one as we have different types:
> 1.- GeoCompositePolygon is just a composite
> 2.- GeoConcavePolygon and GeoConvexPolygon: Create a new interface for
> those polygons which exposes the points, holes, internaledges and
> concavity/convexity
> 3.- GeoComplexPolygons: Do nothing, they are too complex to be serialize??
> I am intersested in accesing the discreatization of the polygons into convex
> and concave ones for other reasons as well. I think this should be expose as
> they end result can be used for other use cases.
> Cheers,
> I.
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
