* Helmut Kudrnovsky [2018-07-14 04:19:53 -0700]:
I did that before too. Did you also note that it takes "too much" >time to
create the Location using the '.tif' file?
it didn't take a long time to create the location.
For completion, using the same sample I used first in this thread:
2018-07-16 18:53 GMT+02:00 Erin Hanan :
Hi Erin,
let me forward your email to the list, since this may be interesting to others.
> Yes, this helps a lot; thank you! I've been reading through your paper and
> see that you mentioned one possible solution would be to remove slope units
> smaller
Thank you
for the information about trac, I didn't know this software, but it could be
useful!
I tried redoing the calculations without rounding. The results are closer to
the results obtained with r.volume (only tens of meters of difference, instead
of thousands), but they are not the exact
On Tue, 17 Jul 2018, Micha Silver wrote:
A single contour line could possibly begin at one side of the raster, and
end at the other side. So, without knowing any better, I would guess that
the whole raster needs to be kept in memory.
Micha,
This makes sense.
This suggests that
On Mon, 16 Jul 2018, Rich Shepard wrote:
This suggests that the solution is to create a mask and generate the
contours only within that area.
In the monitor I displayed the DEM and a couple of reference vectors, then
zoomed to an area within which I want to create a vector area to use as a
On 07/17/2018 12:09 AM, Rich Shepard
wrote:
On
Mon, 16 Jul 2018, Micha Silver wrote:
Current region rows: 47371, cols:
83934
That means that each raster will have about 4 billion
On Mon, 16 Jul 2018, Micha Silver wrote:
Current region rows: 47371, cols: 83934
That means that each raster will have about 4 billion cells. A raster with
integer values takes 32 bits per pixel, (double precision about the same,
float about 1/2 of that), so if the whole raster needs to be
On 07/16/2018 09:53 PM, Rich Shepard
wrote:
'less /proc/meminfo' shows:
MemTotal: 3874108 kB
MemFree: 2977416 kB
MemAvailable: 2972780 kB
top tells me that firefox is
On Mon, 16 Jul 2018, Markus Neteler wrote:
Sounds like a to-be-paid job...
Markus,
As I have no budget for this I'll continue to press the [Enter] key and do
what needs doing.
Regards,
Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
On Mon, 16 Jul 2018, Nikos Alexandris wrote:
I also think there might be something special to these images. From
another example file, LDQ-42124C2:
...
Is it "ok" to have identical stats for all layers?
Nikos,
Beats me. I've not before seen these LiDAR digital quads.
And, while
On Mon, 16 Jul 2018, Markus Metz wrote:
The proj4 string can provide all the information needed, but sometimes
some additional information is only contained in the WKT version of the
SRS. Please use the datasource directly to create a new location.
Markus,
Okay. That's what I'll do.
On Mon, 16 Jul 2018, Markus Metz wrote:
grass74 -c myraster.tif $HOME/grassdata/mylocation Creates new GRASS
location based on georeferenced GeoTIFF file
Interesting that I missed this one although I had looked at that list of
startup options many times.
The options I tried looked to do
On Mon, Jul 16, 2018 at 11:02 AM, Moritz Lennert
wrote:
> On 15/07/18 13:52, marion-bru...@sfr.fr wrote:
>>
>> Hi,
>>
>> Thank you for the clarification on the clumps, it makes more sense for me
>> now.
>>
>> However you said :
>>
>> "Ideally, the clump option of r.volume should be optional. You
On Mon, Jul 16, 2018 at 9:51 PM, Rich Shepard
wrote:
>
> On Mon, 16 Jul 2018, Daniel Victoria wrote:
>
>> The manual [1] gives the following examples. Did you try that?
>>
>> *grass74 -c EPSG:5514:3 $HOME/grassdata/mylocation* Creates new GRASS
>
>
> Daniel,
>
> I've used the '-c EPSG:'
On Mon, Jul 16, 2018 at 5:10 PM, Rich Shepard wrote:
> My desktop runs Slackware-14.2 with Xfce4-4.12. The display appearance
> (particularly window frames and menus) is MurineGPerfection. When I start a
> grass monitor I get the following warning:
>
> GRASS 7.5.svn (dlq):~/data/grassdata >
* Frank David [2018-07-14 12:13:26 +0200]:
Hi Nikos,
You can find below the full interface script. The script is not yet
finished. It may be helps you to understand the problem ?!
I don't really understand how works the parameter guidependency and
with which key I must connect it. I did not
* Rich Shepard [2018-07-16 08:04:59 -0700]:
On Sat, 14 Jul 2018, Nikos Alexandris wrote:
gdalinfo int_43120C4404.tif -proj4 -nomd
Nilos/Helmut:
For some reason I looked at the .xml file rather than running gdalinfo on
the 100th/quad .tif file. Creating a new location with that proj.4
Rich,
I copied 3 examples from the man page. The last one was:
*grass74 -c myraster.tif $HOME/grassdata/mylocation*
That's probably what you are looking for.
On Mon, Jul 16, 2018 at 4:52 PM Rich Shepard
wrote:
> On Mon, 16 Jul 2018, Daniel Victoria wrote:
>
> > The manual [1] gives the
On Mon, 16 Jul 2018, Daniel Victoria wrote:
The manual [1] gives the following examples. Did you try that?
*grass74 -c EPSG:5514:3 $HOME/grassdata/mylocation* Creates new GRASS
Daniel,
I've used the '-c EPSG:' option before. The issue with the DLQs is
what EPSG code to use. Markus M
On Mon, Jul 16, 2018 at 9:14 PM, Daniel Victoria
wrote:
>
> Rich,
>
> The manual [1] gives the following examples. Did you try that?
>
> grass74 -c EPSG:5514:3 $HOME/grassdata/mylocation Creates new GRASS
location with EPSG code 5514 (S-JTSK / Krovak East North - SJTSK) with
datum transformation
Rich,
The manual [1] gives the following examples. Did you try that?
*grass74 -c EPSG:5514:3 $HOME/grassdata/mylocation* Creates new GRASS
location with EPSG code 5514 (S-JTSK / Krovak East North - SJTSK) with
datum transformation parameters used in Czech Republic in the specified
GISDBASE
'less /proc/meminfo' shows:
MemTotal:3874108 kB
MemFree: 2977416 kB
MemAvailable:2972780 kB
top tells me that firefox is using ~14% of that. Nothing else is using
more than ~1.2%
In ~/.bash_profile I 'export GRASS_VECTOR_LOWMEM=1'.
When I run r.contour it cannot
On Mon, 16 Jul 2018, Markus Metz wrote:
The proj4 string can not contain all the information present in WKT. As I
mentioned before, the safest is to create a new location directly from the
data to be imported, unless there is a good reason to assume that the srs
info in the data as reported by
On Mon, Jul 16, 2018 at 6:50 PM, Rich Shepard
wrote:
>
> On Mon, 16 Jul 2018, Markus Metz wrote:
>
>> If you use the -o flag, you are potentially corrupting the data. The
>> safest is to create a new location directly from the data to be imported,
>> unless there is a good reason to assume that
On Mon, 16 Jul 2018, Rich Shepard wrote:
Location PROJ_INFO is:
name: unnamed
ellps: grs80
proj: lcc
Dataset PROJ_INFO is:
name: NAD83(HARN) / Oregon North
datum: nad83harn
ellps: grs80
proj: lcc
It appears that gdalinfo does not
On Mon, 16 Jul 2018, Markus Metz wrote:
If you use the -o flag, you are potentially corrupting the data. The
safest is to create a new location directly from the data to be imported,
unless there is a good reason to assume that the srs info in the data as
reported by gdalinfo is wrong.
On Mon, Jul 16, 2018 at 5:04 PM, Rich Shepard
wrote:
>
> On Sat, 14 Jul 2018, Nikos Alexandris wrote:
>
>> gdalinfo int_43120C4404.tif -proj4 -nomd
>
>
> Nilos/Helmut:
>
> For some reason I looked at the .xml file rather than running gdalinfo
on
> the 100th/quad .tif file. Creating a new
My desktop runs Slackware-14.2 with Xfce4-4.12. The display appearance
(particularly window frames and menus) is MurineGPerfection. When I start a
grass monitor I get the following warning:
GRASS 7.5.svn (dlq):~/data/grassdata >
(main.py:26106): Gtk-WARNING **: Unable to locate theme engine
On Sat, 14 Jul 2018, Nikos Alexandris wrote:
gdalinfo int_43120C4404.tif -proj4 -nomd
Nilos/Helmut:
For some reason I looked at the .xml file rather than running gdalinfo on
the 100th/quad .tif file. Creating a new location with that proj.4 string
allowed me to import the DLQ, but ... I
Thanks a lot Markus.
Regards
Gabriel
On Monday, July 16, 2018, Markus Metz wrote:
>
>
> On Mon, Jul 16, 2018 at 3:32 AM, Gabriel Cotlier
> wrote:
> >
> > Dear grass users,
> >
> > for exporting out of GRASS mapset raster layers in .tif file format I
> have run the following code:
> >
> > for
Dear Markus,
thanks for your advice. You are right, the best thing would be to
enhance the statistical package.
No, it is not about major streams only but the method is just
implemented in a way that it can only deal with two confluences at one
point.
All the best,
Mira
On 11/07/18
On 15/07/18 13:52, marion-bru...@sfr.fr wrote:
Hi,
Thank you for the clarification on the clumps, it makes more sense for
me now.
However you said :
"Ideally, the clump option of r.volume should be optional. You could file
an enhancement wish on trac for that."
But I don't really
On Mon, Jul 16, 2018 at 3:32 AM, Gabriel Cotlier
wrote:
>
> Dear grass users,
>
> for exporting out of GRASS mapset raster layers in .tif file format I
have run the following code:
>
> for raster in rasters:
> grass.run_command('r.out.gdal', input=raster, output=raster +
'.tiff',
33 matches
Mail list logo
