I have a source 28M DEM in a directory with geographic coordinates in
Lat/Long. When I re-project that to another location and dataset with
Lambert Conformal Conic projection the disk space consumed bloats to 106G.
That's more than a 20x increase. Why?
In the destination location/directory there's no .tmp/ subdirectory with a
huge file.
Rich
On Wed, 14 Mar 2012, Rich Shepard wrote:
In the destination location/directory there's no .tmp/ subdirectory with a
huge file.
Actually, there are two such files.
Am I correct in assuming that once the re-projection process is completed
I can delete those two files (called <pid>-1 and <pid>-2) without
consequences?
Related question: if they're no longer needed, why doesn't grass remove
them from the hard drive?
Rich
Hi.
On Wed, Mar 14, 2012 at 11:33 AM, Rich Shepard <rshepard@appl-ecosys.com> wrote:
On Wed, 14 Mar 2012, Rich Shepard wrote:
Related question: if they’re no longer needed, why doesn’t grass remove
them from the hard drive?
If you exit GRASS does it purge them?
Mark
On Wed, 14 Mar 2012, Mark Seibel wrote:
If you exit GRASS does it purge them?
Mark,
Not on my laptop on which I ran the r.proj module. At the bash prompt I
used rm to remove them.
Rich
Some things come to mind:
1) The resolution has changed
2) the number of bits per pixel has changed
3) the region of the reprojected file is bigger than the original file
so you have lots of nulls.
Daniel
On Wed, Mar 14, 2012 at 12:28 PM, Rich Shepard <rshepard@appl-ecosys.com> wrote:
I have a source 28M DEM in a directory with geographic coordinates in
Lat/Long. When I re-project that to another location and dataset with
Lambert Conformal Conic projection the disk space consumed bloats to 106G.
That's more than a 20x increase. Why?In the destination location/directory there's no .tmp/ subdirectory with a
huge file.Rich
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Rich Shepard wrote:
Related question: if they're no longer needed, why doesn't grass remove
them from the hard drive?
Which OS?
r.proj calls remove() on the temporary file immediately after opening
it. On Unix, that removes the directory entry, and will cause the file
itself to be deleted as soon as r.proj terminates. On Windows, the
remove() call will fail (you can't delete an open file on Windows),
and the file will be left behind.
--
Glynn Clements <glynn@gclements.plus.com>
On Thu, 15 Mar 2012, Glynn Clements wrote:
Which OS?
Linux.
r.proj calls remove() on the temporary file immediately after opening it.
On Unix, that removes the directory entry, and will cause the file itself
to be deleted as soon as r.proj terminates. On Windows, the remove() call
will fail (you can't delete an open file on Windows), and the file will be
left behind.
For some reason, then, it's not working here. Slackware-13.1/x486 and
-13.37/x86_64.
On the latter host I found two files in ../.tmp/<hostname>/: <pid>.1 and
<pid>.2. The former was almost 100G in size and the latter was >10G. The
source raster file is 45M in size.
Thanks, Glynn,
Rich
On Thu, Mar 15, 2012 at 3:50 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:
r.proj calls remove() on the temporary file immediately after opening
it. On Unix, that removes the directory entry, and will cause the file
itself to be deleted as soon as r.proj terminates. On Windows, the
remove() call will fail (you can't delete an open file on Windows),
and the file will be left behind.
Could|Will it be cleaned up when the Windows user leaves and reenters
the session? Or could a list of dead tmp files be generated to handle
this issue and savely remove them at next start up?
Markus