Message-ID: <1171342031.2509.1369304335713.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_2508_1713891206.1369304335713" ------=_Part_2508_1713891206.1369304335713 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The dynamic symbolizers proposal opened the door to the possibility of d=
eveloping custom, programmatic symbol generators that do accept feature par=
ameters as inputs, be it in the category of marks or external graphics.
This alone already provides charting abilities to GeoTools when coupled wit= h an external charting service such as Google Chart (thanks Chris Holmes an= d David Winslow for pointing this out in GeoServer land): the chart is seen= as an external graphic that is loaded passing in feature attribute as char= t data series elements.
An example of this is action is:
This combines feature attribute retrieval to show the percentage of fema= le and male population in a pie chart for each state in the usual GeoServer= topp:states demo.
However, relying on an external, remote service to generate charts has i= ts own downsides:
Point 1 and 2 can be mitigated by deploying a local chart service. Havin= g one has also the extra benefit of allowing chart production for other cli= ents as well, such as cases in which the charts are too dense to be drawn o= n a map as smallish icons, but can be more naturally shown in map popups.= p>
Point 4 can be mitigated by having the dynamic symbolizers use filter fu= nction that can query a known data source given a search key.
Point 3 should be addressed by having an in process charting system. Thi= s would also provide a definitive solution for point 1 and 2.
DeeGree has introduced charting abilities in its own WMS and presented i= t at FOSS4G 2008: http://conference.osgeo.org/= index.php/foss4g/2008/paper/view/332/168
The general idea is quite close to the Google charts usage in dynamic sy= mbolizers, that is:
where $attribute$ extracts an attribute from the current feature, and GD=
D,HDD,CDD keys are the titles of the data elements in the pie chart.
Also interesting is how the system has been linked to a local data source, = the SOS service, to provide time series charts (an example of leveraging a = local data series to draw a custom chart).
The chart drawing library chosen is, not surprisingly, the very popular JFr= eeChart.
It is also interesting to see how the charts appearance is configured. T= he request provides only very generic information, but JFreeChart allows fo= r very detailed control on how a chart is made, be it colors, fonts, positi= oning of elements and so on. DeeGree uses a custom xml template file format= to specify how the chart is actually built. There are no examples, but the= parsing code gives some ideas on what it might look like: https://svn.wald.intevation.org/svn/deegree/base/trunk/src/org/deegr= ee/graphics/charts/ChartConfig.java
Eastwood charts reimplements the Google Charts API on top of the JFreeCh= art library: http://www.jfree.org/eastwood/. If Eastwood can b= e also run as a library component this gives us the best bang for the buck,= it's already able to chew URL's, uses a well documented API, and can be di= rectly exposed to the net as a service already.
To sum up: