[Gdal-dev] Bypassing PROJ.4

Frank Warmerdam warmerdam at pobox.com
Wed Sep 1 10:49:41 EDT 2004


Richard didier wrote:
> Hi all,
> 
> I would like to use the GDAL utilities (mainly gdalwarp) but wouldn't like to 
> use PROJ.4 library.
> 
> The issue is that we have algorithms for coordinates transformations. We have 
> compared results from PROJ.4 and our library and we lost the initial 
> coordinates resolution with PROJ.4. Further more, we use specific datum shift 
> grids that are not compatible with the one (NAD83) plugged into PROJ.4.

Richard,

It would be interesting to be able to add support for IGN grids in PROJ.4
at some point.

> I feel like several solutions can be used, but I'd like to have experts 
> opinion. As far I can see, I feel like making a PROJ.4 wrapper to call our 
> coordinates transformation library. Still, I have to pass our SRS ID to GDAL 
> utilities (I then need to write some ogr_srs_ignrig.cpp files to do it).

I would suggest you look at gdal/ogr/ogrct.cpp.  Instead of trying to implement
a PROJ.4 compatible interface to your functions, it might be better to
write an OGRCoordinateTransformation implementation that calls into your
library.  If you look at ogrct.cpp you will see how a PROJ.4 based subclass
of the generic OGRCoordinateTransformation class is defined.  It should, in
theory, be pretty easy to implement an OGR_IGN_CT class as an alternative
for your use, and force OGRCreateCoordinateTransformation() to use that in
preference to the PROJ.4 classes (perhaps controlled by some switch).

This all assumes that you can adequately identify your coordinate systems
of interest in WKT.  I would assume the existing projection descriptions
would be fine, possibly with a particular authority and code being used
to describe your datum.

You could try and implement an ogr_srs_ignrig.cpp module to translate between
OGRSpatialRefernence format, and your own representation but it might just
be easier to do it within your OGR_IGN_CT class.

> Finally, we like to add a -rsi resampling option (sinus cardinal resampling, 
> very slow, but really efficient for image geometry quality) to gdalwarp, but 
> I don't know exactly where to add it in the source tree.

Look in gdal/alg/gdalwarpkernel.cpp.  The GWKGeneralCase() function is the
general purpose code called when no speical case exists for a particular
combination of pixel type and resampling kernel.  If you add your resampling
type here that should be the bulk of the work.

In particular where you see:
/* -------------------------------------------------------------------- */
/*      Collect the source value.                                       */
/* -------------------------------------------------------------------- */
                 if( poWK->eResample == GRA_NearestNeighbour )
                 {
                     GWKGetPixelValue( poWK, iBand, iSrcOffset, &dfDensity,
                                       &dfValueReal, &dfValueImag );
                 }
                 else if( poWK->eResample == GRA_Bilinear )
                 {
                     GWKBilinearResample( poWK, iBand,
                                          padfX[iDstX]-poWK->nSrcXOff,
                                          padfY[iDstX]-poWK->nSrcYOff,
                                          &dfDensity,
                                          &dfValueReal, &dfValueImag );
                 }
...

Add in a case for GRA_SinusCardinal and implement a function for it.  You can
use the other functions as an example.  I imagine the bilinear would be the
simplest case that demonstrates reading from multiple pixels to resample.

Also, there will be a few other places to touch.

  1) Near the beginning of GWKGeneralCase() there is logic to pick the resampling
     kernel size (used for windowing effects) ... make sure you update that.
  2) You will need to add your new resampling type in alg/gdal_warp.h.
  3) You will need to add commandline support in apps/gdalwarp.c

I may have missed a few other spots.  If you can implement this smoothly it
might be nice to incorporate back into the core version.  I presume the support
for your own coordinate system libraries would not be very useful in the
core version and would remain custom to your site.

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




More information about the Gdal-dev mailing list