[GRASS-dev] [GRASS GIS] #2208: r.in.gdal/v.in.ogr: reprojection at import

[GRASS GIS]

#2208: r.in.gdal/v.in.ogr: reprojection at import
----------------------------------------+-----------------------------------
 Reporter:  mlennert                    |       Owner:  grass-dev@…              
     Type:  enhancement                 |      Status:  new                      
 Priority:  normal                      |   Milestone:  7.0.0                    
Component:  Default                     |     Version:  unspecified              
 Keywords:  projection import gdal ogr  |    Platform:  Unspecified              
      Cpu:  Unspecified                 |  
----------------------------------------+-----------------------------------

Comment(by mlennert):

 Replying to [comment:6 mmetz]:
 > Replying to [comment:5 mmetz]:
 > > Replying to [comment:3 mlennert]:
 > > > Replying to [comment:2 mmetz]:
 > > > > Replying to [comment:1 martinl]:
 > > > > > reprojection option available for r.in.gdal/v.in.ogr would a
 step forward from user perspective.
 > > > >
 > > > > You would need to supply all options of [r|v].proj. Moreover,
 vector data might need preprocessing (adding vertices to lines/boundaries)
 in order to provide realistic and topologically correct results. The
 reprojection option could IMHO be best implemented in a script which calls
 r.in.gdal/v.in.ogr and then r.proj/(v.split + v.proj).
 > > > >
 > > >
 > > > I had actually thought that it might be possible to integrate
 GDAL/OGR library tools such as GDALWarpOperation and
 OGRCoordinateTransformation directly into r.in.gdal/v.in.ogr.
 > > >
 > > > But maybe you're right and we should not touch the general GRASS
 structure of import into one location + reproject into another, and rather
 use a wrapper.
 > >
 > > (Ongoing discussion on the dev-ml)
 > >
 > > My point for a wrapper script which calls r.in.gdal/v.in.ogr and then
 r.proj/v.proj is about reprojection pitfalls.
 >
 > I have created the addon script r.in.proj which imports and reprojects
 (if necessary) a GDAL datasource. It is by purpose educational, i.e. the
 user needs to specify the resampling method and by default the average
 target resolution is estimated, but the input is not reprojected. This
 forces the user to think about both the resampling method and a reasonable
 output resolution. If in doubt, read the manual...

 Great work, thanks a lot (including for the educational approach) !

 A few little bugs I've come upon:

 1) 'output' is said to be =input by default but that does not seem to be
 the case anywhere in the source code, so output is a mandatory option.

 2) There are some strings (n,s,e,w) that need to be converted to float for
 calculation in line [https://trac.osgeo.org/grass/browser/grass-
 addons/grass7/raster/r.in.proj/r.in.proj.py#L290 290].

 3) The way I would understand the 'extents' option this should import the
 entire map. So this would entail that the region is adapted to the map
 prior to reprojection. The '-n' flag of r.proj does not do this, IIUC, so
 when I try to import I get an empty map. I guess this needs a first dry
 run of r.proj with the -g flag.

 Thanks again for this !

 Moritz

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/2208#comment:8>
GRASS GIS <http://grass.osgeo.org>