Nicolas and I have made good progress on Geospatial queries for Hibernate Search. # Geospatial indexing and queries Our goal is to give a reasonable but pragmatic answer to geoloc queries. We do not try and implement the most obscure geo-projection favored by ancient greeks, we do not try and find matching elements within a triangular-shaped donut on Mars' surface etc. We have purposely limited the current implementation to: - find matching elements in a circle (we have plans to extends to matching elements in a rectangle if popular demands arise but in our opinion this will not be useful or rather be misleading) - use the internationally accepted geo projection as it is i18n neutral and not centered on one particular country. We can plan on opening to other projections if the need arise (esp if data points are provided in different projections). We made sure to expose as few gory details as possible. That being said, here are more information and questions. The JIRA is https://hibernate.onjira.com/browse/HSEARCH-923 The branch is https://github.com/emmanuelbernard/hibernate-search/tree/HSEARCH-923 ## How is geoloc data exposed to the domain model? We plan on supporting three approaches: ### Special interface and embeddable object Using a specific interface as the property return type: `o.h.s.spatial.Coordinates`    @Indexed    public class Address {        @Field String city;        @Spatial Coordinates location = new Coordinates() {            public double getLatitude() { ... }            public double getLongitude() { ... }        }    } ### Special interface implemented by the entity Using a specific interface implemented by the entity: `o.h.s.spatial.Coordinates`    @Indexed @Spatial    public class Address {        @Field String city;        public double getLatitude() { ... }        public double getLongitude() { ... }    } ### Use JTS's Point type Use `Point` as the spatial property type. ### (maybe) `double` hosted by two unrelated properties The problem is to find a nice way to bind these properties to the spatial data. ## How is geoloc data indexed There will be two strategies - index latitude and longitude as is and do a AND query matching both. This typically works nicely for small datasets. - index latitude and longitude as matching a 15 level grid (from most generic to most specific). this typically works nicely for big datasets ## Query DSL We have worked to make a fluent spatial API to the current query DSL. Before we go on implementing it, we would like your feedback. Some points remains open. ### General overview    builder.spatial()        .scoreByProximity() //not implemented yet        .onField("coord")            .boostedTo(2)        .within(2).km()            .of( coordinates )        .createQuery(); ### onField onField is not a good name. It has a slightly meaning than when it's used in range().onField(). We need to find a better name: - onField - onGrid - onCoordinates - onLocation This really represents the metadata set where the location will be stored. In the boolean approach, we store latitude and longitude. In the grid approach, we store latitude, longitude and the set of grids coordinates belong to. .onField() does accept a field name which can be the `Coordinates` property or the virtual field used by the class-level bridge (if lat and long are top level properties). When latitude and longitude are independent properties, we would use    builder.        .onLatitudeField("lat")        .andLongitudeField("lat") ### Surface checked #### Option 1: centeredOn    .centeredOn(double, double)    //or    .centeredOn()      .latitude(double)      .longitude(double)    //or    .centeredOn(SpatialIndexable)    .centeredOn(JTS.Point) // hard dependency on JTS even for non spatial users :(    .centeredOn(Object) //? to avoid JTS dep - Should we have a version accepting Object? - What is best, centeredOn(double, double) or centeredOn().latitude(double).longitude(double)? #### Option 2: in / within    //query within circle    b.spatial()        .onField("coord")        .within(2).km()        .of(SpatialIndexable)        .within(2).km()        .of()            .latitude()            .longitude()         .createQuery()   //or with a different unit handling    //query within circle    b.spatial()        .onField("coord")        .within(2, Unit.km)        .of(SpatialIndexable)        .within(2, Unit.km)        .of()            .latitude()            .longitude()         .createQuery() My reason to support units is that a. it's explicit and b. when those geosuckers improve, we could support time units like mins or hours. Note, that's a very hard problem to crack and solutions are resource intensive and not very accurate. None really do it correctly, not Google for sure. We could support rectangles / boxes if really needed    //query in box    b.spatial()        .onField("coord")        .inBox()            .from()            .to()         .createQuery();    //more formal but more correct wrt projection    b.spatial()        .onField("coord")        .inBox()            .withUpperLeft()            .withLowerRight()         .createQuery(); Please give us your feedback. ## TODOs - Implement fluent DSL - Implement Special interface implemented by the entity - Implement  Use JTS's Point type - Implement bridge that supports indexing for boolean queries based on lat and long instead of the grid. - Implement @Spatial as a marker annotation for the spatial bridge - Implement variable score based on proximity  Today we use constant score, ie in = 1, out = 0. We can think about a score that goes from 1 to 0 based on the distance from the center to the circle size  We can imagine queries that should return close elements above far elements.  Note we might need a score going from 1 to .5 or some other value. Need to think about that. - Write how to focused doc - Write doc on perf comparing grid vs boolean queries - Convert to JBoss logging - Add unit test using faceting + spatial queries Emmanuel _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

