Landsat image tiffs

[Zenon Panoussis]

Dylan Beaudette wrote:

>> > 1. valid projection settings for your MAP file:

>> > #my sample:
>> > PROJECTION
>> > "+proj=aea +x_0=0.0 +y_0=0 +lon_0=-96 +lat_0=40.0 +lat_1=20 +lat_2=60.0
>> > +datum=NAD83"
>> > END

>> You syntax confuses me and
>> http://mapserver.gis.umn.edu/docs/reference/mapfile/projection/
>> doesn't offer any help at all with it. What's x and y and why do you
>> have one lon and three lat? My map is 90N 90S 180W 180E wgs84.

> Well getting into GIS will take some reading. My projection happens to
> be an Albers equal area projection, with 2 standard parallels. If
> things do not make sense then you will need to get up to speed on the
> conecpt of projection, datum, etc. This will have to be done outside
> of the mapserver / GRASS documentation. If you are near a library, I
> would recommend Principals of Cartography.

It's not the projection itself that confuses me, but your syntax. The form
"+proj=  +x_0=  +t_0=  etc" is not consistent with the PROJECTION syntax
at http://mapserver.gis.umn.edu/docs/reference/mapfile/projection/ . Could
you point me to some manual for your way of writing it?

>> > 2. valid projection string in your raster layer defs

>> ... When I try anyway with
>>     PROJECTION
>>       "proj=latlong"
>>       "ellps=WGS84"
>>       "datum=WGS84"
>>     END
>> in both the map and the layer, it makes no difference at all.

> Here is what will make a difference:

> 1. your map file having a valid projection stanza
> 2. your raster layer having a valid projection stanza
> 3. you raster containing embedded projection data, or at least a world file

I'm sure you're right about projecting maps, but by "it makes no difference
at all" I was referring to my tiff not being displayed, not to making good
maps in general.

>> > #patch together the landsat scenes
>> > r.patch in=`g.mlist type=rast pattern=*.rgb sep=","` out=az_landsat

>> I'm now working on one single scene, so this part is not yet relevant.
>> Later I plan landsat coverage over a bigger area, all of Peru, and I
>> fear that patched scenes will cause greater distorsions when reprojected
>> from UTM, than single scenes suffer individually. Anyway, that's a later
>> headache.

> Yes, you will have to deal with this at some point. do all of the
> scenes come as UTM? where are you getting them from?

All of them are UTM and in different zones to boot. Free download from
ftp://imagery:c6c30U53R@cgceopush2.geo.msu.edu/ . There is a front-end to
it somewhere with a nice scene locator and selector, but I never bookmarked
it and I can't find it any more.

> As with all FOSS projects, please feel free to
> contribute to the documentation. I know that the GRASS team is always
> looking for this type of help.

At this point I am not capable of writing real documentation without
misleading the reader to commit all my mistakes all over again. All
I can do is be verbose in my postings and thereby hopefully of use
to the next guy googling (why is the list archive password-protected?).
The problem however - which is not specific to grass but very common
in FOSS in general - is more fundamental than that. For example, take
a look at http://mapserver.gis.umn.edu/docs/reference/mapfile/join .
It says "Please note this particular documentation is in a state of
flux while I do a bit of source code review..." If I'm reading this
correctly, one person wrote the code and no documentation, and another
person is struggling to write the documentation out of the code. It
shouldn't be like this, code should never be committed unless all the
documentation, from man page to reference and howto, is committed at
the same time.

The extra trouble with GIS software is that it has a narrow user base
and a broad usage spectrum, so there is bound to be less community-driven
documentation. You have a problem with PHP and a kazillion people can
help you and have already answered your question, but you can't expect
the same when you have a problem with proj. Therefore, the need of good
original documentation is greater in this field.

Mind you, I'm not whining, just stating facts (and being rather off-topic).
As I said, whenever I can pull my straw to the stack, I happily do so.

>> Now the surprise: while I was typing that last paragraph, the problem got
>> solved. I have no idea why, but I do know how.

> Here is my interpretation. r.out.gdal is producing a geotiff encoded
> in a way that mapserver cannot properly decode (orange rectangle). I
> have found this to be the case for a while now. r.out.tiff will
> produce acceptable output in 8-bit _or_ 24-bit color (note the -p
> flag), however the file will be a TIFF and not a GeoTIFF.
> gdal_translate can be used to add the spatial reference system, and
> create a proper GeoTIFF form this output. This file can then be warped
> and used in mapserver.

In that case I guessed right when I wrote that this falls in the cracks
between grass, gdal and mapserver. If your interpretation is correct,
it is unclear whether mapserver should be adjusted to understand what
comes out of r.out.gdal, or r.out.gdal adjusted to produce output that
mapserver can understand. It's a buggy situation, but not necessarily
a bug.

>> It still remains to figure why the output of r.out.gdal doesn't work
>> the same way. Anyone with better understanding of tiff internals than
>> mine, please take a shot.

> Dunno. I think that it is a bug with r.out.gdal. I would ask on the
> GRASS list or GDAL or both.

I'll wait until I have something more concrete about that distorsion of
my location, until I know for sure whether i.landsat.rgb caused it or not,
then I'll try to summarise this on the grass list. In any case, I wouldn't
be surprised if Markus reads this list and I'm pretty sure Frank does,
so reposting might not even be necessary.

> Looking forward to seeing the working demo sometime!

It's still a long way to go and a lot of head-banging ahead. The funny
thing is, the more annoyingly difficult and frustrating something is,
the greater the satisfaction when you finally manage to solve it. In this
sense, I have to admit, I have had great joy with GIS so far ;-)

Z