[gdal-dev] gdalwarp extent issues

[Jay L.]

I can confirm that gdal_retile.py also exhibits this behavior.  I am
testing the shift to negative longitude now to see if that "fixes" the
issue.

Should I also post to the ticket concerning the persistance of this error
in gdal_retile?

Jay

On Wed, Feb 22, 2012 at 9:48 AM, J Luis <jmfluis at gmail.com> wrote:

>
>
> On Wed, Feb 22, 2012 at 12:54 AM, Jay L. <jzl5325 at psu.edu> wrote:
>
>> List,
>>
>> I am attempting to reproject 8 gtiffs, each in a local equirectangular
>> projection, back to gcs for use in geoserver.  I immediately went to
>> gdalwarp to perform this task and am having an issue.  The input files are
>> stored in positive longitude, while the output SRS is in negative
>> longitude.  The "shift" to negative longitude is a primary reason for
>> wishing to perform the warp.
>>
>> The input images which cover 0-90 north and 0-90 south are warping
>> correctly.  The others are not.
>>
>> The other warped output images have an extent of -180 180, when the
>> should cover 90 degrees.  The images which remain in positive longitude are
>> drawing correctly, but have the remained of the extent filled in black.
>>  Meaning the image which spans 90-180n and 90-180s renders, but has an
>> extent of -180 to 180.  The input image which are shifted to negative
>> longitude have a global extent and are completely black.
>>
>
> Jay,
>
> I crossed what seams to be the same problem a couple of days ago and
> opened this ticket
> http://trac.osgeo.org/gdal/ticket/4523
> With a bit more of experimenting after that report I found that the, at
> least with global grids, the problem is when they span [0 360]. If they are
> in [-180 180] gdalwarp works fine.
> if you are interested, I have one Mirone solution to warp from [0 360] to
> [-180 180].
>
> Joaquim
>
>
>>
>> I have tried the following without success:
>>
>> gdalwarp -t_srs moon2000.prf input output_warped.tif
>>
>> gdalwarp -s_srs <copy of the gdalinfo srs information in a prf> -t_srs
>> moon2000.prf input.tif output.tif
>>
>> gdalwarp -t_srs moon2000.prf -te <desired extent as xmin ymin xmax ymax>
>> input.tif output.tif
>>
>> Where moon2000.prf is:
>>
>> GEOGCS["Moon 2000",
>>     DATUM["D_Moon_2000",
>>         SPHEROID["Moon_2000_IAU_IAG",1737400.0,0.0]],
>>     PRIMEM["Greenwich",0],
>>     UNIT["Decimal_Degree",0.0174532925199433]]
>>
>> Any insight would be greatly appreciated.
>> Jay
>>
>> Here is the projection info as output by gdalinfo:
>>
>> Coordinate System is:
>> PROJCS["EQUIRECTANGULAR MOON",
>>     GEOGCS["GCS_MOON",
>>         DATUM["D_MOON",
>>             SPHEROID["MOON_localRadius",1737400,0]],
>>         PRIMEM["Reference_Meridian",0],
>>         UNIT["degree",0.0174532925199433]],
>>     PROJECTION["Equirectangular"],
>>     PARAMETER["latitude_of_origin",0],
>>     PARAMETER["central_meridian",0],
>>     PARAMETER["standard_parallel_1",0],
>>     PARAMETER["false_easting",0],
>>     PARAMETER["false_northing",0],
>>     UNIT["metre",1,
>>         AUTHORITY["EPSG","9001"]]]
>> Origin = (100.000000000000000,1819400.000000000000000)
>> Pixel Size = (100.000000000000000,-100.000000000000000)
>>
>> The coordinate information:
>> Corner Coordinates:
>> Upper Left  (     100.000, 1819400.000) (  0d 0'11.87"E, 59d59'59.88"N)
>> Lower Left  (     100.000,    -100.000) (  0d 0'11.87"E,  0d 0'11.87"S)
>> Upper Right ( 2729200.000, 1819400.000) ( 90d 0'11.69"E, 59d59'59.88"N)
>> Lower Right ( 2729200.000,    -100.000) ( 90d 0'11.69"E,  0d 0'11.87"S)
>> Center      ( 1364650.000,  909650.000) ( 45d 0'11.78"E, 29d59'54.00"N)
>>
>> Oddly the central meridian and standard_parallel_1 parameters do not
>> change with each input file.  Since I know that gdal can see the s_srs from
>> within the files I have tried using:
>>
>>
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20120222/906a9a11/attachment.html