Dylan Beaudette wrote: >>>>> "+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"
> 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. Alright, thanks. Talking about which, thanks for your help in general too. I wouldn't have made it without it. [projecting or not] > 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. Would it be correct to say that projecting the map and the layers will save you from layers not working, but not projecting in your map file will catch wrong projections in your input data? That is, assuming that for reasons of efficiency you don't want mapserver to have to reproject on the fly, wouldn't a map file without projections be preferable in a production environment? I am assuming now that you can and should reproject your input data to one common projection, but I don't know that for a fact. [UTM landsat scenes in various zones] > 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. That's not at all a bad idea, and it might also save me from some ugly black lines I got at the edges of my tiffs (not the original null data, but on the very edge of the images outside the null data areas, in what probably represents the exact difference between the projections) when I reprojected ready images. Z
