Re: [GRASS-dev] [GRASS GIS] #328: Add -e switch (=extend location extents based on reprojected map) in r.proj
#328: Add -e switch (=extend location extents based on reprojected map) in r.proj --+- Reporter: nikos| Owner: grass-dev@… Type: enhancement | Status: closed Priority: minor| Milestone: 6.5.0 Component: Raster | Version: unspecified Resolution: fixed|Keywords: r.proj Platform: All | Cpu: All --+- Changes (by hamish): * status: new = closed * platform: Unspecified = All * resolution: = fixed * component: Default = Raster * cpu: Unspecified = All Comment: assumed resolved by the new `r.proj -g` functionality. -- Ticket URL: https://trac.osgeo.org/grass/ticket/328#comment:7 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #328: Add -e switch (=extend location extents based on reprojected map) in r.proj
#328: Add -e switch (=extend location extents based on reprojected map) in r.proj -+-- Reporter: nikos| Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: new Priority: minor| Milestone: 6.4.0 Component: default | Version: unspecified Keywords: |Platform: Unspecified Cpu: Unspecified | -+-- Well, the title speaks itself :-) Would it hurt to have this when reprojecting for example simple study area boundaries or similar? What speaks against it? Also, I read in the manual of r.proj (section NOTES) To avoid excessive time consumption when reprojecting a map the region and resolution of the target location should be set appropriately beforehand. but it's not clear to me why this can't be accomplished automatically. -- Ticket URL: http://trac.osgeo.org/grass/ticket/328 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev