[gdal-dev] gdalwarp cutting off projected image
Hi, I'm fairly new with GDAL, and have been working with a coworker who is a little more familiar with GDAL and gdalwarp, but we are both stumped by this particular issue. I have a GeoTiff image that is in a north polar Lamber Azimuthal Equal Area (laea) projection. I am trying to reproject it using gdalwarp to a cylindrical projection (like EPSG:4326). I am using the following command: gdalwarp -t_srs EPSG:4326 input.gtiff.tif output.gtiff.tif The tool runs OK, but when I open output.gtiff.tif, the projection is "incomplete". The parts that are there look correct, but it seems everything above about 50 degrees is cut off, like the input.gtiff.tif had a big circle around 50 degrees cut out before the reprojection was made. I've tried looking at the options for gdalwarp, but can't seem to find anything that would help. Is there a way to force gdalwarp to reproject the entire image? Thanks! Scott Lewis NSIDC ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp cutting off projected image
Scott Lewis wrote: Hi, I'm fairly new with GDAL, and have been working with a coworker who is a little more familiar with GDAL and gdalwarp, but we are both stumped by this particular issue. I have a GeoTiff image that is in a north polar Lamber Azimuthal Equal Area (laea) projection. I am trying to reproject it using gdalwarp to a cylindrical projection (like EPSG:4326). I am using the following command: gdalwarp -t_srs EPSG:4326 input.gtiff.tif output.gtiff.tif The tool runs OK, but when I open output.gtiff.tif, the projection is "incomplete". The parts that are there look correct, but it seems everything above about 50 degrees is cut off, like the input.gtiff.tif had a big circle around 50 degrees cut out before the reprojection was made. I've tried looking at the options for gdalwarp, but can't seem to find anything that would help. Scott, There are various challenges in pole (or even dateline) spanning reprojection operations. The options at: http://www.gdal.org/structGDALWarpOptions.html#0ed77f9917bb96c7a9aabd73d4d06e08 may be helpful. In particular, you might try specifying -wo SOURCE_EXTRA=1000 or some similar large value on the gdalwarp commandline. It is also possible that the SAMPLE_GRID=YES and SAMPLE_STEPS=100 options might help but generally if you have lots of RAM and a not-too-big input image specifying a large SOURCE_EXTRA value will resolve the issues. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] 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] gdalwarp cutting off projected image
Frank, Thanks for the help. I tried doing this, and ended up with the same image (even diff found them to be the same). Here are the various commands I tried. Maybe I'm just using the -wo option wrong. gdalwarp -t_srs EPSG:4326 -wo SOURCE_EXTRA=1000 input.gtiff.tif output1.gtiff.tif gdalwarp -t_srs EPSG:4326 -wo "SOURCE_EXTRA=1000" input.gtiff.tif output2.gtiff.tif gdalwarp -t_srs EPSG:4326 -wo "SOURCE_EXTRA=1000 SAMPLE_GRID=YES SAMPLE_STEP=100" input.gtiff.tif output3.gtiff.tif I'll continue to play with those options, though. gdalwarp seems to not act any different (IE, it takes the same amount of time to process) with or without the -wo option, so I'm thinking I'm just not using the option correctly somehow. Again, I appreciate your help! Scott Frank Warmerdam wrote: Scott Lewis wrote: Hi, I'm fairly new with GDAL, and have been working with a coworker who is a little more familiar with GDAL and gdalwarp, but we are both stumped by this particular issue. I have a GeoTiff image that is in a north polar Lamber Azimuthal Equal Area (laea) projection. I am trying to reproject it using gdalwarp to a cylindrical projection (like EPSG:4326). I am using the following command: gdalwarp -t_srs EPSG:4326 input.gtiff.tif output.gtiff.tif The tool runs OK, but when I open output.gtiff.tif, the projection is "incomplete". The parts that are there look correct, but it seems everything above about 50 degrees is cut off, like the input.gtiff.tif had a big circle around 50 degrees cut out before the reprojection was made. I've tried looking at the options for gdalwarp, but can't seem to find anything that would help. Scott, There are various challenges in pole (or even dateline) spanning reprojection operations. The options at: http://www.gdal.org/structGDALWarpOptions.html#0ed77f9917bb96c7a9aabd73d4d06e08 may be helpful. In particular, you might try specifying -wo SOURCE_EXTRA=1000 or some similar large value on the gdalwarp commandline. It is also possible that the SAMPLE_GRID=YES and SAMPLE_STEPS=100 options might help but generally if you have lots of RAM and a not-too-big input image specifying a large SOURCE_EXTRA value will resolve the issues. Best regards, ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp cutting off projected image
Le Tuesday 09 December 2008 18:51:59 Scott Lewis, vous avez écrit : > Frank, > > Thanks for the help. I tried doing this, and ended up with the same > image (even diff found them to be the same). Here are the various > commands I tried. Maybe I'm just using the -wo option wrong. > > gdalwarp -t_srs EPSG:4326 -wo SOURCE_EXTRA=1000 input.gtiff.tif > output1.gtiff.tif > gdalwarp -t_srs EPSG:4326 -wo "SOURCE_EXTRA=1000" input.gtiff.tif > output2.gtiff.tif > gdalwarp -t_srs EPSG:4326 -wo "SOURCE_EXTRA=1000 SAMPLE_GRID=YES > SAMPLE_STEP=100" input.gtiff.tif output3.gtiff.tif This last one won't work as you expect. You should repeat -wo in front of each option : gdalwarp -t_srs EPSG:4326 -wo SOURCE_EXTRA=1000 -wo SAMPLE_GRID=YES -wo SAMPLE_STEP=100 input.gtiff.tif output3.gtiff.tif > > I'll continue to play with those options, though. gdalwarp seems to not > act any different (IE, it takes the same amount of time to process) with > or without the -wo option, so I'm thinking I'm just not using the option > correctly somehow. > > Again, I appreciate your help! > > Scott > > Frank Warmerdam wrote: > > Scott Lewis wrote: > >> Hi, > >> > >> I'm fairly new with GDAL, and have been working with a coworker who > >> is a little more familiar with GDAL and gdalwarp, but we are both > >> stumped by this particular issue. > >> > >> I have a GeoTiff image that is in a north polar Lamber Azimuthal > >> Equal Area (laea) projection. I am trying to reproject it using > >> gdalwarp to a cylindrical projection (like EPSG:4326). I am using > >> the following command: > >> > >> gdalwarp -t_srs EPSG:4326 input.gtiff.tif output.gtiff.tif > >> > >> The tool runs OK, but when I open output.gtiff.tif, the projection is > >> "incomplete". The parts that are there look correct, but it seems > >> everything above about 50 degrees is cut off, like the > >> input.gtiff.tif had a big circle around 50 degrees cut out before the > >> reprojection was made. > >> > >> I've tried looking at the options for gdalwarp, but can't seem to > >> find anything that would help. > > > > Scott, > > > > There are various challenges in pole (or even dateline) spanning > > reprojection operations. The options at: > > > > http://www.gdal.org/structGDALWarpOptions.html#0ed77f9917bb96c7a9aabd73d4 > >d06e08 > > > > > > may be helpful. > > > > In particular, you might try specifying -wo SOURCE_EXTRA=1000 or some > > similar > > large value on the gdalwarp commandline. It is also possible that the > > SAMPLE_GRID=YES and SAMPLE_STEPS=100 options might help but generally if > > you have lots of RAM and a not-too-big input image specifying a large > > SOURCE_EXTRA value will resolve the issues. > > > > Best regards, > > ___ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp cutting off projected image
Scott Lewis wrote: Frank, Thanks for the help. I tried doing this, and ended up with the same image (even diff found them to be the same). Here are the various commands I tried. Maybe I'm just using the -wo option wrong. gdalwarp -t_srs EPSG:4326 -wo SOURCE_EXTRA=1000 input.gtiff.tif output1.gtiff.tif gdalwarp -t_srs EPSG:4326 -wo "SOURCE_EXTRA=1000" input.gtiff.tif output2.gtiff.tif gdalwarp -t_srs EPSG:4326 -wo "SOURCE_EXTRA=1000 SAMPLE_GRID=YES SAMPLE_STEP=100" input.gtiff.tif output3.gtiff.tif I'll continue to play with those options, though. gdalwarp seems to not act any different (IE, it takes the same amount of time to process) with or without the -wo option, so I'm thinking I'm just not using the option correctly somehow. Again, I appreciate your help! Scott, I suspect I've misconstrued what is going wrong. If you can stage the input file somewhere, and if it isn't too terribly huge, I would be interested in trying it myself. Ideally this could be filed as a Trac ticket. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] 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] gdalwarp cutting off projected image
I've been having problems getting it staged. As soon as I'm able to I'll send the URL. Maybe the source geotiff file doesn't have the information necessary to convert correctly, perhaps. Again, thanks for your help. Hopefully I'll have the URL soon. Scott Frank Warmerdam wrote: Scott Lewis wrote: Frank, Thanks for the help. I tried doing this, and ended up with the same image (even diff found them to be the same). Here are the various commands I tried. Maybe I'm just using the -wo option wrong. gdalwarp -t_srs EPSG:4326 -wo SOURCE_EXTRA=1000 input.gtiff.tif output1.gtiff.tif gdalwarp -t_srs EPSG:4326 -wo "SOURCE_EXTRA=1000" input.gtiff.tif output2.gtiff.tif gdalwarp -t_srs EPSG:4326 -wo "SOURCE_EXTRA=1000 SAMPLE_GRID=YES SAMPLE_STEP=100" input.gtiff.tif output3.gtiff.tif I'll continue to play with those options, though. gdalwarp seems to not act any different (IE, it takes the same amount of time to process) with or without the -wo option, so I'm thinking I'm just not using the option correctly somehow. Again, I appreciate your help! Scott, I suspect I've misconstrued what is going wrong. If you can stage the input file somewhere, and if it isn't too terribly huge, I would be interested in trying it myself. Ideally this could be filed as a Trac ticket. Best regards, ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp cutting off projected image
Frank, The image I've been trying to convert is at this URL. It's about 6MB, hopefully that's not too big. ftp://sidads.colorado.edu/pub/incoming/glewis/polar.gtiff.tif Basically, I'm trying to convert it to a plain-old EPGS:4326 (latlong projection). I appreciate you taking a look. Scott PS - I'm still new to the GDAL list; when you say file a Trac ticket, where would I do this? Scott Lewis wrote: I've been having problems getting it staged. As soon as I'm able to I'll send the URL. Maybe the source geotiff file doesn't have the information necessary to convert correctly, perhaps. Again, thanks for your help. Hopefully I'll have the URL soon. Scott Frank Warmerdam wrote: Scott Lewis wrote: Frank, Thanks for the help. I tried doing this, and ended up with the same image (even diff found them to be the same). Here are the various commands I tried. Maybe I'm just using the -wo option wrong. gdalwarp -t_srs EPSG:4326 -wo SOURCE_EXTRA=1000 input.gtiff.tif output1.gtiff.tif gdalwarp -t_srs EPSG:4326 -wo "SOURCE_EXTRA=1000" input.gtiff.tif output2.gtiff.tif gdalwarp -t_srs EPSG:4326 -wo "SOURCE_EXTRA=1000 SAMPLE_GRID=YES SAMPLE_STEP=100" input.gtiff.tif output3.gtiff.tif I'll continue to play with those options, though. gdalwarp seems to not act any different (IE, it takes the same amount of time to process) with or without the -wo option, so I'm thinking I'm just not using the option correctly somehow. Again, I appreciate your help! Scott, I suspect I've misconstrued what is going wrong. If you can stage the input file somewhere, and if it isn't too terribly huge, I would be interested in trying it myself. Ideally this could be filed as a Trac ticket. Best regards, ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp cutting off projected image
Scott Lewis wrote: Frank, The image I've been trying to convert is at this URL. It's about 6MB, hopefully that's not too big. ftp://sidads.colorado.edu/pub/incoming/glewis/polar.gtiff.tif Basically, I'm trying to convert it to a plain-old EPGS:4326 (latlong projection). I appreciate you taking a look. Scott, I have established the problem is the logic that computes the desired extent of the output file. It walks the edges of the input file, transforming to WGS84 and ends up with incomplete extents because there is no recognition that there is a topological discontinuity in the transformation (the pole issue). Normally my advice would be to use the SAMPLE_GRID=YES warp option to force internal sampling of the region when computing the bounds, but I have discovered that only applies to deciding what source region to read during warping - not to the computation of the original warp region. So, in the meantime you can just force selection of output extents. Something like: gdalwarp -t_srs EPSG:4326 polar.gtiff.tif out.tif -te -180 28 180 90 When I have the ticket in hand, I'll plan to modify the GDALSuggestedWarpOutput() function to allow forcing of internal gridding. It would also be nice if I could automatically recognise this sort of case to trigger it automatically, but I'm not sure how to do that without quite a bit of extra work. PS - I'm still new to the GDAL list; when you say file a Trac ticket, where would I do this? Visit: http://trac.osgeo.org/gdal There should be brief instructions on getting an OSGeo Userid which you can use to login to the site, and then hit "New Ticket" to file a bug report. If you find this path isn't deducable from the main GDAL web page, please email me suggestions on how to improve things. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED] 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] gdalwarp cutting off projected image
> I have established the problem is the logic that computes the desired > extent of the output file. It walks the edges of the input file, > transforming to WGS84 and ends up with incomplete extents because there > is no recognition that there is a topological discontinuity in the > transformation (the pole issue). Frank, I wonder if a solution to this problem of detecting the vertical discontinuity is solved using the following logic: "Walk the edges of the the input file, reprojecting to get the extents for the output, as usual. Then repeat the process along the edges of an interior rectangle. If the output extent corresponding to the interior source rectangle has a more extreme northing extent than that from the original rectangle, then extend the output extent to the southernmost/northernmost extreme and the entire easting extent." I make extensive use of the below patch to Mapserver, which is based on this logic, and which works well for combinations of source and destination projections in geographic, Albers, polar stereographic, and equidistant cylindrical. http://trac.osgeo.org/mapserver/ticket/2765 If there are limitations/errors in this assumption which are obvious to you on anyone on the list, I'd appreciate your expertise on the issue. Steve Gaffigan ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdalwarp cutting off projected image
Frank Warmerdam wrote: Scott Lewis wrote: Frank, The image I've been trying to convert is at this URL. It's about 6MB, hopefully that's not too big. ftp://sidads.colorado.edu/pub/incoming/glewis/polar.gtiff.tif Basically, I'm trying to convert it to a plain-old EPGS:4326 (latlong projection). I appreciate you taking a look. Scott, I have established the problem is the logic that computes the desired extent of the output file. It walks the edges of the input file, transforming to WGS84 and ends up with incomplete extents because there is no recognition that there is a topological discontinuity in the transformation (the pole issue). Normally my advice would be to use the SAMPLE_GRID=YES warp option to force internal sampling of the region when computing the bounds, but I have discovered that only applies to deciding what source region to read during warping - not to the computation of the original warp region. So, in the meantime you can just force selection of output extents. Something like: gdalwarp -t_srs EPSG:4326 polar.gtiff.tif out.tif -te -180 28 180 90 When I have the ticket in hand, I'll plan to modify the GDALSuggestedWarpOutput() function to allow forcing of internal gridding. It would also be nice if I could automatically recognise this sort of case to trigger it automatically, but I'm not sure how to do that without quite a bit of extra work. PS - I'm still new to the GDAL list; when you say file a Trac ticket, where would I do this? Visit: http://trac.osgeo.org/gdal There should be brief instructions on getting an OSGeo Userid which you can use to login to the site, and then hit "New Ticket" to file a bug report. If you find this path isn't deducable from the main GDAL web page, please email me suggestions on how to improve things. Best regards, Frank, Thanks a lot for your help, that gdalwarp string worked great. I'll submit a ticket today as well! Scott ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
