Saturday, 30 January 2010

Announcing Proj4J

It's been a while since I posted anything, because like a true programmer I've been too busy cutting code to write about it. Time to catch up!

My main focus for a while has been working on a Java port of the popular PROJ.4 projection library. This was motivated by finding the great work that JHLabs started with his JavaProj port. That seemed too good to be left to languish, so I dusted it off and started to clean it up. The library is now known as Proj4J. It has been substantially reworked to provide a more functional API and a cleaner codebase. Various bug fixes have been made to the core projections (although more remains to do!), and a formal test suite has been added.

To answer the question of "Why another Java projection library?", the main reason is that PROJ.4 is popular, well-tested and well-documented, so it seems like a good idea to make it available in the Java world. Other goals include creating a small, easy-to-understand, easy-to-use library, which can be embedded and/or extended as desired by small projects. A personal goal is to provide coordinate system transformation services in JEQL (which is now realized by exposing Proj4J via JEQL functions).

OSGeo is hosting the codebase as part of the MetaCRS umbrella project. There it lives in the good company of Proj4JS, CS-MAP, and of course PROJ.4.

The code is shaping up nicely for a 1.0 release. It can also be downloaded and used as it stands. Check it out! Even better, contribute some tests and bug fixes!

Wagner VII Projection


Juan Lucas Domínguez Rubio said...

Thank you, Martin. This nice package is being used in gvSIG Mobile to avoid JNI and gain portability. Thanks for the hint about transformations.

Juan Lucas

Frank Hardisty said...


This is great, thanks for doing this and releasing it. I had done something similar myself on a smaller scale for the GeoViz Toolkit, but I found the amount of dead code etc. rather daunting. And, thinking in radians always makes my head hurt.

So, I will gladly move to using Proj4J, and I'll be sure to contribute tests and bug fixes for any bits I work on.

I found JHLabs image processing, and the filters in particular, to be quite useful as well. Hooray for Jerry!

-Frank Hardisty

Dr JTS said...

Juan, Frank:

Thanks for the positive comments. It's great to hear that there's a potential user community out there for Proj4J. It's a very wide library (ie lots of projections, etc), so the best way to improve its quality is to get lots of developer eyeballs looking at it!


mentaer said...

what can I say except: great! Now we need to think about giving OpenJUMP support for projections - I guess.

stario said...

Is it LGPL license?

Frank Hardisty said...

Good question, jørnv. The original JHall Labs version is licensed under the Apache 2.0 license. So, that would be an option, or LGPL v3. We await the good doctor's clarification.

stario said...

Yes of course, I think I prefer Apache. Thanks. (was jørnv, now stario)

Dr JTS said...

The question of licensing for Proj4J is high on the To-Do list. It will definitely be a liberal open source license. It probably makes most sense to continue with the original Apache license.

Further comments on this are welcome.

FObermaier said...

Have you come to a conclusion under which license you are going to release Proj4J?

Dr JTS said...

Er, no, haven't sorted out the licensing question yet. Still high on the ToDo list!

Farrukh Najmi said...

Martin, Thank you for this great project. I would like to use it in my project and need to check if you have decided on the license issue. I hope that a liberal OS license like Apache is chosen soon as it will really help with broader adoption of, and wider contribution to, the project. Any updates?

Also I would like to offer to mavenize the project to make building, releasing and consuming it much much easier. Here are some benefits:

Please share your thoughts. Thanks.

Dr JTS said...


I've been swamped with other projects, so I'm afraid I haven't been giving the license issue the attention it deserves. I'll try and make this a priority very soon.

Going Maven sounds fine to me. Will it require a restructuring of the directory layout? Maybe the best way to proceed is for you to prototype the Mavenized codebase, and then share this via the Proj4J mailing list?