[Geoserver-devel] Recommendations needed on dynamic featureTypes

For a project I am working on I need to programmatically add featureTypes. The project’s goal is to create a tool to which users can add new quantitative/spatial data which is then visualized according to their needs.

The best option I can come up with so far is to create a different (database) view and featureType for each of the users datasets.
The problem I have with this solutions is the lack of elegance and flexibility. It might well be that users will upload so much data that animations can be rendered from them, that would mean one view per frame. Technically it is also a mess, because adding a new featureType I will have to do programatically via the user interface ( http://docs.codehaus.org/display/GEOSDOC/Alternative+for+reloading+the+Geoserver+catalog ). Moreover there is also the chance of inconsistencies where each featureType has a one on one relation with the view in the database.

Personally I would much rather have a featureType and Datastore which are under my control.
I know that I can inherit from AbstractDataStore and do some magic there, but then I would have to enter into GeoServer’s memory space, right? My collegue did that by simply deploying Geoserver within the tool he made, but I disagree with this strategy because his tool then became dependend on that particular Geoserver and GeoTools. He basically mixed everything up, and then it became nearly impossible to sort them out. However I do like the idea of having a custom Datastore, but then I would like to deploy it as a plugin or something for Geoserver.

I have also played with the idea of creating some kind of generic Datastore, like HTTPDataStore which you could then have interact with one of your servlets. Something everybody could use, since I am not the only one with this question. But as of now I am new to the field of GIS.

Which strategy would you recommend me?

Hi,

Unfotunatley the kind of thing you want to do is a pretty big gap
currently in GeoServer. Pretty much any strategy you take currently is
going to be a hack more or less, be it rewriting config files and
reloading via web app, or creating a datastore which you can communicate
with via http.

Just recently there was work that went on having to do with a retrofit
of the configuration system. As part of a prototype an xmlrpc api was
created to interact with GeoServer configuration. It worked great!! But
sadly we lack this ability in GeoServer today. And there is no clear
path to when the new configuration will be put on.

Sorry I cant be of much more help. But unless you are willing to get
down and dirty and do some GeoServer programming there is no real good
answer. If you are i recommend a simple class which can be used to add
feature types to the catalog, and an xmlrpc wrapper for it.

-Justin

Lobo wrote:

For a project I am working on I need to programmatically add
featureTypes. The project's goal is to create a tool to which users can
add new quantitative/spatial data which is then visualized according to
their needs.

The best option I can come up with so far is to create a different
(database) view and featureType for each of the users datasets.
The problem I have with this solutions is the lack of elegance and
flexibility. It might well be that users will upload so much data that
animations can be rendered from them, that would mean one view per
frame. Technically it is also a mess, because adding a new featureType I
will have to do programatically via the user interface (
http://docs.codehaus.org/display/GEOSDOC/Alternative+for+reloading+the+Geoserver+catalog
<http://docs.codehaus.org/display/GEOSDOC/Alternative+for+reloading+the+Geoserver+catalog&gt;\).
Moreover there is also the chance of inconsistencies where each
featureType has a one on one relation with the view in the database.

Personally I would much rather have a featureType and Datastore which
are under my control.
I know that I can inherit from AbstractDataStore and do some magic
there, but then I would have to enter into GeoServer's memory space,
right? My collegue did that by simply deploying Geoserver within the
tool he made, but I disagree with this strategy because his tool then
became dependend on that particular Geoserver and GeoTools. He basically
mixed everything up, and then it became nearly impossible to sort them
out. However I do like the idea of having a custom Datastore, but then I
would like to deploy it as a plugin or something for Geoserver.

I have also played with the idea of creating some kind of generic
Datastore, like HTTPDataStore which you could then have interact with
one of your servlets. Something everybody could use, since I am not the
only one with this question. But as of now I am new to the field of GIS.

Which strategy would you recommend me?

!DSPAM:4007,46658e86144514901796417!

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

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

!DSPAM:4007,46658e86144514901796417!

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

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

!DSPAM:4007,46658e86144514901796417!

--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org

Thanks, that is the confirmation I was looking for.

I have now chosen for going with creating database views and programmatically adding featuretypes and reloading the configuration through the user interface. It is a hack for sure, but I think for now this is the best way to do it, since all other ways include changing Geoserver while you are clearly stating that in the near future we can expect a solution to this problem.
Anticipating this solution the best would be to stay out of Geoserver’s way, instead of getting down and dirty into Geoserver’s code. Also since you are saying an XML-RPC handling of the configuration is possibly coming I think it is wise to follow the geotools featureType interface in creating new featureTypes, even though I won’t use any XML-RPC yet.

On 6/5/07, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Hi,

Unfotunatley the kind of thing you want to do is a pretty big gap
currently in GeoServer. Pretty much any strategy you take currently is
going to be a hack more or less, be it rewriting config files and
reloading via web app, or creating a datastore which you can communicate
with via http.

Just recently there was work that went on having to do with a retrofit
of the configuration system. As part of a prototype an xmlrpc api was
created to interact with GeoServer configuration. It worked great!! But
sadly we lack this ability in GeoServer today. And there is no clear
path to when the new configuration will be put on.

Sorry I cant be of much more help. But unless you are willing to get
down and dirty and do some GeoServer programming there is no real good
answer. If you are i recommend a simple class which can be used to add
feature types to the catalog, and an xmlrpc wrapper for it.

-Justin

Lobo wrote:

For a project I am working on I need to programmatically add
featureTypes. The project’s goal is to create a tool to which users can
add new quantitative/spatial data which is then visualized according to
their needs.

The best option I can come up with so far is to create a different
(database) view and featureType for each of the users datasets.
The problem I have with this solutions is the lack of elegance and
flexibility. It might well be that users will upload so much data that
animations can be rendered from them, that would mean one view per
frame. Technically it is also a mess, because adding a new featureType I
will have to do programatically via the user interface (
http://docs.codehaus.org/display/GEOSDOC/Alternative+for+reloading+the+Geoserver+catalog
<http://docs.codehaus.org/display/GEOSDOC/Alternative+for+reloading+the+Geoserver+catalog>).
Moreover there is also the chance of inconsistencies where each
featureType has a one on one relation with the view in the database.

Personally I would much rather have a featureType and Datastore which
are under my control.
I know that I can inherit from AbstractDataStore and do some magic
there, but then I would have to enter into GeoServer’s memory space,
right? My collegue did that by simply deploying Geoserver within the
tool he made, but I disagree with this strategy because his tool then
became dependend on that particular Geoserver and GeoTools. He basically
mixed everything up, and then it became nearly impossible to sort them
out. However I do like the idea of having a custom Datastore, but then I
would like to deploy it as a plugin or something for Geoserver.

I have also played with the idea of creating some kind of generic
Datastore, like HTTPDataStore which you could then have interact with
one of your servlets. Something everybody could use, since I am not the
only one with this question. But as of now I am new to the field of GIS.

Which strategy would you recommend me?

!DSPAM:4007,46658e86144514901796417!



This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

!DSPAM:4007,46658e86144514901796417!



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

!DSPAM:4007,46658e86144514901796417!


Justin Deoliveira
The Open Planning Project
http://topp.openplans.org