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@xxxxxxxxx> wrote:

>
>
> On Wed, Feb 22, 2012 at 12:54 AM, Jay L. <jzl5325@xxxxxxx> 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@xxxxxxxxxxxxxxx
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>
>
_______________________________________________
gdal-dev mailing list
gdal-dev@xxxxxxxxxxxxxxx
http://lists.osgeo.org/mailman/listinfo/gdal-dev