Re: [GRASS-user] Error while creating vectorial file in WinGRASS

2010-08-04 Thread Hamish
You need to run db.connect to select a database backend to use
first. (There is no VAR file in the mapset yet)

Manage databases - connect

see the help page for details, I usually just cut and paste out of the 
examples. v.db.addtable can probably do this automatically.

Vector database connections - New Table

Most modules should create the connection if needed using the default
DB (dbf in grass 6.4) if it is needed, but because db.execute is raw
perhaps it shouldn't and whatever in the GUI is calling that should
check that first.

Hamish


Kim Besson wrote:
- Error in command execution db.executeExecution failed: 'db.execute 
--q'Details: Error: Unable to start driver (null)
And the following is printed in Command Output:
Traceback (most recent call last):  File C:/GRASS6/etc/wxpython/wxgui.py, 
line 546, inOnNewVector
cmdDef=(['v.edit', 'tool=create'], map))
  File C:\GRASS6\etc\wxpython\gui_modules\gdialogs.py,line 192, in 
CreateNewVector
stdin=sql)  File C:\GRASS6\etc\wxpython\gui_modules\gcmd.py, line
369, in __init__
_(Error: ) + self.GetError()))gui_modules.gcmd.CmdErrorTraceback (most recent 
call last):  File C:/GRASS6/etc/wxpython/wxgui.py, line 546, in
OnNewVector
cmdDef=(['v.edit', 'tool=create'], map))  File 
C:\GRASS6\etc\wxpython\gui_modules\gdialogs.py,line 192, in CreateNewVector

stdin=sql)  File C:\GRASS6\etc\wxpython\gui_modules\gcmd.py, line369, in 
__init__
_(Error: ) + self.GetError()))gui_modules.gcmd
.CmdError
I believe this was not expected but, what might be wrong?
Thanks
Kim
I have installed WinGRASS-6.4.SVN-r42868-1-Setup.exe in my WinXP machine and, 
when I  select Vector/Develop Vector Map/Create new vector map, I place output 
name and check Create Attibute table I get an error windows stating:



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


Re: [GRASS-user] Distance-weighted focal functions?

2010-08-04 Thread Jarek Jasiewicz

Dylan Beaudette pisze:

Hi,

After hacking together some R + r.mapcalc code, I started to wonder about how 
hard it would be to add distance-weighting to r.neighbors... Specifically, 
the focal distance-weighted mean difference. An example of what I was trying 
to accomplish can be found here:


http://casoilresource.lawr.ucdavis.edu/drupal/node/937

Surely there is a more elegant solution using r.mfilter.fp, or the like... 


Cheers,
Dylan

  

It shoud not be difficult. See solution in r.convergence in ADD-ONS
J.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Error while creating vectorial file in WinGRASS

2010-08-04 Thread Hamish
Hamish wrote:
 You need to run db.connect to select a database backend to
 use first. (There is no VAR file in the mapset yet)

hopefully fixed  ready for testing in 6.5svn r42988 (v.edit).


devs:
 maybe do this for 'v.in.ascii -e' and 'v.digit -n' too?
 or move this into Vect_open_new() ?  ... but I'm not totally
convinced that's the right place for it either; the mapset may
come from an earlier version of GRASS. perhaps db.execute
instead of exiting with an error.


#include grass/dbmi.h
...
  if (! db_get_default_driver_name() ) {
  G_message(_(Creating new DB connection based on default mapset 
settings...));
  db_set_default_connection();
  }


see bug #7  http://trac.osgeo.org/grass/ticket/7


Hamish




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


Re: [GRASS-user] Error while creating vectorial file in WinGRASS

2010-08-04 Thread Markus Metz
Hamish wrote:
 Hamish wrote:
 You need to run db.connect to select a database backend to
 use first. (There is no VAR file in the mapset yet)

 hopefully fixed  ready for testing in 6.5svn r42988 (v.edit).


 devs:
  maybe do this for 'v.in.ascii -e' and 'v.digit -n' too?
  or move this into Vect_open_new() ?

Not to Vect_open_new(), a GRASS vector does not need to have a DB
connection, this is optional.

Markus M


... but I'm not totally
 convinced that's the right place for it either; the mapset may
 come from an earlier version of GRASS. perhaps db.execute
 instead of exiting with an error.


 #include grass/dbmi.h
 ...
  if (! db_get_default_driver_name() ) {
      G_message(_(Creating new DB connection based on default mapset 
 settings...));
      db_set_default_connection();
  }


 see bug #7  http://trac.osgeo.org/grass/ticket/7


 Hamish





 ___
 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


[GRASS-user] Filling Null values in a MODIS image

2010-08-04 Thread Hanlie Pretorius
Hi,

