Adrian Custer wrote:
Hey everyone,
As preparation for drawing up architectural diagrams of geotools for the
pleasure of users like myself, I've been parsing the source code
distribution of 2.2.RC2. Some questions arise because there are only
three directories which lump together several packages: api (all of
which are also defined elsewhere and whose separate purpose makes
sense), coverage, and referencing.
There are actually a few more, we just have not separated these out on
trunk yet (the change will be visible
when the FM branch returns). I hope you find the breakdown is more clear
in terms of both abstraction
and responsibility.
API
===
Lets talk about interfaces, abstractions and modeling power:
- "geoapi" contains interfaces that have been through formal review, we
are working on adopting several higher level ideas (coverage, feature,
expression and style and maybe Geometry) but for 2.2.x we are limited to
CRS and friends
- module/api - these are APIs that have been through QA and are
consistent (if not always complete), the goal of this module is to be
*empty* and to make use of GeoAPI interfaces as they are made available
and approved.
- any other API (like rendering) has not been reviewed by me yet - so I
am not sure if it makes consistent use of factories for example
CORE
=====
And now we can talk about geotools the library - starting with the
"inner" core:
- module/referencing - captures CRS and friends, requres an EPSG plugin
before functioning, based purely on GeoAPI interfaces this module is the
most stable
- module/main - default implementations of both GeoAPI and GeoTools
interfaces. Also contains "factory finders" which are the only way to
acquire anything - this will be phased out in favour of the use of a
containers (allowing much greater control).
Now that we have the implementations we can move onto interaction with
the outside world:
- module/data and module/coverage - implementation of data access to
feature and coverage information (these are both at the same level of
abstraction making use of ideas and implementations defined earlier).
Moving onto the "outer" core, not all uses of GeoAPI require this stuff,
use is optional:
- module/jdbc - contains NO NEW API, just serves as a baseline to help
those implementing JDBC datastores
- module/xml - support for XML parsing of Filter, Geometry as per
standards, and generation of XML documents from the same, XML is common
enough to be included in "CORE"
- module/renderer - support for Image rendering of spatial data,
currently contains Map interfaces as we have not got an implementation
of the GO-1 standard
- module/svgsupport - support SVG generation, this could be moved to EXT
There is a little bit of bookkeeping:
- module/sample-data - used for the test cases
- module/legacy - DELETE
- module/migrate - DELETE
PLUGIN
======
Inside the plug-in directory you will not find any new ideas (if you do
it is a mistake). Each plugin slots into some part of the geotools
library adding functionality (but not adding abstraction)
EXT
===
Inside the ext directory you will find things built ontop of the "core"
geotools library, these extend the geotools library with new ideas and
abstraction.
There are only two worth worrying about:
- graph
- validation
Coverage:
--------
unessary imposition on the nature of grids. Couldn't this be data/grid
instead?
When we use the coverage interfaces defined by I hope this gets more
clear? You are correct data and coverage are at the
same "level". If you want this called "grid" that could be arranged.
coverages and the idea of images/grids? If so, could someone point me to
what the future directory layout and the package structure might be?
I hope the first part of this emails covers that?
module/referencing:
------------------
This is currently a grab-bag of different packages, many related to
geospatial measurement and science, some of strictly programming utility
(factories, maps (the coding structure)), lots of other stuff. Is there
any plan to refactor this into nice, self-coherent pieces?
Not that I know of. The focus here is on implementation, the coherence
is supposed to be covered by geoapi.
Explicitly the only thing you should see here is the use of GeoAPI
factories, no geotools code from referencing should be
used directly in a application.
Cheers -thanks for the questions,
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=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
