#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> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev