[Proj4j] 02 Code organization

Wed May 19 00:11:39 EDT 2010

Martin,

I think you hit the nail on the head when you said "Perhaps your questions reflect a fundamental dichotomy in how people might use this API."  and I got only a partial printout of the ProjectionMath.java file which resulted in my not seeing the  msfn, tsfn methods.  My goof.

It appears that we have run into another case where beauty is in the eye of the beholder.  Where you see things from a GIS perspective, I see things from a map making and map usage perspective.  When I was working and needed geographic materials I had the CIA making the World Data Bank for on-line map borders and what was then the Defense Mapping Agency providing coordinates for the installations in my target data bases.  Since we all worked with WGS84 I never had to worry about different CRSs.  If we did need some Brit, Aussie or other data then the DMA had to convert it for us.

For my map making investigations and discussions all I really need are a few projections.  I can do very well without the ellipsoid and datum code.  I only included Jerry's ellipsoid code because it was fairly easy and the default projection initialization used the sphere.  I could easily delete the ellipsoid stuff and hard code all projections to use only their sphere code.

By the way, what is the clone method for in the projection.java class.  How should it be used?  Pages 45-52 of Effective Java seem to indicate that it might be wise to avoid cloning.  How does it support using projections?

Because of how I got into Jerry's code, the ellipsoid code seemed to be supportive of the projections because only some of the projections used it and none of the projections used the datum code.  

When I get done, I want to be able to provide the using programmer with one zip file which includes everything he/she/it needs including documentation.  The fewer packages the better because it reduces the number of import statements and words which are needed to describe what is going on.  I know it is a personal thing, but I have always been frustrated by the way UNIX users seem to take delight in seeing how many directories they can use.

I do not have a problem with large directories because the using programmer should not have to look at/in them.  If I were looking for a library of map projections which I could use to make maps I would like to have everything in one package and set of documentation.

I guess much of our discussions relate to who the intended audience is and what makes their life easier.  So far we seem to have identified GIS types and map making types.  I suspect there are others.

In reflecting on these discussions I see several layers of support.  The minimal support is in the form of just the projection code.  For additional capability you can add in the ellipsoid code.  Then you probably add the datum stuff.  Exactly where and how the units, angles, and other stuff in Jerry's files play is not all that clear to me.  Clearly, all of this could be part of the same "product" in which the minimal capability is presented first and the more complex stuff is presented later.  That way the user would only have to mess with the minimum amount of complexity to get the job done.  If the full capability is what is needed then the user could jump to the part of the documentation that addressed it.  This is kind of along the lines of the KISS approach.

This is your project so you get to call the shots.  Whether my interests and perspectives are of benefit only you can decide.  If I am causing more work than help I can easily go back to my original path with no problems.  Unless we hammer out some agreeable approach to the overall goals and approach we are going to waste a lot of each others time.

Hope your vacation was enjoyable.

Fred

From: Martin Davis 
Sent: Friday, May 14, 2010 10:25 PM
To: Fred Pospeschil 
Cc: Proj4j Mail List 
Subject: Re: [Proj4j] 02 Code organization

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/proj4j/attachments/20100518/11c28b1e/attachment.html