Thanks for the suggestions.<br><br>Markus:<br><br>
> Please post<br>
> g.proj -p<br><br>-PROJ_INFO--------------------<div id=":8c">-----------------------------<br>name       : Mercator<br>proj       : merc<br>datum      : wgs84<br>ellps      : wgs84<br>lon_0      : 0<br>k          : 1<br>
x_0        : 0<br>
y_0        : 0<br>no_defs    : defined<br>-PROJ_UNITS------------------------------------------------<br>unit       : metre<br>units      : metres<br>meters     : 1<br><br>Doesn't seem to have a problem, does it?<br>
<br>
Now I looked at the revised wiki (thanks Hamish) and followed it entirely.<br><br>It worked. I guess either I hadn't followed everything the last time or this r.region part was<br>really needed.<br><br>OK, but I have another problem.<br>

<br>When I first imported the data to the latlog location, besides being flipped, it appeared stretched in the N-S direction.<br>When I fixed it with region w=-180 e=180, everything fell back to its correct place and it was fine, with no more stretching.<br>

<br>Now, when I reprojected it, it is stretched again.<br><br>Doing g.region in my latlong location, I get a resolution of 5 minutes with rows=2159 cols=4321. <br>When I r.proj -g in the mercator location, following Hamish suggestion, I get<br>

Input Projection Parameters:  +proj=longlat +no_defs +a=6378137 +rf=298.257223563 +towgs84=0.000,0.000,0.000<br>Input Unit Factor: 1<br>Output
 Projection Parameters:  +proj=merc +lon_0=0 +k=1 +x_0=0 +y_0=0 +no_defs
 +a=6378137 +rf=298.257223563 +towgs84=0.000,0.000,0.000<br>
Output Unit Factor: 1<br>Input map <rbd@ATLANTIC> in location <GEBCO_GEODETIC>:<br>n=46050366.66617828 s=-46050366.66617872 w=-20028233.86541469 e=20028233.86541469 rows=2159 cols=4321<br> <br>But when I apply the n-s w-e it suggests and r.proj again:<br>

<br>Input:<br>Cols: 4321 (4321)<br>Rows: 2159 (2159)<br>North: 89.916705 (89.916705)<br>South: -89.916705 (-89.916705)<br>West: -179.916686 (-179.916686)<br>East: 179.916686 (179.916686)<br>EW-res: 0.083275<br>NS-res: 0.083295<br>

<br>Output:<br>Cols: 4321 (4321)<br>Rows: 2159 (2159)<br>North: 46050366.666178 (46050366.666178)<br>South: -46050366.666179 (-46050366.666179)<br>West: -20028233.865415 (-20028233.865415)<br>East: 20028233.865415 (20028233.865415)<br>

EW-res: 9270.184617<br>NS-res: 42658.977921<br><br><br>You see? It stretched the NS-res. Is it me or the data? (probably me, of course).<br><br>Thanks again,<br>Marcello.</div><br><br><div class="gmail_quote">On Mon, Jul 2, 2012 at 2:47 AM, Hamish <span dir="ltr"><<a href="mailto:hamish_b@yahoo.com" target="_blank">hamish_b@yahoo.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Markus:<br>
<div class="im">> ...<br>
> >  |     <br>
>    Projection: x,y<br>
><br>
> ... this looks suspicious! Above output may help us to find<br>
> the problem.<br>
<br>
</div>probably he was following my tutorial at<br>
 <a href="http://grass.osgeo.org/wiki/Global_datasets#ETOPO1_.28DEM.29" target="_blank">http://grass.osgeo.org/wiki/Global_datasets#ETOPO1_.28DEM.29</a><br>
<br>
which uses a nasty hack to get around the original grid-registered<br>
data exceeding the limits of polar coordinate space:<br>
r.in.bin -f in=etopo1_bed_g.flt out=etopo1_bed_g \<br>
   n=90.008333333335 s=-90.008333333335 e=180.00833333334 \<br>
   w=-180.00833333334 rows=10801 cols=21601 anull=-9999<br>
<br>
but the cellhd/ file was not reset in sync with the location.<br>
<br>
I have now rewriten that wiki entry to use a r.region cleanup<br>
method instead of ugly filesystem edits.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
Hamish<br>
</font></span></blockquote></div><br>