Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 7.1
    • Component/s: modules/spatial-extras
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      Hi,

      After the latest developments in the Geo3d library, in particular:

      https://issues.apache.org/jira/browse/LUCENE-7906 : Spatial relationships between GeoShapes
      https://issues.apache.org/jira/browse/LUCENE-7936: Serialization of GeoShapes.

      I propose a new set of wrapper classes which can be for example linked to Solr as they implement their own SpatialContextFactory. It provides the capability of indexing shapes with
      spherical geometry.

      Thanks!

      1. LUCENE_7951_build.patch
        2 kB
        David Smiley
      2. LUCENE_7951_build.patch
        1 kB
        David Smiley
      3. LUCENE-7951.patch
        76 kB
        David Smiley
      4. LUCENE-7951.patch
        81 kB
        Ignacio Vera
      5. LUCENE-7951.patch
        78 kB
        Ignacio Vera

        Issue Links

          Activity

          Hide
          ivera Ignacio Vera added a comment -

          Attached is the patch. A few considerations:

          LINESTRING: This shape is mapped to Geo3d GeoPath but it does not support paths with cutoff angles equal to 0. Therfore I am setting that value to 1e-10.

          BUFFER: The Satial4j buffer extension is partially supported.

          In addition the DistanceCalculator needs to be reviewed.

          Show
          ivera Ignacio Vera added a comment - Attached is the patch. A few considerations: LINESTRING: This shape is mapped to Geo3d GeoPath but it does not support paths with cutoff angles equal to 0. Therfore I am setting that value to 1e-10. BUFFER: The Satial4j buffer extension is partially supported. In addition the DistanceCalculator needs to be reviewed.
          Hide
          dsmiley David Smiley added a comment -

          Thanks for contributing this Ignacio!

          Geo3dSpatialContextFactory:

          • this should override init() in order to populate the planet model. See the SCF impl to see how this is done for other settings. On the Solr side, the field type settings will be read using init().
          • make planetModel field public and not final. This is to be consistent with SCF. I know it's a bit unusual.
          • override initCalculator() to see if the value is something like "geo3d" and if so then set distCalc that way, let the superclass handle it.

          I was a little surprised to see you didn't subclass SpatialContext with a Geo3d one but it's cool that you didn't have to, actually.

          Geo3dShapeFactory:

          • Constructor: Should not reference PlanetModel.WGS84 explicitly but instead reference a proposed Geo3dSpatialContextFactory.DEFAULT_PLANET_MODEL ? Or instead, just assume Geo3dSpatialContextFactory is in use and fail with the ClassCastException if it isn't? I like the simplicity of the latter; either work for me.
          • Should probably have the "normWrapLongitude" logic that can be seen in ShapeFactoryImpl. Likewise the lat/lon bounds verification. You can probably have the verify logic assume decimal degrees here (-/+ 180 etc.) since Geo3d assumes this.
          • inner classes: the default constructors found in this class are superfluous; they can be removed. Also these classes can be made private.

          Geo3dPointShape:

          • consider removing "Shape" suffix; the Circle, Rectangle ones don't have this. Or maybe they should have them? I don't care; just be consistent.
          • minor: typo in javadoc for Geo3dAreShape. I prefer to use {{ {@link ... }

            }} in general as the IDE helps keep this right.

          Geo3dDistanceCalculator:

          • It appears this is only necessary when the planet model isn't a sphere, as Spatial4j's default dist calculator is for spherical. I suggest letting the distance calculator default. I worry that Geo3d's impl is too slow; it sure looks slow!

          I'll review more of this code later.

          Show
          dsmiley David Smiley added a comment - Thanks for contributing this Ignacio! Geo3dSpatialContextFactory: this should override init() in order to populate the planet model. See the SCF impl to see how this is done for other settings. On the Solr side, the field type settings will be read using init(). make planetModel field public and not final. This is to be consistent with SCF. I know it's a bit unusual. override initCalculator() to see if the value is something like "geo3d" and if so then set distCalc that way, let the superclass handle it. I was a little surprised to see you didn't subclass SpatialContext with a Geo3d one but it's cool that you didn't have to, actually. Geo3dShapeFactory: Constructor: Should not reference PlanetModel.WGS84 explicitly but instead reference a proposed Geo3dSpatialContextFactory.DEFAULT_PLANET_MODEL ? Or instead, just assume Geo3dSpatialContextFactory is in use and fail with the ClassCastException if it isn't? I like the simplicity of the latter; either work for me. Should probably have the "normWrapLongitude" logic that can be seen in ShapeFactoryImpl. Likewise the lat/lon bounds verification. You can probably have the verify logic assume decimal degrees here (-/+ 180 etc.) since Geo3d assumes this. inner classes: the default constructors found in this class are superfluous; they can be removed. Also these classes can be made private. Geo3dPointShape: consider removing "Shape" suffix; the Circle, Rectangle ones don't have this. Or maybe they should have them? I don't care; just be consistent. minor: typo in javadoc for Geo3dAreShape. I prefer to use {{ {@link ... } }} in general as the IDE helps keep this right. Geo3dDistanceCalculator: It appears this is only necessary when the planet model isn't a sphere, as Spatial4j's default dist calculator is for spherical. I suggest letting the distance calculator default. I worry that Geo3d's impl is too slow; it sure looks slow! I'll review more of this code later.
          Hide
          kwright@metacarta.com Karl Wright added a comment -

          Ignacio Vera, David Smiley, the distance calculator Ignacio wrote is designed to work with all planet models, not just spheres, and to compute surface distance, not arc distance. Unfortunately, it's an expensive iterative calculation, and there's no better way to do it if you want true surface distance.

          I don't know what Ignacio's use case is, or whether spatial4j has any particular meaning assigned to the "distance" so computed, but if you just want reasonably fast distances and do not need surface distance, you could use any one of the geo3d's distance metrics, e.g. arc distance or linear distance. The latter would be the cheapest but is only useful for distances less than halfway around the globe.

          Show
          kwright@metacarta.com Karl Wright added a comment - Ignacio Vera , David Smiley , the distance calculator Ignacio wrote is designed to work with all planet models, not just spheres, and to compute surface distance, not arc distance. Unfortunately, it's an expensive iterative calculation, and there's no better way to do it if you want true surface distance. I don't know what Ignacio's use case is, or whether spatial4j has any particular meaning assigned to the "distance" so computed, but if you just want reasonably fast distances and do not need surface distance, you could use any one of the geo3d's distance metrics, e.g. arc distance or linear distance. The latter would be the cheapest but is only useful for distances less than halfway around the globe.
          Hide
          ivera Ignacio Vera added a comment -

          Thanks for the comments! please feel free to add more as tomorrow I will have a couple of hours tomorrow to put as many as possible together.

          Regarding the shape suffix for points: It is there for two reasons: 1) There is already a Geo3DPoint in spatial3d package and I didn't like the class to have a similar name 2) There is always a conflic between a point being a component of shape (~ GeoPoint) and a point behaving like a shape. I thought in this case it stress the functionality of the class. But if you feel that it is better to remove the suffix I do not feel so strong about it.

          Regarding the distance calculator: I implemented this way because I felt it should work for any planet model. In my particular use case, I am using an external function because I need point-shape distance which is supported in Geo3d but not in Spatial4j. I am ok letting the default one although still exact calculations might be useful regardless the performance penalty for some users.

          Show
          ivera Ignacio Vera added a comment - Thanks for the comments! please feel free to add more as tomorrow I will have a couple of hours tomorrow to put as many as possible together. Regarding the shape suffix for points: It is there for two reasons: 1) There is already a Geo3DPoint in spatial3d package and I didn't like the class to have a similar name 2) There is always a conflic between a point being a component of shape (~ GeoPoint) and a point behaving like a shape. I thought in this case it stress the functionality of the class. But if you feel that it is better to remove the suffix I do not feel so strong about it. Regarding the distance calculator: I implemented this way because I felt it should work for any planet model. In my particular use case, I am using an external function because I need point-shape distance which is supported in Geo3d but not in Spatial4j. I am ok letting the default one although still exact calculations might be useful regardless the performance penalty for some users.
          Hide
          dsmiley David Smiley added a comment -

          Lets then add "Shape" suffix to those classes here implementing Shape.

          RE DistanceCalculator – okay. Accurate by default then.

          Show
          dsmiley David Smiley added a comment - Lets then add "Shape" suffix to those classes here implementing Shape. RE DistanceCalculator – okay. Accurate by default then.
          Hide
          ivera Ignacio Vera added a comment -

          Attached a new patch with the proposed improvements.

          • Clean up javadoc
          • Geo3dBinaryCodec & Geo3dShapeFactory assume always a Geo3dSpatialContextFactory
          • Remove unnecessary constructors in inner classes and made them private
          • Override init() method in Geo3dSpatialContextFactory. Currently only sphere and wsg84 planet models supported. What is the preferred syntax for a user defined planet model?
          • Make GeoDistanceCalculator default but it can be override.
          • Default planet model in factory: Sphere
          • Added Shape suffix to all shapes

          On another subject, Karl Wright, would it make sense to add a new GeoShape for degenerated paths (cutoff angle < MINIMUM_RESOLUTION)?

          Show
          ivera Ignacio Vera added a comment - Attached a new patch with the proposed improvements. Clean up javadoc Geo3dBinaryCodec & Geo3dShapeFactory assume always a Geo3dSpatialContextFactory Remove unnecessary constructors in inner classes and made them private Override init() method in Geo3dSpatialContextFactory. Currently only sphere and wsg84 planet models supported. What is the preferred syntax for a user defined planet model? Make GeoDistanceCalculator default but it can be override. Default planet model in factory: Sphere Added Shape suffix to all shapes On another subject, Karl Wright , would it make sense to add a new GeoShape for degenerated paths (cutoff angle < MINIMUM_RESOLUTION)?
          Hide
          kwright@metacarta.com Karl Wright added a comment -

          would it make sense to add a new GeoShape for degenerated paths (cutoff angle < MINIMUM_RESOLUTION)

          It might, if you define such a shape as consisting of points exactly on the path. There would be no need for endpoint circles either, obviously, so the implementation would be easy. If you need such a thing, please create a new ticket for it though.

          Show
          kwright@metacarta.com Karl Wright added a comment - would it make sense to add a new GeoShape for degenerated paths (cutoff angle < MINIMUM_RESOLUTION) It might, if you define such a shape as consisting of points exactly on the path. There would be no need for endpoint circles either, obviously, so the implementation would be easy. If you need such a thing, please create a new ticket for it though.
          Hide
          kwright@metacarta.com Karl Wright added a comment -

          David Smiley, I think that since this is mainly a spatial4j extension, you probably ought to be the one to take charge of landing it on master etc. If that's OK with you, can you assign this ticket to yourself? Thanks!

          Show
          kwright@metacarta.com Karl Wright added a comment - David Smiley , I think that since this is mainly a spatial4j extension, you probably ought to be the one to take charge of landing it on master etc. If that's OK with you, can you assign this ticket to yourself? Thanks!
          Hide
          dsmiley David Smiley added a comment -

          Ignacio Vera I'd prefer a GitHub Pull Request if we make further changes. You need need to reference this LUCENE-7951 in the PR title. But if that's inconvenient for you then we can continue with patch files nonetheless. Locally I've modified a couple things a bit; if we go the PR route it's easier for me to retain them as we go.

          Why the distinction between Geo3dAreaShape & Geo3dShape? I doubt we need both but maybe I'm missing something.

          RandomGeoShapeGenerator

          • I love it. Did you extract this from Geo3dRptTest? Maybe this ought to live in spatial-3d test area and simply referenced here? What do you think Karl Wright?
          • I think the "Geo" should be "Geo3d" in its name for clarity.
          Show
          dsmiley David Smiley added a comment - Ignacio Vera I'd prefer a GitHub Pull Request if we make further changes. You need need to reference this LUCENE-7951 in the PR title. But if that's inconvenient for you then we can continue with patch files nonetheless. Locally I've modified a couple things a bit; if we go the PR route it's easier for me to retain them as we go. Why the distinction between Geo3dAreaShape & Geo3dShape? I doubt we need both but maybe I'm missing something. RandomGeoShapeGenerator I love it. Did you extract this from Geo3dRptTest? Maybe this ought to live in spatial-3d test area and simply referenced here? What do you think Karl Wright ? I think the "Geo" should be "Geo3d" in its name for clarity.
          Hide
          kwright@metacarta.com Karl Wright added a comment -

          David Smiley I'm fine if you want to cut down on code duplication by putting random shape generation in spatial-3d.
          I agree that Geo->Geo3d.
          The distinction between an "area shape" and a "shape" is that one implements GeoArea and the other does not. Some shapes are not amenable to implementing this geo3d interface.

          Show
          kwright@metacarta.com Karl Wright added a comment - David Smiley I'm fine if you want to cut down on code duplication by putting random shape generation in spatial-3d. I agree that Geo->Geo3d. The distinction between an "area shape" and a "shape" is that one implements GeoArea and the other does not. Some shapes are not amenable to implementing this geo3d interface.
          Hide
          ivera Ignacio Vera added a comment -

          David Smiley, I am ok with the pull request but I have never done it so I am trying to figure out how to do it.

          GeoAreaShapes know how to relate spatially with other shapes, Geoshape do not need to. Current generated shapes from Spatial4j can relate spatially. The question here is if we are keeping the current Geo3dShape implementation or we override it with this new version.

          RandomGeoShapeGenerator was originally developed to test spatial relationships between GeoAreaShapes. There is currently two versions, one in spatial-3d test and one in spatial-extras-test. I don't know if I am missing something but I had to copy the class or precommit will complain. Unfortunately, there are now slightly difference but I think we should only have one class that can be referenced.

          Show
          ivera Ignacio Vera added a comment - David Smiley , I am ok with the pull request but I have never done it so I am trying to figure out how to do it. GeoAreaShapes know how to relate spatially with other shapes, Geoshape do not need to. Current generated shapes from Spatial4j can relate spatially. The question here is if we are keeping the current Geo3dShape implementation or we override it with this new version. RandomGeoShapeGenerator was originally developed to test spatial relationships between GeoAreaShapes. There is currently two versions, one in spatial-3d test and one in spatial-extras-test. I don't know if I am missing something but I had to copy the class or precommit will complain. Unfortunately, there are now slightly difference but I think we should only have one class that can be referenced.
          Hide
          githubbot ASF GitHub Bot added a comment -

          GitHub user iverase opened a pull request:

          https://github.com/apache/lucene-solr/pull/246

          LUCENE-7951: New wrapper classes for Geo3d

          Create a pull request for LUCENE-7951

          You can merge this pull request into a Git repository by running:

          $ git pull https://github.com/iverase/lucene-solr origin/LUCENE-7951

          Alternatively you can review and apply these changes as the patch at:

          https://github.com/apache/lucene-solr/pull/246.patch

          To close this pull request, make a commit to your master/trunk branch
          with (at least) the following in the commit message:

          This closes #246


          commit 3ba3dad6b7169b73f3340f518f151511f149e266
          Author: ivera <ivera@eso.org>
          Date: 2017-09-07T08:05:18Z

          LUCENE-7951: first version

          commit ea31e5ce0f377fe23f2d4446fccb5a8e8c52690d
          Author: ivera <ivera@eso.org>
          Date: 2017-09-07T08:09:07Z

          LUCENE-7951: first version


          Show
          githubbot ASF GitHub Bot added a comment - GitHub user iverase opened a pull request: https://github.com/apache/lucene-solr/pull/246 LUCENE-7951 : New wrapper classes for Geo3d Create a pull request for LUCENE-7951 You can merge this pull request into a Git repository by running: $ git pull https://github.com/iverase/lucene-solr origin/ LUCENE-7951 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/246.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #246 commit 3ba3dad6b7169b73f3340f518f151511f149e266 Author: ivera <ivera@eso.org> Date: 2017-09-07T08:05:18Z LUCENE-7951 : first version commit ea31e5ce0f377fe23f2d4446fccb5a8e8c52690d Author: ivera <ivera@eso.org> Date: 2017-09-07T08:09:07Z LUCENE-7951 : first version
          Hide
          dsmiley David Smiley added a comment -

          I think Geo3d randomized shape generation should exist in one place, in it's test classpath somewhere. Now is a great time to do that. If precommit or the build otherwise complains, we can probably figure that out; I'll look closer at such possible errors if you move it there.

          Perhaps the Spatial4j integration should imply "GeoArea". I don't think we need two base shape implementations. Likewise, perhaps just one test, merging in the tests from the one you developed and the existing one. The ability to "intersect" two Shapes is fundamental to the assumptions of Spatial4j, and thus Geo3d's "GeoAreaShape" is required, I think.

          Show
          dsmiley David Smiley added a comment - I think Geo3d randomized shape generation should exist in one place, in it's test classpath somewhere. Now is a great time to do that. If precommit or the build otherwise complains, we can probably figure that out; I'll look closer at such possible errors if you move it there. Perhaps the Spatial4j integration should imply "GeoArea". I don't think we need two base shape implementations. Likewise, perhaps just one test, merging in the tests from the one you developed and the existing one. The ability to "intersect" two Shapes is fundamental to the assumptions of Spatial4j, and thus Geo3d's "GeoAreaShape" is required, I think.
          Hide
          ivera Ignacio Vera added a comment - - edited

          The following error is thrown by precommit if you try to use the random generator in spatial-3d:

          error: cannot find symbol
          [javac] import org.apache.lucene.spatial3d.geom.RandomGeoShapeGenerator;
          [javac] ^
          [javac] symbol: class RandomGeoShapeGenerator
          [javac] location: package org.apache.lucene.spatial3d.geom
          [javac] 1 error

          BUILD FAILED

          It seems you cannot share classes inside different test packages.

          Regarding GeoArea: Do you mean that this implementation will replace the current one? e.g. rename Geo3dAreaShape to Geo3dShape. That was my original idea as current implementation is very limited and now we can really make a full integration. Spatial relationship resolution was the first milestone to be able to complete this integration.

          Show
          ivera Ignacio Vera added a comment - - edited The following error is thrown by precommit if you try to use the random generator in spatial-3d: error: cannot find symbol [javac] import org.apache.lucene.spatial3d.geom.RandomGeoShapeGenerator; [javac] ^ [javac] symbol: class RandomGeoShapeGenerator [javac] location: package org.apache.lucene.spatial3d.geom [javac] 1 error BUILD FAILED It seems you cannot share classes inside different test packages. Regarding GeoArea: Do you mean that this implementation will replace the current one? e.g. rename Geo3dAreaShape to Geo3dShape. That was my original idea as current implementation is very limited and now we can really make a full integration. Spatial relationship resolution was the first milestone to be able to complete this integration.
          Hide
          dsmiley David Smiley added a comment -

          The attached build patch file I developed modifies spatial-extras's build.xml to include the test classpath of spatial3d. This seems to work; I'm even doing the maven based build and it's working.

          Show
          dsmiley David Smiley added a comment - The attached build patch file I developed modifies spatial-extras's build.xml to include the test classpath of spatial3d. This seems to work; I'm even doing the maven based build and it's working.
          Hide
          dsmiley David Smiley added a comment -

          I propose the contents of the Geo3dSpatialContextFactory class look like this:

          
            public static final PlanetModel DEFAULT_PLANET_MODEL = PlanetModel.SPHERE;
          
            public PlanetModel planetModel = DEFAULT_PLANET_MODEL;
          
            public Geo3dSpatialContextFactory() {
              this.binaryCodecClass = Geo3dBinaryCodec.class;
              this.shapeFactoryClass = Geo3dShapeFactory.class;
              this.distCalc = new Geo3dDistanceCalculator(planetModel);
            }
          
            @Override
            protected void init(Map<String, String> args, ClassLoader classLoader) {
              super.init(args, classLoader);
              initPlanetModel(args);
            }
          
            protected void initPlanetModel(Map<String, String> args) {
              String planetModel = args.get("planetModel");
              if (planetModel != null) {
                if (planetModel.equalsIgnoreCase("sphere")) {
                  this.planetModel = PlanetModel.SPHERE;
                } else if (planetModel.equalsIgnoreCase("wgs84")) {
                  this.planetModel = PlanetModel.WGS84;
                } else {
                  throw new RuntimeException("Unknown planet model: " + planetModel);
                }
              }
            }
          
            @Override
            protected void initCalculator() {
              String calcStr = this.args.get("distCalculator");
              if (calcStr == null || calcStr.equals("geo3d")) {
                return;// we already have Geo3d
              }
              super.initCalculator(); // some other distance calculator
            }
          

          Notice that you don't have to even call init(args). Some tests (in Spatial4j) and some here create the factory, manually set some fields directly, and then finally called newSpatialContext() while never calling init(args). init(args) is optional, designed for when you have name-value pair based configuration, e.g. Solr field type.

          Show
          dsmiley David Smiley added a comment - I propose the contents of the Geo3dSpatialContextFactory class look like this: public static final PlanetModel DEFAULT_PLANET_MODEL = PlanetModel.SPHERE; public PlanetModel planetModel = DEFAULT_PLANET_MODEL; public Geo3dSpatialContextFactory() { this .binaryCodecClass = Geo3dBinaryCodec.class; this .shapeFactoryClass = Geo3dShapeFactory.class; this .distCalc = new Geo3dDistanceCalculator(planetModel); } @Override protected void init(Map< String , String > args, ClassLoader classLoader) { super .init(args, classLoader); initPlanetModel(args); } protected void initPlanetModel(Map< String , String > args) { String planetModel = args.get( "planetModel" ); if (planetModel != null ) { if (planetModel.equalsIgnoreCase( "sphere" )) { this .planetModel = PlanetModel.SPHERE; } else if (planetModel.equalsIgnoreCase( "wgs84" )) { this .planetModel = PlanetModel.WGS84; } else { throw new RuntimeException( "Unknown planet model: " + planetModel); } } } @Override protected void initCalculator() { String calcStr = this .args.get( "distCalculator" ); if (calcStr == null || calcStr.equals( "geo3d" )) { return ; // we already have Geo3d } super .initCalculator(); // some other distance calculator } Notice that you don't have to even call init(args). Some tests (in Spatial4j) and some here create the factory, manually set some fields directly, and then finally called newSpatialContext() while never calling init(args). init(args) is optional, designed for when you have name-value pair based configuration, e.g. Solr field type.
          Hide
          ivera Ignacio Vera added a comment -

          Hi David Smiley,

          Updating the configuration files makes precommit happy indeed.

          I updated Geo3dSpatialContextFactory accordingly but note that:

          • initPlanetModel(args) must be called first so generated objects get the right planet model.
          • We must always construct the calculator if initCalculator() is called as the planet model can be different.

          If you agree I can relce current Geo3dShape with the new one and migrate the test.

          BTW, is the pull request I created correct?

          Show
          ivera Ignacio Vera added a comment - Hi David Smiley , Updating the configuration files makes precommit happy indeed. I updated Geo3dSpatialContextFactory accordingly but note that: initPlanetModel(args) must be called first so generated objects get the right planet model. We must always construct the calculator if initCalculator() is called as the planet model can be different. If you agree I can relce current Geo3dShape with the new one and migrate the test. BTW, is the pull request I created correct?
          Hide
          dsmiley David Smiley added a comment -

          We must always construct the calculator if initCalculator() is called as the planet model can be different.

          Oh I see. Instead I suggest letting the planet model and calculator fields be null initially. Overriding factory.newSpatialContext will allow us to do these checks. This way, init(map) is still optional – consistent with the other SpatialContextFactory impls. There is a similar situation for "worldBounds". In that case, the default SpatialContext impl knows checks and has defaulting logic Since we don't have a custom SpatialContext impl for Geo3D, we could just as easily override factory.newSpatialContext.

          The PR looks good; I'll make further comments there. Thanks for doing a PR.

          Show
          dsmiley David Smiley added a comment - We must always construct the calculator if initCalculator() is called as the planet model can be different. Oh I see. Instead I suggest letting the planet model and calculator fields be null initially. Overriding factory.newSpatialContext will allow us to do these checks. This way, init(map) is still optional – consistent with the other SpatialContextFactory impls. There is a similar situation for "worldBounds". In that case, the default SpatialContext impl knows checks and has defaulting logic Since we don't have a custom SpatialContext impl for Geo3D, we could just as easily override factory.newSpatialContext. The PR looks good; I'll make further comments there. Thanks for doing a PR.
          Hide
          ivera Ignacio Vera added a comment -

          I put a new version where planetModel and distanceCalculator are initially null, but factory.newSpatialContext sets the defaults if init(map) is not called.

          The issue with worldBounds is a bit nastier. I cannot really override it and it is currently building one that is not a Geo3dShape. The issue is that to build a shape I need the SpatialContext and the SpatialContext needs the Shape to set the worldBounds. Therefore it uses the default mechanism which does not use the ShapeFactory but creates a Spatial4j RectangleImpl.

          Show
          ivera Ignacio Vera added a comment - I put a new version where planetModel and distanceCalculator are initially null, but factory.newSpatialContext sets the defaults if init(map) is not called. The issue with worldBounds is a bit nastier. I cannot really override it and it is currently building one that is not a Geo3dShape. The issue is that to build a shape I need the SpatialContext and the SpatialContext needs the Shape to set the worldBounds. Therefore it uses the default mechanism which does not use the ShapeFactory but creates a Spatial4j RectangleImpl.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user dsmiley commented on a diff in the pull request:

          https://github.com/apache/lucene-solr/pull/246#discussion_r137825324

          — Diff: lucene/spatial-extras/src/test/org/apache/lucene/spatial/spatial4j/Geo3dAreaRptTest.java —
          @@ -40,10 +41,10 @@

          SpatialContext ctx;
          Geo3dSpatialContextFactory factory;

          • RandomGeoShapeGenerator shapeGenerator = new RandomGeoShapeGenerator();
            + RandomGeo3dShapeGenerator shapeGenerator = new RandomGeo3dShapeGenerator();

          private void setupGeohashGrid() {

          • String planetModel = shapeGenerator.randomPlanetModel();
            + String planetModel = shapeGenerator.randomStringPlanetModel();
            factory = new Geo3dSpatialContextFactory();
            Map<String, String> args = new HashMap<>();
            args.put("planetModel", planetModel);
              • End diff –

          I suggest not calling init(); just set the factory.planetModel directly

          Show
          githubbot ASF GitHub Bot added a comment - Github user dsmiley commented on a diff in the pull request: https://github.com/apache/lucene-solr/pull/246#discussion_r137825324 — Diff: lucene/spatial-extras/src/test/org/apache/lucene/spatial/spatial4j/Geo3dAreaRptTest.java — @@ -40,10 +41,10 @@ SpatialContext ctx; Geo3dSpatialContextFactory factory; RandomGeoShapeGenerator shapeGenerator = new RandomGeoShapeGenerator(); + RandomGeo3dShapeGenerator shapeGenerator = new RandomGeo3dShapeGenerator(); private void setupGeohashGrid() { String planetModel = shapeGenerator.randomPlanetModel(); + String planetModel = shapeGenerator.randomStringPlanetModel(); factory = new Geo3dSpatialContextFactory(); Map<String, String> args = new HashMap<>(); args.put("planetModel", planetModel); End diff – I suggest not calling init(); just set the factory.planetModel directly
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user dsmiley commented on a diff in the pull request:

          https://github.com/apache/lucene-solr/pull/246#discussion_r137824698

          — Diff: lucene/spatial3d/src/test/org/apache/lucene/spatial3d/geom/RandomGeo3dShapeGenerator.java —
          @@ -149,6 +150,26 @@ public PlanetModel randomPlanetModel() {
          }

          /**
          + * Method that returns a random generated Planet model as string from the supported
          — End diff –

          I don't think you need this method. I think you are using it only for init(map) when the test using it could instead simply do randomBoolean() to directly set the planet model on the factory.

          Show
          githubbot ASF GitHub Bot added a comment - Github user dsmiley commented on a diff in the pull request: https://github.com/apache/lucene-solr/pull/246#discussion_r137824698 — Diff: lucene/spatial3d/src/test/org/apache/lucene/spatial3d/geom/RandomGeo3dShapeGenerator.java — @@ -149,6 +150,26 @@ public PlanetModel randomPlanetModel() { } /** + * Method that returns a random generated Planet model as string from the supported — End diff – I don't think you need this method. I think you are using it only for init(map) when the test using it could instead simply do randomBoolean() to directly set the planet model on the factory.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user iverase commented on the issue:

          https://github.com/apache/lucene-solr/pull/246

          I have added the possibility to relate no geo3d rectangles. I was trying to avoid that but I see that for the time being it is necessary.

          I did the changes on the test as well so I am setting the planet model directly to the factory.

          Show
          githubbot ASF GitHub Bot added a comment - Github user iverase commented on the issue: https://github.com/apache/lucene-solr/pull/246 I have added the possibility to relate no geo3d rectangles. I was trying to avoid that but I see that for the time being it is necessary. I did the changes on the test as well so I am setting the planet model directly to the factory.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user iverase commented on a diff in the pull request:

          https://github.com/apache/lucene-solr/pull/246#discussion_r138555768

          — Diff: lucene/spatial-extras/src/java/org/apache/lucene/spatial/spatial4j/Geo3dShape.java —
          @@ -96,45 +95,25 @@ else if (relationship == GeoArea.DISJOINT)
          }

          protected SpatialRelation relate(Point p) {

          • // Create a GeoPoint
          • GeoPoint point = new GeoPoint(planetModel, p.getY()* DistanceUtils.DEGREES_TO_RADIANS, p.getX()* DistanceUtils.DEGREES_TO_RADIANS);
            + GeoPoint point = new GeoPoint(shape.getPlanetModel(), p.getY()* DistanceUtils.DEGREES_TO_RADIANS, p.getX()* DistanceUtils.DEGREES_TO_RADIANS);
            if (shape.isWithin(point)) { - // Point within shape return SpatialRelation.CONTAINS; }

            return SpatialRelation.DISJOINT;
            }

          -
          -
          @Override
          public Rectangle getBoundingBox() {
          Rectangle bbox = this.boundingBox;//volatile read once
          if (bbox == null) {
          LatLonBounds bounds = new LatLonBounds();
          shape.getBounds(bounds);

          • double leftLon;
          • double rightLon;
          • if (bounds.checkNoLongitudeBound()) { - leftLon = -180.0; - rightLon = 180.0; - }

            else

            { - leftLon = bounds.getLeftLongitude().doubleValue() * DistanceUtils.RADIANS_TO_DEGREES; - rightLon = bounds.getRightLongitude().doubleValue() * DistanceUtils.RADIANS_TO_DEGREES; - }
          • double minLat;
          • if (bounds.checkNoBottomLatitudeBound()) { - minLat = -90.0; - }

            else

            { - minLat = bounds.getMinLatitude().doubleValue() * DistanceUtils.RADIANS_TO_DEGREES; - }
          • double maxLat;
          • if (bounds.checkNoTopLatitudeBound()) { - maxLat = 90.0; - }

            else

            { - maxLat = bounds.getMaxLatitude().doubleValue() * DistanceUtils.RADIANS_TO_DEGREES; - }
          • bbox = new RectangleImpl(leftLon, rightLon, minLat, maxLat, ctx).getBuffered(ROUNDOFF_ADJUSTMENT, ctx);
              • End diff –

          Yes, it seems not necessary. Not sure what was needed before but I am glad that we can hopefully get rid of that.

          Show
          githubbot ASF GitHub Bot added a comment - Github user iverase commented on a diff in the pull request: https://github.com/apache/lucene-solr/pull/246#discussion_r138555768 — Diff: lucene/spatial-extras/src/java/org/apache/lucene/spatial/spatial4j/Geo3dShape.java — @@ -96,45 +95,25 @@ else if (relationship == GeoArea.DISJOINT) } protected SpatialRelation relate(Point p) { // Create a GeoPoint GeoPoint point = new GeoPoint(planetModel, p.getY()* DistanceUtils.DEGREES_TO_RADIANS, p.getX()* DistanceUtils.DEGREES_TO_RADIANS); + GeoPoint point = new GeoPoint(shape.getPlanetModel(), p.getY()* DistanceUtils.DEGREES_TO_RADIANS, p.getX()* DistanceUtils.DEGREES_TO_RADIANS); if (shape.isWithin(point)) { - // Point within shape return SpatialRelation.CONTAINS; } return SpatialRelation.DISJOINT; } - - @Override public Rectangle getBoundingBox() { Rectangle bbox = this.boundingBox;//volatile read once if (bbox == null) { LatLonBounds bounds = new LatLonBounds(); shape.getBounds(bounds); double leftLon; double rightLon; if (bounds.checkNoLongitudeBound()) { - leftLon = -180.0; - rightLon = 180.0; - } else { - leftLon = bounds.getLeftLongitude().doubleValue() * DistanceUtils.RADIANS_TO_DEGREES; - rightLon = bounds.getRightLongitude().doubleValue() * DistanceUtils.RADIANS_TO_DEGREES; - } double minLat; if (bounds.checkNoBottomLatitudeBound()) { - minLat = -90.0; - } else { - minLat = bounds.getMinLatitude().doubleValue() * DistanceUtils.RADIANS_TO_DEGREES; - } double maxLat; if (bounds.checkNoTopLatitudeBound()) { - maxLat = 90.0; - } else { - maxLat = bounds.getMaxLatitude().doubleValue() * DistanceUtils.RADIANS_TO_DEGREES; - } bbox = new RectangleImpl(leftLon, rightLon, minLat, maxLat, ctx).getBuffered(ROUNDOFF_ADJUSTMENT, ctx); End diff – Yes, it seems not necessary. Not sure what was needed before but I am glad that we can hopefully get rid of that.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user iverase commented on a diff in the pull request:

          https://github.com/apache/lucene-solr/pull/246#discussion_r138556038

          — Diff: lucene/spatial-extras/src/java/org/apache/lucene/spatial/spatial4j/Geo3dDistanceCalculator.java —
          @@ -70,7 +71,22 @@ public boolean within(Point from, double toX, double toY, double distance) {

          @Override
          public Point pointOnBearing(Point from, double distDEG, double bearingDEG, SpatialContext ctx, Point reuse) {

          • throw new UnsupportedOperationException();
            + double dist = DistanceUtils.DEGREES_TO_RADIANS * distDEG;
            + double bearing = DistanceUtils.DEGREES_TO_RADIANS * bearingDEG;
            + Geo3dPointShape geoFrom = (Geo3dPointShape) from;
            + GeoPoint point = (GeoPoint)geoFrom.shape;
            +
              • End diff –

          I have changes the formula to use vincenty's formulae. Slower as it is iterative but It taken into account the planet model.

          Show
          githubbot ASF GitHub Bot added a comment - Github user iverase commented on a diff in the pull request: https://github.com/apache/lucene-solr/pull/246#discussion_r138556038 — Diff: lucene/spatial-extras/src/java/org/apache/lucene/spatial/spatial4j/Geo3dDistanceCalculator.java — @@ -70,7 +71,22 @@ public boolean within(Point from, double toX, double toY, double distance) { @Override public Point pointOnBearing(Point from, double distDEG, double bearingDEG, SpatialContext ctx, Point reuse) { throw new UnsupportedOperationException(); + double dist = DistanceUtils.DEGREES_TO_RADIANS * distDEG; + double bearing = DistanceUtils.DEGREES_TO_RADIANS * bearingDEG; + Geo3dPointShape geoFrom = (Geo3dPointShape) from; + GeoPoint point = (GeoPoint)geoFrom.shape; + End diff – I have changes the formula to use vincenty's formulae. Slower as it is iterative but It taken into account the planet model.
          Hide
          ivera Ignacio Vera added a comment -

          Now all test are green. Note what I have to do with the circles as for WGS84 I was having problems.

          Show
          ivera Ignacio Vera added a comment - Now all test are green. Note what I have to do with the circles as for WGS84 I was having problems.
          Hide
          ivera Ignacio Vera added a comment -

          Hi David Smiley,

          I would like to share some thoughts of the current solution as there might be room from improvement. From the original classes I had to do two changes that mcan be improve to be able to pass the tests:

          1) Geo3dCircleShape.relate(Shape other): Currently circles in WGS84 gives false positives and false negatives close to the edge. The current solution is not optimal because the behavior of points and other shapes will be different. I had a look how the circles are build in Geo3d and I think there is room from improvement. The solution is not perfect but it will remove the false positives and we could probably remove this method. I will open a ticket to Karl Wright to consider a new way of building circle planes.

          2) New constructor in Geo3dRectangleShape: This has been added because Geo3d wide rectangles (extension > PI) are unable to compute longitude bounds. I would like to investigate if this is possible and therefore having a unique way to compute bounds in the wrapper.

          Cheers,

          I.

          Show
          ivera Ignacio Vera added a comment - Hi David Smiley , I would like to share some thoughts of the current solution as there might be room from improvement. From the original classes I had to do two changes that mcan be improve to be able to pass the tests: 1) Geo3dCircleShape.relate(Shape other): Currently circles in WGS84 gives false positives and false negatives close to the edge. The current solution is not optimal because the behavior of points and other shapes will be different. I had a look how the circles are build in Geo3d and I think there is room from improvement. The solution is not perfect but it will remove the false positives and we could probably remove this method. I will open a ticket to Karl Wright to consider a new way of building circle planes. 2) New constructor in Geo3dRectangleShape: This has been added because Geo3d wide rectangles (extension > PI) are unable to compute longitude bounds. I would like to investigate if this is possible and therefore having a unique way to compute bounds in the wrapper. Cheers, I.
          Hide
          dsmiley David Smiley added a comment -

          (I'm back from travel)
          The current state is looking pretty nice. I think you can now merge Geo3dAreaRptTest into Geo3dRptTest? Keep the specific tests for bugs that were found. Use the new random shape generator instead of the manual code.

          Geo3dCircleShape.relate

          While I don't pretend to know the details of the algorithms for both world models, I do find the override of the method here a bit suspicious. Shouldn't GeoStandardCircle look at the PlanetModel and do the right thing?

          New constructor in Geo3dRectangleShape

          Ok.

          Show
          dsmiley David Smiley added a comment - (I'm back from travel) The current state is looking pretty nice. I think you can now merge Geo3dAreaRptTest into Geo3dRptTest? Keep the specific tests for bugs that were found. Use the new random shape generator instead of the manual code. Geo3dCircleShape.relate While I don't pretend to know the details of the algorithms for both world models, I do find the override of the method here a bit suspicious. Shouldn't GeoStandardCircle look at the PlanetModel and do the right thing? New constructor in Geo3dRectangleShape Ok.
          Hide
          ivera Ignacio Vera added a comment - - edited

          I have merge the Geo3dAreaRptTest into Geo3dRptTest.

          Unfortunately, the current implementation of Geo3dStandardCircle is an approximation and it shows up when trying to build shapes using circles with bearing points. Therefore the test in Geo3dShapeWGS84ModelRectRelationTest fail as some points are declared to be outside of the circle.

          The case of circles on spheroids is hard and you need to eventually use brute force (calculate the distance between the point/shape to center of the circle) if you want to be precise. I have an idea how to minimize the impact but it is on the limits of my maths capabilities. I opened a ticket (LUCENE-7970) to address the problem.

          Meanwhile the WGS84ModelRectRelationTest will fail when removing the doggy relate function. Note that it works for the sphere.

          Show
          ivera Ignacio Vera added a comment - - edited I have merge the Geo3dAreaRptTest into Geo3dRptTest. Unfortunately, the current implementation of Geo3dStandardCircle is an approximation and it shows up when trying to build shapes using circles with bearing points. Therefore the test in Geo3dShapeWGS84ModelRectRelationTest fail as some points are declared to be outside of the circle. The case of circles on spheroids is hard and you need to eventually use brute force (calculate the distance between the point/shape to center of the circle) if you want to be precise. I have an idea how to minimize the impact but it is on the limits of my maths capabilities. I opened a ticket ( LUCENE-7970 ) to address the problem. Meanwhile the WGS84ModelRectRelationTest will fail when removing the doggy relate function. Note that it works for the sphere.
          Hide
          kwright@metacarta.com Karl Wright added a comment -

          Ignacio Vera I am curious as to why the GeoStandardCircle causes relationship failure in the wrapper environment. It's a shape like any other, albeit not exactly a circle, so unless there's some logic that checks that it behaves exactly like a circle, then the wrapper and test logic shouldn't care.

          Show
          kwright@metacarta.com Karl Wright added a comment - Ignacio Vera I am curious as to why the GeoStandardCircle causes relationship failure in the wrapper environment. It's a shape like any other, albeit not exactly a circle, so unless there's some logic that checks that it behaves exactly like a circle, then the wrapper and test logic shouldn't care.
          Hide
          ivera Ignacio Vera added a comment - - edited

          The test generates points of a shape by creating a circle and generating points using a distance (lower than the radius) and bearing angle from the center of the circle. After creating the point it checks that the generated point is inside the circle and if it doesn't it fails.

          That is exactly what fails, sometimes the points are not inside the GeoCircle.

          Show
          ivera Ignacio Vera added a comment - - edited The test generates points of a shape by creating a circle and generating points using a distance (lower than the radius) and bearing angle from the center of the circle. After creating the point it checks that the generated point is inside the circle and if it doesn't it fails. That is exactly what fails, sometimes the points are not inside the GeoCircle.
          Hide
          dsmiley David Smiley added a comment -

          I'm inclined to commit this branch despite the override in Geo3dCircleShape.relate which I think I'll add a comment that this is a hack and referencing JIRA LUCENE-7970. It would be helpful in LUCENE-7970 to provide specific circle coordinates and sample point within a unit test that tests the relationship to illustrate the failure; otherwise the discussion is theoretical.

          I may include a tweak to a Solr spatial test to show that this seems to work there.

          Thanks for all your efforts here Ignacio!

          Show
          dsmiley David Smiley added a comment - I'm inclined to commit this branch despite the override in Geo3dCircleShape.relate which I think I'll add a comment that this is a hack and referencing JIRA LUCENE-7970 . It would be helpful in LUCENE-7970 to provide specific circle coordinates and sample point within a unit test that tests the relationship to illustrate the failure; otherwise the discussion is theoretical. I may include a tweak to a Solr spatial test to show that this seems to work there. Thanks for all your efforts here Ignacio!
          Hide
          ivera Ignacio Vera added a comment -

          sure, I will add a test for this particular feature.

          I think all the goodies that brings Geo3d are worthy. My thanks are to Karl Wright for the support and awesome Geo3d library.

          Show
          ivera Ignacio Vera added a comment - sure, I will add a test for this particular feature. I think all the goodies that brings Geo3d are worthy. My thanks are to Karl Wright for the support and awesome Geo3d library.
          Hide
          ivera Ignacio Vera added a comment -

          Actually there is already a test: In Geo3dShapeWGS84ModelRectRelationTest.pointBearingTest()

          Show
          ivera Ignacio Vera added a comment - Actually there is already a test: In Geo3dShapeWGS84ModelRectRelationTest.pointBearingTest()
          Hide
          kwright@metacarta.com Karl Wright added a comment -

          The test generates points of a shape by creating a circle and generating points using a distance (lower than the radius) and bearing angle from the center of the circle. After creating the point it checks that the generated point is inside the circle and if it doesn't it fails.

          Ignacio Vera It sounds like the test should expect deviation within a certain (computed) error range from a true circle. I think it's possible to compute the actual error by the following process:
          (1) From the center, with the Vincenti formula compute the "actual" top latitude of the circle, the bottom latitude of the circle, and either the left or right latitude of the circle.
          (2) Compute the lat/lon bounds of the comparable GeoStandardCircle
          (3) Compute the difference between those bounds and the Vincenti-computed bounds

          As for what the theoretical error is, I will have to do some math and get back to you on that. But we would want the error to at least be reasonably symmetrical (that is, not significantly larger at the top of the circle than at the bottom), etc. What do you think?

          Show
          kwright@metacarta.com Karl Wright added a comment - The test generates points of a shape by creating a circle and generating points using a distance (lower than the radius) and bearing angle from the center of the circle. After creating the point it checks that the generated point is inside the circle and if it doesn't it fails. Ignacio Vera It sounds like the test should expect deviation within a certain (computed) error range from a true circle. I think it's possible to compute the actual error by the following process: (1) From the center, with the Vincenti formula compute the "actual" top latitude of the circle, the bottom latitude of the circle, and either the left or right latitude of the circle. (2) Compute the lat/lon bounds of the comparable GeoStandardCircle (3) Compute the difference between those bounds and the Vincenti-computed bounds As for what the theoretical error is, I will have to do some math and get back to you on that. But we would want the error to at least be reasonably symmetrical (that is, not significantly larger at the top of the circle than at the bottom), etc. What do you think?
          Hide
          ivera Ignacio Vera added a comment -

          The problem is that in the test you do not have information of the circle, you are just ask to create a point with a distance to another point at a bearing angle.

          I understand that the Geo3dShape is an ellipse as similar as possible to the circle. I wonder if you consider that the distance is the circle to consider, is possible to compute the error for the angle?

          Show
          ivera Ignacio Vera added a comment - The problem is that in the test you do not have information of the circle, you are just ask to create a point with a distance to another point at a bearing angle. I understand that the Geo3dShape is an ellipse as similar as possible to the circle. I wonder if you consider that the distance is the circle to consider, is possible to compute the error for the angle?
          Hide
          dsmiley David Smiley added a comment -

          Uploading the patch I intend to commit later tonight. I made more than trivial changes:

          • Reverted QueryEqualsHashCodeTest as it has nothing to do with Geo3d and the additions duplicated many test lines
          • Removed the redundant test lines in SpatialArgsTest so that it simply randomly picked the spatial context (potentially Geo3d).
          • Geo3dShapeFactory polygon / hole building wasn't quite right; the endHole method is supposed to return the PolygonBuilder of the parent / containing polygon, not some new builder. Admittedly the Spatial4j javadocs should have clarified that. I fixed this and made simplifications.
          • Geo3dShapeFactory addPoint; removed the points.contains(point) check on each input point as it's both not necessary (Geo3d internally has a filterPoints method/functionality) and expensive (O(N^2)).
          • Modified the Geo3dRptTest to not have the factory be a field of the test. The factory is supposed to be a very temporary thing only used to create the context.
          • Auto-formatted most of these source files.
          • Removed Geo3dDistanceCalculator.pointOnBearing2 as it was unused
          • Geo3dDistanceCalculator.distance: made both variants support Point subclasses that aren't Geo3dPointShape

          In at least one of these cases the problem was discovered by using it with some Solr tests. I intend to file a separate issue for Solr since it's both a test + convenience (spatialContextFactory="geo3d") + documentation

          Show
          dsmiley David Smiley added a comment - Uploading the patch I intend to commit later tonight. I made more than trivial changes: Reverted QueryEqualsHashCodeTest as it has nothing to do with Geo3d and the additions duplicated many test lines Removed the redundant test lines in SpatialArgsTest so that it simply randomly picked the spatial context (potentially Geo3d). Geo3dShapeFactory polygon / hole building wasn't quite right; the endHole method is supposed to return the PolygonBuilder of the parent / containing polygon, not some new builder. Admittedly the Spatial4j javadocs should have clarified that. I fixed this and made simplifications. Geo3dShapeFactory addPoint; removed the points.contains(point) check on each input point as it's both not necessary (Geo3d internally has a filterPoints method/functionality) and expensive (O(N^2)). Modified the Geo3dRptTest to not have the factory be a field of the test. The factory is supposed to be a very temporary thing only used to create the context. Auto-formatted most of these source files. Removed Geo3dDistanceCalculator.pointOnBearing2 as it was unused Geo3dDistanceCalculator.distance: made both variants support Point subclasses that aren't Geo3dPointShape In at least one of these cases the problem was discovered by using it with some Solr tests. I intend to file a separate issue for Solr since it's both a test + convenience (spatialContextFactory="geo3d") + documentation
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 035523ba7a86773500c053129f65c9a6dc4fd384 in lucene-solr's branch refs/heads/master from David Smiley
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=035523b ]

          LUCENE-7951: Spatial4j implementations using Geo3d

          Show
          jira-bot ASF subversion and git services added a comment - Commit 035523ba7a86773500c053129f65c9a6dc4fd384 in lucene-solr's branch refs/heads/master from David Smiley [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=035523b ] LUCENE-7951 : Spatial4j implementations using Geo3d
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 85491401d54c59e1593a5c9f13dca7bfcdda31a2 in lucene-solr's branch refs/heads/branch_7x from David Smiley
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8549140 ]

          LUCENE-7951: Spatial4j implementations using Geo3d

          (cherry picked from commit 035523b)

          Show
          jira-bot ASF subversion and git services added a comment - Commit 85491401d54c59e1593a5c9f13dca7bfcdda31a2 in lucene-solr's branch refs/heads/branch_7x from David Smiley [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8549140 ] LUCENE-7951 : Spatial4j implementations using Geo3d (cherry picked from commit 035523b)

            People

            • Assignee:
              dsmiley David Smiley
              Reporter:
              ivera Ignacio Vera
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development