[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [Geotools-devel] [udig-devel] Summer of Code
|
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.