[postgis] ST_TRANSFORM: proposal for postgis projectiontranformation

[Frank Warmerdam]

Dave Blasby wrote:

> I looked at Frank's (?) code for converting WKT to PROJ4.  Its complex.
> 
> Since we have already existing lists of WKT and PROJ4 for all the EPSG
> projections, I'm not going to write the WKT->PROJ4 function.  
> 
> Perhaps someone can make a big list of all the EPSG projections in WKT
> and PROJ4 and make a (big) example spatial_ref_sys table with both the
> srtext (WKT) and proj4text?
> 
> At some point in the future, we can add the WKT->PROJ4 converter, but it
> seems like a lot of work with very little actual gain.


Dave,

First, I would like to suggest calling GDAL/OGR functions for doing the
WKT->Proj.4 translation as an option.  This would avoid the need to have
the proj4text column populated in advance at the cost of loading a
substantially larger shared library (libgdal.1.1.so) in addition to the
PROJ.4 one.  I am not sure how big an issue that is.  Note, there are
C linkage entry points for OGRSpatialReference, and OGRCoordinateTransform.
Once benefit of "buying into" OGR is that we can also piggyback on it's
knowledge of how to translate between other coordinate system representations
like EPSG codes,OGC XML, ESRI .prj format and so forth.  Of course, it might
just be better to use an OGR based tool to help populate the SRID table
and keep the direct dependencies of PostGIS minimal.

Second, an issue that isn't really adequately addressed in general by
the SF_TRANSFORM(shape,newSRID) mechanism is that there could be more than
one transformation that can take you from the source coordinate system
to the destination one.  This isn't a huge issue in the short term, but
will be an issue in the longer term with the need to match up with the
OGC Coordinate Transformations model for coordinate transforms.

Examples of coordinate system pairs with multiple transformations is stuff
like should the NTv1 or NTv2 datum shift tables be used.  What locally
optimized 3 parameter transform should be used for a mapping between two
datums.

Third, I would be willing to produce a table mapping all easily translatable
2D EPSG coordinate systems to WKT and PROJ.4 definitions.  Poke me when the
need for these becomes pressing if I haven't already produced.

Fourth, I would advise against direct serialization of projPJ structures.
The PROJ.4 definition string is pretty much the serialized form, and shouldn't
be terribly expensive to translate back into a structure.  However, for
reprojecting whole tables, it would be really desirable to be able to
cache the projPJ handles for a little while.  Is there no way to cache them
in a hash table and clean them up later when a transaction is complete?


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



------------------------ Yahoo! Groups Sponsor ---------------------~-->
Win a Capcom Console Game of Your Choice Or Even a Capcom Arcade System. Click Here to Enter.
http://us.click.yahoo.com/tmpz8B/exbDAA/ySSFAA/PhFolB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
postgis-unsubscribe at yahoogroups.com

 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/