polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: GeoSpatial Query support
Date Wed, 03 Jun 2015 22:24:41 GMT
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