Skip to main content

[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.


Back to the top