[gdal-dev] How do I find the anchor point in file?

Todd Smith smith.todd at gmail.com
Wed Nov 17 12:27:59 EST 2010


Yeah and a little more investigation on my part showed me that Arc/Info
ASCII Grid files have their origin in the upper left anyway, even though
they have their lat/long coords in the lower left.  This is from
gCore\rasterio.cpp (line 243in 1.6.2).  In my RGB reads, with a nPixelSpace
of 3 and a nBufDataSize of 1, I could get away get away with having GDAL
"flip" my file data for me by using a negative value for nLineSpace because
GDALCopyWords handled that.  Memcpy doesn't do well with a negative value
for nLineSpace :).  It looks like I'll have to have another function flip my
buffer from top to bottom after my RasterIO call.
for(int k=0; k<kmax;k++)
{
    if( eDataType == eBufType
        && nPixelSpace == nBufDataSize )
    {
        if( eRWFlag == GF_Read )
            memcpy( ((GByte *) pData) + iBufOffset + k * nLineSpace,
                    pabySrcBlock + iSrcOffset, nXSpanSize );
        else
            memcpy( pabySrcBlock + iSrcOffset,
                    ((GByte *) pData) + iBufOffset + k * nLineSpace,
nXSpanSize );
    }
    else
    {
        /* type to type conversion */

        if( eRWFlag == GF_Read )
            GDALCopyWords( pabySrcBlock + iSrcOffset,
                        eDataType, nBandDataSize,
                        ((GByte *) pData) + iBufOffset + k * nLineSpace,
                        eBufType, nPixelSpace, nXSpan );
        else
            GDALCopyWords( ((GByte *) pData) + iBufOffset + k * nLineSpace,
                        eBufType, nPixelSpace,
                        pabySrcBlock + iSrcOffset,
                        eDataType, nBandDataSize, nXSpan );
    }

    iSrcOffset += nBlockXSize * nBandDataSize;
}
 Thanks,

Todd

On Tue, Nov 16, 2010 at 6:22 PM, Kyle Shannon <ksshannon at gmail.com> wrote:

> I am not totally sure, but I believe that the gdal data model always uses
> the upper left corner for the origin, even on files that reference the lower
> left in space. I think this is also the way rasterio handles it.  See
> RasterIO docs:
>
> http://gdal.org/classGDALDataset.html#e077c53268d2272eebed10b891a05743
>
> Specifically the nXOff and nYOff parameters.
>
> kss
> # ============================
> Kyle Shannon
> Physical Science Technician
> RMRS Fire Sciences Lab
> Fire, Fuels & Smoke - RWU 4405
> 5775 Highway 10 W.
> Missoula, MT 59808
> (406)829-6954
> kshannon at fs.fed.us
> # ============================
>
>
>   On Tue, Nov 16, 2010 at 5:28 PM, Todd Smith <smith.todd at gmail.com>wrote:
>
>>   The default way of doing things at my company is to treat the lower
>> left corner of a file as the origin.  Thus when I call RasterIO on a
>> GeoTIFF, I make the buffer I pass as pData address to the last row of the
>> buffer I've allocated, and I make nLineSpace negative.  This has the effect
>> of reading the file from the beginning, but placing each line into my buffer
>> starting at the last and finishing at the first line.  This was working
>> great until I started reading ArcInfo/Ascii files with origins in the
>> lower-left.  In this case, I wouldn't want to address to the last row of my
>> buffer, I'd want to address to the beginning of my buffer, and use a
>> positive value for my line space.
>>
>> Is there metadata that will tell me where the file's origin is?  If not,
>> any suggestions as to how to deal with this problem?
>>
>> Thanks!
>>
>> Todd
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20101117/cf5546b3/attachment.html


More information about the gdal-dev mailing list