I have a MODIS land cover image that contains NULL values according to r.univar:
-
r.univar map=modis_land_cover_type1_2001_prim...@permanent
total null and non-null cells: 41884
total null cells: 17145
-

So, I tried to fill it with r.fillnulls and I get the following:
-
r.fillnulls input=mcd12q1.a2001001.005_land_cover_ty...@permanent
output=MCD12Q1.A2001001.005_land_cover_type1_filled
Locating and isolating NULL areas...
Reading input raster map r_fillnulls_1...@permanent...
Writing output raster map r_fillnulls_1911.buf...
Creating interpolation points...
Extracting points...
Building topology for vector map vecttmp_fillnulls_1911...
Registering primitives...
0 primitives registered
0 vertices registered
Building areas...
0 areas built
0 isles built
Attaching islands...
Attaching centroids...
Number of nodes: 0
Number of primitives: 0
Number of points: 0
Number of lines: 0
Number of boundaries: 0
Number of centroids: 0
Number of areas: 0
Number of isles: 0
r.to.vect complete.
Interpolating 0 points
Not sufficient points to interpolate. Maybe no hole(s) to fill in the
current map region?
Removing raster MASK
Removing raster r_fillnulls_1911
Removing raster r_fillnulls_1911.buf
Removing raster r_fillnulls_1911_filled
Raster map r_fillnulls_1911_filled not found
r_fillnulls_1911_filled nothing removed
Removing vector vecttmp_fillnulls_1911
(Wed Aug  4 10:18:22 2010) Command finished (0 sec)
-

Output of g.region -p:
-
g.region -p rast=modis_land_cover_type1_2001_prim...@permanent res=0.00423094
projection: 3 (Latitude-Longitude)
zone:   0
datum:  wgs84
ellipsoid:  wgs84
north:  27:19:08.833466S
south:  28:30:53.475952S
west:   28:03:57.840271E
east:   28:41:37.727966E
nsres:  0:00:15.210751
ewres:  0:00:15.269511
rows:   283
cols:   148
cells:  41884
-

Output of r.info:
-
r.info map=modis_land_cover_type1_2001_prim...@permanent
 ++
 | Layer:modis_land_cover_type1_2001_p  Date: Thu Jul 29 15:17:55 2010
 | Mapset:   PERMANENT  Login of Creator: hanlie
 | Location: world_wgs84
 | DataBase: /media/0847147784/grassdata
 | Title: ( MCD12Q1.A2001001.005_land_cover_type1 )
 | Timestamp: none
 |
 |
 |   Type of Map:  raster   Number of Categories: 14
 |   Data Type:CELL
 |   Rows: 11957
 |   Columns:  6277
 |   Total Cells:  75054089
 |Projection: Latitude-Longitude
 |N: 27:19:08.833466SS: 28:30:53.475952S   Res: 0:00:00.36001
 |E: 28:41:37.727966EW: 28:03:57.840271E   Res: 0:00:00.36002
 |   Range of data:min = 1  max = 14
 |
 |   Data Description:
 |generated by r.in.gdal
 |
 |   Comments:
 |r.in.gdal input=F:\Hanlie\UCT\M.Sc\Data\modis\MOD12Q1\MCD12Q1.A2001\
 |001.h20v11.005.2009342153812_land_cover_type1.tif output=MCD12Q1.A\
 |2001001.005_land_cover_type1
 |
 ++


I have tried to see the NULLS by displaying everything in white,
except for NULLS displayed in red, but I didn't see anything.

Does anyone know how I can find out if there are actually NULL value
and where they are?

Thanks
Hanlie
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Filling Null values in a MODIS image

2010-08-04 Thread Markus Metz
Hanlie Pretorius wrote:
 Hi,

 I have a MODIS land cover image that contains NULL values according to 
 r.univar:
 -
 r.univar map=modis_land_cover_type1_2001_prim...@permanent
 total null and non-null cells: 41884
 total null cells: 17145
 -

 So, I tried to fill it with r.fillnulls
 -
...

 Output of g.region -p:
 -
 nsres:      0:00:15.210751
 ewres:      0:00:15.269511
 -

 Output of r.info:
 -
 r.info map=modis_land_cover_type1_2001_prim...@permanent
  Res: 0:00:00.36001
  Res: 0:00:00.36002

Adjust the resolution of the current region to the MODIS image, either
g.region rast=modis_land_cover_type1_2001_prim...@permanent
or
g.region align=modis_land_cover_type1_2001_prim...@permanent
if you want to work with custom bounds.

That should do the trick

Markus M
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] High resolution dem

2010-08-04 Thread Frank Broniewski

Hi,


Hamish:Feb 28, 2010; 03:15am Re: High resolution dem
I am curious to know what the problem with r.surf.contour was. Usually
it does a great job as long as you take a moment to work around the
integer and NULL/0 issues.


Sorry that I quitted this discussion so silently, but I had to drop this 
and could not persue the issue further. Sometimes I really could use a 
48h day :-)
Of course my problems are still present. To take the thread up again, I 
want to answer to Hamish's question about my problems with 
r.surf.contour first:


DEM interpolation seems to work nice, but when you start deriving maps, 
especially the aspect map looks simply not right ;-)
I've uploaded some example images on our server, so that you can see 
what I mean:


http://www.gis-hosting.lu/static/img/grass/contours5m.png
http://www.gis-hosting.lu/static/img/grass/dtm5m.png
http://www.gis-hosting.lu/static/img/grass/dtm3d.png
http://www.gis-hosting.lu/static/img/grass/expo5m.png

The data source is a shape file with contour lines with 5 meters 
interval. Conversion to raster went well and the pixel values match the 
height values for the contours. Before using the raster map, I 
multiplied the map with 10, just like it is mentioned in the wiki. 
Interpolation took approx. 5 minutes. The region is 10,000m * 10,000m 
wide and has a 5m resolution. Before deriving the aspect map, I divided 
the elevation map by 10 to gain real height values again ...


Now I wonder what could cause the gaps in the aspect map - since the 
terrain model itself looks OK to me ...


Many thanks

Frank

--
Frank BRONIEWSKI

METRICO s.à r.l.
géomètres
technologies d'information géographique
rue des Romains 36
L-5433 NIEDERDONVEN

tél.: +352 26 74 94 - 28
fax.: +352 26 74 94 99
http://www.metrico.lu
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Filling Null values in a MODIS image

2010-08-04 Thread Markus Metz
Apart from the region resolution, it's land cover classes, r.fillnulls
will produce nonsense data: floating point. Rather use r.neighbors
with a modal filter, patch the original with the filtered map, that
would replace NULLs with the most common surrounding land cover type.

Markus M


Hanlie Pretorius wrote:
 Hi,

 I have a MODIS land cover image that contains NULL values according to 
 r.univar:
 -
 r.univar map=modis_land_cover_type1_2001_prim...@permanent
 total null and non-null cells: 41884
 total null cells: 17145
 -

 So, I tried to fill it with r.fillnulls and I get the following:
 -
 r.fillnulls input=mcd12q1.a2001001.005_land_cover_ty...@permanent
 output=MCD12Q1.A2001001.005_land_cover_type1_filled
 Locating and isolating NULL areas...
 Reading input raster map r_fillnulls_1...@permanent...
 Writing output raster map r_fillnulls_1911.buf...
 Creating interpolation points...
 Extracting points...
 Building topology for vector map vecttmp_fillnulls_1911...
 Registering primitives...
 0 primitives registered
 0 vertices registered
 Building areas...
 0 areas built
 0 isles built
 Attaching islands...
 Attaching centroids...
 Number of nodes: 0
 Number of primitives: 0
 Number of points: 0
 Number of lines: 0
 Number of boundaries: 0
 Number of centroids: 0
 Number of areas: 0
 Number of isles: 0
 r.to.vect complete.
 Interpolating 0 points
 Not sufficient points to interpolate. Maybe no hole(s) to fill in the
 current map region?
 Removing raster MASK
 Removing raster r_fillnulls_1911
 Removing raster r_fillnulls_1911.buf
 Removing raster r_fillnulls_1911_filled
 Raster map r_fillnulls_1911_filled not found
 r_fillnulls_1911_filled nothing removed
 Removing vector vecttmp_fillnulls_1911
 (Wed Aug  4 10:18:22 2010) Command finished (0 sec)
 -

 Output of g.region -p:
 -
 g.region -p rast=modis_land_cover_type1_2001_prim...@permanent res=0.00423094
 projection: 3 (Latitude-Longitude)
 zone:       0
 datum:      wgs84
 ellipsoid:  wgs84
 north:      27:19:08.833466S
 south:      28:30:53.475952S
 west:       28:03:57.840271E
 east:       28:41:37.727966E
 nsres:      0:00:15.210751
 ewres:      0:00:15.269511
 rows:       283
 cols:       148
 cells:      41884
 -

 Output of r.info:
 -
 r.info map=modis_land_cover_type1_2001_prim...@permanent
  ++
  | Layer:    modis_land_cover_type1_2001_p  Date: Thu Jul 29 15:17:55 2010
  | Mapset:   PERMANENT                      Login of Creator: hanlie
  | Location: world_wgs84
  | DataBase: /media/0847147784/grassdata
  | Title:     ( MCD12Q1.A2001001.005_land_cover_type1 )
  | Timestamp: none
  |
  |
  |   Type of Map:  raster               Number of Categories: 14
  |   Data Type:    CELL
  |   Rows:         11957
  |   Columns:      6277
  |   Total Cells:  75054089
  |        Projection: Latitude-Longitude
  |            N: 27:19:08.833466S    S: 28:30:53.475952S   Res: 0:00:00.36001
  |            E: 28:41:37.727966E    W: 28:03:57.840271E   Res: 0:00:00.36002
  |   Range of data:    min = 1  max = 14
  |
  |   Data Description:
  |    generated by r.in.gdal
  |
  |   Comments:
  |    r.in.gdal input=F:\Hanlie\UCT\M.Sc\Data\modis\MOD12Q1\MCD12Q1.A2001\
  |    001.h20v11.005.2009342153812_land_cover_type1.tif output=MCD12Q1.A\
  |    2001001.005_land_cover_type1
  |
  ++


 I have tried to see the NULLS by displaying everything in white,
 except for NULLS displayed in red, but I didn't see anything.

 Does anyone know how I can find out if there are actually NULL value
 and where they are?

 Thanks
 Hanlie
 ___
 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


Re: [GRASS-user] Error while creating vectorial file in WinGRASS

2010-08-04 Thread Kim Besson
Hi there
Regarding Hamish suggestion 
You need to run db.connect to select a database backend to use
first. (There is no VAR file in the mapset yet)
The thing is: I have been using an WinGRASS6.4 binary version where I didn't
need to do anything else. Just create Vector by doing this. So, my question
is, why was this disabled? Or is it some error that only occurs in this
release?

About
hopefully fixed  ready for testing in 6.5svn r42988 (v.edit).
Will it be available for 6.4 in Windows?
Thanks
Kim
2010/8/4 Markus Metz markus.metz.gisw...@googlemail.com

 Hamish wrote:
  Hamish wrote:
  You need to run db.connect to select a database backend to
  use first. (There is no VAR file in the mapset yet)
 
  hopefully fixed  ready for testing in 6.5svn r42988 (v.edit).
 
 
  devs:
   maybe do this for 'v.in.ascii -e' and 'v.digit -n' too?
   or move this into Vect_open_new() ?

 Not to Vect_open_new(), a GRASS vector does not need to have a DB
 connection, this is optional.

 Markus M


 ... but I'm not totally
  convinced that's the right place for it either; the mapset may
  come from an earlier version of GRASS. perhaps db.execute
  instead of exiting with an error.
 
 
  #include grass/dbmi.h
  ...
   if (! db_get_default_driver_name() ) {
   G_message(_(Creating new DB connection based on default mapset
 settings...));
   db_set_default_connection();
   }
 
 
  see bug #7  http://trac.osgeo.org/grass/ticket/7
 
 
  Hamish
 
 
 
 
 
  ___
  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


Re: [GRASS-user] Error while creating vectorial file in WinGRASS

2010-08-04 Thread Hamish
Kim wrote:
 Hi there
Regarding Hamish suggestion You need to run db.connect to select a
 database backend to use first. (There is no VAR file in the mapset
 yet)
 The thing is: I have been using an WinGRASS6.4 binary version where I
 didn't need to do anything else. Just create Vector by doing this. So,
 my question is, why was this disabled? Or is it some error that only
 occurs in this release?

the GUI is making the assumption that the mapset will already have a
database link. I don't know when that started. This usually happens for
you when you first create a map in the mapset which uses a database table.
Modules should create that for you if it is needed, but some do not and so
the GRASS startup script for unix was changed to automatically set the
default if it wasn't set already. The Windows startup script does not set
the default DB for you (in the mapset's VAR file) apparently.
(see bug #7)

Perhaps if you start GRASS with MSys the unix startup script might be
used and then it might work from that mapset?? (not sure)


 About
  hopefully fixed  ready for testing in 6.5svn r42988 (v.edit).
 Will it be available for 6.4 in Windows?

I am not totally happy with that work-around, once we decide on the
correct solution it will of course be backported to 6.4. GRASS 6.5 and 7
are for experimenting to find the best solution, which is the stage this
is currently at.


regards,
Hamish



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


Re: [GRASS-user] Filling Null values in a MODIS image

2010-08-04 Thread Hamish
Hanlie wrote:
 I have a MODIS land cover image that contains NULL values
 according to r.univar:
 -
 r.univar map=modis_land_cover_type1_2001_prim...@permanent
 total null and non-null cells: 41884
 total null cells: 17145
 -
 
 So, I tried to fill it with r.fillnulls and I get the
 following:

(as suggested by http://grass.osgeo.org/wiki/MODIS#Removing_holes
 http://grass.osgeo.org/wiki/AVHRR#Removing_holes )

Hamish



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


Re: [GRASS-user] Filling Null values in a MODIS image

2010-08-04 Thread Hamish
Hanlie wrote:
  |   Rows: 11957
  |   Columns:  6277
...
 I have tried to see the NULLS by displaying everything in
 white, except for NULLS displayed in red, but I didn't see
 anything.

 Does anyone know how I can find out if there are actually
 NULL value and where they are?

try zooming in. Unless you have a 12000x7000 monitor, some cells will be
hidden.

extract with r.mapcalc and buffer with r.buffer if they are still hard to find.



Hamish



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


Re: [GRASS-user] Feed and manipulate the result of v.distance -pa in python

2010-08-04 Thread Hamish
Nikos Alexandris wrote:
 I need to convert the following bash-one-liner:
 
 v.distance --q -pa from=ref_points to=coi_points upload=cat \
   column=anycol | cut -d| -f2 | sort -nu | tail -1
 
 into python.
 
 My unsolved problem is that v.distance -pa returns for
 example thousands of 
 lines in the following format:
 ...
 7839|16
 7839|17
 7839|22
 7839|23
 7839|24
 
 Reading the main command in python is not the problem
 (although I am a bit 
 confused between grass.pipe, grass.feed, grass.read). Are
 there any examples 
 (scripts in grass trunk maybe?) to follow in order to split
 the output, keep 
 the second column, sort and keep the maximum? Actually
 the split is what 
 worries me most. I 've been looking for quite some time to
 find something that 
 gives me a strait answer but no luck yet.

try v.rast.stats.py:   cats.append(line.rstrip('\r\n').split(';')[0])

that splits on ; as the sep, and takes the first entry (column counting
starts at 0 not 1 here)

so for you:   line.split('|')[1]

no idea about sorting, but you may be able to program a loop which 
starts out empty and only updates if the line's dmax is bigger that the
one stored in the overall variable's, or if the variable is empty (for
the first).


Hamish



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


[GRASS-user] GRASS vs OpenJump

2010-08-04 Thread Fahad Rasheed
Hi all ,

 I recently viewed OpenJump application written in JAVA which is also a
GIS software but have less features when compared to GRASS GIS. What my plan
is to contribute modules of  GRASS GIS written in C/Python to OpenJump
written in Java. Does osgeo or any grass developers have any objection in
copying the code (mean the idea of making modules) to other OpenSource
software like OpenJump. I do not mean of copying the whole code as same to
java. What is my part of contribution is porting C/C++/Python code to Java
and making some hacks on source code.

I also want to know why OpenJump was not accepted by osgeo.

Any sugeestion and comments are really welcomed..
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] Re: Installing r.area

2010-08-04 Thread LeeDaniel


This will never work unless the OpenSuse packager fixes the
 wrong path (.../BUILD/... is wrong and needs to be /opt/...).
 
 Or you do it yourself... AFAIK, it is in your case in
 /opt/grass/include/Make/Platform.make 

Alright, I think I understood what to do.  I edited
/opt/grass/include/Make/Platform.make (made a backup) and changed these two
lines from:
# GRASS dirs
GRASS_HOME  = /usr/src/packages/BUILD/grass-6.4.0RC6
RUN_GISBASE =
/usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu

to:
# GRASS dirs
GRASS_HOME  = /opt/grass
RUN_GISBASE = /opt/grass/dist.i686-pc-linux-gnu

But this still happens:
l...@pc19384:~/r.area make
Makefile:11: ../../include/Make/Module.make: Datei oder Verzeichnis nicht
gefunden
make: *** Keine Regel, um »../../include/Make/Module.make« zu erstellen. 
Schluss.
l...@pc19384:~/r.area make MODULE_TOPDIR=/opt/grass/
gcc -I/opt/grass/dist.i686-pc-linux-gnu/include  -O2  
-DPACKAGE=\grassmods\  -I/opt/grass/dist.i686-pc-linux-gnu/include -o
OBJ.i686-pc-linux-gnu/main.o -c main.c
main.c:19:23: schwerwiegender Fehler: grass/gis.h: Datei oder Verzeichnis
nicht gefunden
Kompilierung beendet.
make: *** [OBJ.i686-pc-linux-gnu/main.o] Fehler 1

Did I do something wrong?

Thanks a bunch!
Daniel
-- 
View this message in context: 
http://osgeo-org.1803224.n2.nabble.com/Installing-r-area-tp5340139p5372018.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


[GRASS-user] Re: Filling Null values in a MODIS image

2010-08-04 Thread Hanlie Pretorius
2010/8/4, Hamish hamis...@yahoo.com:
 Hanlie wrote:
  |   Rows: 11957
  |   Columns:  6277
 ...
 I have tried to see the NULLS by displaying everything in
 white, except for NULLS displayed in red, but I didn't see
 anything.

 Does anyone know how I can find out if there are actually
 NULL value and where they are?

 try zooming in. Unless you have a 12000x7000 monitor, some cells will be
 hidden.

 extract with r.mapcalc and buffer with r.buffer if they are still hard to
 find.


Thanks for all the replies. I first tried finding the NULLS using
r.mapcalc, and it turns out that the NULLS are the cells in the GRASS
region (rectangular), but outside my study region (irregular
geographical border). I was under the misconception that g.region set
to a raster file functions like a mask.

About the r.neighbors procedure, why is it necessary to follow with
r.patch? Surely the result of r.neighbors will be without NULLS? I did
find, though, that r.neighbours resulted in raster with extended
borders compared to the original, which makes sense. One would then
have to clip it again to the study area. Or use a mask of the original
area before running r.patch?

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


Re: [GRASS-user] Re: Filling Null values in a MODIS image

2010-08-04 Thread Markus Metz
Hanlie Pretorius wrote:

 Thanks for all the replies. I first tried finding the NULLS using
 r.mapcalc, and it turns out that the NULLS are the cells in the GRASS
 region (rectangular), but outside my study region (irregular
 geographical border). I was under the misconception that g.region set
 to a raster file functions like a mask.

Only the N S E W bounds, no irregular border, a MASK would be required here.

 About the r.neighbors procedure, why is it necessary to follow with
 r.patch? Surely the result of r.neighbors will be without NULLS?

That depends on the moving window size and the size of NULL areas. If
all cells in a moving window are NULL, the result should also be NULL.
Patching makes sense only for time series of data like temperature or
vegetation indices. For land cover type, patching with different years
might not be desired.

 I did
 find, though, that r.neighbours resulted in raster with extended
 borders compared to the original, which makes sense. One would then
 have to clip it again to the study area. Or use a mask of the original
 area before running r.patch?

Before doing any analysis or processing, I would set the region to the
raster including its resolution, create a MASK for the study area
maybe with a buffer around, zoom to the MASK with g.region zoom=MASK,
just to be sure align again the region to the raster resolution with
g.region align=modis_land_cover_type1_2001_primary, only now start
processing.

In this particular case, the most conservative solution would probably
be to reclassify all NULL cells as unclassified (there should be a
category value for unclassified).

Markus M
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] Re: Feed and manipulate the result of v.distance -pa in python

2010-08-04 Thread schorschli

For your task the use of lists and the split tool may help.
The different lines have are seperated by a  '\n' (which is interpreted as a
new line). After splitting the string into a line list you can make a loop
each item of this list. Something like this:

output='7839|16\n7839|17\n7839|22\n7839|23\n7839|24'

seccond_column_list=[]
max_value=0

line_list=output.split('\n')

for line in line_list:
columns=line.split('|')
seccond_column_list.append(float(columns[1]))

max_value=max(seccond_column_list)

print seccond_column_list
print max_value 


I may missunderstood your question but I hope this helps.
-- 
View this message in context: 
http://osgeo-org.1803224.n2.nabble.com/Feed-and-manipulate-the-result-of-v-distance-pa-in-python-tp5371195p5372457.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


Re: [GRASS-user] Re: Installing r.area

2010-08-04 Thread Glynn Clements

LeeDaniel wrote:

  wrong path (.../BUILD/... is wrong and needs to be /opt/...).
  
  Or you do it yourself... AFAIK, it is in your case in
  /opt/grass/include/Make/Platform.make 
 
 Alright, I think I understood what to do.  I edited
 /opt/grass/include/Make/Platform.make (made a backup) and changed these two
 lines from:
 # GRASS dirs
 GRASS_HOME  = /usr/src/packages/BUILD/grass-6.4.0RC6
 RUN_GISBASE =
 /usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu
 
 to:
 # GRASS dirs
 GRASS_HOME  = /opt/grass
 RUN_GISBASE = /opt/grass/dist.i686-pc-linux-gnu

GRASS_HOME is the location of the GRASS source tree. If you don't have
the GRASS source tree, it should be unset.

Its value is used to initialise a few other variables, which need to
be changed when building without the source tree:

ARCH_DISTDIR= $(GRASS_HOME)/dist.$(ARCH)
ARCH_BINDIR = $(GRASS_HOME)/bin.$(ARCH)
ERRORLOG= $(GRASS_HOME)/error.log

If you're building against an installed version, ARCH_DISTDIR should
be set to the installation directory (e.g. /usr/local/grass-6.4.0RC6),
ARCH_BINDIR shouldn't matter, and ERRORLOG can be set to any absolute
filename.

Also, you need to override MODULE_TOPDIR on the command line, e.g.:

make MODULE_TOPDIR=/usr/local/grass-6.4.0RC6

This is used to locate the *.make files, so setting in those files
won't work.

-- 
Glynn Clements gl...@gclements.plus.com
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] Re: Installing r.area

2010-08-04 Thread LeeDaniel

Alright, I gave it another shot...


GRASS_HOME is the location of the GRASS source tree. If you don't have
 the GRASS source tree, it should be unset.
 
Okay, I turned it off by putting # in front of it. Now the line looks like
this:
# GRASS dirs
# GRASS_HOME  = /usr/src/packages/BUILD/grass-6.4.0RC6


Its value is used to initialise a few other variables, which need to
 be changed when building without the source tree:
 
 ARCH_DISTDIR = $(GRASS_HOME)/dist.$(ARCH)
 ARCH_BINDIR = $(GRASS_HOME)/bin.$(ARCH)
 ERRORLOG= $(GRASS_HOME)/error.log
 
 If you're building against an installed version, ARCH_DISTDIR should
 be set to the installation directory (e.g. /usr/local/grass-6.4.0RC6),
 ARCH_BINDIR shouldn't matter, and ERRORLOG can be set to any absolute
 filename.
Alright. I took out the variable $ARCH_DISTDIR and replaced it with
/opt/grass/. So the three lines the GRASS dirs are now:
# GRASS dirs
# GRASS_HOME  = /usr/src/packages/BUILD/grass-6.4.0RC6
RUN_GISBASE =
/usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu
RUN_GISRC   =
/opt/grass/demolocation/.grassrc${GRASS_VERSION_MAJOR}${GRASS_VERSION_MINOR}

Also, you need to override MODULE_TOPDIR on the command line, e.g.:

make MODULE_TOPDIR=/usr/local/grass-6.4.0RC6

This is used to locate the *.make files, so setting in those files
won't work. 

Alright. Tried it out by navigating into the folder with r.area. Here are
the results:
l...@pc19384:~/r.area sudo make MODULE_TOPDIR=/opt/grass/
mkdir -p /bin.i686-pc-linux-gnu
mkdir -p /dist.i686-pc-linux-gnu/include/grass
mkdir -p /dist.i686-pc-linux-gnu/lib
mkdir -p /dist.i686-pc-linux-gnu/bin
mkdir -p /dist.i686-pc-linux-gnu/etc
mkdir -p /dist.i686-pc-linux-gnu/driver
mkdir -p /dist.i686-pc-linux-gnu/driver/db
mkdir -p /dist.i686-pc-linux-gnu/fonts
gcc -I/dist.i686-pc-linux-gnu/include  -O2   -DPACKAGE=\grassmods\ 
-I/dist.i686-pc-linux-gnu/include -o OBJ.i686-pc-linux-gnu/main.o -c main.c
main.c:19:23: schwerwiegender Fehler: grass/gis.h: Datei oder Verzeichnis
nicht gefunden
Kompilierung beendet.
make: *** [OBJ.i686-pc-linux-gnu/main.o] Fehler 1

Unfortunately no improvement. Oh man...

The depressed
Daniel
-- 
View this message in context: 
http://osgeo-org.1803224.n2.nabble.com/Installing-r-area-tp5340139p5372689.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


[GRASS-user] Re: Vector attribute query errors on a Mac

2010-08-04 Thread I. Syncrasy

Thank you!
-- 
View this message in context: 
http://osgeo-org.1803224.n2.nabble.com/Vector-attribute-query-errors-on-a-Mac-tp5365200p5373451.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


[GRASS-user] Error when trying to show attribute data on a Mac

2010-08-04 Thread I. Syncrasy

I'm trying to view attribute data for a vector file in the sample North
Carolina data using the GUI. 

My steps:

In the GIS Manager, 

1. Click the Add Vector Layer button in the toolbar
2. Click the Show attribute data in the settings pane below.

The Output window shows the following error:



Bad file descriptor: dup r
dbmi: Protocol error
Unable to start driver dbf



Am I doing something wrong? How do I view attribute data? Is there a dbf
issue on the Mac?
-- 
View this message in context: 
http://osgeo-org.1803224.n2.nabble.com/Error-when-trying-to-show-attribute-data-on-a-Mac-tp5373484p5373484.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


Re: [GRASS-user] Re: Installing r.area

2010-08-04 Thread Glynn Clements

LeeDaniel wrote:

 Its value is used to initialise a few other variables, which need to
  be changed when building without the source tree:
  
  ARCH_DISTDIR = $(GRASS_HOME)/dist.$(ARCH)
  ARCH_BINDIR = $(GRASS_HOME)/bin.$(ARCH)
  ERRORLOG= $(GRASS_HOME)/error.log
  
  If you're building against an installed version, ARCH_DISTDIR should
  be set to the installation directory (e.g. /usr/local/grass-6.4.0RC6),
  ARCH_BINDIR shouldn't matter, and ERRORLOG can be set to any absolute
  filename.
 Alright. I took out the variable $ARCH_DISTDIR and replaced it with
 /opt/grass/. So the three lines the GRASS dirs are now:

 RUN_GISBASE = 
 /usr/src/packages/BUILD/grass-6.4.0RC6/dist.i686-pc-linux-gnu

This should also be /opt/grass (or wherever GRASS is installed).

 Alright. Tried it out by navigating into the folder with r.area. Here are
 the results:

 gcc -I/dist.i686-pc-linux-gnu/include

It would appear that any change to ARCH_DISTDIR was incorrect. The
above is what you would get if you left

ARCH_DISTDIR = $(GRASS_HOME)/dist.$(ARCH)

but GRASS_HOME was unset.

 main.c:19:23: schwerwiegender Fehler: grass/gis.h: Datei oder Verzeichnis
 nicht gefunden
 Kompilierung beendet.

If you're going to post build output to the mailing list, run:

export LC_ALL=C

in the shell before running make.

-- 
Glynn Clements gl...@gclements.plus.com
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Cluster whit area?

2010-08-04 Thread Etienne DELAY (deust 2010)
Hi Dylan and everybody
I'm come back. I have past this week on R for uderstand what you do in
http://casoilresource.lawr.ucdavis.edu/drupal/node/340
Now it's great for R but... I don't understand how make a loop in grass
in the web site we can read

for x in `seq 1 5`
do v.extract --o in=bclust where=cluster=$x out=bclust_$x
v.hull --o in=bclust_$x out=bclust_hull_$x
d.vect bclust_hull_$x type=boundary fcol=none width=2 col=white
d.vect bclust icon=basic/box fcol=black col=black size=6
done

but I have an error and I dont understand very well how work the loop?

My message error is

Sorry 1 is not a valid option
Sorry 5 is not a valid option


Thank you ;-)



-- 
Cordialement

Etienne DELAY
Deust Webmaster et gest. d'intranet (IDSkype : etienne.delay.tic)
Master IUP valorisation du patrimoine et aménagement du territoire
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Cluster whit area?

2010-08-04 Thread Nikos Alexandris
(apologies for interfering...)

Etienne wrote:
 Hi Dylan and everybody
 I'm come back. I have past this week on R for uderstand what you do in
 http://casoilresource.lawr.ucdavis.edu/drupal/node/340
 Now it's great for R but... I don't understand how make a loop in grass
 in the web site we can read
 
 for x in `seq 1 5`
 do v.extract --o in=bclust where=cluster=$x out=bclust_$x
 v.hull --o in=bclust_$x out=bclust_hull_$x
 d.vect bclust_hull_$x type=boundary fcol=none width=2 col=white
 d.vect bclust icon=basic/box fcol=black col=black size=6
 done
 
 but I have an error and I dont understand very well how work the loop?
 My message error is
 
 Sorry 1 is not a valid option
 Sorry 5 is not a valid option

Try out like this:

for x in `seq 1 5`; do
v.extract --o in=bclust where=cluster=${x} out=bclust_${x}
v.hull --o in=bclust_${x} out=bclust_hull_${x}
d.vect bclust_hull_${x} type=boundary fcol=none width=2 col=white
d.vect bclust icon=basic/box fcol=black col=black size=6
done

By the way, I remember reading expert comment in the list that using ${x} is 
rather a good idea.

Cheers, Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] 1-page grass overview

2010-08-04 Thread Hamish
Hi,

for the upcoming FOSS4G conference[1] we have put together a live
dvd[2] with GRASS and a whole bunch of other OSGeo software,
about 40 FOSS geo projects are participating in all.

It would be great if folks could read through the 1-page overview
doc[3] for GRASS (made with reStructured Text and Sphinx if you
wondered), and the 5 minute quickstart tutorial[4].

A full list of project docs on the disc is interesting to look
through as well.[5]

Also if anyone is really keen they can download an ISO of the
DVD[6] and test that it actually works. I've already discovered
that the new QGIS 1.5 grass plugin doesn't like the user not
owning the PERMANENT mapset, even if it's not the one being used.

Test results to the OSGeo wiki[7] and bugs to the osgeo bug
trac'er[8] please (including doc bugs; set component as LiveDVD).


it goes to the printers next week.


[1] http://2010.foss4g.org

[2] http://live.osgeo.org

[3] 
http://download.osgeo.org/livedvd/4.0-rc6/osgeolive-docs/overview/grass_overview.html

[4] 
http://download.osgeo.org/livedvd/4.0-rc6/osgeolive-docs/quickstart/grass_quickstart.html

[5] 
http://download.osgeo.org/livedvd/4.0-rc6/osgeolive-docs/overview/overview.html

[6] http://download.osgeo.org/livedvd/4.0-rc6/

[7] http://wiki.osgeo.org/wiki/Live_GIS_Disc_Testing

[8] https://trac.osgeo.org/osgeo/report/10



thanks,
Hamish



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