[gdal-dev] gdal_clip
Even Rouault
even.rouault at mines-paris.org
Thu Jan 9 04:04:41 PST 2014
Zachary,
is it different from gdal_rasterize with the burn option ?
Even
> 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