Re: [GRASS-user] Classified point cloud from UAS
Hey Anna Yes, I thought of that but the coarse models I would have access would be the STRM which has 10m vertical accuracy, plus that is Height above ellipsoid I think, so I would have to convert it using the geoid ondulation meaning I would have another error (or am I mixing topics here?). So besides all the difference between data I would have increasing error sources in everything. Making a DTM based on random points on locations where I know the ground is would lose the ability to detect height variations within high canopy covers but could be an approach since ground heights are otherwise unavailable? All the best! Nuno On 15 May 2015 at 20:45, Anna Petrášová kratocha...@gmail.com wrote: On Fri, May 15, 2015 at 10:35 AM, Nuno Sá nunocesard...@gmail.com wrote: I've got the same questions :) How will you get the DTM if you don't have info on the ground ? I did some search for publications but couldn't find if there were any methods just by using UAV data, do you have any recommendations? Ciao! Nuno On 15 May 2015 at 14:40, Adam Laža ad.laz...@gmail.com wrote: Hi all, I've got some data from UAS (SenseFly eBee) exported as point cloud. I'd like to ask if there's any way how to classify the data in GRASS. As an input I have a point cloud exported in .las or .txt file. As an output I need another .las file containing only terrain (I need to filter out objects, buildings and vegetation) for next step which is generating DTM. I've already tried some modules, import(r.in.lidar, v.in.lidar) works well. Then I focused on v.lidar.* modules (v.lidar.edgedetection, v.lidar.growing, v.lidar.correction) but already the first step of recognizing and extracting object didn't work for me. I suppose it's due to the v.lidar.* modules need data only from LiDAR, but I have data from phtogrammetry (eBee carries Canon RGB camera). Any idea how to classify my data? Hi, I haven't tried v.lidar.* modules, because I typically work with already classified lidar, what exactly was the problem? Generally, you it would be difficult to get ground from UAV data because the point cloud represents only surface (unlike lidar where you get multiple returns). You could compare the point cloud with some coarser digital terrain model and high differences would mean that there is some vegetation or buildings. Anna Thank in advance, Adam Data sample at google drive: las: https://drive.google.com/file/d/0B3qa8r8b0sq0TTdnSVNHdE1UQ2M/view?usp=sharing txt: https://drive.google.com/file/d/0B3qa8r8b0sq0NVFRMmNEZHNkbDA/view?usp=sharing ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Nuno César de Sá +351 91 961 90 37 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Nuno César de Sá +351 91 961 90 37 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Classified point cloud from UAS
I've got the same questions :) How will you get the DTM if you don't have info on the ground ? I did some search for publications but couldn't find if there were any methods just by using UAV data, do you have any recommendations? Ciao! Nuno On 15 May 2015 at 14:40, Adam Laža ad.laz...@gmail.com wrote: Hi all, I've got some data from UAS (SenseFly eBee) exported as point cloud. I'd like to ask if there's any way how to classify the data in GRASS. As an input I have a point cloud exported in .las or .txt file. As an output I need another .las file containing only terrain (I need to filter out objects, buildings and vegetation) for next step which is generating DTM. I've already tried some modules, import(r.in.lidar, v.in.lidar) works well. Then I focused on v.lidar.* modules (v.lidar.edgedetection, v.lidar.growing, v.lidar.correction) but already the first step of recognizing and extracting object didn't work for me. I suppose it's due to the v.lidar.* modules need data only from LiDAR, but I have data from phtogrammetry (eBee carries Canon RGB camera). Any idea how to classify my data? Thank in advance, Adam Data sample at google drive: las: https://drive.google.com/file/d/0B3qa8r8b0sq0TTdnSVNHdE1UQ2M/view?usp=sharing txt: https://drive.google.com/file/d/0B3qa8r8b0sq0NVFRMmNEZHNkbDA/view?usp=sharing ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Nuno César de Sá +351 91 961 90 37 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.regression.multi for logistic regression - it is possible?
Hey Roberto! Never done it in Grass but its a typical operation. For me it seems a bit confusing with for me since you are not showing me a glm fitting but instead just using the occurrence map in the logistic link function. What you need to do is to fit a GLM to the binary data you have, something you can do in R for example check here: http://www.statmethods.net/advstats/glm.html Then you will build your output in grass using the r.mapcalc: F(x) = 1 / ( 1+ e^(-GLM) (That will be your probability map). But, you can actually do everything using R only, no need to come into grass but you can if you want. Good luck! Ciao! On 5 September 2014 10:46, Roberto Marzocchi roberto.marzoc...@gmail.com wrote: Dear all, I have dichotomous data (occurrence 1 and non-occurence 0) and I want to use the logistic regression method in order to obtain susceptibility map of landslide occurrence. I try to use r.regression.multi, but I am not sure to correctly define the mapy variable.. I try to use r.mapcalc *r.mapcalc expression=logit_occurrence=log(occurrence_map+0.1)-log(1-occurrence_map+0.1)* obtaining a map that go from -11.5 (not occurrence) to +11.5 (occurrence) when I try to use r.regression.multi I obtain a lot of null values in residuals and estimates map. i do not understand why.. Thanks in advanced for the attention Roberto ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Nuno César de Sá +351 91 961 90 37 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] raster exchange between GRASS and R with nodata
Hello! Did you try this one? *r.out.gdal etc nodata*=*'NA'* On 4 September 2014 14:27, Johannes Radinger johannesradin...@gmail.com wrote: Hi all, of course it is possible to load the raster maps directly via spgrass6. However, we use this work flow also to exchange some of the maps between different users (e.g. via email) and to permanently store single files (geotiffs that contain the proj information within the file). So, I agree that using spgrass6 would be much more efficient, but I'll stick to exporting to geotiffs and so I need to solve the issues with NA's. /Johannes On Thu, Sep 4, 2014 at 2:31 PM, Thomas Adams tea...@gmail.com wrote: Johannes, If you want to read your file into R, there is no need to export your map from GRASS to do this. Simply install and use the R contributed package 'spgrass6' (spgrass6 has R dependencies that need to be installed first); it works wonderfully: Within GRASS, at the GRASS terminal prompt... library(spgrass6) Loading required package: sp Loading required package: XML GRASS GIS interface loaded with GRASS version: GRASS 7.0.0beta3 (2014) and location: ohrfc_mpe dat-readRAST6(xmrg0101200306z) image(dat) This is far more efficient. Tom On Thu, Sep 4, 2014 at 5:32 AM, Johannes Radinger johannesradin...@gmail.com wrote: Hi, I want to export a raster map (FCELL) from GRASS70 to the geotiff format using r.out.gdal and to import it later on in R. The map contains many no data values. Here some details about the raster: Type of Map: raster Number of Categories: 0 Data Type:FCELL Rows: 750 Columns: 750 Total Cells: 562500 total null and non-null cells: 15105636 total null cells: 15105047 So when I export the map, r.out.gdal reports: Input raster map contains cells with NULL-value (no-data). The value -nan will be used to represent no-data values in the input map. You can specify a nodata value with the nodata option. When I subsequently try to import the geotiff into R (using the package 'Raster') the nodata values are not recognised as NA's: a - raster(*.tif) summary(a) Min. 0.5294496 1st Qu. 0.7171210 Median 0.7871540 3rd Qu. 1.1581826 Max. 1.5494517 NA's 0.000 So I am wondering if I need to set any specific parameter during the export (r.out.gdal) or import (raster()). As I am not only exporting FCELL (Float32) raster but also multiple (N=500) other rasters to R I would be interested in a solution also for DCELL (Float64). Of course I can export all of as Float64 as the file size should not be a problem. Any suggestions or experiences of handling NA's during raster exchange between GRASS and R? /Johannes ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Nuno César de Sá +351 91 961 90 37 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] raster exchange between GRASS and R with nodata
Ok, didn't check that before since I didn't have the same problem before. Try exporting with a crazy value as NA such as in a 16bit unsigned r.out.gdal etc nodata=65535 Then on R use the mask function such as: mask(x, mask, filename=, inverse=FALSE, maskvalue=65535, updatevalue='NA', ...) might work but its very, you know, hurtful to see :P but I'm like you, I prefer .tif. On 4 September 2014 14:47, Johannes Radinger johannesradin...@gmail.com wrote: On Thu, Sep 4, 2014 at 3:38 PM, Nuno Sá nunocesard...@gmail.com wrote: Hello! Did you try this one? *r.out.gdal etc nodata*=*'NA'* As mentioned in the manual of r.out.gdal, the no data parameter takes only float values and no strings like 'NA'. Without stating as specific value in GRASS, this nodata-value is automatically set to e.g. 65535 for DCELL rasters if I remember correctly and to 255 for BYTE rasters. However, this seems not to be recognized when imported into R with the package 'raster'. /Johannes On 4 September 2014 14:27, Johannes Radinger johannesradin...@gmail.com wrote: Hi all, of course it is possible to load the raster maps directly via spgrass6. However, we use this work flow also to exchange some of the maps between different users (e.g. via email) and to permanently store single files (geotiffs that contain the proj information within the file). So, I agree that using spgrass6 would be much more efficient, but I'll stick to exporting to geotiffs and so I need to solve the issues with NA's. /Johannes On Thu, Sep 4, 2014 at 2:31 PM, Thomas Adams tea...@gmail.com wrote: Johannes, If you want to read your file into R, there is no need to export your map from GRASS to do this. Simply install and use the R contributed package 'spgrass6' (spgrass6 has R dependencies that need to be installed first); it works wonderfully: Within GRASS, at the GRASS terminal prompt... library(spgrass6) Loading required package: sp Loading required package: XML GRASS GIS interface loaded with GRASS version: GRASS 7.0.0beta3 (2014) and location: ohrfc_mpe dat-readRAST6(xmrg0101200306z) image(dat) This is far more efficient. Tom On Thu, Sep 4, 2014 at 5:32 AM, Johannes Radinger johannesradin...@gmail.com wrote: Hi, I want to export a raster map (FCELL) from GRASS70 to the geotiff format using r.out.gdal and to import it later on in R. The map contains many no data values. Here some details about the raster: Type of Map: raster Number of Categories: 0 Data Type:FCELL Rows: 750 Columns: 750 Total Cells: 562500 total null and non-null cells: 15105636 total null cells: 15105047 So when I export the map, r.out.gdal reports: Input raster map contains cells with NULL-value (no-data). The value -nan will be used to represent no-data values in the input map. You can specify a nodata value with the nodata option. When I subsequently try to import the geotiff into R (using the package 'Raster') the nodata values are not recognised as NA's: a - raster(*.tif) summary(a) Min. 0.5294496 1st Qu. 0.7171210 Median 0.7871540 3rd Qu. 1.1581826 Max. 1.5494517 NA's 0.000 So I am wondering if I need to set any specific parameter during the export (r.out.gdal) or import (raster()). As I am not only exporting FCELL (Float32) raster but also multiple (N=500) other rasters to R I would be interested in a solution also for DCELL (Float64). Of course I can export all of as Float64 as the file size should not be a problem. Any suggestions or experiences of handling NA's during raster exchange between GRASS and R? /Johannes ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Nuno César de Sá +351 91 961 90 37 -- Nuno César de Sá +351 91 961 90 37 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.in.gdal for importing categorical ArcGIS binary rasters
Out of the box:
Import it in R and save it as a Tiff - use GRASS to open this tiff. Maybe
it works ;P
On 13 February 2014 10:50, Benjamin Ducke bendu...@fastmail.fm wrote:
Ouch. I am beginning to suspect that the ESRI field
concept for raster layers does not translate well
to GRASS/GDAL. Sorry for not being able to help.
Maybe someone else on this list has experience with
this type of data structure?
At least now we know that r.in.gdal starts counting
bands with 1!
Ben
On 13/02/14 11:14, manuel.martin wrote:
I had already tried this (with 2) ;-). No luck either. Reading your
email I tried with 0 (maybe would gdal detect only two bands over
three). It comes out that only band=1 works
GRASS 7.0.svn (lambert93):~ r.in.gdal --o
input=/home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/clc/clc06_250m
band=0 output=testclc
WARNING: Raster map testclc already exists and will be overwritten
WARNING: Datum Not_specified_based_on_GRS_1980_ellipsoid not recognised
by GRASS and no parameters found
Projection of input dataset and current location appear to match
ERROR 5:
/home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/clc/clc06_250m:
GDALDataset::GetRasterBand(0) - Illegal band #
ERROR: Selected band (0) does not exist
On 02/13/2014 10:59 AM, Benjamin Ducke wrote:
Hmm, the manual page does not say so explicitely,
but maybe band numbering starts with 0?
In that case your band 3 would have index number 2.
Ben
On 13/02/14 10:48, manuel.martin wrote:
Hi Ben,
Thanks for the reply. I tried with the band option but it looks like
gdal does not detect the multiple fields as multiple bands :
GRASS 7.0.svn (lambert93):~ r.in.gdal --o \
input=/home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/clc/clc06_250m
\
band=3 output=testclc
WARNING: Raster map testclc already exists and will be overwritten
WARNING: Datum Not_specified_based_on_GRS_1980_ellipsoid not
recognised
by GRASS and no parameters found
Projection of input dataset and current location appear to match
ERROR 5:
/home/manuel/Desktop/sftp/Projets/Projets/Zones-humides/base_sig/dsm_data/clc/clc06_250m:
GDALDataset::GetRasterBand(3) - Illegal band #
ERROR: Selected band (3) does not exist
Cheers, Manuel
On 02/12/2014 08:25 PM, Benjamin Ducke wrote:
Hi Manuel,
GRASS does not support multi-band rasters, so you'll have
to import each band as a separate raster map.
r.in.gdal has the band= option to specify a band number
to import.
Best,
Ben
On 12/02/14 17:05, manuel.martin wrote:
Hi all,
I tried to import an ArcGIS binary raster (corine land cover for the
French territory) with three fields on each pixels (VALUE, COUNT and
CODE_06) using the *r.in.gdal* command. The import works just fine,
except that in the resulting raster, in GRASS, I only get one field,
which seems to be the VALUE field (and not the CODE_06 field, which
I am
interested in, and which is a categorical field, although coded with
integers).
Is there a way to produce a resulting raster with all the fields of
the
initial ArcGIS layer, or alternatively to choose one unique field?
Also,
is there a limitation on categorical fields. For instance, what if
instead of integer corine land cover codes I have literal labels,
i.e.
levels of my categorical field coded with strings?
Cheers, Manuel
--
00--
INRA - InfoSol
Centre de recherche d'Orléans
2163 Avenue de la Pomme de Pin
CS 40001 ARDON
45075 ORLEANS Cedex 2
tel : (33) (0)2 38 41 48 21
fax : (33) (0)2 38 41 78 69
http://www.gissol.fr
00--
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Nuno César de Sá
+351 91 961 90 37
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Python error with GRASS 7 on Windows 8
System Info
GRASS version: 6.4.4svn
GRASS SVN Revision: 58595
GIS Library Revision: 50937 (2012-02-25)
GDAL/OGR: GDAL 1.10.1, released 2013/08/26
PROJ4: Rel. 4.8.0, 6 March 2012
Python: 2.7.4
wxPython: 2.8.12.1
Platform: Windows-8-6.2.9200
(Wed Jan 08 13:05:25 2014)
g.extension extension=i.landsat.dehaze operation=add
which: svn: unknown command
ERROR: svn client required. Please install Subversion first.
(Wed Jan 08 13:05:26 2014) Command finished (0 sec)
--
And as I type i.landsat.dehaze on the command console window check txt file
On 8 January 2014 08:53, Helmut Kudrnovsky hel...@web.de wrote:
2. I tried the g.extension through the black command box, is that what you
mean when you say it doesn't work through the gui? It says command is not
found, I'm doing something wrong there.
not the black command box, it's the command console of the
Wxgui-layer-manager
(http://grasswiki.osgeo.org/wiki/File:Wxgui-layer-manager-70.png)
just type g.extension in the command console of the Wxgui-layer-manager to
open g.extension itself (not the g.extension-wrapper)
or
type command console of the Wxgui-layer-manager [1]
g.extension extension=i.landsat.dehaze operation=add
[1] http://grass.osgeo.org/grass64/manuals/g.extension.html
-
best regards
Helmut
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Python-error-with-GRASS-7-on-Windows-8-tp5096508p5096909.html
Sent from the Grass - Users mailing list archive at Nabble.com.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Nuno César de Sá
+351 91 961 90 37
Traceback (most recent call last):
File C:\Program Files (x86)\GRASS GIS
6.4.4svn\etc\wxpython\gui_core\prompt.py, line 839, in
OnItemSelected
self.cmdDesc = gtask.parse_interface(GetRealCmd(cmd))
File C:\Program Files (x86)\GRASS GIS
6.4.4svn\etc\python\grass\script\task.py, line 470, in
parse_interface
tree = etree.fromstring(get_interface_description(name))
File C:\Program Files (x86)\GRASS GIS
6.4.4svn\etc\python\grass\script\task.py, line 448, in
get_interface_description
\n\nDetails: %(det)s) % { 'cmd' : cmd, 'det' :
decode(cmderr) }
grass.script.core
.
ScriptError
:
Unable to fetch interface description for command
'i.landsat.dehaze.bat'.
Details: C:/Program Files (x86)/GRASS GIS
6.4.4svn/msys/bin/sh.exe:
C:\Users\Invader\AppData\Roaming\GRASS6\addons;C:\Program
Files (x86)\GRASS GIS 6.4.3\etc\gui\scripts;C:\Invader_B\GRA
SS_Workfolder_01\01_LT4/i.landsat.dehaze: No such file or
directory
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Python error with GRASS 7 on Windows 8
(Wed Jan 08 17:10:18 2014) g.extension.py extension=i.landsat.dehaze operation=add WARNING: GRASS_ADDON_PATH has more items, using first defined - 'C:\Users\Invader\AppData\Roaming\GRASS6\addons' WARNING: Extension i.landsat.dehaze already installed. Re-installing... Downloading precompiled GRASS Addons i.landsat.dehaze... Updating metadata file... Installation of i.landsat.dehaze successfully finished (Wed Jan 08 17:10:22 2014) Command finished (4 sec) indeed, that was the error :P But the dehaze continues to not work :'( same error as before On 8 January 2014 16:47, Martin Landa landa.mar...@gmail.com wrote: Hi, 2014/1/8 Nuno Sá nunocesard...@gmail.com: (Wed Jan 08 13:05:25 2014) g.extension extension=i.landsat.dehaze operation=add which: svn: unknown command ERROR: svn client required. Please install Subversion first. (Wed Jan 08 13:05:26 2014) Command finished (0 sec) g.extension in G6 is a shell script which does not work on Windows. The wxGUI wrapper is using python script which is taken from G7. Unfortunately wxGUI wrapper for installing extensions doesn't work (known problem [1]). In other words, Windows users have only one possibility to install an extension from wxGUI command line by running g.extension.py ext=extension Note '.py' extension! Martin [1] http://lists.osgeo.org/pipermail/grass-dev/2014-January/066801.html -- Nuno César de Sá +351 91 961 90 37 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Python error with GRASS 7 on Windows 8
I guess so.. it doesn't crash anywhere else. When I installed GRASS I installed that optional part regarding C++ and Python, could it be that one? On 7 January 2014 12:32, Rashad M mohammedrasha...@gmail.com wrote: Hi Nuno Sa, Are you sure there is no problem with your python version and windows 8? Out of GRASS GIS are you able to use python? On Tue, Jan 7, 2014 at 12:08 PM, Nuno Sá nunocesard...@gmail.com wrote: Hey! All the description I can get from the error is what is in the picture. Is there any other way to get a more detailed report from errors in windows 8? if there is, tell me and I will try. In this case, I am just forcing the error by trying to install an extension (which I really actually need, i.landsat.dehaze). This case its a killer, it says its unable to load extensions. I guess it might also be because I am using the 7 version. See you!! Nuno On 6 January 2014 18:20, Markus Neteler nete...@osgeo.org wrote: On Mon, Jan 6, 2014 at 10:41 AM, Nuno Sá nunocesard...@gmail.com wrote: Hello! Just to know if this is a common problem. Every time I start grass python flags for an error warning me that it stopped working. GRASS itself continues working without any problem, but the python error box keeps appearing. Is there only the message that it stopped working? No more details? I guess this has to do with this version of GRASS being unstable, unless it happens only to me, in which case, it is more serious hehe It is more about how to get Python applications working on Windows :-) It would be great to get a bit more details about the error. Markus -- Nuno César de Sá +351 91 961 90 37 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Regards, Rashad -- Nuno César de Sá +351 91 961 90 37 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Python error with GRASS 7 on Windows 8
Hey I don't :'( so the differential diagnosis continues :P On 7 January 2014 13:15, Anna Petrášová kratocha...@gmail.com wrote: On Tue, Jan 7, 2014 at 7:43 AM, Helmut Kudrnovsky hel...@web.de wrote: (which I really actually need, i.landsat.dehaze) have a look at http://grasswiki.osgeo.org/wiki/AddOns/GRASS_6 and http://grasswiki.osgeo.org/wiki/AddOns/GRASS_7/imagery https://svn.osgeo.org/grass/grass-addons/grass7/imagery/ i.landsat.dehaze seems to be available only for grass6 at the moment (?), maybe the author (cc'ed) has more insight about this. In this case, I am just forcing the error by trying to install an extension beside addon availability, Settings - Addons extensions - Install extensions from addons isn't working in winGRASS7. only the the command line version of g.extension is working, e.g.: g.extension extension=r.geomorphon operation=add Downloading precompiled GRASS Addons r.geomorphon... Updating metadata file... Installation of r.geomorphon successfully finished (Tue Jan 07 13:41:31 2014) Command finished (2 sec) please open a ticket in http://trac.osgeo.org/grass/ this can be again the Python incompatibility issue (the MAXREPEAT problem). For this issue there is already ticket http://trac.osgeo.org/grass/ticket/2150 It usually appears when you have also ArcGIS installed. Anna - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Python-error-with-GRASS-7-on-Windows-8-tp5096508p5096756.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Nuno César de Sá +351 91 961 90 37 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Python error with GRASS 7 on Windows 8
Oh sorry, I should have added in the previous response to avoid too many
emails:
I have both 6.4.3 and 7 installed at the same time, the first issues no
errors in any moment with the exception of not being able to call
i.landsat.dehaze on the gui command console (yes i have used the plugging
installer to install it). The error log is on the .txt file appended
Ciao!
Thank you so much for the help so far, and I'm sorry if I'm causing any
trouble.
On 7 January 2014 13:29, Nuno Sá nunocesard...@gmail.com wrote:
Hey
I don't :'( so the differential diagnosis continues :P
On 7 January 2014 13:15, Anna Petrášová kratocha...@gmail.com wrote:
On Tue, Jan 7, 2014 at 7:43 AM, Helmut Kudrnovsky hel...@web.de wrote:
(which I really actually need, i.landsat.dehaze)
have a look at
http://grasswiki.osgeo.org/wiki/AddOns/GRASS_6
and
http://grasswiki.osgeo.org/wiki/AddOns/GRASS_7/imagery
https://svn.osgeo.org/grass/grass-addons/grass7/imagery/
i.landsat.dehaze seems to be available only for grass6 at the moment (?),
maybe the author (cc'ed) has more insight about this.
In this case, I am just forcing the error by trying to install an
extension
beside addon availability, Settings - Addons extensions - Install
extensions from addons isn't working in winGRASS7.
only the the command line version of g.extension is working, e.g.:
g.extension extension=r.geomorphon operation=add
Downloading precompiled GRASS Addons r.geomorphon...
Updating metadata file...
Installation of r.geomorphon successfully finished
(Tue Jan 07 13:41:31 2014) Command finished (2 sec)
please open a ticket in http://trac.osgeo.org/grass/
this can be again the Python incompatibility issue (the MAXREPEAT
problem). For this issue there is already ticket
http://trac.osgeo.org/grass/ticket/2150
It usually appears when you have also ArcGIS installed.
Anna
-
best regards
Helmut
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/Python-error-with-GRASS-7-on-Windows-8-tp5096508p5096756.html
Sent from the Grass - Users mailing list archive at Nabble.com.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Nuno César de Sá
+351 91 961 90 37
--
Nuno César de Sá
+351 91 961 90 37
Traceback (most recent call last):
File C:\Program Files (x86)\GRASS GIS
6.4.3\etc\wxpython\gui_core\prompt.py, line 839, in
OnItemSelected
self.cmdDesc = gtask.parse_interface(GetRealCmd(cmd))
File C:\Program Files (x86)\GRASS GIS
6.4.3\etc\python\grass\script\task.py, line 470, in
parse_interface
tree = etree.fromstring(get_interface_description(name))
File C:\Program Files (x86)\GRASS GIS
6.4.3\etc\python\grass\script\task.py, line 448, in
get_interface_description
\n\nDetails: %(det)s) % { 'cmd' : cmd, 'det' :
decode(cmderr) }
grass.script.core
.
ScriptError
:
Unable to fetch interface description for command
'i.landsat.dehaze.bat'.
Details: C:/Program Files (x86)/GRASS GIS
6.4.3/msys/bin/sh.exe:
C:\Users\Invader\AppData\Roaming\GRASS6\addons;C:\Program
Files (x86)\GRASS GIS 6.4.3\etc\gui\scripts;C:\Invader_B\GRA
SS_Workfolder_01\01_LT4/scripts/i.landsat.dehaze: No such
file or directory
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Python error with GRASS 7 on Windows 8
Thank you once again guys, I'll try tomorrow morning, I do have a technical question: 1. Once the Haze is removed, should we re-calculate again the tasscap? 2. I tried the g.extension through the black command box, is that what you mean when you say it doesn't work through the gui? It says command is not found, I'm doing something wrong there. 3. Is it possible to add these tools through the QGIS? maybe through there my problem will be solved Dzien kuia bardzo :) On 7 January 2014 19:12, Helmut Kudrnovsky hel...@web.de wrote: Which seems that there are some problems with path separator since it is trying to run C:\;C: \...i.landsat.dehaze file which does not exists from obvious reasons. Those involved in #2138, is this what #2138 is trying to solve? http://trac.osgeo.org/grass/ticket/2138 as i.landsat.dehaze is a shell addon script, #2138 tries to fix python addon script working - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Python-error-with-GRASS-7-on-Windows-8-tp5096508p5096848.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Nuno César de Sá +351 91 961 90 37 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Python error with GRASS 7 on Windows 8
Hello! Just to know if this is a common problem. Every time I start grass python flags for an error warning me that it stopped working. GRASS itself continues working without any problem, but the python error box keeps appearing. I guess this has to do with this version of GRASS being unstable, unless it happens only to me, in which case, it is more serious hehe So, how common is this error? Does it happen with you? Ciao! Nuno -- Nuno César de Sá +351 91 961 90 37 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS 6.4.3 - Technical questions on Landsat TM/ETM+/OLI and other
Hey, thank you so much :)! I gave up on using the i.pca since it was giving reeaally unexpected results but I think i was doing it wrong. Regarding cloud cover on this LS TM 5 image (lets use it as benchmark) i: CLOUD_COVER = 0.00 IMAGE_QUALITY = 9 Can't really evaluate the output of with the minnaert, it gave obviously a bit different colouring after streching but the overall thing is similiar, besides: Band 2007027_LT5_B.1: Minnaert constant = 0.00 Color table for raster map npca_topo_minna_CM.2007027_LT5_B.1 set to 'grey' So, am I doing something wrong here? maybe I should input a slop layer somehow or verify if the output of illumination is COS(i) or i? i.landsat.rgb and i.landsat.dehaze keep failing.. I also tried to plot feature spaces using d.correlate as an experiment and it says its not implemented in the GUI, for me to use the command line. Is that the the command box that comes with a GUI or is it something somewhere else? I'll try the i.pca correction now. With a 3x3 avg filter it looks nice'er but not nice enough, the image really looks very saturated with expected greens being yellowish :\ On 19 December 2013 01:27, Nikos Alexandris n...@nikosalexandris.net wrote: Nikos: .. i.pca (in GRASS7) which can perform first a forward PCA, filter Components (essentialy keep only Components whose sum of eigenvalues are =... .. It's too late here... so correction: the above would be the importance percentage. And, obviously, if you check the i.pca manual (G7 only), the parameter is called percent. What a surprise :D Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Nuno César de Sá +351 91 961 90 37 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] GRASS 6.4.3 - Technical questions on Landsat TM/ETM+/OLI and other
Hey! I am re-sending this email, I think it got blocked because of attached images jpg examples, if you want to see it, I will send it personally. This is my first post, unfortunate it's not to help somebody but to ask for some help.. I do have to say, GRASS seems to be great so far and I feel my problems are probably user related. I am pre-processing Landsat data (at the moment only TM and ETM) to use for a classification later, doesn't matter. Since all the data I'm acquiring comes as L1T (204/032), then the pre-processing workflow was done as follows: DN - TOA reflectance(temperature) - Cloud detection and masking (if necessary) - Topographic correction using ASTERM 30m DEM. All data projection is as delivered by USGS (I don't remember if I reprojected the DEM but most probably I did). Imagery dates - 204/32: TM4 - 1989001 (January 1, 1989) TM5 - 2007027 (January 27,2007) ETM+ - 2003023 (January 23,2003) All until here seems fine I guess, but I am having the following issues: - Band seems saturated or affected by some multiplier. Such as TM4 composites look normal or as expected but TM5 and ETM+ seem pinkish or saturated as if one of the bands is saturated. - Since TM4 looks the most normal, all the others seem affected by some kind of noise (white noise?). Should I apply a Low pass filter of some kind? - Both i.landsat.rgb (runs endlessly) and i.landsat.dehaze (says it can't find the GUI, I've re-installed it without success) If you need added information, please ask and I'll send you the commands. Here are the ones which i have been using. Added note: I'm using Windows 8! (don't know how important that can be) --- Calling the file r.in.gdal input=C:\Invader_B\GRASS_Workfolder_01\01_LT5\LT52040322007027MPS00\LT52040322007027MPS00_B1.TIF output=RAW_2007027_LT5_B.1 (...) (i used DOS2 in this latest attempt since both uncorrected and DOS1 yield similar problems) i.landsat.toar sensor=tm5 method=dos2 --overwrite --verbose input_prefix=RAW_2007027_LT5_B. output_prefix=2007027_LT5_B. metfile=C:\Invader_B\GRASS_Workfolder_01\01_LT5\LT52040322007027MPS00\LT52040322007027MPS00_MTL.txt i.landsat.acca --overwrite --verbose -5 input_prefix=2007027_LT5_B. output=2007027_CloudMask (The mask is not used by me since i visually see there are no clouds [there is snow in Serra da Estrela, famous place here]) Getting the illumination raster i.topo.corr -i --overwrite base=ASTER_30m zenith=63.09559142 azimuth=153.85758094 out=ASTER.illu.prj i.topo.corr base=ASTER.illu.prj zenith=63.09559142 method=c-factor --verbose --overwrite input=2007027_LT5_B.1,2007027_LT5_B.2,2007027_LT5_B.3,2007027_LT5_B.4,2007027_LT5_B.5,2007027_LT5_B.6,2007027_LT5_B.7 out=npca_topo_CM r.colors -e map=npca_topo_CM.2007027_LT5_B.1@01_LT5 color=grey (...) d.rgb to display the image in attachment. Pop-up window box text for i.landsat.dehaze: unable to fetch interface description for command i.landsat.dehaze.bat. Details: (...) ./scripts/i.landsat.dehaze: no such file or directory -- Nuno César de Sá +351 91 961 90 37 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
