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

GRASS GIS trac at osgeo.org
Thu Jan 29 01:51:04 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:11 mlennert]:
 > Replying to [comment:9 mmetz]:
 > > Replying to [comment:8 mlennert]:
 > > > 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...
 > > >
 > > > Great work, thanks a lot (including for the educational approach) !
 > > >
 > > > A few little bugs I've come upon:
 > > >
 > > > 1) 'output' is said to be =input by default but that does not seem
 to be the case anywhere in the source code, so output is a mandatory
 option.
 > > >
 > > > 2) There are some strings (n,s,e,w) that need to be converted to
 float for calculation in line [https://trac.osgeo.org/grass/browser/grass-
 addons/grass7/raster/r.in.proj/r.in.proj.py#L290 290].
 > > >
 > > > 3) The way I would understand the 'extents' option this should
 import the entire map. So this would entail that the region is adapted to
 the map prior to reprojection. The '-n' flag of r.proj does not do this,
 IIUC, so when I try to import I get an empty map. I guess this needs a
 first dry run of r.proj with the -g flag.
 > >
 > > Thanks for testing. All fixed in r64352.
 >
 > I still get an error:
 [...]

 Fixed.

 >
 > Two more usability remarks:
 >
 > 1. You actually run r.in.gdal (line 187) and you test afterwards,
 whether a projection system was recognized or an XY-location created.
 Could this test be put after line 160 by looking at 'insrs' ? This would
 avoid going through the import which can take a while if the dataset is
 heavy.

 OK, done in r64358. First come the CRS tests, then the actual import.

 >
 > 2. When the '-i' flag is not set a short message at the end should
 inform the user about the fact that the layer has not been imported,
 especially since the module spits out a 'Raster map <XYZ> created' during
 the process (coming from the creation of the raster map in the temp loc)
 and that you have to dig into the doc to understand that you have to
 explicitly set the -i flag.

 The module now says "The input <XYZ> can be imported and reprojected with
 the -i flag".

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



More information about the grass-dev mailing list