Hi all,
I'm trying to work on http://jira.codehaus.org/browse/GEOS-529?page=all and I have
a few comments. Unfortunately I cannot access Jira, have been unable to for the whole
day (sometimes I get to the pages, never managed to login thought), so I'm moving the
discussion here (as I'm fed up of wasting time...)
Now, to be coherent with the spec spirit, we should add a FILTER parameter that
allows to specify a comma separate list of filters. Each filter should be encoded in XML,
and then url-encoded before being added to the getMap request: althought a little
incovenient for hand made filters, it's what the HTTP spec says, so we shall respect it
in my opinion.
Now, the above list of filters may become very very long, so I guess we should support
post requests as well.
Finally, as proposed by Dave in private mails, we may want to support also filters
encoded in the format supported by ExpressionBuilder. It's a simple format,
such as myAttribute=10 or myAtt1>myAtt2 and so on, compact enough to make it
a good candidate for hand written get requests. If you agree to add this too, I'd like
to use a separate parameter for filters encoded this way, say, GTFILTER, or EBFILTER
(again, one filter per layer, url-encoded).
As an extra request, and following a discussion with Dave, we could
also support the semantics of having just one filter spec apply to all
layers. This is already done in the WFS getFeatures request, here is the
code in GetFeatureKvpReader:
// permissive logic: lets one property list apply to all types
LOGGER.finest("setting properties: " + i);
And btw, this is not something foreseen by the OGC spec, but
yes, in some cases it may make sense. The spec (WFS 1.0) says:
A filter specification describes a set of features to operate upon. The filter is defined as specified in the Filter Encoding Specification [3]. If the FILTER parameter is used, one filter must be specified for each feature type listed in the TYPENAME parameter. Individual filters encoded in the FILTER parameter are enclosed in parentheses “(“ and “)”.
Ah, that's what the expression builder for, to parse a simple way. Yes, I think a FILTER following the spec and a GTFILTER makes a lot of sense.
Post requests make sense, and I think we support WMS post, but mixing a filter in is a bit more difficult. I'm inclined to say that if people are using post requests they should be using SLD, which can use the full power of filter. I see this as a shortcut. So I'd say just support filter and gtfilter in get for now, and revisit post at a later date.
Chris
aaime@anonymised.com wrote:
Hi all,
I'm trying to work on http://jira.codehaus.org/browse/GEOS-529?page=all and I have
a few comments. Unfortunately I cannot access Jira, have been unable to for the whole
day (sometimes I get to the pages, never managed to login thought), so I'm moving the
discussion here (as I'm fed up of wasting time...)
Now, to be coherent with the spec spirit, we should add a FILTER parameter that
allows to specify a comma separate list of filters. Each filter should be encoded in XML,
and then url-encoded before being added to the getMap request: althought a little
incovenient for hand made filters, it's what the HTTP spec says, so we shall respect it
in my opinion.
Now, the above list of filters may become very very long, so I guess we should support
post requests as well.
Finally, as proposed by Dave in private mails, we may want to support also filters
encoded in the format supported by ExpressionBuilder. It's a simple format,
such as myAttribute=10 or myAtt1>myAtt2 and so on, compact enough to make it
a good candidate for hand written get requests. If you agree to add this too, I'd like
to use a separate parameter for filters encoded this way, say, GTFILTER, or EBFILTER
(again, one filter per layer, url-encoded).
I would rather suggest to use CONSTRAINT and CONSTRAINTLANGUAGE,
or at least let FILTER and CONSTRAINTLANGUAGE
CONSTRAINTLANGUAGE is defined in the CSW2.0+ spec and its an enum that can be
assigned the values FILTER and CQL_TEXT (which in turn is the format being
parsed by ExpressionBuilder)
BTW, a colleague of me is working on an improved version of ExpressionBuilder
as to cope the full BNF as defined in CSW2.0.1
cheers,
Gabriel
On Wednesday 04 October 2006 16:46, Chris Holmes wrote:
Ah, that's what the expression builder for, to parse a simple way. Yes,
I think a FILTER following the spec and a GTFILTER makes a lot of sense.
Post requests make sense, and I think we support WMS post, but mixing a
filter in is a bit more difficult. I'm inclined to say that if people
are using post requests they should be using SLD, which can use the full
power of filter. I see this as a shortcut. So I'd say just support
filter and gtfilter in get for now, and revisit post at a later date.
Chris
aaime@anonymised.com wrote:
> Hi all,
> I'm trying to work on http://jira.codehaus.org/browse/GEOS-529?page=all
> and I have
> a few comments. Unfortunately I cannot access Jira, have been unable to
> for the whole
> day (sometimes I get to the pages, never managed to login thought), so
> I'm moving the
> discussion here (as I'm fed up of wasting time...)
>
> Now, to be coherent with the spec spirit, we should add a FILTER
> parameter that
> allows to specify a comma separate list of filters. Each filter should
> be encoded in XML,
> and then url-encoded before being added to the getMap request: althought
> a little
> incovenient for hand made filters, it's what the HTTP spec says, so we
> shall respect it
> in my opinion.
>
> Now, the above list of filters may become very very long, so I guess we
> should support
> post requests as well.
>
> Finally, as proposed by Dave in private mails, we may want to support
> also filters
> encoded in the format supported by ExpressionBuilder. It's a simple
> format, such as myAttribute=10 or myAtt1>myAtt2 and so on, compact enough
> to make it a good candidate for hand written get requests. If you agree
> to add this too, I'd like
> to use a separate parameter for filters encoded this way, say, GTFILTER,
> or EBFILTER
> (again, one filter per layer, url-encoded).
>
> What do you think?
> Cheers
> Andrea
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your opinions on IT & business topics through brief surveys -- and earn
> cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
> !DSPAM:1003,4523b5aa59649771116852!
I would rather suggest to use CONSTRAINT and CONSTRAINTLANGUAGE,
or at least let FILTER and CONSTRAINTLANGUAGE
CONSTRAINTLANGUAGE is defined in the CSW2.0+ spec and its an enum that can be assigned the values FILTER and CQL_TEXT (which in turn is the format being parsed by ExpressionBuilder)
BTW, a colleague of me is working on an improved version of ExpressionBuilder as to cope the full BNF as defined in CSW2.0.1
Nice to know... Yes, seems to be a good idea
Cheers
Andrea
Hi all,
I'm trying to work on http://jira.codehaus.org/browse/GEOS-529?page=all and I have
a few comments. Unfortunately I cannot access Jira, have been unable to for the whole
day (sometimes I get to the pages, never managed to login thought), so I'm moving the
discussion here (as I'm fed up of wasting time...)
Now, to be coherent with the spec spirit, we should add a FILTER parameter that
allows to specify a comma separate list of filters. Each filter should be encoded in XML,
and then url-encoded before being added to the getMap request: althought a little
incovenient for hand made filters, it's what the HTTP spec says, so we shall respect it
in my opinion.
Now, the above list of filters may become very very long, so I guess we should support post requests as well.
Bleah, trying to remember how vendor specific parameters are used during Post. If possible leaving Post for the 1.5.x stream where you would have
GTXML to handle the parsing would help. I assume the list of filters is in the same order as the layers request.
Finally, as proposed by Dave in private mails, we may want to support also filters
encoded in the format supported by ExpressionBuilder. It's a simple format,
such as myAttribute=10 or myAtt1>myAtt2 and so on, compact enough to make it
a good candidate for hand written get requests. If you agree to add this too, I'd like
to use a separate parameter for filters encoded this way, say, GTFILTER, or EBFILTER
(again, one filter per layer, url-encoded).
They do have a plain text encoding for Filter listed as part of the CSW specification - they include BNF and so on. Supporting a text format for filter is fine, we just should do the supported one. The only difference between it and ExpressionBuilder is "[" "]" characters - the ExpressionBuilder parser is simply to the point of not having operator precedence instead demanding that braces be used all the time.
Options that would allow us to use a plain text filter:
a) check if a bracket character of any description is allowed, I think '(' and ')' may be, and modify ExpressionBuilder to use it
b) buck up and use JavaCC or ANTLR to produce the real parser
Justin you have looked at WFS 1.1 / Filter 1.1 - do they include any details there?
I would rather suggest to use CONSTRAINT and CONSTRAINTLANGUAGE,
or at least let FILTER and CONSTRAINTLANGUAGE
CONSTRAINTLANGUAGE is defined in the CSW2.0+ spec and its an enum that can be assigned the values FILTER and CQL_TEXT (which in turn is the format being parsed by ExpressionBuilder)
Are you sure? The expression builder use of mandatory "[" braces looked to be a bit of custom overkill to me? Perhaps it
has gotten better since I last looked.
BTW, a colleague of me is working on an improved version of ExpressionBuilder as to cope the full BNF as defined in CSW2.0.1
On Wednesday 04 October 2006 17:38, Jody Garnett wrote:
Gabriel Roldán wrote:
> Hi Andrea,
>
> I would rather suggest to use CONSTRAINT and CONSTRAINTLANGUAGE,
> or at least let FILTER and CONSTRAINTLANGUAGE
>
> CONSTRAINTLANGUAGE is defined in the CSW2.0+ spec and its an enum that
> can be assigned the values FILTER and CQL_TEXT (which in turn is the
> format being parsed by ExpressionBuilder)
Are you sure? The expression builder use of mandatory "[" braces looked
to be a bit of custom overkill to me? Perhaps it
has gotten better since I last looked.
well, I should have said "it's kind of the format being parsed". There are
some differences with the language defined in CSW and lacks a lot of
constructs, but I think having one that respects a 'well defined' constraint
language would be better than using a custom one, and since we're
implementing it sounds even more reasonable
> BTW, a colleague of me is working on an improved version of
> ExpressionBuilder as to cope the full BNF as defined in CSW2.0.1
Are you sure? The expression builder use of mandatory "[" braces looked
to be a bit of custom overkill to me?
BTW, I'm not sure what you mean by mandatory braces?, I've always used
ExpressionBuilder with expressions like "prop = 1 AND prop2 <= 5" without
any "["...
Are you sure? The expression builder use of mandatory "[" braces looked
to be a bit of custom overkill to me?
BTW, I'm not sure what you mean by mandatory braces?, I've always used ExpressionBuilder with expressions like "prop = 1 AND prop2 <= 5" without any "["...
So it *has* gotten better since I last looked - I think the wiki instructions still document braces
I would rather suggest to use CONSTRAINT and CONSTRAINTLANGUAGE,
or at least let FILTER and CONSTRAINTLANGUAGE
CONSTRAINTLANGUAGE is defined in the CSW2.0+ spec and its an enum that can be assigned the values FILTER and CQL_TEXT (which in turn is the format being parsed by ExpressionBuilder)
BTW, a colleague of me is working on an improved version of ExpressionBuilder as to cope the full BNF as defined in CSW2.0.1
cheers,
Btw, I'm setting up Jira so that I won't forget about this.
Do you mind if I open an issue in geot for implementing the above spec and assign it to you?
Cheers
Andrea
Btw, I'm setting up Jira so that I won't forget about this.
Do you mind if I open an issue in geot for implementing the above spec
and assign it to you?
sure, go ahead
It is about parsing CQL into Filter 1.1 using the latest geoapi filter
interfaces.
Btw, I'm setting up Jira so that I won't forget about this.
Do you mind if I open an issue in geot for implementing the above spec
and assign it to you?
sure, go ahead
It is about parsing CQL into Filter 1.1 using the latest geoapi filter interfaces.
Ah, so this mean we'll be able to support it in geoserver only once geoserver will begin using geotools 2.4?
Or maybe it will be included in gt 2.3.x?
Cheers
Andrea
On Thursday 05 October 2006 12:23, aaime@anonymised.com wrote:
Gabriel Roldán ha scritto:
>> Btw, I'm setting up Jira so that I won't forget about this.
>> Do you mind if I open an issue in geot for implementing the above spec
>> and assign it to you?
>
> sure, go ahead
>
> It is about parsing CQL into Filter 1.1 using the latest geoapi filter
> interfaces.
Ah, so this mean we'll be able to support it in geoserver only once
geoserver will begin using geotools 2.4?
Or maybe it will be included in gt 2.3.x?
aha... good question.
AFAIK, 2.3.x is based on geoapi-2.1-SNAPSHOT, meaning that the latest filter
interfaces are available, and the geotools filter implementations are already
sync'ed with geoapi, so I bet for 2.3.
though we're working against trunk, it looks like a fair enough backport,
right? please correct me if I'm wrong
On Thursday 05 October 2006 12:23, aaime@anonymised.com wrote:
Gabriel Roldán ha scritto:
Btw, I'm setting up Jira so that I won't forget about this.
Do you mind if I open an issue in geot for implementing the above spec
and assign it to you?
sure, go ahead
It is about parsing CQL into Filter 1.1 using the latest geoapi filter
interfaces.
Ah, so this mean we'll be able to support it in geoserver only once
geoserver will begin using geotools 2.4?
Or maybe it will be included in gt 2.3.x?
aha... good question. AFAIK, 2.3.x is based on geoapi-2.1-SNAPSHOT, meaning that the latest filter interfaces are available, and the geotools filter implementations are already sync'ed with geoapi, so I bet for 2.3.
though we're working against trunk, it looks like a fair enough backport, right? please correct me if I'm wrong
It seems ok to me, but maybe Jody knows better. CC'ing the geotools developers list so that we
can discuss this with others too.