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

GRASS GIS trac at osgeo.org
Tue Jan 27 12:16:15 PST 2015


#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: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...

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



More information about the grass-dev mailing list