I have more experience in "traditional" (Java EE) webapp development, and I am trying to figure out a decent design for a mapping web application.
My application has a map, and users can see and edit some features on the map. Let's say they can add and modify simple rectangular areas on the map, and edit some data fields for each area. Map will most likely be implemented using OpenLayers.
I will have a relational database that will store non-map-related data. Let's say the area on the map is a "school district" with direct fields such as "number of students". Then there's another page where you can input information about teachers for that area.
How do these options compare?:
A. WFS-T is not used. All the data is stored in the traditional relational DB. When user uses the map, the base map images are read from the map server but the data about the user editable features is read from the DB. I read the coordinates for each area from my backend and draw the areas using OpenLayers tools for drawing e.g. vectors on the map. All my modifiable data (map-related or otherwise) is in the same relational DB.
TABLE SCHOOL_DISTRICT
(ID
AREA_X1
AREA_Y1
AREA_X2
AREA_Y2
NAME
NUMBER_OF_STUDENTS);
TABLE TEACHER(
ID
FIRST_NAME
LAST_NAME
SCHOOL_DISTRICT_ID);
B. Use WFS-T for storing feature data. When user uses the map, both the base map images and the editable areas are read from the map server. Now it becomes a question about where to draw the line between the mapserver/WFS-T and the traditional relational db. All the data is not suitable for storing in the map server. The "school district" data may be linked to a complex graph of tables which need to be e.g. reported on. Should I store just the geometry data (coordinates of the areas) in mapserver/WFS-T and everything else in traditional db tables? Or should the immediate data about school districts be stored in mapserver/WFS-T and rest in traditional db tables? How do these two combine? Or, can mapsers/WFS-T utilise the same tables/schema as the traditional side of the application…?
GEO_TABLE_IN_GEOSERVER SCHOOL_DISTRICT_AREA
(ID
AREA_GEOMETRY);
TABLE SCHOOL_DISTRICT_AREA
(ID
AREA_GEOMETRY_ID??
NAME
NUMBER_OF_STUDENTS);
TABLE TEACHER(
ID
FIRST_NAME
LAST_NAME
SCHOOL_DISTRICT_ID);
EDIT: adding an image to hopefully illustrate what I am talking about
We have a web application that has both
- spatial data viewed and edited in an OpenLayers map interface (left side, for example geometries of "school districts")
- non-spatial data which is viewed and edited elsewhere in the application (right side, for example "teacher" data)
Basically, spatial data is edited using WFS-T. The map server (GeoServer) offers WFS-T interface and ultimately talks with RDBMS using SQL. Non-spatial data is edited with means from "standard" web applications: forms, http requests, application server (such as JBoss etc) handles the requests and ultimately talks with RDBMS using SQL. Map server is not involved in this.
Both spatial and non-spatial data can reside in the same RDBMS.
What I am still unsure of is:
- What data should be updated using WFS-T? Is it just the pure geometry (shapes of "school districts") or also data directly associated with the geometries ("school district's number of students -property)? Or can we use WFS-T for all updates, also non-spatial data ("teacher" data – although this does not sound nice)
- If the stored geometries are simple (points in the map, or rectangular areas), is it smart to involve WFS-T and it's added complexity, or would it be sensible alternative to persist those geometries using the right side of the diagram? You would just have simple X1,Y1,X2,Y2 fields in a non-spatial table "school district", and handle storing that data in your regular web application just like you store all other data.
Best Answer
According to Wikipedia:
You do not use it to store the data. It is not a database. You might want to consider PostGIS though. It is a spatial extension to Postgresql. That way, you can store spatial and non-spatial data in one place.
You might want to follow a setup like the one below:
Clarification: OpenLayers does not communicate directly with the database. It communicates with the middleware or map server using WFS-T. When you send a request to update the data on your OpenLayers client, the WFS-T request gets sent to the middleware which communicates with the database. The WFS-T request is then translated into an SQL query or whatever it is that's required to complete the operation.
You can edit the geometries and the associated data using WFS-T. As for the nonspatial data without associated geometries, I think it's best to use other methods for that. Handle them like you would on a normal web app.
As for the points, that would depend on what your app does. If it's primarily for visualization then I guess it's okay to just store them as x,y pairs. if you would like to do spatial analysis however, like queries, buffers etc then it would be preferable to store them on a spatial database and use a map server and WFS-T.