Zekeng liang wrote:
> Hi
> I want to know how to use two filters for one FeatureSource. e.g. use
> one filter for extracting part of the whole map data, and use another
> filter to separate different kinds of objects(say roads and buildings)
> of this specific map data??
Ofthen the roads and buildings are from two different feature sources.
But your point is taken ...
I assume you have read:
<http://docs.codehaus.org/display/GEOTOOLS/Filters&gt;
<http://docs.codehaus.org/display/GEOTOOLS/The+shapefile+filter+tool+Example&gt;
Make two requests:
- bboxFilter AND attribute="road"
- bboxFilter AND attribute="building"
Or make one request and filter after the fact by hand - Filter has an
accepts( Feature ) method

Hi
I want to know how to use two filters for one FeatureSource. e.g. use one
filter for extracting part of the whole map data, and use another filter to
separate different kinds of objects(say roads and buildings) of this
specific map data??
thanks
zekeng
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Hello everybody.
Being new to geotools and to this mailing list (indeed I started working =
with this tool today) I have a question. I hope, it hasn't been answered =
recently or is much to stupid, but with so much documentation I don't =
even know where to search beside the java docs and the tutorial code.
I need to know whether a given rectangle is completely inside one (or =
more) features of a given set. The feature list is available from a WFS, =
the rectange is given by it's corners.
I'm already able to gather the features (using a feature reader) from =
the server.
From the WFS doc's I learned, that there is a way to query the searched =
features using a filter expression with the "GetFeature"-request but I =
assume composing the URL directly is not the right approach with GT.
I found the object family around the filter object but am unable to =
deduce it's usage from the documentation and found some hints that these =
filters can be used to query the WFS.
Another approach would be to walk the feature list at the client side =
and inspect each feature for a hit. Also I assume that this could be =
nicely done by using filters but how?
So what is the best approach to solve this problem.
Any hint, also to some documentation that deals with this issue or a to =
recent thread from the mailing list, would be helpful.
Thanks in advance and best regards
Gerhard D=FCnnebeil

Vermeij@... wrote:
>>Oh? It is because a Filter isA Expression. They have the same API.
> You're not saying that a Filter isA Expression only because they
> "happen" to have the same API, do you? To me, on a conceptual level, a
> Filter isNotA Expression. A Filter filters. An Expression calculates
> something.
Yeah I can see it that way too. My other motivation is that:
a) they are in the same spec
b) they share a common Factory
c) you need a common visitor to evaluate a filter
But we can answer all of that:
a) The fact that a the Filter is the main consumer of Expression may
just be considered an accident of history (or specification). I can
think of more uses for Expression. Indeed use see the reuse of
Expression in the SLD spec
b) Common factory - blame the spec where you need to parse a Filter document
c) evaluation of expression could be factored out and used by the
various filters
> A Filter can be implemented by delegating to an Expression. But the
> Filter interface should not make it mandatory to do that, in my opinion.
> There is no inherent relationship between Filters and Expressions.
>
> What about this for the Filter interface. I do not like the boolean
> result type very much, it is only by convention that I can now what true
> means ('yes, filtered out' or 'yes, passes filter')
> ---
> import org.geotools.feature.Feature;
>
> public interface Filter
> {
> enum Result {reject, admit};
>
> Result filter (Feature feature);
> }
> ---
Fair assesment - we may have to avoid enum for the Java 1.4 people
consuming the interface. We would need to recast the various geometry
opperations to be Expressions (they are defined in terms of true and false).
So this is the strange ground of where we try and turn XML specs into
something that makes a decent object oriented program.
The true/false meaning inclusion/exclusion is pretty strong (based on
set theory). We should let some of the geoapi people chime in as they
probably have a better idea of where the specs are heading.
Jody

Hi Jody,
> >But I still do not understand why a Filter should be an=20
> Expression? Why
> >is that useful?
> > =20
> >
> Oh? It is because a Filter isA Expression. They have the same API.
You're not saying that a Filter isA Expression only because they
"happen" to have the same API, do you? To me, on a conceptual level, a
Filter isNotA Expression. A Filter filters. An Expression calculates
something.
> >But apart from being useful or not, I do not think there is an "is a"
> >relationship between Filter and Expression. Please try to convince me
> >there is such a relationship!
> > =20
> >
> Oh okay ...
> interface Expression {
> Object accept(ExpressionVisitor visitor, Object extraData)
> Object evaluate(Feature feature)
> }
> intrface Filter {
> Object accept(FilterVisitor visitor, Object extraData)
> boolean evaluate(Feature feature)
> }
> The only difference is in the return type of evaulate, any=20
> implementation you see of ExpressionVisitor you see in the wild=20
> implements both interfaces (and as we mentioned earlier the accept=20
> method is a bad idea).
>=20
> >The more practical issue is, that if an application wants to=20
> implement a
> >Filter, it also has to implement Expression. Is that=20
> additional burden
> >on the application justifiable?
> > =20
> >
> There is no additional burden. Incidently I am also fond of the perl=20
> notion of true/false where "", 0, and nil are considered "false". I=20
> could totally see the benifit at a practicle level of making=20
> a wrapper=20
> on Expression to let it be used as a Filter in this manner.
A Filter can be implemented by delegating to an Expression. But the
Filter interface should not make it mandatory to do that, in my opinion.
There is no inherent relationship between Filters and Expressions.
What about this for the Filter interface. I do not like the boolean
result type very much, it is only by convention that I can now what true
means ('yes, filtered out' or 'yes, passes filter')
---
import org.geotools.feature.Feature;
public interface Filter
{
enum Result {reject, admit};
Result filter (Feature feature);
}
---
I attach a test source file to show a custom implementation of this
Filter.
Cheers, Arjan.
***PRIVILEGED AND CONFIDENTIAL*** =0D
The information contained in this e-mail message (including any attached =
files)=0D
is intended for the use of the addressee(s) only and is privileged inform=
ation.=0D
The information should neither be posted to the Internet, nor published i=
n any=0D
other public domain, without the express permission of the sender. If you=
are=0D
not the intended recipient(s) or the recipient's representative, you are =
hereby=0D
notified that any use, disclosure, copying or distribution of this commun=
ication=0D
is prohibited. If you have received this communication in error please no=
tify us=0D
immediately at postmaster@..., and remove this message from =0D
your system.

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details