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

[Nikos Alexandris]

Should I file for this a ticket in GRASS' trac first?

Nikos

--%<---

1)

Markus Metz wrote:
> >> What says g.proj georef=your_geofile -p?

Nikos Alexandris:
> > 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:

Markus M:
> 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?).

Nikos A: 
> > 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

Markus M:
> 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)

Markus M:
> >> What reports r.in.gdal when trying to import in a location that
> >> definitively does not match the SRS?

Nikos A:
> > Now, r.in.gdal seems to correctly recognise the SRS!

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