To answer your question on "centeredOn", I'd avoid a strong dependency on JTS. The "Object" option you propose could be an interface, and we create a factory class which returns them; users should then be able to use the JTS enabled factory or a dumb one.

Hi Emmanuel, I'm not familiar of what kind of API a gis expert would expect so I'm commenting only as a JPA user who might need to introduce some "close to" feature. Assuming we can get the API to support overloading without enforcing the JTS library as a hard dependency, could we do something like: SomeType centeredOn(JTSLocation jts); // for the more experts SomeType centeredOn(long latitude, long longitude); // the simple one [cut] > > To answer your question on "centeredOn", I'd avoid a strong dependency > on JTS. The "Object" option you propose could be an interface, and we > create a factory class which returns them; users should then be able > to use the JTS enabled factory or a dumb one. How would that look in practice? Maybe it can't work, I was thinking loud about some in this style: SomeType centeredOn(LocationInterface obj); And have an helper class which provides different builder-like constructs: LocationInterface createLocation(JTSLocation jts); LocationInterface createLocation(long latitude, long longitude); LocationInterface createLocation(...);

The idea is that you could have two of these helper classes, one bundled in the search-gis module having the more expressive JTS methods as well, and a simpler one included in the search-engine. Also this would make sure the Query fluent API doesn't get too complex while adding additional (and possibly custom) implementations for LocationInterface; as a user I'd likely want to create my own implementation.

(I wouldn't call it "LocationInterface", just to stress I'm thinking of an interface) On 19 December 2011 13:15, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: > > On 5 déc. 2011, at 17:01, Sanne Grinovero wrote: > >> To answer your question on "centeredOn", I'd avoid a strong dependency >> on JTS. The "Object" option you propose could be an interface, and we >> create a factory class which returns them; users should then be able >> to use the JTS enabled factory or a dumb one. > > I've been thinking about your approach but I don't find it too appealing > > ## Solution 1 > SomeType centeredOn(Object jts); > > .centeredOn( location.getPoint() ); > > ## Solution 2 > > SomeType centeredOn(LocationFactory factory); > > .centeredOn( new JTSLocation( location.getPoint() ) ); > > To me solution 2 adds verbosity and is not a lot more typesafe. Granted, the user will have to find an impl of LocationFactory that matches its need, so the type system guides him a bit more than raw Object. > > Is the extra verbosity worth the extra help here? > > Emmanuel I'm not really understanding solution #2 ..how is this LocationFactory affecting the query?

#1 seems ok. Another question; quoting first email again: "Using a specific interface implemented by the entity: `o.h.s.spatial.Coordinates`" but then your Address of the example doesn't implement Coordinates; did you forget the "implements", or do you intend to just look for the method signatures of public double getLatitude() ?

//or .centeredOn() .latitude(double) .longitude(double)

