<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=text/html;charset=iso-8859-1 http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.7600.16535"></HEAD>
<BODY style="PADDING-LEFT: 10px; PADDING-RIGHT: 10px; PADDING-TOP: 15px"
id=MailContainerBody leftMargin=0 topMargin=0 CanvasTabStop="true"
name="Compose message area">
<DIV>Martin,</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV><FONT color=#a70401 size=2></FONT> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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?</DIV>
<DIV> </DIV>
<DIV>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. </DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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.</DIV>
<DIV><FONT color=#a70401 size=2></FONT> </DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>Hope your vacation was enjoyable.</DIV>
<DIV> </DIV>
<DIV>Fred</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV style="FONT: 10pt Tahoma">
<DIV><BR></DIV>
<DIV style="BACKGROUND: #f5f5f5">
<DIV style="font-color: black"><B>From:</B> <A
title="mailto:mtnclimb@gmail.com CTRL + Click to follow link"
href="mailto:mtnclimb@gmail.com">Martin Davis</A> </DIV>
<DIV><B>Sent:</B> Friday, May 14, 2010 10:25 PM</DIV>
<DIV><B>To:</B> <A
title="mailto:f.w.pospeschil.t.r@charter.net CTRL + Click to follow link"
href="mailto:f.w.pospeschil.t.r@charter.net">Fred Pospeschil</A> </DIV>
<DIV><B>Cc:</B> <A
title="mailto:proj4j@lists.osgeo.org CTRL + Click to follow link"
href="mailto:proj4j@lists.osgeo.org">Proj4j Mail List</A> </DIV>
<DIV><B>Subject:</B> Re: [Proj4j] 02 Code organization</DIV></DIV></DIV>
<DIV><BR></DIV>Fred,<BR><BR>A quick reply to some items<BR><BR>ProjectionMath
does include msfn, tsfn.<BR><BR>it was renamed to ProjectionMath because it
contains code which in the<BR>library is only called by Projections. Calling it
MapMath seemed to<BR>introduce a new term which had no other use in the API -
thus widening<BR>the conceptual width of the interface.<BR><BR>Ellipsoid seemed
more associated with datums than with projections,<BR>that's why it got
moved.<BR><BR>All the exceptions were moved to the proj package since they form
part<BR>of the public interface which users have to know about.
Strictly<BR>speaking the Projection subclasses don't need to be exposed to
users<BR>at all - they are simply used by
CoordinateReferenceSystems.<BR><BR>Perhaps your questions reflect a fundamental
dichotomy in how people<BR>might use this API. Some uses (primarily in
GIS) don't use<BR>Projections directly, they use CoordinateReferenceSystems
(since they<BR>are the only actual concrete objects). Another use case is
perhaps by<BR>tool developers, who intend to manage the provision of
projection<BR>parameters themselves. Perhaps this is closer to your use
case?<BR><BR>Anyway, is it such a big deal to have things split into
separate<BR>packages? The proj package is pretty huge already - framework
stuff<BR>tends to get lost in there.<BR><BR>M<BR><BR>On Fri, May 14, 2010 at
6:28 PM, Fred Pospeschil<BR><<A
href="mailto:f.w.pospeschil.t.r@charter.net">f.w.pospeschil.t.r@charter.net</A>>
wrote:<BR>> Martin,<BR>><BR>> This addresses how the code is organized
and the contents of some of the<BR>> packages.<BR>><BR>> Could the
ProjectionException.java and Ellipsoid.java classes be moved back<BR>>
into the proj package? That way everything needed to use the basic<BR>>
projections would all be in the one package. It would simplify things
for<BR>> some users and make the documentation more straight
forward.<BR>><BR>> If there is going to be a ProjectionUtil class I would
also like to see it<BR>> be located in the prog package for the reasons given
above. What is in the<BR>> ProjectionUtil class now seems more related
to coordinates than<BR>> projections. It seems quite related to the
toString methods in the<BR>> ProjCoordinate class.<BR>><BR>> The
ProjectionMath class appears to be a subset of Jerry's MapMath class.
I<BR>> don't think that any of the projection code calls anything in this
class.<BR>> Maybe the name could go back to MapMath?<BR>><BR>> Where
did the routines in Jerry's MapMath class that were called by the<BR>>
projection code go? (msfn, tsfn, etc.)<BR>><BR>> When working with
Jerry's code I was going to have a ProjectionMath class in<BR>> the proj
package which contained only that code which was actually called by<BR>> the
projection methods. All the other code would be moved into a MapMath
or<BR>> MapUtil class to support the other work needed to draw maps.
Maybe this<BR>> effort could use a CRSUtil class. Does this sound
reasonable?<BR>><BR>> Fred<BR>><BR>>
_______________________________________________<BR>> Proj4j mailing
list<BR>> <A
href="mailto:Proj4j@lists.osgeo.org">Proj4j@lists.osgeo.org</A><BR>> <A
href="http://lists.osgeo.org/mailman/listinfo/proj4j">http://lists.osgeo.org/mailman/listinfo/proj4j</A><BR>><BR>></BODY></HTML>