[GRASS-user] Creating mapset and/or importing data based on a proj4 string

GRASS GRASS user
,
1

Dear List,

Most of the time when I work with data in GRASS it is a provided on a standard GIS grid (EPSG code) and I can work with it easily. I create a location using the “-c” option when I start GRASS, or I import it into an existing mapset with r.import.

I’m now working with data and all I know is this:

+proj=stere +lat_0=90 +lat_ts=71 +lon_0=-39 +k=1 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs”

In the past, when working with a few variables and this information, and lat/lon grids in the NetCDF file, I would export the data (using Python) to lat,lon,data, and then r.in.ascii and project it that way. However, now I’m working with 14,000 high resolution daily records on the above projection.

It seems the only way to do this efficiently is to work in the projection of the data, and r.import the few other variables to this projection. Or perhaps cdo or gdal or some other 3rd party tool can quickly re-project everything for me to a known EPSG code. I’ve solved this before with vectors, ogr2ogr, and arbitrary proj4 strings.

Can anyone here suggest how to best get this data into GRASS?

I’ve tried using gdalwarp:

gdalwarp -of GTIFF -s_srs “+proj=stere +lat_0=90 +lat_ts=71 +lon_0=-39 +k=1 +x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs” -t_srs EPSG:3413 NETCDF:“${file}”:RU out.tif

But am concerned because when I then run gdalinfo on the out.tif file, it reports strange bounds such as:

Origin = (-909.965548780931840,1546.900601999830769)
Pixel Size = (7.477558376763198,-7.477558376763198)
Corner Coordinates:
Upper Left ( -909.966, 1546.901) (165d27’58.34"E, 89d59’ 0.36"N)
Lower Left ( -909.966, -1264.661) ( 80d44’10.54"W, 89d59’ 8.22"N)
Upper Right ( 794.918, 1546.901) (107d48’ 8.56"E, 89d59’ 2.20"N)
Lower Right ( 794.918, -1264.661) ( 12d50’53.17"W, 89d59’10.36"N)
Center ( -57.524, 141.120) (157d10’37.34"E, 89d59’54.94"N)

Which seems to be very close to the pole (both lower and upper at >89 deg). This should be covering a much large portion of the Arctic.

Thanks,

-k.

2

Le 6 octobre 2017 09:44:41 GMT+02:00, Ken Mankoff <mankoff@gmail.com> a écrit :

Dear List,

Most of the time when I work with data in GRASS it is a provided on a
standard GIS grid (EPSG code) and I can work with it easily. I create a
location using the "-c" option when I start GRASS, or I import it into
an
existing mapset with r.import.

I'm now working with data and all I know is this:

+proj=stere +lat_0=90 +lat_ts=71 +lon_0=-39 +k=1 +x_0=0 +y_0=0
+datum=WGS84
+units=m +no_defs”

In the past, when working with a few variables and this information,
and
lat/lon grids in the NetCDF file, I would export the data (using
Python) to
lat,lon,data, and then r.in.ascii and project it that way. However, now
I'm
working with 14,000 high resolution daily records on the above
projection.

It seems the only way to do this efficiently is to work in the
projection
of the data, and r.import the few other variables to this projection.
Or
perhaps cdo or gdal or some other 3rd party tool can quickly re-project
everything for me to a known EPSG code. I've solved this before with
vectors, ogr2ogr, and arbitrary proj4 strings.

Can anyone here suggest how to best get this data into GRASS?

You can use either the GUI startup location creation wizard and chose proj.4
string as way to define the projection or in any existing location use g.proj with the 'proj4' and location' parameters.

It would probably be nice if the startup script could handle proj.4 strings. You can file an enhancement request.

Moritz

3

Ken Mankoff wrote

Dear List,

Most of the time when I work with data in GRASS it is a provided on a
standard GIS grid (EPSG code) and I can work with it easily. I create a
location using the "-c" option when I start GRASS, or I import it into an
existing mapset with r.import.

I'm now working with data and all I know is this:

+proj=stere +lat_0=90 +lat_ts=71 +lon_0=-39 +k=1 +x_0=0 +y_0=0
+datum=WGS84
+units=m +no_defs”

In the past, when working with a few variables and this information, and
lat/lon grids in the NetCDF file, I would export the data (using Python)
to
lat,lon,data, and then r.in.ascii and project it that way. However, now
I'm
working with 14,000 high resolution daily records on the above projection.

It seems the only way to do this efficiently is to work in the projection
of the data, and r.import the few other variables to this projection. Or
perhaps cdo or gdal or some other 3rd party tool can quickly re-project
everything for me to a known EPSG code. I've solved this before with
vectors, ogr2ogr, and arbitrary proj4 strings.

Can anyone here suggest how to best get this data into GRASS?

I've tried using gdalwarp:

gdalwarp -of GTIFF -s_srs "+proj=stere +lat_0=90 +lat_ts=71 +lon_0=-39
+k=1
+x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs" -t_srs EPSG:3413
NETCDF:"${file}":RU out.tif

But am concerned because when I then run gdalinfo on the out.tif file, it
reports strange bounds such as:

