[Geoserver-users] Feature caching

[Lee_Wai_See]

Hi all,

We need to do something like this:

1. Get all features of a feature type from geoserver and this is done on the client side in a jsp
2. Cache the features on the client side (as the features for each client will be different for some reason)
3. Perform a getFeatureInfo from the cache after some time and display a result on the jsp based on the result of the getFeatureInfo query

I am not sure whether I am making sense, but would the above be possible? If yes, how could we go about doing it? How should the cache be implemented and how to get the feature information from the cache? (P/S: It would not be possible to do the cache as a database table or view as this is result in us having as many tables/views as the number of clients.)

Any help on this would be greatly appreciated as we are running out of ideas!

Regards,
Lee Wai See

[This e-mail is confidential and may be priviledged. If you are not the
intended recipient, please kindly notify us immediately and delete the message
from your system; please do not copy or use it for any purpose, nor disclose
its contents to any other person. Thank you.]
---ST Electronics Group---

–
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.411 / Virus Database: 268.17.30/674 - Release Date: 2/7/2007

[Andrea_Aime3]

Lee Wai See ha scritto:

Hi all,

We need to do something like this:

   1. Get all features of a feature type from geoserver and this is done
      on the client side in a jsp
   2. Cache the features on the client side (as the features for each
      client will be different for some reason)
   3. Perform a getFeatureInfo from the cache after some time and
      display a result on the jsp based on the result of the
      getFeatureInfo query

I am not sure whether I am making sense, but would the above be possible? If yes, how could we go about doing it? How should the cache be implemented and how to get the feature information from the cache? (P/S: It would not be possible to do the cache as a database table or view as this is result in us having as many tables/views as the number of clients.)

If you need to run a GetFeatureInfo, you need Geoserver on the client side too (the GetFeatureInfo code is in the WMS plugin...).
Having as many tables as the clients should not really be an issue for
any serious database, thought I would put them in a different namespace.
I don't really know your setup, but the cache makes me think you
either need a snapshot of data on the client side, or the web server that represents your client side is remote, thus it's inefficient to
query. In both cases, you could do the following:
* have a remote/master and a local/cache Geoserver (one server side,
   one in your webapp)
* query your remote/master Geoserver with a GetFeature, and ask for a
   compressed shapefile to be returned;
* store the shapefile on the client side server, and build all the
   files needed to configure it in the client side Geoserver
* reload the client side Geoserver catalog (and hope you don't have to
   do this often, since it may break concurrent requests afaik)
* have the jsp work against your local cache

Would this work?
Cheers
Andrea

[Lee_Wai_See]

Hi Andrea,

Thanks for your reply.

but the cache makes me think you
either need a snapshot of data on the client side

You are right, this is exactly what I need. Please bear with me but I have
some questions on your suggestion.

* have a remote/master and a local/cache Geoserver (one server side,
   one in your webapp)

How do you put a GeoServer in your webapp?

* query your remote/master Geoserver with a GetFeature, and ask for a
   compressed shapefile to be returned;

How do you ask for a compressed shapefile to be returned?

* store the shapefile on the client side server, and build all the
   files needed to configure it in the client side Geoserver

What do you mean by building all the files need to configure the shapefile
in the client side GeoServer, and what are the files needed? How do you
configure the files?

* reload the client side Geoserver catalog (and hope you don't have to
   do this often, since it may break concurrent requests afaik)

What is the GeoServer catalog and how do you reload it? Is 30 seconds
considered too often or does this have to depend on situations?

Regards,
Wai See

Lee Wai See ha scritto:

Hi all,

We need to do something like this:

   1. Get all features of a feature type from geoserver and this is done
      on the client side in a jsp
   2. Cache the features on the client side (as the features for each
      client will be different for some reason)
   3. Perform a getFeatureInfo from the cache after some time and
      display a result on the jsp based on the result of the
      getFeatureInfo query

I am not sure whether I am making sense, but would the above be
possible? If yes, how could we go about doing it? How should the cache
be implemented and how to get the feature information from the cache?
(P/S: It would not be possible to do the cache as a database table or
view as this is result in us having as many tables/views as the number
of clients.)

If you need to run a GetFeatureInfo, you need Geoserver on the client
side too (the GetFeatureInfo code is in the WMS plugin...).
Having as many tables as the clients should not really be an issue for
any serious database, thought I would put them in a different namespace.
I don't really know your setup, but the cache makes me think you
either need a snapshot of data on the client side, or the web server
that represents your client side is remote, thus it's inefficient to
query. In both cases, you could do the following:
* have a remote/master and a local/cache Geoserver (one server side,
   one in your webapp)
* query your remote/master Geoserver with a GetFeature, and ask for a
   compressed shapefile to be returned;
* store the shapefile on the client side server, and build all the
   files needed to configure it in the client side Geoserver
* reload the client side Geoserver catalog (and hope you don't have to
   do this often, since it may break concurrent requests afaik)
* have the jsp work against your local cache

Would this work?
Cheers
Andrea

[This e-mail is confidential and may be priviledged. If you are not the
intended recipient, please kindly notify us immediately and delete the message
from your system; please do not copy or use it for any purpose, nor disclose
its contents to any other person. Thank you.]
---ST Electronics Group---

[Andrea_Aime3]

leewse@anonymised.com ha scritto:

Hi Andrea,

Thanks for your reply.

but the cache makes me think you
either need a snapshot of data on the client side

You are right, this is exactly what I need. Please bear with me but I have
some questions on your suggestion.

* have a remote/master and a local/cache Geoserver (one server side,
   one in your webapp)

How do you put a GeoServer in your webapp?

Well, I wish I had a guide... I never did that, but if I were to, I would probably do it by taking the war contents, adding it to my web app, and merge the two web.xml. You may have to strip out the user interface.
As an easier alternative, you can install Geoserver alongside your app, in the same container, no?

* query your remote/master Geoserver with a GetFeature, and ask for a
   compressed shapefile to be returned;

How do you ask for a compressed shapefile to be returned?

Ask for the SHAPE-ZIP format. Example:

<wfs:GetFeature service="WFS" version="1.0.0"
   outputFormat="SHAPE-ZIP"
   xmlns:topp="http://www.openplans.org/topp&quot;
   xmlns:wfs="http://www.opengis.net/wfs&quot;
   xmlns:ogc="http://www.opengis.net/ogc&quot;
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;
   xsi:schemaLocation="http://www.opengis.net/wfs
                       http://schemas.opengis.net/wfs/1.0.0/WFS-basic.xsd&quot;&gt;
   <wfs:Query typeName="topp:states">
     <ogc:Filter>
        <ogc:FeatureId fid="states.3"/>
     </ogc:Filter>
     </wfs:Query>
</wfs:GetFeature>

* store the shapefile on the client side server, and build all the
   files needed to configure it in the client side Geoserver

What do you mean by building all the files need to configure the shapefile
in the client side GeoServer, and what are the files needed? How do you
configure the files?

You have to create them by hand unfortunately. The files are the info.xml that describes your new feature type, and the catalog.xml to make the feature type known. As an alternative, you could do the same
by making HTTP calls to the user interface (mimicking a user hitting
the user interface, these are just POST requests anyways).

* reload the client side Geoserver catalog (and hope you don't have to
   do this often, since it may break concurrent requests afaik)

What is the GeoServer catalog and how do you reload it? Is 30 seconds
considered too often or does this have to depend on situations?

30 seconds is quite often, yes. But if you don't need to persist the
changes (so that they can survive a server restart) then making POST requests that do configure the new feature type, and then another to
"apply" you changes just to the in-memory version of your catalog should
be enough.
I don't have a guide about making the requests, just look at the various
UI forms and set up requests that do have the same fields.

Hope this helps.
Cheers
Andrea

[Lee_Wai_See]

leewse@anonymised.com ha scritto:

Hi Andrea,

Thanks for your reply.

but the cache makes me think you
either need a snapshot of data on the client side

You are right, this is exactly what I need. Please bear with me but I
have
some questions on your suggestion.

* have a remote/master and a local/cache Geoserver (one server side,
   one in your webapp)

How do you put a GeoServer in your webapp?

Well, I wish I had a guide... I never did that, but if I were to, I
would probably do it by taking the war contents, adding it to my web
app, and merge the two web.xml. You may have to strip out the user
interface.
As an easier alternative, you can install Geoserver alongside your app,
in the same container, no?

We currently have GeoServer and the webapp in a same Tomcat server. But of
course the two are deployed as two separate applications, with its own
web.xml each. Is this what you are referring to - GeoServer and app in the
same container?

* query your remote/master Geoserver with a GetFeature, and ask for a
   compressed shapefile to be returned;

How do you ask for a compressed shapefile to be returned?

Ask for the SHAPE-ZIP format. Example:

<wfs:GetFeature service="WFS" version="1.0.0"
   outputFormat="SHAPE-ZIP"
   xmlns:topp="http://www.openplans.org/topp&quot;
   xmlns:wfs="http://www.opengis.net/wfs&quot;
   xmlns:ogc="http://www.opengis.net/ogc&quot;
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;
   xsi:schemaLocation="http://www.opengis.net/wfs
                       http://schemas.opengis.net/wfs/1.0.0/WFS-basic.xsd&quot;&gt;
   <wfs:Query typeName="topp:states">
     <ogc:Filter>
        <ogc:FeatureId fid="states.3"/>
     </ogc:Filter>
     </wfs:Query>
</wfs:GetFeature>

Testing with your above query is fine. Bu when I tried using SHAPE-ZIP
output format with my feature type on the GeoServer demo page, but I got
this error:

org.vfny.geoserver.wfs.WfsException: java.io.IOException: Unable to write
: java.math.BigDecimal
  at
org.vfny.geoserver.wfs.WfsExceptionHandler.newServiceException(WfsExceptionHandler.java:65)
  at
org.vfny.geoserver.servlets.AbstractService.sendError(AbstractService.java:839)
  at
org.vfny.geoserver.servlets.AbstractService.doService(AbstractService.java:583)
  at
org.vfny.geoserver.servlets.AbstractService.doPost(AbstractService.java:436)
  at org.geoserver.request.Dispatcher.post(Dispatcher.java:273)
  at org.geoserver.request.Dispatcher.dispatch(Dispatcher.java:163)
  at
org.geoserver.request.Dispatcher.handleRequestInternal(Dispatcher.java:56)
  at
org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:139)
  at
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:44)
  at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:684)
  at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:625)
  at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:392)
  at
org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:357)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
  at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
  at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
  at
org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:122)
  at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186)
  at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
  at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
  at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
  at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
  at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
  at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
  at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
  at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
  at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
  at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
  at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118)
  at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
  at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
  at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
  at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
  at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
  at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
  at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
  at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
  at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
  at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
  at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
  at java.lang.Thread.run(Thread.java:534)
Caused by: java.io.IOException: Unable to write : java.math.BigDecimal
  at
org.geotools.data.shapefile.ShapefileDataStore.createDbaseHeader(ShapefileDataStore.java:1046)
  at
org.geotools.data.shapefile.ShapefileDataStore.createSchema(ShapefileDataStore.java:769)
  at
org.vfny.geoserver.wfs.responses.ShapeFeatureResponseDelegate.writeOut(ShapeFeatureResponseDelegate.java:301)
  at
org.vfny.geoserver.wfs.responses.ShapeFeatureResponseDelegate.encode(ShapeFeatureResponseDelegate.java:217)
  at
org.vfny.geoserver.wfs.responses.FeatureResponse.writeTo(FeatureResponse.java:139)
  at
org.vfny.geoserver.servlets.AbstractService.doService(AbstractService.java:572)
  ... 39 more

* store the shapefile on the client side server, and build all the
   files needed to configure it in the client side Geoserver

What do you mean by building all the files need to configure the
shapefile
in the client side GeoServer, and what are the files needed? How do you
configure the files?

You have to create them by hand unfortunately. The files are the
info.xml that describes your new feature type, and the catalog.xml to
make the feature type known. As an alternative, you could do the same
by making HTTP calls to the user interface (mimicking a user hitting
the user interface, these are just POST requests anyways).

Does this mean that each client should have its own GeoServer? We need it
to be such that each client, though accessing the same webapp, have its
own snapshot of the data which is changing dynamically. Will this approach
enable this?

* reload the client side Geoserver catalog (and hope you don't have to
   do this often, since it may break concurrent requests afaik)

What is the GeoServer catalog and how do you reload it? Is 30 seconds
considered too often or does this have to depend on situations?

30 seconds is quite often, yes. But if you don't need to persist the
changes (so that they can survive a server restart) then making POST
requests that do configure the new feature type, and then another to
"apply" you changes just to the in-memory version of your catalog should
be enough.
I don't have a guide about making the requests, just look at the various
UI forms and set up requests that do have the same fields.

Hope this helps.
Cheers
Andrea

[This e-mail is confidential and may be priviledged. If you are not the
intended recipient, please kindly notify us immediately and delete the message
from your system; please do not copy or use it for any purpose, nor disclose
its contents to any other person. Thank you.]
---ST Electronics Group---

[Andrea_Aime3]

leewse@anonymised.com ha scritto:

leewse@anonymised.com ha scritto:

...

As an easier alternative, you can install Geoserver alongside your app,
in the same container, no?

We currently have GeoServer and the webapp in a same Tomcat server. But of
course the two are deployed as two separate applications, with its own
web.xml each. Is this what you are referring to - GeoServer and app in the
same container?

Yes

* query your remote/master Geoserver with a GetFeature, and ask for a
   compressed shapefile to be returned;

How do you ask for a compressed shapefile to be returned?

Ask for the SHAPE-ZIP format. Example:

<wfs:GetFeature service="WFS" version="1.0.0"
   outputFormat="SHAPE-ZIP"
   xmlns:topp="http://www.openplans.org/topp&quot;
   xmlns:wfs="http://www.opengis.net/wfs&quot;
   xmlns:ogc="http://www.opengis.net/ogc&quot;
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;
   xsi:schemaLocation="http://www.opengis.net/wfs
                       http://schemas.opengis.net/wfs/1.0.0/WFS-basic.xsd&quot;&gt;
   <wfs:Query typeName="topp:states">
     <ogc:Filter>
        <ogc:FeatureId fid="states.3"/>
     </ogc:Filter>
     </wfs:Query>
</wfs:GetFeature>

Testing with your above query is fine. Bu when I tried using SHAPE-ZIP
output format with my feature type on the GeoServer demo page, but I got
this error:

org.vfny.geoserver.wfs.WfsException: java.io.IOException: Unable to write
: java.math.BigDecimal
  at
org.vfny.geoserver.wfs.WfsExceptionHandler.newServiceException(WfsExceptionHandler.java:65)
  at

Ouch, apparently the central datastore spits out BigDecimals, and shapefile datastore is apparently not able to write them down.
This seems http://jira.codehaus.org/browse/GEOT-960, which has been
fixed quite some time ago, both geoserver 1.4.0 and 1.5.rc1 should have
the fix in. What is the Geoserver version you're using? Can't remember.

* store the shapefile on the client side server, and build all the
   files needed to configure it in the client side Geoserver

What do you mean by building all the files need to configure the
shapefile
in the client side GeoServer, and what are the files needed? How do you
configure the files?

You have to create them by hand unfortunately. The files are the
info.xml that describes your new feature type, and the catalog.xml to
make the feature type known. As an alternative, you could do the same
by making HTTP calls to the user interface (mimicking a user hitting
the user interface, these are just POST requests anyways).

Does this mean that each client should have its own GeoServer? We need it
to be such that each client, though accessing the same webapp, have its
own snapshot of the data which is changing dynamically. Will this approach
enable this?

There is probably a misundertanding here. What do you mean by client?
I imagined a situation like this:

+-----------+ +-----------------------------+
| CENTRAL | slow/public netwrk | REMOTE WEBAPP WITH YOUR APP |
| GEOSERVER |--------------------| AND GEOSERVER FOR CACHING |---
+-----------+ +-----------------------------+

If this is your case, then you need one geoserver for each remote
webapp, and one shapefile cache for each user. If on the contrary
I misunderstood, and you have a single central webapp, then the
geoserver running alongside it is enough, you just need a snapshot saved as a shapefile for each client.

Cheers
Andrea

[Lee_Wai_See]

Hi Andrea,

Thanks for your patience. Please see below.

leewse@anonymised.com ha scritto:

leewse@anonymised.com ha scritto:

...

As an easier alternative, you can install Geoserver alongside your app,
in the same container, no?

We currently have GeoServer and the webapp in a same Tomcat server. But
of
course the two are deployed as two separate applications, with its own
web.xml each. Is this what you are referring to - GeoServer and app in
the
same container?

Yes

* query your remote/master Geoserver with a GetFeature, and ask for a
   compressed shapefile to be returned;

How do you ask for a compressed shapefile to be returned?

Ask for the SHAPE-ZIP format. Example:

<wfs:GetFeature service="WFS" version="1.0.0"
   outputFormat="SHAPE-ZIP"
   xmlns:topp="http://www.openplans.org/topp&quot;
   xmlns:wfs="http://www.opengis.net/wfs&quot;
   xmlns:ogc="http://www.opengis.net/ogc&quot;
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;
   xsi:schemaLocation="http://www.opengis.net/wfs
                       http://schemas.opengis.net/wfs/1.0.0/WFS-basic.xsd&quot;&gt;
   <wfs:Query typeName="topp:states">
     <ogc:Filter>
        <ogc:FeatureId fid="states.3"/>
     </ogc:Filter>
     </wfs:Query>
</wfs:GetFeature>

Testing with your above query is fine. Bu when I tried using SHAPE-ZIP
output format with my feature type on the GeoServer demo page, but I got
this error:

org.vfny.geoserver.wfs.WfsException: java.io.IOException: Unable to
write
: java.math.BigDecimal
  at
org.vfny.geoserver.wfs.WfsExceptionHandler.newServiceException(WfsExceptionHandler.java:65)
  at

Ouch, apparently the central datastore spits out BigDecimals, and
shapefile datastore is apparently not able to write them down.
This seems http://jira.codehaus.org/browse/GEOT-960, which has been
fixed quite some time ago, both geoserver 1.4.0 and 1.5.rc1 should have
the fix in. What is the Geoserver version you're using? Can't remember.

I am using 1.4.0. However, now peculiarly, I am not able to replicate this
exception. Instead I got another one as below. I tried using various
feature types of mine but all gave me the same exception. I cannot find
the wfsshp5 folder in my GeoServer deployment, much less the xxx.prj
files. What am I not doing correct here?

org.vfny.geoserver.wfs.WfsException: java.io.FileNotFoundException:
C:\Program Files\Apache Software Foundation\Tomcat 5.0\wfsshp5\street.prj
(The system cannot find the file specified)
  at
org.vfny.geoserver.wfs.WfsExceptionHandler.newServiceException(WfsExceptionHandler.java:65)
  at
org.vfny.geoserver.servlets.AbstractService.sendError(AbstractService.java:881)
  at
org.vfny.geoserver.servlets.AbstractService.doService(AbstractService.java:607)
  at
org.vfny.geoserver.servlets.AbstractService.doPost(AbstractService.java:454)
  at org.geoserver.request.Dispatcher.post(Dispatcher.java:278)
  at org.geoserver.request.Dispatcher.dispatch(Dispatcher.java:173)
  at
org.geoserver.request.Dispatcher.handleRequestInternal(Dispatcher.java:58)
  at
org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:139)
  at
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:44)
  at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:684)
  at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:625)
  at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:392)
  at
org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:357)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
  at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
  at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
  at
org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:122)
  at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186)
  at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
  at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
  at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
  at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
  at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
  at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
  at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
  at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
  at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
  at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
  at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118)
  at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
  at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
  at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
  at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
  at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
  at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
  at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
  at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
  at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
  at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
  at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
  at java.lang.Thread.run(Thread.java:534)
Caused by: java.io.FileNotFoundException: C:\Program Files\Apache Software
Foundation\Tomcat 5.0\wfsshp5\street.prj (The system cannot find the file
specified)
  at java.io.FileInputStream.open(Native Method)
  at java.io.FileInputStream.<init>(FileInputStream.java:106)
  at
org.vfny.geoserver.wfs.responses.ShapeFeatureResponseDelegate.encode(ShapeFeatureResponseDelegate.java:256)
  at
org.vfny.geoserver.wfs.responses.FeatureResponse.writeTo(FeatureResponse.java:140)
  at
org.vfny.geoserver.servlets.AbstractService.doService(AbstractService.java:594)
  ... 39 more

* store the shapefile on the client side server, and build all the
   files needed to configure it in the client side Geoserver

What do you mean by building all the files need to configure the
shapefile
in the client side GeoServer, and what are the files needed? How do
you
configure the files?

You have to create them by hand unfortunately. The files are the
info.xml that describes your new feature type, and the catalog.xml to
make the feature type known. As an alternative, you could do the same
by making HTTP calls to the user interface (mimicking a user hitting
the user interface, these are just POST requests anyways).

Does this mean that each client should have its own GeoServer? We need
it
to be such that each client, though accessing the same webapp, have its
own snapshot of the data which is changing dynamically. Will this
approach
enable this?

There is probably a misundertanding here. What do you mean by client?
I imagined a situation like this:

+-----------+ +-----------------------------+
| CENTRAL | slow/public netwrk | REMOTE WEBAPP WITH YOUR APP |
| GEOSERVER |--------------------| AND GEOSERVER FOR CACHING |---
+-----------+ +-----------------------------+

If this is your case, then you need one geoserver for each remote
webapp, and one shapefile cache for each user. If on the contrary
I misunderstood, and you have a single central webapp, then the
geoserver running alongside it is enough, you just need a snapshot saved
as a shapefile for each client.

Sorry for the confusion here. I think you did not misunderstand me. It was
just me not getting the correct picture. Please see below to make sure
that I am getting you right.

+-----------+ +----------------------------+
| CENTRAL | slow/public netwrk | REMOTE CLIENT BROWSER WITH |
| GEOSERVER |--------------------| OWN SHAPEFILE SNAPSHOT |---
| AND MY | +----------------------------+
| SINGLE | slow/public netwrk +----------------------------+
| WEBAPP |--------------------| REMOTE CLIENT BROWSER WITH |
+-----------+ | OWN SHAPEFILE SNAPSHOT |---
                                 +----------------------------+

If this is the case, then I am confused again.

1. Where is the shapefile for each browser client stored?

2. And how do I do a getFeatureInfo from the shapefile snapshot - does my
remote client still make a getFeatureInfo query to the central GeoServer?

3. If the shapefile for each browser client is stored on the central
GeoServer, would that mean I would have multiple new features for as many
clients as I have?

Once again, thank you so much for your time and patience.

Cheers
Andrea

[This e-mail is confidential and may be priviledged. If you are not the
intended recipient, please kindly notify us immediately and delete the message
from your system; please do not copy or use it for any purpose, nor disclose
its contents to any other person. Thank you.]
---ST Electronics Group---

[Andrea_Aime3]

leewse@anonymised.com ha scritto:

Hi Andrea,

Thanks for your patience. Please see below.

leewse@anonymised.com ha scritto:

leewse@anonymised.com ha scritto:

...

As an easier alternative, you can install Geoserver alongside your app,
in the same container, no?

We currently have GeoServer and the webapp in a same Tomcat server. But
of
course the two are deployed as two separate applications, with its own
web.xml each. Is this what you are referring to - GeoServer and app in
the
same container?

Yes

* query your remote/master Geoserver with a GetFeature, and ask for a
   compressed shapefile to be returned;

How do you ask for a compressed shapefile to be returned?

Ask for the SHAPE-ZIP format. Example:

<wfs:GetFeature service="WFS" version="1.0.0"
   outputFormat="SHAPE-ZIP"
   xmlns:topp="http://www.openplans.org/topp&quot;
   xmlns:wfs="http://www.opengis.net/wfs&quot;
   xmlns:ogc="http://www.opengis.net/ogc&quot;
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;
   xsi:schemaLocation="http://www.opengis.net/wfs
                       http://schemas.opengis.net/wfs/1.0.0/WFS-basic.xsd&quot;&gt;
   <wfs:Query typeName="topp:states">
     <ogc:Filter>
        <ogc:FeatureId fid="states.3"/>
     </ogc:Filter>
     </wfs:Query>
</wfs:GetFeature>

Testing with your above query is fine. Bu when I tried using SHAPE-ZIP
output format with my feature type on the GeoServer demo page, but I got
this error:

org.vfny.geoserver.wfs.WfsException: java.io.IOException: Unable to
write
: java.math.BigDecimal
  at
org.vfny.geoserver.wfs.WfsExceptionHandler.newServiceException(WfsExceptionHandler.java:65)
  at

Ouch, apparently the central datastore spits out BigDecimals, and
shapefile datastore is apparently not able to write them down.
This seems http://jira.codehaus.org/browse/GEOT-960, which has been
fixed quite some time ago, both geoserver 1.4.0 and 1.5.rc1 should have
the fix in. What is the Geoserver version you're using? Can't remember.

I am using 1.4.0. However, now peculiarly, I am not able to replicate this
exception. Instead I got another one as below. I tried using various
feature types of mine but all gave me the same exception. I cannot find
the wfsshp5 folder in my GeoServer deployment, much less the xxx.prj
files. What am I not doing correct here?

Frankly, I got no idea...
You did cut the stack trace, I need the full version of it (there
should be a "Caused by" exception somewhere).

Sorry for the confusion here. I think you did not misunderstand me. It was
just me not getting the correct picture. Please see below to make sure
that I am getting you right.

+-----------+ +----------------------------+
| CENTRAL | slow/public netwrk | REMOTE CLIENT BROWSER WITH |
| GEOSERVER |--------------------| OWN SHAPEFILE SNAPSHOT |---
| AND MY | +----------------------------+
| SINGLE | slow/public netwrk +----------------------------+
| WEBAPP |--------------------| REMOTE CLIENT BROWSER WITH |
+-----------+ | OWN SHAPEFILE SNAPSHOT |---
                                 +----------------------------+

Nope, this won't work at all. The shapefile must be stored on the
same machine as Geoserver, otherwise Geoserver won't be able to access it.
What you can do is:

  +-----------+ +----------------------------+
  | CENTRAL | slow/public netwrk | REMOTE CLIENT BROWSER |
  | GEOSERVER |--------------------| |---
  | AND MY | +----------------------------+
  | SINGLE | slow/public netwrk +----------------------------+
  | WEBAPP |--------------------| REMOTE CLIENT BROWSER |
  +-----------+ | |---
                                   +----------------------------+

with your central geoserver keeping a shapefile snapshot for each client on the server. This would give you a private snapshot for each client,
but no speedups whatsoever.

Cheers
Andrea

[Lee_Wai_See]

Hi Andrea,

Please see below. Thanks very much.

Regards,
Lee Wai See

-----Original Message-----
From: geoserver-users-bounces@lists.sourceforge.net
[mailto:geoserver-users-bounces@lists.sourceforge.net] On Behalf Of Andrea
Aime
Sent: Tuesday, February 13, 2007 7:29 PM
To: leewse@...440...
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] Feature caching

leewse@...440... ha scritto:

Hi Andrea,

Thanks for your patience. Please see below.

leewse@...440... ha scritto:

leewse@...440... ha scritto:

...

As an easier alternative, you can install Geoserver alongside your app,
in the same container, no?

We currently have GeoServer and the webapp in a same Tomcat server. But
of
course the two are deployed as two separate applications, with its own
web.xml each. Is this what you are referring to - GeoServer and app in
the
same container?

Yes

* query your remote/master Geoserver with a GetFeature, and ask for a
   compressed shapefile to be returned;

How do you ask for a compressed shapefile to be returned?

Ask for the SHAPE-ZIP format. Example:

<wfs:GetFeature service="WFS" version="1.0.0"
   outputFormat="SHAPE-ZIP"
   xmlns:topp="http://www.openplans.org/topp&quot;
   xmlns:wfs="http://www.opengis.net/wfs&quot;
   xmlns:ogc="http://www.opengis.net/ogc&quot;
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance&quot;
   xsi:schemaLocation="http://www.opengis.net/wfs

http://schemas.opengis.net/wfs/1.0.0/WFS-basic.xsd&quot;&gt;

   <wfs:Query typeName="topp:states">
     <ogc:Filter>
        <ogc:FeatureId fid="states.3"/>
     </ogc:Filter>
     </wfs:Query>
</wfs:GetFeature>

Testing with your above query is fine. Bu when I tried using SHAPE-ZIP
output format with my feature type on the GeoServer demo page, but I got
this error:

org.vfny.geoserver.wfs.WfsException: java.io.IOException: Unable to
write
: java.math.BigDecimal
  at

org.vfny.geoserver.wfs.WfsExceptionHandler.newServiceException(WfsExceptionH
andler.java:65)

  at

Ouch, apparently the central datastore spits out BigDecimals, and
shapefile datastore is apparently not able to write them down.
This seems http://jira.codehaus.org/browse/GEOT-960, which has been
fixed quite some time ago, both geoserver 1.4.0 and 1.5.rc1 should have
the fix in. What is the Geoserver version you're using? Can't remember.

I am using 1.4.0. However, now peculiarly, I am not able to replicate this
exception. Instead I got another one as below. I tried using various
feature types of mine but all gave me the same exception. I cannot find
the wfsshp5 folder in my GeoServer deployment, much less the xxx.prj
files. What am I not doing correct here?

Frankly, I got no idea...
You did cut the stack trace, I need the full version of it (there
should be a "Caused by" exception somewhere).

I did include the "Caused by" exception. Anyway, here it is again. By the
way, this is the only exception I got for this problem.

Caused by: java.io.FileNotFoundException: C:\Program Files\Apache Software
Foundation\Tomcat 5.0\wfsshp5\street.prj (The system cannot find the file
specified)
        at java.io.FileInputStream.open(Native Method)
        at java.io.FileInputStream.<init>(FileInputStream.java:106)
        at
org.vfny.geoserver.wfs.responses.ShapeFeatureResponseDelegate.encode(ShapeFe
atureResponseDelegate.java:256)
        at
org.vfny.geoserver.wfs.responses.FeatureResponse.writeTo(FeatureResponse.jav
a:140)
        at
org.vfny.geoserver.servlets.AbstractService.doService(AbstractService.java:5
94)
        ... 39 more

Sorry for the confusion here. I think you did not misunderstand me. It was
just me not getting the correct picture. Please see below to make sure
that I am getting you right.

+-----------+ +----------------------------+
| CENTRAL | slow/public netwrk | REMOTE CLIENT BROWSER WITH |
| GEOSERVER |--------------------| OWN SHAPEFILE SNAPSHOT |---
| AND MY | +----------------------------+
| SINGLE | slow/public netwrk +----------------------------+
| WEBAPP |--------------------| REMOTE CLIENT BROWSER WITH |
+-----------+ | OWN SHAPEFILE SNAPSHOT |---
                                 +----------------------------+

Nope, this won't work at all. The shapefile must be stored on the
same machine as Geoserver, otherwise Geoserver won't be able to access it.
What you can do is:

  +-----------+ +----------------------------+
  | CENTRAL | slow/public netwrk | REMOTE CLIENT BROWSER |
  | GEOSERVER |--------------------| |---
  | AND MY | +----------------------------+
  | SINGLE | slow/public netwrk +----------------------------+
  | WEBAPP |--------------------| REMOTE CLIENT BROWSER |
  +-----------+ | |---
                                   +----------------------------+

with your central geoserver keeping a shapefile snapshot for each client
on the server. This would give you a private snapshot for each client,
but no speedups whatsoever.

Pardon me for my ignorance, how can I "match"/"identify" a shapefile to its
corresponding client browser? And will each shapefile be a new feature type,
meaning to say if I have 10 clients, I will have 10 shapefiles and
correspondingly 10 new feature types?

Cheers
Andrea

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.411 / Virus Database: 268.17.39/685 - Release Date: 2/13/2007

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.411 / Virus Database: 268.17.39/685 - Release Date: 2/13/2007

[This e-mail is confidential and may be priviledged. If you are not the
intended recipient, please kindly notify us immediately and delete the message
from your system; please do not copy or use it for any purpose, nor disclose
its contents to any other person. Thank you.]
---ST Electronics Group---