Gertjan van Oosten ha scritto:
> As quoted from Gertjan van Oosten <[EMAIL PROTECTED]>:
>> The final statement in this code fragment:
>>
>> final Calendar cal = Calendar.getInstance(TimeZone.getTimeZone("UTC"));
>> cal.set(Calendar.YEAR, 2000);
>>
>> final FeatureSource source = data.getFeatureSource(typeName);
>> final FilterFactory ff =
>> CommonFactoryFinder.getFilterFactory(GeoTools.getDefaultHints());
>> final Expression left = ff.property("timestamp");
>> final Expression right = ff.literal(cal);
>> final Filter filter = ff.greaterOrEqual(left, right);
>> final SortBy sort = ff.sort("timestamp", SortOrder.DESCENDING);
>> final DefaultQuery query = new DefaultQuery("features", filter);
>> query.setSortBy(new SortBy[] { sort });
>>
>> final FeatureCollection fc = source.getFeatures(query);
>> final boolean empty = fc.isEmpty();
>
> I did some more investigating, and it also fails if I use a simple
> filter on a text field like:
>
> final Expression left = ff.property("name");
> final Expression right = ff.literal("test");
> final Filter filter = ff.equals(left, right);
>
> final FeatureCollection fc = source.getFeatures(filter);
> final boolean empty = fc.isEmpty();
>
> It still throws
> java.lang.IllegalArgumentException: Property 'name' could not be found in
> features
>
> As I said:
>
> final FeatureCollection fc = source.getFeatures();
> final boolean empty = fc.isEmpty();
>
> i.e. without a filter, works and returns all features. *With* a filter
> however, it fails. If I use tcpdump to check what goes over the wire to
> the PostGIS data store, I don't see any SQL query being sent (without
> the filter I do). The last thing that gets over the wire is:
>
> SELECT srid FROM geometry_columns WHERE f_table_schema='public' AND
> f_table_name='features' AND f_geometry_column='geom'
>
> and the answer comes back with an srid of 4326. After that, nothing...
> So it appears it isn't actually querying the database but just throws
> the exception.
This is indeed what's happening. Things are like this: we do support
whatever filter is in the OGC spec in every datastore, but not
all datastore can do those filters natively.
The solution is to take the filter and split it into a pre-filter
that can be natively encoded, and a post filter that is run into
memory (for the part that cannot be encoded).
In your case the filter splitter is chocking, but I don't know
why, that's the issue...
The only person left that knows about the magic of the filter splitter
is Saul, which I've cc'ed.
> Is there a way to get some debug logging out of gt2 to
> see what goes on?
Unfortunately gt2 uses java logging, and the way to alter log settings
are between the stupid and the arcane (imho).
You either have to alter a system wide property file that will affect
all of your java apps
(http://java.sun.com/j2se/1.4.2/docs/guide/util/logging/overview.html#1.8)
or set a system variable to point to your custom property file (which
is virtual machine wide), see some notes at the end of this article:
http://www.oracle.com/technology/pub/articles/hunter_logging.html
"You can override the global values by editing this file, but I don't
recommend changing Java's global defaults. It's better to make changes
locally by setting the java.util.logging.config.file system property to
point at a properties file of your own choosing like this:
java -Djava.util.logging.config.file=mylogging.properties Main
You can use the logging.properties global file as a starting point for
your own. "
Hope this helps
Cheers
Andrea
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
