[Geoserver-devel] WFS BBoxKvpParser question?

GeoServer GeoServer Developer
1

Hi list,
I’m having some troubles with GS1-7x ND branch when parsing ND parameters using a getCoverage request.

I have noticed that the wcs’s BBoxKvapParser extends WcsKvpParser which sets “WCS” as service.
Instead, the wfs’s BBoxKvapParser simply extends KvpParser without setting its service field.

Now, when parsing a wcs’s request bounding box parameter, the KvpUtils class uses a wfs’s BBox parser which doesn’t properly handle the 5th,6th element of the bounding box (the minz,maxz elements in WCS).

Should we set “wfs” as the value of the “service” field for the wfs’s BBoxKvapParser?
By this way, when the KvpUtils scans for parsers to be used to handle the wcs’s getCoverage request, it will remove the wfs’s parser.

If my observation is right, I will open a JIRA.

Regards,
Daniele

–

Eng. Daniele Romagnoli
Software Engineer

GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 328 0559267

http://www.geo-solutions.it

2

Hi Daniele,

yes, setting the service property in the bbox spring bean is the correct thing
to do. The only problem I can see is we need to check if the same
BboxKvpParser with no service set is being used for the WMS service, in which
case we could use another instance of the same bboxkvpparser configured in
the WMS's applicationContext to it sets "WMS" as service?

2c.

Gabriel

On Friday 31 October 2008 10:08:32 am Daniele Romagnoli wrote:

Hi list,
I'm having some troubles with GS1-7x ND branch when parsing ND parameters
using a getCoverage request.

I have noticed that the wcs's BBoxKvapParser extends WcsKvpParser which
sets "WCS" as service.
Instead, the wfs's BBoxKvapParser simply extends KvpParser without setting
its service field.

Now, when parsing a wcs's request bounding box parameter, the KvpUtils
class uses a wfs's BBox parser which doesn't properly handle the 5th,6th
element of the bounding box (the minz,maxz elements in WCS).

Should we set "wfs" as the value of the "service" field for the wfs's
BBoxKvapParser?
By this way, when the KvpUtils scans for parsers to be used to handle the
wcs's getCoverage request, it will remove the wfs's parser.

If my observation is right, I will open a JIRA.

Regards,
Daniele

3

Gabriel Roldan ha scritto:

Hi Daniele,

yes, setting the service property in the bbox spring bean is the correct thing to do. The only problem I can see is we need to check if the same BboxKvpParser with no service set is being used for the WMS service, in which case we could use another instance of the same bboxkvpparser configured in the WMS's applicationContext to it sets "WMS" as service?

Hum... what's wrong in having WMS and WFS share the same parser?
Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

4

On Friday 31 October 2008 11:39:16 am Andrea Aime wrote:

Gabriel Roldan ha scritto:
> Hi Daniele,
>
> yes, setting the service property in the bbox spring bean is the correct
> thing to do. The only problem I can see is we need to check if the same
> BboxKvpParser with no service set is being used for the WMS service, in
> which case we could use another instance of the same bboxkvpparser
> configured in the WMS's applicationContext to it sets "WMS" as service?

Hum... what's wrong in having WMS and WFS share the same parser?

nothing wrong at all, but if for the wfs bbox parser not getting in the way of
the wcs specific one we need to set the service property the wms won't find a
bbox parser, or I am missunderstanding the issue.

Gabriel

Cheers
Andrea

5

Gabriel Roldan ha scritto:

On Friday 31 October 2008 11:39:16 am Andrea Aime wrote:

Gabriel Roldan ha scritto:

Hi Daniele,

yes, setting the service property in the bbox spring bean is the correct
thing to do. The only problem I can see is we need to check if the same
BboxKvpParser with no service set is being used for the WMS service, in
which case we could use another instance of the same bboxkvpparser
configured in the WMS's applicationContext to it sets "WMS" as service?

Hum... what's wrong in having WMS and WFS share the same parser?

nothing wrong at all, but if for the wfs bbox parser not getting in the way of the wcs specific one we need to set the service property the wms won't find a bbox parser, or I am missunderstanding the issue.

I believe you can just set the service param on the wcs one, and the one
without service spec should be chosen as a fallback when there is none
for the current service... barring dispatcher issues, as we have one open for choosing the right xml reader when service is set, not sure
if the same can go wrong for kvp one, but I would treat that as
an issue in the dispatcher, not as one in the kvp parsers setup.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

6

Hi,
I have tried setting the service for the WFS’s parser.
By this way, wms getMap request stopped working, being unable to parse BoundingBox.
Then I have defined a BBparser for wms too, also setting a bean in WMS’s applicationContext.
This didn’t solved the problem.

I’m not an expert of geoserver and I guess I need to investigate a bit on the dispatcher to understand it’s mechanism.

Regards,
Daniele

On Fri, Oct 31, 2008 at 2:53 PM, Andrea Aime <aaime@anonymised.com> wrote:

Gabriel Roldan ha scritto:

On Friday 31 October 2008 11:39:16 am Andrea Aime wrote:

Gabriel Roldan ha scritto:

Hi Daniele,

yes, setting the service property in the bbox spring bean is the correct
thing to do. The only problem I can see is we need to check if the same
BboxKvpParser with no service set is being used for the WMS service, in
which case we could use another instance of the same bboxkvpparser
configured in the WMS’s applicationContext to it sets “WMS” as service?
Hum… what’s wrong in having WMS and WFS share the same parser?

nothing wrong at all, but if for the wfs bbox parser not getting in the way of
the wcs specific one we need to set the service property the wms won’t find a
bbox parser, or I am missunderstanding the issue.

I believe you can just set the service param on the wcs one, and the one
without service spec should be chosen as a fallback when there is none
for the current service… barring dispatcher issues, as we have one
open for choosing the right xml reader when service is set, not sure
if the same can go wrong for kvp one, but I would treat that as
an issue in the dispatcher, not as one in the kvp parsers setup.

Cheers
Andrea

–
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

This SF.Net email is sponsored by the Moblin Your Move Developer’s challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–

Eng. Daniele Romagnoli
Software Engineer

GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 328 0559267

http://www.geo-solutions.it

7

Hi,
I have tried setting the service for the WFS’s parser.
By this way, wms getMap request stopped working, being unable to parse BoundingBox.
Then I have defined a BBparser for wms too, also setting a bean in WMS’s applicationContext.
This didn’t solved the problem.

I’m not an expert of geoserver and I guess I need to investigate a bit on the dispatcher to understand it’s mechanism.

Regards,

On Fri, Oct 31, 2008 at 2:53 PM, Andrea Aime <aaime@anonymised.com> wrote:

Gabriel Roldan ha scritto:

On Friday 31 October 2008 11:39:16 am Andrea Aime wrote:

Gabriel Roldan ha scritto:

Hi Daniele,

yes, setting the service property in the bbox spring bean is the correct
thing to do. The only problem I can see is we need to check if the same
BboxKvpParser with no service set is being used for the WMS service, in
which case we could use another instance of the same bboxkvpparser
configured in the WMS’s applicationContext to it sets “WMS” as service?
Hum… what’s wrong in having WMS and WFS share the same parser?

nothing wrong at all, but if for the wfs bbox parser not getting in the way of
the wcs specific one we need to set the service property the wms won’t find a
bbox parser, or I am missunderstanding the issue.

I believe you can just set the service param on the wcs one, and the one
without service spec should be chosen as a fallback when there is none
for the current service… barring dispatcher issues, as we have one
open for choosing the right xml reader when service is set, not sure
if the same can go wrong for kvp one, but I would treat that as
an issue in the dispatcher, not as one in the kvp parsers setup.

Cheers
Andrea

–
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

This SF.Net email is sponsored by the Moblin Your Move Developer’s challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

–

Eng. Daniele Romagnoli
Software Engineer

GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 328 0559267

http://www.geo-solutions.it

8

Hi Danielle,

As Andrea says I think this is probably just a bug in the dispatcher. What it should to is take preference over those kvp parsers which actually declare a service matching the requested service, over those parsers that don't declare any service. A quick review of the dispatching code confirms this.

So here is a bug report for 1.7.1, i will try to post a patch soon.

http://jira.codehaus.org/browse/GEOS-2336

-Justin

Daniele Romagnoli wrote:

Hi,
I have tried setting the service for the WFS's parser.
By this way, wms getMap request stopped working, being unable to parse BoundingBox.
Then I have defined a BBparser for wms too, also setting a bean in WMS's applicationContext.
This didn't solved the problem.

I'm not an expert of geoserver and I guess I need to investigate a bit on the dispatcher to understand it's mechanism.

Regards,
Daniele

On Fri, Oct 31, 2008 at 2:53 PM, Andrea Aime <aaime@anonymised.com <mailto:aaime@anonymised.com>> wrote:

    Gabriel Roldan ha scritto:
     > On Friday 31 October 2008 11:39:16 am Andrea Aime wrote:
     >> Gabriel Roldan ha scritto:
     >>> Hi Daniele,
     >>>
     >>> yes, setting the service property in the bbox spring bean is
    the correct
     >>> thing to do. The only problem I can see is we need to check if
    the same
     >>> BboxKvpParser with no service set is being used for the WMS
    service, in
     >>> which case we could use another instance of the same bboxkvpparser
     >>> configured in the WMS's applicationContext to it sets "WMS" as
    service?
     >> Hum... what's wrong in having WMS and WFS share the same parser?
     >
     > nothing wrong at all, but if for the wfs bbox parser not getting
    in the way of
     > the wcs specific one we need to set the service property the wms
    won't find a
     > bbox parser, or I am missunderstanding the issue.

    I believe you can just set the service param on the wcs one, and the one
    without service spec should be chosen as a fallback when there is none
    for the current service... barring dispatcher issues, as we have one
    open for choosing the right xml reader when service is set, not sure
    if the same can go wrong for kvp one, but I would treat that as
    an issue in the dispatcher, not as one in the kvp parsers setup.

    Cheers
    Andrea

    --
    Andrea Aime
    OpenGeo - http://opengeo.org
    Expert service straight from the developers.

    -------------------------------------------------------------------------
    This SF.Net email is sponsored by the Moblin Your Move Developer's
    challenge
    Build the coolest Linux based applications with Moblin SDK & win
    great prizes
    Grand prize is a trip for two to an Open Source event anywhere in
    the world
    http://moblin-contest.org/redirect.php?banner_id=100&url=/
    <http://moblin-contest.org/redirect.php?banner_id=100&url=/&gt;
    _______________________________________________
    Geoserver-devel mailing list
    Geoserver-devel@lists.sourceforge.net
    <mailto:Geoserver-devel@lists.sourceforge.net>
    https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
-------------------------------------------------------
Eng. Daniele Romagnoli
Software Engineer

GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy

phone: +39 0584983027
fax: +39 0584983027
mob: +39 328 0559267

http://www.geo-solutions.it

-------------------------------------------------------

------------------------------------------------------------------------

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/

------------------------------------------------------------------------

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.