Geo: Adds a set of no dependency geo classes for JDBC driver#36477
Geo: Adds a set of no dependency geo classes for JDBC driver#36477imotov merged 16 commits intoelastic:masterfrom
Conversation
Removes all math and WKB parser and refactors WKT parser
|
Pinging @elastic/es-analytics-geo |
alpar-t
left a comment
There was a problem hiding this comment.
I'm missing some context here, but left some questions around the build.
libs/geo/build.gradle
Outdated
| } | ||
| } | ||
|
|
||
| jarHell.enabled = false |
There was a problem hiding this comment.
Why don't we want to check for jar hell ?
libs/geo/build.gradle
Outdated
|
|
||
| testCompile "com.carrotsearch.randomizedtesting:randomizedtesting-runner:${versions.randomizedrunner}" | ||
| testCompile "junit:junit:${versions.junit}" | ||
| testCompile "org.hamcrest:hamcrest-all:${versions.hamcrest}" |
There was a problem hiding this comment.
Aren't these transitive dependencies of the test framework ?
|
Pinging @elastic/es-core-infra |
libs/geo/build.gradle
Outdated
| testCompile "junit:junit:${versions.junit}" | ||
| testCompile "org.hamcrest:hamcrest-all:${versions.hamcrest}" | ||
|
|
||
| if (isEclipse == false || project.path == ":libs:x-content-tests") { |
There was a problem hiding this comment.
This should be :libs:geo-tests which needs to be defined in settings.gradle to keep eclipse happy.
Note to self: We could simplify this setup for the latest Eclipse version (gradle/gradle#4802).
libs/geo/build.gradle
Outdated
| } | ||
|
|
||
| dependencies { | ||
| compile "org.elasticsearch:elasticsearch-core:${version}" |
There was a problem hiding this comment.
Is this needed ? Couldn't find any code that uses it.
|
|
||
| apply plugin: 'elasticsearch.build' | ||
| apply plugin: 'nebula.maven-base-publish' | ||
| apply plugin: 'nebula.maven-scm' |
There was a problem hiding this comment.
Are we planning to publish this jar e.x to maven central ?
Note that we'll have to update the release manager in that case.
We should only configure publishing if we do plan to publish it.
There was a problem hiding this comment.
That's a good question. Its content will be shipped as a part of fat jdbc jar for SQL, but it will also used inside elasticsearch itself for geo operations. So that probably means that it needs to be published, correct?
There was a problem hiding this comment.
That's right, don't forget to add it to release manager.
libs/geo/build.gradle
Outdated
| } | ||
|
|
||
| dependencies { | ||
| if (isEclipse == false || project.path == ":libs:x-geo-tests") { |
There was a problem hiding this comment.
the project should be :libs:geo-tests and it needs to be created in settings.gradle
| projects << 'libs:x-content-tests' | ||
| projects << 'libs:secure-sm-tests' | ||
| projects << 'libs:grok-tests' | ||
| projects << 'libs:geo-tests' |
There was a problem hiding this comment.
There's another conditional for eclipse, line 104 that needs to be updated.
libs/geo/build.gradle
Outdated
| apply plugin: 'nebula.maven-base-publish' | ||
| apply plugin: 'nebula.maven-scm' | ||
|
|
||
| archivesBaseName = 'elasticsearch-geo' |
There was a problem hiding this comment.
NIT: you could have project(':libs:geo').name = "elasticsearch-geo" in settings.gradle instead of this. That would make the publishing block bellow unnecessary and it has the advantage of showing the module name in the IDE as well.
|
@elasticmachine run gradle build tests 2 |
libs/geo/src/main/java/org/elasticsearch/geo/geometry/GeometryVisitor.java
Show resolved
Hide resolved
|
Thanks, let's wait for Nick's review before merging |
nknize
left a comment
There was a problem hiding this comment.
LGTM. I left a couple minor comments that I think could be added in a future PR so we don't hold this up any longer. The big thing would be to start moving our random geometry generators to lucene's GeoTestUtil. Lets open a separate issue for that.
| /** | ||
| * Basic reusable geo-spatial utility methods | ||
| */ | ||
| public final class GeoUtils { |
There was a problem hiding this comment.
There's also o.e.common.geo.GeoUtils I think we'll want to figure out how to best reconcile the two so that there aren't duplicate GeoUtils in two different packages.
There was a problem hiding this comment.
Agree. I renamed it to GeometryUtils when I made changed its visibility.
libs/geo/src/main/java/org/elasticsearch/geo/geometry/GeometryVisitor.java
Show resolved
Hide resolved
| package org.elasticsearch.geo.geometry; | ||
|
|
||
| /** | ||
| * Support class for creating of geometry Visitors |
There was a problem hiding this comment.
Lets add some good javadocs here to clearly explain the design concept.
| return new Point(randomLat(), randomLon()); | ||
| } | ||
|
|
||
| public static LinearRing randomLinearRing() { |
There was a problem hiding this comment.
I think we should reuse lucene's GeoTestUtil for creating these random geometries. There was a lot of work put in to making sure the test suite creates adversarial geometries that have a tendency to expose weaknesses in the API. I don't think that should hold up the PR, though. So lets create a separate issue to migrate some of the random geometry generators over to lucene's geo test suite.
| import org.elasticsearch.geo.utils.WellKnownText; | ||
| import org.elasticsearch.test.ESTestCase; | ||
|
|
||
| public class LinearRingTests extends ESTestCase { |
There was a problem hiding this comment.
Why is it not extending the BaseGeometryTestCase ?
There was a problem hiding this comment.
Ah Ignore... I see it's not supported by WKT...
| this.maxLat = maxLat; | ||
| empty = false; | ||
| if (maxLat < minLat) { | ||
| throw new IllegalArgumentException("max lat cannot be less than min lat"); |
There was a problem hiding this comment.
shouldn't be a check for minLon maxLon as well?
There was a problem hiding this comment.
Nope, it is perfectly valid to have minLon > maxLon, it just means that the Rectangle crosses the dateline.
| package org.elasticsearch.geo.geometry; | ||
|
|
||
| /** | ||
| * Support class for creating of geometry Visitors. |
| public class LinearRing extends Line { | ||
| public static final LinearRing EMPTY = new LinearRing(); | ||
|
|
||
|
|
There was a problem hiding this comment.
Minor: you could remove this empty line.
|
|
||
|
|
||
| private LinearRing() { | ||
|
|
| public static final MultiLine EMPTY = new MultiLine(); | ||
|
|
||
| private MultiLine() { | ||
|
|
| public static final MultiPolygon EMPTY = new MultiPolygon(); | ||
|
|
||
| private MultiPolygon() { | ||
|
|
| tokenizer.wordChars('-', '-'); | ||
| tokenizer.wordChars('+', '+'); | ||
| tokenizer.wordChars('.', '.'); | ||
| tokenizer.whitespaceChars(0, ' '); |
There was a problem hiding this comment.
Why is 0 a whitespaceChar ?
There was a problem hiding this comment.
Not only 0. Basically this line means that everything between 0 and will be treated as a whitespace character. This is to ignore all control characters below space including new line, line feed, tabs, new page etc. by treating it as a whitespace character. I have decided to leave it as is instead of configuring each a subset of character manually since this is the default behavior of StreamTokenizer, but we can be more restrictive here and allow only spaces, tabs and line feeds as suggested in the standard @iverase, @nknize what do you think?
There was a problem hiding this comment.
The standard seems to only allow spaces, tabs or line feeds to improve readability so let's do as recommended.
|
@matriv I pushed the changes that you have requested. Could you take another look? |
matriv
left a comment
There was a problem hiding this comment.
LGTM. Thank you for your patience.
|
I'm curious why not use JTS instead? (BSD-like license, actively maintained, solid implementation, wide spread adoption, without dependencies, ...) |
|
Sorry, looks like this is answered in #35767:
|
This set of geo classes is meant to be used in the JDBC driver to represent geo data and possibly as an intermediate format to pass geo shapes for indexing in #35320.
Relates to #35767 and #35320