[Gdal-dev] Q: NITF Rotation

[Jason R Hughes]

Dear GDAL Development Team,

First let me tell you that I ultimately want to paint NITF's (and later other georeferenced images) on a map pixel by pixel.

In the attached message I saw that you addressed issues on how to rotate GeoTiffs.  My question: Is a plan in the works to support this with NITF's?

I took a look at the existing source code in nitfdataset.cpp, line 547: 

if( psImage->dfULX == psImage->dfLLX 
&& psImage->dfURX == psImage->dfLRX
&& psImage->dfULY == psImage->dfURY
&& psImage->dfLLY == psImage->dfLRY
&& psImage->dfULX != psImage->dfLRX
&& psImage->dfULY != psImage->dfLRY )
{
    poDS->bGotGeoTransform = TRUE;
    poDS->adfGeoTransform[0] = psImage->dfULX;
    poDS->adfGeoTransform[1] = 
    (psImage->dfLRX - psImage->dfULX) / poDS->nRasterXSize;
    poDS->adfGeoTransform[2] = 0.0;
    poDS->adfGeoTransform[3] = psImage->dfULY;
    poDS->adfGeoTransform[4] = 0.0;
    poDS->adfGeoTransform[5] = 
    (psImage->dfLRY - psImage->dfULY) / poDS->nRasterYSize;
}


I see that any NITF that does not have a 180 degree rotation we will not be able to get any coordinate information back.  Even if it is 180 degrees how are we supposed to know if Col 0 Row 0 is the "northwest", or the "southeast" corner?  I assume this is a temporary implementation, due to the fact that when I try to set a Geotransform it says "GeoTransform not supported for NITF's" yet.    I'm also assuming that adfGeoTransform[2] and adfGeoTransform[4] will be used in the future to help me determine the orientation of the image to paint on the map correctly with North Up.

We have code for NITF's that currently does this, but I think the implementation is a little different compared to the way you've done it with other image formats.  Our implementation first calculates the rotation angle then finds the Maximum Bounding Rectangle (MBR). From this we rescale, rotate then paint it on the surface using the MBR as a reference point.  This works for us however we wanted to use the GDAL library since it supports multiple image formats.  NITF's are more of a priority for us currently though.

Thanks,
Jason R. Hughes

Elantech, Inc. 
6411 Ivy Lane, Suite 300
Greenbelt, MD 20770
Phone: 301-486-0600
jason.hughes at elantech-inc.com


--- Frank Warmerdam <warmerdam at pobox.com> wrote:
> Ayman Kamal wrote:
> > 1.
> > You mentioned that
> > adfGeoTransform[0] = /* top left x */
> > adfGeoTransform[3] = /* top left y */
> > 
> > -Does top left x mean the value of longitude for
> top
> > left corner?
> > -Does top left y mean the value of lattitude for
> top
> > left corner?
> 
> Ayman,
> 
> Yes, if the coordinate system of the image is
> lat/long.
> 
> > 2.
> > What does horizental, vertical pixel size mean?
> 
> The width of a pixel is the coordinate system being
> used.
> 
> > 3.
> > Are adfGeoTransform[2],adfGeoTransform[4] always
> 0?
> 
> No. If the image is not "north up", that is the
> image is
> rotated or sheared from the normal map orientation
> these will
> be non-zero and then the interpretation of the pixel
> size is
> more complicated.
> 
> In common use these values will be zero.
> 
> > 4.
> > If the user doesn't give me any of these data, and
> > still wants me to generate a GeoTiff file out of
> his
> > faces' images for example, 
> > are there default values that I can supply to
> generate
> > a valid GeoTiff file?
> 
> It is pointless to create a "Geo" TIFF file without
> knowing anything
> about a meaningful coordinate system. If you feel
> the need to do so pick
> any random values you feel like.
> 
> 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
> 
> 
> _______________________________________________
> Gdal-dev mailing list
> Gdal-dev at remotesensing.org
> http://remotesensing.org/mailman/listinfo/gdal-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20040219/6d7fa18f/attachment.html