Developers,
Is there a specific reason to keep r.region around? Is there a case
where you want to have a specific raster in a different metric than the
global? If so, why is there no v.region?
Any help is greatly appreciated.
Developers,
Is there a specific reason to keep r.region around? Is there a case
where you want to have a specific raster in a different metric than the
global? If so, why is there no v.region?
Any help is greatly appreciated.
On Tue, 07 Feb 2006 06:48:48 -0800
Brad Douglas <rez@touchofmadness.com> wrote:
Developers,
Is there a specific reason to keep r.region around? Is there a case
where you want to have a specific raster in a different metric than
the global?
I find r.region usefull to move my rasters within the location as
needed. Sometimes handy. I admit this can be achieved by other means
(r.out.tiff with tfw, adjust tfw, reimport), but it's not as
convenient. r.region is also neat for using the same MASK for different
rasters. And for quick georefferencing data which are already
rectified, but have no georefferencing (eg. lost .tfw) - again, could
craft a world file hand but r.region is quicker, for me.
If so, why is there no v.region?
v.transform looks like r.region for vectors, although it's usage is
different.
It would be cool if r.region could also move the raster by a given x,y
shift like v.transform does.
Just my thinking.
Best,
Maciek
--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.panoramainternetu.pl/
Brad Douglas wrote:
Is there a specific reason to keep r.region around? Is there a case
where you want to have a specific raster in a different metric than the
global?
r.region exists for a specific purpose: to "fix" the region
information for rasters which were imported without georeferencing
information.
If so, why is there no v.region?
Ungeoreferenced vector maps are uncommon, and there is already
v.transform.
--
Glynn Clements <glynn@gclements.plus.com>
On Tue, Feb 07, 2006 at 09:28:33PM +0000, Glynn Clements wrote:
Brad Douglas wrote:
> Is there a specific reason to keep r.region around? Is there a case
> where you want to have a specific raster in a different metric than the
> global?r.region exists for a specific purpose: to "fix" the region
information for rasters which were imported without georeferencing
information.> If so, why is there no v.region?
Ungeoreferenced vector maps are uncommon,
Most CAD drawings are not georeferenced - so in this
"niche" it's very common (unfortunately).
and there is already v.transform.
Markus
On Tue, 2006-02-07 at 22:36 +0100, Markus Neteler wrote:
On Tue, Feb 07, 2006 at 09:28:33PM +0000, Glynn Clements wrote:
> Brad Douglas wrote:
>
> > Is there a specific reason to keep r.region around? Is there a case
> > where you want to have a specific raster in a different metric than the
> > global?
>
> r.region exists for a specific purpose: to "fix" the region
> information for rasters which were imported without georeferencing
> information.
>
> > If so, why is there no v.region?
>
> Ungeoreferenced vector maps are uncommon,Most CAD drawings are not georeferenced - so in this
"niche" it's very common (unfortunately).
Unless there are no reference data/points (or in XY "projection"), I
tend to manipulate my data with GDAL before importing into GRASS. I'm
not a heavy end-user, though.
> and there is already v.transform.
Would it make sense to move this functionality to g.region to keep all
region related work in a single module? A flag '-s' could be added in
order to set the region of a particular map (be it vector or raster).
I can see strong cases made for both modular and unified functionality.
--
Brad Douglas <rez@touchofmadness.com> KB8UYR
Address: 37.49,-121.92 / WGS84 National Map Corps #TNMC-3785
GRASS GIS Developer
Brad Douglas wrote:
> > > If so, why is there no v.region?
> >
> > Ungeoreferenced vector maps are uncommon,
>
> Most CAD drawings are not georeferenced - so in this
> "niche" it's very common (unfortunately).Unless there are no reference data/points (or in XY "projection"), I
tend to manipulate my data with GDAL before importing into GRASS. I'm
not a heavy end-user, though.
The nature of vector data is such that there is always a coordinate
system (even if it isn't the right one), whereas rasters don't
normally have any coordinate system.
Similarly, changing the coordinate system of a vector map involves
modifying the actual vector data, whereas a raster's coordinate system
is stored separately.
> > and there is already v.transform.
Would it make sense to move this functionality to g.region to keep all
region related work in a single module?
No. g.region serves a different purpose, namely to manipulate the
state of the "view", whereas r.region is for modifying the actual
data.
--
Glynn Clements <glynn@gclements.plus.com>