[Geoserver-users] Using the new oracleNG plugin

[Kris_Geusebroek]

Hi i’m trying to go from using the old oracle plugin to using the oracleNG plugin

I already found that I need to change my catalog.xml to use:

• Dbtype=Oracle instead of dbtype=oracle

• Use database property instead of instance

• Add connection timeout, loose bbox and fetchsize properties

So far so good, no errors in starting up geoserver with the new config.

But when getting the data I get the following error:

java.sql.SQLException: ORA-29902: error in executing ODCIIndexStart() routine
ORA-13208: internal error while evaluating [window SRID does not match layer SRID] operator
ORA-06512: at “MDSYS.SDO_INDEX_METHOD_10I”, line 369

I have set the SRID in the SDO_GEOM_META_DATA but the log (verbose_logging) says

DEBUG [oracle.sdo] – Using NULL SRID:

I already tried to add my srs code (epsg:28992) to the EPSG.properties but that doesn’t help.

How do I configure this to use the srs I supply in the URL

Thanks in advance

Cheers

Kris Geusebroek

Consultant

	Email: kgeusebroek@anonymised.com Tel: +31 (0)35 538 1921 Fax: +31 (0)35 538 1922 Mobile: +31 (0)6 30 697 223 http://www.xebia.com	Utrechtseweg 49 1213 TL Hilversum The Netherlands

Xebia Blog ! http://blog.xebia.com/

Xebia Podcast! http://podcast.xebia.com/

[Kris_Geusebroek]

I made some progress myself.

I can see in the sourcecode of the oracle plugin that a query is done to the table USER_SDO_GEOM_)METADAT to get the SRID for the table

In my config this table is empty because we use a table from another user by public synonym.

So I think I need to update the USER SDO GEOM METADATA table for this user too.

Any other options are appreciated

Keep you posted

Cheers Kris

From: Kris Geusebroek [mailto:kgeusebroek@anonymised.com]
Sent: Tuesday, March 10, 2009 1:40 PM
To: geoserver-users@lists.sourceforge.net
Subject: [Geoserver-users] Using the new oracleNG plugin

Hi i’m trying to go from using the old oracle plugin to using the oracleNG plugin

I already found that I need to change my catalog.xml to use:

• Dbtype=Oracle instead of dbtype=oracle

• Use database property instead of instance

• Add connection timeout, loose bbox and fetchsize properties

So far so good, no errors in starting up geoserver with the new config.

But when getting the data I get the following error:

java.sql.SQLException: ORA-29902: error in executing ODCIIndexStart() routine
ORA-13208: internal error while evaluating [window SRID does not match layer SRID] operator
ORA-06512: at “MDSYS.SDO_INDEX_METHOD_10I”, line 369

I have set the SRID in the SDO_GEOM_META_DATA but the log (verbose_logging) says

DEBUG [oracle.sdo] – Using NULL SRID:

I already tried to add my srs code (epsg:28992) to the EPSG.properties but that doesn’t help.

How do I configure this to use the srs I supply in the URL

Thanks in advance

Cheers

Kris Geusebroek

Consultant

	Email: kgeusebroek@anonymised.com Tel: +31 (0)35 538 1921 Fax: +31 (0)35 538 1922 Mobile: +31 (0)6 30 697 223 http://www.xebia.com	Utrechtseweg 49 1213 TL Hilversum The Netherlands

Xebia Blog ! http://blog.xebia.com/

Xebia Podcast! http://podcast.xebia.com/

[Andrea_Aime3]

Kris Geusebroek ha scritto:

I made some progress myself.

I can see in the sourcecode of the oracle plugin that a query is done to the table USER_SDO_GEOM_)METADAT to get the SRID for the table

In my config this table is empty because we use a table from another user by public synonym.

So I think I need to update the USER SDO GEOM METADATA table for this user too.

Any other options are appreciated

There is none that I know of, Oracle pretends that the srs of the
bbox and whatever else used in a spatial index is equal to the
one of the indexed geometries.
You say that the old oracle spatial datastore was working properly
for you? I'm wondering how, the old datastore was getting the
srid in pretty much the same way and was encoding the srid as well.

Humm... I see the old was encoding NULL as the srid when it was not
known, whilst I guess the new one is encoding -1. That is probably
the relevant difference? Can you try running manually a query
that uses NULL and see if Oracle complains about it?

Cheers
Andrea

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

[Andrea_Aime3]

Andrea Aime ha scritto:

Kris Geusebroek ha scritto:

I made some progress myself.

I can see in the sourcecode of the oracle plugin that a query is done to the table USER_SDO_GEOM_)METADAT to get the SRID for the table

In my config this table is empty because we use a table from another user by public synonym.

So I think I need to update the USER SDO GEOM METADATA table for this user too.

Any other options are appreciated

There is none that I know of, Oracle pretends that the srs of the
bbox and whatever else used in a spatial index is equal to the
one of the indexed geometries.
You say that the old oracle spatial datastore was working properly
for you? I'm wondering how, the old datastore was getting the
srid in pretty much the same way and was encoding the srid as well.

Humm... I see the old was encoding NULL as the srid when it was not
known, whilst I guess the new one is encoding -1.

Actually, I checked, in case the srid is -1, the SDO_GEOMETRY built
has null srid as well.

Cheers
Andrea

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

[Kris_Geusebroek]

Hi all,

I inserted the metadata and now it works for insert and delete WFS-T requests but not for update.

This looks like the same issue as mentioned in WFS-T oracle update faild on GS 1.7.2 thread.

Here is stated that it works in the nightly build of march 10 (have to verify this).

I’m using the 1.7.3 version from sourgeforce and here the issue still exists.

Am I correct in assuming the 1.7.3 release is done before the fix?

If so I need to use the nightly build

Cheers Kris

From: Kris Geusebroek [mailto:kgeusebroek@anonymised.com]
Sent: Tuesday, March 10, 2009 2:21 PM
To: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] Using the new oracleNG plugin

I made some progress myself.

I can see in the sourcecode of the oracle plugin that a query is done to the table USER_SDO_GEOM_)METADAT to get the SRID for the table

In my config this table is empty because we use a table from another user by public synonym.

So I think I need to update the USER SDO GEOM METADATA table for this user too.

Any other options are appreciated

Keep you posted

Cheers Kris

From: Kris Geusebroek [mailto:kgeusebroek@anonymised.com1858…]
Sent: Tuesday, March 10, 2009 1:40 PM
To: geoserver-users@lists.sourceforge.net
Subject: [Geoserver-users] Using the new oracleNG plugin

Hi i’m trying to go from using the old oracle plugin to using the oracleNG plugin

I already found that I need to change my catalog.xml to use:

• Dbtype=Oracle instead of dbtype=oracle

• Use database property instead of instance

• Add connection timeout, loose bbox and fetchsize properties

So far so good, no errors in starting up geoserver with the new config.

But when getting the data I get the following error:

java.sql.SQLException: ORA-29902: error in executing ODCIIndexStart() routine
ORA-13208: internal error while evaluating [window SRID does not match layer SRID] operator
ORA-06512: at “MDSYS.SDO_INDEX_METHOD_10I”, line 369

I have set the SRID in the SDO_GEOM_META_DATA but the log (verbose_logging) says

DEBUG [oracle.sdo] – Using NULL SRID:

I already tried to add my srs code (epsg:28992) to the EPSG.properties but that doesn’t help.

How do I configure this to use the srs I supply in the URL

Thanks in advance

Cheers

Kris Geusebroek

Consultant

	Email: kgeusebroek@anonymised.com Tel: +31 (0)35 538 1921 Fax: +31 (0)35 538 1922 Mobile: +31 (0)6 30 697 223 http://www.xebia.com	Utrechtseweg 49 1213 TL Hilversum The Netherlands

Xebia Blog ! http://blog.xebia.com/

Xebia Podcast! http://podcast.xebia.com/

[Kris_Geusebroek]

Hi Andrea,

I see the new one is setting the srid parameter to NULL also only
internally handling it as -1 I guess
The old pluggin worked without the filling of the user_sdo_geom_metadata
table yes.
Don't exactly know why though (might try the verbose logging on the old
one later to find out some more)
I think setting the user_sdo_geom_metadata of the other user (the one
used for the connection and with the synonym) seems like a good thing.

Cheers Kris

-----Original Message-----
From: Andrea Aime [mailto:aaime@anonymised.com]
Sent: Tuesday, March 10, 2009 2:50 PM
To: Kris Geusebroek
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] Using the new oracleNG plugin

Kris Geusebroek ha scritto:

I made some progress myself.

I can see in the sourcecode of the oracle plugin that a query is done

to

the table USER_SDO_GEOM_)METADAT to get the SRID for the table

In my config this table is empty because we use a table from another
user by public synonym.

So I think I need to update the USER SDO GEOM METADATA table for this
user too.

Any other options are appreciated

There is none that I know of, Oracle pretends that the srs of the
bbox and whatever else used in a spatial index is equal to the
one of the indexed geometries.
You say that the old oracle spatial datastore was working properly
for you? I'm wondering how, the old datastore was getting the
srid in pretty much the same way and was encoding the srid as well.

Humm... I see the old was encoding NULL as the srid when it was not
known, whilst I guess the new one is encoding -1. That is probably
the relevant difference? Can you try running manually a query
that uses NULL and see if Oracle complains about it?

Cheers
Andrea

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

[Andrea_Aime3]

Kris Geusebroek ha scritto:

Hi all,

I inserted the metadata and now it works for insert and delete WFS-T requests but not for update.

This looks like the same issue as mentioned in WFS-T oracle update faild on GS 1.7.2 thread.

Here is stated that it works in the nightly build of march 10 (have to verify this).

I’m using the 1.7.3 version from sourgeforce and here the issue still exists.

Am I correct in assuming the 1.7.3 release is done before the fix?

Indeed, the fix has been coded when the release packages were already
made.

If so I need to use the nightly build

Yep
Cheers
Andrea

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

[Jukka_Rahkonen]

Hi,

Just wondering, perhaps synonym all_sdo_geom_metadata should be used instead of user_sdo_geom_metadata? At least in our environment Geoserver user account is used just for queries, and indexes, metadata rows etc. are created by another account having manager rights.

-Jukka Rahkonen-

-----Alkuperäinen viesti-----
Lähettäjä: Andrea Aime [mailto:aaime@anonymised.com]
Lähetetty: 10. maaliskuuta 2009 15:50
Vastaanottaja: Kris Geusebroek
Kopio: geoserver-users@lists.sourceforge.net
Aihe: Re: [Geoserver-users] Using the new oracleNG plugin

Kris Geusebroek ha scritto:
> I made some progress myself.
>
> I can see in the sourcecode of the oracle plugin that a
query is done
> to the table USER_SDO_GEOM_)METADAT to get the SRID for the table
>
> In my config this table is empty because we use a table
from another
> user by public synonym.
>
>
>
> So I think I need to update the USER SDO GEOM METADATA
table for this
> user too.
>
> Any other options are appreciated

There is none that I know of, Oracle pretends that the srs of
the bbox and whatever else used in a spatial index is equal
to the one of the indexed geometries.
You say that the old oracle spatial datastore was working
properly for you? I'm wondering how, the old datastore was
getting the srid in pretty much the same way and was encoding
the srid as well.

Humm... I see the old was encoding NULL as the srid when it
was not known, whilst I guess the new one is encoding -1.
That is probably the relevant difference? Can you try running
manually a query that uses NULL and see if Oracle complains about it?

Cheers
Andrea

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

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

[Kris_Geusebroek]

Hi Jukka,

If you want to use the all_sdo_geom_metadata table geoserver must know at least the owner to get the correct row. I don't think this is supported in the config yet?

Cheers Kris

-----Original Message-----
From: Rahkonen Jukka [mailto:Jukka.Rahkonen@anonymised.com]
Sent: Tuesday, March 10, 2009 3:40 PM
To: Andrea Aime; Kris Geusebroek
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] Using the new oracleNG plugin

Hi,

Just wondering, perhaps synonym all_sdo_geom_metadata should be used instead of user_sdo_geom_metadata? At least in our environment Geoserver user account is used just for queries, and indexes, metadata rows etc. are created by another account having manager rights.

-Jukka Rahkonen-

-----Alkuperäinen viesti-----
Lähettäjä: Andrea Aime [mailto:aaime@anonymised.com]
Lähetetty: 10. maaliskuuta 2009 15:50
Vastaanottaja: Kris Geusebroek
Kopio: geoserver-users@lists.sourceforge.net
Aihe: Re: [Geoserver-users] Using the new oracleNG plugin

Kris Geusebroek ha scritto:
> I made some progress myself.
>
> I can see in the sourcecode of the oracle plugin that a
query is done
> to the table USER_SDO_GEOM_)METADAT to get the SRID for the table
>
> In my config this table is empty because we use a table
from another
> user by public synonym.
>
>
>
> So I think I need to update the USER SDO GEOM METADATA
table for this
> user too.
>
> Any other options are appreciated

There is none that I know of, Oracle pretends that the srs of
the bbox and whatever else used in a spatial index is equal
to the one of the indexed geometries.
You say that the old oracle spatial datastore was working
properly for you? I'm wondering how, the old datastore was
getting the srid in pretty much the same way and was encoding
the srid as well.

Humm... I see the old was encoding NULL as the srid when it
was not known, whilst I guess the new one is encoding -1.
That is probably the relevant difference? Can you try running
manually a query that uses NULL and see if Oracle complains about it?

Cheers
Andrea

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

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

[Jukka_Rahkonen]

Well, I can see that it used to be that way.
http://geoserver.org/display/GEOSDOC/Oracle+DataStore

-Jukka-

-----Alkuperäinen viesti-----
Lähettäjä: Kris Geusebroek [mailto:kgeusebroek@anonymised.com]
Lähetetty: 10. maaliskuuta 2009 16:45
Vastaanottaja: Rahkonen Jukka; Andrea Aime
Kopio: geoserver-users@lists.sourceforge.net
Aihe: RE: [Geoserver-users] Using the new oracleNG plugin

Hi Jukka,

If you want to use the all_sdo_geom_metadata table geoserver
must know at least the owner to get the correct row. I don't
think this is supported in the config yet?

Cheers Kris

-----Original Message-----
From: Rahkonen Jukka [mailto:Jukka.Rahkonen@anonymised.com]
Sent: Tuesday, March 10, 2009 3:40 PM
To: Andrea Aime; Kris Geusebroek
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] Using the new oracleNG plugin

Hi,

Just wondering, perhaps synonym all_sdo_geom_metadata should
be used instead of user_sdo_geom_metadata? At least in our
environment Geoserver user account is used just for queries,
and indexes, metadata rows etc. are created by another
account having manager rights.

-Jukka Rahkonen-

> -----Alkuperäinen viesti-----
> Lähettäjä: Andrea Aime [mailto:aaime@anonymised.com]
> Lähetetty: 10. maaliskuuta 2009 15:50
> Vastaanottaja: Kris Geusebroek
> Kopio: geoserver-users@lists.sourceforge.net
> Aihe: Re: [Geoserver-users] Using the new oracleNG plugin
>
> Kris Geusebroek ha scritto:
> > I made some progress myself.
> >
> > I can see in the sourcecode of the oracle plugin that a
> query is done
> > to the table USER_SDO_GEOM_)METADAT to get the SRID for the table
> >
> > In my config this table is empty because we use a table
> from another
> > user by public synonym.
> >
> >
> >
> > So I think I need to update the USER SDO GEOM METADATA
> table for this
> > user too.
> >
> > Any other options are appreciated
>
> There is none that I know of, Oracle pretends that the srs
of the bbox
> and whatever else used in a spatial index is equal to the
one of the
> indexed geometries.
> You say that the old oracle spatial datastore was working
properly for
> you? I'm wondering how, the old datastore was getting the srid in
> pretty much the same way and was encoding the srid as well.
>
> Humm... I see the old was encoding NULL as the srid when it was not
> known, whilst I guess the new one is encoding -1.
> That is probably the relevant difference? Can you try
running manually
> a query that uses NULL and see if Oracle complains about it?
>
> Cheers
> Andrea
>
> --
> Andrea Aime
> OpenGeo - http://opengeo.org
> Expert service straight from the developers.
>
> --------------------------------------------------------------
> ----------------
> _______________________________________________
> Geoserver-users mailing list
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>

[Andrea_Aime3]

Kris Geusebroek ha scritto:

Hi Jukka,

If you want to use the all_sdo_geom_metadata table geoserver must know at least the owner to get the correct row. I don't think this is supported in the config yet?

The "schema" field should give that information.
What's unsettling for me is that I already jumped between
the user_sdo_geom_metadata and the user_sdo_geom_metadata
a few times with the old datastore, and each time someone
tells me I should use the other one.
I guess I should give up and try to use both?

Cheers
Andrea

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

[Per_Engstrom1]

Hello list.

