Re: [gdal-dev] crop a non-square subwindow?
On Thu, Mar 10, 2011 at 05:17:39PM -0500, Frank Warmerdam wrote: > On 11-03-10 05:07 PM, Wendell Turner wrote: > >Is there a way to force pixels outside of the cropping > >polygon to be 'not there', or transparent? Is there a burn > >value that indicates that? > > Another approach is to use -dstalpha to add an alpha channel to the output. That worked fine. Mapserver/OpenLayers likes it that way. Wendell ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] crop a non-square subwindow?
On 11-03-10 05:07 PM, Wendell Turner wrote: Is there a way to force pixels outside of the cropping polygon to be 'not there', or transparent? Is there a burn value that indicates that? Wendell, The -dstnodata parameter can be used to set the output nodata value. I'm not sure if it will properly mark that value as no data or not and whether the end application honours nodata values in geotiff is ... variable. Another approach is to use -dstalpha to add an alpha channel to the output. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] crop a non-square subwindow?
On Wed, Mar 09, 2011 at 06:05:20PM -0600, Marius Jigmond wrote: > On Wed, 2011-03-09 at 12:35 -0500, Frank Warmerdam wrote: > > On 11-03-09 11:51 AM, Wendell Turner wrote: > > > > > > Do any of the gdal utilities crop an image on non-square > > > boundaries? > > > ... > > I think gdalwarp with -crop_to_cutline and a cutline specified > > with the shape will accomplish what you want. > >http://www.gdal.org/gdalwarp.html > > The cutline comes from an OGR supported file but this can be as simple > > as a .csv file with a WKT geometry in it. The -crop_to_cutline may be > > new to 1.8. > > Wendell, > > Please be aware that this method may introduce raster shifting and > possibly resampling (depending on the original cell size). It might or > might not matter for your purposes. A better approach is to use > gdal_translate with -projwin to extract to shape envelope and then > gdal_rasterize with -i to burn nodata where shape is missing. Marius & Frank, The -crop_to_cutline worked as advertised, and I didn't notice any shifting or resampling. However, it seemed to place the cropped image into a larger bounding box and the pixels that are outside the cropping shapefile are black, not transparent. The gdal_rasterize with -i looks interesting, but my input is raster, not vector, and gdal_rasterize doesn't seem to like that. Is there a way to force pixels outside of the cropping polygon to be 'not there', or transparent? Is there a burn value that indicates that? Wendell ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Chinese Filenames
On 11-03-10 10:42 AM, kui yang wrote: gdal 1.8.0 has problem. when the filename is in Chinese Kui Yang, That is not a very detailed bug report. GDAL 1.8 includes some changes in the underlying handling of filenames such that filenames passed in to GDALOpen() should be passed in UTF-8 rather than the local encoding. This was generally the situation already on Linux and I suppose most other unix type operating systems. But it was a change on windows. Are you working on windows? How are you encoding the filenames being passed to GDALOpen()? As a workaround, you can restore essentially the old filename handling behavior on windows by setting the GDAL_FILENAME_IS_UTF8 configuration variable to "NO". Some info on setting config options is available at: http://trac.osgeo.org/gdal/wiki/ConfigOptions Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] (no subject)
gdal 1.8.0 has problem. when the filename is in Chinese ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Inconsistent handling of Lambert Conformal Conic projection
Hi All,
I'm experiencing some inconsistent behavior with GDAL 1.8.0's projection
handling routines that I'd like to bring to someone's attention.
I'm playing with some maps in Lambert Conformal Conic, and the same
projection information is getting handled differently depending on how I
provide it to GDAL.
I started with a MapInfo coordinate system string:
Coordsys Earth Projection 3, 74, "m", -95, 49, 49, 77, 0, 0
When that's used, it will come back in Proj4 format as:
+proj=lcc +lat_1=49 +lat_2=77 +lat_0=49 +lon_0=-95 +x_0=0 +y_0=0
+ellps=GRS80 +towgs84=0,0,0,-0,-0,-0,0 +units=m +no_defs
However, if I start with the above Proj4 format string and ask for it
back, I get
+proj=lcc +lat_1=49 +lat_0=49 +lon_0=-95 +k_0=1 +x_0=0 +y_0=0
+ellps=GRS80 +datum=NAD83 +units=m +no_defs
You can see that the lat_2 parameter is no longer to be found...
After poking around in the source code, I've found a difference between
two routines that handle importing coordinate systems.
gdal-1.8.0\ogr\ogrsf_frmts\mitab\mitab_coordsys.cpp has code
/*--
* Lambert Conic Conformal
*-*/
case 3:
poSR->SetLCC( GetMIFParm( papszNextField, 2, 0.0 ),
GetMIFParm( papszNextField, 3, 0.0 ),
GetMIFParm( papszNextField, 1, 0.0 ),
GetMIFParm( papszNextField, 0, 0.0 ),
GetMIFParm( papszNextField, 4, 0.0 ),
GetMIFParm( papszNextField, 5, 0.0 ) );
break;
however, in \gdal-1.8.0\ogr\ogr_srs_proj4.cpp the code is:
else if( EQUAL(pszProj,"lcc") )
{
if( OSR_GDV(papszNV, "lat_0", 0.0 )
== OSR_GDV(papszNV, "lat_1", 0.0 ) )
{
/* 1SP form */
SetLCC1SP( OSR_GDV( papszNV, "lat_0", 0.0 ),
OSR_GDV( papszNV, "lon_0", 0.0 ),
OSR_GDV( papszNV, "k_0", 1.0 ),
OSR_GDV( papszNV, "x_0", 0.0 ),
OSR_GDV( papszNV, "y_0", 0.0 ) );
}
else
{
/* 2SP form */
SetLCC( OSR_GDV( papszNV, "lat_1", 0.0 ),
OSR_GDV( papszNV, "lat_2", 0.0 ),
OSR_GDV( papszNV, "lat_0", 0.0 ),
OSR_GDV( papszNV, "lon_0", 0.0 ),
OSR_GDV( papszNV, "x_0", 0.0 ),
OSR_GDV( papszNV, "y_0", 0.0 ) );
}
}
As far as I can figure, these are the two spots that are setting up the
internals for the coordinate system, and they're not quite doing it the
same.
I just don't know enough about the Lambert Conformal Conic coordinate
system any more to tell if I should tweak the MapInfo import routine or
the proj4 import routine.
So I thought I'd throw this out there and see what the experts had to
say.
Thanks,
Andy
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
