[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 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.

 For example, it is mathematically not possible to reproject a global map
 in latlong to UTM or most other true projection systems. You should only
 reproject a subregion (that part that corresponds to the current region in
 the target projection) to the target projection. That also for raster data
 that the current region first needs to be adjusted according to the
 desired resolution. Not to mention the resampling method to be used for
 reprojection. The default is nearest neighbor, but nn usually implies
 information loss. Surfaces are best reprojected with bilinear or bicubic,
 imagery best with e.g. lanczos. This can not be determined automatically.
 For high-precision reprojection, the target resolution would depend not
 only on the source resolution, but also on the resampling method (think
 e.g. MODIS quality assessment + pixel shift after reprojection).

 For vector data, lines and boundaries need to be densified first (adding
 additional vertices). I have implemented this for v.proj in G7. Still, the
 reprojection should be limited to the target current region (currently
 possible with v.in.region + v.proj + v.overlay + v.proj) because it is
 mathematically not possible to reproject e.g. a global map in latlong to
 UTM or most other true projection systems.

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