[gdal-dev] gdal-dev Digest, Vol 221, Issue 1

[Sundaram Subramaniam]

________________________________
From: gdal-dev <gdal-dev-bounces at lists.osgeo.org> on behalf of gdal-dev-request at lists.osgeo.org <gdal-dev-request at lists.osgeo.org>
Sent: Tuesday, October 4, 2022 12:30 AM
To: gdal-dev at lists.osgeo.org <gdal-dev at lists.osgeo.org>
Subject: gdal-dev Digest, Vol 221, Issue 1

Send gdal-dev mailing list submissions to
        gdal-dev at lists.osgeo.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.osgeo.org/mailman/listinfo/gdal-dev
or, via email, send a message with subject or body 'help' to
        gdal-dev-request at lists.osgeo.org

You can reach the person managing the list at
        gdal-dev-owner at lists.osgeo.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of gdal-dev digest..."


Today's Topics:

   1. ECRG RasterIO problem (mchapman at hyperacktive.com)
   2. How to obtain the raster footprint poly of actual data with
      python (gdisk.mike)


----------------------------------------------------------------------

Message: 1
Date: Mon, 3 Oct 2022 11:05:48 -0600
From: <mchapman at hyperacktive.com>
To: <gdal-dev at lists.osgeo.org>
Subject: [gdal-dev] ECRG RasterIO problem
Message-ID: <00b701d8d74a$62942f60$27bc8e20$@hyperacktive.com>
Content-Type: text/plain; charset="us-ascii"

All,



I have an ECRG dataset that fails when reading pixels from the
gdalrasterband object on one of the subdatasets.  It appears that the
underlying proxy dataset has a macro check called
RB_PROXY_METHOD_WITH_RET_WITH_INIT_BLOCK that fails because the block sizes
are different.  This happens for all the ECRG subdatasets that I read from,
in other words it's not just specific to a single dataset.  FYI, the same
code works fine for RPFTOC datasets and all other GDAL formats.  I am using
GDAL version 3.4.2.

// code snippet from gdalproxydataset.cpp line 247
else if( nSrcBlockXSize != nBlockXSize || nSrcBlockYSize != nBlockYSize) \
{ \
        CPLError(CE_Failure, CPLE_AppDefined, "Inconsistent block dimensions
between proxy and source"); \
        ret = CE_Failure; \
} \

The variables nBlockXSize and nBlockYSize are (2304, 1) and nSrcBlockXSize
and nSrcBlockYSize are {128, 128).

I think this is because the ECRG frame size is 2304 x 2304 but the block
size of the frame file is 128 x 128.

Does anybody know what my problem might be or is this an error in the driver
code?

Best regards,
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20221003/a36eceb1/attachment-0001.htm>

------------------------------

Message: 2
Date: Mon, 3 Oct 2022 11:20:05 -0600
From: "gdisk.mike" <gdisk.mike at gmail.com>
To: Gdal Dev <gdal-dev at lists.osgeo.org>
Subject: [gdal-dev] How to obtain the raster footprint poly of actual
        data with python
Message-ID:
        <CAKTSvBjS-FjZqi8p2_wgWR+YX-OFphQt2-4gbWp-Q6pKgQAPGw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

To get the result using command line, I found the 3 commands did the trick.

gdal_translate -b mask -of vrt -a_nodata 0 'path/to/input.tif' test.vrt
gdal_translate -b 1 -of vrt -a_nodata 0 test.vrt test2.vrt
gdal_polygonize.[bat/py] -q  -8 test2.vrt -b 1 -f "ESRI Shapefile"
testdata.shp

This was off Stack exchange somewhere.

However, I'd like to get this same geometry in python.

I keep hitting roadblocks as I'm not real sure how to use
gdal.Translate or gdal.TranslateOptions

ive tried
gtp = gdal.TranslateOptions(format="vrt",bandList="mask", noData=0)
in attempt to start with the first gdal_translate command.

I'm also curious if there's another way, perhaps using --oo or something
different.

In the end I'd ultimately like to get a geometry poly object of where the
actual imagery data is in the file.

Any pointers?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20221003/2147d699/attachment-0001.htm>

------------------------------

Subject: Digest Footer

_______________________________________________
gdal-dev mailing list
gdal-dev at lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev


------------------------------

End of gdal-dev Digest, Vol 221, Issue 1
****************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20221015/1433db14/attachment.htm>