Hi Andrea; thanks for taking my documentation question off into another email.
If I can ask that we meet the minimim requirement for the geotools user guide; a single code example; and then link to your more complete examples elsewhere that should prove sufficient. I often get users stuck trying to figure out how to parse SLD when what they really wanted was a code example. Jody On Sat, May 9, 2009 at 11:15 PM, Jody Garnett <jody.garn...@gmail.com> wrote: > Hi Andrea: > > Thanks for setting up the wiki page; if your module is ready meets the > requirements you can move it over to supported status. I was kind of > hoping it could be rolled into the existing renderer module - but it > looks like a plugin is a sensible option in order to control > dependencies. > > My understanding is that once you meet the requirements very little is > required for the work to be included as a supported module; did you > want a code review or anything? > > I am also interested in your experience with the Sphinx documentation; > our wiki is not really building up additional documentation beyond > core contributors. > > Jody > > On Fri, May 8, 2009 at 8:55 PM, Andrea Aime <aa...@opengeo.org> wrote: >> Hi all, >> I want to propose the graduation of the charts module in supported >> land. >> Wiki page here: >> http://docs.codehaus.org/display/GEOTOOLS/Map+charting+module >> >> The module has 4.5 stars out of 5, the missing piece is some >> documentation other than the javadoc, mostly samples, since >> the big part of the docs is really the Google Charts API, >> which is throughly documented online: >> http://code.google.com/intl/it-IT/apis/chart/ >> >> I plan to write samples once in the GeoServer Sphinx docs, >> they can be then linked from the wiki page above. >> >> For the time being, this mail message provides some samples >> too: >> http://n2.nabble.com/Proposing-new-chart-generating-dynamic-symbolizer-module-td2693818.html#a2693818 >> >> Stability wise, I know the module is new, yet: >> - code coverage is 100% as reported by Cobertura >> - the whole module is just a single class and depends on stable external >> libraries such as Eastwood charts and JFreechart >> - I'm a committer on Eastwood so I can fix bugs and make improvements >> there as well >> >> The only thing that does not look good is that the module depends on >> a SNAPSHOT build of Eastwood that I deployed on the OSGEO repositories >> (JFreechart is a stable version instead), but I plan to rectify this >> by releasing Eastwood charts 1.2 sometimes this month. >> >> Location wise, the module is a plugin of the dynamic symbolizers >> API, so it would end up in modules/plugins. >> >> Feedback and votes appreciated. >> >> Cheers >> Andrea >> >> -- >> Andrea Aime >> OpenGeo - http://opengeo.org >> Expert service straight from the developers. >> >> ------------------------------------------------------------------------------ >> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your >> production scanning environment may not be a perfect world - but thanks to >> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 >> Series Scanner you'll get full speed at 300 dpi even with all image >> processing features enabled. http://p.sf.net/sfu/kodak-com >> _______________________________________________ >> Geotools-devel mailing list >> Geotools-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> > ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
