Re: [GRASS-user] v.class.mlR Error

[Helmut Kudrnovsky]

>I committed a patch in r72758 which now correctly applies the replace()
>call to all tempfiles created. Please test. 

locally patched the addons script with this  v.patch
  , then the
script also works with exporting result files incl boxplot png.




-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Spyder IDE with GRASS

[Bernardo Santos]

 Hi Alex,
I have no sollutions, but I am also interested on that, if someone has hints...
Bernardo
Em sexta-feira, 1 de junho de 2018 14:35:27 BRT, Moody, Alex 
 escreveu:  
 
  
I occasionally try to use GRASS via the Spyder IDE but have not found a 
solution that works so far. I am working in Windows 7 with various versions of 
GRASS (72, 74, 75) through the OSGEO install. My attempts include
 
  
 
1.  Manually installing Spyder into the OSGEO python site-packages 
directory. When I run spyder after launching a GRASS session or from the OSGEO 
shell, nothing happens. I’ve seen the Wiki page discussing Spyder that mentions 
the commandspyder –w . 2>dev/null &, though I am not sure what this is 
attempting to do
 
2.  Making a conda environment and using subprocess per the Wiki. I imagine 
this fails because GRASS isn’t install in this environment. I wonder if there 
is a way to set the environment to use the GRASS python executable?
 
  
 
Has anyone had success using Spyder that could offer some further pointers?
 
  
 
Thanks,
 
Alex 
 ___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user  ___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.class.mlR Error

[Helmut Kudrnovsky]

>For clarity, tomorrow I should install the v.class.mlR again and test it?

yes, testing welcome. 

there is still an issue when results should be exported to several files;
this has to be fixed.



-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.class.mlR Error

[Jamille Haarloo]

Hi Moritz and Helmut,

Great proactive energy. Highly appreciated!

For clarity, tomorrow I should install the v.class.mlR again and test it?
Should I also install the needed packages first in R as stated in one of
the messages?
I will not have access to the same computer this weekend, but I can try to
test on another station.

Best,
Jamille



On Fri, Jun 1, 2018 at 2:02 PM, Helmut Kudrnovsky  wrote:

> >I committed a patch in r72758 which now correctly applies the replace()
> >call to all tempfiles created. Please test.
>
> tested now with export to files:
>
> ---
> v.class.mlR -i segments_map=lsat7_segs_stats@user1
> training_map=training@user1 train_class_column=class
> output_class_column=vote1 output_prob_column=prob1 folds=5 partitions=10
> tunelength=10 weighting_metric=accuracy
> classification_results=D:\temp\vclassr\f1.txt
> accuracy_file=D:\temp\vclassr\f2.txt model_details=D:\temp\vclassr\f3.txt
> bw_plot_file=D:\temp\vclassr\bw.png
> r_script_file=D:\temp\vclassr\myRscript.R processes=4
> Running R now. Following output is R output.
> Loading required package: caret
> Loading required package: lattice
> Loading required package: ggplot2
> Loading required package: foreach
> Loading required package: iterators
> Loading required package: parallel
> Warning message:
> In nominalTrainWorkflow(x = x, y = y, wts = weights, info = trainInfo,  :
>   There were missing values in resampled performance measures.
> Error in file(file, ifelse(append, "a", "w")) :
>   cannot open the connection
> Calls: write.csv -> eval.parent -> eval -> eval -> write.table -> file
> In addition: Warning message:
> In file(file, ifelse(append, "a", "w")) :
>   cannot open file 'D:  emp classr 1.txt': Invalid argument
> Execution halted
> ERROR: There was an error in the execution of the R script.
> Please check the R output.
> Error in atexit._run_exitfuncs:
> Traceback (most recent call last):
>   File "C:\OSGEO4~1\apps\Python27\lib\atexit.py", line 24,
> in _run_exitfuncs
> func(*targs, **kargs)
>   File "C:\Users\hkmyr\AppData\Roaming\GRASS7\addons/scripts
> /v.class.mlR.py", line 237, in cleanup
> gscript.try_remove(model_output_csvt)
> NameError: global name 'model_output_csvt' is not defined
> Error in sys.exitfunc:
> Traceback (most recent call last):
>   File "C:\OSGEO4~1\apps\Python27\lib\atexit.py", line 24,
> in _run_exitfuncs
> func(*targs, **kargs)
>   File "C:\Users\hkmyr\AppData\Roaming\GRASS7\addons/scripts
> /v.class.mlR.py", line 237, in cleanup
> gscript.try_remove(model_output_csvt)
> NameError: global name 'model_output_csvt' is not defined
> (Fri Jun 01 18:55:30 2018) Command finished (2 min 22 sec)
> --
>
> it seems the path to the first file f1.txt can't be resolved.
>
> looking into myRscript.R
>
> 
> write.csv(resultsdf, 'D:\temp\vclassr\f1.txt', row.names=FALSE,
> quote=FALSE)
> df_means <- data.frame(method=names(models.cv),accuracy=accuracy_means,
> kappa=kappa_means)
> write.csv(df_means, 'D:\temp\vclassr\f2.txt', row.names=FALSE, quote=FALSE)
> sink('D:\temp\vclassr\f3.txt')
> 
>
> it seems also here is a / needed instead of \ within the path.
>
>
>
> -
> best regards
> Helmut
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] i.maxlik yellow map

