[Geoserver-devel] Adding FILTER to wms getMap (GEOT-529)

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

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);

if (propertySize == 0) {
properties = null;
} else if (propertySize == 1) {
properties = (List) propertyList.get(0);
} else {
properties = (List) propertyList.get(i);
}

// permissive logic: lets one filter apply to all types
LOGGER.finest("setting filters: " + i);

if (filterSize == 0) {
filter = null;
} else if (filterSize == 1) {
filter = (Filter) filterList.get(0);
} else {
filter = (Filter) filterList.get(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 “)”.

Cheers
Andrea

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!

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org

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)

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!

--
Gabriel Roldán (groldan@anonymised.com)
Axios Engineering (http://www.axios.es)
Tel. +34 944 41 63 84
Fax. +34 944 41 64 90

Gabriel Roldán ha scritto:

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)

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

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.
  

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?

Cheers
Jody

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.

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
  

Woot! That is *great* Gabriel :slight_smile:

Jody

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

Woot! That is *great* Gabriel :slight_smile:

Jody

--
Gabriel Roldán (groldan@anonymised.com)
Axios Engineering (http://www.axios.es)
Tel. +34 944 41 63 84
Fax. +34 944 41 64 90

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 "["...

Gabriel Roldán wrote:

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 :slight_smile:

Jody

Gabriel Roldán ha scritto:

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)

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.

regards,

Gabriel

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

--
Gabriel Roldán (groldan@anonymised.com)
Axios Engineering (http://www.axios.es)
Tel. +34 944 41 63 84
Fax. +34 944 41 64 90

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?
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

Cheers,
Gabriel

Cheers
Andrea

--
Gabriel Roldán (groldan@anonymised.com)
Axios Engineering (http://www.axios.es)
Tel. +34 944 41 63 84
Fax. +34 944 41 64 90

Gabriel Roldán ha scritto:

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.

Cheers
Andrea