Mountain Lion Development Environment Links

As befitting a minor release there are only a few fixes if you want get things back in order when working with Mountain Lion.

Java development environment:

• Understanding java from command line on OSX a great summary of "how it works" the command line java_home command line utility and how to get it all working again :-)
• For reference I added the following to ~/.bash_profile:

  export JAVA_HOME=`/usr/libexec/java_home`

General development via homebrew:

• Get Mountain Lion and Homebrew to Be Happy 
• Apple has removed X11.app directing you to grab the XQuartz 2.7.2 (or later)
• Homebrew's 'brew doctor' - edit .bashrc

How to look up the EPSG code for a CoordinateReferenceSystem

Today's question comes for the uDig developers list; this is a fairly classic problem - shapefile store their CoordinateReferneceSystem definition as a .prj file, containing "Well-Known-Text". How can you look up the "official" EPSG code for a CoordinateReferenceSystem? And why would you want to?

A CoordinateReferenceSystem generated from "raw" WKT:

• Often does not have an EPSG code. These codes are useful to know when working with data from a range of sources. If we can figure out the code we can construct a WMS GetMap request (for a base map layer) that matches the shapefile.
• Often lacks some of the meta-data used when creating a good MathTransform

Here is how to look up an "official" CoordinateReferenceSystem.

1. Construct a CoordinateReferenceSystem based on what you have.
   

   String name = "ED50";
   String wkt =
     "GEOGCS[\"" + name + "\",\n" +
     "  DATUM[\"European Datum 1950\",\n" +
     "  SPHEROID[\"International 1924\", 6378388.0, 297.0]],\n" +
     "PRIMEM[\"Greenwich\", 0.0],\n" +
     "UNIT[\"degree\", 0.017453292519943295]]";
   CoordianteReferenceSystem example = CRS.parseWKT(wkt);
   

2. Find the Identifier for your CoordinateReferenceSystem
   

   String code = CRS.lookupIdentifier( example, true ); // should be "EPSG:4230

3. Look up the official definition for that Identifier
   

   CoordinateReferenceSystem crs = CRS.decode( code );

You will find the official CoordinateReferenceSystem is much better at generating MathTransforms.

CoordianteReferenceSystem wsg84 = CRS.decode( "EPSG:4326" );
MathTransform transform = CRS.findMathTransform(crs, wsg84, true);
Geometry targetGeometry = JTS.transform( sourceGeometry, transform );

If you do have any trouble - set the lenient flag to false, the transform will no longer be as accurate (as WKT by itself does not have enough information to account for datum shifts etc...).

CoordianteReferenceSystem wsg84 = CRS.decode( "EPSG:4326" );
MathTransform transform = CRS.findMathTransform(example, wsg84, false );
Geometry targetGeometry = JTS.transform( sourceGeometry, transform );

Documentation harmed in the making of this post:

• CRS Helper Class (GeoTools User Guide)
• JTS Helper Class (GeoTools User Guide)
  

Which class is used to repsent a bounding box?

Today we have a great question:

I noticed in the GeoTools Javadoc (2.5 branch) the following 5 classes that could be used to represent an envelope: Envelope, Envelope2D, EnvelopeExample , org.geotools.geometry.iso.coordinate.EnvelopeImpl , org.geometry.jts.spatialschema.geometry.EnvelopeImpl

Is it possible these different envelope classes are represented by a
single interface that I could reference in my code, or do I need to
pick one? Could we refactor these 5 different classes into a single
Envelope2D class/interface?

The answer is a bit of a pain; but it does go a long way toward explaining what we are about with a spatial library, and why GeoTools may be considered difficult to learn.

Is it possible to have a single interface?

In short there is one interface that represents an "Rectangle" well:
- Envelope - this is a GeoAPI interface defined according to the the ISO 19107 Geometry specification

The Envelope interface stores a CRS and a range of valid values for each axis mentioned by the CRS. If you are really sure you are working with a 2D CRS you can make use of a BoundingBox subclass.

But in actual fact you will need to consider a couple other interfaces:
- When working with Java you will need to use a Rectangle, specifically Rectangle2D.Double
- When working with the JTS Topology Suite you will need to use an Envelope class (defined according to the Simple Features for SQL Specification)
- If you are working with Java3D you will find it has its own Bounds and BoundingBox (and BoundingSphere) classes
- And so on ....

Do I need to pick one?

So yes you need to pick one for your application; the GeoTools library will do its best to work with your needs.

Could we refactor these into a single Envelope2D class/interface?

Internally GeoTools often makes use of a single implementation:
- ReferencedEnvelope

The ReferencedEnvelope is one of the first GeoTools specific classes documented in our user guide, and is an example of something that makes the library unique.

Literally RefernecedEnvelope is a compromise:
- ReferencedEnvelope extends JTS Envelope
- RefernecedEnvelope implements GeoAPI BoundingBox

This gives you the best of both worlds; access bounds in a form acceptable to the JTS Geometry classes (which only wory about the numbers), that also address the need of the GeoTools library to track the Coordinate Refernece System (so we know what the number mean).

Documentation Link

Here is the user guide page that talks about this stuff.