[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:10 mmetz]:
 > 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.
 >
 > Now there is also v.in.proj which imports and reprojects (if necessary)
 a OGR datasource. It is still a bit noisy (lots of messages if direct
 import fails).

 Great. Seems to work without problems in simple test.

 One question: why did you decide to not use the g.proj -j comparison test
 before direct import here ? The current error message from the failed
 direct import is a bit disconcerting.

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