Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce GeometryTree writer/reader #42331

Merged
merged 2 commits into from May 22, 2019

Conversation

talevy
Copy link
Contributor

@talevy talevy commented May 21, 2019

The GeometryTree represent an Elastisearch Geometry
object. This includes collections like MultiPoint
and GeometryCollection.

For the initial implementation, only polygons without
holes are supported. Later commits will fill in those
holes (see what I did there) and support the other geometries

In a follow-up PR, the GeometryTree will be the object that
interacts with doc-value reading and writing.

relates to #37206

The GeometryTree represent an Elastisearch Geometry
object. This includes collections like MultiPoint
and GeometryCollection.

For the initial implementation, only polygons without
holes are supported.

In a follow-up PR, the GeometryTree will be the object that
interacts with doc-value reading and writing.
@talevy talevy added the :Analytics/Geo Indexing, search aggregations of geo points and shapes label May 21, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-analytics-geo

@talevy
Copy link
Contributor Author

talevy commented May 22, 2019

run elasticsearch-ci/2

@talevy talevy requested a review from imotov May 22, 2019 17:25
Copy link
Contributor

@imotov imotov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left a few comments and suggestions, but as we discussed I am fine with merging this first and then refactoring both GeometryTree and EdgeTree to convert them into Writables and remove most of BytesStreamOutput creation logic outside of the class.

@Override
public Void visit(Point point) {
// TODO
return null;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should throw UnsupportedOperationException for now to make sure that if we ever hit this we know about it. The same for other visit methods.

output.writeInt(builder.minLon);
output.writeInt(builder.minLat);
output.writeInt(builder.maxLon);
output.writeInt(builder.maxLat);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It feels like we could use a Writable bounding box class that knows how to read and write itself as well as check for intersections with other bounding boxes. We could then reuse it and in EdgeTreeWriter, which can also become just an EdgeTree.

*/
public class GeometryTreeWriter {

private final GeometryTreeBuilder builder;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this builder can become a Writable GeometryTree that knows how to write and partially read itself.

class GeometryTreeBuilder implements GeometryVisitor<Void, RuntimeException> {

private List<EdgeTreeWriter> shapeWriters;
int minLat;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add a comment why we are using int here.


@Override
public Void visit(Rectangle r) {
int[] lats = new int[] { (int) r.getMinLat(), (int) r.getMinLat(), (int) r.getMaxLat(), (int) r.getMaxLat(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this conversion to (int) a temporary workaround?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh I see. this is a bug

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will address in followup

for (int i = 0; i < numTrees; i++) {
ShapeType shapeType = input.readEnum(ShapeType.class);
if (ShapeType.POLYGON.equals(shapeType)) {
BytesRef treeRef = input.readBytesRef();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't this create a copy of the entire byte array for the shape? Maybe edgeTree should know how to read itself from ByteBufferStreamInput and calculate relative position or even use skip() instead of position()?

@talevy
Copy link
Contributor Author

talevy commented May 22, 2019

thank you Igor, I will follow-up with the move to a Writeable interface for the tree objects and add more tests around real int-encoded polygons using GeoEncodingUtils.

@talevy talevy merged commit e81ef33 into elastic:geoshape-doc-values May 22, 2019
@talevy talevy deleted the geodv-geotree branch May 22, 2019 21:56
talevy added a commit that referenced this pull request Sep 20, 2019
The GeometryTree represent an Elastisearch Geometry
object. This includes collections like MultiPoint
and GeometryCollection.

For the initial implementation, only polygons without
holes are supported.

In a follow-up PR, the GeometryTree will be the object that
interacts with doc-value reading and writing.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Analytics/Geo Indexing, search aggregations of geo points and shapes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants