Hi all,
I would like to propose a new extension for GeoServer, in particular,
dynamic charting in SLD courtesy of the GeoTools charting module
and the Eastwood charts library.
You can find more information about it in this message I wrote
to the GeoTools mailing list:
http://n2.nabble.com/Proposing-new-chart-generating-dynamic-symbolizer-module-td2693818.html#a2693818
The extension would be just like a datastore one, the only thing
required is dropping the gt-chart along with its dependencies
(eastwood, jfreechart, jfree-common) into the GeoServer libraries,
as the module implements a dynamic symbolizer extension point.
I would be the one support it, no unit tests required.
As for documentation, most of it is available online
at the Google Charts API docs, what needs to be added in
the GeoServer docs are example of usage and some discussion
on the dynamic symbolizers (which is still pending:
http://jira.codehaus.org/browse/GEOS-2854)
Also have a look at my parallel request to make the gt-chart
module supported in GeoTools land, it contains more
details about the module:
http://n2.nabble.com/Vote%3A-graduating-the-charts-module-into-supported-land-td2844690.html
Imho this would make for quite a selling point for GeoServer 1.7.5 
Feedback appreciated
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Are you looking to go straight to extension, or let it live as a community module for a bit first? I am fine either way but I know that in the past arguments have been made against adding modules directly as extensions, but instead letting them sit in community in order to socialize them a bit with the community.
That said, nice work. This is going to be sweet extension.
-Justin
Andrea Aime wrote:
Hi all,
I would like to propose a new extension for GeoServer, in particular,
dynamic charting in SLD courtesy of the GeoTools charting module
and the Eastwood charts library.
You can find more information about it in this message I wrote
to the GeoTools mailing list:
http://n2.nabble.com/Proposing-new-chart-generating-dynamic-symbolizer-module-td2693818.html#a2693818
The extension would be just like a datastore one, the only thing
required is dropping the gt-chart along with its dependencies
(eastwood, jfreechart, jfree-common) into the GeoServer libraries,
as the module implements a dynamic symbolizer extension point.
I would be the one support it, no unit tests required.
As for documentation, most of it is available online
at the Google Charts API docs, what needs to be added in
the GeoServer docs are example of usage and some discussion
on the dynamic symbolizers (which is still pending:
http://jira.codehaus.org/browse/GEOS-2854)
Also have a look at my parallel request to make the gt-chart
module supported in GeoTools land, it contains more
details about the module:
http://n2.nabble.com/Vote%3A-graduating-the-charts-module-into-supported-land-td2844690.html
Imho this would make for quite a selling point for GeoServer 1.7.5
Feedback appreciated
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
Justin Deoliveira ha scritto:
Are you looking to go straight to extension, or let it live as a community module for a bit first? I am fine either way but I know that in the past arguments have been made against adding modules directly as extensions, but instead letting them sit in community in order to socialize them a bit with the community.
I understand. My rationale is that this module contains just one
class, that has been covered 100% by tests
and whose functionality is provided by libraries that are deemed
to be stable.
This is a long shot compared to previous modules that had
lots of new code, low coverage, or lots of recent changes.
I believe we can get a compromise. What about making it
a community module, but making it available for download
in the next release so that it can get some user coverage?
Or else, I can make up a blog post and package it so that
it can be tested with 1.7.4 or any 1.7.5-nightly in the meantime.
This shoudl give user time to try it out and if we get positive
feedback about it, we can decide to include it in the release.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Andrea Aime wrote:
Justin Deoliveira ha scritto:
Are you looking to go straight to extension, or let it live as a community module for a bit first? I am fine either way but I know that in the past arguments have been made against adding modules directly as extensions, but instead letting them sit in community in order to socialize them a bit with the community.
I understand. My rationale is that this module contains just one
class, that has been covered 100% by tests
and whose functionality is provided by libraries that are deemed
to be stable.
This is a long shot compared to previous modules that had
lots of new code, low coverage, or lots of recent changes.
I believe we can get a compromise. What about making it
a community module, but making it available for download
in the next release so that it can get some user coverage?
Or else, I can make up a blog post and package it so that
it can be tested with 1.7.4 or any 1.7.5-nightly in the meantime.
This shoudl give user time to try it out and if we get positive
feedback about it, we can decide to include it in the release.
Works for me. Again I was not a hard negative on making it an extension, but this sounds nice.
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.