I’ve been working on GeoWebCache (GWC) for some time now and I’ve just come across a bit of a problem when caching layers with multiple projections (SRS:s). The problem occurs when the Capabillities document only specifies a BoundingBox for one SRS and not one BoundingBox for each SRS. This is ok according to OGC:s WMS spec 1.1.1:
“A server which has the ability to transform data to different SRSes may choose not to
provide an explicit BoundingBox for every possible SRS available for each Layer. The
server should provide BoundingBox information for at least the native SRS of the Layer.”

As I understand this is the default behaviour of GeoServer.

However, GeoTools (GWC utilizes GeoTools for parsing the Capabilities document) is not able to recognize SRS:s that does not have a specified BoundingBox, thus GWC is unable to recognize and cache the layer in those projections.

My question is:
Is there a way to force GeoServer to provide a BoundingBox for all SRS:s provided?

Regards,
Per Engström

[Per_Engstrom]

Hello list.

I’ve been working on GeoWebCache (GWC) for some time now and I’ve just come across a bit of a problem when caching layers with multiple projections (SRS:s). The problem occurs when the Capabillities document only specifies a BoundingBox for one SRS and not one BoundingBox for each SRS. This is ok according to OGC:s WMS spec 1.1.1:
“A server which has the ability to transform data to different SRSes may choose not to
provide an explicit BoundingBox for every possible SRS available for each Layer. The
server should provide BoundingBox information for at least the native SRS of the Layer.”

As I understand this is the default behaviour of GeoServer.

However, GeoTools (GWC utilizes GeoTools for parsing the Capabilities document) is not able to recognize SRS:s that does not have a specified BoundingBox, thus GWC is unable to recognize and cache the layer in those projections.

My question is:
Is there a way to force GeoServer to provide a BoundingBox for all SRS:s provided?

Regards,
Per Engström

[Andrea_Aime3]

Per Engström ha scritto:

Hello list.

I've been working on GeoWebCache (GWC) for some time now and I've just come across a bit of a problem when caching layers with multiple projections (SRS:s). The problem occurs when the Capabillities document only specifies a BoundingBox for one SRS and not one BoundingBox for each SRS. This is ok according to OGC:s WMS spec 1.1.1:
"A server which has the ability to transform data to different SRSes *may* choose not to provide an explicit BoundingBox for every possible SRS available for each Layer. The server *should* provide BoundingBox information for at least the native SRS of the Layer."

As I understand this is the default behaviour of GeoServer.

However, GeoTools (GWC utilizes GeoTools for parsing the Capabilities document) is not able to recognize SRS:s that does not have a specified BoundingBox, thus GWC is unable to recognize and cache the layer in those projections.

My question is:
Is there a way to force GeoServer to provide a BoundingBox for all SRS:s provided?

Nope, that would mean listing 3000+ envelopes per layer, most of which we would not be able to compute due to their math breaking outside of their specific area of applicability. But I guess we'd end up with
a good 50 envelopes per layer nevertheless

Cheers
Andrea

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

[Arne_Kepp]

I agree with Andrea, there's no reasonable way to do this unless you specify what SRSs to list per layer. The list of supported SRSs by itself is enough to kill some clients, without multiplying it by the number of layers.

But lets take a step back, what are you trying to achieve, and in what timeframe?

In the "upcoming" GeoServer 2.0, GWC hooks straight into the catalog and has access to the classes that let it do transforms. So if you don't care about the getcapabilities response per se, the only component that is missing is a Wicket UI plugin that lets the user specify what SRSs GWC should enable for the layer or namespace/workspace.

-Arne

Per Engström wrote:

Hello list.

I've been working on GeoWebCache (GWC) for some time now and I've just come across a bit of a problem when caching layers with multiple projections (SRS:s). The problem occurs when the Capabillities document only specifies a BoundingBox for one SRS and not one BoundingBox for each SRS. This is ok according to OGC:s WMS spec 1.1.1:
"A server which has the ability to transform data to different SRSes *may* choose not to provide an explicit BoundingBox for every possible SRS available for each Layer. The server *should* provide BoundingBox information for at least the native SRS of the Layer."

As I understand this is the default behaviour of GeoServer.

However, GeoTools (GWC utilizes GeoTools for parsing the Capabilities document) is not able to recognize SRS:s that does not have a specified BoundingBox, thus GWC is unable to recognize and cache the layer in those projections.

My question is:
Is there a way to force GeoServer to provide a BoundingBox for all SRS:s provided?

Regards,
Per Engström

--
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers

[jive]

