Hi Jody,

Thanks for the fast turn away; a back port to stable branches would be
great.  Lemme know if I can help with that.  

I was actually asking about something a little different from
reprojection.  Since each Accumulo table effectively has one index,
I'm working on tearing apart ECQL filters so that I can use their
spatial, temporal, and attribute predicates differently.  We ran into
this issue since I pulled out temporal filters on the client-side and
needed to send them to the server-side.

As a general follow-up, since there are a number of DataStore
implementations, has anyone cooked up a general DataStore 'integration
test'?  I could imagine such a test being really, really helpful to
see the status of a project like GeoMesa.  

Thanks again!

Jim

----- Original Message -----
From: "Jody Garnett" 
To:"Jim Hughes" 
Cc:"GeoTools Developers list" 
Sent:Fri, 1 Aug 2014 10:42:26 -0700
Subject:Re: [Geotools-devel] ECQL temporal filter question

Hi Jim, 
 Thanks for the pull request, looks fine to me (the test cases help),
think you made a good call about printing the extra info if present.

 Serialising by ECQL is fine, the XML format is more verbose, but can
be used to smuggle additional information along for the ride.

 As for a better way: I had my heart set on a "transform" addition to
GeoTools Query for the GeoMesa [1] project. This would express a bit
of the processing involved in reprojection more clearly in the filter
syntax. The result is an expression for each attribute in the final
data product, making it easier to split work up. Sadly that
development team did not come back geotools-devel before the 12.x code
freeze. Hopefully with time/talent/money the idea will be put back on
the table. 

Jody Garnett 

On Fri, Aug 1, 2014 at 5:22 AM, Jim Hughes  wrote:
  Thanks Jody,

 I've put up https://github.com/geotools/geotools/pull/519 [3].  I'm
a little unsure how much of the tests it made sense to duplicate. 
Also, given that the current behavior is to truncate Dates to the
second, I figured it was reasonable to print the extra info if it is
present, but otherwise to act the same.

 By the way, my use case involves splitting up ECQL filters and giving
pieces of the filter to various Accumulo iterators.  If there is a
better way to be serializing and deserializing parts of an ECQL query,
I'm open to doing things a better way.

 Thanks in advance,

 Jim 

On 07/31/2014 07:35 PM, Jody Garnett wrote:
  My three questions are  
   1.  Is it reasonable to expect that ECQL.toCQL/toFilter should be
inverses?

 If it is reasonable if you supply a patch :) I figured it was
reasonable and patched a couple of gaps
here: https://jira.codehaus.org/browse/GEOT-4783 [4]  
 In particular you can review the
patch 
https://github.com/geotools/geotools/commit/649853a304a4779ed86121151193ea0fe049f367
[5] to see how I handled recognising part of a filter as being
representable as ECQL, and then creating a method to output the ECQL. 
         if (isInFilter(filter)) {             return
buildIN(filter, extraData);        }          // default to
normal OR output        return
FilterToTextUtil.buildBinaryLogicalOperator("OR", this, filter,
extraData);  
    2.  If my issue is a bug, can I submit a PR, etc?  Is
there documentation about that process?

 Yep, there is a CONTRIBUTING.md [6]file (which is shown as a link
when you issue a github pull request).  Or see the home page about
getting involved [7]. 
  3.  Has anyone else run into this?  Is there a well-known
work-around?

 I don't think many people rely on ECQL.toCQL/toFilter being
invertible. So lets just get it done. 
 -- Jody      

 

Links:
------
[1] http://geomesa.github.io
[2] mailto:[email protected]
[3] https://github.com/geotools/geotools/pull/519
[4] https://jira.codehaus.org/browse/GEOT-4783
[5]
https://github.com/geotools/geotools/commit/649853a304a4779ed86121151193ea0fe049f367
[6] https://github.com/geotools/geotools/blob/master/CONTRIBUTING.md
[7] http://geotools.org/getinvolved.html

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to