Origin = (-909.965548780931840,1546.900601999830769)
Pixel Size = (7.477558376763198,-7.477558376763198)
Corner Coordinates:
Upper Left ( -909.966, 1546.901) (165d27'58.34"E, 89d59' 0.36"N)
Lower Left ( -909.966, -1264.661) ( 80d44'10.54"W, 89d59' 8.22"N)
Upper Right ( 794.918, 1546.901) (107d48' 8.56"E, 89d59' 2.20"N)
Lower Right ( 794.918, -1264.661) ( 12d50'53.17"W, 89d59'10.36"N)
Center ( -57.524, 141.120) (157d10'37.34"E, 89d59'54.94"N)

Which seems to be very close to the pole (both lower and upper at >89
deg).
This should be covering a much large portion of the Arctic.

e.g. you can use a proj4 string in the startup wizard to create a new
location.

just tested with your proj4 string,

g.proj -j
+proj=stere
+lat_0=90
+lat_ts=71
+lon_0=-39
+k=1
+x_0=0
+y_0=0
+no_defs
+a=6378137
+rf=298.257223563
+towgs84=0.000,0.000,0.000
+to_meter=1

HTH

-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html

4

Dear Moritz and Helmut,

Thank you for letting me know that the GRASS GUI (and g.proj) have the ability to work directly with proj4 strings.

-k.

···

On Fri, Oct 6, 2017 at 10:34 AM, Helmut Kudrnovsky <hellik@web.de> wrote:

Ken Mankoff wrote

Dear List,

Most of the time when I work with data in GRASS it is a provided on a
standard GIS grid (EPSG code) and I can work with it easily. I create a
location using the “-c” option when I start GRASS, or I import it into an
existing mapset with r.import.

I’m now working with data and all I know is this:

+proj=stere +lat_0=90 +lat_ts=71 +lon_0=-39 +k=1 +x_0=0 +y_0=0
+datum=WGS84
+units=m +no_defs”

In the past, when working with a few variables and this information, and
lat/lon grids in the NetCDF file, I would export the data (using Python)
to
lat,lon,data, and then r.in.ascii and project it that way. However, now
I’m
working with 14,000 high resolution daily records on the above projection.

It seems the only way to do this efficiently is to work in the projection
of the data, and r.import the few other variables to this projection. Or
perhaps cdo or gdal or some other 3rd party tool can quickly re-project
everything for me to a known EPSG code. I’ve solved this before with
vectors, ogr2ogr, and arbitrary proj4 strings.

Can anyone here suggest how to best get this data into GRASS?

I’ve tried using gdalwarp:

gdalwarp -of GTIFF -s_srs “+proj=stere +lat_0=90 +lat_ts=71 +lon_0=-39
+k=1
+x_0=0 +y_0=0 +datum=WGS84 +units=m +no_defs” -t_srs EPSG:3413
NETCDF:“${file}”:RU out.tif

But am concerned because when I then run gdalinfo on the out.tif file, it
reports strange bounds such as:

Origin = (-909.965548780931840,1546.900601999830769)
Pixel Size = (7.477558376763198,-7.477558376763198)
Corner Coordinates:
Upper Left ( -909.966, 1546.901) (165d27’58.34"E, 89d59’ 0.36"N)
Lower Left ( -909.966, -1264.661) ( 80d44’10.54"W, 89d59’ 8.22"N)
Upper Right ( 794.918, 1546.901) (107d48’ 8.56"E, 89d59’ 2.20"N)
Lower Right ( 794.918, -1264.661) ( 12d50’53.17"W, 89d59’10.36"N)
Center ( -57.524, 141.120) (157d10’37.34"E, 89d59’54.94"N)

Which seems to be very close to the pole (both lower and upper at >89
deg).
This should be covering a much large portion of the Arctic.

e.g. you can use a proj4 string in the startup wizard to create a new
location.

just tested with your proj4 string,

g.proj -j
+proj=stere
+lat_0=90
+lat_ts=71
+lon_0=-39
+k=1
+x_0=0
+y_0=0
+no_defs
+a=6378137
+rf=298.257223563
+towgs84=0.000,0.000,0.000
+to_meter=1

HTH

best regards
Helmut

Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html

grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

5

Dear Ken,

On Oct 8, 2017 12:38 PM, “Ken Mankoff” <mankoff@gmail.com> wrote:

Dear Moritz and Helmut,

Thank you for letting me know that the GRASS GUI (and g.proj) have the ability to work directly with proj4 strings.

Please let us know where to improve the documentation for this.

Thanks
Markus

6

On Sun, Oct 8, 2017 at 2:58 PM, Markus Neteler <neteler@osgeo.org> wrote:

Please let us know where to improve the documentation for this.

I'm embarrassed to say this is operator error, not software error. I don't
use the GUI so I didn't think to look there. I think the g.proj page is
fine. I didn't recall it, nor did I find it when Googling, but I might not
have been using the wrong terms.

  -k.

7

Ken Mankoff wrote

On Sun, Oct 8, 2017 at 2:58 PM, Markus Neteler &lt;

neteler@

&gt; wrote:

Please let us know where to improve the documentation for this.

I'm embarrassed to say this is operator error, not software error. I don't
use the GUI so I didn't think to look there. I think the g.proj page is
fine. I didn't recall it, nor did I find it when Googling, but I might not
have been using the wrong terms.

  -k.

_______________________________________________
grass-user mailing list

grass-user@.osgeo

https://lists.osgeo.org/mailman/listinfo/grass-user

the location creation functionality of g.proj/v.in.ogr/r.in.gdal may be a
little bit hidden in these modules.

What about to compile these functionalities in a wrapper script like e.g.
g.location?

-----
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html