Re: [hibernate-dev] Hibernate JTS upgrade: migration notes required

[Karel Maesen]

Hi Guillaume,

Thanks for pointing this out. I will take care of it.

Regards,

Karel

On Mon, Sep 24, 2018 at 4:23 PM Guillaume Smet 
wrote:

> Hi Karel,
>
> Back from vacation and I just saw this commit:
> https://github.com/hibernate/hibernate-orm/commit/b3e56a5db71110d07a095762a788c53ef258bd01
> .
>
> As it will break user code, we need a note in the migration guide about
> this change (migration-guide.adoc at the root of the repository).
>
> The migration guide in master (
> https://github.com/hibernate/hibernate-orm/blob/master/migration-guide.adoc)
> is currently empty but you can see some examples in the 5.3 migration guide:
> https://github.com/hibernate/hibernate-orm/blob/5.3/migration-guide.adoc .
>
> Could you take care of it?
>
> Thanks!
>
> --
> Guillaume
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate Spatial - JTS update - compatibility issue

[Karel Maesen]

Hi Guillaume,

We can do this in a 5.4.  As a commenter on this issue correctly noted,
geolatte-geom has already moved to 1.16.0-RC1, so the change in HS can
follow quickly.  We should wait for the official 1.16 release though before
releasing it.

I'll put the ticket into progress, and upgrade the geolatte-geom dependency
so people can see the progress.

Best regards,

Karel





On Wed, Sep 5, 2018 at 3:42 PM Guillaume Smet 
wrote:

> Hi list, Karel,
>
> In https://hibernate.atlassian.net/browse/HHH-12144 , people are asking
> about a JTS upgrade and at least one person seems to be willing to
> contribute it.
>
> The issue is that in newer JTS versions, they have changed the package
> names so we would have a compatibility issue (see
> https://github.com/locationtech/jts/blob/master/MIGRATION.md), which, if
> I understand our spatial support correctly, would require hibernate-spatial
> users to change their own code.
>
> So the big question is: would that be acceptable to do in a potential 5.4
> or should we wait for 6?
>
> I'm not exactly sure of the type of compatibility guarantees we offer for
> hibernate-spatial.
>
> Karel, do you have plans for it?
>
> Thanks,
>
> --
> Guillaume
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Merging hibernate spatial Dialects with the core ones

[Karel Maesen]

Yes, a SqlFunctionContributor would solve the problem of registering
spatial functions. Then the only thing left are the methods defined in the
SpatialDialect interface. These are helper methods for use in Criterion
implementations (to generate the correct SQL syntax). I think these methods
can be refactored to a separate Service (SpatialQuerySupportService). In
that case, yes we can remove the spatial dialects altogether.

When I'm back from holiday, I will attempt refactoring the methods in
SpatialDialect to a Service. If you then provide a SqlFunctionContributor
we can start with the work of removing spatial dialects.


On Tue, Jun 28, 2016 at 5:19 PM, Steve Ebersole <st...@hibernate.org> wrote:

> Thanks for the clarification.
>
> However, all told I am not sure what you are suggesting.  Are you
> suggesting that we somehow make Dialect itself expandable/mutable and
> hibernate-spatial hook into that to expand mutate the ORM Dialect?
>
> If it is just augmenting Types and SQLFunctions we already have
> capabilities for this that I'd rather leverage:
>
>- For Types, hibernate-spatial would just provide a TypeContributor
>and based on the ORM Dialect it could contribute the needed Types.
>- We do not currently have a clean way to "contribute SQLFunctions"
>from an integration.  But if we are making changes anyway, I'd rather do
>this - adding a SqlFunctionContributor
>
> If spatial dialects are really *only* used to contribute Types and 
> SQLFunctions,
> the above options would remove the need for having spatial dialects at all
> and still allow hibernate-spatial to contribute its things.
>
> WDYT?
>
>
> On Tue, Jun 28, 2016 at 9:18 AM Karel Maesen <ka...@geovise.com> wrote:
>
>> @Steve, besides Types a number of spatial Functions are registered for
>> use in queries.
>>
>> The Dialect#contributetypes method is currently already used by
>> Hibernate-spatial to inject to correct Types (with the correct
>> SqlTypeDescriptors) for the SpatialDialect.
>>
>> On Tue, Jun 28, 2016 at 3:40 PM, Steve Ebersole <st...@hibernate.org>
>> wrote:
>>
>>> I agree.  I think keeping these separate makes the most sense.
>>>
>>> @Karel, we already have that capability wrt Types (see
>>> Dialect#contributeTypes).  What else would get injected?
>>>
>>> On Tue, Jun 28, 2016 at 8:33 AM Gunnar Morling <gun...@hibernate.org>
>>> wrote:
>>>
>>>> One thing to keep in mind is that the module system of Java 9
>>>> ("Jigsaw") doesn't support a notion of optional module dependences.
>>>>
>>>> So if this is meant to remain an "optional feature" (i.e. Geo-specific
>>>> libraries are not required at runtime when not using the spatial stuff), it
>>>> should remain a separate artifact - this is, should we plan to make
>>>> Hibernate ORM JARs Jigsaw modules at some point.
>>>>
>>>> --Gunnar
>>>>
>>>>
>>>> 2016-06-28 15:22 GMT+02:00 Karel Maesen <ka...@geovise.com>:
>>>>
>>>>> It makes sense for some Dialects such as those for MySQL and MS SQL
>>>>> Server.
>>>>> Less so for Postgresql and Oracle Spatial because here the spatial
>>>>> capabilities need to be installed and configured separately (and even
>>>>> have
>>>>> versioning separate from the main database engine).
>>>>>
>>>>> I would favour an approach, close to what Sanne is suggesting, where
>>>>> the
>>>>> spatial capability (Incl. Types) is injected into the Dialect during
>>>>> Dialect construction based on some explicit configuration. In that way
>>>>> the
>>>>> relation between Dialect and the spatial capability mirrors the
>>>>> relation
>>>>> between database engine and spatial capability (if any).
>>>>>
>>>>> Regards,
>>>>>
>>>>> Karel
>>>>>
>>>>> PS: I'm leaving tomorrow on holiday for a couple of weeks so I won't be
>>>>> able to resume the exchange before July 20.
>>>>>
>>>>> On Mon, Jun 27, 2016 at 3:53 PM, Steve Ebersole <st...@hibernate.org>
>>>>> wrote:
>>>>>
>>>>> > They have not been "merged" in the same way we merged
>>>>> > hibernate-entitymanager into hibernate-core.So at the moment
>>>>> using
>>>>> > hibernate-core e.g. does not require geolatte to be pr

Re: [hibernate-dev] Merging hibernate spatial Dialects with the core ones

[Karel Maesen]

@Steve, besides Types a number of spatial Functions are registered for use
in queries.

The Dialect#contributetypes method is currently already used by
Hibernate-spatial to inject to correct Types (with the correct
SqlTypeDescriptors) for the SpatialDialect.

On Tue, Jun 28, 2016 at 3:40 PM, Steve Ebersole <st...@hibernate.org> wrote:

> I agree.  I think keeping these separate makes the most sense.
>
> @Karel, we already have that capability wrt Types (see
> Dialect#contributeTypes).  What else would get injected?
>
> On Tue, Jun 28, 2016 at 8:33 AM Gunnar Morling <gun...@hibernate.org>
> wrote:
>
>> One thing to keep in mind is that the module system of Java 9 ("Jigsaw")
>> doesn't support a notion of optional module dependences.
>>
>> So if this is meant to remain an "optional feature" (i.e. Geo-specific
>> libraries are not required at runtime when not using the spatial stuff), it
>> should remain a separate artifact - this is, should we plan to make
>> Hibernate ORM JARs Jigsaw modules at some point.
>>
>> --Gunnar
>>
>>
>> 2016-06-28 15:22 GMT+02:00 Karel Maesen <ka...@geovise.com>:
>>
>>> It makes sense for some Dialects such as those for MySQL and MS SQL
>>> Server.
>>> Less so for Postgresql and Oracle Spatial because here the spatial
>>> capabilities need to be installed and configured separately (and even
>>> have
>>> versioning separate from the main database engine).
>>>
>>> I would favour an approach, close to what Sanne is suggesting, where the
>>> spatial capability (Incl. Types) is injected into the Dialect during
>>> Dialect construction based on some explicit configuration. In that way
>>> the
>>> relation between Dialect and the spatial capability mirrors the relation
>>> between database engine and spatial capability (if any).
>>>
>>> Regards,
>>>
>>> Karel
>>>
>>> PS: I'm leaving tomorrow on holiday for a couple of weeks so I won't be
>>> able to resume the exchange before July 20.
>>>
>>> On Mon, Jun 27, 2016 at 3:53 PM, Steve Ebersole <st...@hibernate.org>
>>> wrote:
>>>
>>> > They have not been "merged" in the same way we merged
>>> > hibernate-entitymanager into hibernate-core.So at the moment using
>>> > hibernate-core e.g. does not require geolatte to be present.  geolatte
>>> is
>>> > only required if using hibernate-spatial (isolated transitive dep).
>>> >
>>> > Karel, what are your thoughts on this?  I am not a fan of making
>>> geolatte
>>> > optional/provided, but if we all deem that folding hibernate-spatial
>>> into
>>> > hibernate-core (ala hibernate-entitymanager) as Vlad suggests is
>>> desirable
>>> > then I will accept that
>>> >
>>> > On Mon, Jun 27, 2016, 6:50 AM Sanne Grinovero <sa...@hibernate.org>
>>> wrote:
>>> >
>>> > > Nice idea!
>>> > >
>>> > > since the modules were merged already, don't we already require
>>> > > geolatte-geom ?
>>> > > I guess some code might be intentionally designed to fail gracefully
>>> > > about this library being there or not, but we'd need to make sure
>>> that
>>> > > can be tested for it to be maintainable.
>>> > >
>>> > > My preference would be to have:
>>> > >  - All Dialects automatically provide the spatial extensions if the
>>> > > needed dependencies are in place: we could automatically alias them
>>> > > based on this?
>>> > >  - a good error message naming the missing dependencies explicitly
>>> > > when someone attempts to use such a Spatial extensions, but the
>>> > > feature was not enabled by our automatic logic.
>>> > >  - be able to test for these.
>>> > >
>>> > > In practice I believe this means we should still have it as an
>>> > > independent source module, compile and test it as an independent
>>> > > module, and only bundle within the ORM main jar as final distribution
>>> > > step.
>>> > >
>>> > > If that's too much work, I'd rather make the geolatte-geom a
>>> mandatory
>>> > > dependency than to have cryptic runtime failures.
>>> > >
>>> > > On 27 June 2016 at 12:41, Vlad Mihalcea <mihalcea.v...@gmail.com&

Re: [hibernate-dev] Merging hibernate spatial Dialects with the core ones

[Karel Maesen]

It makes sense for some Dialects such as those for MySQL and MS SQL Server.
Less so for Postgresql and Oracle Spatial because here the spatial
capabilities need to be installed and configured separately (and even have
versioning separate from the main database engine).

I would favour an approach, close to what Sanne is suggesting, where the
spatial capability (Incl. Types) is injected into the Dialect during
Dialect construction based on some explicit configuration. In that way the
relation between Dialect and the spatial capability mirrors the relation
between database engine and spatial capability (if any).

Regards,

Karel

PS: I'm leaving tomorrow on holiday for a couple of weeks so I won't be
able to resume the exchange before July 20.

On Mon, Jun 27, 2016 at 3:53 PM, Steve Ebersole  wrote:

> They have not been "merged" in the same way we merged
> hibernate-entitymanager into hibernate-core.So at the moment using
> hibernate-core e.g. does not require geolatte to be present.  geolatte is
> only required if using hibernate-spatial (isolated transitive dep).
>
> Karel, what are your thoughts on this?  I am not a fan of making geolatte
> optional/provided, but if we all deem that folding hibernate-spatial into
> hibernate-core (ala hibernate-entitymanager) as Vlad suggests is desirable
> then I will accept that
>
> On Mon, Jun 27, 2016, 6:50 AM Sanne Grinovero  wrote:
>
> > Nice idea!
> >
> > since the modules were merged already, don't we already require
> > geolatte-geom ?
> > I guess some code might be intentionally designed to fail gracefully
> > about this library being there or not, but we'd need to make sure that
> > can be tested for it to be maintainable.
> >
> > My preference would be to have:
> >  - All Dialects automatically provide the spatial extensions if the
> > needed dependencies are in place: we could automatically alias them
> > based on this?
> >  - a good error message naming the missing dependencies explicitly
> > when someone attempts to use such a Spatial extensions, but the
> > feature was not enabled by our automatic logic.
> >  - be able to test for these.
> >
> > In practice I believe this means we should still have it as an
> > independent source module, compile and test it as an independent
> > module, and only bundle within the ORM main jar as final distribution
> > step.
> >
> > If that's too much work, I'd rather make the geolatte-geom a mandatory
> > dependency than to have cryptic runtime failures.
> >
> > On 27 June 2016 at 12:41, Vlad Mihalcea  wrote:
> > > Hi,
> > >
> > > Since hibenrate-spatial has been merged into Hibernate code base,
> > shouldn't
> > > we merge the Dialects as well.
> > > For instance, we have MySQL56InnoDBSpatialDialect which can simply be
> > > merged into a MySQL56InnoDBDialect.
> > > This way, MySQL57InnoDBDialect can take advantage of spatial queries as
> > > well.
> > >
> > > The only drawback is that we need to add the geolatte-geom lib to
> > > hibernate-orm.
> > >
> > > Let me know what you think.
> > >
> > > Vlad
> > > ___
> > > hibernate-dev mailing list
> > > hibernate-dev@lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] http://www.hibernatespatial.org/

[Karel Maesen]

That is correct.

Karel

On Mon, Apr 18, 2016 at 5:40 PM, Vlad Mihalcea <mihalcea.v...@gmail.com>
wrote:

> I'm going to integrate it in master, 5.1, and 5.0 since theHibernate
> Spatial module is the same for all three, right?
>
> Vlad
>
> On Mon, Apr 18, 2016 at 6:19 PM, Steve Ebersole <st...@hibernate.org>
> wrote:
>
> > The User Guide will definitely need some updates for 5.2, but none of my
> > changed so far have touched User Guide sources.
> >
> > On Mon, Apr 18, 2016 at 5:25 AM Sanne Grinovero <sa...@hibernate.org>
> > wrote:
> >
> >> On 17 April 2016 at 19:43, Vlad Mihalcea <mihalcea.v...@gmail.com>
> wrote:
> >> > Hi,
> >> >
> >> > Thanks for the update. I'm going to integrate it next week after the
> >> > Session->EntityFactory merge.
> >>
> >> Best to double-check with Steve, but I believe updates to the user
> >> guide might not need to wait for his refactoring work to be completed?
> >>
> >> >
> >> > Vlad
> >> >
> >> > On Sun, Apr 17, 2016 at 5:12 PM, Karel Maesen <ka...@geovise.com>
> >> wrote:
> >> >
> >> >> Hi Vlad,
> >> >>
> >> >> I've created a PR (#1334) that contains a number of corrections and
> >> >> additions for the User Guide.
> >> >>
> >> >> Regards,
> >> >>
> >> >> Karel
> >> >>
> >> >> On Wed, Mar 2, 2016 at 10:24 PM, Karel Maesen <ka...@geovise.com>
> >> wrote:
> >> >>
> >> >>> Hi Vlad,
> >> >>>
> >> >>> Thanks for doing this already. It’s a good starting point. I’ll
> >> suggest a
> >> >>> number of changes using a PR on the asciidoc and unit test sources
> in
> >> the
> >> >>> coming weeks.
> >> >>>
> >> >>> Regards,
> >> >>>
> >> >>> Karel
> >> >>>
> >> >>>
> >> >>> > On 25 Feb 2016, at 10:52, Vlad Mihalcea <mihalcea.v...@gmail.com>
> >> >>> wrote:
> >> >>> >
> >> >>> > Hi Karel,
> >> >>> >
> >> >>> > I pushed the first version of the Spatial chapter into the new
> User
> >> >>> Guide.
> >> >>> > I basically integrated the hibernatespatial.org documentation and
> >> >>> changed all examples to match the current API in Hibernate 5.
> >> >>> >
> >> >>> > You can build the User Guide as follows:
> >> >>> >
> >> >>> > $ cd documentation
> >> >>> > $ gradle rUG
> >> >>> > $ ls
> target/asciidoc/userguide/html_single/Hibernate_User_Guide.html
> >> >>> >
> >> >>> > Let me know what you think and what else do you suggest we should
> >> add.
> >> >>> >
> >> >>> > Thanks,
> >> >>> > Vlad
> >> >>> >
> >> >>> > On Wed, Feb 24, 2016 at 8:38 PM, Vlad Mihalcea <
> >> mihalcea.v...@gmail.com>
> >> >>> wrote:
> >> >>> > Hi,
> >> >>> >
> >> >>> > I already started the Spatial chapter in the new User Guide.
> >> >>> > I'm using your documentation as a starting point and build on top
> of
> >> >>> that.
> >> >>> >
> >> >>> > All examples are built as unit tests so we are notified when
> things
> >> >>> will change.
> >> >>> > I'll integrate it when I'm done and I'll send you an email with
> some
> >> >>> steps to build the User Guide.
> >> >>> > After you review it, I'll collect all your findings improve it
> >> further.
> >> >>> >
> >> >>> > Vlad
> >> >>> >
> >> >>> > On Wed, Feb 24, 2016 at 8:30 PM, Karel Maesen <ka...@geovise.com>
> >> >>> wrote:
> >> >>> > Hi Vlad,
> >> >>> >
> >> >>> > I think this is a good idea. I’m away on conference the second
> week
> >> of
> >> >>> March, but afterwards I can make some time to help you write it up.
> >> >>> >
> >> >>> > Regards,

Re: [hibernate-dev] http://www.hibernatespatial.org/

[Karel Maesen]

Hi Vlad,

I've created a PR (#1334) that contains a number of corrections and
additions for the User Guide.

Regards,

Karel

On Wed, Mar 2, 2016 at 10:24 PM, Karel Maesen <ka...@geovise.com> wrote:

> Hi Vlad,
>
> Thanks for doing this already. It’s a good starting point. I’ll suggest a
> number of changes using a PR on the asciidoc and unit test sources in the
> coming weeks.
>
> Regards,
>
> Karel
>
>
> > On 25 Feb 2016, at 10:52, Vlad Mihalcea <mihalcea.v...@gmail.com> wrote:
> >
> > Hi Karel,
> >
> > I pushed the first version of the Spatial chapter into the new User
> Guide.
> > I basically integrated the hibernatespatial.org documentation and
> changed all examples to match the current API in Hibernate 5.
> >
> > You can build the User Guide as follows:
> >
> > $ cd documentation
> > $ gradle rUG
> > $ ls target/asciidoc/userguide/html_single/Hibernate_User_Guide.html
> >
> > Let me know what you think and what else do you suggest we should add.
> >
> > Thanks,
> > Vlad
> >
> > On Wed, Feb 24, 2016 at 8:38 PM, Vlad Mihalcea <mihalcea.v...@gmail.com>
> wrote:
> > Hi,
> >
> > I already started the Spatial chapter in the new User Guide.
> > I'm using your documentation as a starting point and build on top of
> that.
> >
> > All examples are built as unit tests so we are notified when things will
> change.
> > I'll integrate it when I'm done and I'll send you an email with some
> steps to build the User Guide.
> > After you review it, I'll collect all your findings improve it further.
> >
> > Vlad
> >
> > On Wed, Feb 24, 2016 at 8:30 PM, Karel Maesen <ka...@geovise.com> wrote:
> > Hi Vlad,
> >
> > I think this is a good idea. I’m away on conference the second week of
> March, but afterwards I can make some time to help you write it up.
> >
> > Regards,
> >
> > Karel
> >
> > > On 20 Feb 2016, at 22:22, Vlad Mihalcea <mihalcea.v...@gmail.com>
> wrote:
> > >
> > > Hi Karel,
> > >
> > > Next week, I'm going to finish the SQL native chapter and then I have
> just the OSGI and Envers chapters to review.
> > > But since Hibernate Spatial is not covered at all, I think it's good
> to start with Hibernate Spatial right after I'm done with the SQL native
> one.
> > >
> > > What do you think of this?
> > >
> > > Vlad
> > >
> > > On Sat, Feb 20, 2016 at 4:18 PM, Karel Maesen <ka...@geovise.com>
> wrote:
> > > HI all,
> > >
> > > First, there seems to be a problem with the hibernate-spatial mailing
> list that I was unaware of. The user in question reached out to me
> yesterday. I will investigate shortly.
> > >
> > > Fair point about the website not mentioning the move to Hibernate 5. I
> will put up a message for this on the site.
> > >
> > > For the near future what I’m hoping for is that first, we can have the
> hibernate spatial tutorial updated to version 5, and integrated into the
> Hibernate User Guide. After that I can have the hibernatespatial.org
> URL’s redirect to that chapter. To support users of the older versions (3.x
> and 4.x), we should also make sure that users can download older versions
> of hibernate-spatial jars, and can consult older versions of the spatial
> tutorial from the hibernate.org website.
> > >
> > > As for the mailing lists, I plan on announcing shortly that they will
> be discontinued by end of year, and that questions should be asked on the
> usual hibernate channels. Btw, how can I be notified about questions about
> Spatial on the hibernate forums?
> > >
> > > Vlad, have you some idea about time frame for starting on the
> Hibernate Spatial chapter?
> > >
> > > Regards,
> > >
> > > Karel
> > >
> > >
> > > > On 20 Feb 2016, at 09:18, Vlad Mihalcea <mihalcea.v...@gmail.com>
> wrote:
> > > >
> > > > I also plan on writing a Hibernate Spatial Chapter in the new User
> Guide so
> > > > we can complete the migration.
> > > > But first, I need to finish the remaining chapters from the current
> User
> > > > Guide.
> > > >
> > > > Vlad
> > > >
> > > > On Fri, Feb 19, 2016 at 6:03 PM, Davide D'Alto <
> daltodav...@gmail.com>
> > > > wrote:
> > > >
> > > >> The user registered to the hibernate-spatial mailing list but none
> of his
> > > >> mess

[hibernate-dev] Release bundle doesn't contain spatial lib

[Karel Maesen]

Hi all,

A user recently asked where the hibernate-spatial jar could be found. The
Quickstart states that it should be in the /lib directory, but at least
recent bundles don't contain it (e.g. 5.1.0.Final).

How can this be fixed?

Regards,

Karel
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] http://www.hibernatespatial.org/

[Karel Maesen]

Hi Vlad,

Thanks for doing this already. It’s a good starting point. I’ll suggest a 
number of changes using a PR on the asciidoc and unit test sources in the 
coming weeks.  

Regards,

Karel


> On 25 Feb 2016, at 10:52, Vlad Mihalcea <mihalcea.v...@gmail.com> wrote:
> 
> Hi Karel,
> 
> I pushed the first version of the Spatial chapter into the new User Guide.
> I basically integrated the hibernatespatial.org documentation and changed all 
> examples to match the current API in Hibernate 5.
> 
> You can build the User Guide as follows:
> 
> $ cd documentation
> $ gradle rUG
> $ ls target/asciidoc/userguide/html_single/Hibernate_User_Guide.html 
> 
> Let me know what you think and what else do you suggest we should add.
> 
> Thanks,
> Vlad
> 
> On Wed, Feb 24, 2016 at 8:38 PM, Vlad Mihalcea <mihalcea.v...@gmail.com> 
> wrote:
> Hi,
> 
> I already started the Spatial chapter in the new User Guide.
> I'm using your documentation as a starting point and build on top of that.
> 
> All examples are built as unit tests so we are notified when things will 
> change.
> I'll integrate it when I'm done and I'll send you an email with some steps to 
> build the User Guide.
> After you review it, I'll collect all your findings improve it further.
> 
> Vlad
> 
> On Wed, Feb 24, 2016 at 8:30 PM, Karel Maesen <ka...@geovise.com> wrote:
> Hi Vlad,
> 
> I think this is a good idea. I’m away on conference the second week of March, 
> but afterwards I can make some time to help you write it up.
> 
> Regards,
> 
> Karel
> 
> > On 20 Feb 2016, at 22:22, Vlad Mihalcea <mihalcea.v...@gmail.com> wrote:
> >
> > Hi Karel,
> >
> > Next week, I'm going to finish the SQL native chapter and then I have just 
> > the OSGI and Envers chapters to review.
> > But since Hibernate Spatial is not covered at all, I think it's good to 
> > start with Hibernate Spatial right after I'm done with the SQL native one.
> >
> > What do you think of this?
> >
> > Vlad
> >
> > On Sat, Feb 20, 2016 at 4:18 PM, Karel Maesen <ka...@geovise.com> wrote:
> > HI all,
> >
> > First, there seems to be a problem with the hibernate-spatial mailing list 
> > that I was unaware of. The user in question reached out to me yesterday. I 
> > will investigate shortly.
> >
> > Fair point about the website not mentioning the move to Hibernate 5. I will 
> > put up a message for this on the site.
> >
> > For the near future what I’m hoping for is that first, we can have the 
> > hibernate spatial tutorial updated to version 5, and integrated into the 
> > Hibernate User Guide. After that I can have the hibernatespatial.org URL’s 
> > redirect to that chapter. To support users of the older versions (3.x and 
> > 4.x), we should also make sure that users can download older versions of 
> > hibernate-spatial jars, and can consult older versions of the spatial 
> > tutorial from the hibernate.org website.
> >
> > As for the mailing lists, I plan on announcing shortly that they will be 
> > discontinued by end of year, and that questions should be asked on the 
> > usual hibernate channels. Btw, how can I be notified about questions about 
> > Spatial on the hibernate forums?
> >
> > Vlad, have you some idea about time frame for starting on the Hibernate 
> > Spatial chapter?
> >
> > Regards,
> >
> > Karel
> >
> >
> > > On 20 Feb 2016, at 09:18, Vlad Mihalcea <mihalcea.v...@gmail.com> wrote:
> > >
> > > I also plan on writing a Hibernate Spatial Chapter in the new User Guide 
> > > so
> > > we can complete the migration.
> > > But first, I need to finish the remaining chapters from the current User
> > > Guide.
> > >
> > > Vlad
> > >
> > > On Fri, Feb 19, 2016 at 6:03 PM, Davide D'Alto <daltodav...@gmail.com>
> > > wrote:
> > >
> > >> The user registered to the hibernate-spatial mailing list but none of his
> > >> messages
> > >> appeared in the archive.
> > >>
> > >> On Fri, Feb 19, 2016 at 3:25 PM, Steve Ebersole <st...@hibernate.org>
> > >> wrote:
> > >>
> > >>> Karel, a user was asking about problems using the hibernate-spatial
> > >> mailing
> > >>> list on IRC which precipitated a discussion about how we want deal with
> > >>> these things moving forward.  For example, the
> > >>> http://www.hibernatespatial.org/ site is still up and running and really
> >

Re: [hibernate-dev] http://www.hibernatespatial.org/

[Karel Maesen]

Hi Vlad,

I think this is a good idea. I’m away on conference the second week of March, 
but afterwards I can make some time to help you write it up.

Regards,

Karel

> On 20 Feb 2016, at 22:22, Vlad Mihalcea <mihalcea.v...@gmail.com> wrote:
> 
> Hi Karel,
> 
> Next week, I'm going to finish the SQL native chapter and then I have just 
> the OSGI and Envers chapters to review.
> But since Hibernate Spatial is not covered at all, I think it's good to start 
> with Hibernate Spatial right after I'm done with the SQL native one.
> 
> What do you think of this?
> 
> Vlad
> 
> On Sat, Feb 20, 2016 at 4:18 PM, Karel Maesen <ka...@geovise.com> wrote:
> HI all,
> 
> First, there seems to be a problem with the hibernate-spatial mailing list 
> that I was unaware of. The user in question reached out to me yesterday. I 
> will investigate shortly.
> 
> Fair point about the website not mentioning the move to Hibernate 5. I will 
> put up a message for this on the site.
> 
> For the near future what I’m hoping for is that first, we can have the 
> hibernate spatial tutorial updated to version 5, and integrated into the 
> Hibernate User Guide. After that I can have the hibernatespatial.org URL’s 
> redirect to that chapter. To support users of the older versions (3.x and 
> 4.x), we should also make sure that users can download older versions of 
> hibernate-spatial jars, and can consult older versions of the spatial 
> tutorial from the hibernate.org website.
> 
> As for the mailing lists, I plan on announcing shortly that they will be 
> discontinued by end of year, and that questions should be asked on the usual 
> hibernate channels. Btw, how can I be notified about questions about Spatial 
> on the hibernate forums?
> 
> Vlad, have you some idea about time frame for starting on the Hibernate 
> Spatial chapter?
> 
> Regards,
> 
> Karel
> 
> 
> > On 20 Feb 2016, at 09:18, Vlad Mihalcea <mihalcea.v...@gmail.com> wrote:
> >
> > I also plan on writing a Hibernate Spatial Chapter in the new User Guide so
> > we can complete the migration.
> > But first, I need to finish the remaining chapters from the current User
> > Guide.
> >
> > Vlad
> >
> > On Fri, Feb 19, 2016 at 6:03 PM, Davide D'Alto <daltodav...@gmail.com>
> > wrote:
> >
> >> The user registered to the hibernate-spatial mailing list but none of his
> >> messages
> >> appeared in the archive.
> >>
> >> On Fri, Feb 19, 2016 at 3:25 PM, Steve Ebersole <st...@hibernate.org>
> >> wrote:
> >>
> >>> Karel, a user was asking about problems using the hibernate-spatial
> >> mailing
> >>> list on IRC which precipitated a discussion about how we want deal with
> >>> these things moving forward.  For example, the
> >>> http://www.hibernatespatial.org/ site is still up and running and really
> >>> has no indication that the move to integrate Spatial into Hibernate
> >> proper
> >>> was completed.  What do you want to have happen with that website/URL?
> >>>
> >>> As for other infrastructure, what would you like to have happen?  It
> >> seems
> >>> like hibernate-spatial is a more user-focused mailing list, as opposed
> >> to a
> >>> dev mailing list?  If so, Hibernate does not really do user mailing
> >> lists.
> >>> We prefer the forums or StackOverflow for user questions, so there is
> >> not a
> >>> straight "migration".  You can obviously keep the hibernate-spatial
> >> mailing
> >>> list running too, but we should have some idea how to help users who are
> >>> having trouble with it on the website (which website depends on what you
> >>> decide to do with http://www.hibernatespatial.org/.
> >>>
> >>> Any other things we should discuss in terms of infrastructure?
> >>>
> >>> Davide, what was the exact problem the user on IRC was complaining about
> >>> wrt the hibernate-spatial mailing list?
> >>> ___
> >>> hibernate-dev mailing list
> >>> hibernate-dev@lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>
> >> ___
> >> hibernate-dev mailing list
> >> hibernate-dev@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
> 


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] http://www.hibernatespatial.org/

[Karel Maesen]

HI all,

First, there seems to be a problem with the hibernate-spatial mailing list that 
I was unaware of. The user in question reached out to me yesterday. I will 
investigate shortly.

Fair point about the website not mentioning the move to Hibernate 5. I will put 
up a message for this on the site. 

For the near future what I’m hoping for is that first, we can have the 
hibernate spatial tutorial updated to version 5, and integrated into the 
Hibernate User Guide. After that I can have the hibernatespatial.org URL’s 
redirect to that chapter. To support users of the older versions (3.x and 4.x), 
we should also make sure that users can download older versions of 
hibernate-spatial jars, and can consult older versions of the spatial tutorial 
from the hibernate.org website. 

As for the mailing lists, I plan on announcing shortly that they will be 
discontinued by end of year, and that questions should be asked on the usual 
hibernate channels. Btw, how can I be notified about questions about Spatial on 
the hibernate forums? 

Vlad, have you some idea about time frame for starting on the Hibernate Spatial 
chapter? 

Regards,

Karel   


> On 20 Feb 2016, at 09:18, Vlad Mihalcea  wrote:
> 
> I also plan on writing a Hibernate Spatial Chapter in the new User Guide so
> we can complete the migration.
> But first, I need to finish the remaining chapters from the current User
> Guide.
> 
> Vlad
> 
> On Fri, Feb 19, 2016 at 6:03 PM, Davide D'Alto 
> wrote:
> 
>> The user registered to the hibernate-spatial mailing list but none of his
>> messages
>> appeared in the archive.
>> 
>> On Fri, Feb 19, 2016 at 3:25 PM, Steve Ebersole 
>> wrote:
>> 
>>> Karel, a user was asking about problems using the hibernate-spatial
>> mailing
>>> list on IRC which precipitated a discussion about how we want deal with
>>> these things moving forward.  For example, the
>>> http://www.hibernatespatial.org/ site is still up and running and really
>>> has no indication that the move to integrate Spatial into Hibernate
>> proper
>>> was completed.  What do you want to have happen with that website/URL?
>>> 
>>> As for other infrastructure, what would you like to have happen?  It
>> seems
>>> like hibernate-spatial is a more user-focused mailing list, as opposed
>> to a
>>> dev mailing list?  If so, Hibernate does not really do user mailing
>> lists.
>>> We prefer the forums or StackOverflow for user questions, so there is
>> not a
>>> straight "migration".  You can obviously keep the hibernate-spatial
>> mailing
>>> list running too, but we should have some idea how to help users who are
>>> having trouble with it on the website (which website depends on what you
>>> decide to do with http://www.hibernatespatial.org/.
>>> 
>>> Any other things we should discuss in terms of infrastructure?
>>> 
>>> Davide, what was the exact problem the user on IRC was complaining about
>>> wrt the hibernate-spatial mailing list?
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> 
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> 
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] HQL and spatial

[Karel Maesen]

Hi Steve,


> On 02 Nov 2015, at 16:16, Steve Ebersole  wrote:
> 
> Any further thoughts?
> 
> I looked over the link you gave in regards to literals, but did not fully 
> understand.  I'd prefer this follow some "escape syntax" form, beyond that 
> maybe you could just enumerate the literal types you'd want to support and 
> their formats.

Spatial literals would be really nice to have, but then it is best to have also 
spatial functions in the grammar. So let’s try to add them. The escape syntax 
form is OK for me. We can have something like ‘{gm ‘SRID=4326;POINT(4.6 
52.1)’}’ for a geometry literal.

How do we proceed? Do I write something up informally? Or is there a formalism 
you prefer? 

> 
> ALso, I have not seen any discussion around "boolean-function-expressions as 
> predicates" on SQM-15…

I’ll add some comments on that issue.

Regards,

Karel


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] HQL and spatial

[Karel Maesen]

Hi Steve,

> On 08 Sep 2015, at 22:29, Steve Ebersole  wrote:
> 
> What do you mean "have these functions integrated into HQL"?  What you 
> describe is exactly how sql functions are supported as well.  Perhaps you 
> mean defining standard support for spatial functions.  

Yes, precisely that

> As a corollary, take something like the ANSI SQL TRIM function.  Not all 
> databases support TRIM as defined by ANSI SQL so ultimately we leverage 
> Dialect registered support for what the database does support.  However, we 
> encode "TRIM support" into the HQL grammar (in the rewrite) to make sure that 
> the arguments are handled consistently.  We do still expect each that the 
> Dialect as registered an appropriate SQLFunction representation of its TRIM 
> function support.  We could do something like that here as well.  The main 
> difference is that not all applications are using spatial.

It is true that not all applications use spatial, or even that DB’s support 
(all) spatial functions. But it would help to ensure consistency in the 
available dialects. Now this consistency is tested for in the integration 
tests, so not having this at the grammar isn’t a big problem. 

> 
> So more I am asking about syntax changes that might help support spatial 
> queries, specific operators, etc.  How about declaring "spatial literals"?  
> Does that make sense for spatial queries?

W.r.t operators: don’t the same concern about not all applications using 
spatial apply here as well? In any case, I don’t think operators are going to 
be popular. Just about everyone is happy to use the relevant spatial 
relationship functions. At least their names and semantics are pretty standard 
across implementations and technologies. There is to my knowledge no comparable 
standard for spatial symbolic operators.

Support for spatial literals would be a great plus. In my opinion, the best 
candidate for HQL spatial literals is the Postgis EWKT format 
(http://postgis.net/docs/manual-2.1/using_postgis_dbmanagement.html#EWKB_EWKT), 
which is a sane, and popular extension of the purely 2D WKT standard. It is  
supported in the geolatte-geom library and many others. I can help by writing a 
grammar for this.

There is also at least one HQL syntax change that would help implement spatial 
functions:  function invocations that evaluate to boolean should be regarded as 
valid boolean expressions. The HQL currently doesn’t seem to allow this, so I 
needed to wrap them in equality expressions. But then MySQL wouldn’t use its 
spatial index (as I wrote before, although I mistakenly wrote “spatial query” 
in my original email).

Regards,

Karel
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] HQL and spatial

[Karel Maesen]

Hi Steve,

Have a look at this table: 
http://www.hibernatespatial.org/documentation/03-dialects/01-overview/

It provides an overview of the HQL functions that are supported in Hibernate 
Spatial. They are  currently registered into each concrete SpatialDialect. I 
think it might be a good start to start having these functions integrated into 
HQL. 

These functions are commonly found in spatial databases because they have been 
defined in the Simple Feature Specification (SFS). The reference given after 
each function refers to this spec. This spec was originally intended to be used 
only for planar 2D geometries, but has been extended by most databases to apply 
also to 3D/4D and non-planer, i.e. geographic coordinates.

There is also the 'SQL/MM, Part 3' - Spatial specification. This spec is, as I 
understand it, derived from the Simple Feature Specification but adds support 
for more complicated geometries and for 3D/4D geometries. Not all databases 
have support for everything specified in there, and no open-source Java 
geometry library has either.

As for implementation, there are some weird cases.  For example, if you specify 
in MySQL (native SQL)  "select * from t where st_contains(geom1, geom2) = 1” 
the spatial query is not used, but it is used when the statement reads "select 
* from t where st_contains(geom1, geom2)”. Both should be equivalent. 

Another example. In Oracle10g the HQL spatial functions are translated to 
something like this:  "SELECT A.Feature_ID FROM TARGET A WHERE 
sdo_filter(A.shape, :theWindow,'querytype=window') = 'TRUE’;” 

The whole and only the whole expression ‘sdo_filter(...) = ‘TRUE’’ evaluates to 
TRUE. So leaving the “... = ‘TRUE’” part off or putting something else in 
there, fails to evaluate.

Hope this helps kick off the discussion.

Regards,

Karel




> On 26 Aug 2015, at 05:20, Steve Ebersole  wrote:
> 
> Karel, etal
> 
> We have discussed spatial-specific extensions to HQL for quite some time.
> But those discussions have always been kind of esoteric ("boy wouldn't it
> be nice to have some spatial support in HQL").
> 
> As we are working on redesigning the parsing and interpretation of HQL
> queries and since spatial has been integrated upstream, it seems like a
> great time to discuss specifics of what this might mean.
> 
> I have never used spatial data, let alone crafted queries using spatial
> data.  So I am not the best driver here.
> 
> What kinds of things make sense to add to HQL for supporting spatial
> queries?
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Problems running matrix tests

[Karel Maesen]

I’v tried to run my matrix tests for hibernate-spatial and I’m running into 
some problems.

First problem is that setting JAVA6_HOME on OS X didn't work because Gradle 
apparently can’t find the runtime jar (the Home layout of JDK 1.6 on Mac seems 
to be non-standard). I worked around that by pointing that variable to a JDK1.7.

Next problem is that I now get an exception when I run:
$ ../gradlew -Dhibernate-matrix-databases=`pwd`/databases 
-Dhibernate-matrix-ignore='mysql50,mysql51,postgresql82,postgresql83,postgresql84'
 tasks —stacktrace

The exception is: 
Caused by: org.gradle.api.internal.plugins.PluginApplicationException: Failed 
to apply plugin [id 'hibernate-matrix-testing']
at 
org.gradle.api.internal.plugins.DefaultPluginManager.doApply(DefaultPluginManager.java:160)
at 
org.gradle.api.internal.plugins.DefaultPluginManager.apply(DefaultPluginManager.java:112)
at 
org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.applyType(DefaultObjectConfigurationAction.java:113)
at 
org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.access$200(DefaultObjectConfigurationAction.java:36)
at 
org.gradle.api.internal.plugins.DefaultObjectConfigurationAction$3.run(DefaultObjectConfigurationAction.java:80)
at 
org.gradle.api.internal.plugins.DefaultObjectConfigurationAction.execute(DefaultObjectConfigurationAction.java:136)
at 
org.gradle.api.internal.project.AbstractPluginAware.apply(AbstractPluginAware.java:46)
at org.gradle.api.plugins.PluginAware$apply.call(Unknown Source)
at 
org.gradle.api.internal.project.ProjectScript.apply(ProjectScript.groovy:34)
at org.gradle.api.Script$apply.callCurrent(Unknown Source)
at 
hibernate_core_28emj67po4a3o66dseh0ycn0w.run(/Users/maesenka/workspaces/github/hibernate-core/hibernate-core/hibernate-core.gradle:8)
at 
org.gradle.groovy.scripts.internal.DefaultScriptRunnerFactory$ScriptRunnerImpl.run(DefaultScriptRunnerFactory.java:74)
... 91 more
Caused by: groovy.lang.MissingPropertyException: No such property: 
testReportDir for class: org.gradle.api.tasks.testing.Test_Decorated
Possible solutions: testReporter
at 
org.gradle.api.internal.plugins.ExtraPropertiesDynamicObjectAdapter.setProperty(ExtraPropertiesDynamicObjectAdapter.java:46)
at 
org.gradle.api.internal.CompositeDynamicObject.setProperty(CompositeDynamicObject.java:122)
at org.gradle.api.tasks.testing.Test_Decorated.setProperty(Unknown 
Source)
at 
org.hibernate.build.gradle.testing.matrix.MatrixTestingPlugin.prepareNodeTask(MatrixTestingPlugin.groovy:154)
at 
org.hibernate.build.gradle.testing.matrix.MatrixTestingPlugin.this$2$prepareNodeTask(MatrixTestingPlugin.groovy)
at 
org.hibernate.build.gradle.testing.matrix.MatrixTestingPlugin$this$2$prepareNodeTask.callCurrent(Unknown
 Source)
at 
org.hibernate.build.gradle.testing.matrix.MatrixTestingPlugin.apply(MatrixTestingPlugin.groovy:89)
at 
org.hibernate.build.gradle.testing.matrix.MatrixTestingPlugin.apply(MatrixTestingPlugin.groovy)
at 
org.gradle.api.internal.plugins.ImperativeOnlyPluginApplicator.applyImperative(ImperativeOnlyPluginApplicator.java:35)
at 
org.gradle.api.internal.plugins.RuleBasedPluginApplicator.applyImperative(RuleBasedPluginApplicator.java:43)
at 
org.gradle.api.internal.plugins.DefaultPluginManager.doApply(DefaultPluginManager.java:144)
... 102 more

Anyone an idea on what is going on here? I also tried to run this command on 
hibernate-core and it produced the same result. 

Regards,

Karel
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] problem running local matrix tests

[Karel Maesen]

It used to work fine until the matrix-testing support was moved to a separate 
project. 

On 12 Jun 2013, at 15:22, Steve Ebersole st...@hibernate.org wrote:

 Hmm, not sure about that one.  I'll have to look.  Did that work before?  I 
 see the code loading resources/hibernate.properties, but not generally 
 loading all stuff from resources.  And even then, I am not seeing the loaded 
 hibernate.properties being used atm.
 
 
 On Tue 11 Jun 2013 02:47:04 PM CDT, Karel Maesen wrote:
 
 I compiled it locally and the exception is no longer thrown.
 
 But now I have another problem. The generated matrix tasks have on their 
 class path only the jdbcDepency from matrix.gradle and the hibernate-core 
 classes and resources. The databases/database/resources directory is not 
 added so the db-specific hibernate.properties is not picked up. The result 
 is that all my matrix tests now run with the hibernate config of the unit 
 tests.
 
 
 On 11 Jun 2013, at 18:35, Steve Ebersole st...@hibernate.org wrote:
 
 You might be seeing 
 https://github.com/hibernate/hibernate-matrix-testing/pull/1
 
 I merged that pull request, but I have not built a new release and pulled 
 that into hibernate-orm yet.
 
 Could you try building it locally and integrating it into your local 
 hibernate-orm checkout?  If that works, I'll do that upstream. Really just 
 been looking for some validation that that fix really was a fix...
 
 On 06/06/2013 02:48 PM, Karel Maesen wrote:
 Hi,
 
 I have local database configurations for matrix testing against spatial 
 databases. With HHH-8235 support for matrix testing has been moved into  a 
 separate project. Unfortunately, this change broke my matrix tests. I now 
 get this error:
 
 Execution failed for task ':hibernate-spatial:matrix_postgis'.
 No such property: project for class: 
 org.hibernate.build.gradle.testing.database.alloc.DatabaseAllocator
 Anyone an idea what I'm doing wrong?
 
 Btw, I did update my Gradle file to include: apply plugin: 
 'hibernate-matrix-testing'.
 
 Regards,
 
 Karel Maesen
 
 
 ___
 hibernate-dev mailing list
 hibernate-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/hibernate-dev
 
 


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] problem running local matrix tests

[Karel Maesen]

Hi, 

I have local database configurations for matrix testing against spatial 
databases. With HHH-8235 support for matrix testing has been moved into  a 
separate project. Unfortunately, this change broke my matrix tests. I now get 
this error:

Execution failed for task ':hibernate-spatial:matrix_postgis'.
 No such property: project for class: 
 org.hibernate.build.gradle.testing.database.alloc.DatabaseAllocator

Anyone an idea what I'm doing wrong? 

Btw, I did update my Gradle file to include: apply plugin: 
'hibernate-matrix-testing'.

Regards,

Karel Maesen


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

[Karel Maesen]

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.29d)
   .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 
 

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

[Karel Maesen]

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 Spatial in Hibernate 
Core, you could bring in explicit spatial types (Coordinates, Points or 
others). In that way we can make sure that the use of spatial types and 
concepts are at least consistent between HSearch and HSpatial.

Btw, I was thinking of adding to geolatte-geom (my JTS alternative) explicit 
classes for geographic geometries. 

Regards,

Karel


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [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 emman...@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] Problem using maven 2.2.1

[Karel Maesen]

Hi,

When using mvn install on Hibernate Core, the jar was copied to my local 
repository with the extension *.docbook.style.

When I uncomment the jdocbook-style-plugin in the parent pom.xml, the install 
works correctly. Also when I use maven 2.2.0.  So I guess the jdocbook-style 
plugin doesn't currently work correctly with maven 2.2.1?

Regards,

Karel 
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev