[gdal-dev] Is there an easy way to clip an image to the realdata?
Stephen Woodbridge
stephenwoodbridge37 at gmail.com
Thu Jun 27 08:19:00 PDT 2019
Hi Lars,
Thank you for sharing your ideas and scripts. These will come in handy
for the future.
For this project I took a different approach of creating a master tiff
and then copying the data from each patch into that master tiff. It
turns out that this was pretty straight forward in python given that
each patch is masked array and by inverting the mask I end up with a
mask of the good data that I can conditionally copy into the master. So
now I have one image with all the real data from 100+ patches which I
was trying to get using a vrt.
Come to think of it, it might be possible to get the BBOX of the
inverted mask, and then use that to slice the 2d numpy array and just
output the sliced image. Something to play with later.
Thanks again,
-Steve
On 6/27/2019 10:30 AM, lars.schylberg at blixtmail.se wrote:
> Hi Steve,
>
> Sorry for the late reply!
>
> I have some scripts that I developed this winter that contains a function
> to clip an image or images to the parts that only contains data.
>
> My aim was to create tighter tile indexes for Mapserver.
> I achieved good results for my use case.
>
> This will be one of the topics that I will present in my talk at
> FOSS4G in Bucharest in August. I haven't yet prepared the details how to
> explain what I did. But here we go:
>
> 1) First I retile the data to suitable size,
> 2) then check for empty tiles that I throw away.
>
> The function "trim_tile" is actually what You are asking for, I think.
>
> What I do in the function trim_tile is to use:
>
> 1) gdal_calc to produce a binary image where I have data
> 2) polygonize where data exists
> 3) compare extents
> 4) clip data with gdal_translate with projwin argument, if polygon extent is smaller
>
> All is done in a bash script, since it is my preferred language to do things fast.
> I use gnu parallel to speed things up. In my case I had 16 cpus in the server.
> Some versions of parallel requires the argument "--will-cite", others don't.
>
> I made my own bash version of retiling that keeps masks.
>
> Further notes is that the script is working on paletted tif 8 bit image.
> I have a version for rbg images also. The main difference is that the
> empty image test looks like this in that case:
>
> STDDEV=$(gdalinfo $tile -stats | \
> grep STATISTICS_STDDEV | \
> sed 's/STATISTICS_STDDEV=//g' | \
> awk '{$1=$1;printf "%d", $1}')
>
> if [ "$STDDEV" = "000" ]; then
> /bin/rm $tile
> fi
>
> If You have tagged nodata values, those have to be removed with gdal_edit.py
> before You run statistics and then reaplied afterwards with gdal_edit again.
>
> This might hopefully give some inspiration for you how to tackle your
> use case.
>
> The full script can be found here:
>
> https://gist.github.com/LarsSchy/9ecb31eb964dd83820c139b2f2769a7c
>
> Have fun
>
> Lars Schylberg
>
>
> 20 juni 2019 kl. 22:06, "Stephen Woodbridge" <stephenwoodbridge37 at gmail.com> skrev:
>
>> Hi,
>>
>> I'm working with VIIRS L3U images of L2P (level 2 patches). The L3U data
>> is gridded to the +-180 x +-90 but the patch only fills a small
>> percentage of that. I'm compositing a the patch for a day using a vrt.
>>
>> Performance is an issue because all the patches cover the whole globe
>> instead of the extents of the patch.
>>
>> Is there a way to automatically clip an image to the extents of the
>> patch, where all the rest of the image it filled with nodata? IE. remove
>> all rows and columns from the exterior edges that are all nodata and
>> stop when you hit real data.
>>
>> -Steve
>>
>> ---
>> This email has been checked for viruses by Avast antivirus software.
>> https://www.avast.com/antivirus
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
More information about the gdal-dev
mailing list