Hello Jan
Jan Jezek a écrit :
The code can be seen here:
http://svn.geotools.org/udig/community/jan/2.2.x/ext/transformations/
Sound like an encouraging work :). There is some suggestions that popup from my
head:
* Current package names are org.geotools.algorithms and
org.geotools.transformations.
Maybe they should be in the org.geotools.referencing namespace? What abot the
following
packages:
- org.geotools.referencing.operation.algorithm
- org.geotools.referencing.operation.calculator
Note that by convention, package names in Java are singular.
* Javadoc for every classes, methods and fields please :) On a strictly
formatting detail,
it may be better to avoid tabulations and use spaces only. Some IDE are
configured for 4
spaces by tabulation, other are configured for 8 spaces by tabulation, etc.
* Is it possible to avoid direct dependency to
com.vividsolutions.jts.geom.Coordinate
and use the org.opengis.spatialschema.geometry.DirectPosition interface
instead? I
saw that ExtendedPolygon use CGAlgorithm from JTS. I assume that this class
is an
important part of this work and requires JTS Coordinate objects?
* For classes that may (or may not - not sure yet) duplicate other classes, it
may be
safer to keep them private. For example the algorithm package has a Circle
class.
We may consider providing such class in a geometry package is some future
Geotools
version. If this Circle class is used only for internal working of algorithms
and do
not appears in the API, it may be safer to keep this class package-privated.
* What is the entry point for users? Is it the calculator package? Does the
user need
to known about the algorithm package? Would it it be envisageable to keep the
whole
algorithm package as package-private classes in the calculator package?
Martin.
_______________________________________________
User-friendly Desktop Internet GIS (uDig)
http://udig.refractions.net
http://lists.refractions.net/mailman/listinfo/udig-devel
