Yes, you have a good point there about the performance because otherwise
canHandle and evaluate are basically doing two times the same thing (the
only way to check if the x-path points to a valid property is by trying
to evaluate it).
However, considering the API I'm not sure if you're right.
Sounds good; one clarification for performance considerations.
I am not sure the API will let you check the x-path against the feature or
feature type; the canHandle method is supposed to be fast; and should just
check that the xpath expression is valid.
You will need to check that the xpath po
Hi,
Thanks for the advice.
So my plan of attack will be:
1. Implement the 'canHandle' of class 'XPathPropertyAcessor' to make it
return false when the x-path doesn't resolve to a property
2. Throw an exception in AttributeExpressionImpl.evaluate if no property
accessor can be found.
3. Go th
I expect that JD (ie Justin's) comment was with respect to preserving
compatibility with the existing test cases when transitioning to the
GeoTools 2.3 Filter implementation (ie with Property Accessors).
Now that the transition is mostly completed; throwing a good
exception is possible (but some
I think you could throw an exception there; and update the geotools test cases.
Jody
On Thu, Sep 2, 2010 at 4:02 PM, Niels wrote:
> Hi,
>
> I am a new geotools developer who just started working on app-schema for
> CSIRO last week.
> I was asked to look at this problem:
> http://jira.codehaus.or
We have not had the policy of deprecating unsupported modules; but I
could see the point of deprecating modules that are on their way out
because a replacement is ready.
Due to our plugin system there is not much opportunity for code to
depend directly and thus see deprecation warnings.
Ideas:
-
Hi all,
Since there were no objections i am going to start the release train. If
something does come up let me know and i can stop.
-Justin
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
Ok, looks like running with java 5 the tests pass.
On Thu, Sep 2, 2010 at 8:13 AM, Justin Deoliveira wrote:
> Hmmm... oddly enough if i run the tests directly from the module everything
> passes. If however i run the tests as part of the full build i get the
> failure.
>
> I also notice i was run
[Patch] Shapefile handling is broken for 3D shapefiles
--
Key: GEOT-3259
URL: http://jira.codehaus.org/browse/GEOT-3259
Project: GeoTools
Issue Type: Bug
Components: data shapefil
2010/8/31 Jody Garnett :
> I remember us having this discussion earlier in the year; I will go ahead and
> move those two over.
> Jody
>
> On 31/08/2010, at 5:25 PM, Jody Garnett wrote:
>
>> I am writing up some docs (actually listing the formats supported by
>> geoserver) and decided to go back t
Hmmm... oddly enough if i run the tests directly from the module everything
passes. If however i run the tests as part of the full build i get the
failure.
I also notice i was running with java 6. Could be the issue. Going to try
and drop back to java 5 and see if that changes anything.
-Justin
Hello Justin,
I just have run "mvn clean install -Pextensive.tests" in my
geotools/trunk/modules/plugin/imagepyramid folder, build is
successfull on Java 1.6.0_20 and Java 1.5.0_24. I'm using Mac Os X
10.6.4.
Emiliano
On Thu, Sep 2, 2010 at 12:41 AM, Justin Deoliveira wrote:
> Running on a ma
Hi Justin,
Emiliano has a Mac. I have just asked him to try a build with
extensive.tests.
Daniele
On Thu, Sep 2, 2010 at 12:41 AM, Justin Deoliveira wrote:
> Running on a mac
>
> referencing:
> WarpTransformTest
>
> feature-pregeneralized:
> ShapeFilePreGeneralizedFeatureSourceTest
>
> image
Hi Justin,
we have local gt trunk changes for testing purposes which leverage on
imageio-ext 1.1.X (dealing with GDAL 1.7.2) which is actually used in
benchmarks.
However, for the proposed release, I think we should still depend on 1.0.7.
Aime, what do you suggest about this?
Cheers,
Daniele
On W
14 matches
Mail list logo
