[jira] [Updated] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7906: - Attachment: LUCENE-7906.patch > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7906: - Attachment: (was: LUCENE-7906.patch) > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16110521#comment-16110521 ] Ignacio Vera commented on LUCENE-7906: -- Hi [~daddywri], I have attached a new path withrandom test. I have actually created a randomGeoShapeGenerator that allows me to generate Random shapes with known spatial properties. All tests seems ok. I have tried to push down GeoArea down to GeoShape and I didn't get any surpises and it can be easily test with small modification in the new random shape generator. But (there is always a but), the implementation is currently not so clean because the class GeoCompositeMembershipShape does not extends any of the base classes. Cheers, I. > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7906: - Attachment: LUCENE-7906-AreaShape.patch Hi [~daddywri], Attached is a new Patch with the new proposed interface GeoAreaShape. It was trivial to add this new interface for existing Shapes. I created a new composite for GeoAreaShape and use it as the base class for GeoCompositePolygon. > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906-AreaShape.patch, LUCENE-7906.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16110828#comment-16110828 ] Ignacio Vera commented on LUCENE-7906: -- No, The current patch is very similar to the last one only adding GeoArea to GeoPolygons but with the radomShapeGenerator tests. I am looking forward to hearing what you want to propose. > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16110911#comment-16110911 ] Ignacio Vera commented on LUCENE-7906: -- (1) I propose is to create a new interface that implements GeoShape and GeoArea and adds the insersects method. I would prefer to call the interface GeoAreaShape. (2) No, the randomized tests use a random planetmodel calling the method randomPlanetModel(). Note I kept the orginal hardcoded test I developed at the begining, which are focused in the SPHERE. > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112812#comment-16112812 ] Ignacio Vera commented on LUCENE-7906: -- [~daddywri], thanks for committing this new feature, I hope it will prove very useful as well for my use case. I am already using them in LUCENE with very promising results. The big offender is the CONTAINS test as finding the right shape can be difficult because there is too much freedom. I have considered removing it all together as the feature is tested in the WITHIN test (being the opposite case). Then the tests converge quite fast. > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906-AreaShape.patch, LUCENE-7906.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16114054#comment-16114054 ] Ignacio Vera commented on LUCENE-7906: -- thanks for fixing these issues. I found the ticket about the issue of using Math.toRadians and I understand why it is troblesome. Hopefully it will be stable now! > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906-AreaShape.patch, LUCENE-7906.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-7918) Give access to members of a composite shape
Ignacio Vera created LUCENE-7918: Summary: Give access to members of a composite shape Key: LUCENE-7918 URL: https://issues.apache.org/jira/browse/LUCENE-7918 Project: Lucene - Core Issue Type: Improvement Components: modules/spatial3d Reporter: Ignacio Vera Hi [~daddywri], I hope this is my last point in my wish list. In order to serialize objects I need to access the members of a composite geoshape. This is currently not possible so I was wondering if it is possible to add to more methods to the class GeoCompositeMembershipShape: public int size() public GeoMembershipShape getShape(int index) Thanks, Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7906: - Attachment: LUCENE-7906-AreaShape.patch Attached a new version. The compiler warnings should be gone now. I lower the iterations so the complete suit typically runs in ~30 sec. The slower test in the new suite is the contains because sometimes it takes a few seconds to find the right shape. you can control iteration under the class RandomGeoShapeRelationshipTest. At the moment is set to 5 except for contains which is not repeated. > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906-AreaShape.patch, LUCENE-7906.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (LUCENE-7918) Give access to members of a composite shape
[ https://issues.apache.org/jira/browse/LUCENE-7918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera reopened LUCENE-7918: -- Hi [~daddywri], I found an small issue with the composite shapes. I think this issue existed before so not sure if the behavior is intended. The problem comes from the way equality is defined in GeoBaseCompositeShape, in particular the return in line 119: return super.equals(o) && shapes.equals(other.shapes); I think the call to the parent class should be removed or equals will only return true if it is the same instance: return shapes.equals(other.shapes); What do you think? Cheers, I. > Give access to members of a composite shape > --- > > Key: LUCENE-7918 > URL: https://issues.apache.org/jira/browse/LUCENE-7918 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Fix For: 6.6, master (8.0), 7.1 > > Attachments: LUCENE-7918.patch > > > Hi [~daddywri], > I hope this is my last point in my wish list. In order to serialize objects I > need to access the members of a composite geoshape. This is currently not > possible so I was wondering if it is possible to add to more methods to the > class GeoCompositeMembershipShape: > public int size() > public GeoMembershipShape getShape(int index) > Thanks, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7918) Give access to members of a composite shape
[ https://issues.apache.org/jira/browse/LUCENE-7918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16121463#comment-16121463 ] Ignacio Vera commented on LUCENE-7918: -- Note one thing as well. If you remove that, the following case will be true: 1. Create a GeoCompositeMembershipShape 2. Create a GeoCompositeAreaShape 3. add the same shapes to the composites: Then both are equal, is that right? or should be add equals methods to the other composites? > Give access to members of a composite shape > --- > > Key: LUCENE-7918 > URL: https://issues.apache.org/jira/browse/LUCENE-7918 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Fix For: 6.6, master (8.0), 7.1 > > Attachments: LUCENE-7918.patch > > > Hi [~daddywri], > I hope this is my last point in my wish list. In order to serialize objects I > need to access the members of a composite geoshape. This is currently not > possible so I was wondering if it is possible to add to more methods to the > class GeoCompositeMembershipShape: > public int size() > public GeoMembershipShape getShape(int index) > Thanks, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7918) Give access to members of a composite shape
[ https://issues.apache.org/jira/browse/LUCENE-7918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16121501#comment-16121501 ] Ignacio Vera commented on LUCENE-7918: -- Thanks for the quick fix [~daddywri]! I am not too alarmed either :) If I find the time I will submit a patch as I think it is a better behavior and as you said close the hole. > Give access to members of a composite shape > --- > > Key: LUCENE-7918 > URL: https://issues.apache.org/jira/browse/LUCENE-7918 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Fix For: 6.6, master (8.0), 7.1 > > Attachments: LUCENE-7918.patch > > > Hi [~daddywri], > I hope this is my last point in my wish list. In order to serialize objects I > need to access the members of a composite geoshape. This is currently not > possible so I was wondering if it is possible to add to more methods to the > class GeoCompositeMembershipShape: > public int size() > public GeoMembershipShape getShape(int index) > Thanks, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16089788#comment-16089788 ] Ignacio Vera commented on LUCENE-7906: -- Ok, I understand and I will try to follow similar strategy for polygons when possible. Thanks! Ignacio > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16089690#comment-16089690 ] Ignacio Vera commented on LUCENE-7906: -- Hi [~daddywri], I would try to do so. I have already some code that works for simple polygons. Let see if I manage for more complex cases. I am concern with the case of GeoComplexPolygon but I will have a try. By the way, there is something in the implementation of getRelationship in GeoRectangle that seems wrong. The method call another method in GeoBaseBox called isShapeInsideBBox. In this methods there is the following call: final GeoPoint[] pathPoints = path.getEdgePoints(); Expecting more than one point returned that is not true as the doc says: /** * Return a sample point that is on the outside edge/boundary of the shape. * * @return samples of all edge points from distinct edge sections. Typically one point * is returned, but zero or two are also possible. */ public GeoPoint[] getEdgePoints(); I think that method is not doing what it is expected. Still the overall method getRelationship seems to work. Cheers, I. > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (LUCENE-7853) Request to change visibility of classes in geo3d
[ https://issues.apache.org/jira/browse/LUCENE-7853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera closed LUCENE-7853. Change applied. Thanks! > Request to change visibility of classes in geo3d > > > Key: LUCENE-7853 > URL: https://issues.apache.org/jira/browse/LUCENE-7853 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Fix For: 7.0, 6.7 > > Attachments: LUCENE-7853.patch > > > I am creating my own spatial context by wrapping the objects in lucene geo3d > library and implement my own query which mixes the recursive and the > serialized strategy to add precision to searches. > > I had the following issue specially with polygons: The factory for creating > polygons is slow and when serializing shapes, I already know if I am dealing > with convex or concave polygons (in my case they are always concave). So when > de-serializing a polygon I do not want to go through the factory to decide > the type of polygon to create. > > Wouldn't make sense to add the possibility to create a type of polygon > directly? you cannot create the polygons directly as they are protected in > the package. My suggestion request would be either to add methods in the > polygon factory to create a type of polygons with no checking (e.g. > makeConcavePolygon(…)) or change the visibility of the classes so that they > can be instantiated directly. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-7906) Spatial relationship between Geoshapes
Ignacio Vera created LUCENE-7906: Summary: Spatial relationship between Geoshapes Key: LUCENE-7906 URL: https://issues.apache.org/jira/browse/LUCENE-7906 Project: Lucene - Core Issue Type: Improvement Components: modules/spatial3d Reporter: Ignacio Vera Hi, Working with geosahpes and trying to resolve spatial relationships between them I came accross a big limitation when trying to solve the relationship between two geopolygons. This object does not expose the internal structure. In particular at some point, it is necessary to check if one polygon intersects the edges of the other polygon which currently is not possible as edges are not exposed. To be able to perform such operation it can be several options. The ones I can think of are: 1) Expose the edges of the polygon ( and probably the notable points for the edges) adding getters in the GeoPolygon interface. Easy to implement and leave users the responsability of coding the spatial relationship. 2) Extends GeoPolygon interface to extends geoarea and leave the object make the spatial relationship. 3) Extends GeoShape interface so all shapes can infer the spatial relationship with other GeoShapes. I might be bias as my interest is in 2d Shapes in the unit sphere and there might be some cases which what I propose cannot be implemented or are againts the aim of the library. What do you think? Cheers, Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7909) Issue with holes in polygons
[
https://issues.apache.org/jira/browse/LUCENE-7909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16091483#comment-16091483
]
Ignacio Vera commented on LUCENE-7909:
--
I think I understand, holes must be convex so the area inside is the area
between the hole and the edges of the polygon. Could you confirm?
> Issue with holes in polygons
>
>
> Key: LUCENE-7909
> URL: https://issues.apache.org/jira/browse/LUCENE-7909
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>
> Hi,
> It seems the behavior of adding holes to polygons is not behaving well. It
> seems it is all related to the following method:
> /** Check if a point is within the provided holes.
>*@param point point to check.
>*@return true if the point is within any of the holes.
>*/
> protected boolean isWithinHoles(final GeoPoint point) {
> if (holes != null) {
> for (final GeoPolygon hole : holes) {
> if (!hole.isWithin(point)) {
> return true;
> }
> }
> }
> return false;
> }
> The negation in the if clause is wrong. This affects two classes,
> GeoConvexPolygon and GeoConcavePolygon. I have ready a patch if you think it
> should be corrected.
> Thanks,
> I.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-7909) Issue with holes in polygons
Ignacio Vera created LUCENE-7909:
Summary: Issue with holes in polygons
Key: LUCENE-7909
URL: https://issues.apache.org/jira/browse/LUCENE-7909
Project: Lucene - Core
Issue Type: Bug
Components: modules/spatial3d
Reporter: Ignacio Vera
Hi,
It seems the behavior of adding holes to polygons is not behaving well. It
seems it is all related to the following method:
/** Check if a point is within the provided holes.
*@param point point to check.
*@return true if the point is within any of the holes.
*/
protected boolean isWithinHoles(final GeoPoint point) {
if (holes != null) {
for (final GeoPolygon hole : holes) {
if (!hole.isWithin(point)) {
return true;
}
}
}
return false;
}
The negation in the if clause is wrong. This affects two classes,
GeoConvexPolygon and GeoConcavePolygon. I have ready a patch if you think it
should be corrected.
Thanks,
I.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16094338#comment-16094338 ] Ignacio Vera commented on LUCENE-7906: -- I thought it was enough with skipping the internal edges but I can reproduce the behavior when I have a collection of shapes inside a GeoCompositeMembershipShape. The wrong behavior happens because of this call GeoBaseShape.isShapeInsidePolygon(final GeoShape geoShape). When checking in a multishape you might get SOME_INSIDE and therefore overlaps. The Polygon to be compared should be the composite polygon and not the subcomponent so the methods returns the correct answer ALL_INSIDE. What it means is that either GeoConvexPolygon and GeoConcavePolygon should have a reference to the parent composite polygon. I have implemented it and it works but it means that the contructor for those objects need to change. Is that ok? > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906.patch, LUCENE-7906-test.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7906: - Attachment: LUCENE-7906.patch Yes, you are right. I fixed the spelling mistake and improve coding style. > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906.patch, LUCENE-7906.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7906: - Attachment: (was: LUCENE-7906.patch) > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7906: - Attachment: (was: LUCENE-7906.patch) > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7906: - Attachment: LUCENE-7906.patch Yes, adding a new interface method to the polygon interface does the trick. I have added the method GeoPolygon.intersects(Geshape geoshape) and it is working as expected. Patch attached > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7906: - Attachment: (was: LUCENE-7906-test.patch) > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7906: - Attachment: (was: LUCENE-7906.patch) > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7906: - Attachment: LUCENE-7906.patch Move the getRelationship method down to the GeoBasePolygon. > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906.patch, LUCENE-7906.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16095821#comment-16095821 ] Ignacio Vera commented on LUCENE-7906: -- Hi [~daddywri], The problem with convex polygons is that the whole plane is within the shape and therefore if you try to bound the intersection with the convex polygon you get OVERLAP when the shape is actually WITHIN. What it holds true is that the bounds for an intersection for convex polygons are the ones defined by the convex counter part. Therefore I need to invert the shape to bound the intersection. The class variable is to cash the object so it is only created once. Does it make sense? I will try to implement randomized tests as well but it will take a bit longer because I have never used the framework and I am actually having problems running those tests (environment issues). Finally, I want to go back to the idea of moving GeoArea down to GeoShape. If the implementation for polygons is valid, it means that any shape that can implement the new interface method intersects(GeoShape geoShape) can implement GeoArea. You were concerned about circle intersection but I think it is a trivial implementation. We only need to add the interface GeoOutsideDistance to GeoShape which is free as all shapes already implement the interface. Then intersection is trivial by calculating the distance of the shape to the center of the circle. What do you think? Cheers, Ignacio > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes
[
https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101670#comment-16101670
]
Ignacio Vera commented on LUCENE-7906:
--
I coorected the code above.
I found the issue, it is in line 496 of GeoComplexPolygon:
if (right != null && minValue >= low && right.traverse(edgeIterator, minValue,
maxValue) == false) {
|It seems that the condition minValue >= low prevents to look for necessary
planes. If a change the condition to maxValue >= low my test run smooth but I
don't know if is correct. What it is sure is that the conditin is not right.
Any ideas?
> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between
> them I came accross a big limitation when trying to solve the relationship
> between two geopolygons. This object does not expose the internal structure.
> In particular at some point, it is necessary to check if one polygon
> intersects the edges of the other polygon which currently is not possible as
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the
> edges) adding getters in the GeoPolygon interface. Easy to implement and
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make
> the spatial relationship.
> 3) Extends GeoShape interface so all shapes can infer the spatial
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there
> might be some cases which what I propose cannot be implemented or are againts
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-7906) Spatial relationship between Geoshapes
[
https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101670#comment-16101670
]
Ignacio Vera edited comment on LUCENE-7906 at 7/26/17 1:37 PM:
---
I corrected the code above.
I found the issue, it is in line 496 of GeoComplexPolygon:
if (right != null && minValue >= low && right.traverse(edgeIterator, minValue,
maxValue) == false) {
|It seems that the condition minValue >= low prevents to look for necessary
planes. If a change the condition to maxValue >= low my test run smooth but I
don't know if it is correct. What it is sure is that the condition is not
right. Any ideas?
was (Author: ivera):
I coorected the code above.
I found the issue, it is in line 496 of GeoComplexPolygon:
if (right != null && minValue >= low && right.traverse(edgeIterator, minValue,
maxValue) == false) {
|It seems that the condition minValue >= low prevents to look for necessary
planes. If a change the condition to maxValue >= low my test run smooth but I
don't know if is correct. What it is sure is that the conditin is not right.
Any ideas?
> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between
> them I came accross a big limitation when trying to solve the relationship
> between two geopolygons. This object does not expose the internal structure.
> In particular at some point, it is necessary to check if one polygon
> intersects the edges of the other polygon which currently is not possible as
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the
> edges) adding getters in the GeoPolygon interface. Easy to implement and
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make
> the spatial relationship.
> 3) Extends GeoShape interface so all shapes can infer the spatial
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there
> might be some cases which what I propose cannot be implemented or are againts
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-7906) Spatial relationship between Geoshapes
[
https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101644#comment-16101644
]
Ignacio Vera edited comment on LUCENE-7906 at 7/26/17 1:32 PM:
---
My qiestion is, is there any issue to implement intersects in the circle as:
@Override
public boolean intersects(GeoShape shape) {
if (circlePlane == null) {
return false;
}
return shape.intersects(circlePlane, circlePoints);
}
On another topic, I am having problems with GeoComplexPolygon. It seems they
way I have implemented and the more efficient way of intersects with plane on
the class give different results. I tried to implement an
IntersectorShapeIterator but some of my test were failing. I need to have a
closer look into that.
was (Author: ivera):
My qiestion is, is there any issue to implement intersects in the circle as:
@Override
public boolean intersects(GeoShape shape) {
if (circlePlane == null) {
return false;
}
return shape.intersects(planetModel, p, notablePoints, circlePoints);
}
On another topic, I am having problems with GeoComplexPolygon. It seems they
way I have implemented and the more efficient way of intersects with plane on
the class give different results. I tried to implement an
IntersectorShapeIterator but some of my test were failing. I need to have a
closer look into that.
> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between
> them I came accross a big limitation when trying to solve the relationship
> between two geopolygons. This object does not expose the internal structure.
> In particular at some point, it is necessary to check if one polygon
> intersects the edges of the other polygon which currently is not possible as
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the
> edges) adding getters in the GeoPolygon interface. Easy to implement and
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make
> the spatial relationship.
> 3) Extends GeoShape interface so all shapes can infer the spatial
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there
> might be some cases which what I propose cannot be implemented or are againts
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes
[
https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101644#comment-16101644
]
Ignacio Vera commented on LUCENE-7906:
--
My qiestion is, is there any issue to implement intersects in the circle as:
@Override
public boolean intersects(GeoShape shape) {
if (circlePlane == null) {
return false;
}
return shape.intersects(planetModel, p, notablePoints, circlePoints);
}
On another topic, I am having problems with GeoComplexPolygon. It seems they
way I have implemented and the more efficient way of intersects with plane on
the class give different results. I tried to implement an
IntersectorShapeIterator but some of my test were failing. I need to have a
closer look into that.
> Spatial relationship between Geoshapes
> --
>
> Key: LUCENE-7906
> URL: https://issues.apache.org/jira/browse/LUCENE-7906
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
> Attachments: LUCENE-7906.patch
>
>
> Hi,
> Working with geosahpes and trying to resolve spatial relationships between
> them I came accross a big limitation when trying to solve the relationship
> between two geopolygons. This object does not expose the internal structure.
> In particular at some point, it is necessary to check if one polygon
> intersects the edges of the other polygon which currently is not possible as
> edges are not exposed.
> To be able to perform such operation it can be several options. The ones I
> can think of are:
> 1) Expose the edges of the polygon ( and probably the notable points for the
> edges) adding getters in the GeoPolygon interface. Easy to implement and
> leave users the responsability of coding the spatial relationship.
> 2) Extends GeoPolygon interface to extends geoarea and leave the object make
> the spatial relationship.
> 3) Extends GeoShape interface so all shapes can infer the spatial
> relationship with other GeoShapes.
> I might be bias as my interest is in 2d Shapes in the unit sphere and there
> might be some cases which what I propose cannot be implemented or are againts
> the aim of the library.
> What do you think?
> Cheers,
> Ignacio
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101746#comment-16101746 ] Ignacio Vera commented on LUCENE-7906: -- Great! Shall I add it to the patch? I have the random test almost ready except for polygon with holes. I am concern because sometimes get a bit stuck when trying to build shapes with very specific characteristics. I will send you a new patch soon. > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16101725#comment-16101725 ] Ignacio Vera commented on LUCENE-7906: -- My feel is that there is a min value missing: * high: higher value of the node * low: lower value ofthe node * max: maximum value of the tree * min: (missing) minimum value of the tree. The condition you want to add is: minValue>=min insterad of minValue>=low ... then you discard edges out of scope. > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7906: - Attachment: LUCENE-7906.patch LUCENE-7906-test.patch Hi [~daddywri], Attached is the patches implementing GeoArea for polygons. I provide extended testing, Some notes: a) I have to modified the method getEdgePoints() from GeoCompositeMembershipShape. It ewas returning only the edge points for the first shape which seems incorrect. My implementation is not very efficient but works. b)To be able able to bound the intersection of convex polygons I create the conves counter part. Maybe there is more efficient way of doing that. c) Would it be worthy to push the geoArea interface down to GeoShape? Cheers, I. > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906.patch, LUCENE-7906-test.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7906: - Attachment: (was: LUCENE-7906-test.patch) > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906.patch, LUCENE-7906-test.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7906: - Attachment: LUCENE-7906-test.patch > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906.patch, LUCENE-7906-test.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16096164#comment-16096164 ] Ignacio Vera commented on LUCENE-7906: -- Ok, I did not know that distance calculation is only support for unit sphere. That is my use case so I guess I am bias. It is totally fine to leave things then as they are. Thanks for your suggestions, I will try to put everything together in the next week or so. Cheers, Ignacio > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16110917#comment-16110917 ] Ignacio Vera commented on LUCENE-7906: -- We clearly agree on the name. 100% agree, I will work on that! > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (LUCENE-7918) Give access to members of a composite shape
[ https://issues.apache.org/jira/browse/LUCENE-7918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera closed LUCENE-7918. Lucene Fields: (was: New) Thanks for your support! I hope these new features of the library are useful (sure for me!). > Give access to members of a composite shape > --- > > Key: LUCENE-7918 > URL: https://issues.apache.org/jira/browse/LUCENE-7918 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Fix For: 6.6, master (8.0), 7.1 > > Attachments: LUCENE-7918.patch > > > Hi [~daddywri], > I hope this is my last point in my wish list. In order to serialize objects I > need to access the members of a composite geoshape. This is currently not > possible so I was wondering if it is possible to add to more methods to the > class GeoCompositeMembershipShape: > public int size() > public GeoMembershipShape getShape(int index) > Thanks, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7918) Give access to members of a composite shape
[ https://issues.apache.org/jira/browse/LUCENE-7918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7918: - Attachment: LUCENE-7918.patch New version attached with "lucene-experimental" for public classes and "lucene-internal" for protected ones. The casting of Geopolygon is removed from the test. No warnings when compiling and precommit seems happy. > Give access to members of a composite shape > --- > > Key: LUCENE-7918 > URL: https://issues.apache.org/jira/browse/LUCENE-7918 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7918.patch > > > Hi [~daddywri], > I hope this is my last point in my wish list. In order to serialize objects I > need to access the members of a composite geoshape. This is currently not > possible so I was wondering if it is possible to add to more methods to the > class GeoCompositeMembershipShape: > public int size() > public GeoMembershipShape getShape(int index) > Thanks, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7918) Give access to members of a composite shape
[ https://issues.apache.org/jira/browse/LUCENE-7918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7918: - Attachment: (was: LUCENE-7918.patch) > Give access to members of a composite shape > --- > > Key: LUCENE-7918 > URL: https://issues.apache.org/jira/browse/LUCENE-7918 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7918.patch > > > Hi [~daddywri], > I hope this is my last point in my wish list. In order to serialize objects I > need to access the members of a composite geoshape. This is currently not > possible so I was wondering if it is possible to add to more methods to the > class GeoCompositeMembershipShape: > public int size() > public GeoMembershipShape getShape(int index) > Thanks, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7906: - Attachment: (was: LUCENE-7906-AreaShape.patch) > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906-AreaShape.patch, LUCENE-7906.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7918) Give access to members of a composite shape
[ https://issues.apache.org/jira/browse/LUCENE-7918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7918: - Attachment: LUCENE-7918.patch Hi [~daddywri], I am sorry of hearing that. I will be running the precommit in this patch although it seems I am getting the same errors as you are getting (Lots of Unescaped symbol "->" on line #). I will try to see if I can fix it somewhat. I think I found a good solution. I am using Generic abstract classes and the exposing in the API the concretization of those classes. I attach the solution in case you have any comments. I wonder if it makes sense to have a generic interface for those composite classes Another issue I am having, is that I am not sure what I should do with the toString() methods. Thanks again! Ignacio > Give access to members of a composite shape > --- > > Key: LUCENE-7918 > URL: https://issues.apache.org/jira/browse/LUCENE-7918 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7918.patch > > > Hi [~daddywri], > I hope this is my last point in my wish list. In order to serialize objects I > need to access the members of a composite geoshape. This is currently not > possible so I was wondering if it is possible to add to more methods to the > class GeoCompositeMembershipShape: > public int size() > public GeoMembershipShape getShape(int index) > Thanks, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7918) Give access to members of a composite shape
[ https://issues.apache.org/jira/browse/LUCENE-7918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7918: - Attachment: LUCENE-7918.patch Hi [~daddywri], thanks for the tips. I was able to run precommit and actually had a hard time to make it succeed. It seems I had to declare public the abstract class GeoBaseCompositeShape. This is because it holds the ublic methods for a composite. Maybe we should add a new class called GeoComposite with those methods and then have the abstract class protected. Attached new patch that should pass precommit. > Give access to members of a composite shape > --- > > Key: LUCENE-7918 > URL: https://issues.apache.org/jira/browse/LUCENE-7918 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7918.patch > > > Hi [~daddywri], > I hope this is my last point in my wish list. In order to serialize objects I > need to access the members of a composite geoshape. This is currently not > possible so I was wondering if it is possible to add to more methods to the > class GeoCompositeMembershipShape: > public int size() > public GeoMembershipShape getShape(int index) > Thanks, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7918) Give access to members of a composite shape
[ https://issues.apache.org/jira/browse/LUCENE-7918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7918: - Attachment: (was: LUCENE-7918.patch) > Give access to members of a composite shape > --- > > Key: LUCENE-7918 > URL: https://issues.apache.org/jira/browse/LUCENE-7918 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7918.patch > > > Hi [~daddywri], > I hope this is my last point in my wish list. In order to serialize objects I > need to access the members of a composite geoshape. This is currently not > possible so I was wondering if it is possible to add to more methods to the > class GeoCompositeMembershipShape: > public int size() > public GeoMembershipShape getShape(int index) > Thanks, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7936) Extend Geoshape interfaces so objects can be copied/serialized
[ https://issues.apache.org/jira/browse/LUCENE-7936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16138025#comment-16138025 ] Ignacio Vera commented on LUCENE-7936: -- Hi [~daddywri], I agree we should separate the different tasks. O leave this ticket for encoded/decoded of geoShapes and open one more ticket for the TileIterator stuff. I see if I can propose something by the end of the week. One thing is clear is that you already open a can of worms with the GeoPoint stuff. The reason I used x/y/z instead of Lat/Lon is because of the Planet Model as you would need to encode it as well and for generic cases you will need two doubles to encode it. Thinking more in depth, there is something I am doing wrong and it is trying to use GeoPoint as a GeoShape. There is one shape missig which is a GeoPointShape which is actually a GeoShape containing a point. GeoPoint should never extend GeoShape! So my first proposal is: * Add GeoPointShape Interface * Change GeoDegeneratePoint to contain a GeoPoint and not extend it and implement the GeoPointShape interface. Probably rename it to GeoStandardPointShape. * Add a GeoPointshapeFactory What do you think? > Extend Geoshape interfaces so objects can be copied/serialized > -- > > Key: LUCENE-7936 > URL: https://issues.apache.org/jira/browse/LUCENE-7936 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: GeoBinaryCodec.patch, LUCENE-7936.patch, Spatial4j.patch > > > Hi [~david.wri...@bksv.com], > I would like to propose to extends the GeoShape interfaces to be able to > copy/serialized the objects. The current status and propose change is as > following: > GeoPoint: It can be serialized by using x, y, z > GeoCircle: It can be serialized by using getCenter() and getRadius() and > getPlanetModel() > GeoCompositeShape: It can be serialized by accesing shapes using size() and > GetShape(int index) > GeoPath: add methods to the interface getPoints() and getCutoffAngle() > GeoPolygon: This is the most complicated one as we have different types: >1.- GeoCompositePolygon is just a composite >2.- GeoConcavePolygon and GeoConvexPolygon: Create a new interface for > those polygons which exposes the points, holes, internaledges and > concavity/convexity >3.- GeoComplexPolygons: Do nothing, they are too complex to be serialize?? > I am intersested in accesing the discreatization of the polygons into convex > and concave ones for other reasons as well. I think this should be expose as > they end result can be used for other use cases. > Cheers, > I. > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7936) Extend Geoshape interfaces so objects can be copied/serialized
[ https://issues.apache.org/jira/browse/LUCENE-7936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16138247#comment-16138247 ] Ignacio Vera commented on LUCENE-7936: -- Ok I will wait until you are ready, it looking promising. I like what I see in the patch but I would like to have a thought about how we are using GeoPoint. My point is the following: There are basically two type of Objects for building shapes: GeoShape components: Everything that is extending the Vector class, GeoPoint and Planes. These do not need to be serialized. Geoshape objects: Everything that implements PlanetObject and hence extends GeoBasePanetObject. The interface PlanetObject should be implementing the SerializeObject. There should be no Geoshape extending GeoPoint as that is like trying to build a shape by extending a Plane. A GeoShapePoint object should be a GeoShapeObject with one component, being that component a GeoPoint. In addition, your static methods to support serialization/deserialization should live in GeoBasePanetObject. Then you can have them protected in the package. Cheers, I. > Extend Geoshape interfaces so objects can be copied/serialized > -- > > Key: LUCENE-7936 > URL: https://issues.apache.org/jira/browse/LUCENE-7936 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: GeoBinaryCodec.patch, LUCENE-7936.patch, > LUCENE-7936.patch, Spatial4j.patch > > > Hi [~david.wri...@bksv.com], > I would like to propose to extends the GeoShape interfaces to be able to > copy/serialized the objects. The current status and propose change is as > following: > GeoPoint: It can be serialized by using x, y, z > GeoCircle: It can be serialized by using getCenter() and getRadius() and > getPlanetModel() > GeoCompositeShape: It can be serialized by accesing shapes using size() and > GetShape(int index) > GeoPath: add methods to the interface getPoints() and getCutoffAngle() > GeoPolygon: This is the most complicated one as we have different types: >1.- GeoCompositePolygon is just a composite >2.- GeoConcavePolygon and GeoConvexPolygon: Create a new interface for > those polygons which exposes the points, holes, internaledges and > concavity/convexity >3.- GeoComplexPolygons: Do nothing, they are too complex to be serialize?? > I am intersested in accesing the discreatization of the polygons into convex > and concave ones for other reasons as well. I think this should be expose as > they end result can be used for other use cases. > Cheers, > I. > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7853) Request to change visibility of classes in geo3d
[
https://issues.apache.org/jira/browse/LUCENE-7853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16026264#comment-16026264
]
Ignacio Vera commented on LUCENE-7853:
--
Do you see any isuue with the following proposal:
I would like to add the following four methods to the GeoPolygonFactory which
should only be used when we know the type of polygon we are delaing with, e.g.
polygon has been serialized:
public static GeoConcavePolygon makeGeoConcavePolygon(final PlanetModel
planetModel,
final List
pointList) {
return new GeoConcavePolygon(planetModel, pointList);
}
public static GeoConcavePolygon makeGeoConcavePolygon(final PlanetModel
planetModel,
final List
pointList,
final List
holes) {
return new GeoConcavePolygon(planetModel,pointList, holes);
}
public static GeoConvexPolygon makeGeoConvexPolygon(final PlanetModel
planetModel,
final List
pointList) {
return new GeoConvexPolygon(planetModel, pointList);
}
public static GeoConvexPolygon makeGeoConvexPolygon(final PlanetModel
planetModel,
final List
pointList,
final List
holes) {
return new GeoConvexPolygon(planetModel,pointList, holes);
}
> Request to change visibility of classes in geo3d
>
>
> Key: LUCENE-7853
> URL: https://issues.apache.org/jira/browse/LUCENE-7853
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial3d
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>
> I am creating my own spatial context by wrapping the objects in lucene geo3d
> library and implement my own query which mixes the recursive and the
> serialized strategy to add precision to searches.
>
> I had the following issue specially with polygons: The factory for creating
> polygons is slow and when serializing shapes, I already know if I am dealing
> with convex or concave polygons (in my case they are always concave). So when
> de-serializing a polygon I do not want to go through the factory to decide
> the type of polygon to create.
>
> Wouldn't make sense to add the possibility to create a type of polygon
> directly? you cannot create the polygons directly as they are protected in
> the package. My suggestion request would be either to add methods in the
> polygon factory to create a type of polygons with no checking (e.g.
> makeConcavePolygon(…)) or change the visibility of the classes so that they
> can be instantiated directly.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7853) Request to change visibility of classes in geo3d
[ https://issues.apache.org/jira/browse/LUCENE-7853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16026179#comment-16026179 ] Ignacio Vera commented on LUCENE-7853: -- Hi [~daddywri], I agree with your apporach and yes I can submit the patch. On the other hand I am a bit new on this, How do I submit the patch? > Request to change visibility of classes in geo3d > > > Key: LUCENE-7853 > URL: https://issues.apache.org/jira/browse/LUCENE-7853 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > > I am creating my own spatial context by wrapping the objects in lucene geo3d > library and implement my own query which mixes the recursive and the > serialized strategy to add precision to searches. > > I had the following issue specially with polygons: The factory for creating > polygons is slow and when serializing shapes, I already know if I am dealing > with convex or concave polygons (in my case they are always concave). So when > de-serializing a polygon I do not want to go through the factory to decide > the type of polygon to create. > > Wouldn't make sense to add the possibility to create a type of polygon > directly? you cannot create the polygons directly as they are protected in > the package. My suggestion request would be either to add methods in the > polygon factory to create a type of polygons with no checking (e.g. > makeConcavePolygon(…)) or change the visibility of the classes so that they > can be instantiated directly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-7853) Request to change visibility of classes in geo3d
Ignacio Vera created LUCENE-7853: Summary: Request to change visibility of classes in geo3d Key: LUCENE-7853 URL: https://issues.apache.org/jira/browse/LUCENE-7853 Project: Lucene - Core Issue Type: Improvement Components: modules/spatial3d Reporter: Ignacio Vera I am creating my own spatial context by wrapping the objects in lucene geo3d library and implement my own query which mixes the recursive and the serialized strategy to add precision to searches. I had the following issue specially with polygons: The factory for creating polygons is slow and when serializing shapes, I already know if I am dealing with convex or concave polygons (in my case they are always concave). So when de-serializing a polygon I do not want to go through the factory to decide the type of polygon to create. Wouldn't make sense to add the possibility to create a type of polygon directly? you cannot create the polygons directly as they are protected in the package. My suggestion request would be either to add methods in the polygon factory to create a type of polygons with no checking (e.g. makeConcavePolygon(…)) or change the visibility of the classes so that they can be instantiated directly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7853) Request to change visibility of classes in geo3d
[ https://issues.apache.org/jira/browse/LUCENE-7853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7853: - Attachment: LUCENE-7853.patch Attached is that patch. One thing I noticed is that when I call the method makeGeopolygon from the polygon factory I always get back a GeoCompositePolygon even when building a simple four points polygon. Is that behavior expected? > Request to change visibility of classes in geo3d > > > Key: LUCENE-7853 > URL: https://issues.apache.org/jira/browse/LUCENE-7853 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7853.patch > > > I am creating my own spatial context by wrapping the objects in lucene geo3d > library and implement my own query which mixes the recursive and the > serialized strategy to add precision to searches. > > I had the following issue specially with polygons: The factory for creating > polygons is slow and when serializing shapes, I already know if I am dealing > with convex or concave polygons (in my case they are always concave). So when > de-serializing a polygon I do not want to go through the factory to decide > the type of polygon to create. > > Wouldn't make sense to add the possibility to create a type of polygon > directly? you cannot create the polygons directly as they are protected in > the package. My suggestion request would be either to add methods in the > polygon factory to create a type of polygons with no checking (e.g. > makeConcavePolygon(…)) or change the visibility of the classes so that they > can be instantiated directly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7853) Request to change visibility of classes in geo3d
[ https://issues.apache.org/jira/browse/LUCENE-7853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7853: - Attachment: (was: LUCENE-7853.patch) > Request to change visibility of classes in geo3d > > > Key: LUCENE-7853 > URL: https://issues.apache.org/jira/browse/LUCENE-7853 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > > I am creating my own spatial context by wrapping the objects in lucene geo3d > library and implement my own query which mixes the recursive and the > serialized strategy to add precision to searches. > > I had the following issue specially with polygons: The factory for creating > polygons is slow and when serializing shapes, I already know if I am dealing > with convex or concave polygons (in my case they are always concave). So when > de-serializing a polygon I do not want to go through the factory to decide > the type of polygon to create. > > Wouldn't make sense to add the possibility to create a type of polygon > directly? you cannot create the polygons directly as they are protected in > the package. My suggestion request would be either to add methods in the > polygon factory to create a type of polygons with no checking (e.g. > makeConcavePolygon(…)) or change the visibility of the classes so that they > can be instantiated directly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7853) Request to change visibility of classes in geo3d
[ https://issues.apache.org/jira/browse/LUCENE-7853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7853: - Attachment: LUCENE-7853.patch > Request to change visibility of classes in geo3d > > > Key: LUCENE-7853 > URL: https://issues.apache.org/jira/browse/LUCENE-7853 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7853.patch > > > I am creating my own spatial context by wrapping the objects in lucene geo3d > library and implement my own query which mixes the recursive and the > serialized strategy to add precision to searches. > > I had the following issue specially with polygons: The factory for creating > polygons is slow and when serializing shapes, I already know if I am dealing > with convex or concave polygons (in my case they are always concave). So when > de-serializing a polygon I do not want to go through the factory to decide > the type of polygon to create. > > Wouldn't make sense to add the possibility to create a type of polygon > directly? you cannot create the polygons directly as they are protected in > the package. My suggestion request would be either to add methods in the > polygon factory to create a type of polygons with no checking (e.g. > makeConcavePolygon(…)) or change the visibility of the classes so that they > can be instantiated directly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7853) Request to change visibility of classes in geo3d
[ https://issues.apache.org/jira/browse/LUCENE-7853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029353#comment-16029353 ] Ignacio Vera commented on LUCENE-7853: -- New patch attached, this time looks what you expect I hope. Thanks for he answer. In my case I would have to simplify the polygon to its minimal description because of performance. I can do that at indexing time. Cheers, I. > Request to change visibility of classes in geo3d > > > Key: LUCENE-7853 > URL: https://issues.apache.org/jira/browse/LUCENE-7853 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7853.patch > > > I am creating my own spatial context by wrapping the objects in lucene geo3d > library and implement my own query which mixes the recursive and the > serialized strategy to add precision to searches. > > I had the following issue specially with polygons: The factory for creating > polygons is slow and when serializing shapes, I already know if I am dealing > with convex or concave polygons (in my case they are always concave). So when > de-serializing a polygon I do not want to go through the factory to decide > the type of polygon to create. > > Wouldn't make sense to add the possibility to create a type of polygon > directly? you cannot create the polygons directly as they are protected in > the package. My suggestion request would be either to add methods in the > polygon factory to create a type of polygons with no checking (e.g. > makeConcavePolygon(…)) or change the visibility of the classes so that they > can be instantiated directly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7853) Request to change visibility of classes in geo3d
[ https://issues.apache.org/jira/browse/LUCENE-7853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7853: - Attachment: (was: LUCENE-7853.patch) > Request to change visibility of classes in geo3d > > > Key: LUCENE-7853 > URL: https://issues.apache.org/jira/browse/LUCENE-7853 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > > I am creating my own spatial context by wrapping the objects in lucene geo3d > library and implement my own query which mixes the recursive and the > serialized strategy to add precision to searches. > > I had the following issue specially with polygons: The factory for creating > polygons is slow and when serializing shapes, I already know if I am dealing > with convex or concave polygons (in my case they are always concave). So when > de-serializing a polygon I do not want to go through the factory to decide > the type of polygon to create. > > Wouldn't make sense to add the possibility to create a type of polygon > directly? you cannot create the polygons directly as they are protected in > the package. My suggestion request would be either to add methods in the > polygon factory to create a type of polygons with no checking (e.g. > makeConcavePolygon(…)) or change the visibility of the classes so that they > can be instantiated directly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7853) Request to change visibility of classes in geo3d
[ https://issues.apache.org/jira/browse/LUCENE-7853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7853: - Attachment: LUCENE-7853.patch Attached a new patch with updated documentation. I hope this is closer to what is expected. It was a good exercise for me as now I have a better understanding how it works for complex polygons. Thanks, I. > Request to change visibility of classes in geo3d > > > Key: LUCENE-7853 > URL: https://issues.apache.org/jira/browse/LUCENE-7853 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7853.patch > > > I am creating my own spatial context by wrapping the objects in lucene geo3d > library and implement my own query which mixes the recursive and the > serialized strategy to add precision to searches. > > I had the following issue specially with polygons: The factory for creating > polygons is slow and when serializing shapes, I already know if I am dealing > with convex or concave polygons (in my case they are always concave). So when > de-serializing a polygon I do not want to go through the factory to decide > the type of polygon to create. > > Wouldn't make sense to add the possibility to create a type of polygon > directly? you cannot create the polygons directly as they are protected in > the package. My suggestion request would be either to add methods in the > polygon factory to create a type of polygons with no checking (e.g. > makeConcavePolygon(…)) or change the visibility of the classes so that they > can be instantiated directly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7853) Request to change visibility of classes in geo3d
[ https://issues.apache.org/jira/browse/LUCENE-7853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16029535#comment-16029535 ] Ignacio Vera commented on LUCENE-7853: -- [~daddywri]: You are totally right, the order of the points (counter-clockwise or clockwise) does not matter as it always generates the convex polygon. I will try to re-phrase it an add a new patch. Composite polygons are not appreciably slower but my strategy is to serialize the objects to read them at query time for the boundaries of a spatial search (inspired from SerializedDVStrategy). Having to serialize the composite polygon and the polygon inside it and then read it during a query can have a performance penalty when dealing with hundreds or even thousand of them. Another more philosofical doubt I have is that composite polygons can be confused with multipolygons. One thing I have learnt the hard way is that multipolygons cannot be composed of polygons that intersect to each other. I guess this is not the case for Geo3d composite polygons. > Request to change visibility of classes in geo3d > > > Key: LUCENE-7853 > URL: https://issues.apache.org/jira/browse/LUCENE-7853 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7853.patch > > > I am creating my own spatial context by wrapping the objects in lucene geo3d > library and implement my own query which mixes the recursive and the > serialized strategy to add precision to searches. > > I had the following issue specially with polygons: The factory for creating > polygons is slow and when serializing shapes, I already know if I am dealing > with convex or concave polygons (in my case they are always concave). So when > de-serializing a polygon I do not want to go through the factory to decide > the type of polygon to create. > > Wouldn't make sense to add the possibility to create a type of polygon > directly? you cannot create the polygons directly as they are protected in > the package. My suggestion request would be either to add methods in the > polygon factory to create a type of polygons with no checking (e.g. > makeConcavePolygon(…)) or change the visibility of the classes so that they > can be instantiated directly. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-7970) Improve generation of circle plane
Ignacio Vera created LUCENE-7970: Summary: Improve generation of circle plane Key: LUCENE-7970 URL: https://issues.apache.org/jira/browse/LUCENE-7970 Project: Lucene - Core Issue Type: Improvement Components: modules/spatial3d Reporter: Ignacio Vera Hi [~Karl wright], How circles are currently build do not behave very well when the planet model is not an sphere. when you are close to the border in WGS84 you might get false positves or false negatives when checking if a point is WITHIN. I think the reason is how the points to generate the circle plane are generated which assumes a sphere. My proposal is the following: Add a new method to PlanetModel: public GeoPoint pointOnBearing(GeoPoint from, double dist, double bearing); Which uses and algorithm that takes into account that the planet might not be spherical. For example Vincenty's formulae (https://en.wikipedia.org/wiki/Vincenty%27s_formulae). Use this method to generate the points for the circle plane. My experiments shows that this approach removes false negatives in WGS84 meanwhile it works nicely in the Sphere. Does it make sense? -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7906: - Attachment: LUCENE-7906-Generator_update.patch Hi [~daddywri], I have realized there is something no correct in the random shape generator. Currently it is only building shapes in a portion of the planet! (lat and lon between 0 and 1) Attached is the fix to build shapes in the whole planet. I "beasted" the test and there were no surpises and performance seems to improve. > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906-AreaShape.patch, > LUCENE-7906-Generator_update.patch, LUCENE-7906.patch, > LUCENE-7906-test.patch, LUCENE-7906-test.patch, LUCENE-7906-test.patch, > test-degenerate_point.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16165923#comment-16165923 ] Ignacio Vera commented on LUCENE-7906: -- Agree. Thanks! > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906-AreaShape.patch, > LUCENE-7906-Generator_update.patch, LUCENE-7906.patch, > LUCENE-7906-test.patch, LUCENE-7906-test.patch, LUCENE-7906-test.patch, > test-degenerate_point.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7951) New wrapper classes for Geo3d
[ https://issues.apache.org/jira/browse/LUCENE-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16165907#comment-16165907 ] Ignacio Vera commented on LUCENE-7951: -- Hi [~dsmiley], 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 [~daddywri] 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. > New wrapper classes for Geo3d > - > > Key: LUCENE-7951 > URL: https://issues.apache.org/jira/browse/LUCENE-7951 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial-extras >Reporter: Ignacio Vera >Assignee: David Smiley >Priority: Minor > Attachments: LUCENE_7951_build.patch, LUCENE_7951_build.patch, > LUCENE-7951.patch, LUCENE-7951.patch > > > 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! -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7970) Improve generation of circle plane
[ https://issues.apache.org/jira/browse/LUCENE-7970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16167836#comment-16167836 ] Ignacio Vera commented on LUCENE-7970: -- [~karl wright], that is ok. It seems a very hard problem and I only got partial results which are not so happy with. I will give myself a week and see how far I can get. I am very busy as well later so let see if we can improve cirlces in non-spherical planets. > Improve generation of circle plane > --- > > Key: LUCENE-7970 > URL: https://issues.apache.org/jira/browse/LUCENE-7970 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7970.patch, LUCENE-7970-proposed.patch > > > Hi [~Karl wright], > How circles are currently build do not behave very well when the planet model > is not an sphere. when you are close to the border in WGS84 you might get > false positves or false negatives when checking if a point is WITHIN. I think > the reason is how the points to generate the circle plane are generated which > assumes a sphere. > My proposal is the following: > Add a new method to PlanetModel: > public GeoPoint pointOnBearing(GeoPoint from, double dist, double bearing); > Which uses and algorithm that takes into account that the planet might not be > spherical. For example Vincenty's formulae > (https://en.wikipedia.org/wiki/Vincenty%27s_formulae). > Use this method to generate the points for the circle plane. My experiments > shows that this approach removes false negatives in WGS84 meanwhile it works > nicely in the Sphere. > Does it make sense? -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7970) Improve generation of circle plane
[ https://issues.apache.org/jira/browse/LUCENE-7970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7970: - Attachment: LUCENE-7970-proposed.patch Attached is the changes I have done. I changed the way the circle plane points are calculated to consider the planetModel. > Improve generation of circle plane > --- > > Key: LUCENE-7970 > URL: https://issues.apache.org/jira/browse/LUCENE-7970 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera > Attachments: LUCENE-7970.patch, LUCENE-7970-proposed.patch > > > Hi [~Karl wright], > How circles are currently build do not behave very well when the planet model > is not an sphere. when you are close to the border in WGS84 you might get > false positves or false negatives when checking if a point is WITHIN. I think > the reason is how the points to generate the circle plane are generated which > assumes a sphere. > My proposal is the following: > Add a new method to PlanetModel: > public GeoPoint pointOnBearing(GeoPoint from, double dist, double bearing); > Which uses and algorithm that takes into account that the planet might not be > spherical. For example Vincenty's formulae > (https://en.wikipedia.org/wiki/Vincenty%27s_formulae). > Use this method to generate the points for the circle plane. My experiments > shows that this approach removes false negatives in WGS84 meanwhile it works > nicely in the Sphere. > Does it make sense? -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-7970) Improve generation of circle plane
[
https://issues.apache.org/jira/browse/LUCENE-7970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16166119#comment-16166119
]
Ignacio Vera edited comment on LUCENE-7970 at 9/14/17 11:46 AM:
Hi [~daddywri],
I attached a test with my expections. The test perform the following operations:
1) Generates a circle
2) Generate a point
3) calculates the surface distance between the center of the circle and the
point
4) if distance is bigger than radius the it is out-of-set else in-set.
This works for the Sphere but you get errors when doing it in WGS84.
My naive idea is that considering {{circle.center.latitud + radius}} and
{{circle.center.latitud - radius}} as the upper and lower latitud for a circle
is only correct for the SPHERE but it needs to be properly calculated for other
planets, for example using Vincenti formula.
make sense? or there is a falw in my reasoning?
was (Author: ivera):
Hi [~daddywri],
I attached a test with my expections. The test perform the following operations:
1) Generates a circle
2) Generate a point
3) calculates the surface distance between the center of the circle and the
point
4) if distance is bigger than radius the it is out-of-set else in-set.
This works for the Sphere but you get errors when doing it in WGS84.
My naive idea is that considering {{circle.center + radius}} and
{{circle.center - radius}} as the upper and lower latitud for a circle is only
correct for the SPHERE but it needs to be properly calculated for other
planets, for example using Vincenti formula.
make sense? or there is a falw in my reasoning?
> Improve generation of circle plane
> ---
>
> Key: LUCENE-7970
> URL: https://issues.apache.org/jira/browse/LUCENE-7970
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial3d
>Reporter: Ignacio Vera
> Attachments: LUCENE-7970.patch
>
>
> Hi [~Karl wright],
> How circles are currently build do not behave very well when the planet model
> is not an sphere. when you are close to the border in WGS84 you might get
> false positves or false negatives when checking if a point is WITHIN. I think
> the reason is how the points to generate the circle plane are generated which
> assumes a sphere.
> My proposal is the following:
> Add a new method to PlanetModel:
> public GeoPoint pointOnBearing(GeoPoint from, double dist, double bearing);
> Which uses and algorithm that takes into account that the planet might not be
> spherical. For example Vincenty's formulae
> (https://en.wikipedia.org/wiki/Vincenty%27s_formulae).
> Use this method to generate the points for the circle plane. My experiments
> shows that this approach removes false negatives in WGS84 meanwhile it works
> nicely in the Sphere.
> Does it make sense?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-7970) Improve generation of circle plane
[
https://issues.apache.org/jira/browse/LUCENE-7970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16166119#comment-16166119
]
Ignacio Vera edited comment on LUCENE-7970 at 9/14/17 11:45 AM:
Hi [~daddywri],
I attached a test with my expections. The test perform the following operations:
1) Generates a circle
2) Generate a point
3) calculates the surface distance between the center of the circle and the
point
4) if distance is bigger than radius the it is out-of-set else in-set.
This works for the Sphere but you get errors when doing it in WGS84.
My naive idea is that considering {{circle.center + radius}} and
{{circle.center - radius}} as the upper and lower latitud for a circle is only
correct for the SPHERE but it needs to be properly calculated for other
planets, for example using Vincenti formula.
make sense? or there is a falw in my reasoning?
was (Author: ivera):
Hi [~daddywri],
I attached a test with my expections. The test perform the following operations:
1) Generates a circle
2) Generate a point
3) calculates the surface distance between the center of the circle and the
point
4) if distance is bigger than radius the it is out-of-set else in-set.
This works for the Sphere but you get errors when doing it in WGS84.
My naive idea is that considering {{circle.center + radius}} and
{{circle.center - radius}} as the upper and lower point for a circle is only
correct for the SPHERE but it needs to be properly calculated for other
planets, for example using Vincenti formula.
make sense? or there is a falw in my reasoning?
> Improve generation of circle plane
> ---
>
> Key: LUCENE-7970
> URL: https://issues.apache.org/jira/browse/LUCENE-7970
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial3d
>Reporter: Ignacio Vera
> Attachments: LUCENE-7970.patch
>
>
> Hi [~Karl wright],
> How circles are currently build do not behave very well when the planet model
> is not an sphere. when you are close to the border in WGS84 you might get
> false positves or false negatives when checking if a point is WITHIN. I think
> the reason is how the points to generate the circle plane are generated which
> assumes a sphere.
> My proposal is the following:
> Add a new method to PlanetModel:
> public GeoPoint pointOnBearing(GeoPoint from, double dist, double bearing);
> Which uses and algorithm that takes into account that the planet might not be
> spherical. For example Vincenty's formulae
> (https://en.wikipedia.org/wiki/Vincenty%27s_formulae).
> Use this method to generate the points for the circle plane. My experiments
> shows that this approach removes false negatives in WGS84 meanwhile it works
> nicely in the Sphere.
> Does it make sense?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7970) Improve generation of circle plane
[
https://issues.apache.org/jira/browse/LUCENE-7970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ignacio Vera updated LUCENE-7970:
-
Attachment: LUCENE-7970.patch
Hi [~daddywri],
I attached a test with my expections. The test perform the following operations:
1) Generates a circle
2) Generate a point
3) calculates the surface distance between the center of the circle and the
point
4) if distance is bigger than radius the it is out-of-set else in-set.
This works for the Sphere but you get errors when doing it in WGS84.
My naive idea is that considering {{circle.center + radius}} and
{{circle.center - radius}} as the upper and lower point for a circle is only
correct for the SPHERE but it needs to be properly calculated for other
planets, for example using Vincenti formula.
make sense? or there is a falw in my reasoning?
> Improve generation of circle plane
> ---
>
> Key: LUCENE-7970
> URL: https://issues.apache.org/jira/browse/LUCENE-7970
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial3d
>Reporter: Ignacio Vera
> Attachments: LUCENE-7970.patch
>
>
> Hi [~Karl wright],
> How circles are currently build do not behave very well when the planet model
> is not an sphere. when you are close to the border in WGS84 you might get
> false positves or false negatives when checking if a point is WITHIN. I think
> the reason is how the points to generate the circle plane are generated which
> assumes a sphere.
> My proposal is the following:
> Add a new method to PlanetModel:
> public GeoPoint pointOnBearing(GeoPoint from, double dist, double bearing);
> Which uses and algorithm that takes into account that the planet might not be
> spherical. For example Vincenty's formulae
> (https://en.wikipedia.org/wiki/Vincenty%27s_formulae).
> Use this method to generate the points for the circle plane. My experiments
> shows that this approach removes false negatives in WGS84 meanwhile it works
> nicely in the Sphere.
> Does it make sense?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7951) New wrapper classes for Geo3d
[ https://issues.apache.org/jira/browse/LUCENE-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173086#comment-16173086 ] Ignacio Vera commented on LUCENE-7951: -- 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. > New wrapper classes for Geo3d > - > > Key: LUCENE-7951 > URL: https://issues.apache.org/jira/browse/LUCENE-7951 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial-extras >Reporter: Ignacio Vera >Assignee: David Smiley >Priority: Minor > Attachments: LUCENE_7951_build.patch, LUCENE_7951_build.patch, > LUCENE-7951.patch, LUCENE-7951.patch > > > 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! -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7951) New wrapper classes for Geo3d
[ https://issues.apache.org/jira/browse/LUCENE-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173092#comment-16173092 ] Ignacio Vera commented on LUCENE-7951: -- Actually there is already a test: In Geo3dShapeWGS84ModelRectRelationTest.pointBearingTest() > New wrapper classes for Geo3d > - > > Key: LUCENE-7951 > URL: https://issues.apache.org/jira/browse/LUCENE-7951 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial-extras >Reporter: Ignacio Vera >Assignee: David Smiley >Priority: Minor > Attachments: LUCENE_7951_build.patch, LUCENE_7951_build.patch, > LUCENE-7951.patch, LUCENE-7951.patch > > > 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! -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7951) New wrapper classes for Geo3d
[ https://issues.apache.org/jira/browse/LUCENE-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16172931#comment-16172931 ] Ignacio Vera commented on LUCENE-7951: -- I have merge the Geo3dAreaRptTest into Geo3dRptTest. T 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 circle 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 WGS84 test will fail. Note that it works for the Sphere. > New wrapper classes for Geo3d > - > > Key: LUCENE-7951 > URL: https://issues.apache.org/jira/browse/LUCENE-7951 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial-extras >Reporter: Ignacio Vera >Assignee: David Smiley >Priority: Minor > Attachments: LUCENE_7951_build.patch, LUCENE_7951_build.patch, > LUCENE-7951.patch, LUCENE-7951.patch > > > 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! -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-7970) Improve generation of circle plane
[ https://issues.apache.org/jira/browse/LUCENE-7970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16174442#comment-16174442 ] Ignacio Vera edited comment on LUCENE-7970 at 9/21/17 1:02 PM: --- Hi [~karl wright], Not sure if we have something to do here as I think current implementation might be the best one to approximate the circle using one plane intersecting the spheroid. I don't think I can assure that any other implementation would be more precise. Anyway, I was thinking what is needed to support circles in a spheroid and of course it needs a totally different approach and eventually in some cases you need to use brute force. I want to share what I think it would be a viable solution if Geo3d ever needs to add precision to circles in spheriods like WGS84: The new shape should have two planes: innerEllipse: plane cutting the spheriod producing the maximum ellipse within the circle. Anything within this plane is within the circle. outerEllipse: plane cutting the spheriod producing the minimum ellipse contaning the circle. Anything not within this plane is not within the circle. There is only one gray area between the two planes (within outerEllipse, not within innerEllipse) where brute force will be needed. I attach my implementation for such a shape. It seems to work for WGS84, except for verly large and very small angles. I was unable to find the mathematical model to generate those planes (is that possible to solve mathematically?). Thanks! was (Author: ivera): Hi [~karl wright], Not sure if we have something to do here as I think current implementation might be the best one to approximate the circle using one plane intersecting the spheroid. I don't think I can assure that any other implementation would be more precise. Anyway, I was thinking what is needed to support circles in a spheroid and of course it needs a totally different approach and eventually in some cases you need to use brute force. I want to share what I think it would be a viable solution if Geo3d ever needs to add precision to circles in spheriods like WGS84: The new shape should have two planes: innerElipse: plane cutting the spheriod producing the maximum ellipse within the circle. Anything within this plane is within the circle. outerElipse: plane cutting the spheriod producing the maximum ellipse contaning the circle. Anything not within this plane is not within the circle. There is only one gray area between the two planes (within outerEllipse, not within innerEllipse) where brute force will be needed. I attach my implementation for such a shape. It seems to work for WGS84, except for verly large and very small angles. I was unable to find the mathematical model to generate those planes (is that possible to solve mathematically?). Thanks! > Improve generation of circle plane > --- > > Key: LUCENE-7970 > URL: https://issues.apache.org/jira/browse/LUCENE-7970 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE_7970.patch, LUCENE-7970.patch, > LUCENE-7970-proposed.patch > > > Hi [~Karl wright], > How circles are currently build do not behave very well when the planet model > is not an sphere. when you are close to the border in WGS84 you might get > false positves or false negatives when checking if a point is WITHIN. I think > the reason is how the points to generate the circle plane are generated which > assumes a sphere. > My proposal is the following: > Add a new method to PlanetModel: > public GeoPoint pointOnBearing(GeoPoint from, double dist, double bearing); > Which uses and algorithm that takes into account that the planet might not be > spherical. For example Vincenty's formulae > (https://en.wikipedia.org/wiki/Vincenty%27s_formulae). > Use this method to generate the points for the circle plane. My experiments > shows that this approach removes false negatives in WGS84 meanwhile it works > nicely in the Sphere. > Does it make sense? -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7970) Improve generation of circle plane
[ https://issues.apache.org/jira/browse/LUCENE-7970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16174740#comment-16174740 ] Ignacio Vera commented on LUCENE-7970: -- (1) I was having problems with the maths so before going foward in trying to solve/formalize it I wanted to see if the approach I was taken would be considered. First thing we need to do then, it is to formalize the way to compute the planes. I know there is something missing; there is a maximum cutoff angle which depends on the spheriod(ab,c) where the outerEllipse does not make sense and should be the whole planet. The same with the innerEllipse. (2) Ok, I think we can use only the outer plane as it is bigger than the shape. If null then bounds should be the whole world.Using the inner plane can give bounds smaller than the shape and we might want to avoid that. (3) upps, my mistake ... shapes should not be public. I will try then to find the way to compute the planes that provides the desired inner and outer plane in a formal way. Thanks! > Improve generation of circle plane > --- > > Key: LUCENE-7970 > URL: https://issues.apache.org/jira/browse/LUCENE-7970 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE_7970.patch, LUCENE-7970.patch, > LUCENE-7970-proposed.patch > > > Hi [~Karl wright], > How circles are currently build do not behave very well when the planet model > is not an sphere. when you are close to the border in WGS84 you might get > false positves or false negatives when checking if a point is WITHIN. I think > the reason is how the points to generate the circle plane are generated which > assumes a sphere. > My proposal is the following: > Add a new method to PlanetModel: > public GeoPoint pointOnBearing(GeoPoint from, double dist, double bearing); > Which uses and algorithm that takes into account that the planet might not be > spherical. For example Vincenty's formulae > (https://en.wikipedia.org/wiki/Vincenty%27s_formulae). > Use this method to generate the points for the circle plane. My experiments > shows that this approach removes false negatives in WGS84 meanwhile it works > nicely in the Sphere. > Does it make sense? -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7970) Improve generation of circle plane
[ https://issues.apache.org/jira/browse/LUCENE-7970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16175991#comment-16175991 ] Ignacio Vera commented on LUCENE-7970: -- Thanks [~karl wright], For the documentation I took the method from, it seems that it might have problems for antipodal points. Other than that, I will devise a test to shows the limits in distance and maybe values for planet model. One more observation: I think there would be a dependency on whether the center of the circle is in the north or south hemisphere. I am busy this morning but I hope to be able to spend some time on this later today. > Improve generation of circle plane > --- > > Key: LUCENE-7970 > URL: https://issues.apache.org/jira/browse/LUCENE-7970 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE_7970.patch, LUCENE-7970.patch, > LUCENE-7970-proposed.patch > > > Hi [~Karl wright], > How circles are currently build do not behave very well when the planet model > is not an sphere. when you are close to the border in WGS84 you might get > false positves or false negatives when checking if a point is WITHIN. I think > the reason is how the points to generate the circle plane are generated which > assumes a sphere. > My proposal is the following: > Add a new method to PlanetModel: > public GeoPoint pointOnBearing(GeoPoint from, double dist, double bearing); > Which uses and algorithm that takes into account that the planet might not be > spherical. For example Vincenty's formulae > (https://en.wikipedia.org/wiki/Vincenty%27s_formulae). > Use this method to generate the points for the circle plane. My experiments > shows that this approach removes false negatives in WGS84 meanwhile it works > nicely in the Sphere. > Does it make sense? -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7970) Add a Geo3d shape that models an exact circle, even when the planet model is not a sphere
[ https://issues.apache.org/jira/browse/LUCENE-7970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7970: - Attachment: LUCENE-7970_testBearingPoint.patch Hi [~daddywri] Attached is a random test to check that cardinality points are correctly computed. The check is performed by comparing the result from the methods surfaceDistance and the original distance. There is test specific for WGS84 and one with random planet models. When planet model is generated randomly is limitied to have ab and c between 0.9 and 1.5. It seems things do start behaving less accurate the less spherical is the planet as expected. Ichanged the conditions for the iterations in surfacePointOnBearing to match the ones in surfaceDistance. > Add a Geo3d shape that models an exact circle, even when the planet model is > not a sphere > - > > Key: LUCENE-7970 > URL: https://issues.apache.org/jira/browse/LUCENE-7970 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE_7970.patch, LUCENE-7970.patch, > LUCENE-7970-proposed.patch, LUCENE-7970_testBearingPoint.patch > > > Hi [~Karl wright], > How circles are currently build do not behave very well when the planet model > is not an sphere. when you are close to the border in WGS84 you might get > false positves or false negatives when checking if a point is WITHIN. I think > the reason is how the points to generate the circle plane are generated which > assumes a sphere. > My proposal is the following: > Add a new method to PlanetModel: > public GeoPoint pointOnBearing(GeoPoint from, double dist, double bearing); > Which uses and algorithm that takes into account that the planet might not be > spherical. For example Vincenty's formulae > (https://en.wikipedia.org/wiki/Vincenty%27s_formulae). > Use this method to generate the points for the circle plane. My experiments > shows that this approach removes false negatives in WGS84 meanwhile it works > nicely in the Sphere. > Does it make sense? -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7951) New wrapper classes for Geo3d
[ https://issues.apache.org/jira/browse/LUCENE-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173178#comment-16173178 ] Ignacio Vera commented on LUCENE-7951: -- 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? > New wrapper classes for Geo3d > - > > Key: LUCENE-7951 > URL: https://issues.apache.org/jira/browse/LUCENE-7951 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial-extras >Reporter: Ignacio Vera >Assignee: David Smiley >Priority: Minor > Attachments: LUCENE_7951_build.patch, LUCENE_7951_build.patch, > LUCENE-7951.patch, LUCENE-7951.patch > > > 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! -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-7951) New wrapper classes for Geo3d
[ https://issues.apache.org/jira/browse/LUCENE-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16172931#comment-16172931 ] Ignacio Vera edited comment on LUCENE-7951 at 9/20/17 10:40 AM: 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. was (Author: ivera): I have merge the Geo3dAreaRptTest into Geo3dRptTest. T 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 circle 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 WGS84 test will fail. Note that it works for the Sphere. > New wrapper classes for Geo3d > - > > Key: LUCENE-7951 > URL: https://issues.apache.org/jira/browse/LUCENE-7951 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial-extras >Reporter: Ignacio Vera >Assignee: David Smiley >Priority: Minor > Attachments: LUCENE_7951_build.patch, LUCENE_7951_build.patch, > LUCENE-7951.patch, LUCENE-7951.patch > > > 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! -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7951) New wrapper classes for Geo3d
[ https://issues.apache.org/jira/browse/LUCENE-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173045#comment-16173045 ] Ignacio Vera commented on LUCENE-7951: -- There 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. > New wrapper classes for Geo3d > - > > Key: LUCENE-7951 > URL: https://issues.apache.org/jira/browse/LUCENE-7951 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial-extras >Reporter: Ignacio Vera >Assignee: David Smiley >Priority: Minor > Attachments: LUCENE_7951_build.patch, LUCENE_7951_build.patch, > LUCENE-7951.patch, LUCENE-7951.patch > > > 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! -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-7951) New wrapper classes for Geo3d
[ https://issues.apache.org/jira/browse/LUCENE-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173045#comment-16173045 ] Ignacio Vera edited comment on LUCENE-7951 at 9/20/17 11:35 AM: 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. was (Author: ivera): There 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. > New wrapper classes for Geo3d > - > > Key: LUCENE-7951 > URL: https://issues.apache.org/jira/browse/LUCENE-7951 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial-extras >Reporter: Ignacio Vera >Assignee: David Smiley >Priority: Minor > Attachments: LUCENE_7951_build.patch, LUCENE_7951_build.patch, > LUCENE-7951.patch, LUCENE-7951.patch > > > 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! -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7970) Improve generation of circle plane
[ https://issues.apache.org/jira/browse/LUCENE-7970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7970: - Attachment: LUCENE_7970.patch Hi [~karl wright], Not sure if we have something to do here as I think current implementation might be the best one to approximate the circle using one plane intersecting the spheroid. I don't think I can assure that any other implementation would be more precise. Anyway, I was thinking what is needed to support circles in a spheroid and of course it needs a totally different approach and eventually in some cases you need to use brute force. I want to share what I think it would be a viable solution if Geo3d ever needs to add precision to circles in spheriods like WGS84: The new shape should have two planes: innerElipse: plane cutting the spheriod producing the maximum ellipse within the circle. Anything within this plane is within the circle. outerElipse: plane cutting the spheriod producing the maximum ellipse contaning the circle. Anything not within this plane is not within the circle. There is only one gray area between the two planes (within outerEllipse, not within innerEllipse) where brute force will be needed. I attach my implementation for such a shape. It seems to work for WGS84, except for verly large and very small angles. I was unable to find the mathematical model to generate those planes (is that possible to solve mathematically?). Thanks! > Improve generation of circle plane > --- > > Key: LUCENE-7970 > URL: https://issues.apache.org/jira/browse/LUCENE-7970 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE_7970.patch, LUCENE-7970.patch, > LUCENE-7970-proposed.patch > > > Hi [~Karl wright], > How circles are currently build do not behave very well when the planet model > is not an sphere. when you are close to the border in WGS84 you might get > false positves or false negatives when checking if a point is WITHIN. I think > the reason is how the points to generate the circle plane are generated which > assumes a sphere. > My proposal is the following: > Add a new method to PlanetModel: > public GeoPoint pointOnBearing(GeoPoint from, double dist, double bearing); > Which uses and algorithm that takes into account that the planet might not be > spherical. For example Vincenty's formulae > (https://en.wikipedia.org/wiki/Vincenty%27s_formulae). > Use this method to generate the points for the circle plane. My experiments > shows that this approach removes false negatives in WGS84 meanwhile it works > nicely in the Sphere. > Does it make sense? -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7955) New GeoShape: GeoDegeneratePath
[ https://issues.apache.org/jira/browse/LUCENE-7955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16154850#comment-16154850 ] Ignacio Vera commented on LUCENE-7955: -- Thanks for the update [~daddywri]. There is no rush about this request. I just think it is a missing shape to support WKT line strings. > New GeoShape: GeoDegeneratePath > --- > > Key: LUCENE-7955 > URL: https://issues.apache.org/jira/browse/LUCENE-7955 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Ignacio Vera >Assignee: Karl Wright >Priority: Minor > > Hi [~daddywri], > I propose to add new type of shape for GeoPaths that have a cutoffangle < > MINIMUM_RESOLUTION. We can define it as a shape consisting of points exactly > on the path. > It would be a much lighter version of GeoStandardPath and created only when > the cutoff angle is between 0 and MINIMUM_RESOLUTION. > Thanks! > Ignacio > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7951) New wrapper classes for Geo3d
[ https://issues.apache.org/jira/browse/LUCENE-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158689#comment-16158689 ] Ignacio Vera commented on LUCENE-7951: -- 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. > New wrapper classes for Geo3d > - > > Key: LUCENE-7951 > URL: https://issues.apache.org/jira/browse/LUCENE-7951 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial-extras >Reporter: Ignacio Vera >Assignee: David Smiley >Priority: Minor > Attachments: LUCENE_7951_build.patch, LUCENE_7951_build.patch, > LUCENE-7951.patch, LUCENE-7951.patch > > > 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! -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7965) Geo3d test failure
[
https://issues.apache.org/jira/browse/LUCENE-7965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16159823#comment-16159823
]
Ignacio Vera commented on LUCENE-7965:
--
I see that was a real bug and a good catch. Around the poles the shape is
always a degenerate point.
Thanks!
> Geo3d test failure
> --
>
> Key: LUCENE-7965
> URL: https://issues.apache.org/jira/browse/LUCENE-7965
> Project: Lucene - Core
> Issue Type: Bug
> Components: modules/spatial3d
>Reporter: Karl Wright
>Assignee: Karl Wright
> Fix For: 6.7, master (8.0), 7.1
>
>
> Build: https://jenkins.thetaphi.de/job/Lucene-Solr-master-Linux/20435/
> Java: 64bit/jdk-9-ea+181 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC
> --illegal-access=deny
> 1 tests failed.
> FAILED: org.apache.lucene.spatial3d.TestGeo3DPoint.testGeo3DRelations
> Error Message:
> invalid bounds for shape=GeoWideDegenerateHorizontalLine:
> {planetmodel=PlanetModel.WGS84, latitude=1.5707963267948966(90.0),
> leftlon=-3.016975395495807(-172.8599570567221),
> rightLon=1.5813494162526271(90.60464748675197)}
> Stack Trace:
> java.lang.AssertionError: invalid bounds for
> shape=GeoWideDegenerateHorizontalLine: {planetmodel=PlanetModel.WGS84,
> latitude=1.5707963267948966(90.0),
> leftlon=-3.016975395495807(-172.8599570567221),
> rightLon=1.5813494162526271(90.60464748675197)}
> at
> __randomizedtesting.SeedInfo.seed([941CF510B97966F3:246388843634C86F]:0)
> at org.junit.Assert.fail(Assert.java:93)
> at
> org.apache.lucene.spatial3d.TestGeo3DPoint.testGeo3DRelations(TestGeo3DPoint.java:259)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1737)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:934)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$9.evaluate(RandomizedRunner.java:970)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$10.evaluate(RandomizedRunner.java:984)
> at
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:49)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> at
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
> at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:64)
> at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:47)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:368)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:817)
> at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:468)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:943)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:829)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:879)
> at
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:890)
> at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:41)
> at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> at
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
> at
>
[jira] [Updated] (LUCENE-7936) Extend Geoshape interfaces so objects can be copied/serialized
[ https://issues.apache.org/jira/browse/LUCENE-7936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7936: - Attachment: LUCENE-7936-code.patch > Extend Geoshape interfaces so objects can be copied/serialized > -- > > Key: LUCENE-7936 > URL: https://issues.apache.org/jira/browse/LUCENE-7936 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Fix For: 6.7, master (8.0), 7.1 > > Attachments: factory.patch, GeoBinaryCodec.patch, > LUCENE-7936-code.patch, LUCENE-7936-GeoComplexPolygon.patch, > LUCENE-7936.patch, LUCENE-7936.patch, LUCENE-7936.patch, > LUCENE-7936-test.patch, Spatial4j.patch > > > Hi [~david.wri...@bksv.com], > I would like to propose to extends the GeoShape interfaces to be able to > copy/serialized the objects. The current status and propose change is as > following: > GeoPoint: It can be serialized by using x, y, z > GeoCircle: It can be serialized by using getCenter() and getRadius() and > getPlanetModel() > GeoCompositeShape: It can be serialized by accesing shapes using size() and > GetShape(int index) > GeoPath: add methods to the interface getPoints() and getCutoffAngle() > GeoPolygon: This is the most complicated one as we have different types: >1.- GeoCompositePolygon is just a composite >2.- GeoConcavePolygon and GeoConvexPolygon: Create a new interface for > those polygons which exposes the points, holes, internaledges and > concavity/convexity >3.- GeoComplexPolygons: Do nothing, they are too complex to be serialize?? > I am intersested in accesing the discreatization of the polygons into convex > and concave ones for other reasons as well. I think this should be expose as > they end result can be used for other use cases. > Cheers, > I. > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7936) Extend Geoshape interfaces so objects can be copied/serialized
[ https://issues.apache.org/jira/browse/LUCENE-7936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7936: - Attachment: (was: LUCENE-7936-code.patch) > Extend Geoshape interfaces so objects can be copied/serialized > -- > > Key: LUCENE-7936 > URL: https://issues.apache.org/jira/browse/LUCENE-7936 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Fix For: 6.7, master (8.0), 7.1 > > Attachments: factory.patch, GeoBinaryCodec.patch, > LUCENE-7936-code.patch, LUCENE-7936-GeoComplexPolygon.patch, > LUCENE-7936.patch, LUCENE-7936.patch, LUCENE-7936.patch, > LUCENE-7936-test.patch, Spatial4j.patch > > > Hi [~david.wri...@bksv.com], > I would like to propose to extends the GeoShape interfaces to be able to > copy/serialized the objects. The current status and propose change is as > following: > GeoPoint: It can be serialized by using x, y, z > GeoCircle: It can be serialized by using getCenter() and getRadius() and > getPlanetModel() > GeoCompositeShape: It can be serialized by accesing shapes using size() and > GetShape(int index) > GeoPath: add methods to the interface getPoints() and getCutoffAngle() > GeoPolygon: This is the most complicated one as we have different types: >1.- GeoCompositePolygon is just a composite >2.- GeoConcavePolygon and GeoConvexPolygon: Create a new interface for > those polygons which exposes the points, holes, internaledges and > concavity/convexity >3.- GeoComplexPolygons: Do nothing, they are too complex to be serialize?? > I am intersested in accesing the discreatization of the polygons into convex > and concave ones for other reasons as well. I think this should be expose as > they end result can be used for other use cases. > Cheers, > I. > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7906: - Attachment: LUCENE-7906-test.patch sorry about this [~kwri...@metacarta.com], I have the feeling I generated the patch and the project was not clean. Attached a new version, I hope this work. Thanks! > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906-AreaShape.patch, LUCENE-7906.patch, > LUCENE-7906-test.patch, LUCENE-7906-test.patch, test-degenerate_point.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7906: - Attachment: LUCENE-7906-test.patch I have recreated the patch from scratch and it is generated using plain git command. This should work. sorry again! > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906-AreaShape.patch, LUCENE-7906.patch, > LUCENE-7906-test.patch, LUCENE-7906-test.patch, LUCENE-7906-test.patch, > test-degenerate_point.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16161222#comment-16161222 ] Ignacio Vera commented on LUCENE-7906: -- I think something did not go as expected: lucene/spatial3d/src/test/org/apache/lucene/spatial3d/geom/RandomBinaryCodecTest.java diff | blob | history lucene/spatial3d/src/test/org/apache/lucene/spatial3d/geom/RandomGeoShapeGenerator.java [deleted file] blob | history lucene/spatial3d/src/test/org/apache/lucene/spatial3d/geom/RandomGeoShapeRelationshipTest.java diff | blob | history The RandomGeoShapeGenerator.java class was deleted but not replaced with RandomGeo3dShapeGenerator.java > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906-AreaShape.patch, LUCENE-7906.patch, > LUCENE-7906-test.patch, LUCENE-7906-test.patch, LUCENE-7906-test.patch, > test-degenerate_point.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7906) Spatial relationship between Geoshapes
[ https://issues.apache.org/jira/browse/LUCENE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7906: - Attachment: LUCENE-7906-test.patch Hi [~kwri...@metacarta.com], I attach a new version of the random shape generator class. I think it belongs to this ticket. Main changes are: * Rename the class to "Geo3d" * Added two new shapes, GeoPointShape and degenerate path. * Improve test by providing feedback in case they fail I "beasted" the test and run precommit successfully. Thanks! > Spatial relationship between Geoshapes > -- > > Key: LUCENE-7906 > URL: https://issues.apache.org/jira/browse/LUCENE-7906 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial3d >Reporter: Ignacio Vera >Assignee: Karl Wright > Attachments: LUCENE-7906-AreaShape.patch, LUCENE-7906.patch, > LUCENE-7906-test.patch, test-degenerate_point.patch > > > Hi, > Working with geosahpes and trying to resolve spatial relationships between > them I came accross a big limitation when trying to solve the relationship > between two geopolygons. This object does not expose the internal structure. > In particular at some point, it is necessary to check if one polygon > intersects the edges of the other polygon which currently is not possible as > edges are not exposed. > To be able to perform such operation it can be several options. The ones I > can think of are: > 1) Expose the edges of the polygon ( and probably the notable points for the > edges) adding getters in the GeoPolygon interface. Easy to implement and > leave users the responsability of coding the spatial relationship. > 2) Extends GeoPolygon interface to extends geoarea and leave the object make > the spatial relationship. > 3) Extends GeoShape interface so all shapes can infer the spatial > relationship with other GeoShapes. > I might be bias as my interest is in 2d Shapes in the unit sphere and there > might be some cases which what I propose cannot be implemented or are againts > the aim of the library. > What do you think? > Cheers, > Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7955) New GeoShape: GeoDegeneratePath
[ https://issues.apache.org/jira/browse/LUCENE-7955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16160254#comment-16160254 ] Ignacio Vera commented on LUCENE-7955: -- Hi [~daddywri], Thanks for this development. I have a question, are the endpoints for this type of shape really needed? I understand that in standard paths end points get buffer to circles but in the case the end points are actually a point of the segment and I think they don't need to be treated specially. What do you think? > New GeoShape: GeoDegeneratePath > --- > > Key: LUCENE-7955 > URL: https://issues.apache.org/jira/browse/LUCENE-7955 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Ignacio Vera >Assignee: Karl Wright >Priority: Minor > Fix For: 6.7, master (8.0), 7.1 > > > Hi [~daddywri], > I propose to add new type of shape for GeoPaths that have a cutoffangle < > MINIMUM_RESOLUTION. We can define it as a shape consisting of points exactly > on the path. > It would be a much lighter version of GeoStandardPath and created only when > the cutoff angle is between 0 and MINIMUM_RESOLUTION. > Thanks! > Ignacio > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7955) New GeoShape: GeoDegeneratePath
[
https://issues.apache.org/jira/browse/LUCENE-7955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ignacio Vera updated LUCENE-7955:
-
Attachment: LUCENE-7955-test.patch
Attached the side effect of end points as point. When a shape contains a
degenerate path it will always return OVERLAPS because of the following method:
/** Determine if this endpoint intersects a GeoShape.
*@param geoShape is the GeoShape.
*@return true if there is shape intersect this endpoint.
*/
public boolean intersects(final GeoShape geoShape) {
return geoShape.isWithin(point);
}
> New GeoShape: GeoDegeneratePath
> ---
>
> Key: LUCENE-7955
> URL: https://issues.apache.org/jira/browse/LUCENE-7955
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Ignacio Vera
>Assignee: Karl Wright
>Priority: Minor
> Fix For: 6.7, master (8.0), 7.1
>
> Attachments: LUCENE-7955-test.patch
>
>
> Hi [~daddywri],
> I propose to add new type of shape for GeoPaths that have a cutoffangle <
> MINIMUM_RESOLUTION. We can define it as a shape consisting of points exactly
> on the path.
> It would be a much lighter version of GeoStandardPath and created only when
> the cutoff angle is between 0 and MINIMUM_RESOLUTION.
> Thanks!
> Ignacio
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7951) New wrapper classes for Geo3d
[ https://issues.apache.org/jira/browse/LUCENE-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7951: - Attachment: LUCENE-7951.patch 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, [~daddywri], would it make sense to add a new GeoShape for degenerated paths (cutoff angle < MINIMUM_RESOLUTION)? > New wrapper classes for Geo3d > - > > Key: LUCENE-7951 > URL: https://issues.apache.org/jira/browse/LUCENE-7951 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial-extras >Reporter: Ignacio Vera >Priority: Minor > Attachments: LUCENE-7951.patch, LUCENE-7951.patch > > > 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! -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7955) New GeoShape: GeoDegeneratePath
[ https://issues.apache.org/jira/browse/LUCENE-7955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7955: - Summary: New GeoShape: GeoDegeneratePath (was: New GeoShape: GeoDegeneratedPath) > New GeoShape: GeoDegeneratePath > --- > > Key: LUCENE-7955 > URL: https://issues.apache.org/jira/browse/LUCENE-7955 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Ignacio Vera >Priority: Minor > > Hi [~daddywri], > I propose to add new type of shape for GeoPaths that have a cutoffangle < > MINIMUM_RESOLUTION. We can define it as a shape consisting of points exactly > on the path. > It would be a much lighter version of GeoStandardPath and created only when > the cutoff angle is between 0 and MINIMUM_RESOLUTION. > Thanks! > Ignacio > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-7955) New GeoShape: GeoDegeneratedPath
Ignacio Vera created LUCENE-7955: Summary: New GeoShape: GeoDegeneratedPath Key: LUCENE-7955 URL: https://issues.apache.org/jira/browse/LUCENE-7955 Project: Lucene - Core Issue Type: Improvement Reporter: Ignacio Vera Priority: Minor Hi [~daddywri], I propose to add new type of shape for GeoPaths that have a cutoffangle < MINIMUM_RESOLUTION. We can define it as a shape consisting of points exactly on the path. It would be a much lighter version of GeoStandardPath and created only when the cutoff angle is between 0 and MINIMUM_RESOLUTION. Thanks! Ignacio -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7951) New wrapper classes for Geo3d
[ https://issues.apache.org/jira/browse/LUCENE-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16156980#comment-16156980 ] Ignacio Vera commented on LUCENE-7951: -- The following error is thrown by precommit if you try to use the random generator in spatial-3d: [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. > New wrapper classes for Geo3d > - > > Key: LUCENE-7951 > URL: https://issues.apache.org/jira/browse/LUCENE-7951 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial-extras >Reporter: Ignacio Vera >Assignee: David Smiley >Priority: Minor > Attachments: LUCENE-7951.patch, LUCENE-7951.patch > > > 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! -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-7951) New wrapper classes for Geo3d
[ https://issues.apache.org/jira/browse/LUCENE-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16156980#comment-16156980 ] Ignacio Vera edited comment on LUCENE-7951 at 9/7/17 1:59 PM: -- 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. was (Author: ivera): The following error is thrown by precommit if you try to use the random generator in spatial-3d: [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. > New wrapper classes for Geo3d > - > > Key: LUCENE-7951 > URL: https://issues.apache.org/jira/browse/LUCENE-7951 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial-extras >Reporter: Ignacio Vera >Assignee: David Smiley >Priority: Minor > Attachments: LUCENE-7951.patch, LUCENE-7951.patch > > > 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! -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7951) New wrapper classes for Geo3d
[ https://issues.apache.org/jira/browse/LUCENE-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16164335#comment-16164335 ] Ignacio Vera commented on LUCENE-7951: -- Now all test are green. Note what I have to do with the circles as for WGS84 I was having problems. > New wrapper classes for Geo3d > - > > Key: LUCENE-7951 > URL: https://issues.apache.org/jira/browse/LUCENE-7951 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial-extras >Reporter: Ignacio Vera >Assignee: David Smiley >Priority: Minor > Attachments: LUCENE_7951_build.patch, LUCENE_7951_build.patch, > LUCENE-7951.patch, LUCENE-7951.patch > > > 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! -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7955) New GeoShape: GeoDegeneratePath
[ https://issues.apache.org/jira/browse/LUCENE-7955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16160306#comment-16160306 ] Ignacio Vera commented on LUCENE-7955: -- Looks great, thanks! Once more thing, it would be good to add this class to StandardObjects so it is serialize efficiently. thanks again! > New GeoShape: GeoDegeneratePath > --- > > Key: LUCENE-7955 > URL: https://issues.apache.org/jira/browse/LUCENE-7955 > Project: Lucene - Core > Issue Type: Improvement >Reporter: Ignacio Vera >Assignee: Karl Wright >Priority: Minor > Fix For: 6.7, master (8.0), 7.1 > > Attachments: LUCENE-7955-test.patch > > > Hi [~daddywri], > I propose to add new type of shape for GeoPaths that have a cutoffangle < > MINIMUM_RESOLUTION. We can define it as a shape consisting of points exactly > on the path. > It would be a much lighter version of GeoStandardPath and created only when > the cutoff angle is between 0 and MINIMUM_RESOLUTION. > Thanks! > Ignacio > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7951) New wrapper classes for Geo3d
[ https://issues.apache.org/jira/browse/LUCENE-7951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16158156#comment-16158156 ] Ignacio Vera commented on LUCENE-7951: -- Hi [~dsmiley], 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? > New wrapper classes for Geo3d > - > > Key: LUCENE-7951 > URL: https://issues.apache.org/jira/browse/LUCENE-7951 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/spatial-extras >Reporter: Ignacio Vera >Assignee: David Smiley >Priority: Minor > Attachments: LUCENE_7951_build.patch, LUCENE_7951_build.patch, > LUCENE-7951.patch, LUCENE-7951.patch > > > 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! -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-7967) GeoDegeneratePoint in Pole
[ https://issues.apache.org/jira/browse/LUCENE-7967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ignacio Vera updated LUCENE-7967: - Attachment: LUCENE-7967.patch Test attached > GeoDegeneratePoint in Pole > -- > > Key: LUCENE-7967 > URL: https://issues.apache.org/jira/browse/LUCENE-7967 > Project: Lucene - Core > Issue Type: Bug >Reporter: Ignacio Vera >Priority: Minor > Attachments: LUCENE-7967.patch > > > Hi [~daddywri], > This a small thing that shows up during the effort of integrating the library > with Spatial4J. if we have a degenerated point in the pole and you create a > point in the pole, it can happen that the new point is not within the > degenerated point. > I attach a test case. > Thanks, > I. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-7967) GeoDegeneratePoint in Pole
[ https://issues.apache.org/jira/browse/LUCENE-7967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16162772#comment-16162772 ] Ignacio Vera commented on LUCENE-7967: -- There is no hurry so please just have a look whenever you have time. Thanks! > GeoDegeneratePoint in Pole > -- > > Key: LUCENE-7967 > URL: https://issues.apache.org/jira/browse/LUCENE-7967 > Project: Lucene - Core > Issue Type: Bug >Reporter: Ignacio Vera >Assignee: Karl Wright >Priority: Minor > Attachments: LUCENE-7967.patch > > > Hi [~daddywri], > This a small thing that shows up during the effort of integrating the library > with Spatial4J. if we have a degenerated point in the pole and you create a > point in the pole, it can happen that the new point is not within the > degenerated point. > I attach a test case. > Thanks, > I. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
