[GRASS-user] [gdal-dev] Working with NTF files

[Markus Metz]

On Sat, Jul 20, 2013 at 9:20 PM, Nikos Alexandris
<nik at nikosalexandris.net> wrote:
>
> 1)
>> What says g.proj georef=your_geofile -p?
>
> g.proj -p georef=15JUN11IK0101000po_697515_pan_0000000.ntf
>
> Trying to open with OGR...
> ...succeeded.
> WARNING: Read of file 15JUN11IK0101000po_697515_pan_0000000.ntf was
> successful, but it did not contain projection information. 'XY
> (unprojected)' will be used
> XY location (unprojected)

>
> This is however 1) strange -- it misses a message like "Trying to open with
> GDAL..." and 2) (successively) not true because gdalinfo reports:

g.proj first tries to open the geofile with OGR, if that fails, it
tries to open it with GDAL. Apparently OGR found a driver with which
it could successfully open the geofile. This might be a bug in OGR
(Frank?).

> Using this file in
>
> "grass7 -c 15JUN11IK0101000po_697515_pan_0000000.tif /grassdb/test_Location"
>
> creates the following Location:
>
> g.proj -p
> -PROJ_INFO-------------------------------------------------
> name : Lat/Lon
> proj : ll
> datum : wgs84
> ellps : wgs84
> no_defs : defined
> -PROJ_UNITS------------------------------------------------
> unit : degree
> units : degrees
> meters : 1.0
>
grass7 -c uses g.proj to create a location, thus the resulting
projection info of grass7 -c and g.proj georef= should be identical.
>
> 2)
>
>> What reports r.in.gdal when trying to import in a location that
>> definitively does not match the SRS?
> Now, r.in.gdal seems to correctly recognise the SRS!

Good.

So it is either a bug in g.proj (even though the call to OGROpen()
succeeds) or in OGR.

Markus M