Landsat image tiffs

[Dylan Beaudette]

On Saturday 19 August 2006 18:25, Zenon Panoussis wrote:
> 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?

This is the PROJ4 syntax, as used on the command line, or with the GDAL 
utilities. Mapserver will use this or, the simpler to read form as referenced 
in the URL that you mention.

> >> > 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.

It does make a difference in terms of your map being displayed. If you setup 
your map file with some extent in DD, and define a LAYER that is not in the 
same projection you will likely see nothing. Similar problems when the layer 
in question does not have a spatial reference system encoded into the file, 
or a world file in the case of a raster.

> >> > #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.

You can do some test cases to see if this is not true, but you might be able 
to save yourself quite a bit of time by first projecting the data into a 
consistant, and suitable coordinate system; and then operating on the result 
from within a single GRASS location.

> > 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.

Agreed. I have struggled with the same issues in both mapserver and other such 
projects. Unfortunately documentation is not always written at the same speed 
as the code. If you feel strongly about this, bring it up with the OSGeo 
people- and people will probably listen.

> 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.

That is what these mailing lists serve as.

> 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.

Mapserver clearly understands a specific _subset_ of what a GeoTIFF can 
contain. That being said, it would be a good time to determine just what 
Mapserver can do in this regard. Any ideas on this Frank W ? 

The problem with r.out.gdal has been discussed on the GRASS mailing list for a 
while, and I have lost track of where things lie. I'll post some thoughts to 
the GRASS list soon.

> >> 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.

Indeed. :)

> > 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

Keep trying, you certainly picked one of the more difficult disciplines to 
jump into. It has taken me a while to get my projects in order, but I must 
sometimes admit to my self that there is much left to learn.

Cheers,

-- 
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341