[Gdal-dev] USGS projection class

[Frank Warmerdam]

April Shimitz wrote:
...
> I haven't determined where the projection system format
> conversion routines should reside yet either - as stand-alone support
> routines, or perhaps the GDALUSGSProj class and the OGRSpatialReference
> class should each implement a constructor that takes as input the
> projection system defined by the opposing class. I've also implemeted some
> overloaded routines for GetProjectionRef() and SetProjection() to get/set
> the projection in the proper format, but I'm not sure if there are more
> routines within GDAL that modify any of the projection infomation that need
> to be addressed as well. Since I am not as familiar with the GDAL core as
> you are, I wondered if you'd be willing to tackle what's still needed to
> incorporate this class into GDAL so I don't miss anything?
> 
> If you'd be willing to do this (or anyone else???), let me know and I'll
> give you a patch for the changes I've made to the code so far and let you
> run with it.

April,

While I am not wildly enthusiastic about incorporating the GDALUSGSProj
class, I am willing to have it in the source tree if that is what you
need.  If so, I would likely suggest keeping it as a separate classes that
knows how to convert to and from OGRSpatialReference format, but without
the OGRSpatialReference format necessarily knowing anything about it.  In
this case you can just check it into gdal/ogr and add to the appropriate
makefiles, as well as having the class definition in it's own include file.
Then it should be ready to use.

However, I am not so keen on having any GDALUSGSProj related overloaded
methods in gdal/gdal_priv.h.  Having overloaded methods is particular
drivers is just fine of course.

All that said, I think it is problematic transporting your projections
object around as an object.  Within GDAL the unit passed around for
coordinate system definitions is a string ... normally in WKT format.
This is what the GetProjectionRef() returns, and what SetProjection()
gives.  The translators assuming they are passing around a string as
the coordinate system.  As long as you are only moving these around within
a very view drivers using fairly custom code to do so, then you should
be allright.

However, I would like to suggest we consider making the OGRSpatialReference
more ammenable to incompeteness, or perhaps add some sort of hack allowing
us to transport your various data items in something that the system can
think of as "sort-of-WKT".

Let me first assume that USGS projections that are complete will just
be transformed into WKT via the normal OGRSpatialReference mechanisms. So
the issue is now to transport partial information when we have it available.
My suggestion is that we "hack" it into a specific string format within
an existing coordinate system type ... likely the LOCAL_CS[] type.  LOCAL_CS
is a coordinate system that can't be related to word coordinates, but that
may still have a helpful name indicating something about the coordinates.

I suggest that the "name" we supply is actually an encoding of all the
information in your GDALUSGSProj class.

For example:

  LOCAL_CS["USGSProj:proj=1:datum=NULL:zone=11:proj_parms=-117,0,0,500000:units=2"]

The GDALUSGSProj class would continue to exist and would have a toWKT()
and fromWKT() method on it, but when it can't properly define a GEOGCS
or PROJCS style coordinate system it would just encode the parameters
in a LOCAL_CS definition.  Only other GDALUSGSProj drivers would make
any use of this coordinate system, but it can be safely transported
through the various levels of GDAL.

The main role of the GDALUSGSProj class then is as a helper for
drivers to convert between USGS projection definitions, and a well
known text format. But drivers wouldn't need overloaded GetProjectionRef()
methods because they would still just be returning strings.

Does this sound plausible?

If you want to go ahead with this approach I would suggest you check
in the appropriate changes but the let me know so I can ensure any
new files have been added the in the right places, and that the
resulting tree still builds cleanly.

Best regards,

-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent