[Geoserver-users] reconfiguring gewebcache for gda94

Dear GeoServers,

I am seeing some very odd behaviour when trying to use a previously working (but older) geowebcache.xml file in geoserver 2.0.2.

I have created a custom gridset to use EPSG:4283 (using a short gridset name of GDA94) in geowebcache.xml.

<?xml version="1.0" encoding="utf-8"?>

<gwcConfiguration xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance

xsi:noNamespaceSchemaLocation=“http://geowebcache.org/schema/1.2.0/geowebcache.xsd

xmlns=“http://geowebcache.org/schema/1.2.0”>

1.2.0

120

GDA94

4283

137.8125000-29.5751949

154.2041016-10.3271480

true

10

111226.31

512

512

topp:telascience

GDA94

0

9

http://localhost:8080/geoserver/wms

topp:telascience

topp:100ktopo

GDA94

0

9

http://localhost:8080/geoserver/wms

topp:100ktopo

tiger:common_estate_label

GDA94

0

9

http://localhost:8080/geoserver/wms

tiger:common_estate_label

tiger:common_estate

GDA94

0

9

http://localhost:8080/geoserver/wms

tiger:common_estate

tiger:common_town

GDA94

0

9

http://localhost:8080/geoserver/wms

tiger:common_town

This worked fine before upgrading to the current geoserver 2.0.2, except now I see the following in the GWC demo page –

topp:100ktopo
Seed this layer

EPSG:4283_topp:100kt… OpenLayers: [png, gif, png8, jpeg]
EPSG:4326 OpenLayers: [png, gif, png8, jpeg] KML: [png, gif, png8, jpeg, kml]
GDA94 OpenLayers: [png, gif, png8, jpeg]
EPSG:900913 OpenLayers: [png, gif, png8, jpeg]

Why has the EPSG:4283_topp:100kt… suddenly appeared when it is isn’t even listed in geowebcache.xml ?

I am also now seeing an error appearing in the geoserver.log file that the tilesize (512x512) does not match (256x256) ?

If I change the tilesize of course all the old tiles are now invalid and will need to be reseeded or generated on the fly.

Does anyone in Aus have a more local example of geowebcache.xml for GDA94 and do I need to be more specific about other parameters now in the config file ?

Many thanks,

Shaun

±---------------------------------------------------------------+

Think B4U Print

1 ream of paper = 6% of a tree and 5.4kg CO2 in the atmosphere

3 sheets of A4 paper = 1 litre of water

±---------------------------------------------------------------+

I think you forgot to tell us what the odd behaviour was?

I also note, from testing, that the geowebcache configuration shipped with geoserver 2.0.2 was not quite working; Arne applied some patches in order to get me a demo machine to test against.

Jody

On 22/08/2010, at 3:41 PM, Kolomeitz Shaun wrote:

Dear GeoServers,

I am seeing some very odd behaviour when trying to use a previously working (but older) geowebcache.xml file in geoserver 2.0.2.

I have created a custom gridset to use EPSG:4283 (using a short gridset name of GDA94) in geowebcache.xml.

<?xml version="1.0" encoding="utf-8"?>

<gwcConfiguration xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance

xsi:noNamespaceSchemaLocation=“http://geowebcache.org/schema/1.2.0/geowebcache.xsd

xmlns=“http://geowebcache.org/schema/1.2.0”>

1.2.0

120

GDA94

4283

137.8125000-29.5751949

154.2041016-10.3271480

true

10

111226.31

512

512

topp:telascience

GDA94

0

9

http://localhost:8080/geoserver/wms

topp:telascience

topp:100ktopo

GDA94

0

9

http://localhost:8080/geoserver/wms

topp:100ktopo

tiger:common_estate_label

GDA94

0

9

http://localhost:8080/geoserver/wms

tiger:common_estate_label

tiger:common_estate

GDA94

0

9

http://localhost:8080/geoserver/wms

tiger:common_estate

tiger:common_town

GDA94

0

9

http://localhost:8080/geoserver/wms

tiger:common_town

This worked fine before upgrading to the current geoserver 2.0.2, except now I see the following in the GWC demo page –

topp:100ktopo
Seed this layer

EPSG:4283_topp:100kt… OpenLayers: [png, gif, png8, jpeg]
EPSG:4326 OpenLayers: [png, gif, png8, jpeg] KML: [png, gif, png8, jpeg, kml]
GDA94 OpenLayers: [png, gif, png8, jpeg]
EPSG:900913 OpenLayers: [png, gif, png8, jpeg]

Why has the EPSG:4283_topp:100kt… suddenly appeared when it is isn’t even listed in geowebcache.xml ?

I am also now seeing an error appearing in the geoserver.log file that the tilesize (512x512) does not match (256x256) ?

If I change the tilesize of course all the old tiles are now invalid and will need to be reseeded or generated on the fly.

Does anyone in Aus have a more local example of geowebcache.xml for GDA94 and do I need to be more specific about other parameters now in the config file ?

Many thanks,

Shaun

±---------------------------------------------------------------+

Think B4U Print

1 ream of paper = 6% of a tree and 5.4kg CO2 in the atmosphere

3 sheets of A4 paper = 1 litre of water

±---------------------------------------------------------------+


This SF.net email is sponsored by

Make an app they can’t live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev _______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Jody,

Is it possible to get the patch (Arne ?), or am I better off trying to use geowebcache as a separate WAR ?

Sorry, the odd behaviour is that

  1. Geoserver is creating Directories in the disk cache called EPSG_4283_topp_100ktopo_01, 02 etc despite a custom Grid being defined “GDA94”

  2. Requests that used to work fine are now not working and return errors on the tilesize

  3. The GDA94 cache is used when I zoom down a few levels, and then suddenly geoserver creates directories called EPSG_4283_topp_100ktopo_04 and generates tiles in those. What the ???

I’d like to have a working disk cache again, but more importantly I’d like to be able to understand how the heck it is meant to be setup, because fairly obviously I am missing something with the custom grid. I’d like to remove the default 4326 and 900913 as we never use them.

I’ve been looking for a well explained working example as the docs really don’t cut it for me.

Regards,

Shaun


From: Jody Garnett [mailto:jody.garnett@anonymised.com]
Sent: Sunday, 22 August 2010 8:55 PM
To: Kolomeitz Shaun
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] reconfiguring gewebcache for gda94

I think you forgot to tell us what the odd behaviour was?

I also note, from testing, that the geowebcache configuration shipped with geoserver 2.0.2 was not quite working; Arne applied some patches in order to get me a demo machine to test against.

Jody

On 22/08/2010, at 3:41 PM, Kolomeitz Shaun wrote:

Dear GeoServers,

I am seeing some very odd behaviour when trying to use a previously working (but older) geowebcache.xml file in geoserver 2.0.2.

I have created a custom gridset to use EPSG:4283 (using a short gridset name of GDA94) in geowebcache.xml.

<?xml version="1.0" encoding="utf-8"?>

<gwcConfiguration xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance

xsi:noNamespaceSchemaLocation=“http://geowebcache.org/schema/1.2.0/geowebcache.xsd

xmlns=“http://geowebcache.org/schema/1.2.0”>

1.2.0

120

GDA94

4283

137.8125000-29.5751949

154.2041016-10.3271480

true

10

111226.31

512

512

topp:telascience

GDA94

0

9

http://localhost:8080/geoserver/wms

topp:telascience

topp:100ktopo

GDA94

0

9

http://localhost:8080/geoserver/wms

topp:100ktopo

tiger:common_estate_label

GDA94

0

9

http://localhost:8080/geoserver/wms

tiger:common_estate_label

tiger:common_estate

GDA94

0

9

http://localhost:8080/geoserver/wms

tiger:common_estate

tiger:common_town

GDA94

0

9

http://localhost:8080/geoserver/wms

tiger:common_town

This worked fine before upgrading to the current geoserver 2.0.2, except now I see the following in the GWC demo page –

topp:100ktopo
Seed this layer

EPSG:4283_topp:100kt… OpenLayers: [png, gif, png8, jpeg]
EPSG:4326 OpenLayers: [png, gif, png8, jpeg] KML: [png, gif, png8, jpeg, kml]
GDA94 OpenLayers: [png, gif, png8, jpeg]
EPSG:900913 OpenLayers: [png, gif, png8, jpeg]

Why has the EPSG:4283_topp:100kt… suddenly appeared when it is isn’t even listed in geowebcache.xml ?

I am also now seeing an error appearing in the geoserver.log file that the tilesize (512x512) does not match (256x256) ?

