Message-ID: <302230299.8231.1419247550056.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_8230_1701189951.1419247550055" ------=_Part_8230_1701189951.1419247550055 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 = with an external charting service such as Google Chart (thanks Chris Holmes= and David Winslow for pointing this out in GeoServer land): the chart is s= een as an external graphic that is loaded passing in feature attribute as c= hart 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.=20
However, relying on an external, remote service to generate charts has i= ts own downsides:=20
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>=20
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.=20
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.=20
DeeGree has introduced charting abilities in its own WMS and presented i= t at FOSS4G 2008: http://con= ference.osgeo.org/index.php/foss4g/2008/paper/view/332/168=20
The general idea is quite close to the Google charts usage in dynamic sy= mbolizers, that is:=20 =20
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 JFreeChart.
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://s= vn.wald.intevation.org/svn/deegree/base/trunk/src/org/deegree/graphics/char= ts/ChartConfig.java=20
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.=20
To sum up:=20