On 21 Dec 2011, at 18:32, Emmanuel Bernard wrote:
>
> Maybe `Coordinates` is a bad idea entirely and we should only use "free form
> properties" like this
Why not do this in two steps. Use the "free form properties" now for the first
implementation. Later, after integration of Hibernate Spati
On 21 déc. 2011, at 16:29, Sanne Grinovero wrote:
> wrote:
>> My two cents :
>>
>> - .onLocation("position")
>>
>> - .onLatitude("lat").onLongitude("lng")
>
> I'm confused on what the String represents. I'm going to assume index
> fields? So I'm preferring the "onLocation*Field* [..]" version
On 21 déc. 2011, at 18:10, Hardy Ferentschik wrote:
>
> 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 :-)
I'm moving my mailbox to a Git repo on GitHub. If you w
On 21 déc. 2011, at 18:02, Sanne Grinovero wrote:
> On 21 December 2011 17:58, Emmanuel Bernard wrote:
>>
>> On 21 déc. 2011, at 17:36, Sanne Grinovero wrote:
>>
>>> On 21 December 2011 17:34, Emmanuel Bernard wrote:
On 21 déc. 2011, at 17:30, Hardy Ferentschik wrote:
>>
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 :-)
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.j
On 21 December 2011 17:58, Emmanuel Bernard wrote:
>
> On 21 déc. 2011, at 17:36, Sanne Grinovero wrote:
>
>> On 21 December 2011 17:34, Emmanuel Bernard wrote:
>>>
>>> On 21 déc. 2011, at 17:30, Hardy Ferentschik wrote:
>>>
>
> But we can reduce the number of methods called by doing some
On 21 déc. 2011, at 17:36, Sanne Grinovero wrote:
> On 21 December 2011 17:34, Emmanuel Bernard 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()
On 21 December 2011 17:34, Emmanuel Bernard 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)
>>>
On Dec 21, 2011, at 5:34 PM, Emmanuel Bernard 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
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)
>> .crea
On 21 déc. 2011, at 17:30, Hardy Ferentschik wrote:
>>>
>>> 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
>> 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 big problem we have is that forLocation is not really pointing to one or
even two (lat + long) fields in Lucene. It's pointing to a user property that
leads to a set of Lucene fields (one per grid level + lat + long. That's why we
have shied away from naming it Field.
I guess LatLong is the
On 21 déc. 2011, at 15:19, Hardy Ferentschik wrote:
>
> On Dec 21, 2011, at 2:59 PM, Emmanuel Bernard wrote:
>
>> Which one do you prefer (line in bold for each sample)?
>>
>> builder
>> .spatial()
>> .onCoo
Inline to both these, and some thoughts about subsequent mails:
On 21 December 2011 15:03, Nicolas Helleringer
wrote:
> My two cents :
>
> - .onLocation("position")
>
> - .onLatitude("lat").onLongitude("lng")
I'm confused on what the String represents. I'm going to assume index
fields? So I'm pr
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 re
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 .
My two cents :
- .onLocation("position")
- .onLatitude("lat").onLongitude("lng")
Niko
2011/12/21 Emmanuel Bernard
> Which one do you prefer (line in bold for each sample)?
>
>builder
>.spatial()
>.
Which one do you prefer (line in bold for each sample)?
builder
.spatial()
.onCoordinates( "location" ) or
.forCoordinates("location") or .forLocation("location") or something else
On 19 déc. 2011, at 18:30, Sanne Grinovero wrote:
> 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.
It's more that the
Thanks Karel,
if that's your suggestion I guess that would nicely simplify the problem.
Regarding Emmanuel's
"Note that `within ... of` is the alternative to `centeredOn` that I
think we will go for but that's irrelevant for this problem."
+1 nice! looks much better.
About ".of(JTSLocation.class
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()/ge
On 19 déc. 2011, at 16:17, Hardy Ferentschik wrote:
> I am sitting in a similar boat than Sanne. I don't know how much useful
> feedback I can provide w/o first getting to
> know the actual problem space better.
>
> Looking at the Jira issue and comments, I like the idea of having the
> @Spat
On Dec 19, 2011, at 6:04 PM, Emmanuel Bernard wrote:
> spatial()
>.onCoordinates("location")
>.within(2, KM).of(JTSLocation.class, jtsObject)
>.createQuery();
> ```
I prefer this, but probably with the arguments in 'of' rotated:
spatial()
.onCoordinates("location")
.within(2,
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
I am sitting in a similar boat than Sanne. I don't know how much useful
feedback I can provide w/o first getting to
know the actual problem space better.
Looking at the Jira issue and comments, I like the idea of having the @Spatial
annotation. One think which comes
to my mind here is how this
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 lik
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
Hey guys,
I have not received much feedback on this. Can you take a look. I wanted to get
the DSL done in the next couple of days.
Emmanuel
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
On 5 déc. 2011, at 17:01, Sanne Grinovero wrote:
> Thanks! Looks like a great start.
>
> Some questions/considerations:
> # In case of multi-level grids, I'd assume that the option is
> specified only on the mapping, but doesn't need to be specified at
> Query time?
That's correct.
> # Not usi
Thanks! Looks like a great start.
Some questions/considerations:
# In case of multi-level grids, I'd assume that the option is
specified only on the mapping, but doesn't need to be specified at
Query time?
# Not using anything fancy from the Lucene side correct? Just exact
term matches with boole
31 matches
Mail list logo
