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

[Emmanuel Bernard]

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 at hibernate.org> 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).