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.

How hard can it be?

One of the fun things that happens when working on a project like uDig is people expect you to live up to the name (ie User-friendly desktop Internet GIS).

This post is about living up to the User-friendly part, for the last week or so I have been helping a user place a 400 meter buffer around some points and road networks and generate a PDF.

How hard can that be?

• The point data was found in a Microsoft access database...
  Final solution was to export from Access to CSV and use gdal to convert that to a shapefile and load the shapefile into uDig.
• The projection is kind of lost to the mists of time...
  This is actually a very common occurrence - those who collected the data knew what they were measuring, but for us that come later it results in no end of fun.
  Final solution was to guess based on some shapefiles and adjust the CRS settings until it lined up.
• Placing a buffer around the points was done by using the Reshape operation to generate a new set of features. While figuring out the buffer( the_geom, 400 ) syntax was not too bad it took a little bit of work (and checking the CRS) to see that the data was measured in meters.
  
• Exporting to a PDF can be done...
  But the functionality is hidden as part of the Export Image wizard (PDF is one of the options just like PNG)
  

Lessons learned:
- CSV happens; I should stop treating it as a toy example for developers and build it into the application
- Showing a the raw WKT definition of a CoordinateReferenceSystem is actually useful; and allowing users to edit it even more so.
- Stay visual: The reshape operation just generated a new scratch layer and adds it to the catalog. Not so good - and hard to tell if anything was actually done ... so When the user is working on the Map, they expect the results on the Map,
- PDF really needs its own wizard.

So how (with all of that) can uDig be considered friendly? Well the documentation was updated as we went through the problem; and the developers were on the #udig IRC channel to answer questions.

Documentation harmed in the making of this post:
- Processing the Geometry in a Shapefile (now with a buffer example)
- Map to Image Wizard

Welcome to How 2 Map

This is a continuation of my blog over at java.net. While Java.net is a great way to contact the Java crowd the set up is a little too formal, clunky and language specific for a lot of what I talk about. The recent deluge of spam comments has finally pushed me to move on.

I have kept a blog very in-frequently; but I have been doing a lot of writing. To start off this blog I wanted to cover the kind of writing I am willing to do on the web; and see if I could work that into a useful article / publication / web-log thing that would be interesting enough for others to follow.

• Email: I write a lot of email, sometimes very detailed and researched, sometimes quick (and in my limited opinion funny).
  Email can occasionally be turned into a good blog post, but usually they make a good topic for an article (since you need to fill is so much context
  
• Documentation: I have taken to writing documentation, and sending email links, rather than directly taking part in the geotools user list or udig user list.
  Problem is it seems only I know what has been written, in fact the best way for me to tell if the documentation is successful is to watch what kind of questions are asked on the user list. Last year at this time all the questions were about connecting to WFS or opening a Shapefile, this year there are lots of questions about drawing maps. Looks like the documentation on working with data is starting to work...
  

What I am not going to do is write big long articles; while these can be very valuable - the time is better spent on coding or documentation.