Adrian Custer wrote:
Hey all,
I'm done with the prototype for the Programmers' Manual.
http://docs.codehaus.org/display/GEOTOOLS/Programmers+Manual+Prototype
Thanks Adrian,
Before we get going I am very interested in locking down writing style
(sound like a broken record), I want to know what is and what is not
fair game to write about. Example Java syntax no (assumed), Web
Feature Server maybe (query is inspired by it), Naming yes
(implemented by gt)?
There are several decisions that are needed by the PMC:
1) what the tutorial examples' package(s) should be
The packages should match the module they target.
2) what the tutorial examples' license should be
LGPL same as all code, will that get in anyones way?
3) where the tutorial examples should live
subversion demo/
4) where the graphics should live (all are svg done with inkscape)
we can directly link pictures in svn into geotools, so perhaps they
would be well suited next to the demo the document?
Comments, revisions, and insults are welcome.
Blood good job mate :-)
Jody, you were interested in particular in the design for each tutorial
section. My vision for the tutorial section on the geometric model is
essentially fully outlined in the Geometry Tutorial. The section needs a
lot more work but you should get the full idea of what I want in it.
Will review.
Finally, I'm still struggling with semantic (mental) models of the
library and some of you may have ideas. Are you all aware of how you
conceptualize of the library when you use it? I'm hopelessly confused
but at least I now have all of my confusion well organized in my head.
Currently, I have six different 'looks' on the library:
Code Stack view: the library in the context of the hardware,
Java stack, outside libs...
Only interested for deployment.
Model view: what's in the doc
Ah abstractions, its whats for breakfast. It is hard because you *need*
to start from the middle - aka data. And then work down through
aggregation (geometry coordinates) and up through context (featureType,
attributeType, geometryAttirbuteType, CRS) and you miss out on the
whole data access.
Dependency graph view: what you all did at the module level but
maybe should be done at the package level.
package is supposed to reflect module, put it on the QA list for
geotools 3 :-)
Package list: Each of the two hundred odd packages and where it
fits into the code directories, where its api hangs out, where
it fits in the 'model view'
Not sure how useful this is, it is already covered by javadocs, and
better document using package.html files.
API list: where the various API's are, probably in context of
the Model view.
Not sure what you mean here ...
Data model: where the various pieces are, e.g. where a feature's
coordinates can be found, where its CRS hangs out...
Once I find some clarity with those, I'll draw or compose them and add
them to the doc if they look like they help.
I would start with the model view, and then with that foundation work
on explaining data access.
Jody
---
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