On 19 déc. 2011, at 15:24, Sanne Grinovero wrote: > Hi Emmanuel, > I'm not familiar of what kind of API a gis expert would expect so I'm > commenting only as a JPA user who might need to introduce some "close > to" feature. > > Assuming we can get the API to support overloading without enforcing > the JTS library as a hard dependency, could we do something like: > > SomeType centeredOn(JTSLocation jts); // for the more experts > SomeType centeredOn(long latitude, long longitude); // the simple one > > [cut] >> >> To answer your question on "centeredOn", I'd avoid a strong dependency >> on JTS. The "Object" option you propose could be an interface, and we >> create a factory class which returns them; users should then be able >> to use the JTS enabled factory or a dumb one. > > How would that look in practice? > > Maybe it can't work, I was thinking loud about some in this style: > > SomeType centeredOn(LocationInterface obj); > > And have an helper class which provides different builder-like constructs: > > LocationInterface createLocation(JTSLocation jts); > LocationInterface createLocation(long latitude, long longitude); > LocationInterface createLocation(...); I think I have a way to crack that one using generics. That will be extensible and not tie us to JTS as a dependency at runtime. ``` spatial() .onCoordinates("location") .within(2, KM).of(JTSLocation.class, jtsObject) .createQuery(); ``` you alternative is nice too but requires static imports ``` spatial() .onCoordinates("location") .within(2, KM).of( toCoordinates(jtsObject) ) .createQuery(); ``` which one do you guys prefer? Note that `within ... of` is the alternative to `centeredOn` that I think we will go for but that's irrelevant for this problem. > > The idea is that you could have two of these helper classes, one > bundled in the search-gis module having the more expressive JTS > methods as well, and a simpler one included in the search-engine. > Also this would make sure the Query fluent API doesn't get too complex > while adding additional (and possibly custom) implementations for > LocationInterface; as a user I'd likely want to create my own > implementation. Do you have a specific reason in mind besides liking to hack things up :) > (I wouldn't call it "LocationInterface", just to stress I'm thinking > of an interface) > > > On 19 December 2011 13:15, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: >> >> On 5 déc. 2011, at 17:01, Sanne Grinovero wrote: >> >>> To answer your question on "centeredOn", I'd avoid a strong dependency >>> on JTS. The "Object" option you propose could be an interface, and we >>> create a factory class which returns them; users should then be able >>> to use the JTS enabled factory or a dumb one. >> >> I've been thinking about your approach but I don't find it too appealing >> >> ## Solution 1 >> SomeType centeredOn(Object jts); >> >> .centeredOn( location.getPoint() ); >> >> ## Solution 2 >> >> SomeType centeredOn(LocationFactory factory); >> >> .centeredOn( new JTSLocation( location.getPoint() ) ); >> >> To me solution 2 adds verbosity and is not a lot more typesafe. Granted, the user will have to find an impl of LocationFactory that matches its need, so the type system guides him a bit more than raw Object. >> >> Is the extra verbosity worth the extra help here? >> >> Emmanuel > > I'm not really understanding solution #2 ..how is this LocationFactory > affecting the query? You mentioned factory in your proposal, I tried to guesstimate what you meant :) #1 is not type safe though, that's the one accepting any Object. > #1 seems ok. > > Another question; quoting first email again: > "Using a specific interface implemented by the entity: > `o.h.s.spatial.Coordinates`" > but then your Address of the example doesn't implement Coordinates; > did you forget the "implements", or do you intend to just look for the > method signatures of > public double getLatitude() > ? I forgot the implements clause. but what you describe is also planned as a maybe (two points later in the initial email). _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

About ".of(JTSLocation.class, jtsObject)" nice trick, is the idea that you then return an object having a JTS specific interface to ask for the additional parameters and options? But I assume this is no longer relevant.

