[Proj4j] Did some homework

[Martin Davis]

Fred,

I myself am heading out on holiday in about 5 mins, but I thought I 
should reply quickly so you aren't left hanging.

Anything you feel you can contribute is fine.  It's good to have some 
users of the library who don't have too much emotional attachment to the 
code, anyway - more objectivity.

As for doc, I personally feel Javadoc is quite valuable.  But as you 
say, you really need to add some significant content to it (eg 
package-level doc, diagrams, etc).  But it's definitely not the end-all 
- regular doc is also useful as well.  I think a users/developers guide 
to Proj4J would be very useful.

So I look forward to seeing what you can contribute in the end...

Martin

Fred Pospeschil wrote:
> Martin,
>
> I went over all of your code and did a lot of thinking about it while 
> I sailed the briny deep.  I'll split up my thoughts so the emails 
> don't get too long.
>
> I took a look at the OSGEO web page to see if it would be a source for 
> solutions I am looking for and a home for what I hope to develop.  
> Other than your effort, it does not appear to line up very well.  The 
> OSGEO thrust appears to be very aligned with the OGC standards and, as 
> a result, the higher end GIS type of functions and applications.  I 
> did not find any mention of interest in general map making - probably 
> too elementary to be interesting.  What I have in mind would probably 
> be classified by OSGEO as "map making for dummies".
>
> As a result, it appears that I will have to find a different home for 
> the bulk of what I hope to address.
>
> As for your effort, I can see myself trying to document the 
> projection.java part of your effort and maybe building a "GUI to 
> visualize projections on the globe" providing I can use JBuilder to 
> develop the GUI application.  I have taken another look at Eclipse and 
> Net Beans and find them incompatible with my longer range efforts.  
> Plus, I do not what to shift over to the SWT.
>
> Although I plan to use Java for my project, I want my illustrating 
> code to be as non-Java as possible so the code will be meaningful to 
> non-Java programmers. However, that is not to say that I will not 
> develop Java classes which encapsulate the essence of the concepts and 
> approaches illustrated with the minimally-Java code.
>
> Depending on how you eventually configure your code I may also be able 
> to document the ellipsoid aspects as well.  Anything outside of the 
> basic projection and ellipsoid code is of no use in what I am 
> intending to address.
>
> When I began work with Jerry's code I looked at doing javadoc but 
> rapidly came to the conclusion that it would fall far short of what 
> was needed - as most javadoc seems to do.  While javadoc is better 
> than nothing, in many cases it is not much better than simply reading 
> the code - especially for getters and setters.  It seems to have its 
> most value when the class you are looking at inherits deeply - then it 
> helps in tracking the inheritance chain.  The JavaDoc system support 
> the higher levels of documentation, however, most programmers tend to 
> ignore doing it.
>
> Is the general approach I used in the document I sent you acceptable 
> for your project?
>
> Is it acceptable that I not try to document anything other than the 
> Projection.java and ellipsoid.java classes until you get things 
> further along? I sense there is still a lot of flux in your code.
>
> At this point I do not see myself getting involved in the type of 
> testing you are currently working on.  I am willing to continue to do 
> testing to see if the projection code will generate graticules/maps 
> which generally match the illustrations in the manuals and books which 
> are considered to be written by authorities.  I would provide you with 
> graphic examples of error conditions.  Is this acceptable?
>
> Fred
>
>
>
>
>
> _______________________________________________
> Proj4j mailing list
> Proj4j at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/proj4j
>

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022