Re: [hibernate-dev] [HSEARCH] Geospatial indexing and queries

//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