Jody,
I tried to report the issue in Jira; do I need an account? I setup a
Codehaus as 'jnh5y' with this e-mail address.
If there were a general test, I imagine one could test the DataStore
interface rather than that ContentDataStore interface/abstract
implementation. (For GeoMesa, we ended up going with the Abstract**
implementations since some class element had too restrictive of
permissions at one point.)
Anyhow, is a back-port to the 11.x series possible? In reality, that
likely only matters if the 11.3 release will come before the 12.0 release...
Thanks,
Jim
On 08/01/2014 02:38 PM, Jody Garnett wrote:
Actually there is something you could do to help. Create a bug ticket
so this change can show up in our release notes :)
There is examples of how to do a common integration test - see how
JDBCDataStore does it. Other than that we had a set of tests form
MemoryDatastore that have been copied into each implementation and
customised.
There was a bug about setting up a common "ContentDataStore" test
suite - but I cannot seem to find it. It is a great idea if you would
like to work on it.
Jody Garnett
On Fri, Aug 1, 2014 at 11:29 AM, James Hughes <[email protected]
<mailto:[email protected]>> wrote:
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" <[email protected]
<mailto:[email protected]>>
To:
"Jim Hughes" <[email protected] <mailto:[email protected]>>
Cc:
"GeoTools Developers list"
<[email protected]
<mailto:[email protected]>>
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
<http://geomesa.github.io> 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 <[email protected]
<mailto:[email protected]>> wrote:
Thanks Jody,
I've put up https://github.com/geotools/geotools/pull/519.
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
In particular you can review the patch
https://github.com/geotools/geotools/commit/649853a304a4779ed86121151193ea0fe049f367
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
<https://github.com/geotools/geotools/blob/master/CONTRIBUTING.md>file
(which is shown as a link when you issue a github pull
request). Or see the home page about getting involved
<http://geotools.org/getinvolved.html>.
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
------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
GeoTools-Devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
