#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 annakrat):
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...
Thanks, that's great! Eventually, this should be a core module and should
be incorporated in the import dialog. Although the gui should be simple,
we can still force users to actively decide the method and resolution.
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2208#comment:7>
GRASS GIS <http://grass.osgeo.org>
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