[Paul Shapley]

Hi Users,

I have created a signature file in the g.gui.iclass (supervised
classification module) and it looks correct in 'preview' and when i
inspected the 'sig' file. When the signature is applied using 'i.maxlik'
the result is a solid yellow colour as a layer. What could have gone wrong?

Thanks,

-- 
*Paul J. Shapley *MSc CGeog (GIS) FRGS
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Spyder IDE with GRASS

[Moody, Alex]

I occasionally try to use GRASS via the Spyder IDE but have not found a 
solution that works so far. I am working in Windows 7 with various versions of 
GRASS (72, 74, 75) through the OSGEO install. My attempts include


1.   Manually installing Spyder into the OSGEO python site-packages 
directory. When I run spyder after launching a GRASS session or from the OSGEO 
shell, nothing happens. I've seen the Wiki page discussing Spyder that mentions 
the command spyder -w . 2>dev/null &, though I am not sure what this is 
attempting to do

2.   Making a conda environment and using subprocess per the Wiki. I 
imagine this fails because GRASS isn't install in this environment. I wonder if 
there is a way to set the environment to use the GRASS python executable?

Has anyone had success using Spyder that could offer some further pointers?

Thanks,
Alex
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.class.mlR Error

[Helmut Kudrnovsky]

>I committed a patch in r72758 which now correctly applies the replace()
>call to all tempfiles created. Please test. 

tested now with export to files:

---
v.class.mlR -i segments_map=lsat7_segs_stats@user1
training_map=training@user1 train_class_column=class
output_class_column=vote1 output_prob_column=prob1 folds=5 partitions=10
tunelength=10 weighting_metric=accuracy
classification_results=D:\temp\vclassr\f1.txt
accuracy_file=D:\temp\vclassr\f2.txt model_details=D:\temp\vclassr\f3.txt
bw_plot_file=D:\temp\vclassr\bw.png
r_script_file=D:\temp\vclassr\myRscript.R processes=4
Running R now. Following output is R output.
Loading required package: caret
Loading required package: lattice
Loading required package: ggplot2
Loading required package: foreach
Loading required package: iterators
Loading required package: parallel
Warning message:
In nominalTrainWorkflow(x = x, y = y, wts = weights, info = trainInfo,  :
  There were missing values in resampled performance measures.
Error in file(file, ifelse(append, "a", "w")) : 
  cannot open the connection
Calls: write.csv -> eval.parent -> eval -> eval -> write.table -> file
In addition: Warning message:
In file(file, ifelse(append, "a", "w")) :
  cannot open file 'D:  empclassr1.txt': Invalid argument
Execution halted
ERROR: There was an error in the execution of the R script.
Please check the R output.
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "C:\OSGEO4~1\apps\Python27\lib\atexit.py", line 24,
in _run_exitfuncs
func(*targs, **kargs)
  File "C:\Users\hkmyr\AppData\Roaming\GRASS7\addons/scripts
/v.class.mlR.py", line 237, in cleanup
gscript.try_remove(model_output_csvt)
NameError: global name 'model_output_csvt' is not defined
Error in sys.exitfunc:
Traceback (most recent call last):
  File "C:\OSGEO4~1\apps\Python27\lib\atexit.py", line 24,
in _run_exitfuncs
func(*targs, **kargs)
  File "C:\Users\hkmyr\AppData\Roaming\GRASS7\addons/scripts
/v.class.mlR.py", line 237, in cleanup
gscript.try_remove(model_output_csvt)
NameError: global name 'model_output_csvt' is not defined
(Fri Jun 01 18:55:30 2018) Command finished (2 min 22 sec)   
--

it seems the path to the first file f1.txt can't be resolved.

looking into myRscript.R


write.csv(resultsdf, 'D:\temp\vclassr\f1.txt', row.names=FALSE, quote=FALSE)
df_means <- data.frame(method=names(models.cv),accuracy=accuracy_means,
kappa=kappa_means)
write.csv(df_means, 'D:\temp\vclassr\f2.txt', row.names=FALSE, quote=FALSE)
sink('D:\temp\vclassr\f3.txt')


it seems also here is a / needed instead of \ within the path.



-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] 3D raster color coding

[Francois Chartier]

Thanks, I'll check it out.

On Fri, Jun 1, 2018, 03:05 Veronica Andreo,  wrote:

> Hello,
>
> That's probably because that palette is for integer values ranging from 0
> to 360 [0]. Try with a relative one such as viridis or bcyr.
>
> HTH,
> Vero
>
> [0] https://grass.osgeo.org/grass74/manuals/r.colors.html
>
> El jue., 31 may. 2018 a las 3:18, Francois Chartier (<
> fra.chart...@gmail.com>) escribió:
>
>> Hi,
>>
>> I have created a 3D raster from soil properties with about 70K points,
>> with a* lot of help from the mailing list i must say*.
>> from the copy of the metadata of the 3d raster (below) it would confirm
>> that the 3D raster worked and the grid is populated with data.
>> I have copied below the r3.colors and assigned  'aspectcolr' as a
>> trial.  Unfortunately in the Display window nothing shows up, whether in 2D
>> or in 3D view.  I do not know what i am doing incorrectly.
>>
>> Once I am done and able to develop the 3D raster of the soil properties,
>> I will prepare a simple step by step for developing such a raster which may
>> be useful for others.
>>
>>
>> ++
>>  | Layer:BHALL_May24v2@Toronto  Date: Sun May 27 16:43:46
>> 2018|
>>  | Mapset:   TorontoLogin of Creator: Francois
>> Charti |
>>  | Location: Toronto
>> |
>>  | DataBase: C:\Users\Francois Chartier\Documents\grassdata
>>  |
>>  | Title:BHALL_May24v2
>> |
>>  | Units:none
>>  |
>>  | Vertical unit: units
>>  |
>>  | Timestamp: none
>> |
>>
>>  
>> ||
>>  |
>> |
>>  |   Type of Map:  raster_3dNumber of Categories: 0
>>  |
>>  |   Data Type:FCELL
>> |
>>  |   Rows: 90
>>  |
>>  |   Columns:  85
>>  |
>>  |   Depths:   307
>> |
>>  |   Total Cells:  2348550
>> |
>>  |   Total size:   3180868 Bytes
>> |
>>  |   Number of tiles:  336
>> |
>>  |   Mean tile size:   9466 Bytes
>>  |
>>  |   Tile size in memory:  30420 Bytes
>> |
>>  |   Number of tiles in x, y and  z:   6, 7, 8
>> |
>>  |   Dimension of a tile in x, y, z:   15, 13, 39
>>  |
>>  |
>> |
>>  |Projection: UTM (zone 17)
>>  |
>>  |N:4870795S:4825715   Res: 500.8889
>> |
>>  |E: 651669W: 609204   Res: 499.58823529
>> |
>>  |T:352B: 45   Res: 1
>>  |
>>  |   Range of data:   min = -8.99099445 max = 33.89262009
>>  |
>>  |
>> |
>>  |   Data Source:
>>  |
>>  |
>> |
>>  |
>> |
>>  |
>> |
>>  |   Data Description:
>> |
>>  |generated by v.vol.rst
>> |
>>  |
>> |
>>  |   Comments:
>> |
>>  |v.vol.rst input="BHMat1All_May12@Toronto" wcolumn="cat"
>> tension=40. \   |
>>  |smooth=0.1 segmax=50 npmin=200 npmax=700 dmin=2 wscale=1.0
>> zscale=1.\   |
>>  |0 elevation="BHALL_May24v2"
>>  |
>>  |
>> |
>>
>>  
>> ++
>> (Wed May 30 21:11:59 2018) Command finished (0 sec)
>>
>>
>>
>>
>> 
>>
>> (Wed May 30 21:10:02 2018)
>>
>> r3.colors map=BHALL_May24v2@Toronto color=aspectcolr
>>
>> Color table for raster3d map  set to 'aspectcolr'
>> (Wed May 30 21:10:03 2018) Command finished (0 sec)
>>
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-user
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] v.class.mlR Error

[Moritz Lennert]

On 01/06/18 00:41, Helmut Kudrnovsky wrote:

But it's not about the tempfile, it's about calling Rscript and >Windows not

being able to find it, or ?

looking closer at the report and the used command, the Rscript and other
files should be written to files in some folder, right?


Rscript is an executable which allows to call R commands 
non-interactively in a scripting environment.


However, I noticed that the file with the R commands was the only one I 
hadn't done the replace("\\", "/") on, so maybe the error about not 
being able to find the file is about the command file, not Rscript.




  >Some paths to set correctly maybe ?

What I've seen today during quick tests, it may be the path can't be
resolved, it may be a similar issue with path like for the temp File.

But in my first quuck test, the Rscript was written to a folder when
specified.

I suggest to apply a patch in svn to solve the temp file issue, then further
testing is needed.


I committed a patch in r72758 which now correctly applies the replace() 
call to all tempfiles created. Please test.


If you still see an error that combines

pts/v.class.mlR.py", line 570, in main
subprocess.check_call(['Rscript', r_commands],
stderr=subprocess.STDOUT, )

and

WindowsError: [Error 2] The system cannot find the file
specified

Then maybe it is about Rscript not being in the PATH...

Jamille, could you please also test ? It should be available for Windows 
for installation with g.extension by tomorrow.


Moritz
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Supervised Classification Tool - g.gui.iclass

[Moritz Lennert]

Am 1. Juni 2018 11:26:22 MESZ schrieb Paul Shapley :
>Hi Users,
>
>I want to know if there is any good sources of information on the above
>wxlClass. I want to know roughly how large the training areas should be
>to
>prevent the module from taking several hours to process a signature.

I haven't had this experience. Check your region settings. Maybe that explains 
long run times.


>Also
>in the Training Area Display must i use a composite RGB image to
>digitise a
>training area from or will a single channel be okay?


You can use whatever suits you. Often it is advisable to display different 
bands and composites and switch between them according to need.

Moritz

>
>Many thanks,
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Supervised Classification Tool - g.gui.iclass

[Paul Shapley]

Hi Users,

I want to know if there is any good sources of information on the above
wxlClass. I want to know roughly how large the training areas should be to
prevent the module from taking several hours to process a signature. Also
in the Training Area Display must i use a composite RGB image to digitise a
training area from or will a single channel be okay?

Many thanks,

-- 
*Paul J. Shapley *MSc CGeog (GIS) FRGS
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.mapcalc

[Nikos Alexandris]

* jaindamini  [2018-06-01 01:48:41 -0700]:




I have been trying to digitize a Landsat 8 image for that in the layer
manager  I am creating a new raster map for it but it isn't allowing me
every time this error arrives.


Hi,

can you be a bit more specific in what you are trying to do?
I tested the following expression,

r.mapcalc "test = int( null() )"

and it works.

Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] GRASS GIS virtual raster data sets

[Nikos Alexandris]

* Markus Metz  [2018-06-01 08:24:20 +0200]:


On Thu, May 31, 2018 at 10:41 PM, Markus Neteler  wrote:


On Wed, May 30, 2018 at 4:21 PM, Nikos Alexandris
 wrote:
> Dears,
>
> I guess there is no GRASS GIS built-in implementation of GDAL's VRT
> concept (several related ideas listed
> https://trac.osgeo.org/grass/wiki/Grass8Planning).

I wish to see that as well (and discussed it a while ago with our dear
Markus M...


I have an idea about how to implement native GRASS VRT, but no resources to
do so...


That is great! If I may ask, is time the main requirement?


GRASS GIS would gain a lot having the possibility to virtually mosaik
raster tiles.

> Once past some compilation issues, I am about to try to build a VRT
> based on native GRASS GIS raster maps (using GDAL with support for GRASS
> GIS raster data), then link to this VRT via `r.external` from inside a
> regular Mapset.

Interesting, will that not cause loop dependencies?



I didn't think about it carefully then. Stefan's test shows that you are
right, I guess.

My naive thinking was: source images are, each, an inode. A VRT is a list of
filenames pointing to inodes. Link via r.external to the VRT which points
to the source inodes. Essentially, an indirect way to read GRASS GIS
raster maps, from inside a valid GRASS GIS session.

I guess I miss important parts of GRASS GIS' raster data model which
render the above schema to be of no use.




I thought of true internal support for that to avoid loops.

> As a side-note, an image without pre-computed statistics stored in its
> metadata, will require some time for `r.external` to work. The latter
> likely forces  this computation.
>
> Perhaps it is faster to use `gdalinfo`'s '-stats' option to do this.


It will not be faster because you would need gdalinfo -mm -stats in order
to get the actual values, not an approximation. Sometimes an approximation
of the stats based on a subsample is stored in the metadata of a raster.


>
> I wonder if there are smart ways to build, in GRASS GIS' data base,
> a larger virtual raster map out of many smaller ones, without the need
> to actually patch the latter ones in a new raster map file.

I guess that some C code needs to be touched in lib/raster/ to allow
for a VRT-style raster concept.


Yes.


Maybe we missed the current GSoC train for this idea :)>


The tricky part is to get a qualified student for this project.


(I wish I could be in this position! :-/)

Nikos


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] r.mapcalc

[jaindamini1111]

 

I have been trying to digitize a Landsat 8 image for that in the layer
manager  I am creating a new raster map for it but it isn't allowing me
every time this error arrives.





--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] GRASS GIS virtual raster data sets

[Nikos Alexandris]

Essentially, I have "exactly", I think, the same workflow in mind. So, I am in a
path where you have been already. Thank you for sharing this Stefan.

- Computing LST images from Landsat 8.

- Instead of writing GRASS GIS native raster maps, I will switch to
 GeoTIFFs via r.external.out

- After having built time series for hundreds of WRS2 Paths and Rows
 combinations, I end up with some aggregated products.

- I tiled Europe in 10k^2 squares (in ETRS89) to have less tiles to deal
 with. Size of images per tile is acceptable (compressed via DEFLATE, ranging
 between less than 100 and up to 400MB).

- I "need" to avoid to patch these tiles in single European-wide raster
 maps. Thus the need, and the idea, for a "VRT".

So, I guess the idea won't work. I will do the attempt to "learn" this
by experience.

Thank you, Nikos

* Stefan Blumentrath  [2018-06-01 07:09:08 +]:


Hi,

Some experience with GDAL VRT and GRASS:

Be aware of: https://trac.osgeo.org/grass/ticket/2837

Also note also that esp. for integer rasters, compression of one big raster map 
can be much better than with lots of smaller tiles [1]. So I guess cases where 
patching by means of a virtual raster is most beneficial is in intermediate 
steps of an analysis chain…

Cheers
Stefan

1: https://www.mail-archive.com/grass-user@lists.osgeo.org/msg33125.html


From: grass-user  On Behalf Of Markus Metz
Sent: fredag 1. juni 2018 08:24
To: Markus Neteler 
Cc: GRASS user list 
Subject: Re: [GRASS-user] GRASS GIS virtual raster data sets



On Thu, May 31, 2018 at 10:41 PM, Markus Neteler 
mailto:nete...@osgeo.org>> wrote:


On Wed, May 30, 2018 at 4:21 PM, Nikos Alexandris
mailto:n...@nikosalexandris.net>> wrote:
> Dears,
>
> I guess there is no GRASS GIS built-in implementation of GDAL's VRT
> concept (several related ideas listed
> https://trac.osgeo.org/grass/wiki/Grass8Planning).

I wish to see that as well (and discussed it a while ago with our dear
Markus M...


I have an idea about how to implement native GRASS VRT, but no resources to do 
so...


GRASS GIS would gain a lot having the possibility to virtually mosaik
raster tiles.

> Once past some compilation issues, I am about to try to build a VRT
> based on native GRASS GIS raster maps (using GDAL with support for GRASS
> GIS raster data), then link to this VRT via `r.external` from inside a
> regular Mapset.

Interesting, will that not cause loop dependencies?

I thought of true internal support for that to avoid loops.

> As a side-note, an image without pre-computed statistics stored in its
> metadata, will require some time for `r.external` to work. The latter
> likely forces  this computation.
>
> Perhaps it is faster to use `gdalinfo`'s '-stats' option to do this.


It will not be faster because you would need gdalinfo -mm -stats in order to 
get the actual values, not an approximation. Sometimes an approximation of the 
stats based on a subsample is stored in the metadata of a raster.


>
> I wonder if there are smart ways to build, in GRASS GIS' data base,
> a larger virtual raster map out of many smaller ones, without the need
> to actually patch the latter ones in a new raster map file.

I guess that some C code needs to be touched in lib/raster/ to allow
for a VRT-style raster concept.


Yes.


Maybe we missed the current GSoC train for this idea :)>


The tricky part is to get a qualified student for this project.

Markus M


markusN
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user



___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user



--
Nikos Alexandris | Remote Sensing & Geomatics
GPG Key Fingerprint 6F9D4506F3CA28380974D31A9053534B693C4FB3 


signature.asc
Description: PGP signature
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] 3D raster color coding

[Veronica Andreo]

Hello,

That's probably because that palette is for integer values ranging from 0
to 360 [0]. Try with a relative one such as viridis or bcyr.

HTH,
Vero

[0] https://grass.osgeo.org/grass74/manuals/r.colors.html

El jue., 31 may. 2018 a las 3:18, Francois Chartier ()
escribió:

