Uploaded image for project: 'Lucene - Core'
  1. Lucene - Core
  2. LUCENE-7056

Separate Geo3DPoint into another package from the rest of Geo3D

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 6.0
    • Component/s: modules/spatial3d
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      The original description follows; it's greater in scope than the new title:


      This is a proposal for the "spatial3d" module to be purely about the shape/geometry implementations it has. In Lucene 5 that's actually all it has. In Lucene 6 at the moment its ~76 files have 2 classes that I think should go elsewhere: Geo3DPoint and PointInGeo3DShapeQuery. Specifically lucene-spatial-extras (which doesn't quite exist yet so lucene-spatial) would be a suitable place due to the dependency. Eventually I see this module migrating elsewhere be it on its own or a part of something else more spatial-ish. Even if that never comes to pass, non-Lucene users who want to use this module for it's geometry annoyingly have to exclude the Lucene dependencies that are there because this module also contains these two classes.

      In a comment I'll suggest some specifics.

        Issue Links

          Activity

          Hide
          dsmiley David Smiley added a comment -

          Specifics:

          • Rename module "spatial3d" to "spatial-geom3d" or perhaps "spatial-3d-geom" in order to emphasizes the geometry aspect
          • Move package “org.apache.lucene.geo3d” to “org.apache.lucene.spatial.3d.geom”.
          • Move Geo3DPoint and PointInGeo3DShapeQuery to the lucene-spatial-extras module to the package “org.apache.lucene.spatial.3d”
            • Remove dependency from lucene-spatial-geom3d to Lucene. Ensure that the new module’s Maven POM has no runtime dependencies at all.
          • Move Geo3dShape in “org.apache.lucene.spatial.spatial4j” to “org.apache.lucene.spatial.3d” to keep the 3d related stuff here together with the 2 other classes moving over.

          Note “Geo3D” will then cease to be a package/brand in here. It’s basically our spatial 3d geometry module.

          Show
          dsmiley David Smiley added a comment - Specifics: Rename module "spatial3d" to "spatial-geom3d" or perhaps "spatial-3d-geom" in order to emphasizes the geometry aspect Move package “org.apache.lucene.geo3d” to “org.apache.lucene.spatial.3d.geom”. Move Geo3DPoint and PointInGeo3DShapeQuery to the lucene-spatial-extras module to the package “org.apache.lucene.spatial.3d” Remove dependency from lucene-spatial-geom3d to Lucene. Ensure that the new module’s Maven POM has no runtime dependencies at all. Move Geo3dShape in “org.apache.lucene.spatial.spatial4j” to “org.apache.lucene.spatial.3d” to keep the 3d related stuff here together with the 2 other classes moving over. Note “Geo3D” will then cease to be a package/brand in here. It’s basically our spatial 3d geometry module.
          Hide
          mikemccand Michael McCandless added a comment -

          Hmm I don't think this is a good idea?

          Lucene shouldn't try to be in the business of "exporting spatial math libraries for others to use". We are a search engine, and our priorities here are to make spatial indexing and searching work well.

          If someone wants the geo3d math implemenation, alone, they can poach/fork from us?

          It's the same reason why we don't e.g. invest in making FSTs easier for outsiders to use: these are internal data structures that we use to provide awesome indexing/searching.

          I would rather see us do the opposite: make all the geo3d math only APIs package private, and publicly expose only the Geo3DPoint class, for indexing and searching? This gives us the most freedom to iterate on geo3d APIs, privately.

          Also, it's still early for these new geo APIs, and it's not clear where they will live longish term. E.g., we are struggling with precision/fuzzines issues in the 2D geo math (this is why only now we finally have a BKD/points distance query: see LUCENE-6698, LUCENE-6540, LUCENE-7054, etc.), so we may very well want to make the geo3d the primary spatial implementation instead, or a hybrid 2D/3D solution, which well mean more shuffling.

          In Lucene 5 that's actually all it has

          Actually 5.x also has the classes for Lucene users to index and search with geo3d, under the org.apache.lucene.bkdtree3d package in the spatial3d module.

          It's just that in 6.0 most of that is folded into core, with core support for N-dimensional points, so the minimal (2) classes were moved under the geo3d package.

          Show
          mikemccand Michael McCandless added a comment - Hmm I don't think this is a good idea? Lucene shouldn't try to be in the business of "exporting spatial math libraries for others to use". We are a search engine, and our priorities here are to make spatial indexing and searching work well. If someone wants the geo3d math implemenation, alone, they can poach/fork from us? It's the same reason why we don't e.g. invest in making FSTs easier for outsiders to use: these are internal data structures that we use to provide awesome indexing/searching. I would rather see us do the opposite: make all the geo3d math only APIs package private, and publicly expose only the Geo3DPoint class, for indexing and searching? This gives us the most freedom to iterate on geo3d APIs, privately. Also, it's still early for these new geo APIs, and it's not clear where they will live longish term. E.g., we are struggling with precision/fuzzines issues in the 2D geo math (this is why only now we finally have a BKD/points distance query: see LUCENE-6698 , LUCENE-6540 , LUCENE-7054 , etc.), so we may very well want to make the geo3d the primary spatial implementation instead, or a hybrid 2D/3D solution, which well mean more shuffling. In Lucene 5 that's actually all it has Actually 5.x also has the classes for Lucene users to index and search with geo3d, under the org.apache.lucene.bkdtree3d package in the spatial3d module. It's just that in 6.0 most of that is folded into core, with core support for N-dimensional points, so the minimal (2) classes were moved under the geo3d package.
          Hide
          rcmuir Robert Muir added a comment -

          I would rather see us do the opposite: make all the geo3d math only APIs package private, and publicly expose only the Geo3DPoint class, for indexing and searching? This gives us the most freedom to iterate on geo3d APIs, privately.

          +1 from someone who is just started looking at this stuff. I think we need to keep this stuff as simple as possible. Exposing a bunch of unnecessary API makes things much more difficult. We've applied a similar approach to the other point classes already.

          Show
          rcmuir Robert Muir added a comment - I would rather see us do the opposite: make all the geo3d math only APIs package private, and publicly expose only the Geo3DPoint class, for indexing and searching? This gives us the most freedom to iterate on geo3d APIs, privately. +1 from someone who is just started looking at this stuff. I think we need to keep this stuff as simple as possible. Exposing a bunch of unnecessary API makes things much more difficult. We've applied a similar approach to the other point classes already.
          Hide
          kwright@metacarta.com Karl Wright added a comment - - edited

          If you folks make everything that we need package private, we're screwed.

          We need to be able to construct shapes and Geo
          We need access to the factories, distance computation implementations, PlanetModel abstraction, GeoCircle construction, and interfaces like GeoDistance, Membership, GeoArea, etc.

          I had envisioned that the integration would be open to the extent that FST integration is.

          Show
          kwright@metacarta.com Karl Wright added a comment - - edited If you folks make everything that we need package private, we're screwed. We need to be able to construct shapes and Geo We need access to the factories, distance computation implementations, PlanetModel abstraction, GeoCircle construction, and interfaces like GeoDistance, Membership, GeoArea, etc. I had envisioned that the integration would be open to the extent that FST integration is.
          Hide
          dsmiley David Smiley added a comment -

          +1 from someone who is just started looking at this stuff. I think we need to keep this stuff as simple as possible. Exposing a bunch of unnecessary API makes things much more difficult. We've applied a similar approach to the other point classes already.

          Can you please explain how leaving it exposed (public) makes things "much more difficult"? Or maybe you don't mean more difficult but just less "simple" by virtue of people seeing it and being confused by cognitive overload of stuff they won't need? If it's the latter and not difficulty in something else then I think keeping purely the geometries separated and even better, out of Lucene, helps. Keeping it package private would help too at the determent of others who want to use this, and it would foster the continuation of this very large Java package growing without organization. One of the biggest annoyances I have with it is that each time I look in there I have to figure out which of these classes are the Lucene ones. It's taken me an embarrassingly long time on occasion to the point that I've resorted to my IDE's dependency analyzer to tell me which are the Lucene ones. Even if we don't agree to the entire aims of this issue, I'd like to to consider separating these 2 classes out by package. What do you think about that specifically?

          If someone wants the geo3d math implemenation, alone, they can poach/fork from us?

          Because that's a large barrier to sharing / re-use. it's easy for you to suggest this, living in the code base that has it, but please consider an outsider. Hearing this suggestion makes me sad; and the idea of making it all package private even sadder.

          Lucene shouldn't try to be in the business of "exporting spatial math libraries for others to use". We are a search engine, and our priorities here are to make spatial indexing and searching work well.

          Then why is Geo3d/Spatial3d even here at all? I'd rather it not be but I'm not pushing for that today; just a compromise. Keep it here while it suits us. You've made the point that it's easier/faster to iterate on Geo3d here and I recognize that, so leave it here. Some day we will look back and see it has stabilized, and I hold out some fleeting hope you might be convinced in the merits of a dependency instead of maintaining it here. Not a dependency from lucene-core or lucene-spatial, but lucene-spatial-extras.

          It's the same reason why we don't e.g. invest in making FSTs easier for outsiders to use: these are internal data structures that we use to provide awesome indexing/searching.

          I don't think these are mutually exclusive. Of course there can be technical decisions that trade off ease of use for performance and we'd rather choose performance in many cases, but that doesn't mean it's a bad idea to expose a library that others might use. If we were to do so, we wouldn't have to be bound by annoyances like backwards compatibility if we chose not to. Part of the thrill I get in contributing to open-source is knowing my code is used so widely, and hearing kind remarks of its usefulness. Don't you?

          Actually 5.x also has the classes for Lucene users to index and search with geo3d, under the org.apache.lucene.bkdtree3d package in the spatial3d module.

          Oh yeah; I overlooked that for some reason; weird.

          Show
          dsmiley David Smiley added a comment - +1 from someone who is just started looking at this stuff. I think we need to keep this stuff as simple as possible. Exposing a bunch of unnecessary API makes things much more difficult. We've applied a similar approach to the other point classes already. Can you please explain how leaving it exposed (public) makes things "much more difficult"? Or maybe you don't mean more difficult but just less "simple" by virtue of people seeing it and being confused by cognitive overload of stuff they won't need? If it's the latter and not difficulty in something else then I think keeping purely the geometries separated and even better, out of Lucene, helps. Keeping it package private would help too at the determent of others who want to use this, and it would foster the continuation of this very large Java package growing without organization. One of the biggest annoyances I have with it is that each time I look in there I have to figure out which of these classes are the Lucene ones. It's taken me an embarrassingly long time on occasion to the point that I've resorted to my IDE's dependency analyzer to tell me which are the Lucene ones. Even if we don't agree to the entire aims of this issue, I'd like to to consider separating these 2 classes out by package. What do you think about that specifically? If someone wants the geo3d math implemenation, alone, they can poach/fork from us? Because that's a large barrier to sharing / re-use. it's easy for you to suggest this, living in the code base that has it, but please consider an outsider. Hearing this suggestion makes me sad; and the idea of making it all package private even sadder. Lucene shouldn't try to be in the business of "exporting spatial math libraries for others to use". We are a search engine, and our priorities here are to make spatial indexing and searching work well. Then why is Geo3d/Spatial3d even here at all? I'd rather it not be but I'm not pushing for that today; just a compromise. Keep it here while it suits us. You've made the point that it's easier/faster to iterate on Geo3d here and I recognize that, so leave it here. Some day we will look back and see it has stabilized, and I hold out some fleeting hope you might be convinced in the merits of a dependency instead of maintaining it here. Not a dependency from lucene-core or lucene-spatial, but lucene-spatial-extras. It's the same reason why we don't e.g. invest in making FSTs easier for outsiders to use: these are internal data structures that we use to provide awesome indexing/searching. I don't think these are mutually exclusive. Of course there can be technical decisions that trade off ease of use for performance and we'd rather choose performance in many cases, but that doesn't mean it's a bad idea to expose a library that others might use. If we were to do so, we wouldn't have to be bound by annoyances like backwards compatibility if we chose not to. Part of the thrill I get in contributing to open-source is knowing my code is used so widely, and hearing kind remarks of its usefulness. Don't you? Actually 5.x also has the classes for Lucene users to index and search with geo3d, under the org.apache.lucene.bkdtree3d package in the spatial3d module. Oh yeah; I overlooked that for some reason; weird.
          Hide
          rcmuir Robert Muir added a comment -

          Can you please explain how leaving it exposed (public) makes things "much more difficult"? Or maybe you don't mean more difficult but just less "simple" by virtue of people seeing it and being confused by cognitive overload of stuff they won't need?

          That is part of it, but its more complex than that. To me its about making the api intuitive for both users and ourselves (e.g. tests). For example the guts of PointRangeQuery etc were all public, taking byte[][] arrays as inputs and requiring you to use correct Point classes that match and so on. Same goes for polygon etc queries in sandbox. Very error prone to use the wrong encoding when we can just make it type-safe etc instead and only expose some methods like IntPoint.newRangeQuery. And having a smaller public footprint means we can try to make it really nice and really document the contracts of the methods. I think this spatial stuff has enough trickiness that it really helps to make everything we expose well-defined, safe, fast, etc.

          I think it extends to this geo3d as well. I hate that the point class we provide forces users to pass around PlanetModel to every ctor and method, it makes it harder and more error-prone: instead we just make one thats wired at WGS84, and consider a separate point class that is "expert" or "custom" that works with other models.

          If it's the latter and not difficulty in something else then I think keeping purely the geometries separated and even better, out of Lucene, helps. Keeping it package private would help too at the determent of others who want to use this, and it would foster the continuation of this very large Java package growing without organization. One of the biggest annoyances I have with it is that each time I look in there I have to figure out which of these classes are the Lucene ones. It's taken me an embarrassingly long time on occasion to the point that I've resorted to my IDE's dependency analyzer to tell me which are the Lucene ones. Even if we don't agree to the entire aims of this issue, I'd like to to consider separating these 2 classes out by package. What do you think about that specifically?

          I agree that some separation can help. I think we should move the lucene classes into a separate package at the moment to make this easier. This should not really be controversial, lets take this small step. I had the same problem as you here finding stuff.

          Making a separate module in my opinion is not really helpful at the problem, it just adds more indirection/confusion and more potential mistakes. I agree with Mike that we shouldn't make these kind of compromises for non-search since we are a search engine library.

          Show
          rcmuir Robert Muir added a comment - Can you please explain how leaving it exposed (public) makes things "much more difficult"? Or maybe you don't mean more difficult but just less "simple" by virtue of people seeing it and being confused by cognitive overload of stuff they won't need? That is part of it, but its more complex than that. To me its about making the api intuitive for both users and ourselves (e.g. tests). For example the guts of PointRangeQuery etc were all public, taking byte[][] arrays as inputs and requiring you to use correct Point classes that match and so on. Same goes for polygon etc queries in sandbox. Very error prone to use the wrong encoding when we can just make it type-safe etc instead and only expose some methods like IntPoint.newRangeQuery. And having a smaller public footprint means we can try to make it really nice and really document the contracts of the methods. I think this spatial stuff has enough trickiness that it really helps to make everything we expose well-defined, safe, fast, etc. I think it extends to this geo3d as well. I hate that the point class we provide forces users to pass around PlanetModel to every ctor and method, it makes it harder and more error-prone: instead we just make one thats wired at WGS84, and consider a separate point class that is "expert" or "custom" that works with other models. If it's the latter and not difficulty in something else then I think keeping purely the geometries separated and even better, out of Lucene, helps. Keeping it package private would help too at the determent of others who want to use this, and it would foster the continuation of this very large Java package growing without organization. One of the biggest annoyances I have with it is that each time I look in there I have to figure out which of these classes are the Lucene ones. It's taken me an embarrassingly long time on occasion to the point that I've resorted to my IDE's dependency analyzer to tell me which are the Lucene ones. Even if we don't agree to the entire aims of this issue, I'd like to to consider separating these 2 classes out by package. What do you think about that specifically? I agree that some separation can help. I think we should move the lucene classes into a separate package at the moment to make this easier. This should not really be controversial, lets take this small step. I had the same problem as you here finding stuff. Making a separate module in my opinion is not really helpful at the problem, it just adds more indirection/confusion and more potential mistakes. I agree with Mike that we shouldn't make these kind of compromises for non-search since we are a search engine library.
          Hide
          mikemccand Michael McCandless added a comment -

          I'd like to to consider separating these 2 classes out by package.

          +1, this seems like a good compromise, and it would match what we have
          in 5.x (separate package holds the Lucene classes from the "pure geo3d
          math" classes).

          instead we just make one thats wired at WGS84, and consider a separate point class that is "expert" or "custom" that works with other models.

          +1 to make WGS84 the "obvious" default, and all other planet models
          expert: it's the best earth model spatial3d has.

          I also wonder if we can somehow improve the naming ... 3D makes it
          seem like you get to index altitude as well, but that's not the case
          (you are still indexing and searching points described with 2D
          coordinates, e.g. lat/lon). Rather, it's using math in unprojected
          (3D) space to more accurately compute things on the surface of the
          idealized (ellipsoid) planet. Anyway, these are separate issues ...

          If you folks make everything that we need package private, we're screwed.

          OK, let's leave them public then ... but they may move around a lot in
          the future! They are all already @lucene.experimental, I
          believe.

          Part of the thrill I get in contributing to open-source is knowing my code is used so widely, and hearing kind remarks of its usefulness. Don't you?

          Yes! But we need to stay focused in Lucene: we can't try to be
          everything to everyone otherwise we can't achieve the one job we do
          have (awesome indexing and searching) which is already hard enough by
          itself

          Show
          mikemccand Michael McCandless added a comment - I'd like to to consider separating these 2 classes out by package. +1, this seems like a good compromise, and it would match what we have in 5.x (separate package holds the Lucene classes from the "pure geo3d math" classes). instead we just make one thats wired at WGS84, and consider a separate point class that is "expert" or "custom" that works with other models. +1 to make WGS84 the "obvious" default, and all other planet models expert: it's the best earth model spatial3d has. I also wonder if we can somehow improve the naming ... 3D makes it seem like you get to index altitude as well, but that's not the case (you are still indexing and searching points described with 2D coordinates, e.g. lat/lon). Rather, it's using math in unprojected (3D) space to more accurately compute things on the surface of the idealized (ellipsoid) planet. Anyway, these are separate issues ... If you folks make everything that we need package private, we're screwed. OK, let's leave them public then ... but they may move around a lot in the future! They are all already @lucene.experimental , I believe. Part of the thrill I get in contributing to open-source is knowing my code is used so widely, and hearing kind remarks of its usefulness. Don't you? Yes! But we need to stay focused in Lucene: we can't try to be everything to everyone otherwise we can't achieve the one job we do have (awesome indexing and searching) which is already hard enough by itself
          Hide
          dsmiley David Smiley added a comment -

          So gents where does this leave us in terms of specific package naming to separate them? I made a recommendation; do you like it?

          • org.apache.lucene.spatial.3d gets the 2 Lucene classes.
          • org.apache.lucene.spatial.3d.geom (most of the current code goes here; it implements the geometries)

          The aspects of this I like the most are that it has "spatial" as an intermediate package (it's spatial after all; no denying that), and that it uses "geom" short for geometry for the computational geometry code. I don't particularly like "3d" but I have no better ideas right now. Perhaps "geo3d" to be consistent with the original (& current) branding?

          So just to be clear, Mike & Rob feel that keeping the 2 Lucene dependent classes here is better than separating them into different modules? I don't agree but so be it.

          Show
          dsmiley David Smiley added a comment - So gents where does this leave us in terms of specific package naming to separate them? I made a recommendation; do you like it? org.apache.lucene.spatial.3d gets the 2 Lucene classes. org.apache.lucene.spatial.3d.geom (most of the current code goes here; it implements the geometries) The aspects of this I like the most are that it has "spatial" as an intermediate package (it's spatial after all; no denying that), and that it uses "geom" short for geometry for the computational geometry code. I don't particularly like "3d" but I have no better ideas right now. Perhaps "geo3d" to be consistent with the original (& current) branding? So just to be clear, Mike & Rob feel that keeping the 2 Lucene dependent classes here is better than separating them into different modules? I don't agree but so be it.
          Hide
          dsmiley David Smiley added a comment -

          I meant to add that I understand many of the points you guys made... yet I don't see how separating the 2 classes from the module is detrimental to anything. Except perhaps maybe someone might first look in a geom only module and not find the 2 Lucene classes they were looking for if that's what they are actually looking for. Putting "geom" in the module name would help with that.

          Show
          dsmiley David Smiley added a comment - I meant to add that I understand many of the points you guys made... yet I don't see how separating the 2 classes from the module is detrimental to anything. Except perhaps maybe someone might first look in a geom only module and not find the 2 Lucene classes they were looking for if that's what they are actually looking for. Putting "geom" in the module name would help with that.
          Hide
          rcmuir Robert Muir added a comment -

          So gents where does this leave us in terms of specific package naming to separate them? I made a recommendation; do you like it?

          org.apache.lucene.spatial.3d gets the 2 Lucene classes.
          org.apache.lucene.spatial.3d.geom (most of the current code goes here; it implements the geometries)

          Well i don't like this since 3d is not a valid identifier in a java package.

          Personally i would think it should be named org.apache.lucene.spatial3d and org.apache.lucene.spatial3d.geom. Only because spatial3d is the module's name, and this formula seems to be the only/easiest way to scope/organize packages in our modules to prevent problems? Nearly all of our modules are this way more or less, with the exception of misc and sandbox which reuse packages like org.apache.lucene.index that really belong to core. I think we should clean this stuff up for java 9

          As far as the additional module, i still don't personally agree with that, but don't you think if we want to do that we still have to fix the java packages? So basically I'm saying either way, we want to not have all of spatial3d/geo3d piled in one package, so lets just start with that?

          Show
          rcmuir Robert Muir added a comment - So gents where does this leave us in terms of specific package naming to separate them? I made a recommendation; do you like it? org.apache.lucene.spatial.3d gets the 2 Lucene classes. org.apache.lucene.spatial.3d.geom (most of the current code goes here; it implements the geometries) Well i don't like this since 3d is not a valid identifier in a java package. Personally i would think it should be named org.apache.lucene.spatial3d and org.apache.lucene.spatial3d.geom . Only because spatial3d is the module's name, and this formula seems to be the only/easiest way to scope/organize packages in our modules to prevent problems? Nearly all of our modules are this way more or less, with the exception of misc and sandbox which reuse packages like org.apache.lucene.index that really belong to core . I think we should clean this stuff up for java 9 As far as the additional module, i still don't personally agree with that, but don't you think if we want to do that we still have to fix the java packages? So basically I'm saying either way, we want to not have all of spatial3d/geo3d piled in one package, so lets just start with that?
          Hide
          nknize Nicholas Knize added a comment -

          we want to not have all of spatial3d/geo3d piled in one package, so lets just start with that?

          +1 This would be a wonderful improvement.

          I'm also not a fan of the name *3d. It causes confusion that this package handles altitude. Since its dependency free I still think it makes most sense to refactor it to the spatial module under a geometry package and just have the spatial and spatial-extras modules. Having a third just for a geometry model doesn't make sense to me.

          Of course, longer term, we should simplify the geom portion of the Geo API so the users don't care what the underlying geometry model is. That should be dictated by chosen datum/projection once we have support in place.

          Show
          nknize Nicholas Knize added a comment - we want to not have all of spatial3d/geo3d piled in one package, so lets just start with that? +1 This would be a wonderful improvement. I'm also not a fan of the name *3d. It causes confusion that this package handles altitude. Since its dependency free I still think it makes most sense to refactor it to the spatial module under a geometry package and just have the spatial and spatial-extras modules. Having a third just for a geometry model doesn't make sense to me. Of course, longer term, we should simplify the geom portion of the Geo API so the users don't care what the underlying geometry model is. That should be dictated by chosen datum/projection once we have support in place.
          Hide
          rcmuir Robert Muir added a comment -

          I'm also not a fan of the name *3d. It causes confusion that this package handles altitude.

          +1

          Show
          rcmuir Robert Muir added a comment - I'm also not a fan of the name *3d. It causes confusion that this package handles altitude. +1
          Hide
          dsmiley David Smiley added a comment -

          I'm also not a fan of the name *3d. It causes confusion that this package handles altitude.

          I agree as well but I'm at a loss to come up with a better name. Any suggestions? sphere-geom? Although it does ellipsoid too. At least "Geo3d" was the contribution name and current package name; and I've presented it under that name at a conference & meetup.

          Since its dependency free I still think it makes most sense to refactor it to the spatial module under a geometry package and just have the spatial and spatial-extras modules. Having a third just for a geometry model doesn't make sense to me.

          I realize my view may be unpopular but in my view, this module is itself a dependency, albeit a special one we have control over to modify as we please for our convenience.

          Show
          dsmiley David Smiley added a comment - I'm also not a fan of the name *3d. It causes confusion that this package handles altitude. I agree as well but I'm at a loss to come up with a better name. Any suggestions? sphere-geom? Although it does ellipsoid too. At least "Geo3d" was the contribution name and current package name; and I've presented it under that name at a conference & meetup. Since its dependency free I still think it makes most sense to refactor it to the spatial module under a geometry package and just have the spatial and spatial-extras modules. Having a third just for a geometry model doesn't make sense to me. I realize my view may be unpopular but in my view, this module is itself a dependency, albeit a special one we have control over to modify as we please for our convenience.
          Hide
          mikemccand Michael McCandless added a comment -

          Since its dependency free I still think it makes most sense to refactor it to the spatial module under a geometry package and just have the spatial and spatial-extras modules. Having a third just for a geometry model doesn't make sense to me.

          +1

          I'm also not a fan of the name *3d. It causes confusion that this package handles altitude.

          +1

          I feel the "3d-ness" is an implementation detail about how this package does very accurate spatial math, vs the 2d math in projected space which seems to be hard to get right (troubles we've had with the 2D points-based distance query).

          Personally i would think it should be named org.apache.lucene.spatial3d and org.apache.lucene.spatial3d.geom.

          +1

          So the user would use o.a.l.spatial3d.Geo3DPoint to do indexing and create queries, and then the geom sub-package has all the under-the-hood math.

          Show
          mikemccand Michael McCandless added a comment - Since its dependency free I still think it makes most sense to refactor it to the spatial module under a geometry package and just have the spatial and spatial-extras modules. Having a third just for a geometry model doesn't make sense to me. +1 I'm also not a fan of the name *3d. It causes confusion that this package handles altitude. +1 I feel the "3d-ness" is an implementation detail about how this package does very accurate spatial math, vs the 2d math in projected space which seems to be hard to get right (troubles we've had with the 2D points-based distance query). Personally i would think it should be named org.apache.lucene.spatial3d and org.apache.lucene.spatial3d.geom. +1 So the user would use o.a.l.spatial3d.Geo3DPoint to do indexing and create queries, and then the geom sub-package has all the under-the-hood math.
          Hide
          dsmiley David Smiley added a comment -

          Ok I will create a patch with the packages org.apache.lucene.spatial3d and org.apache.lucene.spatial3d.geom

          Show
          dsmiley David Smiley added a comment - Ok I will create a patch with the packages org.apache.lucene.spatial3d and org.apache.lucene.spatial3d.geom
          Hide
          dsmiley David Smiley added a comment -

          Here's the patch. Aside from letting my IDE do all the work, I also updated the package-info.java for geom, added a new package-info.java, and updated the overview.html a little. ant precommit passes, and I have the tests running now which I assume will be fine.

          Show
          dsmiley David Smiley added a comment - Here's the patch. Aside from letting my IDE do all the work, I also updated the package-info.java for geom, added a new package-info.java, and updated the overview.html a little. ant precommit passes, and I have the tests running now which I assume will be fine.
          Hide
          rcmuir Robert Muir added a comment -

          patch looks good to me at a glance

          Show
          rcmuir Robert Muir added a comment - patch looks good to me at a glance
          Hide
          dsmiley David Smiley added a comment -

          I've updated the patch since there were conflicts due to LUCENE-7072. I also noticed GeoPointTest in lucene-spatial-extras that should be moved to the other tests in spatial3d simply by removing a trivial reference to Spatial4j's DistanceUtils so I did that.

          FYI contrary to my claim in a comment or two ago, the Geo3d brand/name whatever lives on as there's Geo3dPoint, Geo3dShape and some misc utilities starting with that prefix.

          I'll commit this tonight as I think we have agreement here, but if I get a +1 I may do it sooner.

          Show
          dsmiley David Smiley added a comment - I've updated the patch since there were conflicts due to LUCENE-7072 . I also noticed GeoPointTest in lucene-spatial-extras that should be moved to the other tests in spatial3d simply by removing a trivial reference to Spatial4j's DistanceUtils so I did that. FYI contrary to my claim in a comment or two ago, the Geo3d brand/name whatever lives on as there's Geo3dPoint, Geo3dShape and some misc utilities starting with that prefix. I'll commit this tonight as I think we have agreement here, but if I get a +1 I may do it sooner.
          Hide
          nknize Nicholas Knize added a comment -

          +1 for new patch

          Show
          nknize Nicholas Knize added a comment - +1 for new patch
          Hide
          mikemccand Michael McCandless added a comment -

          the Geo3d brand/name whatever lives on

          Do you have an alternative? I would love to rename the public Lucene index/search APIs here to something that doesn't imply altitude is supported ...

          Show
          mikemccand Michael McCandless added a comment - the Geo3d brand/name whatever lives on Do you have an alternative? I would love to rename the public Lucene index/search APIs here to something that doesn't imply altitude is supported ...
          Hide
          kwright@metacarta.com Karl Wright added a comment -

          FWIW, I wrestled with naming for quite a long time but could find nothing better to distinguish the 2d world from the 3d one. And there may well be an attempt to add altitude to geo3d someday as well, which would confuse everyone to no end.

          The best I could come up with used map projection, e.g. 2D = "cartesian" and 3D = "spherical". But "spherical" is also misleading since ellipsoids are described too. Argh.

          Show
          kwright@metacarta.com Karl Wright added a comment - FWIW, I wrestled with naming for quite a long time but could find nothing better to distinguish the 2d world from the 3d one. And there may well be an attempt to add altitude to geo3d someday as well, which would confuse everyone to no end. The best I could come up with used map projection, e.g. 2D = "cartesian" and 3D = "spherical". But "spherical" is also misleading since ellipsoids are described too. Argh.
          Hide
          dsmiley David Smiley added a comment -

          I think if we can't think of a better name than Geo3D, we should embrace it despite its imperfect name. I have no better alternatives... other than including "geom" in some way (e.g. a package) to emphasize the geometry portion to distinguish the geometries/math from Lucene Query/Field integration.

          Show
          dsmiley David Smiley added a comment - I think if we can't think of a better name than Geo3D, we should embrace it despite its imperfect name. I have no better alternatives... other than including "geom" in some way (e.g. a package) to emphasize the geometry portion to distinguish the geometries/math from Lucene Query/Field integration.
          Hide
          mikemccand Michael McCandless added a comment -

          Naming is the hardest part But I think that should be moot in this case, because I think geo3d shouldn't ever be seen by users: it's a low level geo math implementation detail.

          Lucene's dimensional point values (new in 6.0.0) are agnostic to whatever "user space math" is used at search time to guide the intersection, and so we should pick, in the spatial module, whatever math 1) gives the right results (no fuzziness in the tests!) and 2) has good performance with no adversaries, and give that to our users as the "spatial" indexing and searching implementation.

          The math in projected 2D space seems fraught with accuracy issues that after much iterating won't go away, e.g. see the struggles in LUCENE-6698, LUCENE-6540, LUCENE-7054. Only that last issue (LUCENE-7054) finally succeeded in adding a points based distance query that can pass its test that don't allow for any "fuzz", except for quantization error, and only then by doing the most limited of geo 2D math (so limited this query could easily be promoted to core), but likely leaving a lot of search performance on the table. Even so, it seems (based on the London, UK bench) to have similar performance to the legacy (postings based) GeoPointDistanceQuery.

          I tested the corresponding geo3d distance query (as best I could so far) and it has nearly 2X the performance as our geo2d solution from LUCENE-7054, so unless we can fix the geo2d math to be an "admissible" optimization for Lucene's points, I think we should plan to make geo3d our default spatial implementation going forwards, so that users index a LatLonPointField and under the hood it's using the accurate, and fast, geo3d math.

          Show
          mikemccand Michael McCandless added a comment - Naming is the hardest part But I think that should be moot in this case, because I think geo3d shouldn't ever be seen by users: it's a low level geo math implementation detail. Lucene's dimensional point values (new in 6.0.0) are agnostic to whatever "user space math" is used at search time to guide the intersection, and so we should pick, in the spatial module, whatever math 1) gives the right results (no fuzziness in the tests!) and 2) has good performance with no adversaries, and give that to our users as the "spatial" indexing and searching implementation. The math in projected 2D space seems fraught with accuracy issues that after much iterating won't go away, e.g. see the struggles in LUCENE-6698 , LUCENE-6540 , LUCENE-7054 . Only that last issue ( LUCENE-7054 ) finally succeeded in adding a points based distance query that can pass its test that don't allow for any "fuzz", except for quantization error, and only then by doing the most limited of geo 2D math (so limited this query could easily be promoted to core), but likely leaving a lot of search performance on the table. Even so, it seems (based on the London, UK bench) to have similar performance to the legacy (postings based) GeoPointDistanceQuery . I tested the corresponding geo3d distance query (as best I could so far) and it has nearly 2X the performance as our geo2d solution from LUCENE-7054 , so unless we can fix the geo2d math to be an "admissible" optimization for Lucene's points, I think we should plan to make geo3d our default spatial implementation going forwards, so that users index a LatLonPointField and under the hood it's using the accurate, and fast, geo3d math.
          Hide
          kwright@metacarta.com Karl Wright added a comment -

          Would there be a difference in index space requirements?

          Show
          kwright@metacarta.com Karl Wright added a comment - Would there be a difference in index space requirements?
          Hide
          rcmuir Robert Muir added a comment -

          +1, this is all implementation detail. That's why i like the package-private idea as well (i know it was not a popular idea here).

          calling this stuff spatial3D or geo3D causes infinite amount of confusion.

          The user does not need to know more than new LatLonPoint(lat, lon), LatLonPointField.newDistanceQuery, LatLonPointField.newPolygonQuery, LatLonPointField.nearestNeighbor, etc.

          I just had another conversation with someone today who had the same confusion as me with geo3d. I had to say "wait, stop everything, geo3d does not do altitude" and then explain what its doing.

          Show
          rcmuir Robert Muir added a comment - +1, this is all implementation detail. That's why i like the package-private idea as well (i know it was not a popular idea here). calling this stuff spatial3D or geo3D causes infinite amount of confusion. The user does not need to know more than new LatLonPoint(lat, lon) , LatLonPointField.newDistanceQuery , LatLonPointField.newPolygonQuery , LatLonPointField.nearestNeighbor , etc. I just had another conversation with someone today who had the same confusion as me with geo3d. I had to say "wait, stop everything, geo3d does not do altitude" and then explain what its doing.
          Hide
          rcmuir Robert Muir added a comment -

          Karl: that is also a good point. If the 2D field in sandbox is really not better in any way, e.g. if the 3D one is twice as fast, even if its e.g. 50% bigger, i think we should just ditch the 2D stuff. Why offer a slower implementation?

          Of course we should try to consolidate testing and all that stuff. And maybe its ok for the 2D to live in the sandbox for a little bit, maybe someone can optimize the 2D speed to be more competitive, I don't know.

          Show
          rcmuir Robert Muir added a comment - Karl: that is also a good point. If the 2D field in sandbox is really not better in any way, e.g. if the 3D one is twice as fast, even if its e.g. 50% bigger, i think we should just ditch the 2D stuff. Why offer a slower implementation? Of course we should try to consolidate testing and all that stuff. And maybe its ok for the 2D to live in the sandbox for a little bit, maybe someone can optimize the 2D speed to be more competitive, I don't know.
          Hide
          mikemccand Michael McCandless added a comment -

          Yeah ... but I think they are all in the ballpark: geo2d index is ~630M, the geo3d index is ~800M, and the legacy GeoPoint (postings based) index is ~772 MB (on the London, UK bechmark).

          I think query-time tradeoffs (~2X faster, more accurate for distance query) really should drive the decision of what we present as Lucene's spatial implementation.

          Show
          mikemccand Michael McCandless added a comment - Yeah ... but I think they are all in the ballpark: geo2d index is ~630M, the geo3d index is ~800M, and the legacy GeoPoint (postings based) index is ~772 MB (on the London, UK bechmark). I think query-time tradeoffs (~2X faster, more accurate for distance query) really should drive the decision of what we present as Lucene's spatial implementation.
          Hide
          kwright@metacarta.com Karl Wright added a comment - - edited

          The user does not need to know more than new LatLonPoint(lat, lon), LatLonPointField.newDistanceQuery, LatLonPointField.newPolygonQuery, LatLonPointField.nearestNeighbor, etc.

          There is more than one strategy you can use with geo3D for filtering results. You can certainly use the BKD query but there are other ways; you may also want to score results using distance functions in geo3d itself. Making things package-private would prevent that unless such functionality made its way into some higher-level API.

          Show
          kwright@metacarta.com Karl Wright added a comment - - edited The user does not need to know more than new LatLonPoint(lat, lon), LatLonPointField.newDistanceQuery, LatLonPointField.newPolygonQuery, LatLonPointField.nearestNeighbor, etc. There is more than one strategy you can use with geo3D for filtering results. You can certainly use the BKD query but there are other ways; you may also want to score results using distance functions in geo3d itself. Making things package-private would prevent that unless such functionality made its way into some higher-level API.
          Hide
          mikemccand Michael McCandless added a comment -

          +1, this is all implementation detail.

          +1

          We don't tell our users about "geo2d", give talks about it, feel compelled to stick to it, fight over how to rename it Because that 2D math is also an implementation detail.

          Show
          mikemccand Michael McCandless added a comment - +1, this is all implementation detail. +1 We don't tell our users about "geo2d", give talks about it, feel compelled to stick to it, fight over how to rename it Because that 2D math is also an implementation detail.
          Hide
          dsmiley David Smiley added a comment -

          I think the notion of a default spatial implementation is flawed. Perhaps "preferred" if it handles many use-cases. Geo3d is cool 'n all, but for anyone with polygonal data/queries, it is most likely that the data was authored in a specific projected (2D) space (e.g. web-mercator), and as-such it would be invalid to use a a spherical/ellipsoidal model. Another factor Karl just mentioned is for sorting. If you want to sort your data, you might not want the BKD index.

          Show
          dsmiley David Smiley added a comment - I think the notion of a default spatial implementation is flawed. Perhaps "preferred" if it handles many use-cases. Geo3d is cool 'n all, but for anyone with polygonal data/queries, it is most likely that the data was authored in a specific projected (2D) space (e.g. web-mercator), and as-such it would be invalid to use a a spherical/ellipsoidal model. Another factor Karl just mentioned is for sorting. If you want to sort your data, you might not want the BKD index.
          Hide
          nknize Nicholas Knize added a comment -

          I'm also not sure I'm comfortable making definitive performance statements based on the London test set? While its testing with a reasonable amount of data and many queries, its not exercising anything beyond a relatively small bounding area. For example, I noticed considerable performance degradation when exercising BKD w/ Geo3D/Spatial3D on global data sets (simply through beasting). This is when adversarial rectangles were created like: http://imagebin.ca/v/2ZSrT1nVbIHn and the postings based approach actually performed better. In performance testing TermEnum updates I also noticed orders of magnitude improvements when beasting the testcases and only marginal improvements when testing with the London set.

          I've spent a bit of time working on adding Geo benchmarks to luceneutil. I think we can make more informed decisions about what to add/remove and which approach to use once we have decent nightly benchmarks to characterize performance. Remember, the Postings approach is not an "incorrect" or even a wholly "suboptimal" approach. Its a raster approach which lends itself well to certain use-cases.

          Show
          nknize Nicholas Knize added a comment - I'm also not sure I'm comfortable making definitive performance statements based on the London test set? While its testing with a reasonable amount of data and many queries, its not exercising anything beyond a relatively small bounding area. For example, I noticed considerable performance degradation when exercising BKD w/ Geo3D/Spatial3D on global data sets (simply through beasting). This is when adversarial rectangles were created like: http://imagebin.ca/v/2ZSrT1nVbIHn and the postings based approach actually performed better. In performance testing TermEnum updates I also noticed orders of magnitude improvements when beasting the testcases and only marginal improvements when testing with the London set. I've spent a bit of time working on adding Geo benchmarks to luceneutil. I think we can make more informed decisions about what to add/remove and which approach to use once we have decent nightly benchmarks to characterize performance. Remember, the Postings approach is not an "incorrect" or even a wholly "suboptimal" approach. Its a raster approach which lends itself well to certain use-cases.
          Hide
          kwright@metacarta.com Karl Wright added a comment - - edited

          Any approach one picks will degrade if given a sufficient number of pathological cases; it's usually not a good idea to optimize for that. A worldwide selection of points are typically quite localized on the globe – if they are confined to land areas – and search shapes are typically not bizarre polygons or rectangles but usually pretty regular ones.

          But it probably makes sense to evaluate using a better global test set, and not an artificial one.

          Show
          kwright@metacarta.com Karl Wright added a comment - - edited Any approach one picks will degrade if given a sufficient number of pathological cases; it's usually not a good idea to optimize for that. A worldwide selection of points are typically quite localized on the globe – if they are confined to land areas – and search shapes are typically not bizarre polygons or rectangles but usually pretty regular ones. But it probably makes sense to evaluate using a better global test set, and not an artificial one.
          Hide
          kwright@metacarta.com Karl Wright added a comment -

          Right, I have no doubt that there exists a need for drawing straight boundary lines on a mercator projection, even if this corresponds to curves on the real world, because that's what some people need to be compatible with.

          Show
          kwright@metacarta.com Karl Wright added a comment - Right, I have no doubt that there exists a need for drawing straight boundary lines on a mercator projection, even if this corresponds to curves on the real world, because that's what some people need to be compatible with.
          Hide
          mikemccand Michael McCandless added a comment -

          But it probably makes sense to evaluate using a better global test set, and not an artificial one.

          +1 for real data, not synthetic data. I think when one tests on synthetic data, one draws synthetic conclusions.

          The London UK test I've been running (all sources in luceneutil) is 2.5% of ALL the world's OpenStreetMap (PlanetOSM) points, plus 100% of the points contained within the bbox around London, UK, so it really is a global test, just with a sampling of the world's points. It's ~61M total points.

          But I agree that 2.5% sampling is not realistic ... I'll download the latest OSM export (48 GB .bz2!) and try to index all points, and test on larger shapes across the globe.

          Does anyone have any pointers for other large realistic geospatial corpora? Geonames is smallish (~8.6 M docs in my snapshot, though that's ~2 years ago now).

          I've spent a bit of time working on adding Geo benchmarks to luceneutil. I think we can make more informed decisions about what to add/remove and which approach to use once we have decent nightly benchmarks to characterize performance.

          +1 to get these benchmarks folded into our nightly benchmark (so we can catch/measure regressions/improvements over time), and to make it easier for anyone to run them.

          Show
          mikemccand Michael McCandless added a comment - But it probably makes sense to evaluate using a better global test set, and not an artificial one. +1 for real data, not synthetic data. I think when one tests on synthetic data, one draws synthetic conclusions. The London UK test I've been running (all sources in luceneutil) is 2.5% of ALL the world's OpenStreetMap (PlanetOSM) points, plus 100% of the points contained within the bbox around London, UK, so it really is a global test, just with a sampling of the world's points. It's ~61M total points. But I agree that 2.5% sampling is not realistic ... I'll download the latest OSM export (48 GB .bz2!) and try to index all points, and test on larger shapes across the globe. Does anyone have any pointers for other large realistic geospatial corpora? Geonames is smallish (~8.6 M docs in my snapshot, though that's ~2 years ago now). I've spent a bit of time working on adding Geo benchmarks to luceneutil. I think we can make more informed decisions about what to add/remove and which approach to use once we have decent nightly benchmarks to characterize performance. +1 to get these benchmarks folded into our nightly benchmark (so we can catch/measure regressions/improvements over time), and to make it easier for anyone to run them.
          Hide
          dsmiley David Smiley added a comment -

          Where do we stand with my patch? I think it's surely an improvement but are there changes yet we shall make? I can hold off but I'm hoping there's no commits to spatial3d/Geo3d in the interim as it's a pain to redo.

          Show
          dsmiley David Smiley added a comment - Where do we stand with my patch? I think it's surely an improvement but are there changes yet we shall make? I can hold off but I'm hoping there's no commits to spatial3d/Geo3d in the interim as it's a pain to redo.
          Hide
          mikemccand Michael McCandless added a comment -

          +1 to your patch David Smiley, it's an improvement.

          Sorry for causing conflicts, and sorry for having this big sudden discussion about whether Lucene should adopt geo2d or geo3d as its preferred spatial math under-the-hood, here

          These ideas can be explored in later issues; I don't think we'll sort it out in time for 6.0.0, which is fine (these are all experimental APIs).

          Show
          mikemccand Michael McCandless added a comment - +1 to your patch David Smiley , it's an improvement. Sorry for causing conflicts, and sorry for having this big sudden discussion about whether Lucene should adopt geo2d or geo3d as its preferred spatial math under-the-hood, here These ideas can be explored in later issues; I don't think we'll sort it out in time for 6.0.0, which is fine (these are all experimental APIs).
          Hide
          nknize Nicholas Knize added a comment -

          search shapes are typically not bizarre polygons or rectangles

          I guess I should have clarified. The adversarial rectangles are created from internal BKD nodes during split, they are not bizarre rectangles one would create from a query. They are also not an abnormal corner case. Adversarial rectangles can/will be created unless you know your data in advance.

          A worldwide selection of points are typically quite localized on the globe

          +1. localized clusters. Unless separate indexes are created for different regions - a viable recommendation if we find global data sets to drastically degrade search performance.

          But it probably makes sense to evaluate using a better global test set.

          Any good spatial indexing benchmark (as seen in most publications) should test with real data, but also not ignore the sparse random data sets just for characterizing performance for randomly distributed spatial data applications (regardless of the popularity of this type of use case).

          Show
          nknize Nicholas Knize added a comment - search shapes are typically not bizarre polygons or rectangles I guess I should have clarified. The adversarial rectangles are created from internal BKD nodes during split, they are not bizarre rectangles one would create from a query. They are also not an abnormal corner case. Adversarial rectangles can/will be created unless you know your data in advance. A worldwide selection of points are typically quite localized on the globe +1. localized clusters. Unless separate indexes are created for different regions - a viable recommendation if we find global data sets to drastically degrade search performance. But it probably makes sense to evaluate using a better global test set. Any good spatial indexing benchmark (as seen in most publications) should test with real data, but also not ignore the sparse random data sets just for characterizing performance for randomly distributed spatial data applications (regardless of the popularity of this type of use case).
          Hide
          kwright@metacarta.com Karl Wright added a comment -

          The adversarial rectangles are created from internal BKD nodes during split, they are not bizarre rectangles one would create from a query.

          With geo3d, though, the splits are rectangular solids in (x,y,z), not rectangles on the sphere surface. That's kind of why I was confused by your graphic, which looked nothing like a geo3d BKD split that I know of. One area looked like a circle, and the other was the pointy tip of a very long polygon . So either the shape was a circle and the split made no sense, or the split was a circle and the shape was a bizarre one?

          Show
          kwright@metacarta.com Karl Wright added a comment - The adversarial rectangles are created from internal BKD nodes during split, they are not bizarre rectangles one would create from a query. With geo3d, though, the splits are rectangular solids in (x,y,z), not rectangles on the sphere surface. That's kind of why I was confused by your graphic, which looked nothing like a geo3d BKD split that I know of. One area looked like a circle, and the other was the pointy tip of a very long polygon . So either the shape was a circle and the split made no sense, or the split was a circle and the shape was a bizarre one?
          Hide
          nknize Nicholas Knize added a comment -

          To keep from further hijacking David Smiley thread I'll open a separate issue to further investigate this issue. I actually think this can be solved during segment merge where we have a broader view of the data in bulk as opposed to inserting point by point. It gives a chance to build a more efficient KD tree.

          not rectangles on the surface sphere

          That rectangle was from a higher level (I think it was level 2 or 3) internal BKD node while testing LatLonPoint during a distance query. Since the split happens along one of the lat lon dimensions those values were taken from the lat lon rages of the internal node. Any query (bbox, distance, poly) that intersects that long rectangle recurses into the rectangle. This node was visited quite often

          Show
          nknize Nicholas Knize added a comment - To keep from further hijacking David Smiley thread I'll open a separate issue to further investigate this issue. I actually think this can be solved during segment merge where we have a broader view of the data in bulk as opposed to inserting point by point. It gives a chance to build a more efficient KD tree. not rectangles on the surface sphere That rectangle was from a higher level (I think it was level 2 or 3) internal BKD node while testing LatLonPoint during a distance query. Since the split happens along one of the lat lon dimensions those values were taken from the lat lon rages of the internal node. Any query (bbox, distance, poly) that intersects that long rectangle recurses into the rectangle. This node was visited quite often
          Hide
          jira-bot ASF subversion and git services added a comment -

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

          LUCENE-7056: Geo3D package re-org

          Show
          jira-bot ASF subversion and git services added a comment - Commit f7f81c3284cb855136c4e468b6e1f73cf58ced4c in lucene-solr's branch refs/heads/master from David Smiley [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f7f81c3 ] LUCENE-7056 : Geo3D package re-org
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 0a1951bef2ca7e18993ca167ff0c20f2e13e3c84 in lucene-solr's branch refs/heads/branch_6_0 from David Smiley
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0a1951b ]

          LUCENE-7056: Geo3D package re-org
          (cherry picked from commit 3a31a8c)

          Show
          jira-bot ASF subversion and git services added a comment - Commit 0a1951bef2ca7e18993ca167ff0c20f2e13e3c84 in lucene-solr's branch refs/heads/branch_6_0 from David Smiley [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=0a1951b ] LUCENE-7056 : Geo3D package re-org (cherry picked from commit 3a31a8c)

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development