Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

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

enter image description here

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.
share|improve this question
1  
This question ended up a bit fuzzy. Based on R.K.'s answer I now think that both types of data (spatial/non-spatial) are probably stored in the same RDBMS. The question still exists regarding the used interface. Where do I draw the line between updating data with a) WFS-T and b) SQL etc.? Do I use WFS-T only to update the geometry, and SQL for everything else? And is the option A from OP (do not use WFS-T at all) a reasonable alternative (especially if the geometries are very simple)? –  Janne Mattila Sep 26 '12 at 9:40
    
OpenLayers does not communicate directly with the database. It communicates with the middleware or map server using WFS-T. The middleware then communicates with the database. You may or may not store both the spatial and nonspatial data on the same database. That's your call. –  R.K. Sep 26 '12 at 10:11
    
Yes, I understand that. I still have a couple of open questions from my OP: 1) would design A from OP be feasible (dont use WFS-T, instead persist geometries directly using SQL based persistence, and omitting map server? 2) if you use SQL (and do not go through map server) anyhow to store non-spatial data, where do you draw the line? Do you only use WFS-T (and go through map server) to store the pure geometries, or also the properties directly associated with them (as in "school district" example) –  Janne Mattila Sep 26 '12 at 11:19
    
Answer updated. –  R.K. Sep 26 '12 at 12:34
add comment

2 Answers

up vote 3 down vote accepted

According to Wikipedia:

The WFS specification defines interfaces for describing data manipulation operations of geographic features. Data manipulation operations include the ability to:

  • get or query features based on spatial and non-spatial constraints
  • create a new feature instance
  • delete a feature instance
  • update a feature instance

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:

enter image description here

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.

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)

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.

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.

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.

share|improve this answer
    
Thanks for added clarity, I guess my question is a little bit fuzzy. Can I continue with some follow-ups: - If you have both spatial data ("schoold district" areas on the map) and non-spatial data ("teacher info"), do you typically store them both in the same RDBMS (in your example, PostGIS)? Do you typically store both types on data in the same schema? In same tables? What's a typical approach? - If you use WFS-T to update the spatial data, where do you draw the line between spatial and non-spatial? Do you use WFS-T to manage only geometry data, or also the properties of "school district"? –  Janne Mattila Sep 26 '12 at 9:35
    
Added a clarification. –  R.K. Sep 26 '12 at 10:12
    
Edited original question to clarify what I am still missing. –  Janne Mattila Sep 26 '12 at 11:53
    
I don't have enough reputation to upvote. Marked you answer as accepted - it clarified the issue greatly, thanks a lot! If anyone has any additional experiences, please chime in freely. –  Janne Mattila Sep 26 '12 at 12:45
    
Oh... sorry about that. Glad to be of help :) –  R.K. Sep 26 '12 at 12:48
add comment

GIS generally talks about what and where?. Yes both are data in general.

What corresponds to the spatial data(point/line/polygon) where corresponds to non spatial data(attributes like in your case name of school, no of students, and so on)

Its better to store the data (spatial and non spatial) in the same table (called as postgis layer) in a postgis db( dataset).

reg WFS-T and db

There are three basic things which people do using GIS data Storage Retreival Query

Boosting one may result in less performance of others and it depends on the outcome

when you are taking about db its about storage and WFS/WMS are taking about retrieval

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.