If I change the tilesize of course all the old tiles are now invalid and will need to be reseeded or generated on the fly.

Does anyone in Aus have a more local example of geowebcache.xml for GDA94 and do I need to be more specific about other parameters now in the config file ?

Many thanks,

Shaun

±---------------------------------------------------------------+

Think B4U Print

1 ream of paper = 6% of a tree and 5.4kg CO2 in the atmosphere

3 sheets of A4 paper = 1 litre of water

±---------------------------------------------------------------+


This SF.net email is sponsored by

Make an app they can’t live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev _______________________________________________
Geoserver-users mailing list
Geoserver-users@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

The bug reports are here:
- http://jira.codehaus.org/browse/UDIG-1705
- http://jira.codehaus.org/browse/GEOS-4076

The working server is:
- http://demo.opengeo.org/geoserver/gwc/service/wms?request=getcapabilities&tiled=true

Jody

On Mon, Aug 23, 2010 at 7:49 AM, Kolomeitz Shaun
<shaun.kolomeitz@anonymised.com> wrote:

Jody,

Is it possible to get the patch (Arne ?), or am I better off trying to use
geowebcache as a separate WAR ?

Sorry, the odd behaviour is that

1) Geoserver is creating Directories in the disk cache called
EPSG_4283_topp_100ktopo_01, 02 etc despite a custom Grid being defined
“GDA94”

2) Requests that used to work fine are now not working and return
errors on the tilesize

3) The GDA94 cache is used when I zoom down a few levels, and then
suddenly geoserver creates directories called EPSG_4283_topp_100ktopo_04 and
generates tiles in those. What the ???

I’d like to have a working disk cache again, but more importantly I’d like
to be able to understand how the heck it is meant to be setup, because
fairly obviously I am missing something with the custom grid. I’d like to
remove the default 4326 and 900913 as we never use them.

I’ve been looking for a well explained working example as the docs really
don’t cut it for me.

Regards,

Shaun

________________________________

From: Jody Garnett [mailto:jody.garnett@anonymised.com]
Sent: Sunday, 22 August 2010 8:55 PM
To: Kolomeitz Shaun

Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] reconfiguring gewebcache for gda94

I think you forgot to tell us what the odd behaviour was?

I also note, from testing, that the geowebcache configuration shipped with
geoserver 2.0.2 was not quite working; Arne applied some patches in order to
get me a demo machine to test against.

Jody

On 22/08/2010, at 3:41 PM, Kolomeitz Shaun wrote:

Dear GeoServers,

I am seeing some very odd behaviour when trying to use a previously working
(but older) geowebcache.xml file in geoserver 2.0.2.

I have created a custom gridset to use EPSG:4283 (using a short gridset name
of GDA94) in geowebcache.xml.

<?xml version="1.0" encoding="utf-8"?>

<gwcConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;

xsi:noNamespaceSchemaLocation="http://geowebcache.org/schema/1.2.0/geowebcache.xsd&quot;

xmlns="http://geowebcache.org/schema/1.2.0&quot;&gt;

<version>1.2.0</version>

<backendTimeout>120</backendTimeout>

<gridSets>

<gridSet>

<name>GDA94</name>

<srs><number>4283</number></srs>

<extent><coords>

&lt;double&gt;137\.8125000&lt;/double&gt;&lt;double&gt;\-29\.5751949&lt;/double&gt;

&lt;double&gt;154\.2041016&lt;/double&gt;&lt;double&gt;\-10\.3271480&lt;/double&gt;

</coords></extent>

<alignTopLeft>true</alignTopLeft>

<levels>10</levels>

<metersPerUnit>111226.31</metersPerUnit>

<tileHeight>512</tileHeight>

<tileWidth>512</tileWidth>

</gridSet>

</gridSets>

<layers>

<wmsLayer><name>topp:telascience</name>

<gridSubsets><gridSubset><gridSetName>GDA94</gridSetName>

&lt;zoomStart&gt;0&lt;/zoomStart&gt;

&lt;zoomStop&gt;9&lt;/zoomStop&gt;

</gridSubset></gridSubsets>

<wmsUrl><string>http://localhost:8080/geoserver/wms&lt;/string&gt;&lt;/wmsUrl&gt;

<wmsLayers>topp:telascience</wmsLayers>

</wmsLayer>

<wmsLayer><name>topp:100ktopo</name>

<gridSubsets><gridSubset><gridSetName>GDA94</gridSetName>

&lt;zoomStart&gt;0&lt;/zoomStart&gt;

&lt;zoomStop&gt;9&lt;/zoomStop&gt;

</gridSubset></gridSubsets>

<wmsUrl><string>http://localhost:8080/geoserver/wms&lt;/string&gt;&lt;/wmsUrl&gt;

<wmsLayers>topp:100ktopo</wmsLayers>

</wmsLayer>

<wmsLayer><name>tiger:common_estate_label</name>

<gridSubsets><gridSubset><gridSetName>GDA94</gridSetName>

&lt;zoomStart&gt;0&lt;/zoomStart&gt;

&lt;zoomStop&gt;9&lt;/zoomStop&gt;

</gridSubset></gridSubsets>

<wmsUrl><string>http://localhost:8080/geoserver/wms&lt;/string&gt;&lt;/wmsUrl&gt;

<wmsLayers>tiger:common_estate_label</wmsLayers>

</wmsLayer>

<wmsLayer><name>tiger:common_estate</name>

<gridSubsets><gridSubset><gridSetName>GDA94</gridSetName>

&lt;zoomStart&gt;0&lt;/zoomStart&gt;

&lt;zoomStop&gt;9&lt;/zoomStop&gt;

</gridSubset>

</gridSubsets>

<wmsUrl><string>http://localhost:8080/geoserver/wms&lt;/string&gt;&lt;/wmsUrl&gt;

<wmsLayers>tiger:common_estate</wmsLayers>

</wmsLayer>

<wmsLayer><name>tiger:common_town</name>

<gridSubsets><gridSubset> <gridSetName>GDA94</gridSetName>

&lt;zoomStart&gt;0&lt;/zoomStart&gt;

&lt;zoomStop&gt;9&lt;/zoomStop&gt;

</gridSubset>

</gridSubsets>

<wmsUrl><string>http://localhost:8080/geoserver/wms&lt;/string&gt;&lt;/wmsUrl&gt;

<wmsLayers>tiger:common_town</wmsLayers>

</wmsLayer>

</layers>

</gwcConfiguration>

This worked fine before upgrading to the current geoserver 2.0.2, except now
I see the following in the GWC demo page –

topp:100ktopo
Seed this layer

EPSG:4283_topp:100kt... OpenLayers: [png, gif, png8, jpeg]
EPSG:4326 OpenLayers: [png, gif, png8, jpeg] KML: [png, gif,
png8, jpeg, kml]
GDA94 OpenLayers: [png, gif, png8, jpeg]
EPSG:900913 OpenLayers: [png, gif, png8, jpeg]

Why has the EPSG:4283_topp:100kt… suddenly appeared when it is isn’t even
listed in geowebcache.xml ?

I am also now seeing an error appearing in the geoserver.log file that the
tilesize (512x512) does not match (256x256) ?

If I change the tilesize of course all the old tiles are now invalid and
will need to be reseeded or generated on the fly.

Does anyone in Aus have a more local example of geowebcache.xml for GDA94
and do I need to be more specific about other parameters now in the config
file ?

Many thanks,

Shaun

+----------------------------------------------------------------+

Think B4U Print

1 ream of paper = 6% of a tree and 5.4kg CO2 in the atmosphere

3 sheets of A4 paper = 1 litre of water

+----------------------------------------------------------------+

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
Best Open Source Mac Front-Ends 2024
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

  Jody: You are discussing this as if this is related to uDig / WMS-C getcapabilities, but I don't see Shaun going anywhere near that?

The embedded version of GWC tries to configure itself automatically based on the GeoServer catalog. My guess is that this is the layers you are seeing, and that your configuration file is not being picked up for some other reason. Check the logs right after startup, there should be an error message or something there.

I'm on vacation and a prepaid 3G account this week, I can have a closer look next week when I catch up on emails.
-Arne

On 8/23/10 3:25 AM, Jody Garnett wrote:

The bug reports are here:
- http://jira.codehaus.org/browse/UDIG-1705
- http://jira.codehaus.org/browse/GEOS-4076

The working server is:
- http://demo.opengeo.org/geoserver/gwc/service/wms?request=getcapabilities&tiled=true

Jody

On Mon, Aug 23, 2010 at 7:49 AM, Kolomeitz Shaun
<shaun.kolomeitz@anonymised.com> wrote:

Jody,

Is it possible to get the patch (Arne ?), or am I better off trying to use
geowebcache as a separate WAR ?

Sorry, the odd behaviour is that

1) Geoserver is creating Directories in the disk cache called
EPSG_4283_topp_100ktopo_01, 02 etc despite a custom Grid being defined
“GDA94”

2) Requests that used to work fine are now not working and return
errors on the tilesize

3) The GDA94 cache is used when I zoom down a few levels, and then
suddenly geoserver creates directories called EPSG_4283_topp_100ktopo_04 and
generates tiles in those. What the ???

I’d like to have a working disk cache again, but more importantly I’d like
to be able to understand how the heck it is meant to be setup, because
fairly obviously I am missing something with the custom grid. I’d like to
remove the default 4326 and 900913 as we never use them.

I’ve been looking for a well explained working example as the docs really
don’t cut it for me.

Regards,

Shaun

________________________________

From: Jody Garnett [mailto:jody.garnett@anonymised.com]
Sent: Sunday, 22 August 2010 8:55 PM
To: Kolomeitz Shaun

Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] reconfiguring gewebcache for gda94

I think you forgot to tell us what the odd behaviour was?

I also note, from testing, that the geowebcache configuration shipped with
geoserver 2.0.2 was not quite working; Arne applied some patches in order to
get me a demo machine to test against.

Jody

On 22/08/2010, at 3:41 PM, Kolomeitz Shaun wrote:

Dear GeoServers,

I am seeing some very odd behaviour when trying to use a previously working
(but older) geowebcache.xml file in geoserver 2.0.2.

I have created a custom gridset to use EPSG:4283 (using a short gridset name
of GDA94) in geowebcache.xml.

<?xml version="1.0" encoding="utf-8"?>

<gwcConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;

xsi:noNamespaceSchemaLocation="http://geowebcache.org/schema/1.2.0/geowebcache.xsd&quot;

   xmlns="http://geowebcache.org/schema/1.2.0&quot;&gt;

<version>1.2.0</version>

<backendTimeout>120</backendTimeout>

<gridSets>

  <gridSet>

   <name>GDA94</name>

   <srs><number>4283</number></srs>

   <extent><coords>

     <double>137.8125000</double><double>-29.5751949</double>

     <double>154.2041016</double><double>-10.3271480</double>

    </coords></extent>

   <alignTopLeft>true</alignTopLeft>

   <levels>10</levels>

   <metersPerUnit>111226.31</metersPerUnit>

   <tileHeight>512</tileHeight>

   <tileWidth>512</tileWidth>

  </gridSet>

</gridSets>

<layers>

  <wmsLayer><name>topp:telascience</name>

   <gridSubsets><gridSubset><gridSetName>GDA94</gridSetName>

     <zoomStart>0</zoomStart>

     <zoomStop>9</zoomStop>

    </gridSubset></gridSubsets>

   <wmsUrl><string>http://localhost:8080/geoserver/wms&lt;/string&gt;&lt;/wmsUrl&gt;

  <wmsLayers>topp:telascience</wmsLayers>

</wmsLayer>

<wmsLayer><name>topp:100ktopo</name>

   <gridSubsets><gridSubset><gridSetName>GDA94</gridSetName>

     <zoomStart>0</zoomStart>

     <zoomStop>9</zoomStop>

    </gridSubset></gridSubsets>

   <wmsUrl><string>http://localhost:8080/geoserver/wms&lt;/string&gt;&lt;/wmsUrl&gt;

   <wmsLayers>topp:100ktopo</wmsLayers>

</wmsLayer>

<wmsLayer><name>tiger:common_estate_label</name>

   <gridSubsets><gridSubset><gridSetName>GDA94</gridSetName>

     <zoomStart>0</zoomStart>

     <zoomStop>9</zoomStop>

    </gridSubset></gridSubsets>

   <wmsUrl><string>http://localhost:8080/geoserver/wms&lt;/string&gt;&lt;/wmsUrl&gt;

   <wmsLayers>tiger:common_estate_label</wmsLayers>

</wmsLayer>

<wmsLayer><name>tiger:common_estate</name>

   <gridSubsets><gridSubset><gridSetName>GDA94</gridSetName>

     <zoomStart>0</zoomStart>

     <zoomStop>9</zoomStop>

    </gridSubset>

   </gridSubsets>

   <wmsUrl><string>http://localhost:8080/geoserver/wms&lt;/string&gt;&lt;/wmsUrl&gt;

   <wmsLayers>tiger:common_estate</wmsLayers>

</wmsLayer>

<wmsLayer><name>tiger:common_town</name>

   <gridSubsets><gridSubset> <gridSetName>GDA94</gridSetName>

     <zoomStart>0</zoomStart>

     <zoomStop>9</zoomStop>

    </gridSubset>

   </gridSubsets>

   <wmsUrl><string>http://localhost:8080/geoserver/wms&lt;/string&gt;&lt;/wmsUrl&gt;

   <wmsLayers>tiger:common_town</wmsLayers>

</wmsLayer>

</layers>

</gwcConfiguration>

This worked fine before upgrading to the current geoserver 2.0.2, except now
I see the following in the GWC demo page –

topp:100ktopo
Seed this layer

EPSG:4283_topp:100kt... OpenLayers: [png, gif, png8, jpeg]
EPSG:4326 OpenLayers: [png, gif, png8, jpeg] KML: [png, gif,
png8, jpeg, kml]
GDA94 OpenLayers: [png, gif, png8, jpeg]
EPSG:900913 OpenLayers: [png, gif, png8, jpeg]

Why has the EPSG:4283_topp:100kt… suddenly appeared when it is isn’t even
listed in geowebcache.xml ?

I am also now seeing an error appearing in the geoserver.log file that the
tilesize (512x512) does not match (256x256) ?

If I change the tilesize of course all the old tiles are now invalid and
will need to be reseeded or generated on the fly.

Does anyone in Aus have a more local example of geowebcache.xml for GDA94
and do I need to be more specific about other parameters now in the config
file ?

Many thanks,

Shaun

+----------------------------------------------------------------+

Think B4U Print

1 ream of paper = 6% of a tree and 5.4kg CO2 in the atmosphere

3 sheets of A4 paper = 1 litre of water

+----------------------------------------------------------------+

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

------------------------------------------------------------------------------
This SF.net email is sponsored by

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

  Hi Shaun,

finally had a chance to look through it and try it. I don't really see a problem, but you probably have an (occasional) collision between what is configured automatically and what is configured from the XML file.

Change
<name>tiger:common_town</name>
to something else (tiger:common_town_cached), it'll probably make the problem disappear for good, and it'll be much easier to debug.

This is true in general, don't use the the same value in <name> as in <wmsLayers> unless you really know what you are doing.

-Arne

On 8/23/10 1:09 PM, Arne Kepp wrote:

   Jody: You are discussing this as if this is related to uDig / WMS-C
getcapabilities, but I don't see Shaun going anywhere near that?

The embedded version of GWC tries to configure itself automatically
based on the GeoServer catalog. My guess is that this is the layers you
are seeing, and that your configuration file is not being picked up for
some other reason. Check the logs right after startup, there should be
an error message or something there.

I'm on vacation and a prepaid 3G account this week, I can have a closer
look next week when I catch up on emails.
-Arne

On 8/23/10 3:25 AM, Jody Garnett wrote:

The bug reports are here:
- http://jira.codehaus.org/browse/UDIG-1705
- http://jira.codehaus.org/browse/GEOS-4076

The working server is:
- http://demo.opengeo.org/geoserver/gwc/service/wms?request=getcapabilities&tiled=true

Jody

On Mon, Aug 23, 2010 at 7:49 AM, Kolomeitz Shaun
<shaun.kolomeitz@anonymised.com> wrote:

Jody,

Is it possible to get the patch (Arne ?), or am I better off trying to use
geowebcache as a separate WAR ?

Sorry, the odd behaviour is that

1) Geoserver is creating Directories in the disk cache called
EPSG_4283_topp_100ktopo_01, 02 etc despite a custom Grid being defined
“GDA94”

2) Requests that used to work fine are now not working and return
errors on the tilesize

3) The GDA94 cache is used when I zoom down a few levels, and then
suddenly geoserver creates directories called EPSG_4283_topp_100ktopo_04 and
generates tiles in those. What the ???

I’d like to have a working disk cache again, but more importantly I’d like
to be able to understand how the heck it is meant to be setup, because
fairly obviously I am missing something with the custom grid. I’d like to
remove the default 4326 and 900913 as we never use them.

I’ve been looking for a well explained working example as the docs really
don’t cut it for me.

Regards,

Shaun

________________________________

From: Jody Garnett [mailto:jody.garnett@anonymised.com]
Sent: Sunday, 22 August 2010 8:55 PM
To: Kolomeitz Shaun

Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] reconfiguring gewebcache for gda94

I think you forgot to tell us what the odd behaviour was?

I also note, from testing, that the geowebcache configuration shipped with
geoserver 2.0.2 was not quite working; Arne applied some patches in order to
get me a demo machine to test against.

Jody

On 22/08/2010, at 3:41 PM, Kolomeitz Shaun wrote:

Dear GeoServers,

I am seeing some very odd behaviour when trying to use a previously working
(but older) geowebcache.xml file in geoserver 2.0.2.

I have created a custom gridset to use EPSG:4283 (using a short gridset name
of GDA94) in geowebcache.xml.

<?xml version="1.0" encoding="utf-8"?>

<gwcConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;

xsi:noNamespaceSchemaLocation="http://geowebcache.org/schema/1.2.0/geowebcache.xsd&quot;

    xmlns="http://geowebcache.org/schema/1.2.0&quot;&gt;

<version>1.2.0</version>

<backendTimeout>120</backendTimeout>

<gridSets>

   <gridSet>

    <name>GDA94</name>

    <srs><number>4283</number></srs>

    <extent><coords>

      <double>137.8125000</double><double>-29.5751949</double>

      <double>154.2041016</double><double>-10.3271480</double>

     </coords></extent>

    <alignTopLeft>true</alignTopLeft>

    <levels>10</levels>

    <metersPerUnit>111226.31</metersPerUnit>

    <tileHeight>512</tileHeight>

    <tileWidth>512</tileWidth>

   </gridSet>

</gridSets>

<layers>

   <wmsLayer><name>topp:telascience</name>

    <gridSubsets><gridSubset><gridSetName>GDA94</gridSetName>

      <zoomStart>0</zoomStart>

      <zoomStop>9</zoomStop>

     </gridSubset></gridSubsets>

    <wmsUrl><string>http://localhost:8080/geoserver/wms&lt;/string&gt;&lt;/wmsUrl&gt;

   <wmsLayers>topp:telascience</wmsLayers>

</wmsLayer>

<wmsLayer><name>topp:100ktopo</name>

    <gridSubsets><gridSubset><gridSetName>GDA94</gridSetName>

      <zoomStart>0</zoomStart>

      <zoomStop>9</zoomStop>

     </gridSubset></gridSubsets>

    <wmsUrl><string>http://localhost:8080/geoserver/wms&lt;/string&gt;&lt;/wmsUrl&gt;

    <wmsLayers>topp:100ktopo</wmsLayers>

</wmsLayer>

<wmsLayer><name>tiger:common_estate_label</name>

    <gridSubsets><gridSubset><gridSetName>GDA94</gridSetName>

      <zoomStart>0</zoomStart>

      <zoomStop>9</zoomStop>

     </gridSubset></gridSubsets>

    <wmsUrl><string>http://localhost:8080/geoserver/wms&lt;/string&gt;&lt;/wmsUrl&gt;

    <wmsLayers>tiger:common_estate_label</wmsLayers>

</wmsLayer>

<wmsLayer><name>tiger:common_estate</name>

    <gridSubsets><gridSubset><gridSetName>GDA94</gridSetName>

      <zoomStart>0</zoomStart>

      <zoomStop>9</zoomStop>

     </gridSubset>

    </gridSubsets>

    <wmsUrl><string>http://localhost:8080/geoserver/wms&lt;/string&gt;&lt;/wmsUrl&gt;

    <wmsLayers>tiger:common_estate</wmsLayers>

</wmsLayer>

<wmsLayer><name>tiger:common_town</name>

    <gridSubsets><gridSubset> <gridSetName>GDA94</gridSetName>

      <zoomStart>0</zoomStart>

      <zoomStop>9</zoomStop>

     </gridSubset>

    </gridSubsets>

    <wmsUrl><string>http://localhost:8080/geoserver/wms&lt;/string&gt;&lt;/wmsUrl&gt;

    <wmsLayers>tiger:common_town</wmsLayers>

</wmsLayer>

</layers>

</gwcConfiguration>