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 Wed, 03 Jun 2015 20:47:28 GMT
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
>

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