There are instructions on how to sign up for "xircles" (CodeHaus single
sign on) which should allow you to open a ticket.
http://docs.geotools.org/latest/userguide/welcome/support.html#issue-tracker
Jody Garnett
On Wed, Aug 6, 2014 at 1:10 PM, Jim Hughes <[email protected]> wrote:
> 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]> 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]>
>>
>> To:
>> "Jim Hughes" <[email protected]>
>> Cc:
>> "GeoTools Developers list" <[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]> 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