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 Sat, 06 Jun 2015 04:00:51 GMT
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 <niclas@hedhman.org> wrote:

>
> 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
>



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

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