I think I realize that there are several aspects to this; 1. Scope at hand; Query geodata stored in Zest (so called) entity stores, back by one or more capable Indexing engines. Zest defines a fluent api, query language independent, which is translated in runtime to the underlying indexer.
2. Retrieving geo data from external sources, and interfacing with third-party endpoints for that. This is currently a bit out of scope, but this sounds like easy stuff to integrate into Zest, once there is an interest for it. Cheers On Wed, Jun 3, 2015 at 11:26 PM, johann sorel <[email protected]> wrote: > Hello, > > In geotoolkit we made a query/session api, with joint support, It uses : > - OGC Filter Encoding specification, > - SQL/MM(st_...) are just a a set of functions which are the exact same as > those defined in OGC Filter. > - A derivate of JSR-283 : Java Content Repository for queries and > sessions but adapted to Features > http://www.opengeospatial.org/standards/filter > > This specification is already transposed in Java in the GeoAPI project : > http://www.geoapi.org/snapshot/pending/index.html > in package : org.opengis.filter > > I don't know much about apache zest, but a more pragmatic approach would > be to get closer to Apache JackRabbit which is JCR compliant and has a lot > of data connectors. > > > Johann Sorel > [email protected] > > > > On 03/06/2015 17:12, [email protected] wrote: > >> Most excellent, Dr. Mattmann! @sis, we should definitely collaborate with >> @zest on this one. If they are implementing simple query functionality, >> maybe they can take advantage of the work Marc has already done and also >> use the projection support Martin has been committing. >> >> Thoughts? >> Adam >> >> Sent from my iPhone >> >> On Jun 3, 2015, at 11:00 AM, Mattmann, Chris A (3980) < >>> [email protected]> wrote: >>> >>> Maybe this is a good integration point for sis.apache.org? >>> >>> CC’ing the Apache SIS list for visibility >>> >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> Chris Mattmann, Ph.D. >>> Chief Architect >>> Instrument Software and Science Data Systems Section (398) >>> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA >>> Office: 168-519, Mailstop: 168-527 >>> Email: [email protected] >>> WWW: http://sunset.usc.edu/~mattmann/ >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> Adjunct Associate Professor, Computer Science Department >>> University of Southern California, Los Angeles, CA 90089 USA >>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>> >>> >>> >>> >>> -----Original Message----- >>> From: Jiri Jetmar <[email protected]> >>> Reply-To: "[email protected]" <[email protected]> >>> Date: Wednesday, June 3, 2015 at 7:45 AM >>> To: "[email protected]" <[email protected]> >>> Subject: Re: GeoSpatial Query support >>> >>> 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 <[email protected]>: >>>> >>>> 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
