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. _______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user