[gdal-dev] gdal_clip

[Even Rouault]

Selon "Zachary L. Stauber" <zachary at stauber.org>:

> Replying to all respondents on this thread... M. Rouault's right, it
> appears to duplicate the functionality of gdal_rasterize with the -burn
> option, which I had never looked into.  Thus, I withdraw the idea.  If
> anyone wants a copy of the source or a compiled executable, I will still
> provide that.  And thank you M. Rouault for providing the functionality.

Actually, all credit for gdal_rasterize goes to Frank Warmerdam.

>
>       -Zack
>
> On Jan 9 2014 5:04 AM, Even Rouault wrote:
> > 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
> >>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>