polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jiri Jetmar <juergen.jet...@gmail.com>
Subject Re: GeoSpatial Query support
Date Thu, 04 Jun 2015 20:18:25 GMT
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

2015-06-04 0:24 GMT+02:00 Niclas Hedhman <niclas@hedhman.org>:

> 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, without worrying
> of two different syntaxes?
>
> If so, we should collaborate to formulate such a DSL, without too much
> concern over the existing work. It can really make things a lot less
> verbose.
>
>
> Cheers
>
> On Thu, Jun 4, 2015 at 4:47 AM, Jiri Jetmar <juergen.jetmar@gmail.com>
> wrote:
>
> > 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 fix it in the TXXXBuilders in the
> > "org.qi4j.api.geometry.internal.builders"
> > package as in *all* other cases the builders are used to create spatial
> > types. I;m not 100% sure here,
> > but the reason to introduce the TXXXBuilders is the fact that spatial
> types
> > tend to be complex in terms
> > of definition :
> >
> >                 ValueBuilder<TLinearRing> builder =
> > module.newValueBuilder(TLinearRing.class);
> >         assertNotNull(
> >                 builder.prototype().of
> >                         (
> >
> > module.newValueBuilder(TPoint.class).prototype().of
> >                                         (
> >
> > module.newValueBuilder(Coordinate.class).prototype().of(1d),  //x
> >
> > module.newValueBuilder(Coordinate.class).prototype().of(1d)   //y
> >                                         )
> >                                 ,
> >
> > module.newValueBuilder(TPoint.class).prototype().of
> >                                         (
> >
> > module.newValueBuilder(Coordinate.class).prototype().of(2d),  //x
> >
> > module.newValueBuilder(Coordinate.class).prototype().of(2d)   //y
> >                                         )
> >
> >                         )
> >         );
> >
> > versus
> >
> >        TLinearRing ring = TLinearRing(module).ring(new double[][]
> >                 {
> >                         {0, 0},
> >                         {1, 0},
> >                         {1, 1},
> >                         {0, 1},
> >                         {0, 0}
> >                 }).geometry();
> >
> > Let me know how I can support you on this topic.
> >
> > Thank you.
> >
> > Cheers,
> > jj
> >
> >
> >
> > 2015-06-03 17:42 GMT+02:00 Niclas Hedhman <niclas@hedhman.org>:
> >
> > > 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
> > > TransientComposites or how/when to make them into ValueComposites. I
> > > recommend that Values are used, due to the nature of the datatypes, but
> > > right now, they are broken... Any comments before I fix the rest
> (already
> > > sorted out the many Builders)?
> > >
> > > Cheers
> > >
> > > On Wed, Jun 3, 2015 at 10:45 PM, Jiri Jetmar <juergen.jetmar@gmail.com
> >
> > > wrote:
> > >
> > > > 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 able to understand the Apache Zest approach.
> > > >
> > > > But clearly I can "lowercase" the ST_Xx expressions in the code.
> > > >
> > > > Cheers,
> > > > jj
> > > >
> > > > 2015-06-03 16:22 GMT+02:00 Niclas Hedhman <niclas@hedhman.org>:
> > > >
> > > > > Jiri,
> > > > > There is one thing that bothers me; ST_Within and similar doesn't
> > > follow
> > > > > the Java convention at all. I have researched and seen that many
> DBs
> > > uses
> > > > > this, but don't you think we should lower case st_ instead for
> > methods?
> > > > >
> > > > >
> > > > > Cheers
> > > > > --
> > > > > Niclas Hedhman, Software Developer
> > > > > http://zest.apache.org - New Energy for Java
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Niclas Hedhman, Software Developer
> > > http://zest.apache.org - New Energy for Java
> > >
> >
>
>
>
> --
> Niclas Hedhman, Software Developer
> http://zest.apache.org - New Energy for Java
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message