Cancer CDC Project
What will the paper talk about?
The development of an interactive client for visualizing state cancer data.
Whats special about it?
It uses the OGC WFS spec to drive it
It uses flash and is designed to be easy to use, good to look at and very interactive
It has a nice interactive population pyramid - structure of data important.
It is constantly loading and throwing small chunks of data so it has a small memory footprint.
Key points to remember:
We switched from shapefiles to a database with minimal changes to the client
We can connect in other clients (e.g. Studio, uDIG, the right version of ArcView with the right plugin)
Much easier to manage the database than lots of flat files though managing the numerous views-as-layers in geoServer can be a challenge
Security - WFS is not yet secure - ref ongonig work on authentication than IanT shoul be able to fill me in on. As such we have a air wall between server 1 (individual data) and server 2 (aggregated data) This paper is only insterested in Paper 1.
Maps can change policy - ref: obesity epidemic.
We have shifted our internal operations to a single GeoServer install - serves out Shapefiles, GML and CSV files as needed. Helps keep internal data catalog up-to-date.
Colors are brewer based - should we consider forcing a single map range with quantiles when comparing maps within a single age/race/sex/stage combination- ref Cindys work on the analysis of this.
Class as quantiles for time series, breaks across domain (not individual period)
Printing... GeoServer is able to act as a WMS as well as a WFS so... the flash client can send an SLD request to the map server to generate output in the format of choise - inc SVG...?
can print fine out of Flash, but how do we save a printable doc (pdf, etc)
Can an easy to use interactive client also be standards based?
What advantages are there to being standards based?
Is GML a barrier to efficient processing? (are we able to process the data as it streams in?)
What, if any, are the limitations of WFS? - METADATA! - Could the catalog spec be the answer??? To do, need to check.
Why a targeted client? Why not a generic one?
Speed of development
Ease of use - lots of variables, nested classes, time series.
Crucial 'safty' features - error bars show standard error on mouse-over?
no "overhead" of generic client...just what the user needs and no more
Are counties the right level to be doing this sort of work? Is there a better scale to work from?
A standards based interactive client for the distribution of cancer data.
Maps are playing an increasingly important role in both epidemiology research (refs) and in government policy (refs). Most notably, from a policy perspective, the sequence of maps showing the spread of obesity across the USA over time was compelling and hard to ignore.
More details on compelling uses of maps for driving public health policy decisions
Do our cancer maps show anything this compelling over short time frame?
1.2 Nature of the data
Description of the colon cancer data, what the details mean, what ascending descending is all about. Note fact that there is a small number of observations in this case, but a lot of variables.
2. Requirements for the atlas
Talk about ease of use, speed. Required features like comparative displays and explicit indication of confidence intervals.
3.1 Client / Server
Given the volume of data it was clearly impractical to develop a solution which passed all of the data to the client at startup, instead a client server approach was nessasary in which the client would pull data as it was required.
Communication via plain old HTTP over port 80, important as we did not want to worry about firewall issues.
3.2 Client details
We chose Flash for the client for several reasons, most important was the ability to perform rapid protyping. In addition was the desire to have elegant looking high quality graphics.
3.3 Server details
The entire stack is open source...
Apache web server -> Tomcat servlet engine -> PostGIS -> PostgreSQL