________________________________
From: gdal-dev <[email protected]> on behalf of
[email protected] <[email protected]>
Sent: Tuesday, October 4, 2022 12:30 AM
To: [email protected] <[email protected]>
Subject: gdal-dev Digest, Vol 221, Issue 1
Send gdal-dev mailing list submissions to
[email protected]
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
[email protected]
You can reach the person managing the list at
[email protected]
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 ([email protected])
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: <[email protected]>
To: <[email protected]>
Subject: [gdal-dev] ECRG RasterIO problem
Message-ID: <[email protected]>
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" <[email protected]>
To: Gdal Dev <[email protected]>
Subject: [gdal-dev] How to obtain the raster footprint poly of actual
data with python
Message-ID:
<caktsvbjs-fjzqi8p2_wgwr+yx-ofphqt2-4gbwp-q6pkgqa...@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
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
------------------------------
End of gdal-dev Digest, Vol 221, Issue 1
****************************************
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
