[Proj4j] 02 Code organization

Martin Davis mtnclimb at gmail.com
Fri May 14 23:25:08 EDT 2010


Fred,

A quick reply to some items

ProjectionMath does include msfn, tsfn.

it was renamed to ProjectionMath because it contains code which in the
library is only called by Projections. Calling it MapMath seemed to
introduce a new term which had no other use in the API - thus widening
the conceptual width of the interface.

Ellipsoid seemed more associated with datums than with projections,
that's why it got moved.

All the exceptions were moved to the proj package since they form part
of the public interface which users have to know about.  Strictly
speaking the Projection subclasses don't need to be exposed to users
at all - they are simply used by CoordinateReferenceSystems.

Perhaps your questions reflect a fundamental dichotomy in how people
might use this API.  Some uses (primarily in GIS) don't use
Projections directly, they use CoordinateReferenceSystems (since they
are the only actual concrete objects). Another use case is perhaps by
tool developers, who intend to manage the provision of projection
parameters themselves.  Perhaps this is closer to your use case?

Anyway, is it such a big deal to have things split into separate
packages?  The proj package is pretty huge already - framework stuff
tends to get lost in there.

M

On Fri, May 14, 2010 at 6:28 PM, Fred Pospeschil
<f.w.pospeschil.t.r at charter.net> wrote:
> Martin,
>
> This addresses how the code is organized and the contents of some of the
> packages.
>
> Could the ProjectionException.java and Ellipsoid.java classes be moved back
> into the proj package?  That way everything needed to use the basic
> projections would all be in the one package.  It would simplify things for
> some users and make the documentation more straight forward.
>
> If there is going to be a ProjectionUtil class I would also like to see it
> be located in the prog package for the reasons given above.  What is in the
> ProjectionUtil class now seems more related to coordinates than
> projections.  It seems quite related to the toString methods in the
> ProjCoordinate class.
>
> The ProjectionMath class appears to be a subset of Jerry's MapMath class.  I
> don't think that any of the projection code calls anything in this class.
> Maybe the name could go back to MapMath?
>
> Where did  the routines in Jerry's MapMath class that were called by the
> projection code go?  (msfn, tsfn, etc.)
>
> When working with Jerry's code I was going to have a ProjectionMath class in
> the proj package which contained only that code which was actually called by
> the projection methods.  All the other code would be moved into a MapMath or
> MapUtil class to support the other work needed to draw maps.  Maybe this
> effort could use a CRSUtil class.  Does this sound reasonable?
>
> Fred
>
> _______________________________________________
> Proj4j mailing list
> Proj4j at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/proj4j
>
>


More information about the Proj4j mailing list