<html style="direction: ltr;">
<head>
<meta content="text/html; charset=windows-1255"
http-equiv="Content-Type">
<style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
</head>
<body style="direction: ltr;"
bidimailui-detected-decoding-type="preferred-charset"
bgcolor="#FFFFFF" text="#000000">
Hi Ken<br>
<br>
<div class="moz-cite-prefix">On 07/17/2016 02:06 PM, Ken Mankoff
wrote:<br>
</div>
<blockquote cite="mid:m2d1mc34n2.fsf@gmail.com" type="cite">
<pre wrap="">Hi Micha,
Sorry if my terminology was incorrect and confused the issue.
On 2016-07-17 at 05:45, Micha Silver <a class="moz-txt-link-rfc2396E" href="mailto:micha@arava.co.il"><micha@arava.co.il></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">First, I have never heard of UTM 33X. Normally UTM zones are either
north or south. So you might have UTM 33N, or UTM 33S. All UTM north
zones that are based on the WGS84 datum are numbered: 326zz, where zz
is the zone. So if your data is in UTM 33N, the EPSG code will be
32633. All UTM south projections (again based on WGS84) are numbered
327zz, with the zz=zone again.
</pre>
</blockquote>
<pre wrap="">
33X exists. It covers Svalbard.
See <a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/Universal_Transverse_Mercator_coordinate_system#Exceptions">https://en.wikipedia.org/wiki/Universal_Transverse_Mercator_coordinate_system#Exceptions</a>
</pre>
</blockquote>
Well, shame on me for missing that.<br>
I like to take part in these mail lists because I learn something
new all the time!<br>
<br>
Helmut already pointed to trying gdalinfo on the file.grid. If that
does not return a full projection description then either get the
full projection info from the data provider, or try to manually
setup a GRASS location with the parameters for UTM 33X, then import
the original into that correctly defined location with the -o option
to r.in.gdal . At that point you will be able to re-project to other
projections.<br>
<br>
<blockquote cite="mid:m2d1mc34n2.fsf@gmail.com" type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">And if I'm in another projection, and I try to import with =r.proj=,
it does not work:
</pre>
</blockquote>
<pre wrap="">
The r.proj module does not import. Rather it does reprojection between
one CRS and another.
</pre>
</blockquote>
<pre wrap="">
Yes, I mean reproject, although I think of it as importing from an existing location to a new location.
</pre>
<blockquote type="cite">
<pre wrap="">So: I think you should setup a GRASS LOCATION and MAPSET (using the
wizard) based on the EPSG code 32633 (or 32733 if your data is UTM
33S), then, within a GRASS session in that LOCATION just do: r.in.gdal
-c input=file.grd output=file
</pre>
</blockquote>
<pre wrap="">
I've let grass define the location using the "-c" flag to the grass command, then imported it with r.in.gdal. But because it is 33X, the location isn't fully defined, and I cannot reproject.
If I follow your advice, it does not work:
</pre>
</blockquote>
<br>
<blockquote cite="mid:m2d1mc34n2.fsf@gmail.com" type="cite">
<pre wrap="">
$ grass70 -c epsg:32633 tmp
GRASS 7.0.3 (tmp): > r.in.gdal input=file.grid output=file
ERROR: Projection of dataset does not appear to match current location.
-k.
</pre>
</blockquote>
<br>
</body>
</html>