Selon "Zachary L. Stauber" <[email protected]>: > 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 > >> [email protected] > >> http://lists.osgeo.org/mailman/listinfo/gdal-dev > >> > > _______________________________________________ > gdal-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev > _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
