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

[Karel Maesen]

Hi Emmanuel,

I didn't see your mail from 5/12, so I only now read your proposal. Sorry for the late reaction.

I'll give you more feedback but here some quick notes.

I would advise not to use JTS for this case. It's not intended for geographic coordinates (lat/long). That's why it has getX()/getY() accessors which leads to endless confusion as to whether getX() is longitude or latitude. For these straightforward spatial searches (within distance searches), the added dependency of JTS offers imo not enough added-value.

I liked the proposal to use:

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

because it makes it clear what the doubles mean. Again, some people are used to lat/long others long/lat - the confusion is quite widespread among users (experts and novices in geospatial).

Regards,

Karel


On 19 Dec 2011, at 18:04, Emmanuel Bernard wrote:

> 
> 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).
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev