Hello,
this email follows my threads from 9 July. I finally decided to aim at the DataStore approach as it seems more seminal to me. The pure implementation of the data store was rather straight forward with the provided tutorials (took me less than a day, thanks!).
However, I've still got some questions:
1.) Can the served data structure only be made known to GeoServer by a .properties file? In other words, can I also give a dynamic resource (a servlet), which has the particular output format, which my DataStore can read? I would guess so... (s. also question no. 2.)
2.) Related to the first question: can I make my DataStore understand the O&M XML format? My idea is to create a separate class, which converts the O&M format (which is the output of the servlet) to the structure the DataStore can understand and thus replace the .properties file by the return value of the class/function. Do you think it would make sense or would it rather be counterproductive for the integration into GeoServer to change the readable format from the pipe-separated variety (PSV) to another format? (especially if we think about
integrating the O&M DataStore into future GeoServer releases) Do - until now - all data stores work like that?
3.) What else needs to be done to integrate the created DataStore into GeoServer? Somehow, I have to pack everything into a .jar file and put in into the GeoServer folder tree, but I guess there are still some steps before?
4.) Is there anything else to consider or implement? Filter mapping WFS->O&M, etc. Which class is responsible for filter handling in GeoServer/DataStore?
Thanks very much!!
Bernd.
Hi Bernd,
Sorry it took me so long to answer your questions.
Bernd Resch wrote:
Hello,
this email follows my threads from 9 July. I finally decided to aim at the DataStore approach as it seems more seminal to me. The pure implementation of the data store was rather straight forward with the provided tutorials (took me less than a day, thanks!).
However, I've still got some questions:
1.) Can the served data structure only be made known to GeoServer by a .properties file? In other words, can I also give a dynamic resource (a servlet), which has the particular output format, which my DataStore can read? I would guess so... (s. also question no. 2.)
Yup, you can register a new servlet and really have it return anything. I am not sure what you mean about the .properties file.
2.) Related to the first question: can I make my DataStore understand the O&M XML format? My idea is to create a separate class, which converts the O&M format (which is the output of the servlet) to the structure the DataStore can understand and thus replace the .properties file by the return value of the class/function. Do you think it would make sense or would it rather be counterproductive for the integration into GeoServer to change the readable format from the pipe-separated variety (PSV) to another format? (especially if we think about
integrating the O&M DataStore into future GeoServer releases) Do - until now - all data stores work like that?
Well... all datastores only talk Feature. That is they don't really talk custom exchange formats. I don't think there would really be a good way to build in the O&M xml format into the datastore directly.
3.) What else needs to be done to integrate the created DataStore into GeoServer? Somehow, I have to pack everything into a .jar file and put in into the GeoServer folder tree, but I guess there are still some steps before?
Yeah, package it up in a jar file which has a META-INF/services/org.geoserver.data.DataStoreFactorySpi file in it. Inside hte file will be the fully qualified classname of the datastore factory for your datastore.
4.) Is there anything else to consider or implement? Filter mapping WFS->O&M, etc. Which class is responsible for filter handling in GeoServer/DataStore?
Depends on what you are talking about. GeoServer does all the filter parsing.. but its up to the datastore to respect the filter when a query is made. So I would say its mostly the responsibility of the datastore.
Thanks very much!!
Bernd.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
!DSPAM:4007,46b6ee97154581137850744!
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org
Hey,
thanks for your reply!! My comments once more inline...
Justin Deoliveira wrote:
Hi Bernd,
Sorry it took me so long to answer your questions.
Bernd Resch wrote:
Hello,
this email follows my threads from 9 July. I finally decided to aim at the DataStore approach as it seems more seminal to me. The pure implementation of the data store was rather straight forward with the provided tutorials (took me less than a day, thanks!).
However, I've still got some questions:
1.) Can the served data structure only be made known to GeoServer by a .properties file? In other words, can I also give a dynamic resource (a servlet), which has the particular output format, which my DataStore can read? I would guess so... (s. also question no. 2.)
Yup, you can register a new servlet and really have it return anything. I am not sure what you mean about the .properties file.
a.) "register" in the sense of include it in the getTypeNames() and property() methods of the data store?
b.) In the DataStore tutorial, a text file (extension .properties) is used containing the first line to declare the data structure followed by the data themselves in a pipe-separated format. According to this format, the PropertyAttributeReader.read() method is designed to read features and their attributes.
2.) Related to the first question: can I make my DataStore understand the O&M XML format? My idea is to create a separate class, which converts the O&M format (which is the output of the servlet) to the structure the DataStore can understand and thus replace the .properties file by the return value of the class/function. Do you think it would make sense or would it rather be counterproductive for the integration into GeoServer to change the readable format from the pipe-separated variety (PSV) to another format? (especially if we think about
integrating the O&M DataStore into future GeoServer releases) Do - until now - all data stores work like that?
Well... all datastores only talk Feature. That is they don't really talk custom exchange formats. I don't think there would really be a good way to build in the O&M xml format into the datastore directly.
ok, so I'll proceed as stated in point 1.)
3.) What else needs to be done to integrate the created DataStore into GeoServer? Somehow, I have to pack everything into a .jar file and put in into the GeoServer folder tree, but I guess there are still some steps before?
Yeah, package it up in a jar file which has a META-INF/services/org.geoserver.data.DataStoreFactorySpi file in it. Inside hte file will be the fully qualified classname of the datastore factory for your datastore.
ok, thanks. Perhaps, I'll come back on that later 
4.) Is there anything else to consider or implement? Filter mapping WFS->O&M, etc. Which class is responsible for filter handling in GeoServer/DataStore?
Depends on what you are talking about. GeoServer does all the filter parsing.. but its up to the datastore to respect the filter when a query is made. So I would say its mostly the responsibility of the datastore.
I want to receive the WFS filter parameters and convert them to an O&M filter to restrict data, which have to be gathered from the sensors. I guess, I'll do it within the DataStore then. How can I actually access the WFS filter parameters? (using which class/method?)
Thanks very much!!
Bernd.
Bernd Resch wrote:
Hey,
thanks for your reply!! My comments once more inline...
Justin Deoliveira wrote:
Hi Bernd,
Sorry it took me so long to answer your questions.
Bernd Resch wrote:
Hello,
this email follows my threads from 9 July. I finally decided to aim
at the DataStore approach as it seems more seminal to me. The pure
implementation of the data store was rather straight forward with the
provided tutorials (took me less than a day, thanks!).
However, I've still got some questions:
1.) Can the served data structure only be made known to GeoServer by
a .properties file? In other words, can I also give a dynamic
resource (a servlet), which has the particular output format, which
my DataStore can read? I would guess so... (s. also question no. 2.)
Yup, you can register a new servlet and really have it return
anything. I am not sure what you mean about the .properties file.
a.) "register" in the sense of include it in the getTypeNames() and
property() methods of the data store?
Hmm.. no i meant register in terms of registering with geoserver (in the
web.xml file) so that all requests to a certain url are handled by the
servlet. For instance mapping the servlet to the path "/om" so that
requests look like:
http://<host>/geoserver/om
b.) In the DataStore tutorial, a text file (extension .properties) is
used containing the first line to declare the data structure followed by
the data themselves in a pipe-separated format. According to this
format, the PropertyAttributeReader.read() method is designed to read
features and their attributes.
I see so you are using the same properties file format as the
PropertyDataStore. You should note that this does not have to be the
case. You can store your data in any format you choose.. that is the
point of the datastore api... to give GeoServer a single interface
through which to access various formats.
2.) Related to the first question: can I make my DataStore understand
the O&M XML format? My idea is to create a separate class, which
converts the O&M format (which is the output of the servlet) to the
structure the DataStore can understand and thus replace the
.properties file by the return value of the class/function. Do you
think it would make sense or would it rather be counterproductive for
the integration into GeoServer to change the readable format from the
pipe-separated variety (PSV) to another format? (especially if we
think about
integrating the O&M DataStore into future GeoServer releases) Do -
until now - all data stores work like that?
Well... all datastores only talk Feature. That is they don't really
talk custom exchange formats. I don't think there would really be a
good way to build in the O&M xml format into the datastore directly.
ok, so I'll proceed as stated in point 1.)
3.) What else needs to be done to integrate the created DataStore
into GeoServer? Somehow, I have to pack everything into a .jar file
and put in into the GeoServer folder tree, but I guess there are
still some steps before?
Yeah, package it up in a jar file which has a
META-INF/services/org.geoserver.data.DataStoreFactorySpi file in it.
Inside hte file will be the fully qualified classname of the datastore
factory for your datastore.
ok, thanks. Perhaps, I'll come back on that later
4.) Is there anything else to consider or implement? Filter mapping
WFS->O&M, etc. Which class is responsible for filter handling in
GeoServer/DataStore?
Depends on what you are talking about. GeoServer does all the filter
parsing.. but its up to the datastore to respect the filter when a
query is made. So I would say its mostly the responsibility of the
datastore.
I want to receive the WFS filter parameters and convert them to an O&M
filter to restrict data, which have to be gathered from the sensors. I
guess, I'll do it within the DataStore then. How can I actually access
the WFS filter parameters? (using which class/method?)
The Query class has a getFilter() method which should be what you need.
A query instance gets passed into various methods:
DataStore.getFeatureReader(Query,Transaction)
FeatureSource.getFeatures(Query)
Thanks very much!!
Bernd.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
!DSPAM:4007,46bc2852248473362379201!
--
Justin Deoliveira
The Open Planning Project
http://topp.openplans.org