[Geoserver-users] Creating WFS source for data sets at a lat/lon?

What is needed in the way of process and data files to create a generic WFS
feature (schema only) that is just several numerical data at a given
lat/lon, and then later to add data to the WFS programmatically for this
feature (either through a Java program or some REST approach via HTTP?

The tutorial references using a shape file with some data, but this seems
like a one-time setup for line data and associated attributes.

Thanks,
Rick

Rick McMullen ha scritto:

What is needed in the way of process and data files to create a generic WFS
feature (schema only) that is just several numerical data at a given
lat/lon, and then later to add data to the WFS programmatically for this
feature (either through a Java program or some REST approach via HTTP?

You have no direct way now. The process for doing dynamic feature types is usually to:
* create some kind of data store with the data structure you need (maybe
   be a shapefile, or a database table). This you have to do on your own,
   using geotools, or database management tools
* configure the datastore in Geoserver mimicking the same calls a user
   would use to interactively configure it (it's a bunch of POST calls,
   you should be able to replicate them, there's a page on our wiki
   to do so)
* populate data using WFS-T, we have no REST interfaces at the moment.
   Alternatively, use geotools datastore API to populate the datastore

Not ideal, I know... it's an area where we should try to improve.
Cheers
Andrea

Complicated is better than impossible! Thanks.

I would prefer working with a database, so I'm guessing postgres+postgis
would be a good start. Are there "required" or standard field/column names
for e.g. geolocation information, or is it all freeform and your
field/column names are what you use in your queries?

Thanks again,
Rick

From: Andrea Aime <aaime@anonymised.com>
Date: Thu, 26 Apr 2007 22:58:51 +0200
To: Rick McMullen <mcmullen@anonymised.com>
Cc: <geoserver-users@lists.sourceforge.net>
Subject: Re: [Geoserver-users] Creating WFS source for data sets at a lat/lon?

Rick McMullen ha scritto:

What is needed in the way of process and data files to create a generic WFS
feature (schema only) that is just several numerical data at a given
lat/lon, and then later to add data to the WFS programmatically for this
feature (either through a Java program or some REST approach via HTTP?

You have no direct way now. The process for doing dynamic feature types
is usually to:
* create some kind of data store with the data structure you need (maybe
   be a shapefile, or a database table). This you have to do on your own,
   using geotools, or database management tools
* configure the datastore in Geoserver mimicking the same calls a user
   would use to interactively configure it (it's a bunch of POST calls,
   you should be able to replicate them, there's a page on our wiki
   to do so)
* populate data using WFS-T, we have no REST interfaces at the moment.
   Alternatively, use geotools datastore API to populate the datastore

Not ideal, I know... it's an area where we should try to improve.
Cheers
Andrea

Rick,

I saw andrea's response to your email, and I have a question:

1) Do you want to dynamically create NEW featuretypes all the time? As in you want to create new database spatial tables in the db from your application, and then fill them in?

2) Or do you want to pre-create one single generic spatial data table, and then use WFS-T to fill in some values from your application?

If you want to do 1, that's what andrea's suggestions will take you to, and it's not so straightforward.

If you want to do 2, that's actually quite easy, and is what geoserver is built for.

Just wanted to double-check that you're really trying to solve the harder problem (#1) before you go down that path.

--saul

________________________________

From: geoserver-users-bounces@lists.sourceforge.net on behalf of Rick McMullen
Sent: Thu 4/26/2007 10:53 AM
To: geoserver-users@lists.sourceforge.net
Cc: Rick McMullen
Subject: [Geoserver-users] Creating WFS source for data sets at a lat/lon?

What is needed in the way of process and data files to create a generic WFS
feature (schema only) that is just several numerical data at a given
lat/lon, and then later to add data to the WFS programmatically for this
feature (either through a Java program or some REST approach via HTTP?

The tutorial references using a shape file with some data, but this seems
like a one-time setup for line data and associated attributes.

Thanks,
Rick

-------------------------------------------------------------------------
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/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

This is the wiki page to add new featureTypes:

http://docs.codehaus.org/display/GEOSDOC/Alternative+for+reloading+the+Geoserver+catalog

And there's no standard field/column names, just make sure they are proper geometry types, and registered in the geometry_columns table (if you use the AddGeometryColumn function to add your geometry columns it takes care of that).

Chris

Rick McMullen wrote:

Complicated is better than impossible! Thanks.

I would prefer working with a database, so I'm guessing postgres+postgis
would be a good start. Are there "required" or standard field/column names
for e.g. geolocation information, or is it all freeform and your
field/column names are what you use in your queries?

Thanks again,
Rick

From: Andrea Aime <aaime@anonymised.com>
Date: Thu, 26 Apr 2007 22:58:51 +0200
To: Rick McMullen <mcmullen@anonymised.com>
Cc: <geoserver-users@lists.sourceforge.net>
Subject: Re: [Geoserver-users] Creating WFS source for data sets at a lat/lon?

Rick McMullen ha scritto:

What is needed in the way of process and data files to create a generic WFS
feature (schema only) that is just several numerical data at a given
lat/lon, and then later to add data to the WFS programmatically for this
feature (either through a Java program or some REST approach via HTTP?

You have no direct way now. The process for doing dynamic feature types
is usually to:
* create some kind of data store with the data structure you need (maybe
   be a shapefile, or a database table). This you have to do on your own,
   using geotools, or database management tools
* configure the datastore in Geoserver mimicking the same calls a user
   would use to interactively configure it (it's a bunch of POST calls,
   you should be able to replicate them, there's a page on our wiki
   to do so)
* populate data using WFS-T, we have no REST interfaces at the moment.
   Alternatively, use geotools datastore API to populate the datastore

Not ideal, I know... it's an area where we should try to improve.
Cheers
Andrea

-------------------------------------------------------------------------
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/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org

Rick McMullen ha scritto:

Complicated is better than impossible! Thanks.

I would prefer working with a database, so I'm guessing postgres+postgis
would be a good start. Are there "required" or standard field/column names
for e.g. geolocation information, or is it all freeform and your
field/column names are what you use in your queries?

We just require you to have a primary key (having that SERIAL type would be best, but we handle also string pk, or multicolumns ones, that you'll
have to fill with the primary key by hand), and properly register the
geometric columns (addGeometryColumn is your friend).

Yes, we do use the column names as attribute names.

Cheers
Andrea

Reply inline. Thanks for replying, Saul.
Rick

From: "Farber, Saul (ENV)" <Saul.Farber@anonymised.com>
Date: Thu, 26 Apr 2007 17:56:34 -0400
To: Rick McMullen <mcmullen@anonymised.com>,
<geoserver-users@lists.sourceforge.net>
Conversation: Creating WFS source for data sets at a lat/lon?
Subject: RE: [Geoserver-users] Creating WFS source for data sets at a lat/lon?

Rick,

I saw andrea's response to your email, and I have a question:

1) Do you want to dynamically create NEW featuretypes all the time? As in
you want to create new database spatial tables in the db from your
application, and then fill them in?

2) Or do you want to pre-create one single generic spatial data table, and
then use WFS-T to fill in some values from your application?

#2 is it generally, though the table's columns may need be extended over
time. So, is a "feature" a fixed-for-all-time schema or can it be extended
as a relational table can be?

The application is gathering data from monitoring stations. Stations may
have some variations in what data are provided, and station design may
evolve over time. A feature based on a relational table with columns that
are the union of all available data seems like a good fit, with unused cells
filled with "missing data". This might depend on the availability of a
"missing data" value in WFS transactions.

If you want to do 1, that's what andrea's suggestions will take you to, and
it's not so straightforward.

If you want to do 2, that's actually quite easy, and is what geoserver is
built for.

Just wanted to double-check that you're really trying to solve the harder
problem (#1) before you go down that path.

--saul

________________________________

From: geoserver-users-bounces@lists.sourceforge.net on behalf of Rick McMullen
Sent: Thu 4/26/2007 10:53 AM
To: geoserver-users@lists.sourceforge.net
Cc: Rick McMullen
Subject: [Geoserver-users] Creating WFS source for data sets at a lat/lon?

What is needed in the way of process and data files to create a generic WFS
feature (schema only) that is just several numerical data at a given
lat/lon, and then later to add data to the WFS programmatically for this
feature (either through a Java program or some REST approach via HTTP?

The tutorial references using a shape file with some data, but this seems
like a one-time setup for line data and associated attributes.

Thanks,
Rick

-------------------------------------------------------------------------
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/
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

No problem rick,

I'm actually very glad to hear that it's #2.

You wrote:
#2 is it generally, though the table's columns may need be extended over
time. So, is a "feature" a fixed-for-all-time schema or can it be extended
as a relational table can be?

The application is gathering data from monitoring stations. Stations may
have some variations in what data are provided, and station design may
evolve over time. A feature based on a relational table with columns that
are the union of all available data seems like a good fit, with unused cells
filled with "missing data". This might depend on the availability of a
"missing data" value in WFS transactions.

You've got the right idea here. Geoserver does a couple of things, but one thing that it does is act as a "web front-end" to a PostGIS table (that is, a postgres table that is 'spatially enabled' by the PostGIS postgres add-on). Geoserver will then handle the insertion, deletion, modifcation and query of that table via OGC standard XML messages. These messages (defined in the Web Feature Service or "WFS" specification) are not SOAP, nor are they standard XML-RPC messages...but they are "standard" in that they are well-known and decently documented.

Since geoserver acts as a 'web front-end' to this table, you can actually change the table behind the scenes all that you want. As long as it's a working PostGIS table, you should be all set. When you make changes to the table, you may need to 'reconfigure' geoserver in order to make everything work together just right, but I don't think there will generally be a problem with extending the table in the future.

In addition, PostGIS will allow you to create spatial 'views' where you join together two or more tables into a view, one or more columns of which are 'spatial' columns. This is the only mechanism by which geoserver can directly draw data from two tables at the same time, so if your queries are going to be based on any sort of joins between tables, you'll need to think this part through ahead of time.

Here's a basic run-down of what you'll need to do to get geoserver up and running.

1) Install postgres, and postGIS
2) Properly create and register a 'spatial' table with the columns you want, in the database.
3) Install Java (version 1.4.2 or higher, although 1.5 will give you significant performance improvements)
4) Download and start up geoserver (either in a seperate servlet container or using the built-in 'jetty' container)
5) Using the geoserver web-ui, configure a "datasource" to your running postGIS instance
6) Using the geoserver web-ui, configure a 'featuretype' based on the table you created in step 2
7) Learn enough about the WFS specification to start querying (or inserting) data from (or into) the featuretype you've created in step 6. This will involve sending XML messages via POST to geoserver...take a look at 'wget' or 'curl' for your debugging sessions.
8) Add the functionality you develop in step 7 to a program so that you can have this all done automatically. You can use any major programming language, and you can also use javascript (and other browser-based languages) or even command-line UNIX based scripts.

Good luck! Keep us in the loop on your progress.

--saul