Nicolas and I have made good progress on Geospatial queries for Hibernate Search. # Geospatial indexing and queries Our goal is to give a reasonable but pragmatic answer to geoloc queries. We do not try and implement the most obscure geo-projection favored by ancient greeks, we do not try and find matching elements within a triangular-shaped donut on Mars' surface etc. We have purposely limited the current implementation to: - find matching elements in a circle (we have plans to extends to matching elements in a rectangle if popular demands arise but in our opinion this will not be useful or rather be misleading) - use the internationally accepted geo projection as it is i18n neutral and not centered on one particular country. We can plan on opening to other projections if the need arise (esp if data points are provided in different projections). We made sure to expose as few gory details as possible. That being said, here are more information and questions. The JIRA is https://hibernate.onjira.com/browse/HSEARCH-923 The branch is https://github.com/emmanuelbernard/hibernate-search/tree/HSEARCH-923 ## How is geoloc data exposed to the domain model? We plan on supporting three approaches: ### Special interface and embeddable object Using a specific interface as the property return type: `o.h.s.spatial.Coordinates` @Indexed public class Address { @Field String city; @Spatial Coordinates location = new Coordinates() { public double getLatitude() { ... } public double getLongitude() { ... } } } ### Special interface implemented by the entity Using a specific interface implemented by the entity: `o.h.s.spatial.Coordinates` @Indexed @Spatial public class Address { @Field String city; public double getLatitude() { ... } public double getLongitude() { ... } } ### Use JTS's Point type Use `Point` as the spatial property type. ### (maybe) `double` hosted by two unrelated properties The problem is to find a nice way to bind these properties to the spatial data. ## How is geoloc data indexed There will be two strategies - index latitude and longitude as is and do a AND query matching both. This typically works nicely for small datasets. - index latitude and longitude as matching a 15 level grid (from most generic to most specific). this typically works nicely for big datasets ## Query DSL We have worked to make a fluent spatial API to the current query DSL. Before we go on implementing it, we would like your feedback. Some points remains open. ### General overview builder.spatial() .scoreByProximity() //not implemented yet .onField("coord") .boostedTo(2) .within(2).km() .of( coordinates ) .createQuery(); ### onField onField is not a good name. It has a slightly meaning than when it's used in range().onField(). We need to find a better name: - onField - onGrid - onCoordinates - onLocation This really represents the metadata set where the location will be stored. In the boolean approach, we store latitude and longitude. In the grid approach, we store latitude, longitude and the set of grids coordinates belong to. .onField() does accept a field name which can be the `Coordinates` property or the virtual field used by the class-level bridge (if lat and long are top level properties). When latitude and longitude are independent properties, we would use builder. .onLatitudeField("lat") .andLongitudeField("lat") ### Surface checked #### Option 1: centeredOn .centeredOn(double, double) //or .centeredOn() .latitude(double) .longitude(double) //or .centeredOn(SpatialIndexable) .centeredOn(JTS.Point) // hard dependency on JTS even for non spatial users :( .centeredOn(Object) //? to avoid JTS dep - Should we have a version accepting Object? - What is best, centeredOn(double, double) or centeredOn().latitude(double).longitude(double)? #### Option 2: in / within //query within circle b.spatial() .onField("coord") .within(2).km() .of(SpatialIndexable) .within(2).km() .of() .latitude() .longitude() .createQuery() //or with a different unit handling //query within circle b.spatial() .onField("coord") .within(2, Unit.km) .of(SpatialIndexable) .within(2, Unit.km) .of() .latitude() .longitude() .createQuery() My reason to support units is that a. it's explicit and b. when those geosuckers improve, we could support time units like mins or hours. Note, that's a very hard problem to crack and solutions are resource intensive and not very accurate. None really do it correctly, not Google for sure. We could support rectangles / boxes if really needed //query in box b.spatial() .onField("coord") .inBox() .from() .to() .createQuery(); //more formal but more correct wrt projection b.spatial() .onField("coord") .inBox() .withUpperLeft() .withLowerRight() .createQuery(); Please give us your feedback. ## TODOs - Implement fluent DSL - Implement Special interface implemented by the entity - Implement Use JTS's Point type - Implement bridge that supports indexing for boolean queries based on lat and long instead of the grid. - Implement @Spatial as a marker annotation for the spatial bridge - Implement variable score based on proximity Today we use constant score, ie in = 1, out = 0. We can think about a score that goes from 1 to 0 based on the distance from the center to the circle size We can imagine queries that should return close elements above far elements. Note we might need a score going from 1 to .5 or some other value. Need to think about that. - Write how to focused doc - Write doc on perf comparing grid vs boolean queries - Convert to JBoss logging - Add unit test using faceting + spatial queries Emmanuel _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

My two cents : - .onLocation("position") - .onLatitude("lat").onLongitude("lng")

2011/12/21 Emmanuel Bernard <emmanuel(a)hibernate.org&gt; > Which one do you prefer (line in bold for each sample)? > >                        builder >                                .spatial() >                                        .onCoordinates( "location" )  or > .forCoordinates("location") or .forLocation("location") or something else >                                        .within( 500, Unit.KM ) > >  .of().latitude(48.858333d).longitude(2.294444d) >                                        .createQuery(); > > > >                        builder >                                .spatial() >                                        .onLatitudeField( "latitude" > ).onLongitudeField( "longitude" ) or .forLatitudeField( "latitude" > ).forLongitudeField( "longitude" )  or something else >                                        .within( 51, Unit.KM ) >                                                .of().latitude( 24d > ).longitude( 31.5d ) >                                        .createQuery();

Maybe `Coordinates` is a bad idea entirely and we should only use "free form properties" like this

On Dec 21, 2011, at 2:59 PM, Emmanuel Bernard wrote: > Which one do you prefer (line in bold for each sample)? > > builder > .spatial() > .onCoordinates( "location" ) or .forCoordinates("location") or .forLocation("location") or something else > .within( 500, Unit.KM ) > .of().latitude(48.858333d).longitude(2.294444d) > .createQuery(); builder .spatial() .forLocation("location") .within( 500, Unit.KM ) .of().latitude(48.858333d).longitude(2.294444d) .createQuery(); On a side node, do we really need 'of()'. Sure it makes it sounds a little more like real English, but then why is there no 'and()' between lat and long. The whole DSL part only carries so far when directly hosted in Java. If there is no compelling reason for 'of()' i would argue one can drop it.

what's about 'proximity' instead of 'spatial'?

> builder > .spatial() > .onLatitudeField( "latitude" ).onLongitudeField( "longitude" ) or .forLatitudeField( "latitude" ).forLongitudeField( "longitude" ) or something else > .within( 51, Unit.KM ) > .of().latitude( 24d ).longitude( 31.5d ) > .createQuery(); builder .spatial() .onFields(long, lat) .within( 51, Unit.KM ) .of().latitude( 24d ).longitude( 31.5d ) .createQuery();

>> >> what's about 'proximity' instead of 'spatial'? > > I am somewhat neutral, but I think the industry term is spatial queries. Thoughts? The industry term is spatial, but I think the John Doe user might be more familiar with proximity.

On 21 déc. 2011, at 17:30, Hardy Ferentschik wrote: >> >> But we can reduce the number of methods called by doing something like this >> >> builder >>   .spatial() >>       .forLocation("location") >>       .within(500, Unit.KM) >>           .ofLatitude(48.8d).andLongitude(2.29d) >>       .createQuery(); >> >> Would you like it better? > > much actually :-) If we go that way, we could even make the alternative model more explicit as well builder  .spatial()      .forLocation("location")      .within(500, Unit.KM)          .ofCoordinates(coordinates)      .createQuery();

On 21 déc. 2011, at 17:36, Sanne Grinovero wrote: > On 21 December 2011 17:34, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: >> >> On 21 déc. 2011, at 17:30, Hardy Ferentschik wrote: >> >>>> >>>> But we can reduce the number of methods called by doing something like this >>>> >>>> builder >>>>   .spatial() >>>>       .forLocation("location") >>>>       .within(500, Unit.KM) >>>>           .ofLatitude(48.8d).andLongitude(2.29d) >>>>       .createQuery(); >>>> >>>> Would you like it better? >>> >>> much actually :-) >> >> If we go that way, we could even make the alternative model more explicit as well >> >> builder >>  .spatial() >>      .forLocation("location") >>      .within(500, Unit.KM) >>          .ofCoordinates(coordinates) >>      .createQuery(); > > +1 > Best looking I've seen so far. What's the type of _coordinates_ ? `Coordinates` :)

On Dec 21, 2011, at 6:02 PM, Sanne Grinovero wrote: > And where do I find a markdown rendering plugin for gmail ? Markdown support in Apple Mail wouldn't be so bad either :-)

On 21 déc. 2011, at 17:30, Hardy Ferentschik wrote: >> >> But we can reduce the number of methods called by doing something like this >> >> builder >> .spatial() >> .forLocation("location") >> .within(500, Unit.KM) >> .ofLatitude(48.8d).andLongitude(2.29d) >> .createQuery(); >> >> Would you like it better? > > much actually :-) If we go that way, we could even make the alternative model more explicit as well builder .spatial() .forLocation("location") .within(500, Unit.KM) .ofCoordinates(coordinates) .createQuery();

Hi Emmanuel, My preference: .forLocation("location") .forLatitudeField("lat").forLongitudeField("long") Btw, I quite like "LatLong" as an alternative for the term "Coordinates" or "Location". It makes clear what the meaning is of the coordinates/location interface/method, and conditions the reader as to the order of latitude and longitude. It is also used in the Google Maps JS API (well almost, the use the imo uglier "LatLng"). Regards, Karel On 21 Dec 2011, at 14:59, Emmanuel Bernard wrote: > Which one do you prefer (line in bold for each sample)? > > builder > .spatial() > .onCoordinates( "location" ) or .forCoordinates("location") or .forLocation("location") or something else > .within( 500, Unit.KM ) > .of().latitude(48.858333d).longitude(2.294444d) > .createQuery(); > > > > builder > .spatial() > .onLatitudeField( "latitude" ).onLongitudeField( "longitude" ) or .forLatitudeField( "latitude" ).forLongitudeField( "longitude" ) or something else > .within( 51, Unit.KM ) > .of().latitude( 24d ).longitude( 31.5d ) > .createQuery(); > > On 5 déc. 2011, at 16:21, Emmanuel Bernard wrote: > >> Nicolas and I have made good progress on Geospatial queries for Hibernate Search. >> >> # Geospatial indexing and queries >> >> Our goal is to give a reasonable but pragmatic answer to geoloc queries. We do not try and implement the most obscure geo-projection favored by ancient greeks, we do not try and find matching elements within a triangular-shaped donut on Mars' surface etc. We have purposely limited the current implementation to: >> >> - find matching elements in a circle (we have plans to extends to matching elements in a rectangle if popular demands arise but in our opinion this will not be useful or rather be misleading) >> - use the internationally accepted geo projection as it is i18n neutral and not centered on one particular country. We can plan on opening to other projections if the need arise (esp if data points are provided in different projections). >> >> We made sure to expose as few gory details as possible. >> >> That being said, here are more information and questions. >> >> The JIRA is https://hibernate.onjira.com/browse/HSEARCH-923 >> The branch is https://github.com/emmanuelbernard/hibernate-search/tree/HSEARCH-923 >> >> ## How is geoloc data exposed to the domain model? >> >> We plan on supporting three approaches: >> >> ### Special interface and embeddable object >> >> Using a specific interface as the property return type: `o.h.s.spatial.Coordinates` >> >> @Indexed >> public class Address { >> @Field String city; >> @Spatial Coordinates location = new Coordinates() { >> public double getLatitude() { ... } >> public double getLongitude() { ... } >> } >> } >> >> ### Special interface implemented by the entity >> >> Using a specific interface implemented by the entity: `o.h.s.spatial.Coordinates` >> >> @Indexed @Spatial >> public class Address { >> @Field String city; >> >> public double getLatitude() { ... } >> public double getLongitude() { ... } >> } >> >> ### Use JTS's Point type >> >> Use `Point` as the spatial property type. >> >> ### (maybe) `double` hosted by two unrelated properties >> >> The problem is to find a nice way to bind these properties to the spatial data. >> >> ## How is geoloc data indexed >> >> There will be two strategies >> >> - index latitude and longitude as is and do a AND query matching both. This typically works nicely for small datasets. >> - index latitude and longitude as matching a 15 level grid (from most generic to most specific). this typically works nicely for big datasets >> >> ## Query DSL >> >> We have worked to make a fluent spatial API to the current query DSL. Before we go on implementing it, we would like your feedback. Some points remains open. >> >> ### General overview >> >> builder.spatial() >> .scoreByProximity() //not implemented yet >> .onField("coord") >> .boostedTo(2) >> .within(2).km() >> .of( coordinates ) >> .createQuery(); >> >> ### onField >> >> onField is not a good name. It has a slightly meaning than when it's used in range().onField(). We need to find a better name: >> >> - onField >> - onGrid >> - onCoordinates >> - onLocation >> >> This really represents the metadata set where the location will be stored. In the boolean approach, we store latitude and longitude. In the grid approach, we store latitude, >> longitude and the set of grids coordinates belong to. >> >> .onField() does accept a field name which can be the `Coordinates` property or the virtual field used by the class-level bridge (if lat and long are top level properties). >> >> When latitude and longitude are independent properties, we would use >> >> builder. >> .onLatitudeField("lat") >> .andLongitudeField("lat") >> >> ### Surface checked >> >> #### Option 1: centeredOn >> >> .centeredOn(double, double) >> //or >> .centeredOn() >> .latitude(double) >> .longitude(double) >> //or >> .centeredOn(SpatialIndexable) >> .centeredOn(JTS.Point) // hard dependency on JTS even for non spatial users :( >> .centeredOn(Object) //? to avoid JTS dep >> >> - Should we have a version accepting Object? >> - What is best, centeredOn(double, double) or centeredOn().latitude(double).longitude(double)? >> >> #### Option 2: in / within >> >> >> //query within circle >> b.spatial() >> .onField("coord") >> .within(2).km() >> .of(SpatialIndexable) >> >> .within(2).km() >> .of() >> .latitude() >> .longitude() >> .createQuery() >> >> //or with a different unit handling >> >> //query within circle >> b.spatial() >> .onField("coord") >> .within(2, Unit.km) >> .of(SpatialIndexable) >> >> .within(2, Unit.km) >> .of() >> .latitude() >> .longitude() >> .createQuery() >> >> My reason to support units is that a. it's explicit and b. when those geosuckers improve, we could support time units like mins or hours. Note, that's a very hard problem to crack and solutions are resource intensive and not very accurate. None really do it correctly, not Google for sure. >> >> >> We could support rectangles / boxes if really needed >> >> //query in box >> b.spatial() >> .onField("coord") >> .inBox() >> .from() >> .to() >> .createQuery(); >> >> //more formal but more correct wrt projection >> b.spatial() >> .onField("coord") >> .inBox() >> .withUpperLeft() >> .withLowerRight() >> .createQuery(); >> >> >> Please give us your feedback. >> >> ## TODOs >> >> - Implement fluent DSL >> - Implement Special interface implemented by the entity >> - Implement Use JTS's Point type >> - Implement bridge that supports indexing for boolean queries based on lat and long instead of the grid. >> - Implement @Spatial as a marker annotation for the spatial bridge >> - Implement variable score based on proximity >> Today we use constant score, ie in = 1, out = 0. We can think about a score that goes from 1 to 0 based on the distance from the center to the circle size >> We can imagine queries that should return close elements above far elements. >> Note we might need a score going from 1 to .5 or some other value. Need to think about that. >> - Write how to focused doc >> - Write doc on perf comparing grid vs boolean queries >> - Convert to JBoss logging >> - Add unit test using faceting + spatial queries >> >> Emmanuel >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev