[GRASS-user] help with v.db.update

[Sharon M]

I'm trying to update an attribute table column using v.db.update with
the DBF driver and keep getting a dbmi: Protocol error message.

Example using Spearfish

g.copy vect=fields,myfields

v.db.addcol myfields col="polynum integer"

v.db.select myfields where="label like 'V%'"
cat|label|polynum
59|V. White#1|

v.db.update myfields col=polynum val=42 where="label like 'V%'"
dbmi: Protocol error
ERROR: Error while executing: 'UPDATE myfields SET polynum=42 WHERE
label like V%
'

I've tried this on both winGrass 6.4 rc2 or winGrass 6.5 r45847 on
winXP using the wxGUI via both the v.db.update module and the wxgui
command line and get the same error issue.

What am I doing wrong? Can anyone help please?

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

Re: [GRASS-user] Re: Duplication of lines in output of r.profile.

[Hamish]

Marcello wrote:
> I solved it using:
> 
> > d.where > map_profile
> 
> instead of:
> 
> > r.profile -ig input=map output=map_profile
> 
> The only problem is that I can't see the points while I am digitizing.

use the middle mouse button with d.where to show the line.

> > I get many duplicated lines, some of which are not exactly duplicated,
> > but displace the coordinates by a very small distance, affecting also
> > the distance.

what version of GRASS? what kind of machine/OS?
how about if you trim off the 3rd,4th columns from what becomes the input
file?


Hamish

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

Re: [GRASS-user] How to aggregate values of a raster to an area specified by a polygon?

[Hamish]

TimNorwey wrote:
> What I´m planning to do, is to aggregate the calculated solar values given
> by the raster to an area that is specified by a polygon of
> the footprint shapefile. 
> 
> At the end I want to have one average number of incoming
> solar irradiance per sqm for each footprint.


check out the v.rast.stats module.
It's a script, see inside it for the method.



Hamish

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

[GRASS-user] How to aggregate values of a raster to an area specified by a polygon?

[TimNorwey]

Hy all,

I´m calculating solar values using r.sun. As you know the result is a
raster, representing values of global total irradiance.

Beside of this raster I have a shapefile including the footprints of houses.

What I´m planning to do, is to aggregate the calculated solar values given
by the raster to an area that is specified by a polygon of the footprint
shapefile. 

At the end I want to have one average number of incoming solar irradiance
per sqm for each footprint.

I hope you all can understand what I mean??

- I was thinking about to use r.to.vect to create a point file out of the
raster. 
- Then I thought about using v.select, to get only these points that are
inside of the polygons. 
- After doing that I could use v.overlay to extract only those points that
are within a specific polygon (in this case footprint). This step has to be
done for each polygon and that means to get a point file for each
footprint-polygon. 
- Then I could calculate the average value of each point cloud using Open
Office (access to .dbf file).

So I guess my proposed workflow is a little bit inconvenient... And I hope
that someone of you can tell me an easier way of doing that.

Thanks in advance,
Tim

 

--
View this message in context: 
http://osgeo-org.1803224.n2.nabble.com/How-to-aggregate-values-of-a-raster-to-an-area-specified-by-a-polygon-tp6244506p6244506.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: Duplication of lines in output of r.profile.

[Marcello Gorini]

Dear all,

I solved it using:

> d.where > map_profile

instead of:

> r.profile -ig input=map output=map_profile

The only problem is that I can't see the points while I am digitizing. Also,
it demands another line of code to get the actual topographic profile since
d.where only gets the coordinates, instead of sampling the raster.
Still don't know why the method with r.profile doesn't work right though. If
anybody does, I would be glad to "hear".

Thanks,
Marcello.


Marcello Gorini wrote:
> 
> Dear all,
> 
> My problem (a very common one) is that I want to digitize a profile and
> then sample other maps using the extracted coordinates. In order to do so,
> I tried the following;
> 
>>r.profile -ig input=map output=map_profile 
> 
> With that, I managed to digitize the profile and to get the following file
> (a piece of it):
> 
> -8063204.17 4311231.25 0.00 -3769.528809
> -8062653.139926 4312065.737586 1000.00 -3768.805176
> -8062102.113186 4312900.225172 2000.00 -3768.805176
> -8061551.086445 4313734.712758 3000.00 -3767.810791
> -8061000.059705 4314569.200344 4000.00 -3764.308105
> -8060449.032965 4315403.687930 5000.00 -3764.054199
> -8059898.006224 4316238.175517 6000.00 -3763.437500
> -8059346.979484 4317072.663103 7000.00 -3760.115723
> -8058795.952743 4317907.150689 8000.00 -3759.792236
> -8058244.926003 4318741.638275 9000.00 -3758.425537
> 
> Which is correct. I have eastings, northings, distance (which increases in
> steps equal to the resolution of 1000 meters) and then the sampled depth.
> 
> Ok, but the problem appears when I try to use this profile to sample
> another map... 
> 
>>cat map_profile | r.profile -g input=another_map
output=another_map_profile
> 
>  the following happens:
> 
> -8063204.17 4311231.25 0.00 8
> -8062653.139927 4312065.737586 1000.00 8
> -8062653.139926 4312065.737586 1000.00 8
> -8062102.113186 4312900.225172 2000.00 8
> -8061551.086446 4313734.712758 3000.00 8
> -8061551.086445 4313734.712758 3000.00 8
> -8061000.059705 4314569.200344 4000.00 8
> -8060449.032965 4315403.687930 4999.99 8
> -8059898.006225 4316238.175516 5999.99 8
> -8059898.006224 4316238.175517 6000.00 8
> -8059346.979484 4317072.663103 7000.00 8
> -8058795.952744 4317907.150689 8000.00 8
> -8058795.952743 4317907.150689 8000.00 8
> 
> I get many duplicated lines, some of which are not exactly duplicated, but
> displace the coordinates by a very small distance, affecting also the
> distance. The 8 in the last column is correct, don't worry.
> 
> Any ideas about what might be happening?
> 
> I thank you all very much in advance for any help.
> 
> Best regards,
> Marcello.
> 


--
View this message in context: 
http://osgeo-org.1803224.n2.nabble.com/Duplication-of-lines-in-output-of-r-profile-tp6242694p6244412.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 while running a compiled wingrass module in WinXP and win/

[Jenny Turner]

Greetings

After Antonio's reply I tried to run my compiled module in WinGRASS (in
winXP) and in Win7 and it runned ok in WinXP but I got this error in Win7:
This application has requested the Runtime to terminate it
in an unusual way.
Please contact the application's support team for more
information.
And the process was terminated.
Why might be wrong? is there any known limitation of win7 when compared with
winXP?
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Re: Compiling a module in Win OsGEO4w

[antonio . rocha]

Try placing lib... .dll in lib folder. It will work

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

[GRASS-user] Compiling a module in Win OsGEO4w

[Jenny Turner]

Greetings

I have developed a function, which also includes a shared lib
(libsegmentimage.dll) and I have compiled with success in OSGEO4W in
winGRASS. (before that I needed to place  libsegmentimage.dll in
C:\OSGeo4W\usr\src\grass-6.4.svn_src\dist.i686-pc-mingw32\lib .

It has places my binary (i.segment.exe) in
c:\C:\OSGeo4W\usr\src\grass-6.4.svn_src\dist.i686-pc-mingw32\bin\ and
now I want to place it in C:\OSGeo4W\apps\grass\grass-6.4.1. TO do
that I just copied the exe to bin folder but the bin it seems not to
be working because I get this error:
Traceback (most recent call last):
  File "C:/OSGeo4W/apps/grass/grass-6.4.1svn/etc/wxpython/wx
gui.py", line 486, in OnRunCmd

self.goutput.RunCmd(cmd, switchPage=False)
  File "C:\OSGeo4W\apps\grass\grass-6.4.1svn\etc\wxpython\gu
i_modules\goutput.py", line 368, in RunCmd

menuform.GUI().ParseCommand(cmdlist, parentframe=self)
  File "C:\OSGeo4W\apps\grass\grass-6.4.1svn\etc\wxpython\gu
i_modules\menuform.py", line 1866, in ParseCommand

xml.sax.parseString(getInterfaceDescription(cmd[0]).decode(e
nc).split('\n',1)[1].replace('', '\n', 1).encode("utf-8"),
IndexError
:
list index out of range

By the way I have complied like this:

 make -C i.segment MODULE_TOPDIR=/C/OSGeo4W/usr/src/grass-6.4.svn


Can anyone help me?

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

Re: [GRASS-user] Read/Write numpy array

[Glynn Clements]

Johannes Radinger wrote:

> I try to do a mapcalculation with scipy (do to limited functionality of 
> usual mapcalc functions.
> 
> Therefore I want to read a map into numpy-array, do the calculation
> on it and write it back to a GRASS-map. I tried to follow the
> instructions in the wiki
> (http://grass.osgeo.org/wiki/GRASS_and_Python#Interfacing_with_NumPy)
> but I got stucked when it comes to the writing-process.
> Thats my code so far:
> 
> x = garray.array()
> x.read("distance_raster")
> Density = garray.array()
> Density = p * stats.norm.pdf(x,loc=m, scale=s1*K) + (1-p) * 
> stats.norm.pdf(x, loc=m, scale=s2*K)
> Density.write("Density")
> 
> The stats.norm.pdf is from the stats-scipy module. I get following
> error when I try to process the script:
> 
>Density.write("Density")
> AttributeError: 'numpy.ndarray' object has no attribute
> 'write'
> 
> I don't know excactly what how I have to use the write command.

The write() method is part of garray.array, which is a subclass of
numpy.array (specifically, of numpy.memmap).

This line:

> Density = garray.array()

creates an instance of garray.array and associates the name "Density"
with it.

This line:

 Density = p * stats.norm.pdf(x,loc=m, scale=s1*K) + (1-p) * 
stats.norm.pdf(x, loc=m, scale=s2*K)

creates a normal numpy.array and associates the name "Density" with
it, replacing the original association. Consequently, Density.write()
fails because Density now refers to a numpy.array and not a
garray.array().

Rather than making the name Density refer to the resulting
numpy.array, you have to assign the resulting numpy.array *into* the
existing garray.array to which the name Density already refers, i.e.:

 Density[...] = p * stats.norm.pdf(x,loc=m, scale=s1*K) + (1-p) * 
stats.norm.pdf(x, loc=m, scale=s2*K)

Note that the "..." (ellipsis) is literal. The above is equivalent to:

 Density[:,:] = p * stats.norm.pdf(x,loc=m, scale=s1*K) + (1-p) * 
stats.norm.pdf(x, loc=m, scale=s2*K)

> I am working on 6.5 and I read there were some problems with
> numpy-arrays. Are the solved now?

I believe that the issue with grass.script.array requiring the 7.0
version of r.{in,out}.bin has been solved by backporting the changes
into 6.5.

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

[GRASS-user] Duplication of lines in output of r.profile.

[Marcello Gorini]

Dear all,

My problem (a very common one) is that I want to digitize a profile and then
sample other maps using the extracted coordinates. In order to do so, I
tried the following;

>r.profile -ig input=map output=map_profile 

With that, I managed to digitize the profile and to get the following file
(a piece of it):

-8063204.17 4311231.25 0.00 -3769.528809
-8062653.139926 4312065.737586 1000.00 -3768.805176
-8062102.113186 4312900.225172 2000.00 -3768.805176
-8061551.086445 4313734.712758 3000.00 -3767.810791
-8061000.059705 4314569.200344 4000.00 -3764.308105
-8060449.032965 4315403.687930 5000.00 -3764.054199
-8059898.006224 4316238.175517 6000.00 -3763.437500
-8059346.979484 4317072.663103 7000.00 -3760.115723
-8058795.952743 4317907.150689 8000.00 -3759.792236
-8058244.926003 4318741.638275 9000.00 -3758.425537

Which is correct. I have eastings, northings, distance (which increases in
steps equal to the resolution of 1000 meters) and then the sampled depth.

Ok, but the problem appears when I try to use this profile to sample another
map... 

>cat map_profile | r.profile -g input=another_map output=another_map_profile

 the following happens:

-8063204.17 4311231.25 0.00 8
-8062653.139927 4312065.737586 1000.00 8
-8062653.139926 4312065.737586 1000.00 8
-8062102.113186 4312900.225172 2000.00 8
-8061551.086446 4313734.712758 3000.00 8
-8061551.086445 4313734.712758 3000.00 8
-8061000.059705 4314569.200344 4000.00 8
-8060449.032965 4315403.687930 4999.99 8
-8059898.006225 4316238.175516 5999.99 8
-8059898.006224 4316238.175517 6000.00 8
-8059346.979484 4317072.663103 7000.00 8
-8058795.952744 4317907.150689 8000.00 8
-8058795.952743 4317907.150689 8000.00 8

I get many duplicated lines, some of which are not exactly duplicated, but
displace the coordinates by a very small distance, affecting also the
distance. The 8 in the last column is correct, don't worry.

Any ideas about what might be happening?

I thank you all very much in advance for any help.

Best regards,
Marcello.


--
View this message in context: 
http://osgeo-org.1803224.n2.nabble.com/Duplication-of-lines-in-output-of-r-profile-tp6242694p6242694.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] Manual page on how to create/edit/delete Mapsets and Locations

[Alfredo Alessandrini]

http://grass.osgeo.org/gdp/html_grass64/helptext.html


2011/4/5 Monica Buescu :
> Greetings
> Where can I find, if available, a webpage or manual page on how to
> define/create/edit/delete Locations and Mapsets?
> Thanks
> Monica
> ___
> 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] Manual page on how to create/edit/delete Mapsets and Locations

[Monica Buescu]

Greetings

Where can I find, if available, a webpage or manual page on how to
define/create/edit/delete Locations and Mapsets?
Thanks
Monica
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Shell script: d.what.rast

[roberto marzocchi]

Hello,

a simple question!

Running a shell script that I am writing,  I would like to run d.what.rast
on the map display and not in a monitor.  It is possible?

Thanks in advanced to everyone and have a nice day!
RM



--

Roberto Marzocchi

PhD student in Hydrogeology
SUPSI - Institute of Earth Sciences
Via Trevano C.P. 72, 6952 Canobbio, Switzerland
Phone: +41 58  212  Fax: +41 58  209

E-mail: roberto.marzoc...@supsi.ch





--

*'"L'acqua è la forza che dirige la natura - Water is the driving force of
all nature"
Leonardo Da Vinci *
 --



*
Please consider the environment before printing this mail note!*

* *
 Signature powered by

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

[GRASS-user] error opening netcdf file

[Chiara Scaini]

hi everybody
this is my first post :-)

i'm working with meteo data.
usually i open netcdf with qgis and then import them in grass, using 
the r.in.gdal.


grass/qgis error in command line is:

Loaded : GdalTools (package: GdalTools)
 100%
ERROR 4: `/home/cscaini/Desktop/meteo/
WRF-Puerto/prova.nc' not recognised as a supported file format.

 100%
Warning: QProcess: Destroyed while process is still running.
 100%
ERROR 6: No translation an empty SRS to PROJ.4 format is known.
ERROR 6: No translation an empty SRS to PROJ.4 format is known.
ERROR 6: No translation an empty SRS to PROJ.4 format is known.
ERROR 6: No translation an empty SRS to PROJ.4 format is known.
ERROR 6: No translation an empty SRS to PROJ.4 format is known.
ERROR 6: No translation an empty SRS to PROJ.4 format is known.
GRASS 6.4.0 (barcelona):~ > exit^C

i have a .nc file that i cannot import,
so i tryed by command line to investigate what happens
ncdump -h gives a normal output starting like this:

netcdf Con-001.res {
dimensions:
   lon = 151 ;
   lat = 151 ;
   alt = 33 ;
   time = UNLIMITED ; // (25 currently)
variables:
   float lon(lon) ;
   lon:units = "degrees_east" ;
   lon:description = "longitude. East positive" ;
   float lat(lat) ;
   lat:units = "degrees_north" ;
   lat:description = "latitude. North positive" ;
   float alt(alt) ;
   alt:units = "m" ;
   alt:description = "heights (a.s.l.)" ;
   float time(time) ;
   time:units = "h" ;
   time:description = "time after UTC" ;
etc etc etc

but when i try to do a gdalinfo, or translate it into geotiff, this is 
the message i get:


cscaini@cscaini-ThinkPad-T400:~/Desktop$ gdal_translate -a_srs WGS84 
-sds prova2.nc prova-translation

ERROR 4: `prova2.nc' not recognised as a supported file format.

GDALOpen failed - 4
`prova2.nc' not recognised as a supported file format.

cscaini@cscaini-ThinkPad-T400:~/Desktop$ gdalinfo prova2.nc
ERROR 4: `prova2.nc' not recognised as a supported file format.

gdalinfo failed - unable to open 'prova2.nc'.

does everybody know which could be the problem?
this file is generated by WRF weather forecast model, and then 
modified.

(i attached the file)

with packages netcdf, gdal, etc, everything should be ok,
because until today i could manage netcdf without problems directly in 
grass


thank you very much :-)
chiara scaini

WARNING / LEGAL TEXT: This message is intended only for the use of the
individual or entity to which it is addressed and may contain
information which is privileged, confidential, proprietary, or exempt
from disclosure under applicable law. If you are not the intended
recipient or the person responsible for delivering the message to the
intended recipient, you are strictly prohibited from disclosing,
distributing, copying, or in any way using this message. If you have
received this communication in error, please notify the sender and
destroy and delete any copies you may have received.

http://www.bsc.es/disclaimer.htm
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Using r.buffer on image with geographic coordinates

[Ned Horning]

Markus M.

Thanks once again for the advice. I updated to the most recent version 
yesterday and tried v.buffer again but it ran out of memory at around 
the 75% complete mark during the snapping boundaries step. I only have 
5.7 GB physical memory and 5.7 GB swap available. I tried r.grow and 
that appears to have worked just fine. It took about 10 hours but I'm 
not in a rush so that's fine. I look forward to testing the GRASS 7 
version of v.buffer when that is working.


All the best,

Ned

On 04/03/2011 09:07 AM, Markus Metz wrote:

On Wed, Mar 30, 2011 at 1:52 PM, Ned Horning  wrote:

Thanks for the help compiling with v.buffer. I think I'm running the correct
version now but the function still does not complete properly. I pasted the
last several lines from the terminal screen below. I have a feeling I ran
out of memory. Any ideas about what I can try next?


Not sure if the "d.vect: free(): invalid" error means that d.vect
caused the problem.

You could try several things:
- update your grass-6.5 to r45873
- close the grass gui and other applications not really necessary
- now try v.buffer again

The process got killed while snapping boundaries which is rather
memory demanding. Memory consumption for vector operations like
snapping can be substantially reduced in grass 7, but grass 7 still
has only the broken version of v.buffer2 (to be fixed).

Alternatively you could use r.grow.distance on the rasterized version
and set all values larger than the desired buffer distance to NULL

Markus M



--
D0/0: sa: 22
D0/0: current: 22
D0/0:   current = 29, last = 30, lcount = 1
D0/0: sa: 28
D0/0: current: 28
D0/0:   current = 29, last = 34, lcount = 1
D0/0: sa: 28
D0/0: current: 28
Building parts of topology...
Building topology for vector map...
Registering primitives...
1433691 primitives registered
119731336 vertices registered
Number of nodes: 1433605
Number of primitives: 1433691
Number of points: 0
Number of lines: 0
Number of boundaries: 1433691
Number of centroids: 0
Number of areas: -
Number of isles: -
Snapping boundaries...
Killed
GRASS 6.5.svn (NHD_Test):~>

GRASS 6.5.svn (NHD_Test):~>  *** glibc detected *** d.vect: free(): invalid
next size (normal): 0x01a77fc0 ***
=== Backtrace: =
/lib/libc.so.6(+0x775b6)[0x7f32f1a055b6]
/lib/libc.so.6(cfree+0x73)[0x7f32f1a0be83]
/usr/local/grass-6.5.svn/lib/libgrass_vect.6.5.svn.so(Vect_destroy_line_struct+0x28)[0x7f32f35be638]
d.vect(plot1+0xb0a)[0x40876a]
d.vect(main+0x1314)[0x4072d4]
/lib/libc.so.6(__libc_start_main+0xfd)[0x7f32f19acc4d]
d.vect[0x403cd9]
=== Memory map: 
0040-0040c000 r-xp  08:05 206108
/usr/local/grass-6.5.svn/bin/d.vect
0060b000-0060c000 r--p b000 08:05 206108
/usr/local/grass-6.5.svn/bin/d.vect
0060c000-0060d000 rw-p c000 08:05 206108
/usr/local/grass-6.5.svn/bin/d.vect
01a6a000-01a8b000 rw-p  00:00 0
  [heap]
7f32e400-7f32e4021000 rw-p  00:00 0
7f32e4021000-7f32e800 ---p  00:00 0
7f32e8b3c000-7f32e8b48000 r-xp  08:05 531120
/lib/libnss_files-2.11.1.so
7f32e8b48000-7f32e8d47000 ---p c000 08:05 531120
/lib/libnss_files-2.11.1.so
7f32e8d47000-7f32e8d48000 r--p b000 08:05 531120
/lib/libnss_files-2.11.1.so
7f32e8d48000-7f32e8d49000 rw-p c000 08:05 531120
/lib/libnss_files-2.11.1.so
7f32e8d49000-7f32e8d53000 r-xp  08:05 531542
/lib/libnss_nis-2.11.1.so
7f32e8d53000-7f32e8f52000 ---p a000 08:05 531542
/lib/libnss_nis-2.11.1.so
7f32e8f52000-7f32e8f53000 r--p 9000 08:05 531542
/lib/libnss_nis-2.11.1.so
7f32e8f53000-7f32e8f54000 rw-p a000 08:05 531542
/lib/libnss_nis-2.11.1.so
7f32e8f54000-7f32e8f5c000 r-xp  08:05 527981
/lib/libnss_compat-2.11.1.so
7f32e8f5c000-7f32e915b000 ---p 8000 08:05 527981
/lib/libnss_compat-2.11.1.so
7f32e915b000-7f32e915c000 r--p 7000 08:05 527981
/lib/libnss_compat-2.11.1.so
7f32e915c000-7f32e915d000 rw-p 8000 08:05 527981
/lib/libnss_compat-2.11.1.so
7f32e915d000-7f32e916 r-xp  08:05 523508
/lib/libgpg-error.so.0.4.0
7f32e916-7f32e935f000 ---p 3000 08:05 523508
/lib/libgpg-error.so.0.4.0
7f32e935f000-7f32e936 r--p 2000 08:05 523508
/lib/libgpg-error.so.0.4.0
7f32e936-7f32e9361000 rw-p 3000 08:05 523508
/lib/libgpg-error.so.0.4.0
7f32e9361000-7f32e9371000 r-xp  08:05 134688
/usr/lib/libtasn1.so.3.1.7
7f32e9371000-7f32e957 ---p 0001 08:05 134688
/usr/lib/libtasn1.so.3.1.7
7f32e957-7f32e9571000 r--p f000 08:05 134688
/usr/lib/libtasn1.so.3.1.7
7f32e9571000-7f32e9572000 rw-p 0001 08:05 134688
/usr/lib/libtasn1.so.3.1.7
7f32e9572000-7f32e958b000 r-xp  08:05 134634
/usr/lib/libsasl2.so.2.0.23
7f32e958b000-7f32e978a000 ---p 00019000 08:05 134634
/usr/lib/libsasl2.so.2.0.23
7f32e978a000-7f32e978b000 r--p 00018000 08:05 134634
/usr/lib/libsasl2.so.2.0.23
7f32e978b000-7f32e978c000 rw-p 00019000 08:05 134634
/usr/lib/libsasl2.so.2.0.23
7f32e978c000-7f32e97a2000 r-xp  08:05 531562
/lib/libresolv-2.11.1.so

Re: [GRASS-user] Load PostGIS layer with tow geometry columns

[Eloi Ribeiro]

On Tue, Apr 5, 2011 at 13:17, Martin Landa  wrote:

> Hi,
>
> 2011/4/5 Eloi Ribeiro :
> > This is what I'm trying to do:
> > v.in.ogr dsn="PG:host=localhost dbname=bd_ceamsig user=postgres"
> > layer=sch_ambiente.escv_incendios_todos where="anyo=2009" output=temp
>
> missing `format=PostgreSQL` ?
>
> Martin
>
>
Thanks for your quick reply Martin,

Actually it's not a format parameter that I miss but a parameter that would
define which geometry I want to use in case there is more than one geometry
per layer/postgis table.

Example. In my table '*escv_incendios_todos'* I have tow filds/columns with
geometry, one is called geom_23030 (coord. syst. epsg 23030) and the other
geom_4258 (coord. syst. epsg 4258) and a trigger maintaining this
tow geometry's synchronized. In the geometry_columns table there are
tow entry's for the '*escv_incendios_todos' *table:

3970433;"''";"sch_ambiente";"escv_incendios_todos";"geom_23030";2;23030;"MULTIPOLYGON"
3970434;"''";"sch_ambiente";"escv_incendios_todos";"geom_4258";2;4258;"MULTIPOLYGON"

So when I try to load '*escv_incendios_todos'* in GRASS there is no way to
define which geometry I want to use. And the error  'ERROR: Layer
 not available' jumps out.

By now I worked around by deleting the entry with the geometry I'm not
interested on the geometry_columns table and then insert it again.

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

Re: [GRASS-user] Load PostGIS layer with tow geometry columns

[Martin Landa]

Hi,

2011/4/5 Eloi Ribeiro :
> This is what I'm trying to do:
> v.in.ogr dsn="PG:host=localhost dbname=bd_ceamsig user=postgres"
> layer=sch_ambiente.escv_incendios_todos where="anyo=2009" output=temp

missing `format=PostgreSQL` ?

Martin

-- 
Martin Landa  * http://geo.fsv.cvut.cz/~landa
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Load PostGIS layer with tow geometry columns

[Eloi Ribeiro]

Dear all,

Trying to load a PostGIS layer with tow geometry columns it output's the
following error: 'ERROR: Layer  not available'.

If one of the tow geometry's is dropped it works fine. Is there a way to
define witch geometry I wont to load, something like 'geom_column=the_geom'?

This is what I'm trying to do:
*v.in.ogr dsn="PG:host=localhost dbname=bd_ceamsig user=postgres"
layer=sch_ambiente.escv_incendios_todos where="anyo=2009" output=temp*

Thanks in advance! Regards,

Eloi Ribeiro
GIS Analyst
39,45º -4,40º
http://eloiribeiro.wordpress.com
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Read/Write numpy array

[Johannes Radinger]

Hello,

I try to do a mapcalculation with scipy (do to limited functionality of 
usual mapcalc functions.

Therefore I want to read a map into numpy-array, do the calculation on it and 
write it back to a GRASS-map. I tried to follow the instructions in the wiki 
(http://grass.osgeo.org/wiki/GRASS_and_Python#Interfacing_with_NumPy) but I got 
stucked when it comes to the writing-process.
Thats my code so far:

x = garray.array()
x.read("distance_raster")
Density = garray.array()
Density = p * stats.norm.pdf(x,loc=m, scale=s1*K) + (1-p) * 
stats.norm.pdf(x, loc=m, scale=s2*K)
Density.write("Density")

The stats.norm.pdf is from the stats-scipy module. I get following error when I 
try to process the script:

   Density.write("Density")
AttributeError: 'numpy.ndarray' object has no attribute
'write'

I don't know excactly what how I have to use the write command. I am working on 
6.5 and I read there were some problems with numpy-arrays. Are the solved now?

/johannes
-- 
GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit 
gratis Handy-Flat! http://portal.gmx.net/de/go/dsl
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Length of a political boundary

[ambijat]

On 4/5/2011 1:08 PM, Hamish wrote:

ambijat wrote:

No, Hamish,
This is not the case as I see it.

ok, sorry if I misunderstood. how do you get a political boundary
from SRTM data?
The answer to this is by first extracting the vector line (boundary 
line) then converting it to raster line and then finally by r.mapcalc 
substituting the values by corresponding cells. So, this was not a 
problem at all.


Aha! you have given me an idea about using r.slope.aspect let me see how 
I can work it out.


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

Re: [GRASS-user] Length of a political boundary

[Hamish]

ambijat wrote:
> No, Hamish,
> This is not the case as I see it.

ok, sorry if I misunderstood. how do you get a political boundary
from SRTM data? by watershed? is knowing the "length" actually
important? could whatever you are looking at be answered instead
by a less problematic metric like area or proportion?

> My fundamental method is as follows:
> 1. in a 3x3 matrix of neighbours analysis I want to fit in
> one worthy formula.
> 2. For every such matrix there are going to be at least 3
> non-zero values and 6 zero values.

so far sounds like a job for r.mfilter or r.mapcalc's neighbor
modifier,

> 3. as we know that c^2 = a^2 + b^2, i would be counting on
> a = elevation difference between the two adjacent cells, and
> b = 90 meters, which is the resolution of the cell.

ok. is the center cell always non-zero/null? (ie skip over those)

> 4. So, c values for each such set of two adjacent cells can
> be calculated, and a sum of all such values which are actually
> hypotenuse values would give me more accurate value of the total
> length of the boundary.
> 
> This is a kind of algorithm I have in mind. Anybody who can
> translate into formula?

probably it would be r.mapcalc (incredibly versitile), but I
guess you could get a head start by multiplying a r.slope.aspect
slope map into the mix.


good luck,
Hamish

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

Re: SV: [GRASS-user] Vector map text legend

[Hamish]

Hamish:
>> "the way to do this is to use
>> r.category to add category labels to each of your four
>> raster category numbers, then use d.legends's -c flag to
>> hide the value of the number, so only the label is
>> displayed."

Martin Album Ytre-Eide wrote:
> This was exactly what I was looking for. This solves many
> of my legend issues. Thanks a lot.

glad to hear it.

> A follow up question is: Would this be a good way to deal
> with logarithmic values in a legend? 

d.legend use=, but the version from GRASS 6.5 or 7, with Dylan's verbatim patch.
 
> -I convert rasters to have logarithmic values with
> r.mapcal: map = log(old_map,10)
> -This gives me a nice map with a nice legend. One could use
> r.colors -g (logarithmic scaling), but this messes up the
> legend - the legend is still linear- and it does not look
> good.
> -The problem is(my way of doing things) that the category
> numbers are log values as well(say 1-3-5 insted of
> 10-1000-10), which there is noting wrong with, it is
> just not that easy to read. 

use= will draw at whatever levels you give it; I plan to backport
the (anti-)rounding patch for 6.4.2, ie after some time of live
testing. see https://trac.osgeo.org/grass/ticket/1147
feedback welcome.

> So, is it a good idea to add category labels to all values
> (or a range of values) x - 10^x ( so for 1, I add 10 and so
> fort) or is it a better way to do this as well?

It's a matter of taste, but personally I am not a fan of band
rendering- where you (as a human) decide to arbitrarily assign
the category breaks can have a most remarkable(!) effect on how
the map is interpreted by other humans. See "how to lie with
statistics", "how to lie with maps", and other related books &
articles. You'll probably be most convinced by your own data one
day, when you pop one of your own insights after a new rendering.
In nature such thresholds are not so clearly defined. To aid the
viewer of a figure my favourite method is a continuous color
gradation + overlaid contour lines.


but anyway, ... the easiest way to display classes from raster
data in GRASS is to make a r.colors rule set like:

0% blue
25% blue
25% cyan
50% cyan
50% yellow
75% yellow
75% red
100% red

then r.category 'a - b' classes + d.legend use= can work.
hint for the above: remember that if you are careful the map
displayed and the legend displayed can actually be for two
different maps (one of which being a dummy which just exists
for making the legend).

(note to self- verify that GRASS 7 doesn't optimize that step
functionality away)


I think Arc & copycats use class breaks so much in their legends
simply as a matter of the vector-feature heritage of that
software; histogram classes make more sense if you start with
a number of sparse data points. In raster maps (traditionally
GRASS's strong point) it is more a case of continuous gradations.
shrug; just a small theory.


hope it helps,
Hamish

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