Hei, Even if the issue is solved, some additional info might shed some more light on this.
The X in 33X is specific for the Military Grid Reference System (http://mgrs-data.org/), which is still frequently used in e.g. some botanical journals. There is no EPSG code for MGRS since there are several exceptions for grid cell sizes where cells like 33X or 32V were expanded, while other, neighboring cells were shrunk. For practical purposes, 33X can be treated as WGS84/UTM 33N represented by EPSG:32633 (as e.g. 32V equals to WGS84/UTM 32N). Kind regards, Stefan -----Original Message----- From: grass-user [mailto:[email protected]] On Behalf Of Ken Mankoff Sent: 17. juli 2016 16:48 To: Micha Silver <[email protected]> Cc: GRASS users list <[email protected]> Subject: Re: [GRASS-user] UTM 33x Hi Micha and Helmut, Thanks again for your help so far, and sorry to everyone else for filling your mailboxes on a Sunday morning. It seems that Micha suggested the fix several emails ago (as did Helmut), which is to try to import into 33N and see what happens. I replied: > If I follow your advice, it does not work: > $ 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. But if you tell GRASS to ignore the data projection, with "r.in.gdal -o", then it does appear to work (especially after dealing with other issues, such as re-setting the region with "g.region raster=file" after importing). Thank you, Micha and Helmut, for helping me figure this out, -k. _______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user _______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