> Hi,
>
> I have created a 3D raster from soil properties with about 70K points,
> with a* lot of help from the mailing list i must say*.
> from the copy of the metadata of the 3d raster (below) it would confirm
> that the 3D raster worked and the grid is populated with data.
> I have copied below the r3.colors and assigned  'aspectcolr' as a trial.
> Unfortunately in the Display window nothing shows up, whether in 2D or in
> 3D view.  I do not know what i am doing incorrectly.
>
> Once I am done and able to develop the 3D raster of the soil properties, I
> will prepare a simple step by step for developing such a raster which may
> be useful for others.
>
>
> ++
>  | Layer:BHALL_May24v2@Toronto  Date: Sun May 27 16:43:46
> 2018|
>  | Mapset:   TorontoLogin of Creator: Francois
> Charti |
>  | Location: Toronto
> |
>  | DataBase: C:\Users\Francois Chartier\Documents\grassdata
>|
>  | Title:BHALL_May24v2
> |
>  | Units:none
>|
>  | Vertical unit: units
>|
>  | Timestamp: none
> |
>
>  
> ||
>  |
> |
>  |   Type of Map:  raster_3dNumber of Categories: 0
>|
>  |   Data Type:FCELL
> |
>  |   Rows: 90
>|
>  |   Columns:  85
>|
>  |   Depths:   307
> |
>  |   Total Cells:  2348550
> |
>  |   Total size:   3180868 Bytes
> |
>  |   Number of tiles:  336
> |
>  |   Mean tile size:   9466 Bytes
>|
>  |   Tile size in memory:  30420 Bytes
> |
>  |   Number of tiles in x, y and  z:   6, 7, 8
> |
>  |   Dimension of a tile in x, y, z:   15, 13, 39
>|
>  |
> |
>  |Projection: UTM (zone 17)
>|
>  |N:4870795S:4825715   Res: 500.8889
> |
>  |E: 651669W: 609204   Res: 499.58823529
> |
>  |T:352B: 45   Res: 1
>|
>  |   Range of data:   min = -8.99099445 max = 33.89262009
>|
>  |
> |
>  |   Data Source:
>|
>  |
> |
>  |
> |
>  |
> |
>  |   Data Description:
> |
>  |generated by v.vol.rst
> |
>  |
> |
>  |   Comments:
> |
>  |v.vol.rst input="BHMat1All_May12@Toronto" wcolumn="cat" tension=40.
> \   |
>  |smooth=0.1 segmax=50 npmin=200 npmax=700 dmin=2 wscale=1.0
> zscale=1.\   |
>  |0 elevation="BHALL_May24v2"
>|
>  |
> |
>
>  
> ++
> (Wed May 30 21:11:59 2018) Command finished (0 sec)
>
>
>
>
> 
>
> (Wed May 30 21:10:02 2018)
>
> r3.colors map=BHALL_May24v2@Toronto color=aspectcolr
>
> Color table for raster3d map  set to 'aspectcolr'
> (Wed May 30 21:10:03 2018) Command finished (0 sec)
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] GRASS GIS virtual raster data sets

[Markus Metz]

On Thu, May 31, 2018 at 10:41 PM, Markus Neteler  wrote:
>
> On Wed, May 30, 2018 at 4:21 PM, Nikos Alexandris
>  wrote:
> > Dears,
> >
> > I guess there is no GRASS GIS built-in implementation of GDAL's VRT
> > concept (several related ideas listed
> > https://trac.osgeo.org/grass/wiki/Grass8Planning).
>
> I wish to see that as well (and discussed it a while ago with our dear
> Markus M...

I have an idea about how to implement native GRASS VRT, but no resources to
do so...
>
> GRASS GIS would gain a lot having the possibility to virtually mosaik
> raster tiles.
>
> > Once past some compilation issues, I am about to try to build a VRT
> > based on native GRASS GIS raster maps (using GDAL with support for GRASS
> > GIS raster data), then link to this VRT via `r.external` from inside a
> > regular Mapset.
>
> Interesting, will that not cause loop dependencies?
>
> I thought of true internal support for that to avoid loops.
>
> > As a side-note, an image without pre-computed statistics stored in its
> > metadata, will require some time for `r.external` to work. The latter
> > likely forces  this computation.
> >
> > Perhaps it is faster to use `gdalinfo`'s '-stats' option to do this.

It will not be faster because you would need gdalinfo -mm -stats in order
to get the actual values, not an approximation. Sometimes an approximation
of the stats based on a subsample is stored in the metadata of a raster.

> >
> > I wonder if there are smart ways to build, in GRASS GIS' data base,
> > a larger virtual raster map out of many smaller ones, without the need
> > to actually patch the latter ones in a new raster map file.
>
> I guess that some C code needs to be touched in lib/raster/ to allow
> for a VRT-style raster concept.

Yes.

> Maybe we missed the current GSoC train for this idea :)>

The tricky part is to get a qualified student for this project.

Markus M

> markusN
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user