We could also fix the GeoTools parsing; if you have a specific capabilities document we could use to write a test case it would be good.

Jody

On Wed, Mar 11, 2009 at 2:50 AM, Per Engström <pereng@anonymised.com> wrote:

Hello list.

I’ve been working on GeoWebCache (GWC) for some time now and I’ve just come across a bit of a problem when caching layers with multiple projections (SRS:s). The problem occurs when the Capabillities document only specifies a BoundingBox for one SRS and not one BoundingBox for each SRS. This is ok according to OGC:s WMS spec 1.1.1:
“A server which has the ability to transform data to different SRSes may choose not to
provide an explicit BoundingBox for every possible SRS available for each Layer. The
server should provide BoundingBox information for at least the native SRS of the Layer.”

As I understand this is the default behaviour of GeoServer.

However, GeoTools (GWC utilizes GeoTools for parsing the Capabilities document) is not able to recognize SRS:s that does not have a specified BoundingBox, thus GWC is unable to recognize and cache the layer in those projections.

My question is:
Is there a way to force GeoServer to provide a BoundingBox for all SRS:s provided?

Regards,
Per Engström

---

---

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

[Per-Olof_Noren]

Hi

Jody Garnett skrev:

We could also fix the GeoTools parsing; if you have a specific capabilities document we could use to write a test case it would be good.

Jody

On Wed, Mar 11, 2009 at 2:50 AM, Per Engström <pereng@anonymised.com <mailto:pereng@anonymised.com>> wrote:

    Hello list.

    I've been working on GeoWebCache (GWC) for some time now and I've
    just come across a bit of a problem when caching layers with
    multiple projections (SRS:s). The problem occurs when the
    Capabillities document only specifies a BoundingBox for one SRS
    and not one BoundingBox for each SRS. This is ok according to
    OGC:s WMS spec 1.1.1:
    "A server which has the ability to transform data to different
    SRSes *may* choose not to provide an explicit BoundingBox for every possible SRS available
    for each Layer. The server *should* provide BoundingBox information for at least the
    native SRS of the Layer."

    As I understand this is the default behaviour of GeoServer.

    However, GeoTools (GWC utilizes GeoTools for parsing the
    Capabilities document) is not able to recognize SRS:s that does
    not have a specified BoundingBox, thus GWC is unable to recognize
    and cache the layer in those projections.

    My question is:
    Is there a way to force GeoServer to provide a BoundingBox for all
    SRS:s provided?

    Regards,
    Per Engström

Since Per and I have been working on dimensions support for geowebcache and actually already done changes to the geotools parser I think a parser change wont get us all the way.

To clarify the setup a bit
* geoserver (1.7.2) on one machine.
* geowebcache (ndims branch) on another machine.
* geowebcache is configured using GetCapabilitiesConfiguration against geoserver on the other machine.
* Geoserver is configured to supply data in WGS84, google and rt90 and sweref99tm (swedish grids).

In geowebcache
For all "world grid", wgs84 and google, the grid bounds used to create cache key is "known".
For all other layers we use boundingboxes as both grid and data bounds. In the future one would want to implement a way to configure grid bounds for arbitrary SRS:es in GWC.

When using this aproach against a WMS that actually do calculate and report bounding boxes for all delcared SRS:es, this aproach works fine.

So if it is possible to make geoserver calculate bounds for all the declared SRS:es when producing getCapabilities response it would be great. Just thought we'd ask if this feature is already in the works somewhere before taking a plunge into geoserver code base

Thanks in advance,
Per-Olof Norén

[Arne_Kepp]

Per-Olof Norén wrote:

Hi

Jody Garnett skrev:
  

We could also fix the GeoTools parsing; if you have a specific capabilities document we could use to write a test case it would be good.

Jody
    

<snip>

In the future one would want to implement a way to configure grid bounds for arbitrary SRS:es in GWC.

When using this aproach against a WMS that actually do calculate and report bounding boxes for all delcared SRS:es, this aproach works fine.

Regarding the future, I still think the *long* term solution is an AJAX interface, and you can do the reprojection of bounds there (automatically). There are lots of settings that you cannot read from a getcapabilities document, and it's a bit unfortunate that a power outage can reconfigure your server.

The SRS thing may be nice for other WMS clients anyway though, like OpenLayers.

-Arne

--
Arne Kepp
OpenGeo - http://opengeo.org
Expert service straight from the developers