[gdal-dev] gdal_clip

Even Rouault even.rouault at mines-paris.org
Thu Jan 9 04:04:41 PST 2014


is it different from gdal_rasterize with the burn option ?


> Dear developers,
>       I would like to contribute some code to the project.  I have a
> utility I call gdal_clip I wrote wrote in C++, which I used to compile
> against the FWTools gdal .lib file and later Mr. Szekeres .lib files,
> which will "clip" an image.  It uses an input image and an input polygon
> shapefile, and where the polygons in the shapefile overlap the image, it
> will fill them in with a chosen color (defaults to black).  It will NOT
> resize the output image in any way.
>       This was useful for me to black out, or white out areas of tiles
> in orthophoto projects that were outside the project boundary (outside
> of control network and therefore of low accuracy).  I am out of the
> photogrammetry business, but I have photogrammetry colleagues who wish
> for me to recompile this every time there is a new set of builds on
> gisinternals.com/sdk, so it may be useful to build it into GDAL's code.
>       It is pretty optimized, not doing a pixel-in-polygon check for
> EVERY pixel, but breaking the image into tiles and then breaking those
> tiles into quarters only if they intersect the polygons, and so forth
> down to individual pixels.  It works correctly with doughnut polygons
> and rotated images.  I probably need to pretty up the code in some way
> friendly to Doxygen, but otherwise it is ready to go.
>       In the future I'd like to generalize the code to deal with
> polygons from any vector data source that OGR reads, and optionally
> resize an image to cut it down if large parts are clipped.  It would
> also be nice to make it smart enough to reproject the input polygons to
> the image's coordinate reference system if they are not the same.  I
> also think right now it only reads in and outputs TIFF images.  But
> again, I think it is useful right now.  Please let me know if you all
> think this would be useful or would like the code to see.
>       It is all MIT license right now, but could be changed to GDAL's
> standard license if necessary.
>       -Zack Stauber
>        Albuquerque, New Mexico
>        United States
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev

More information about the gdal-dev mailing list