[
https://issues.apache.org/jira/browse/LUCENE-7936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16136663#comment-16136663
]
Karl Wright commented on LUCENE-7936:
-------------------------------------
[~ivera], thanks for the code patches.
I think we need to involve [~dsmiley] if you want to extend what's in
spatial-extras; he's the primary author of that module. David, what is your
opinion as to the spatial4j patch proposed?
As for the binary codec, I'll have to think about how best to structure this.
Usually, as I've indicated, it's better for packages structured as interfaces
with multiple implementations to have each object know how to pack itself and
unpack itself, rather than supporting deep inspection and writing a wrapper.
Too much internal information has to be exposed to do the latter.
I can see adding basic methods to all Geo3D objects for encoding to, and
decoding from, a codec binary stream. As long as these methods can be written
efficiently, and the streams they read from/write to are standard in Lucene
core or in the Java util package, I see no reason not to make this a standard
feature of Geo3d. A typical pattern would look something like this:
{code}
public MyObject(final InputStream is) throws IOException {
...
}
...
@Override
public void write(final OutputStream os) throws IOException {
...
}
{code}
To be fully general, the interface-implementing class name would need to be
included in the stream, and instantiated by reflection when the stream is read
back. This uses a fair bit of space but for your purposes might well be OK.
Please let me know. I'll think on this further.
> 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: GeoBinaryCodec.patch, LUCENE-7936.patch, Spatial4j.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
