I think the consensus is; Let's not hold up the 2.1 release for GeoSpatial
Query support, as we seem to need more time to flesh out how to integrate
this efficiently, and possibly take into account the Java 8 benefits, that
we get with a 3.0 release.
So, I am trying to move forward with a 2.1 rele
Evtl. here the usage of the spatial extension :
https://github.com/apache/zest-qi4j/blob/ramtej-fb/spatial.queries/core/testsupport/src/main/java/org/qi4j/test/indexing/AbstractSpatialRegressionTest.java
Cheers,
jj
2015-06-11 13:39 GMT+02:00 Niclas Hedhman :
> Ah, I see... This would allow the
Ah, I see... This would allow the "Module" handling to be preserved if
necessary, and makes sense to me.
There is already a QueryBuilderSPI class, but not sure how it works (or is
not in use).
The Spatial Query stuff sits in a separate branch. See
https://github.com/apache/zest-qi4j/tree/ramtej
Actually I was not thinking of QueryBuilderFactory as a decoupled
service, but rather as a SPI like EntityFinder.
Something like
/public interface SolrQueryService extends EntityFinder,
StateChangeListener, QueryBuilderFactory, ServiceComposite//
//public interface SQLIndexingEngineService exte
Hi Kent,
"So a possible design could be to simply break out the querybuilder API's
form core. No more, no less."
Interesting approach.. Right now the Query Specifications are in the Core
and therefore
the spatial stuff is added there as well together with "custom" spatial
types that mimics
the g
Kent,
Nice to hear your refreshing input. Perhaps you have a very strong point.
Lng ago, the Query and Storage was more intertwined (days before
org.qi4j.api.property.Property and we tried to do pojo-style "properties")
than it is today, and perhaps we stopped that separation "too early" and
ev
While I agree that the goal of decoupling the query part from core is a
worthy one, I fail to see what UnitOfWorkFactory has to do with that.
Decoupling the UnitOfWork may or may not make sence, but I think that is
another discussion - which could make sense eg. if you wish to integrate
a Zest app
Hello Niclas
Thanks for your email. There is no worry, we understand very well the
wish to keep the amount of dependencies low in the core. SIS is doing
the same. Indeed, a geospatial dependency in Zest could quickly become
many megabytes in size given how complex geospatial can be.
Regard,
Sorry typo...
s/and can easily integrate with GeoAPI/and can't easily integrate with
GeoAPI/
On Sat, Jun 6, 2015 at 11:59 AM, Niclas Hedhman wrote:
>
> Martin & SIS community,
>
> A clarification about the dependency in my first paragraph to the Zest
> community;
> We want to support geospatial
Martin & SIS community,
A clarification about the dependency in my first paragraph to the Zest
community;
We want to support geospatial querying. But querying is at the moment an
integral part in the Zest/Qi4j Core runtime. And we have been striving to
remove dependencies in Core, and have all of
Thanks Martin, that gives a nice overview of the situation (you should
plaster that on frontpage)...
Zest gang,
So, I think our challenge is to be able to introduce Geospatial
indexing/querying, without introducing a dependency.
What do I mean by this?
Well, we already have another "Custom Query
Thanks Chris for getting Zest and SIS in touch. I just finished reading
the thread. There is some tips for information purpose:
Niclas Hedhman wrote:
> So, IF SIS are primarily based around interfaces, then that would be
> great and we can possibly leverage quite a bit, especially at what we
> ca
It is difficult to have a co-existing world for this, since it is part of
the Core itself, which is Java 7.
We could allow libraries of Java 8 only to be added, but must be able to
co-exist with a Java 7 Core. So, the Builders that i pulled out to
libraries/geometry (which perhaps should be in lib
Hi Niclas,
Regarding samples - there are spatial regression tests
at AbstractSpatialRegressionTest.java.
Indeed closures can help a lot to defined/structure a query DSL. Do you
have already something concrete in mind ? Do you think on a kind of
co-existence of the new/old approach ?
Cheers,
jj
M
To: "dev@zest.apache.org"
Subject: Re: GeoSpatial Query support
>Hi Adam & Chris,
>
>some notes on the Zest spatial implementations. It is in general
>structured
>in three main components :
>
>1.) Zest core that defines spatial values, like TPoint, TPolygon,
It has been good to see these examples, and I realize that the Java 8
closures could help a lot,
It seems that Java 8 closures could help a lot to define the DSL, and
maybe(!) that is a strong enough reason to defer the geospatial inclusion
until 3.0, so we can make it "right" from the beginning,
Hi Niclas,
hmm, yes I;m using the expression like
module.newValueBuilder(TMultiPoint.class).prototype();
in the TXXXBuilders. I was not aware that this is not supported. I try to
understand
the "deep" secrets of Zest type approach, but this is pretty hard to get...
I think it should be fine to
++
> > Adjunct Associate Professor, Computer Science Department
> > University of Southern California, Los Angeles, CA 90089 USA
> > ++++++++++++++
> >
> >
> >
> >
> > -Original Message-
> &
t
>>>> Instrument Software and Science Data Systems Section (398)
>>>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
>>>> Office: 168-519, Mailstop: 168-527
>>>> Email: chris.a.mattm...@nasa.gov
>>>> WWW: http://sunset.usc.edu/~mattmann/
>>>&g
++
>>> Adjunct Associate Professor, Computer Science Department
>>> University of Southern California, Los Angeles, CA 90089 USA
>>> ++
>>>
>>>
>>>
>>>
>>>
9 USA
++
-Original Message-
From: Jiri Jetmar
Reply-To: "dev@zest.apache.org"
Date: Wednesday, June 3, 2015 at 7:45 AM
To: "dev@zest.apache.org"
Subject: Re: GeoSpatial Query support
Hi Niclas,
th
nia, Los Angeles, CA 90089 USA
> > ++
> >
> >
> >
> >
> > -Original Message-
> > From: Jiri Jetmar
> > Reply-To: "dev@zest.apache.org"
> > Date: Wednesday, June
Let's decide that a little bit later...
Another anomaly that I notice everywhere;
return module.newValueBuilder( TPoint.class ).prototype();
This is invalid (read unstable/unsupported) use of prototypes, since you
don't instantiate them. Is it because you where unsure of the
TransientComposite
ginal Message-
> From: Jiri Jetmar
> Reply-To: "dev@zest.apache.org"
> Date: Wednesday, June 3, 2015 at 7:45 AM
> To: "dev@zest.apache.org"
> Subject: Re: GeoSpatial Query support
>
>> Hi Niclas,
>>
>> this ST_XX follows the http://en.wikip
, CA 90089 USA
++
-Original Message-
From: Jiri Jetmar
Reply-To: "dev@zest.apache.org"
Date: Wednesday, June 3, 2015 at 7:45 AM
To: "dev@zest.apache.org"
Subject: Re: GeoSpatial Query support
>H
Hi Niclas,
this ST_XX follows the http://en.wikipedia.org/wiki/DE-9IM and
http://en.wikipedia.org/wiki/Simple_Features standards that are indeed
"SQL" related. I used this expression to be similar with e.g. PostGIS,
means when someone knows how to use spatial expressions on PostGIS,
he should be a
26 matches
Mail list logo
