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 <[email protected]> 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 <[email protected]> > 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 < >> [email protected]> 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
