Mailing-List: contact dev-help@zest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@zest.apache.org
MIME-Version: 1.0
Sender: hedhman@gmail.com
In-Reply-To: 
 <CADmm+Kc3wk3iH8J-DVK_0WgvjpVSXmw64SZArhaOj1V+G_sUog@mail.gmail.com>
References: 
 <CADmm+Ket4yaL+5HMkSMP2Z649PO9gGyeJ4CQ7V0eSA++dfYbMw@mail.gmail.com>
 <CAH+CGsK_Z5iXXEB=LX4jC1zDDhLTm8mLYpr-ouOoHoqC8YP9dg@mail.gmail.com>
 <D194646F.11785A%chris.a.mattmann@jpl.nasa.gov>
 <EC53BFF6-1B9C-4A25-9199-DB2550AC73B6@gmail.com>
 <CAH+CGs+5K_7w_nXycgAt5zcJRF3cx4AUagm=t5UGc5L+cyFSmQ@mail.gmail.com>
 <D1953283.117B80%chris.a.mattmann@jpl.nasa.gov>
 <55716472.8080109@geomatys.com>
 <CADmm+Kc3wk3iH8J-DVK_0WgvjpVSXmw64SZArhaOj1V+G_sUog@mail.gmail.com>
From: Niclas Hedhman <niclas@hedhman.org>
Date: Sat, 6 Jun 2015 11:59:34 +0800
Message-ID: 
 <CADmm+Kd9C-3jF3JpyvmiqSS_7pvdtiZS0Sumriv3YQdZVkpu-w@mail.gmail.com>
Subject: Re: GeoSpatial Query support
To: dev <dev@zest.apache.org>
Cc: dev <dev@sis.apache.org>
Content-Type: multipart/alternative; boundary=047d7bd757580174690517d171b3

--047d7bd757580174690517d171b3
Content-Type: text/plain; charset=UTF-8

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 those sitting in
Libraries(used by user code) or Extensions (used by Core Runtime).

The current work, done for a project and contributed back, is therefor
having its own interfaces for the data types, and can easily integrate with
GeoAPI interfaces, and probably not that easy with SIS down the line. It is
this restriction that I want to overcome, i.e. no new dependency in Core,
yet still allow GeoAPI types to be used in Indexing/Querying subsystem.

I hope that makes more sense, than the previous very terse sentence which
assumed familiarity with Zest mantra and vision.

One more thing; Zest is not a Geo-related project per se, so don't expect
me (and most the others) to understand your world ;-)


Cheers
Niclas


On Sat, Jun 6, 2015 at 11:41 AM, Niclas Hedhman <niclas@hedhman.org> wrote:

>
> 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" type, the Lucene free-text
> search, which couldn't be fitted nicely into the very nature of the
> UnitOfWork/QueryExpressions/QueryBuilder system.
>
> So let's hypothesize about;
>   * Ability to introduce new indexable data types,
>   * Ability to introduce extensions to the Query DSL
>   * Ability to extend the Indexing/Query extension itself.
>
>
> Where is the root of this system? Well, it all begins in the UnitOfWork.
> So, one possibility would be to disconnect UnitOfWorkFactory from the
> Module itself, and have a ServiceComposite for the UnitOfWorkFactory. Once
> the UnifOfWorkFactory implementation is outside the Core Runtime, so is
> UnitOfWork and everything that derives from it. It SHOULD mean that all
> parts could be Composites, in which case we can add arbitrary methods to
> them, the static methods of QueryExpressions could go away and probably
> other, yet to be discovered, benefits.
>
> Granted, it won't be common for users to create their own, but having this
> possibility, without becoming incompatible and without introducing
> dependencies in the Core, seems to me to be worthwhile going down this
> route. Having such a major part of the Core to be on the "Composite-side of
> things", might open up more cool ideas...
> It also feels "right" along our habit of breaking things out of Core and
> moving towards more modularity.
>
> On paper, it sounds reasonably easy to do this, but I bet the devil is in
> the details. Maybe an impossible circular dependency will arise, or
> something to that extent.
>
>
> Any thought on this?
>
>
> Cheers
>
> On Fri, Jun 5, 2015 at 4:57 PM, Martin Desruisseaux <
> martin.desruisseaux@geomatys.com> wrote:
>
>> 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
>> > call "Library" level, i.e. not part of the Core runtime itself, which
>> > we try to keep free of dependencies
>> The core part of SIS is defined by a set of interfaces provided by a
>> separated project: http://www.geoapi.org/. GeoAPI consists of only
>> interfaces, except some classes for Exception, Enum and "CodeList"
>> (similar to Enum but extensible). GeoAPI is based on some international
>> standards published jointly by the Open Geospatial Consortium (OGC) and
>> International Organization for Standardization (ISO). It currently
>> covers only a small part of OGC standards, but this includes map
>> projections.
>>
>> Apache SIS is a GeoAPI 3.0 implementation. The GeoAPI project provides
>> also implementations as wrappers around Proj.4 (the C/C++ library used
>> by GDAL) and the UCAR NetCDF library. All those projects have advantages
>> and inconvenient (e.g. Proj.4 supports a wider range of map projections
>> than SIS, but SIS is more compliant with OGC/ISO standards). But if Zest
>> depends directly on only GeoAPI interfaces you would have the freedom to
>> change implementation. However I do not know if Spatial4J would be
>> interested to implement GeoAPI interfaces.
>>
>> On geometry and indexing, there is no satisfying solution on GeoAPI side
>> yet. In particular, geometries are defined by the ISO 19107
>> international standard, which is currently under revision. This will
>> have a deep impact on GeoAPI once the ISO revision will be completed.
>>
>> Please let us know if you would like to explore further (e.g. how to
>> apply a map projection using the API defined by GeoAPI).
>>
>>     Martin
>>
>>
>
>
> --
> Niclas Hedhman, Software Developer
> http://zest.apache.org - New Energy for Java
>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

--047d7bd757580174690517d171b3--