[gdal-dev] Geolocation Arrays ??

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

[gdal-dev] Geolocation Arrays ??

Etienne Tourigny-3
Hi all,

I would like to have information on the status of geolocation array
support in GDAL.

The relevant RFC4 (http://trac.osgeo.org/gdal/wiki/rfc4_geolocate)  is
still "under development", and the information there is that
GDALCreateGeoLocTransformer "is currently partially implemented".

Also, the only driver which seems to support it is hdf4, is this still true?

regards,
Etienne
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Geolocation Arrays ??

Even Rouault
Le mardi 07 février 2012 16:40:21, Etienne Tourigny a écrit :

> Hi all,
>
> I would like to have information on the status of geolocation array
> support in GDAL.
>
> The relevant RFC4 (http://trac.osgeo.org/gdal/wiki/rfc4_geolocate)  is
> still "under development", and the information there is that
> GDALCreateGeoLocTransformer "is currently partially implemented".
>
> Also, the only driver which seems to support it is hdf4, is this still
> true?

"grep -r GEOLOCATION frmts" suggests that HDF4 and L1B support geolocation
(and VRT, but as a proxy)

>
> regards,
> Etienne
> _______________________________________________
> gdal-dev mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Geolocation Arrays ??

Frank Warmerdam
In reply to this post by Etienne Tourigny-3
On Tue, Feb 7, 2012 at 7:40 AM, Etienne Tourigny
<[hidden email]> wrote:
> Hi all,
>
> I would like to have information on the status of geolocation array
> support in GDAL.
>
> The relevant RFC4 (http://trac.osgeo.org/gdal/wiki/rfc4_geolocate)  is
> still "under development", and the information there is that
> GDALCreateGeoLocTransformer "is currently partially implemented".

Etienne,

I think the geoloc transformer received some fixes from someone
other than myself and now is working reasonable well.  It would
be desirable to freshen up the RFC and get it passed but it isn't
particularly a priority of mine so I'm not likely to drive it in the
very near future.

Best regards,

--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Software Developer
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Geolocation Arrays ??

Etienne Tourigny-3
Even, Frank,

thanks for your answers.  I have run into a problem with using
gdalwarp with geoloc transform.

In ticket #1895 there is an hdf file for which the HDF4 driver creates
GEOLOCATION metadata.

Trying gdalwarp on it gives an error, and the result transform is
incorrect.  Am I doing something wrong, or is this a bug?

command is : gdalwarp -geoloc -t_srs EPSG:4326
HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13 tmp1.tif
more info below:

$ gdalinfo HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13
Driver: HDF4Image/HDF4 Dataset
Files: A2006005182000.L2_LAC_SST.x.hdf
Size is 389, 602
Coordinate System is `'
Metadata:
[...]
Geolocation:
  LINE_OFFSET=0
  LINE_STEP=1
  PIXEL_OFFSET=0
  PIXEL_STEP=1
  SRS=GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS
84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9108"]],AUTHORITY["EPSG","4326"]]
  X_BAND=1
  X_DATASET=HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":11
  Y_BAND=1
  Y_DATASET=HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":12
Corner Coordinates:
[...]

$ gdalwarp -geoloc -t_srs EPSG:4326
HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13 tmp1.tif
Creating output file that is 31119P x 5864L.
Processing input file HDF4_SDS:UNKNOWN:A2006005182000.L2_LAC_SST.x.hdf:13.
ERROR 1: Too many points (441 out of 441) failed to transform,
unable to compute output bounds.
0...10...20...30...40...50...60...70...80...90...100 - done.

$ gdalinfo tmp1.tif
Driver: GTiff/GeoTIFF
Files: tmp1.tif
Size is 31119, 5864
Coordinate System is:
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
            AUTHORITY["EPSG","7030"]],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0],
    UNIT["degree",0.0174532925199433],
    AUTHORITY["EPSG","4326"]]
Origin = (-90.198287963867188,90.300000000000011)
Pixel Size = (0.015398926739995,-0.015398926739995)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  ( -90.1982880,  90.3000000) ( 90d11'53.84"W, 90d18' 0.00"N)
Lower Left  ( -90.1982880,   0.0006936) ( 90d11'53.84"W,  0d 0' 2.50"N)
Upper Right (     389.001,      90.300) (Invalid angle, 90d18' 0.00"N)
Lower Right (     389.001,       0.001) (Invalid angle,  0d 0' 2.50"N)
Center      ( 149.4013126,  45.1503468) (149d24' 4.73"E, 45d 9' 1.25"N)


Regards,
Etienne


On Tue, Feb 7, 2012 at 7:05 PM, Frank Warmerdam <[hidden email]> wrote:

> On Tue, Feb 7, 2012 at 7:40 AM, Etienne Tourigny
> <[hidden email]> wrote:
>> Hi all,
>>
>> I would like to have information on the status of geolocation array
>> support in GDAL.
>>
>> The relevant RFC4 (http://trac.osgeo.org/gdal/wiki/rfc4_geolocate)  is
>> still "under development", and the information there is that
>> GDALCreateGeoLocTransformer "is currently partially implemented".
>
> Etienne,
>
> I think the geoloc transformer received some fixes from someone
> other than myself and now is working reasonable well.  It would
> be desirable to freshen up the RFC and get it passed but it isn't
> particularly a priority of mine so I'm not likely to drive it in the
> very near future.
>
> Best regards,
>
> --
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial Software Developer
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Geolocation Arrays ??

Brian Case
Etienne
with the transformer the way it sits now, in most cases you will need to
specify -te xmin ymin xmax ymax with gdalwarp to avoid that error

Brian


On Tue, 2012-02-07 at 19:22 -0200, Etienne Tourigny wrote:

> Even, Frank,
>
> thanks for your answers.  I have run into a problem with using
> gdalwarp with geoloc transform.
>
> In ticket #1895 there is an hdf file for which the HDF4 driver creates
> GEOLOCATION metadata.
>
> Trying gdalwarp on it gives an error, and the result transform is
> incorrect.  Am I doing something wrong, or is this a bug?
>
> command is : gdalwarp -geoloc -t_srs EPSG:4326
> HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13 tmp1.tif
> more info below:
>
> $ gdalinfo HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13
> Driver: HDF4Image/HDF4 Dataset
> Files: A2006005182000.L2_LAC_SST.x.hdf
> Size is 389, 602
> Coordinate System is `'
> Metadata:
> [...]
> Geolocation:
>   LINE_OFFSET=0
>   LINE_STEP=1
>   PIXEL_OFFSET=0
>   PIXEL_STEP=1
>   SRS=GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS
> 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9108"]],AUTHORITY["EPSG","4326"]]
>   X_BAND=1
>   X_DATASET=HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":11
>   Y_BAND=1
>   Y_DATASET=HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":12
> Corner Coordinates:
> [...]
>
> $ gdalwarp -geoloc -t_srs EPSG:4326
> HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13 tmp1.tif
> Creating output file that is 31119P x 5864L.
> Processing input file HDF4_SDS:UNKNOWN:A2006005182000.L2_LAC_SST.x.hdf:13.
> ERROR 1: Too many points (441 out of 441) failed to transform,
> unable to compute output bounds.
> 0...10...20...30...40...50...60...70...80...90...100 - done.
>
> $ gdalinfo tmp1.tif
> Driver: GTiff/GeoTIFF
> Files: tmp1.tif
> Size is 31119, 5864
> Coordinate System is:
> GEOGCS["WGS 84",
>     DATUM["WGS_1984",
>         SPHEROID["WGS 84",6378137,298.257223563,
>             AUTHORITY["EPSG","7030"]],
>         AUTHORITY["EPSG","6326"]],
>     PRIMEM["Greenwich",0],
>     UNIT["degree",0.0174532925199433],
>     AUTHORITY["EPSG","4326"]]
> Origin = (-90.198287963867188,90.300000000000011)
> Pixel Size = (0.015398926739995,-0.015398926739995)
> Metadata:
>   AREA_OR_POINT=Area
> Image Structure Metadata:
>   INTERLEAVE=BAND
> Corner Coordinates:
> Upper Left  ( -90.1982880,  90.3000000) ( 90d11'53.84"W, 90d18' 0.00"N)
> Lower Left  ( -90.1982880,   0.0006936) ( 90d11'53.84"W,  0d 0' 2.50"N)
> Upper Right (     389.001,      90.300) (Invalid angle, 90d18' 0.00"N)
> Lower Right (     389.001,       0.001) (Invalid angle,  0d 0' 2.50"N)
> Center      ( 149.4013126,  45.1503468) (149d24' 4.73"E, 45d 9' 1.25"N)
>
>
> Regards,
> Etienne
>
>
> On Tue, Feb 7, 2012 at 7:05 PM, Frank Warmerdam <[hidden email]> wrote:
> > On Tue, Feb 7, 2012 at 7:40 AM, Etienne Tourigny
> > <[hidden email]> wrote:
> >> Hi all,
> >>
> >> I would like to have information on the status of geolocation array
> >> support in GDAL.
> >>
> >> The relevant RFC4 (http://trac.osgeo.org/gdal/wiki/rfc4_geolocate)  is
> >> still "under development", and the information there is that
> >> GDALCreateGeoLocTransformer "is currently partially implemented".
> >
> > Etienne,
> >
> > I think the geoloc transformer received some fixes from someone
> > other than myself and now is working reasonable well.  It would
> > be desirable to freshen up the RFC and get it passed but it isn't
> > particularly a priority of mine so I'm not likely to drive it in the
> > very near future.
> >
> > Best regards,
> >
> > --
> > ---------------------------------------+--------------------------------------
> > I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
> > light and sound - activate the windows | http://pobox.com/~warmerdam
> > and watch the world go round - Rush    | Geospatial Software Developer
> _______________________________________________
> gdal-dev mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/gdal-dev


_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Geolocation Arrays ??

Anton Korosov
In reply to this post by Etienne Tourigny-3
Hello Etienne!

I also got such error when trying to process MODIS L1B images taken near
the pole. Try to set some limited extent with the -te option for
gdalwarp. It helped me, at least.

Best regards!
Anton

On 02/07/2012 10:22 PM, Etienne Tourigny wrote:

> Even, Frank,
>
> thanks for your answers.  I have run into a problem with using
> gdalwarp with geoloc transform.
>
> In ticket #1895 there is an hdf file for which the HDF4 driver creates
> GEOLOCATION metadata.
>
> Trying gdalwarp on it gives an error, and the result transform is
> incorrect.  Am I doing something wrong, or is this a bug?
>
> command is : gdalwarp -geoloc -t_srs EPSG:4326
> HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13 tmp1.tif
> more info below:
>
> $ gdalinfo HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13
> Driver: HDF4Image/HDF4 Dataset
> Files: A2006005182000.L2_LAC_SST.x.hdf
> Size is 389, 602
> Coordinate System is `'
> Metadata:
> [...]
> Geolocation:
>    LINE_OFFSET=0
>    LINE_STEP=1
>    PIXEL_OFFSET=0
>    PIXEL_STEP=1
>    SRS=GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS
> 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9108"]],AUTHORITY["EPSG","4326"]]
>    X_BAND=1
>    X_DATASET=HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":11
>    Y_BAND=1
>    Y_DATASET=HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":12
> Corner Coordinates:
> [...]
>
> $ gdalwarp -geoloc -t_srs EPSG:4326
> HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13 tmp1.tif
> Creating output file that is 31119P x 5864L.
> Processing input file HDF4_SDS:UNKNOWN:A2006005182000.L2_LAC_SST.x.hdf:13.
> ERROR 1: Too many points (441 out of 441) failed to transform,
> unable to compute output bounds.
> 0...10...20...30...40...50...60...70...80...90...100 - done.
>
> $ gdalinfo tmp1.tif
> Driver: GTiff/GeoTIFF
> Files: tmp1.tif
> Size is 31119, 5864
> Coordinate System is:
> GEOGCS["WGS 84",
>      DATUM["WGS_1984",
>          SPHEROID["WGS 84",6378137,298.257223563,
>              AUTHORITY["EPSG","7030"]],
>          AUTHORITY["EPSG","6326"]],
>      PRIMEM["Greenwich",0],
>      UNIT["degree",0.0174532925199433],
>      AUTHORITY["EPSG","4326"]]
> Origin = (-90.198287963867188,90.300000000000011)
> Pixel Size = (0.015398926739995,-0.015398926739995)
> Metadata:
>    AREA_OR_POINT=Area
> Image Structure Metadata:
>    INTERLEAVE=BAND
> Corner Coordinates:
> Upper Left  ( -90.1982880,  90.3000000) ( 90d11'53.84"W, 90d18' 0.00"N)
> Lower Left  ( -90.1982880,   0.0006936) ( 90d11'53.84"W,  0d 0' 2.50"N)
> Upper Right (     389.001,      90.300) (Invalid angle, 90d18' 0.00"N)
> Lower Right (     389.001,       0.001) (Invalid angle,  0d 0' 2.50"N)
> Center      ( 149.4013126,  45.1503468) (149d24' 4.73"E, 45d 9' 1.25"N)
>
>
> Regards,
> Etienne
>
>
> On Tue, Feb 7, 2012 at 7:05 PM, Frank Warmerdam<[hidden email]>  wrote:
>> On Tue, Feb 7, 2012 at 7:40 AM, Etienne Tourigny
>> <[hidden email]>  wrote:
>>> Hi all,
>>>
>>> I would like to have information on the status of geolocation array
>>> support in GDAL.
>>>
>>> The relevant RFC4 (http://trac.osgeo.org/gdal/wiki/rfc4_geolocate)  is
>>> still "under development", and the information there is that
>>> GDALCreateGeoLocTransformer "is currently partially implemented".
>>
>> Etienne,
>>
>> I think the geoloc transformer received some fixes from someone
>> other than myself and now is working reasonable well.  It would
>> be desirable to freshen up the RFC and get it passed but it isn't
>> particularly a priority of mine so I'm not likely to drive it in the
>> very near future.
>>
>> Best regards,
>>
>> --
>> ---------------------------------------+--------------------------------------
>> I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
>> light and sound - activate the windows | http://pobox.com/~warmerdam
>> and watch the world go round - Rush    | Geospatial Software Developer
> _______________________________________________
> gdal-dev mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Geolocation Arrays ??

Etienne Tourigny-3
Thanks Anton,

The latitudes of this dataset span from 26.77687 to 33.82318 , so
nowhere near the poles!

I tried your suggestion, using the extents from the hdf metadata:

                :Northernmost\ Latitude = 33.82318f ;
                :Southernmost\ Latitude = 26.77687f ;
                :Easternmost\ Longitude = -79.69389f ;
                :Westernmost\ Longitude = -90.15974f ;


$ gdalwarp -geoloc -t_srs EPSG:4326 -te -90.15974 26.77687 -79.69389
33.82318f  --debug off
HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13 tmp1.tif

And casual inspection shows that the value is correctly reprojected
(the outlines of Florida are consistent).

==> Does this mean that gdalwarp -geoloc should always be used with -te option?

Etienne

On Wed, Feb 8, 2012 at 6:21 AM, Anton Korosov <[hidden email]> wrote:

> Hello Etienne!
>
> I also got such error when trying to process MODIS L1B images taken near the
> pole. Try to set some limited extent with the -te option for gdalwarp. It
> helped me, at least.
>
> Best regards!
> Anton
>
>
> On 02/07/2012 10:22 PM, Etienne Tourigny wrote:
>>
>> Even, Frank,
>>
>> thanks for your answers.  I have run into a problem with using
>> gdalwarp with geoloc transform.
>>
>> In ticket #1895 there is an hdf file for which the HDF4 driver creates
>> GEOLOCATION metadata.
>>
>> Trying gdalwarp on it gives an error, and the result transform is
>> incorrect.  Am I doing something wrong, or is this a bug?
>>
>> command is : gdalwarp -geoloc -t_srs EPSG:4326
>> HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13 tmp1.tif
>> more info below:
>>
>> $ gdalinfo HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13
>> Driver: HDF4Image/HDF4 Dataset
>> Files: A2006005182000.L2_LAC_SST.x.hdf
>> Size is 389, 602
>> Coordinate System is `'
>> Metadata:
>> [...]
>> Geolocation:
>>   LINE_OFFSET=0
>>   LINE_STEP=1
>>   PIXEL_OFFSET=0
>>   PIXEL_STEP=1
>>   SRS=GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS
>>
>> 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9108"]],AUTHORITY["EPSG","4326"]]
>>   X_BAND=1
>>   X_DATASET=HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":11
>>   Y_BAND=1
>>   Y_DATASET=HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":12
>> Corner Coordinates:
>> [...]
>>
>> $ gdalwarp -geoloc -t_srs EPSG:4326
>> HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13 tmp1.tif
>> Creating output file that is 31119P x 5864L.
>> Processing input file HDF4_SDS:UNKNOWN:A2006005182000.L2_LAC_SST.x.hdf:13.
>> ERROR 1: Too many points (441 out of 441) failed to transform,
>> unable to compute output bounds.
>> 0...10...20...30...40...50...60...70...80...90...100 - done.
>>
>> $ gdalinfo tmp1.tif
>> Driver: GTiff/GeoTIFF
>> Files: tmp1.tif
>> Size is 31119, 5864
>> Coordinate System is:
>> GEOGCS["WGS 84",
>>     DATUM["WGS_1984",
>>         SPHEROID["WGS 84",6378137,298.257223563,
>>             AUTHORITY["EPSG","7030"]],
>>         AUTHORITY["EPSG","6326"]],
>>     PRIMEM["Greenwich",0],
>>     UNIT["degree",0.0174532925199433],
>>     AUTHORITY["EPSG","4326"]]
>> Origin = (-90.198287963867188,90.300000000000011)
>> Pixel Size = (0.015398926739995,-0.015398926739995)
>> Metadata:
>>   AREA_OR_POINT=Area
>> Image Structure Metadata:
>>   INTERLEAVE=BAND
>> Corner Coordinates:
>> Upper Left  ( -90.1982880,  90.3000000) ( 90d11'53.84"W, 90d18' 0.00"N)
>> Lower Left  ( -90.1982880,   0.0006936) ( 90d11'53.84"W,  0d 0' 2.50"N)
>> Upper Right (     389.001,      90.300) (Invalid angle, 90d18' 0.00"N)
>> Lower Right (     389.001,       0.001) (Invalid angle,  0d 0' 2.50"N)
>> Center      ( 149.4013126,  45.1503468) (149d24' 4.73"E, 45d 9' 1.25"N)
>>
>>
>> Regards,
>> Etienne
>>
>>
>> On Tue, Feb 7, 2012 at 7:05 PM, Frank Warmerdam<[hidden email]>
>>  wrote:
>>>
>>> On Tue, Feb 7, 2012 at 7:40 AM, Etienne Tourigny
>>> <[hidden email]>  wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I would like to have information on the status of geolocation array
>>>> support in GDAL.
>>>>
>>>> The relevant RFC4 (http://trac.osgeo.org/gdal/wiki/rfc4_geolocate)  is
>>>> still "under development", and the information there is that
>>>> GDALCreateGeoLocTransformer "is currently partially implemented".
>>>
>>>
>>> Etienne,
>>>
>>> I think the geoloc transformer received some fixes from someone
>>> other than myself and now is working reasonable well.  It would
>>> be desirable to freshen up the RFC and get it passed but it isn't
>>> particularly a priority of mine so I'm not likely to drive it in the
>>> very near future.
>>>
>>> Best regards,
>>>
>>> --
>>>
>>> ---------------------------------------+--------------------------------------
>>> I set the clouds in motion - turn up   | Frank Warmerdam,
>>> [hidden email]
>>> light and sound - activate the windows | http://pobox.com/~warmerdam
>>> and watch the world go round - Rush    | Geospatial Software Developer
>>
>> _______________________________________________
>>
>> gdal-dev mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> _______________________________________________
> gdal-dev mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Geolocation Arrays ??

Anton Korosov
Hi Etienne!

probably yes. At least that's what I got from an answer from Brian some
time ago:

 > > EOS_SWATH has 2 geolocation arrays, you might try the -geoloc switch to
 >  > gdalwarp, otherwise it creates a handfull of gcps from the arrays, if
 >  > you get a error about points failing to transform, set the output
extent
 >  > with the -te switch.
 >  >
 >  > also you could try the swath2grid application in
 >  > https://lpdaac.usgs.gov/tools/modis_reprojection_tool_swath
 >  >
 >  > Brian

Anton

On 02/08/2012 02:13 PM, Etienne Tourigny wrote:

> Thanks Anton,
>
> The latitudes of this dataset span from 26.77687 to 33.82318 , so
> nowhere near the poles!
>
> I tried your suggestion, using the extents from the hdf metadata:
>
> :Northernmost\ Latitude = 33.82318f ;
> :Southernmost\ Latitude = 26.77687f ;
> :Easternmost\ Longitude = -79.69389f ;
> :Westernmost\ Longitude = -90.15974f ;
>
>
> $ gdalwarp -geoloc -t_srs EPSG:4326 -te -90.15974 26.77687 -79.69389
> 33.82318f  --debug off
> HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13 tmp1.tif
>
> And casual inspection shows that the value is correctly reprojected
> (the outlines of Florida are consistent).
>
> ==>  Does this mean that gdalwarp -geoloc should always be used with -te option?
>
> Etienne
>
> On Wed, Feb 8, 2012 at 6:21 AM, Anton Korosov<[hidden email]>  wrote:
>> Hello Etienne!
>>
>> I also got such error when trying to process MODIS L1B images taken near the
>> pole. Try to set some limited extent with the -te option for gdalwarp. It
>> helped me, at least.
>>
>> Best regards!
>> Anton
>>
>>
>> On 02/07/2012 10:22 PM, Etienne Tourigny wrote:
>>>
>>> Even, Frank,
>>>
>>> thanks for your answers.  I have run into a problem with using
>>> gdalwarp with geoloc transform.
>>>
>>> In ticket #1895 there is an hdf file for which the HDF4 driver creates
>>> GEOLOCATION metadata.
>>>
>>> Trying gdalwarp on it gives an error, and the result transform is
>>> incorrect.  Am I doing something wrong, or is this a bug?
>>>
>>> command is : gdalwarp -geoloc -t_srs EPSG:4326
>>> HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13 tmp1.tif
>>> more info below:
>>>
>>> $ gdalinfo HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13
>>> Driver: HDF4Image/HDF4 Dataset
>>> Files: A2006005182000.L2_LAC_SST.x.hdf
>>> Size is 389, 602
>>> Coordinate System is `'
>>> Metadata:
>>> [...]
>>> Geolocation:
>>>    LINE_OFFSET=0
>>>    LINE_STEP=1
>>>    PIXEL_OFFSET=0
>>>    PIXEL_STEP=1
>>>    SRS=GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS
>>>
>>> 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9108"]],AUTHORITY["EPSG","4326"]]
>>>    X_BAND=1
>>>    X_DATASET=HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":11
>>>    Y_BAND=1
>>>    Y_DATASET=HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":12
>>> Corner Coordinates:
>>> [...]
>>>
>>> $ gdalwarp -geoloc -t_srs EPSG:4326
>>> HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13 tmp1.tif
>>> Creating output file that is 31119P x 5864L.
>>> Processing input file HDF4_SDS:UNKNOWN:A2006005182000.L2_LAC_SST.x.hdf:13.
>>> ERROR 1: Too many points (441 out of 441) failed to transform,
>>> unable to compute output bounds.
>>> 0...10...20...30...40...50...60...70...80...90...100 - done.
>>>
>>> $ gdalinfo tmp1.tif
>>> Driver: GTiff/GeoTIFF
>>> Files: tmp1.tif
>>> Size is 31119, 5864
>>> Coordinate System is:
>>> GEOGCS["WGS 84",
>>>      DATUM["WGS_1984",
>>>          SPHEROID["WGS 84",6378137,298.257223563,
>>>              AUTHORITY["EPSG","7030"]],
>>>          AUTHORITY["EPSG","6326"]],
>>>      PRIMEM["Greenwich",0],
>>>      UNIT["degree",0.0174532925199433],
>>>      AUTHORITY["EPSG","4326"]]
>>> Origin = (-90.198287963867188,90.300000000000011)
>>> Pixel Size = (0.015398926739995,-0.015398926739995)
>>> Metadata:
>>>    AREA_OR_POINT=Area
>>> Image Structure Metadata:
>>>    INTERLEAVE=BAND
>>> Corner Coordinates:
>>> Upper Left  ( -90.1982880,  90.3000000) ( 90d11'53.84"W, 90d18' 0.00"N)
>>> Lower Left  ( -90.1982880,   0.0006936) ( 90d11'53.84"W,  0d 0' 2.50"N)
>>> Upper Right (     389.001,      90.300) (Invalid angle, 90d18' 0.00"N)
>>> Lower Right (     389.001,       0.001) (Invalid angle,  0d 0' 2.50"N)
>>> Center      ( 149.4013126,  45.1503468) (149d24' 4.73"E, 45d 9' 1.25"N)
>>>
>>>
>>> Regards,
>>> Etienne
>>>
>>>
>>> On Tue, Feb 7, 2012 at 7:05 PM, Frank Warmerdam<[hidden email]>
>>>   wrote:
>>>>
>>>> On Tue, Feb 7, 2012 at 7:40 AM, Etienne Tourigny
>>>> <[hidden email]>    wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I would like to have information on the status of geolocation array
>>>>> support in GDAL.
>>>>>
>>>>> The relevant RFC4 (http://trac.osgeo.org/gdal/wiki/rfc4_geolocate)  is
>>>>> still "under development", and the information there is that
>>>>> GDALCreateGeoLocTransformer "is currently partially implemented".
>>>>
>>>>
>>>> Etienne,
>>>>
>>>> I think the geoloc transformer received some fixes from someone
>>>> other than myself and now is working reasonable well.  It would
>>>> be desirable to freshen up the RFC and get it passed but it isn't
>>>> particularly a priority of mine so I'm not likely to drive it in the
>>>> very near future.
>>>>
>>>> Best regards,
>>>>
>>>> --
>>>>
>>>> ---------------------------------------+--------------------------------------
>>>> I set the clouds in motion - turn up   | Frank Warmerdam,
>>>> [hidden email]
>>>> light and sound - activate the windows | http://pobox.com/~warmerdam
>>>> and watch the world go round - Rush    | Geospatial Software Developer
>>>
>>> _______________________________________________
>>>
>>> gdal-dev mailing list
>>> [hidden email]
>>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>> _______________________________________________
>> gdal-dev mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Geolocation Arrays ??

Etienne Tourigny-3
In reply to this post by Brian Case
Brian, thanks fot the info.

I have seen that on all tests I made (without -te option).  Sometimes
it fails completely, and sometimes it creates an extent that is too
large.

Would it make sense, if the geolocation SRS and target are SRS are the
same (e.g. WGS84), to calculate the target extents from the min/max of
the geolocation arrays?
Current extent detection code seems to try many transformations with
proj4, and either fails or creates an extent that is too large.

regards,
Etienne


On Tue, Feb 7, 2012 at 8:46 PM, Brian Case <[hidden email]> wrote:

> Etienne
> with the transformer the way it sits now, in most cases you will need to
> specify -te xmin ymin xmax ymax with gdalwarp to avoid that error
>
> Brian
>
>
> On Tue, 2012-02-07 at 19:22 -0200, Etienne Tourigny wrote:
>> Even, Frank,
>>
>> thanks for your answers.  I have run into a problem with using
>> gdalwarp with geoloc transform.
>>
>> In ticket #1895 there is an hdf file for which the HDF4 driver creates
>> GEOLOCATION metadata.
>>
>> Trying gdalwarp on it gives an error, and the result transform is
>> incorrect.  Am I doing something wrong, or is this a bug?
>>
>> command is : gdalwarp -geoloc -t_srs EPSG:4326
>> HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13 tmp1.tif
>> more info below:
>>
>> $ gdalinfo HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13
>> Driver: HDF4Image/HDF4 Dataset
>> Files: A2006005182000.L2_LAC_SST.x.hdf
>> Size is 389, 602
>> Coordinate System is `'
>> Metadata:
>> [...]
>> Geolocation:
>>   LINE_OFFSET=0
>>   LINE_STEP=1
>>   PIXEL_OFFSET=0
>>   PIXEL_STEP=1
>>   SRS=GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS
>> 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9108"]],AUTHORITY["EPSG","4326"]]
>>   X_BAND=1
>>   X_DATASET=HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":11
>>   Y_BAND=1
>>   Y_DATASET=HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":12
>> Corner Coordinates:
>> [...]
>>
>> $ gdalwarp -geoloc -t_srs EPSG:4326
>> HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13 tmp1.tif
>> Creating output file that is 31119P x 5864L.
>> Processing input file HDF4_SDS:UNKNOWN:A2006005182000.L2_LAC_SST.x.hdf:13.
>> ERROR 1: Too many points (441 out of 441) failed to transform,
>> unable to compute output bounds.
>> 0...10...20...30...40...50...60...70...80...90...100 - done.
>>
>> $ gdalinfo tmp1.tif
>> Driver: GTiff/GeoTIFF
>> Files: tmp1.tif
>> Size is 31119, 5864
>> Coordinate System is:
>> GEOGCS["WGS 84",
>>     DATUM["WGS_1984",
>>         SPHEROID["WGS 84",6378137,298.257223563,
>>             AUTHORITY["EPSG","7030"]],
>>         AUTHORITY["EPSG","6326"]],
>>     PRIMEM["Greenwich",0],
>>     UNIT["degree",0.0174532925199433],
>>     AUTHORITY["EPSG","4326"]]
>> Origin = (-90.198287963867188,90.300000000000011)
>> Pixel Size = (0.015398926739995,-0.015398926739995)
>> Metadata:
>>   AREA_OR_POINT=Area
>> Image Structure Metadata:
>>   INTERLEAVE=BAND
>> Corner Coordinates:
>> Upper Left  ( -90.1982880,  90.3000000) ( 90d11'53.84"W, 90d18' 0.00"N)
>> Lower Left  ( -90.1982880,   0.0006936) ( 90d11'53.84"W,  0d 0' 2.50"N)
>> Upper Right (     389.001,      90.300) (Invalid angle, 90d18' 0.00"N)
>> Lower Right (     389.001,       0.001) (Invalid angle,  0d 0' 2.50"N)
>> Center      ( 149.4013126,  45.1503468) (149d24' 4.73"E, 45d 9' 1.25"N)
>>
>>
>> Regards,
>> Etienne
>>
>>
>> On Tue, Feb 7, 2012 at 7:05 PM, Frank Warmerdam <[hidden email]> wrote:
>> > On Tue, Feb 7, 2012 at 7:40 AM, Etienne Tourigny
>> > <[hidden email]> wrote:
>> >> Hi all,
>> >>
>> >> I would like to have information on the status of geolocation array
>> >> support in GDAL.
>> >>
>> >> The relevant RFC4 (http://trac.osgeo.org/gdal/wiki/rfc4_geolocate)  is
>> >> still "under development", and the information there is that
>> >> GDALCreateGeoLocTransformer "is currently partially implemented".
>> >
>> > Etienne,
>> >
>> > I think the geoloc transformer received some fixes from someone
>> > other than myself and now is working reasonable well.  It would
>> > be desirable to freshen up the RFC and get it passed but it isn't
>> > particularly a priority of mine so I'm not likely to drive it in the
>> > very near future.
>> >
>> > Best regards,
>> >
>> > --
>> > ---------------------------------------+--------------------------------------
>> > I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
>> > light and sound - activate the windows | http://pobox.com/~warmerdam
>> > and watch the world go round - Rush    | Geospatial Software Developer
>> _______________________________________________
>> gdal-dev mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Geolocation Arrays ??

Brian Case
the forward transform is pretty strait forwards, however the reverse is
not, it creates back-mask (a geo-referenced image that contains the x/y locations
in the source image). the points that the warper tries to transform to
figure out the target extent are no-data in the back-mask.

Brian

On Sun, 2012-02-12 at 12:25 -0200, Etienne Tourigny wrote:

> Brian, thanks fot the info.
>
> I have seen that on all tests I made (without -te option).  Sometimes
> it fails completely, and sometimes it creates an extent that is too
> large.
>
> Would it make sense, if the geolocation SRS and target are SRS are the
> same (e.g. WGS84), to calculate the target extents from the min/max of
> the geolocation arrays?
> Current extent detection code seems to try many transformations with
> proj4, and either fails or creates an extent that is too large.
>
> regards,
> Etienne
>
>
> On Tue, Feb 7, 2012 at 8:46 PM, Brian Case <[hidden email]> wrote:
> > Etienne
> > with the transformer the way it sits now, in most cases you will need to
> > specify -te xmin ymin xmax ymax with gdalwarp to avoid that error
> >
> > Brian
> >
> >
> > On Tue, 2012-02-07 at 19:22 -0200, Etienne Tourigny wrote:
> >> Even, Frank,
> >>
> >> thanks for your answers.  I have run into a problem with using
> >> gdalwarp with geoloc transform.
> >>
> >> In ticket #1895 there is an hdf file for which the HDF4 driver creates
> >> GEOLOCATION metadata.
> >>
> >> Trying gdalwarp on it gives an error, and the result transform is
> >> incorrect.  Am I doing something wrong, or is this a bug?
> >>
> >> command is : gdalwarp -geoloc -t_srs EPSG:4326
> >> HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13 tmp1.tif
> >> more info below:
> >>
> >> $ gdalinfo HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13
> >> Driver: HDF4Image/HDF4 Dataset
> >> Files: A2006005182000.L2_LAC_SST.x.hdf
> >> Size is 389, 602
> >> Coordinate System is `'
> >> Metadata:
> >> [...]
> >> Geolocation:
> >>   LINE_OFFSET=0
> >>   LINE_STEP=1
> >>   PIXEL_OFFSET=0
> >>   PIXEL_STEP=1
> >>   SRS=GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS
> >> 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9108"]],AUTHORITY["EPSG","4326"]]
> >>   X_BAND=1
> >>   X_DATASET=HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":11
> >>   Y_BAND=1
> >>   Y_DATASET=HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":12
> >> Corner Coordinates:
> >> [...]
> >>
> >> $ gdalwarp -geoloc -t_srs EPSG:4326
> >> HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13 tmp1.tif
> >> Creating output file that is 31119P x 5864L.
> >> Processing input file HDF4_SDS:UNKNOWN:A2006005182000.L2_LAC_SST.x.hdf:13.
> >> ERROR 1: Too many points (441 out of 441) failed to transform,
> >> unable to compute output bounds.
> >> 0...10...20...30...40...50...60...70...80...90...100 - done.
> >>
> >> $ gdalinfo tmp1.tif
> >> Driver: GTiff/GeoTIFF
> >> Files: tmp1.tif
> >> Size is 31119, 5864
> >> Coordinate System is:
> >> GEOGCS["WGS 84",
> >>     DATUM["WGS_1984",
> >>         SPHEROID["WGS 84",6378137,298.257223563,
> >>             AUTHORITY["EPSG","7030"]],
> >>         AUTHORITY["EPSG","6326"]],
> >>     PRIMEM["Greenwich",0],
> >>     UNIT["degree",0.0174532925199433],
> >>     AUTHORITY["EPSG","4326"]]
> >> Origin = (-90.198287963867188,90.300000000000011)
> >> Pixel Size = (0.015398926739995,-0.015398926739995)
> >> Metadata:
> >>   AREA_OR_POINT=Area
> >> Image Structure Metadata:
> >>   INTERLEAVE=BAND
> >> Corner Coordinates:
> >> Upper Left  ( -90.1982880,  90.3000000) ( 90d11'53.84"W, 90d18' 0.00"N)
> >> Lower Left  ( -90.1982880,   0.0006936) ( 90d11'53.84"W,  0d 0' 2.50"N)
> >> Upper Right (     389.001,      90.300) (Invalid angle, 90d18' 0.00"N)
> >> Lower Right (     389.001,       0.001) (Invalid angle,  0d 0' 2.50"N)
> >> Center      ( 149.4013126,  45.1503468) (149d24' 4.73"E, 45d 9' 1.25"N)
> >>
> >>
> >> Regards,
> >> Etienne
> >>
> >>
> >> On Tue, Feb 7, 2012 at 7:05 PM, Frank Warmerdam <[hidden email]> wrote:
> >> > On Tue, Feb 7, 2012 at 7:40 AM, Etienne Tourigny
> >> > <[hidden email]> wrote:
> >> >> Hi all,
> >> >>
> >> >> I would like to have information on the status of geolocation array
> >> >> support in GDAL.
> >> >>
> >> >> The relevant RFC4 (http://trac.osgeo.org/gdal/wiki/rfc4_geolocate)  is
> >> >> still "under development", and the information there is that
> >> >> GDALCreateGeoLocTransformer "is currently partially implemented".
> >> >
> >> > Etienne,
> >> >
> >> > I think the geoloc transformer received some fixes from someone
> >> > other than myself and now is working reasonable well.  It would
> >> > be desirable to freshen up the RFC and get it passed but it isn't
> >> > particularly a priority of mine so I'm not likely to drive it in the
> >> > very near future.
> >> >
> >> > Best regards,
> >> >
> >> > --
> >> > ---------------------------------------+--------------------------------------
> >> > I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
> >> > light and sound - activate the windows | http://pobox.com/~warmerdam
> >> > and watch the world go round - Rush    | Geospatial Software Developer
> >> _______________________________________________
> >> gdal-dev mailing list
> >> [hidden email]
> >> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> >
> >


_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Geolocation Arrays ??

Etienne Tourigny-3
Brian,

I'm not sure I understand your point - I probably don't understand the
algorithm enough. Are both the forward and reverse transformations
necessary in all cases?

My point is that, if (manually) adding the -te option to gdalwarp is
necessary in most cases, why not (automatically) setting the extents
from the min/max of the geolocation arrays instead of trying to
calculate them?
This could fix when the algorithm fails or generates an extent that is
too large.

Etienne

On Sun, Feb 12, 2012 at 12:38 PM, Brian Case <[hidden email]> wrote:

> the forward transform is pretty strait forwards, however the reverse is
> not, it creates back-mask (a geo-referenced image that contains the x/y locations
> in the source image). the points that the warper tries to transform to
> figure out the target extent are no-data in the back-mask.
>
> Brian
>
> On Sun, 2012-02-12 at 12:25 -0200, Etienne Tourigny wrote:
>> Brian, thanks fot the info.
>>
>> I have seen that on all tests I made (without -te option).  Sometimes
>> it fails completely, and sometimes it creates an extent that is too
>> large.
>>
>> Would it make sense, if the geolocation SRS and target are SRS are the
>> same (e.g. WGS84), to calculate the target extents from the min/max of
>> the geolocation arrays?
>> Current extent detection code seems to try many transformations with
>> proj4, and either fails or creates an extent that is too large.
>>
>> regards,
>> Etienne
>>
>>
>> On Tue, Feb 7, 2012 at 8:46 PM, Brian Case <[hidden email]> wrote:
>> > Etienne
>> > with the transformer the way it sits now, in most cases you will need to
>> > specify -te xmin ymin xmax ymax with gdalwarp to avoid that error
>> >
>> > Brian
>> >
>> >
>> > On Tue, 2012-02-07 at 19:22 -0200, Etienne Tourigny wrote:
>> >> Even, Frank,
>> >>
>> >> thanks for your answers.  I have run into a problem with using
>> >> gdalwarp with geoloc transform.
>> >>
>> >> In ticket #1895 there is an hdf file for which the HDF4 driver creates
>> >> GEOLOCATION metadata.
>> >>
>> >> Trying gdalwarp on it gives an error, and the result transform is
>> >> incorrect.  Am I doing something wrong, or is this a bug?
>> >>
>> >> command is : gdalwarp -geoloc -t_srs EPSG:4326
>> >> HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13 tmp1.tif
>> >> more info below:
>> >>
>> >> $ gdalinfo HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13
>> >> Driver: HDF4Image/HDF4 Dataset
>> >> Files: A2006005182000.L2_LAC_SST.x.hdf
>> >> Size is 389, 602
>> >> Coordinate System is `'
>> >> Metadata:
>> >> [...]
>> >> Geolocation:
>> >>   LINE_OFFSET=0
>> >>   LINE_STEP=1
>> >>   PIXEL_OFFSET=0
>> >>   PIXEL_STEP=1
>> >>   SRS=GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS
>> >> 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9108"]],AUTHORITY["EPSG","4326"]]
>> >>   X_BAND=1
>> >>   X_DATASET=HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":11
>> >>   Y_BAND=1
>> >>   Y_DATASET=HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":12
>> >> Corner Coordinates:
>> >> [...]
>> >>
>> >> $ gdalwarp -geoloc -t_srs EPSG:4326
>> >> HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13 tmp1.tif
>> >> Creating output file that is 31119P x 5864L.
>> >> Processing input file HDF4_SDS:UNKNOWN:A2006005182000.L2_LAC_SST.x.hdf:13.
>> >> ERROR 1: Too many points (441 out of 441) failed to transform,
>> >> unable to compute output bounds.
>> >> 0...10...20...30...40...50...60...70...80...90...100 - done.
>> >>
>> >> $ gdalinfo tmp1.tif
>> >> Driver: GTiff/GeoTIFF
>> >> Files: tmp1.tif
>> >> Size is 31119, 5864
>> >> Coordinate System is:
>> >> GEOGCS["WGS 84",
>> >>     DATUM["WGS_1984",
>> >>         SPHEROID["WGS 84",6378137,298.257223563,
>> >>             AUTHORITY["EPSG","7030"]],
>> >>         AUTHORITY["EPSG","6326"]],
>> >>     PRIMEM["Greenwich",0],
>> >>     UNIT["degree",0.0174532925199433],
>> >>     AUTHORITY["EPSG","4326"]]
>> >> Origin = (-90.198287963867188,90.300000000000011)
>> >> Pixel Size = (0.015398926739995,-0.015398926739995)
>> >> Metadata:
>> >>   AREA_OR_POINT=Area
>> >> Image Structure Metadata:
>> >>   INTERLEAVE=BAND
>> >> Corner Coordinates:
>> >> Upper Left  ( -90.1982880,  90.3000000) ( 90d11'53.84"W, 90d18' 0.00"N)
>> >> Lower Left  ( -90.1982880,   0.0006936) ( 90d11'53.84"W,  0d 0' 2.50"N)
>> >> Upper Right (     389.001,      90.300) (Invalid angle, 90d18' 0.00"N)
>> >> Lower Right (     389.001,       0.001) (Invalid angle,  0d 0' 2.50"N)
>> >> Center      ( 149.4013126,  45.1503468) (149d24' 4.73"E, 45d 9' 1.25"N)
>> >>
>> >>
>> >> Regards,
>> >> Etienne
>> >>
>> >>
>> >> On Tue, Feb 7, 2012 at 7:05 PM, Frank Warmerdam <[hidden email]> wrote:
>> >> > On Tue, Feb 7, 2012 at 7:40 AM, Etienne Tourigny
>> >> > <[hidden email]> wrote:
>> >> >> Hi all,
>> >> >>
>> >> >> I would like to have information on the status of geolocation array
>> >> >> support in GDAL.
>> >> >>
>> >> >> The relevant RFC4 (http://trac.osgeo.org/gdal/wiki/rfc4_geolocate)  is
>> >> >> still "under development", and the information there is that
>> >> >> GDALCreateGeoLocTransformer "is currently partially implemented".
>> >> >
>> >> > Etienne,
>> >> >
>> >> > I think the geoloc transformer received some fixes from someone
>> >> > other than myself and now is working reasonable well.  It would
>> >> > be desirable to freshen up the RFC and get it passed but it isn't
>> >> > particularly a priority of mine so I'm not likely to drive it in the
>> >> > very near future.
>> >> >
>> >> > Best regards,
>> >> >
>> >> > --
>> >> > ---------------------------------------+--------------------------------------
>> >> > I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
>> >> > light and sound - activate the windows | http://pobox.com/~warmerdam
>> >> > and watch the world go round - Rush    | Geospatial Software Developer
>> >> _______________________________________________
>> >> gdal-dev mailing list
>> >> [hidden email]
>> >> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>> >
>> >
>
>
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: Geolocation Arrays ??

Brian Case
Etienne

the algorithm that finds the target extent is not in the transformer

Brian

On Sun, 2012-02-12 at 13:17 -0200, Etienne Tourigny wrote:

> Brian,
>
> I'm not sure I understand your point - I probably don't understand the
> algorithm enough. Are both the forward and reverse transformations
> necessary in all cases?
>
> My point is that, if (manually) adding the -te option to gdalwarp is
> necessary in most cases, why not (automatically) setting the extents
> from the min/max of the geolocation arrays instead of trying to
> calculate them?
> This could fix when the algorithm fails or generates an extent that is
> too large.
>
> Etienne
>
> On Sun, Feb 12, 2012 at 12:38 PM, Brian Case <[hidden email]> wrote:
> > the forward transform is pretty strait forwards, however the reverse is
> > not, it creates back-mask (a geo-referenced image that contains the x/y locations
> > in the source image). the points that the warper tries to transform to
> > figure out the target extent are no-data in the back-mask.
> >
> > Brian
> >
> > On Sun, 2012-02-12 at 12:25 -0200, Etienne Tourigny wrote:
> >> Brian, thanks fot the info.
> >>
> >> I have seen that on all tests I made (without -te option).  Sometimes
> >> it fails completely, and sometimes it creates an extent that is too
> >> large.
> >>
> >> Would it make sense, if the geolocation SRS and target are SRS are the
> >> same (e.g. WGS84), to calculate the target extents from the min/max of
> >> the geolocation arrays?
> >> Current extent detection code seems to try many transformations with
> >> proj4, and either fails or creates an extent that is too large.
> >>
> >> regards,
> >> Etienne
> >>
> >>
> >> On Tue, Feb 7, 2012 at 8:46 PM, Brian Case <[hidden email]> wrote:
> >> > Etienne
> >> > with the transformer the way it sits now, in most cases you will need to
> >> > specify -te xmin ymin xmax ymax with gdalwarp to avoid that error
> >> >
> >> > Brian
> >> >
> >> >
> >> > On Tue, 2012-02-07 at 19:22 -0200, Etienne Tourigny wrote:
> >> >> Even, Frank,
> >> >>
> >> >> thanks for your answers.  I have run into a problem with using
> >> >> gdalwarp with geoloc transform.
> >> >>
> >> >> In ticket #1895 there is an hdf file for which the HDF4 driver creates
> >> >> GEOLOCATION metadata.
> >> >>
> >> >> Trying gdalwarp on it gives an error, and the result transform is
> >> >> incorrect.  Am I doing something wrong, or is this a bug?
> >> >>
> >> >> command is : gdalwarp -geoloc -t_srs EPSG:4326
> >> >> HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13 tmp1.tif
> >> >> more info below:
> >> >>
> >> >> $ gdalinfo HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13
> >> >> Driver: HDF4Image/HDF4 Dataset
> >> >> Files: A2006005182000.L2_LAC_SST.x.hdf
> >> >> Size is 389, 602
> >> >> Coordinate System is `'
> >> >> Metadata:
> >> >> [...]
> >> >> Geolocation:
> >> >>   LINE_OFFSET=0
> >> >>   LINE_STEP=1
> >> >>   PIXEL_OFFSET=0
> >> >>   PIXEL_STEP=1
> >> >>   SRS=GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS
> >> >> 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],TOWGS84[0,0,0,0,0,0,0],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9108"]],AUTHORITY["EPSG","4326"]]
> >> >>   X_BAND=1
> >> >>   X_DATASET=HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":11
> >> >>   Y_BAND=1
> >> >>   Y_DATASET=HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":12
> >> >> Corner Coordinates:
> >> >> [...]
> >> >>
> >> >> $ gdalwarp -geoloc -t_srs EPSG:4326
> >> >> HDF4_SDS:UNKNOWN:"A2006005182000.L2_LAC_SST.x.hdf":13 tmp1.tif
> >> >> Creating output file that is 31119P x 5864L.
> >> >> Processing input file HDF4_SDS:UNKNOWN:A2006005182000.L2_LAC_SST.x.hdf:13.
> >> >> ERROR 1: Too many points (441 out of 441) failed to transform,
> >> >> unable to compute output bounds.
> >> >> 0...10...20...30...40...50...60...70...80...90...100 - done.
> >> >>
> >> >> $ gdalinfo tmp1.tif
> >> >> Driver: GTiff/GeoTIFF
> >> >> Files: tmp1.tif
> >> >> Size is 31119, 5864
> >> >> Coordinate System is:
> >> >> GEOGCS["WGS 84",
> >> >>     DATUM["WGS_1984",
> >> >>         SPHEROID["WGS 84",6378137,298.257223563,
> >> >>             AUTHORITY["EPSG","7030"]],
> >> >>         AUTHORITY["EPSG","6326"]],
> >> >>     PRIMEM["Greenwich",0],
> >> >>     UNIT["degree",0.0174532925199433],
> >> >>     AUTHORITY["EPSG","4326"]]
> >> >> Origin = (-90.198287963867188,90.300000000000011)
> >> >> Pixel Size = (0.015398926739995,-0.015398926739995)
> >> >> Metadata:
> >> >>   AREA_OR_POINT=Area
> >> >> Image Structure Metadata:
> >> >>   INTERLEAVE=BAND
> >> >> Corner Coordinates:
> >> >> Upper Left  ( -90.1982880,  90.3000000) ( 90d11'53.84"W, 90d18' 0.00"N)
> >> >> Lower Left  ( -90.1982880,   0.0006936) ( 90d11'53.84"W,  0d 0' 2.50"N)
> >> >> Upper Right (     389.001,      90.300) (Invalid angle, 90d18' 0.00"N)
> >> >> Lower Right (     389.001,       0.001) (Invalid angle,  0d 0' 2.50"N)
> >> >> Center      ( 149.4013126,  45.1503468) (149d24' 4.73"E, 45d 9' 1.25"N)
> >> >>
> >> >>
> >> >> Regards,
> >> >> Etienne
> >> >>
> >> >>
> >> >> On Tue, Feb 7, 2012 at 7:05 PM, Frank Warmerdam <[hidden email]> wrote:
> >> >> > On Tue, Feb 7, 2012 at 7:40 AM, Etienne Tourigny
> >> >> > <[hidden email]> wrote:
> >> >> >> Hi all,
> >> >> >>
> >> >> >> I would like to have information on the status of geolocation array
> >> >> >> support in GDAL.
> >> >> >>
> >> >> >> The relevant RFC4 (http://trac.osgeo.org/gdal/wiki/rfc4_geolocate)  is
> >> >> >> still "under development", and the information there is that
> >> >> >> GDALCreateGeoLocTransformer "is currently partially implemented".
> >> >> >
> >> >> > Etienne,
> >> >> >
> >> >> > I think the geoloc transformer received some fixes from someone
> >> >> > other than myself and now is working reasonable well.  It would
> >> >> > be desirable to freshen up the RFC and get it passed but it isn't
> >> >> > particularly a priority of mine so I'm not likely to drive it in the
> >> >> > very near future.
> >> >> >
> >> >> > Best regards,
> >> >> >
> >> >> > --
> >> >> > ---------------------------------------+--------------------------------------
> >> >> > I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
> >> >> > light and sound - activate the windows | http://pobox.com/~warmerdam
> >> >> > and watch the world go round - Rush    | Geospatial Software Developer
> >> >> _______________________________________________
> >> >> gdal-dev mailing list
> >> >> [hidden email]
> >> >> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> >> >
> >> >
> >
> >


_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev