Re: [GRASS-user] Possible issue with ps.map

[Dave Roberts]

Dr. Southern,

   Can you provide a link for the code you downloaded?  I didn't find 
it at GISCAN.


Thanks, Dave
--

David W. Roberts office 406-994-5670
Professor   FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
117 AJM Johnson Hall
Montana State University
Bozeman, MT 59717-3460

On 6/1/21 9:28 AM, Timothy Glyn Southern via grass-user wrote:

Good afternoon all,

I am using ps.map to create an OS map for an archaeological site and 
want to add the OS grid lines with their appropriate coordinates.


If I use
grid 100

It produces the lines as desired but only puts the leading 4 digits of 
the coordinates  and omits the 2 trailing zeros.

if however I use

grid 50

it again produces the grid but this time with the correct coordinates, 
all 6 digits.


I am running Grass 7.8 downloaded from Giscan.com 
 
as it is a a “working version” overcoming the as yet un resolved 
wxpython issue for AUR based versions.


Am I doing something wrong or is this a possible bug, either from using 
newer versions of wxpython (4.1.1) or in Grass?


While I am writing is the north arrow option no longer available in 
Grass 7.8 within ps.map? It is no longer listed in the manual for the 
ps.map.


Thanks for


Dr Timothy Glyn Southern
0155 941 8432
0791 076 6814





On 30 May 2021, at 20:00, grass-user-requ...@lists.osgeo.org 
 wrote:


Send grass-user mailing list submissions to
grass-user@lists.osgeo.org 

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.osgeo.org/mailman/listinfo/grass-user
or, via email, send a message with subject or body 'help' to
grass-user-requ...@lists.osgeo.org

You can reach the person managing the list at
grass-user-ow...@lists.osgeo.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of grass-user digest..."


Today's Topics:

  1. Re: bayesian belief network analysis (was r.binfer) (Saulteau Don)


--

Message: 1
Date: Sat, 29 May 2021 12:12:45 -0700
From: Saulteau Don 
To: GRASS user list 
Subject: Re: [GRASS-user] bayesian belief network analysis (was
r.binfer)
Message-ID:

Content-Type: text/plain; charset="utf-8"

OK thanks! I'll see if I can find an old grass executable, compile in a VM
with r.binfer in it or fallback to QGIS and OpenBugs. I thought I'd poke
around cause I prefer analysis in GRASS over any other platform out 
there :)


I've started to assist indigenous nations with assertion and
protection/preservation of their rights with GIS. Some of these analytical
methods like fuzzy/boolean patch modelling, weighted overlays, bayesian
belief networks (BBN) allow them to translate their oral history and
ecological knowledge into tools that help them engage effectively and
meaningfully with other parties such as other nations/governments and
industries who have expressed interest in their lands and resources.

I SO wish I could code or even knew what to ask for in procurement for
these things cause I would.

Been a lowly user, bug reporter, package maintainer and crowd funder.
Continuing to find ways to feed back and wholly contribute into these FOSS
communities any way I can.




Donovan

On Sat., May 29, 2021, 03:12 Markus Neteler,  wrote:


On Sat, May 29, 2021 at 4:20 AM Donovan Cameron 
wrote:


Evening,

I'm attempting to analyze a set of layers (slope, aspect, vegetation,
soil, etc) that have been coded/scored based on expert opinion to output
a probability/suitability map.

I'm looking to apply a bayesian belief network [1] and i've got the
raster layers ready for the inputs and coded like seen in this figure

[2].


There was a grass4 module called r.binfer [3] that did this and I can't
seem to find it with GRASS 78 - deprecated or replaced?


The latest code trace which I could find is this one:

GRASS GIS 5.5:

https://github.com/OSGeo/grass-legacy/tree/releasebranch_5_5/src/raster/r.binfer

I do not recall why the module has been abandoned in GRASS GIS 6
(maybe no particular reason and a volunteer could update it...?).

Another option might be to rely on R and use "rgrass7" to exchange
data between GRASS GIS and R.

Best,
Markus


Searches lead me to either r.regression.multi [4] or r.learn.ml [5] but
i'm not sure where to start with these to get a BBN processed thru them.


SaultDon

[1] 

Re: [GRASS-user] disappearing d.mon

[Dave Roberts]

Thanks Markus!  I'll push this along.

On 5/15/21 3:01 PM, Markus Neteler wrote:

Dave, Ben,

Thanks to Anna and Tomas I now remember that the same happened in
Fedora as well (last year).

It seems that Arch/Manjaro are still missing this upstream fix for
wxPseudoDC.FindObjects crash:
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FwxWidgets%2FPhoenix%2Fpull%2F1849data=04%7C01%7Cdroberts%40montana.edu%7C0414fc5be7c743f8e1a508d917e49a10%7C324aa97a03a644fc91e43846fbced113%7C0%7C0%7C637567093344262380%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=c9XBx4ParX5kgjTPR%2FfqA19n1%2BNPp281L0UTHsiy7vA%3Dreserved=0

(in Fedora, it had been backported in
https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsrc.fedoraproject.org%2Frpms%2Fpython-wxpython4%2Fc%2Ff5471fb86aaae46a686b85c654fcbb98516355e6%3Fbranch%3Drawhidedata=04%7C01%7Cdroberts%40montana.edu%7C0414fc5be7c743f8e1a508d917e49a10%7C324aa97a03a644fc91e43846fbced113%7C0%7C0%7C637567093344262380%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=oZDugXEeBXWfKiubiktVxu4Vlr074%2FAdA0ii3AyXQmI%3Dreserved=0)

Hence it is not directly a GRASS GIS problem but has to be fixed in wxWidgets.
Please contact the maintainer of Arch/Manjaro wxWidgets to patch it
accordingly and release an update (such as Fedora has done).

Best,
Markus



--

David W. Roberts office 406-994-5670
Professor   FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
117 AJM Johnson Hall
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] disappearing d.mon

[Dave Roberts]

Colleagues,

Finally, after probably a year I now have no errors about 
incompatible versions of wxwidgets, wxpython, and GRASS.  However, when 
I execute


d.mon wx0

it pops up the box, but which then spontaneously disappears after about 
10-15 seconds.  It leaves behind the MONITORS/wx0 file.  Honestly I'm 
pretty much at my wits end with wxwidgets.


I run manjaro(arch) linux with the the custom build by Sylvain Poulain at

https://github.com/giscan/AUR-grass

uname -a
Linux sonnyboy 5.4.116-1-MANJARO #1 SMP PREEMPT Sun May 2 11:10:35 UTC 
2021 x86_64 GNU/Linux


Thanks in advance for any help, Dave
--

David W. Roberts office 406-994-5670
Professor   FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
117 AJM Johnson Hall
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] configure file for Fedora 33 and grass-7.8.5

[Dave Roberts]

Michael, you define perseverance.  Markus, you are extraordinarily 
gracious with your time and expertise.  This is a happy outcome that 
demonstrates the depth of commitment of the GRASS community.


Bravo, Dave R.

On 12/23/20 4:39 PM, mdwxman via grass-user wrote:

GRASS GIS 7.8.5 exported compilation log
--
Started compilation: Wed Dec 23 04:40:02 PM CST 2020
--
Errors in:
No errors detected.
--
Finished compilation: Wed Dec 23 04:40:40 PM CST 2020

SUCCESS!!  There was another small hiccough (or is that now spelled 
differently?  The cairo library also needed the devel files and a very 
small error during compilation as ~/raster3d/r3.in.asciialso needed to 
be compiled.  Still, GRASS 7.8.5 is alive.


Thank you Markus for all your patience and help.

Michael Allen
Industrial Weather
763-777-1263

Sent with ProtonMail 
 
Secure Email.


‐‐‐ Original Message ‐‐‐
On Wednesday, December 23, 2020 3:14 PM, mdwxman via grass-user 
 wrote:



Yeah, I noticed that.  Libtiff-devel now installed.

Michael Allen
Industrial Weather
763-777-1263

Sent with ProtonMail 
 
Secure Email.


‐‐‐ Original Message ‐‐‐
On Wednesday, December 23, 2020 2:08 PM, Markus Neteler 
 wrote:



Hi

You need to install the development package as well which includes 
the header .h files:


libtiff-devel

Markus


mdwxman via grass-user > schrieb am Mi., 23. Dez. 2020, 
20:39:


And here's what I get from the dnf install libtiff:

(base) [root@godelsrevenge ~]# dnf install libtiff
Fedora Modular 33 - x86_64 - Updates


   40
kB/s |  15 kB 00:00
Fedora 33 - x86_64 - Updates


   54
kB/s |  16 kB 00:00
Package libtiff-4.1.0-4.fc33.x86_64 is already installed.
Dependencies resolved.
Nothing to do.
Complete!

Could it be that the Fedora 33 gremlins have inserted a
differently-named libtiff version or a different location?

Michael Allen
Industrial Weather
763-777-1263

Sent with ProtonMail


Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, December 23, 2020 1:35 PM, mdwxman
mailto:mdwx...@protonmail.com>> wrote:


Evidently "TIFF" corresponds to libtiff.  I'll attempt to dnf
install.

Michael Allen
Industrial Weather
763-777-1263

Sent with ProtonMail


Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, December 23, 2020 1:32 PM, mdwxman via grass-user
mailto:grass-user@lists.osgeo.org>>
wrote:


Markus:

Who knows what the configure means by "TIFF missing?"  But
here's the configure file and the result:
(base) [root@godelsrevenge grass-7.8.5]# ./configure \
> --with-cxx \
> --with-gdal=/usr/bin/gdal-config \
> --with-proj --with-proj-share=/usr/share/proj \
> --with-geos \
> --with-sqlite \
> --with-nls \
> --with-wxwidgets=/usr/bin/wx-config \
> --with-fftw \
> --with-cairo --with-cairo-ldflags=-ldfontconfig \
> --with-freetype --with-freetype-includes=/usr/include/freetype2 \
> --enable-largefile \
> --without-odbc \
> --with-blas
  

[GRASS-user] six.py

[Dave Roberts]

I compiled 7.8.3 from source successfully.  However, I get an error when 
tying to start a monitor



GRASS GIS 7.8.3 > d.mon wx3

 Mapset  in Location  
GRASS GIS 7.8.3 
> Traceback (most recent call last):
  File "/usr/local/grass78/gui/wxpython/mapdisp/main.py", line 33, in 


import six
ImportError: No module named six


However, six is installed (several places apparently).

python
Python 3.8.3 (default, May 17 2020, 18:15:42)
[GCC 10.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import six
>>>
-

So presumably this is a path problem but I haven't found any useful
posts on the topic yet.

I run

uname -a
Linux luthertucker 5.4.52-1-MANJARO #1 SMP PREEMPT Thu Jul 16 16:07:11 
UTC 2020 x86_64 GNU/Linux


Thanks, Dave
--

David W. Roberts office 406-994-5670
Professor   FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
117 AJM Johnson Hall
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] No module named wx

[Dave Roberts]

Friends,

   I compiled grass_7.8.3from source to run on arch linux (the AUR 
version is broken).  Compiled and installed fine.  Still have problems 
though.


**

d.rast relief
Traceback (most recent call last):
  File 
"/home/dvrbts/grass/rmveg/PERMANENT/.tmp/luthertucker/MONITORS/wx1/render.py", 
line 6, in 

from grass.script import core as grass
  File "/usr/local/grass78/etc/python/grass/__init__.py", line 4, in 


import six
ImportError: No module named six

find /usr/local/grass78 -name six.py
/usr/local/grass78/gui/wxpython/mapdisp/six.py

*

python
Python 3.8.3 (default, May 17 2020, 18:15:42)
[GCC 10.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import six
>>> import wxwidgets

No problems in python, so it looks to be a path problem but six.py is 
clearly in /usr/local/grass78/gui/wxpython/mapdisp



Thanks in advance for any help, Dave Roberts
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] ImportError: No module named six

[Dave Roberts]

I compiled 7.8.3 from source successfully.  However, I get an error when 
tying to start a monitor



GRASS GIS 7.8.3 > d.mon wx3

 Mapset  in Location  
  GRASS GIS 
7.8.3 > Traceback (most recent call last):
  File "/usr/local/grass78/gui/wxpython/mapdisp/main.py", line 33, in 


import six
ImportError: No module named six


However, six is installed (several places apparently).

python
Python 3.8.3 (default, May 17 2020, 18:15:42)
[GCC 10.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import six
>>>
-

So presumably this is a path problem but I haven't found any useful
posts on the topic yet.

I run

uname -a
Linux luthertucker 5.4.52-1-MANJARO #1 SMP PREEMPT Thu Jul 16 16:07:11 
UTC 2020 x86_64 GNU/Linux


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

Re: [GRASS-user] areas with no centroid

[Dave Roberts]

Thanks Helmut

v.extract demo cats=1-100 out=new

worked like a charm!  Sorry I missed your point the first time.

Dave

On 11/27/16 23:46, Helmut Kudrnovsky wrote:

Thanks for the suggestion, but the area with no centroid doesn't
have a cat.


that's exactly what I've meant.

then do v.extract cats="cats of the polygones with cat" to extract only
these polygones you need.

from the v.extract manual :

cats=range
Category values
Example: 1,3,7-9,13




-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/areas-with-no-centroid-tp5297590p5297603.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 mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] areas with no centroid

[Dave Roberts]

Hi Helmut,

   Thanks for the suggestion, but the area with no centroid doesn't 
have a cat.  I think somehow I deleted the centroid instead of the area, 
and the cat went with it.


   It's not really causing any problems I'm aware of; it's just odd.

Thanks, Dave

On 11/27/16 13:24, Helmut Kudrnovsky wrote:

Dave Roberts wrote

After editing a map with wxgui I ended up with 39 areas and 38
centroids.  How do I find and delete the area with no centroid?

I have tried many combinations of v.info, v.category, v.to.db, and
visualizing with d.vect.  If I use v.clean tool=rmarea with slowly
increasing thresholds it gets rid of an area I want before it finds the
one I don't so I don't think it's a sliver.

GRASS GIS 7.3.svn > v.info demo
  . . .
Number of points:   0   Number of centroids: 38
Number of lines:0   Number of boundaries: 112
Number of areas:   39   Number of islands:19
  . . .
GRASS GIS 7.3.svn > v.category demo op=report
Layer/table: 1/demo
type   countminmax
point  0  0  0
line   0  0  0
boundary   0  0  0
centroid  38  1 75
area   0  0  0
face   0  0  0
kernel 0  0  0
all   38  1 75

Thanks, Dave
--
___
grass-user mailing list



grass-user@.osgeo



http://lists.osgeo.org/mailman/listinfo/grass-user


d. vect has following option :

cat: Display category numbers of features

try to display the cat info for the polygones to check where the centroid is
missing.

have then a look at v.extract and extract only these polygones you need.

HTH



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/areas-with-no-centroid-tp5297590p5297591.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 mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] areas with no centroid

[Dave Roberts]

After editing a map with wxgui I ended up with 39 areas and 38 
centroids.  How do I find and delete the area with no centroid?


I have tried many combinations of v.info, v.category, v.to.db, and 
visualizing with d.vect.  If I use v.clean tool=rmarea with slowly 
increasing thresholds it gets rid of an area I want before it finds the 
one I don't so I don't think it's a sliver.


GRASS GIS 7.3.svn > v.info demo
 . . .
Number of points:   0   Number of centroids: 38 
Number of lines:0   Number of boundaries: 112

Number of areas:   39   Number of islands:19
 . . .
GRASS GIS 7.3.svn > v.category demo op=report
Layer/table: 1/demo
type   countminmax
point  0  0  0
line   0  0  0
boundary   0  0  0
centroid  38  1 75
area   0  0  0
face   0  0  0
kernel 0  0  0
all   38  1 75

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

Re: [GRASS-user] min and max raster within polygons

[Dave Roberts]

Thanks Anna.  Wow, only two lines of code!

v.to.rast inp=new_mountains out=new_mountains attr=cat use=attr
r.univar map=srtm zones=new_mountains

Thanks, Dave


On 11/20/16 13:20, Anna Petrášová wrote:

On Sun, Nov 20, 2016 at 3:12 PM, Dave Roberts <drobe...@montana.edu> wrote:

Friends,

   I have succeeded (finally) in heads-up digitizing the mountain ranges of
the Rocky Mountains.  Now I want to know the minimum and maximum elevation
for each range.  I have a suitable DEM, but I cannot figure out a
combination or r.mapcalc or other that will give me this.


I would probably use r.univar with zones option. You have to first
rasterize your vector of ranges.

https://grass.osgeo.org/grass73/manuals/r.univar.html

Anna



   Clearly, what I want is to query a raster within a boundary, not at a
point.

Thanks, Dave
--
___
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] min and max raster within polygons

[Dave Roberts]

Friends,

   I have succeeded (finally) in heads-up digitizing the mountain 
ranges of the Rocky Mountains.  Now I want to know the minimum and 
maximum elevation for each range.  I have a suitable DEM, but I cannot 
figure out a combination or r.mapcalc or other that will give me this.


   Clearly, what I want is to query a raster within a boundary, not at 
a point.


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

Re: [GRASS-user] postgres connection failure SOLVED

[Dave Roberts]

Friends,

   Deleting the postgres installed from source and re-installing 
postgres from pacman (arch linux) solved the problem, although it did 
require a full database dump and restore.


   I still find the interaction between user postgres and systemd init 
files to be confusing, but for now perhaps I'm alright.


Dave

On 11/19/16 11:45, Dave Roberts wrote:

Friends,

   I recently made some changes to postgresql (deleted from package
manager and installed from source 9.5.1).  It was a hassle because they
install in different locations and put the bin files in different
places, etc.  It's all working now, except for GRASS, which seems to be
running a command from the old installation and failing to connect.  E.g.

GRASS GIS 7.3.svn > db.connect driver=pg
database="host=127.0.0.1,dbname=beartooth"
GRASS GIS 7.3.svn > db.tables
DBMI-PostgreSQL driver error:
Connection failed.
could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket
"/run/postgresql/.s.PGSQL.5432"?

HOWEVER

GRASS GIS 7.3.svn > pgsql -h 127.0.0.1 -d beartooth -p 5432
psql (9.5.1)
Type "help" for help.
\d

beartooth=# \d
 List of relations
 Schema |   Name   | Type  | Owner
+--+---+
 public | boundary | table | dvrbts
 public | draft_map| table | dvrbts
   . .  .   .
   . .  .   .
 public | vmap | table | dvrbts
(31 rows)
\q

run from inside GRASS shows that postgres is running and accepting
connections on the default port.

The connection failure message is commonly produced from a mismatch of
versions of postgres, so I'm guessing that somewhere GRASS is trying the
old version.

Any ideas?

Thanks, Dave

GRASS GIS 7.3.svn (r69510)
Linux luthertucker 4.8.7-1-ARCH #1 SMP PREEMPT Thu Nov 10 17:22:48 CET
2016 x86_64 GNU/Linux


___
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] postgres connection failure

[Dave Roberts]

Friends,

   I recently made some changes to postgresql (deleted from package 
manager and installed from source 9.5.1).  It was a hassle because they 
install in different locations and put the bin files in different 
places, etc.  It's all working now, except for GRASS, which seems to be 
running a command from the old installation and failing to connect.  E.g.


GRASS GIS 7.3.svn > db.connect driver=pg
database="host=127.0.0.1,dbname=beartooth"
GRASS GIS 7.3.svn > db.tables
DBMI-PostgreSQL driver error:
Connection failed.
could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket
"/run/postgresql/.s.PGSQL.5432"?

HOWEVER

GRASS GIS 7.3.svn > pgsql -h 127.0.0.1 -d beartooth -p 5432
psql (9.5.1)
Type "help" for help.
\d

beartooth=# \d
 List of relations
 Schema |   Name   | Type  | Owner
+--+---+
 public | boundary | table | dvrbts
 public | draft_map| table | dvrbts
   . .  .   .
   . .  .   .
 public | vmap | table | dvrbts
(31 rows)
\q

run from inside GRASS shows that postgres is running and accepting 
connections on the default port.


The connection failure message is commonly produced from a mismatch of 
versions of postgres, so I'm guessing that somewhere GRASS is trying the 
old version.


Any ideas?

Thanks, Dave

GRASS GIS 7.3.svn (r69510)
Linux luthertucker 4.8.7-1-ARCH #1 SMP PREEMPT Thu Nov 10 17:22:48 CET 
2016 x86_64 GNU/Linux



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

Re: [GRASS-user] new map in wxgui digitizer

[Dave Roberts]

Hi Anna,  yes I can create tickets now.  I'll do that this weekend.

Thanks, Dave

On 11/18/16 10:03, Anna Petrášová wrote:

On Fri, Nov 18, 2016 at 10:41 AM, Dave Roberts <drobe...@montana.edu> wrote:

Friends,

  I am trying to make use of the wxgui digitizer and finding it somewhat
challenging.  One issue is that I like to run from the console (i.e. grass73
-text) and that produces a subtly different widget than if I run from the
gui (i.e. grass73 -gui).  Using the console version, when I try to digitize
a new map (as opposed to editing an existing map) I get the error below.

GRASS GIS 7.3.svn > Traceback (most recent call last):
  File "/usr/local/grass-7.3.svn/gui/wxpython/vdigit/toolbars.py", line 849,
in OnSelectMap
if self.layers[selection] == self.mapLayer:
UnboundLocalError: local variable 'selection' referenced before assignment

and it doesn't digitize any points.

The obvious short term solution is to work from the GUI, but that defeats
much oswhat I am trying to accomplish in scriptable, repeatable analyses.

GRASS GIS 7.3.svn (r69510)

Linux luthertucker 4.8.7-1-ARCH #1 SMP PREEMPT Thu Nov 10 17:22:48 CET 2016
x86_

Thanks, Dave




That's a bug we should fix before release (if it's in 72). I don't
remember, are you able to create a ticket now?

Anna


___
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] new map in wxgui digitizer

[Dave Roberts]

Friends,

  I am trying to make use of the wxgui digitizer and finding it 
somewhat challenging.  One issue is that I like to run from the console 
(i.e. grass73 -text) and that produces a subtly different widget than if 
I run from the gui (i.e. grass73 -gui).  Using the console version, when 
I try to digitize a new map (as opposed to editing an existing map) I 
get the error below.


GRASS GIS 7.3.svn > Traceback (most recent call last):
  File "/usr/local/grass-7.3.svn/gui/wxpython/vdigit/toolbars.py", line 
849, in OnSelectMap

if self.layers[selection] == self.mapLayer:
UnboundLocalError: local variable 'selection' referenced before assignment

and it doesn't digitize any points.

The obvious short term solution is to work from the GUI, but that 
defeats much oswhat I am trying to accomplish in scriptable, repeatable 
analyses.


GRASS GIS 7.3.svn (r69510)

Linux luthertucker 4.8.7-1-ARCH #1 SMP PREEMPT Thu Nov 10 17:22:48 CET 
2016 x86_


Thanks, Dave


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

Re: [GRASS-user] Vector file import formats

[Dave Roberts]

Rich,

   I'm working on a page for my tutorial on "GRASS for Ecologists" 
called "Living with ESRI".  Let me know how your project works out so I 
can benefit from your experience.


Dave

On 10/27/16 11:13, Rich Shepard wrote:


Dave,

  Yes, I have/had this; don't know if it's still on the hard drive ... yes,
it is. There's a SlackBuilds.org package for this and it's still installed.


 For the spatial data you'll have to find a shape file or coverage.


  There is another sub-directory with shapefiles.

  This is all for an idea that I might pursue if there's time for it.

Many thanks,

Rich
___
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] Vector file import formats

[Dave Roberts]

Rich,

   I would look at the excellent MDB-tools package 
(http://mdbtools.sourceforge.net). mdb-export will pull a specific layer 
out of the mdb file.  Unless it's a point coverage it's not going to 
contain spatial data though, and even for point coverages it's rare to 
the the point coordinates in the table.


   The access2csv java.jar program also claims to do .mdb, but I have 
only used it for .accdb files because mdb-export works so well.


   As I recall, you're a linux guy, so you should have little trouble 
with this.


   For the spatial data you'll have to find a shape file or coverage.

Dave

On 10/27/16 10:46, Rich Shepard wrote:

On Thu, 27 Oct 2016, Randal Hale wrote:


The MXD files are just ArcGIS Map documents. They will hold no data -
only symbology.


Randy,

  Therefore, useless to me.


You'll need to get your data out of the personal geodatabase files (the
.mdb files). It's been a while since I've tackled that - I wrote a
tutorial for doing this in QGIS. People have had hit or miss luck with
the
tutorial -
http://www.northrivergeographic.com/qgis-accessing-personal-geodatabase.
It works for me (win 10 64 bit with QGIS).


  I think I still have an .mdb converter here somewhere. I'll go look for
it. I work with only linux and F/OSS tools. And I can still access data
from
20+ years ago. :-)


I know that probably isn't helping much - but - it might get you started.
I don't think there's a straight forward way to push that into GRASS -
there will need to be a few steps before hand.


  Okay. If I decide to pursue this I'll do more digging.

Thanks,

Rich
___
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] meaning of "geometry"

[Dave Roberts]

Thanks Rich.  Comments interspersed.

On 10/25/16 13:33, Rich Shepard wrote:

On Tue, 25 Oct 2016, Dave Roberts wrote:


So now when I see "geometry" in a manual page or GRASS-user posting I
interpret that to mean "vertices, nodes, centroids, and associated
categories ordered by the (not necessarily consecutive) layer numbers" as
that's the essential nature of a record in the coor file that manages all
this.



Obviously that's more operational than conceptual so I was wondering
where the concept of geometry is actually defined.


Dave,

  If I may contribute a thought or two to this thread: there are two
definitions of 'geometry' which we all use. One definition is coordinate
geometry which can be described as where points on a geographic surface are
located; the x, y values.



Right, this is what most of us think of immediately.


  Then there's object geometry. When setting a dinner table it's common to
place plates, glasses, and flatware in designated positions relative to
each
other. Same with the controls in a vehicle: the accelerator is on the
right,
the brake in the center and the clutch on the left (at least here in the
US; it's been decades since I drove in the UK).

  If we think of GRASS' geometry as object geometry, the placement of
vector
objects relative to each other it might lessen any confusion.



But here again is the confusion.  The position of objects relative to 
each other is independent of the number of layers associated with each 
object.  And so it seems to me that when GRASS users talk about 
"geometry" they mean space AND layers combined because they are 
inseparable in the implementation.  Perhaps we need a new word for 
spatial realization and attributes combined rather than geometry.


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

Re: [GRASS-user] meaning of "geometry"

[Dave Roberts]

Dear Markus and Anna,

I'd have to dig a little for man pages, but one interesting example is a 
series of GRASS-user postings on "grass vector model, cats and layers 
concept" from 6/13 which you were central to Markus.  At the time, the 
question was "why does adding a new layer to a map require creating a 
new map?"  And your answer (over two postings) was "Because you need to 
modify vector geometries in order to add a new layer. Categories and 
layers are first and foremost stored together with the geometries... 
[Adding a new layer] ... changes the geometry directly."


Nikos Alexandris (and I) were baffled by this because it doesn't change 
any vertices, nodes, or centroids.


Now, having studied the structure of the coor file I see that adding a 
new layer to a vector object increases the length of that record in the 
coor file, so that all records downstream of that record also have to be 
re-written.  It's simpler and safer to write a new vector object than to 
modify the original.  It would be possible to simulate the expected 
behavior by writing the new map to "tmp", deleting the original map, and 
renaming the tmp map to the original name, but obviously the programmers 
elected not to do that.  It could, however, be easily implemented in a 
shell or python script.


So now when I see "geometry" in a manual page or GRASS-user posting I 
interpret that to mean "vertices, nodes, centroids, and associated 
categories ordered by the (not necessarily consecutive) layer numbers" 
as that's the essential nature of a record in the coor file that manages 
all this.


Obviously that's more operational than conceptual so I was wondering 
where the concept of geometry is actually defined.


Thanks, Dave


On 10/24/16 14:39, Markus Metz wrote:

On Mon, Oct 24, 2016 at 4:07 PM, Anna Petrášová <kratocha...@gmail.com> wrote:

On Mon, Oct 24, 2016 at 9:04 AM, Dave Roberts <drobe...@montana.edu> wrote:

Frequently in GRASS help files or emails in this list the term "geometry" is
used.  Is geometry synonymous with a record in the coor file, or does it
have a broader meaning?


I would say geometry of features, such as points, lines, boundaries,
areas.


and centroids. In most cases, the vector features of interest are only
points, lines, and areas.


Depends on the particular context I guess, could be related to
topology too.


An example of the context, i.e. a particular manual, would be helpful
for clarification.

Markus M


I am actually not sure what is in the coor file, but you
are not supposed to access it directly anyway.

Anna



Thanks, Dave
--



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

[GRASS-user] meaning of "geometry"

[Dave Roberts]

Frequently in GRASS help files or emails in this list the term 
"geometry" is used.  Is geometry synonymous with a record in the coor 
file, or does it have a broader meaning?


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

Re: [GRASS-user] d.what.vect highlighting

[Dave Roberts]

Anna,

Sorry, my two emails arrived in the wrong order due to some odd 
behavior of the email system.  Comments interspersed.


On 10/19/16 08:47, Anna Petrášová wrote:

On Wed, Oct 19, 2016 at 10:07 AM, Dave Roberts <drobe...@montana.edu> wrote:

Recent versions of GRASS (at least as of 7.3, maybe sooner) added a
highlight feature to the wx query tool (or d.what.vect) that paints the
selected feature yellow for identification.  This works well when the map is
all gray polygons, but changes the color scheme of colored thematic maps in
a way I find confusing.

I would have expected that it would only influence the polygon I click on,
but often other polygons change color as well, depending on their cat values
in other tables.

Is there a way to turn this behavior off?


I don't think so. The problem is, it highlights all features with the
same category. Maybe this should be changed to highlight just the
specific feature? The underlying function already supports that, so it
should be easy to change. Should it be in settings perhaps?

You are quite right about this behavior.  It would be nice to have a 
switch between highlighting cats and specific polygons.


As it turns out, however, the issue is related to ticket 3174 (see "map 
display query" email chain of Oct 4), where the query tool is reporting 
all layers, not just the layer specified in the d.vect command.  In this 
case, the highlighting is based on cats in a different layer than the 
one I'm interested in, so perhaps when ticket 3174 is resolved the 
highlighting issue will go away as well.



Please create a ticket for this so that we don't forget about it.

OK. Last time I lacked a mantra and you did the ticket for me.  I'll 
step up and get engaged.


Thanks for your always prompt and helpful answers, Dave


Thank you

Anna



Dave Roberts
--
___
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] d.what.vect highlighting

[Dave Roberts]

Recent versions of GRASS (at least as of 7.3, maybe sooner) added a 
highlight feature to the wx query tool (or d.what.vect) that paints the 
selected feature yellow for identification.  This works well when the 
map is all gray polygons, but changes the color scheme of colored 
thematic maps in a way I find confusing.


I would have expected that it would only influence the polygon I click 
on, but often other polygons change color as well, depending on their 
cat values in other tables.


Is there a way to turn this behavior off?

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

[GRASS-user] d.what.vect highlighting redux

[Dave Roberts]

Actually, the highlight color depends on the map color scheme and isn't 
always yellow.


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

Re: [GRASS-user] boundary vs area in wx0

[Dave Roberts]

Thanks Helmut.  v.build did not help, as the topology was already OK. 
The problem seems to be that the database has come unconnected.  To make 
a long story short


1) I used v.in.ogr on a GDB directory, which produced a single feature 
with 20 layers, only a few of which had spatial data


2) to isolate the one element I was most interested in I did a v.extract 
on layer 20 to create the new map.


3) that worked, except that the database was still attached to layer 20, 
even though the new map only had a single layer.  So,


4) I did a v.db.connect -d layer=20, followed by a v.db.connect layer=1 
on the same table that used to be attached to layer 20.


Now, d.vect newveg doesn't work, but d.vect newveg layer=20 does, and 
the query returns layer 20 results, but layer 20 is no longer attached 
to a table in sqlite so all I get are area and cat.Presumably, some 
permutation of v.category will straighten all of this out.


   In the meantime, I discovered that I could import layers from a GDB 
individually with v.in.ogr, so all is well.


Dave

On 10/12/16 14:33, Helmut Kudrnovsky wrote:

Dave Roberts wrote

I'm having difficulty getting the wx devices to show vector features.
For example, I have a map called newveg.  v.info clearly shows that
newveg has areas, e.g.

Number of points:  0 Number of centroids:  38183
Number of lines:   0 Number of boundaries: 97451
Number of areas:   38183 Number of islands:7112

If I enter

d.vect newveg

it doesn't render anything.  If I enter

d.vect newveg type=area

it doesn't render anything, but if I enter

d.vect newveg type=boundary

I get the boundaries.  Furthermore, even when it doesn't draw anything,
the query tool returns information on polygons I can't see.
Unfortunately, even though

v.db.connect -p newveg

says

Vector map

 is connected by:
layer <1/newveg> table

 in database
/home/dvrbts/grass/romo_gdb/PERMANENT/sqlite/sqlite.db through
driver

 with key

The query tool is returning information on layer 20 that is no longer
connected to newveg (it was once upon a time).

I'm confused

Dave

GRASS 7.3.svn, Linux magicsam 4.6.2-1-ARCH #1 SMP PREEMPT Wed Jun 8
08:40:59 CEST 2016 x86_64 GNU/Linux


tested here with

Number of areas: 989768

rendering takes some time, after finished rendering areas are displayed
without any problem.

try to rebuild topology by eg. v.build map=yourvector



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/boundary-vs-area-in-wx0-tp5290472p5290487.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



--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] ogrinfo vs v.in.ogr of GDB files

[Dave Roberts]

Sorry, not having a good day.  This message below was not intended for 
GRASS.


However, the message that should have been here (to keep the thread from 
breaking)


ogrinfo filename.GDB says that some layers in this file are 
multi-polygon.  However, when I use v.in.ogr on the same file they come 
in as individual polygons (which is what I want), not multi-ploygons 
(i.e. there are as many records in the database file as there are areas).


Id ogrinfo getting this wrong, or is v.in.ogr doing something with the 
cats to make this work?  I'm happy with what it did, but it seems odd.


Dave

On 10/12/16 15:04, Dave Roberts wrote:

Indeed.  I should have held out a little longer on canceling.

Dave


--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] ogrinfo vs v.in.ogr of GDB files

[Dave Roberts]

Indeed.  I should have held out a little longer on canceling.

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

Re: [GRASS-user] query highlight too persistent

[Dave Roberts]

Sorry, closing the query output widget works as well, so maybe that's as 
intended.


Dave

On 10/12/16 13:29, Dave Roberts wrote:

In GRASS 7.3.svn (and maybe earlier) querying a polygon in an wx device
with your mouse highlights the polygon in yellow.  However, the
highlight is too persistent, i.e. a d.erase does not make it go away,
although the render map icon will clear it.


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

[GRASS-user] query highlight too persistent

[Dave Roberts]

In GRASS 7.3.svn (and maybe earlier) querying a polygon in an wx device 
with your mouse highlights the polygon in yellow.  However, the 
highlight is too persistent, i.e. a d.erase does not make it go away, 
although the render map icon will clear it.

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

[GRASS-user] boundary vs area in wx0

[Dave Roberts]

I'm having difficulty getting the wx devices to show vector features.
For example, I have a map called newveg.  v.info clearly shows that 
newveg has areas, e.g.


Number of points:  0 Number of centroids:  38183
Number of lines:   0 Number of boundaries: 97451
Number of areas:   38183 Number of islands:7112

If I enter

d.vect newveg

it doesn't render anything.  If I enter

d.vect newveg type=area

it doesn't render anything, but if I enter

d.vect newveg type=boundary

I get the boundaries.  Furthermore, even when it doesn't draw anything, 
the query tool returns information on polygons I can't see. 
Unfortunately, even though


v.db.connect -p newveg

says

Vector map  is connected by:
layer <1/newveg> table  in database 
 through driver 
 with key 


The query tool is returning information on layer 20 that is no longer 
connected to newveg (it was once upon a time).


I'm confused

Dave

GRASS 7.3.svn, Linux magicsam 4.6.2-1-ARCH #1 SMP PREEMPT Wed Jun 8 
08:40:59 CEST 2016 x86_64 GNU/Linux






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

Re: [GRASS-user] map display query and layers

[Dave Roberts]

Dear Moritz and Helmut,

v.what works perfectly; thanks for that.  Sadly, the issue reflects 
my misunderstanding.  I thought the map display GUI was calling v.what 
with coordinates extracted by the GUI from the mouse click.  I have been 
talking about the map display query tool on wx# all along, so I 
apologize if I have used the wrong vocabulary to describe the problem.


File PERMANENT/.tmp/hostname/MONITORS/wx0/cmd correctly reflects 
the layer request from d.vect, so it shouldn't be too difficult to get 
the GUI query tool to honor that, but I'm just beginning to dig into 
GRASS source code and I wouldn't want to tackle this yet.


Thanks, Dave

On 10/04/16 06:32, Helmut Kudrnovsky wrote:

Dave Roberts wrote

Thanks Helmut, Thanks Anna

I compiled the trunk version, and the map query tool now clearly behaves
differently, but not how I expected

1) it shows all layers in the map query results, regardless of what
layer (if any) was selected in d.vect

I.e.

d.vect map
d.vect map layer=1
v.vect map layer=2

all have identical results in map query.  In addition, specifying layers
that don't exist emits no warning, e.g. d.vect map layer=999
works fine, and behaves the same as any of the d.vect commands above

2) it highlights selected features in yellow, and the selected features
(areas in my case) reflect layer #1, no matter what layer is requested
in d.vect.  I.e. d.vect map layer=2 map queries highlight layer 1.

I had been working on this with a quite complicated imported data set,
so to isolate the behavior more clearly I created the data below



material deleted to reduce the  length



Fyi

http://lists.osgeo.org/pipermail/grass-commit/2016-
October/040536.html

Anna committed the patch to trunk ; so if may be able to switch to trunk
for
compiling, this v.what addition is available there without the need of
manually patching.



-
best regards
Helmut
--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/map-display-query-and-layers-tp5288830p5289152.html
Sent from the Grass - Users mailing list archive at Nabble.com.
___
grass-user mailing list




grass-user@.osgeo



http://lists.osgeo.org/mailman/listinfo/grass-user



___
grass-user mailing list



grass-user@.osgeo



http://lists.osgeo.org/mailman/listinfo/grass-user


AFAIK the map query hasn't been changed by Anna's commit.

v. what (https://grass.osgeo.org/grass73/manuals/v.what.html) has a changed
behaviour by now reckognizing the specified layer.

the same behaviour for the map query may need a separate enhancement ticket.

in the meantime would be v.what an alternative?





-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/map-display-query-and-layers-tp5288830p5289199.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 mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] map display query and layers

[Dave Roberts]

Thanks Helmut, Thanks Anna

I compiled the trunk version, and the map query tool now clearly behaves 
differently, but not how I expected


1) it shows all layers in the map query results, regardless of what 
layer (if any) was selected in d.vect


I.e.

d.vect map
d.vect map layer=1
v.vect map layer=2

all have identical results in map query.  In addition, specifying layers 
that don't exist emits no warning, e.g. d.vect map layer=999

works fine, and behaves the same as any of the d.vect commands above

2) it highlights selected features in yellow, and the selected features 
(areas in my case) reflect layer #1, no matter what layer is requested 
in d.vect.  I.e. d.vect map layer=2 map queries highlight layer 1.


I had been working on this with a quite complicated imported data set, 
so to isolate the behavior more clearly I created the data below


(file ascii.txt)
VERTI:
B 5
 0  0
 0 10
10 10
10  0
 0  0
C 1 1
 8  5
 1  1
B 5
10  0
10 10
20 10
20  0
10  0
C 1 1
18  5
  1 2
B 5
 3  3
 3  7
 7  7
 7  3
 3  3
C 1 1
 5  5
 1  2
B 5
13  3
13  7
17  7
17  3
13  3
C 1 1
15  5
 1  1
(end of file)

then

v.in.ascii input=ascii.txt output=ascii format=standard
g.region vect=ascii
v.category --overwrite option=add input=ascii output=new_ascii
layer=2 type=centroid

# check results

v.category ascii op=report
# 1 layer, 4 centroids with cats 1 & 2
v.category new_ascii op=report
# 2 layers, L1 4 centroids with cats 1,2 L2 4 centroids cats=1,2,3,4

d.vect new_ascii layer=2

# and check results with map query tool

Thanks, Dave


On 10/04/16 01:31, Helmut Kudrnovsky wrote:



  >At any rate, since I did not edit what.c to apply Moritz's patch

none of this affects my issues with map display query or >d.what.vect.
I'll get back to that in a subsequent post.


Fyi

http://lists.osgeo.org/pipermail/grass-commit/2016-
October/040536.html

Anna committed the patch to trunk ; so if may be able to switch to trunk for
compiling, this v.what addition is available there without the need of
manually patching.



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/map-display-query-and-layers-tp5288830p5289152.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 mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] map display query and layers

[Dave Roberts]

Dear Maciek,

Thanks you sincerely for an updated PKGBUILD.  If I delete the 
includes for liblas and python-termcolor it builds successfully. 
Whether or not my previous reassignment of /usr/bin/python (see response 
to Markus) had any effect or whether your PKGBUILD finessed that I don't 
know.  Like the AUR PKGBUILD your PKGBUILD generated an extraordinary 
number of warnings about


 dlsym(acl_get_file): /usr/lib/libfakeroot/libfakeroot.so: undefined 
symbol: acl_get_file


As I expected

pacman -U grass7-7.0.5-1-x86_64.pkg.tar.xz

complained about conflicts with the existing GRASS7; when I approved an 
overwrite it installed fine.


   At any rate, since I did not edit what.c to apply Moritz's patch 
none of this affects my issues with map display query or d.what.vect. 
I'll get back to that in a subsequent post.


Thanks, Dave


On 10/03/16 15:46, Maciej Sieczka wrote:

W dniu 03.10.2016 o 23:18, Markus Neteler pisze:

On Mon, Oct 3, 2016 at 7:12 PM, Dave Roberts <drobe...@montana.edu>
wrote:

Hi Markus,

Given your kind offer I elected to try and compile GRASS again. This
time I was successful (after a few false starts).  The primary
problem was
python confusion, where arch linux assumes python3 as the default,
and I had
not done the symbolic links  correctly to redicrect to python2.
After that

./configure \
   --without-freetype \
   --with-postgress \
   --with-readline

worked successfully.  I'm now testing GRASS-7.0.5.


Hi Dave,

My PKGBUILD may help:
https://gitlab.com/tutturu/grass7_pkgbuild/blob/master/PKGBUILD.
Advertised on https://grass.osgeo.org/download/software/linux/.

Maciek



--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] map display query and layers

[Dave Roberts]

Markus, The material at the wiki (url below) did not work for me, but it 
DID provide the clues I needed to get things to work.  I can't speak for 
other Arch linux users, but I don't have sudo configured and just su to 
root when necessary.  So, the posted script failed when I didn't have 
permission to sudo ln -s.  In addition, since I don't sudo, I don't 
quite understand the path being constructed.  $HOME for someone using 
sudo is presumably their home directory (not root), and creating 
$HOME/usr/bin seems like an odd idea to me.  so,


su
ln -s /usr/bin/python2.7 /usr/bin/python
ln -s /usr/bin/python2.7-config /usr/bin/python-config
exit

worked.  That means that from now on python2 is the default, as opposed 
to python3, but I'm fine with that.  Then, I don't have all the 
libraries required by the config command (notably liblas, maybe more), 
so the config command needed to be edited for me, and there were several 
libraries I didn't include in addition to freetype.  Others may have 
different needs and experiences.


Again, I didn't sudo, but

make
su
make install
exit

worked of course.  Finally, I now have /usr/bin/grass70 as GRASS-7.0.4
and /usr/local/bin/grass70 as GRASS-7.0.5.  /usr/bin precedes 
/us/local/bin so I am at present entering /usr/local/bin/grass70 to 
start GRASS-7.0.5.  I think


mv /usr/bih/grass70 /usr/bin/grass704
mv /usr/local/bin/grass70 /usr/bin/grass705

might be my solution to have both available.

Thanks, Dave

P.S. the subject on this rthread should probably have been switched to 
Arch linux GRASS build, but I left it alone to allow tracking


On 10/03/16 15:18, Markus Neteler wrote:

On Mon, Oct 3, 2016 at 7:12 PM, Dave Roberts <drobe...@montana.edu> wrote:

Hi Markus,

Given your kind offer I elected to try and compile GRASS again. This
time I was successful (after a few false starts).  The primary problem was
python confusion, where arch linux assumes python3 as the default, and I had
not done the symbolic links  correctly to redicrect to python2.  After that

./configure \
   --without-freetype \
   --with-postgress \
   --with-readline

worked successfully.  I'm now testing GRASS-7.0.5.


Glad you solved it! Please verify if all here is ok:

https://grasswiki.osgeo.org/wiki/Compile_and_Install#Arch_Linux

Best,
Markus



--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] map display query and layers

[Dave Roberts]

Thanks Moritz.  This looks like the solution I was looking for.

However, I have not been successful at building GRASS from source for 
quite a long time (just tried again and generated fatal errors in over
50 directories), so it will be a little while before I can test the 
patch. At a first glance, much of it appears to be the use of a TAB in 
python code causing indentation problems, but that is clearly a 
different issue than v.what behavior.


The v.what Makefile has a few environment variables to sort out before I 
can isolate just that program and substitute it in, so I will report on 
test results as soon as I am able.


Thanks, Dave

On 10/02/16 06:23, Moritz Lennert wrote:

On 02/10/16 10:53, Helmut Kudrnovsky wrote:

it seems that d.what.vect [1] reports always all data of all layers.

the same with v.what although the queried layer is specified.

so maybe a bug/enhancement ticket is needed.



https://trac.osgeo.org/grass/ticket/3172

I've attached a patch to v.what. Please test if this solves your problem.

Moritz

___
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] map display query and layers

[Dave Roberts]

Thanks Helmut,

On 10/02/16 02:53, Helmut Kudrnovsky wrote:

{material deleted for space ...}



it seems that d.what.vect [1] reports always all data of all layers.

the same with v.what although the queried layer is specified.

so maybe a bug/enhancement ticket is needed.

[1] https://grass.osgeo.org/grass73/manuals/d.what.vect.html
[2] https://grass.osgeo.org/grass73/manuals/v.what.html



Just to be clear, in my case the problem was not that d.what.vect listed 
ALL the layers (that would have been OK although excessively verbose), 
but rather from click to click I might get different layers reported, 
and even different numbers of layers reported.  Generally the one I 
wanted wasn't included or I would have ignored the problem.


Moritz has proposed a fix to the issue you noted, and it looks like it 
will likely solve my problem as well.  That may take a while to find out 
though.


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

Re: [GRASS-user] map display query and layers

[Dave Roberts]

Hi Vincent,

   I have studied the GRASS_GIS_vector_management_model page (and all 
the discussion leading up to that), and I think I understand the data 
model.  What I don't understand is how the map display interacts with 
the data tables.  So in my example case, yes, there are two tables, both 
with key=cat, but that's pretty typical for data imported into GRASS 
with v.in.ogr or v.in.e00.  I have another case where I imported an ESRI 
GDB, and GRASS created 25 layers all with key=cat.  When I do


d.vect bryceveg

it seems to draw correctly, but when I use the map query icon and mouse 
click it gives me results for layers 22, 23, 25, and 26 (which is not 
connected to a table).  Even if I specify


d.vect bryceveg layer=1

when I query I still get 22, 23, 25, and 26, none of which I want.

   So undoubtedly it's possible (with significant effort) to convert 
this to 25 different vector features each with only one table, but that 
seems like a lot of work, and I would expect when I specify the layer to 
draw that's the layer that gets queried.  If I have time, I'll dig into 
the code (hopefully python) driving the map query.


Thanks, Dave



On 10/01/16 01:04, Vincent Bain wrote:

Hello Dave,

am I wrong or is your map connected to two distinct tables with the same
key (cat) ? then the behavior you describe may be related to a confusion
on the type of features holding 'cat' values. For exemple in the case of
a polygon map, you need to define which type of object handles cats
(i.e. boundaries or centroids).
Just to check, you can have a look at this wiki entry :
https://grasswiki.osgeo.org/wiki/Vector_Database_Management#GRASS_GIS_vector_management_model

Best,
Vincent.

Le vendredi 30 septembre 2016 à 15:47 -0600, Dave Roberts a écrit :

d.vect has an option for layer= but I don't get any consistent effect
from the query tool in the map display.  For example

GRASS GIS 7.0.4 > v.db.connect -p fuel
Vector map  is connected by:
layer <1/LAB> table  in database
 through driver
 with key 
layer <2/ARC> table  in database
 through driver
 with key 

says there two layers to this feature connected to a sqlite database.
I'm interested in the data in layer=2, so

d.vect fuel layer=2

draws the map correctly, but when I click on polygons I get results from
layer 1, not 2.  And sometimes for other maps I get multiple layer
results, but often not the one I want.  It may depend on exactly where I
click (e.g. nearest a centroid (often invisible) vs a boundary) but it
seems more random to me.

GRASS 7.0.4

Linux 4.6.2-1-ARCH #1 SMP PREEMPT x86_64 GNU/Linux

Thanks, Dave
___
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] map display query and layers

[Dave Roberts]

d.vect has an option for layer= but I don't get any consistent effect 
from the query tool in the map display.  For example


GRASS GIS 7.0.4 > v.db.connect -p fuel
Vector map  is connected by:
layer <1/LAB> table  in database 
 through driver 
 with key 
layer <2/ARC> table  in database 
 through driver 
 with key 


says there two layers to this feature connected to a sqlite database. 
I'm interested in the data in layer=2, so


d.vect fuel layer=2

draws the map correctly, but when I click on polygons I get results from 
layer 1, not 2.  And sometimes for other maps I get multiple layer 
results, but often not the one I want.  It may depend on exactly where I 
click (e.g. nearest a centroid (often invisible) vs a boundary) but it 
seems more random to me.


GRASS 7.0.4

Linux 4.6.2-1-ARCH #1 SMP PREEMPT x86_64 GNU/Linux

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

Re: [GRASS-user] GIS software popularity ranking: http://gisgeography.com/mapping-out-gis-software-landscape

[Dave Roberts]

Sadly, it's not just Microsoft users that take the GUI view.  A couple 
of years ago GRASS was reviewed in Linux Journal and they didn't even 
mention it was scriptable.  I wrote a letter to the editor to point that 
out and they responded that that was minimally interesting.


Dave Roberts

On 09/26/16 06:55, Rich Shepard wrote:

On Mon, 26 Sep 2016, Blumentrath, Stefan wrote:


FYI, I could not resist to also commenting on the GRASS "review" here:



Obviously, the authors of the review seem to be lost in new
surroundings.


Stefan,

  When you realize that the majority of computer users who write
articles or
reviews for the Web know only Microsoft's OSes the author's 'cons' make
perfect sense.

  Too many users know only to point-and-click, drag-and-drop, and work in a
pretty GUI. The idea of typing something on a command line is not only
foreigh, but frightening; many have never done so before. When you see
complaints such as 'the toolbars are in a different place' and 'handles
coordinate systems in different locations' it is obvious that the writer is
very limited in understanding what's important: function over form.

  I read reviews like this and know to ignore them. Those readers who
accept
such reviews at face value are equally naive. The focus on the user
interface is typical of those who were taught superficial use of an
application without fully understanding how to use it to solve problems.
The
analogy I use when texplaing my GIS or statistical tools to clients and
others is that one can teach someone how to use a word processor but that
does not make him a writer.

Rich

___
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] v.category chlayer issues

[Dave Roberts]

I have a vector feature with four areas and two layers.   Each of the 
two layers is tied to a different sqlite table.  I'm trying to make what 
is currently layer 2 the default, and to delete the no longer needed 
layer 1.  I tried


v.category inp=new_ascii op=chlayer type=centroid layer=2,1 out=fixed
WARNING: Database connection and attribute tables for concerned layers are
 not changed
Processing features...

but it never stops processing and I have to kill it.  The vector feature 
new_ascii only has four areas, so it's not computationally intensive. 
new_ascii layer 1 and 2 are both tied to a sqlite table.


I've looked at op=transfer, but haven't had luck with that yet either.

GRASS 7.0.4 on Arch linux if that matters.


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

Re: [GRASS-user] create location from CLI

[Dave Roberts]

Paul,

On 09/06/16 16:28, Paul Kelly wrote:


The proj4 parameter in g.proj takes a PROJ string description, not a
file containing one.
So,
g.proj -c proj4="+proj=longlat +datum=WGS84"

should work, as far as I can think.



  Indeed it does, and that seems to be the end of the line.  So it's 
possible to create an arbitrary locations with nothing but projection 
information (no data yet), but it takes two lines of code.  That works 
for me.  When I migrate to 7.2 apparently I can do it in one.


Thanks all, Dave



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

Re: [GRASS-user] create location from CLI

[Dave Roberts]

Thanks for clarification Markus, and thanks Helmut for similar input. 
So, the last problem is that


g.proj -c proj4=-

followed by input to stdin works, but I cannot seem to construct a file 
with proj4 parameters that g.proj will accept, even though identical 
information entered at stdin works.  So, I'm still struggling for the 
syntax of aproj4 file I guess.


Thanks all, Dave

On 09/06/16 14:37, Markus Neteler wrote:

Hi,

On Sep 6, 2016 9:25 PM, "Dave Roberts" <drobe...@montana.edu
<mailto:drobe...@montana.edu>> wrote:


Hi Ken, Hi Sajid,

   Thanks for the pointers.  I think my problem is that grass70 and

g.proj parse the files differently.  I.e.,


Here is file teste.prj

PROJCS["Lambert_Conformal_Conic",
GEOGCS["GCS_WGS_1984",
DATUM["D_WGS_1984",
SPHEROID["WGS_1984",6378137,298.257223563]],
PRIMEM["Greenwich",0],
UNIT["Degree",0.017453292519943295]],
PROJECTION["Lambert_Conformal_Conic"],
PARAMETER["standard_parallel_1",40],
PARAMETER["standard_parallel_2",45],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",-109],
PARAMETER["false_easting",0],
PARAMETER["false_northing",0],
UNIT["Meter",1]]

The following does not work

grass70 -e -c teste.prj teste

Creating new GRASS GIS location/mapset...
ERROR: ERROR 4: `teste.prj' not recognised as a supported
file format.

ERROR: Could not read georeferenced file teste.prj using either OGR nor
   GDAL


Yes because it is not a raster or vector file.


However, this does work

grass70 -c teste
g.proj -c wkt=teste.prj


This one is right.


   I'm having even worse luck with PROJ4 syntax of files.


AFAIK that's only supported in g.proj.

Markus



--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] create location from CLI

[Dave Roberts]

Hi Ken, Hi Sajid,

   Thanks for the pointers.  I think my problem is that grass70 and 
g.proj parse the files differently.  I.e.,


Here is file teste.prj

PROJCS["Lambert_Conformal_Conic",
GEOGCS["GCS_WGS_1984",
DATUM["D_WGS_1984",
SPHEROID["WGS_1984",6378137,298.257223563]],
PRIMEM["Greenwich",0],
UNIT["Degree",0.017453292519943295]],
PROJECTION["Lambert_Conformal_Conic"],
PARAMETER["standard_parallel_1",40],
PARAMETER["standard_parallel_2",45],
PARAMETER["latitude_of_origin",0],
PARAMETER["central_meridian",-109],
PARAMETER["false_easting",0],
PARAMETER["false_northing",0],
UNIT["Meter",1]]

The following does not work

grass70 -e -c teste.prj teste
Creating new GRASS GIS location/mapset...
ERROR: ERROR 4: `teste.prj' not recognised as a supported
file format.

ERROR: Could not read georeferenced file teste.prj using either OGR nor
   GDAL

However, this does work

grass70 -c teste
g.proj -c wkt=teste.prj

   I'm having even worse luck with PROJ4 syntax of files.

Sajid, I have no problem getting EPSG specs to work, but that's a lttle 
too indirect for the audience I'm trying to reach.


Thanks, Dave




On 09/06/16 08:12, Ken Mankoff wrote:


On 2016-09-06 at 13:21, Dave Roberts <drobe...@montana.edu> wrote:

I'm trying to understand the simplest way in GRASS7 to create a
location from the command line without using a georeferenced file. So
far, it appears to be

% grass70 -c newLocation

at the OS prompt, followed by

GRASS GIS 7.0.4 > g.proc -c wkt=some WKT text file


You say "without using a georeferenced file" but then use the WKTfile. Why not 
use that at the CLI?

grass70 -e -c WKTfile newLocation
grass70 ./newLocation/PERMANENT

I do it in two lines and use -e on the first so that if I run this again, and 
the location exists, it will still launch GRASS. If you just do the first line 
w/o -e, GRASS won't start if the location exists.


I can't seem to get g.proj to parse any proj4 strings either from
stdin or a file, even substituting the output from a g.proj -j command
from a working location.


A MWE would help debugging.

  -k.



--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] create location from CLI

[Dave Roberts]

Dear All,

   I'm trying to understand the simplest way in GRASS7 to create a 
location from the command line without using a georeferenced file.  So 
far, it appears to be


% grass70 -c newLocation

at the OS prompt, followed by

GRASS GIS 7.0.4 > g.proc -c wkt=some WKT text file

inside of the new GRASS location (which temporarily has a generic XY 
non-projection).   Two things:


1) I can't seem to coerce grass70 or g.proj to do this in a single step 
from the OS command line (probably missing environment variables when 
trying to go straight to g.proj from OS CLI).


2) I would prefer to use g.proj -c proj4=some PROJ4 string or file but I 
can't seem to get g.proj to parse any proj4 strings either from stdin or 
a file, even substituting the output from a g.proj -j command from a 
working location.


GRASS 7.0.4

grass70 --config
x86_64-pc-linux-gnu
./configure  --prefix=/opt/grass 
--with-freetype-includes=/usr/include/freetype2 --with-wxwidgets 
--with-readline --with-pthread --with-netcdf --with-nls --with-geos 
--with-postgres


uname -a
Linux luthertucker 4.6.4-1-ARCH #1 SMP PREEMPT Mon Jul 11 19:12:32 CEST 
2016 x86_64 GNU/Linux


Thanks, Dave
--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] d.out.file format=png file malformed

[Dave Roberts]

Friends,

I'm using GRASS 70-svn on Arch linux to generate figures for a 
report.  The general process is


1) GRASS - d.out.file format=png
2) xfig - import the PNG file, annotate, and export as PDF
3) TeX - import the file in a dvipdfm \special

   However, I'm now having problems with non-functional PNG files from 
d.out.file.  Just below is a paste from my console.  You can't see the 
error from inside xfig, but the line just below xfig is the stderr 
output from attempting to import demo_png.png.


***
GRASS 7.0.svn  d.out.file out=demo_png.png format=png size=800,600

  Mapset final in Location beartooth
GRASS 7.0.svn  xfig
Warning: translation table syntax error: Missing '(' while parsing 
action sequence

'arning: ... found while parsing ':~CtrlKey1: insert-string(1)
Warning: String to TranslationTable conversion encountered errors
libpng error: invalid file gamma in png_set_gamma
***

   The resulting PNG file will import into Imagemagick OK, and can then 
be exported back out as a PNG file which xfig will accept, so there is a 
work around, but maybe this is easily fixed?  I've had a look at Anna's 
python script but haven't gone into the imported modules.


Thanks, Dave
--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] d.out.file format=png file malformed

[Dave Roberts]

Hi Anna,

   I hadn't tried gimp yet so I installed it to see.  Works fine in 
both gimp and Imagemagick, so I guess it's an xfig thing.  I'm running 
xfig 3.2.5c which is only slightly newer than yours, but maybe that 
broke it.


Thanks, Dave

On 07/18/2014 01:00 PM, Anna Petrášová wrote:

Hi,


On Fri, Jul 18, 2014 at 1:56 PM, Dave Roberts
dvr...@ecology.msu.montana.edu mailto:dvr...@ecology.msu.montana.edu
wrote:

Friends,

 I'm using GRASS 70-svn on Arch linux to generate figures for a
report.  The general process is

1) GRASS - d.out.file format=png
2) xfig - import the PNG file, annotate, and export as PDF
3) TeX - import the file in a dvipdfm \special

However, I'm now having problems with non-functional PNG files
from d.out.file.  Just below is a paste from my console.  You can't
see the error from inside xfig, but the line just below xfig is
the stderr output from attempting to import demo_png.png.

**__**__***
GRASS 7.0.svn  d.out.file out=demo_png.png format=png size=800,600

   Mapset final in Location beartooth
GRASS 7.0.svn  xfig
Warning: translation table syntax error: Missing '(' while parsing
action sequence
'arning: ... found while parsing ':~CtrlKey1: insert-string(1)
Warning: String to TranslationTable conversion encountered errors
libpng error: invalid file gamma in png_set_gamma
**__**__***

The resulting PNG file will import into Imagemagick OK, and can
then be exported back out as a PNG file which xfig will accept, so
there is a work around, but maybe this is easily fixed?  I've had a
look at Anna's python script but haven't gone into the imported modules.


I have never had any problems with exported images from GRASS.
d.out.file uses the same mechanism as when you use the toolbar button in
map display. I tried to get the png into xfig and it didn't complain
(xfig version 3.2.5b). Any other image processing tools have problems
(e.g. gimp)?

Anna


Thanks, Dave
--
~~__~~__
David W. Roberts office
406-994-4548 tel:406-994-4548
Professor and Head  FAX
406-994-3190 tel:406-994-3190
Department of Ecology email
drobe...@montana.edu mailto:drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
_
grass-user mailing list
grass-user@lists.osgeo.org mailto:grass-user@lists.osgeo.org
http://lists.osgeo.org/__mailman/listinfo/grass-user
http://lists.osgeo.org/mailman/listinfo/grass-user




--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] wxgui fails using scripts

[Dave Roberts]

Hi Markus,

   Sorry, I misspoke.  I did mean wx0.  I work from the command line, 
not the full GUI.   I think of wx0 as also a GUI due to the toolbar at 
the top.


   Even the simple script below occasionally fails on the d.vect command

d.erase
g.region study
d.his h=elev i=hillshd
d.vect boundary type=boundary col=white

Dave


On 06/17/2014 11:26 AM, Markus Neteler wrote:

Dave,

On Mon, Jun 16, 2014 at 9:59 PM, Dave Roberts
...

 Then simply sh litho.sh would produce the reuslts I wanted, and if I
decided on a different color scheme it was a trival matter to edit the file.

In wxgui this no longer works, as after the first one or two lines GRASS
reponds with



Did you try the standalone monitor?

d.mon wx0
(also wx1, wx2 etc)

It still suffers from being very slow but should listen to the command line.

Markus



--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] wxgui fails using scripts

[Dave Roberts]

Dear all,

   I frequently want a thematic map for a variable that is not numeric, 
and thus not permisaable in d.vect.thematic.  In the past a simple 
solution was to write a shell script with d.vect commands.  For example, 
I could create a file called litho.sh with the following lines


d.vect litho type=area where=litho='i' col=red fcol=red
d.vect litho type=area where=litho='m' col=orange fcol=orange
d.vect litho type=area where=litho='s' col=yellow fcol=yellow
d.vect litho type=area where=litho='v' col=green fcol=green
d.vect litho type=area where=litho='w' col=blue fcol=blue
d.vect litho type=area where=litho='x' col=purple fcol=purple

Then simply sh litho.sh would produce the reuslts I wanted, and 
if I decided on a different color scheme it was a trival matter to edit 
the file.


   In wxgui this no longer works, as after the first one or two lines 
GRASS reponds with


d.vect complete.
d.vect complete.
ERROR: No graphics device selected. Use d.mon to select graphics device.
ERROR: No graphics device selected. Use d.mon to select graphics device.
  . . .   .  ...   .   ..   .

etc for each line in the file.  Presumably it's some sort of a buffer 
overflow problem, but it's making my library of scripts useless.  Simply 
pasting the contents of the file into the console with a mouse produces 
the same result.


  Anybody have any good ideas?  I tried inserting a sleep command in 
between each line of the script, and that worked if the sleep interval 
was long enough (2 seconds in my case), but that seems a little silly.


  I realize that I could add a column to the table with a numeric value 
for each value, but I try to avoid arbitrary integer codes that require 
a foreign key to another table to interpret.


Thanks, Dave

Arch linux 3.14.1-1-ARCH, GRASS 70-svn
--
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] d.what.vect in GRASS 7

[Dave Roberts]

Friends,

Would it be possible to get d.what.vect back in GRASS 7?  The 
current query tool works OK if I don't have too many maps loaded, but it 
oftern returns an extensive list of stuff I'm not interetsed in and 
buries what I'm after.


   E.g., if I execute multiple d.vect commands with the same map but 
different where=something qualifiers it prints out the query results 
for every instance of the map instead of just once.  If I have multiple 
maps layered on each other I get a result for everything, including 
separate query results fron each color in d.rgb.


  With d.what.vect I didn't even have to have the map displayed I 
wanted to query, I just had to have a map plotted to define the coordinates.


  I don't mean to be griping, I LOVE the pan and zoom functions of the 
wx d.mons; I just miss d.what.vect.


Thanks, Dave
--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] random points through multiple vector maps

[Dave Roberts]

Friends,

   Sorry, this DID work for points inside the polygon of interest.

   I guess I was too tired.

Dave

On 05/30/2014 05:42 PM, Dave Roberts wrote:

Friends,

I am trying to drop random points through two vector maps to
establish the correspondence between them.  I couldn't figure out how to
do that with v.random so I created a database table with 10,000 random
points within the bounds of the region, and then used v.in.db to bring
the points in as a vector map.  Then I tried v.what.vect using the
random points on a vegetation map, but v.what.vect failed as noted below

v.what.vect map=rnd_points column=vmap_veg qmap=vmap qcolumn=vegtype
Finding nearest features...
  100%
Update vector attributes...
  100%
5049 categories - no nearest feature found
v.distance complete. 1 records updated.

So 10,000 points were updated to NULL because no nearest feature was
found.  Can somebody explain to me what went wrong or how to fix it?

OS: 3.12.6-1-ARCH
GRASS: grass70-svn

Thanks, Dave


--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] random points through multiple vector maps

[Dave Roberts]

Friends,

   I am trying to drop random points through two vector maps to 
establish the correspondence between them.  I couldn't figure out how to 
do that with v.random so I created a database table with 10,000 random 
points within the bounds of the region, and then used v.in.db to bring 
the points in as a vector map.  Then I tried v.what.vect using the 
random points on a vegetation map, but v.what.vect failed as noted below


v.what.vect map=rnd_points column=vmap_veg qmap=vmap qcolumn=vegtype
Finding nearest features...
 100%
Update vector attributes...
 100%
5049 categories - no nearest feature found
v.distance complete. 1 records updated.

So 10,000 points were updated to NULL because no nearest feature was 
found.  Can somebody explain to me what went wrong or how to fix it?


OS: 3.12.6-1-ARCH
GRASS: grass70-svn

Thanks, Dave
--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] .lyr legends from ArcInfo grid

[Dave Roberts]

Johannes,

  pvanb has a post on is blog about this.  Look at

http://pvanb.wordpress.com/?s=lyr

It's a post from Feb 5

Dave

On 02/25/2014 06:07 AM, Johannes Radinger wrote:

Hi all,

just I short question. Although I don't think that is possible, but is
there a way to import/use a legend file (*.lyr) from a ArcGIS raster (
ArcInfo grid file, *.adf files) within GRASS?

/Johannes



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


--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] broken d.mon

[Dave Roberts]

Ultimately had to recompile GRASS-6.4.3 to get d.mon to work again.  The 
make generated numerous errors, but much to my surprise make install 
worked and solved my problem (at least for now).


Dave

On 02/21/2014 02:08 PM, Vaclav Petras wrote:




On Fri, Feb 21, 2014 at 4:06 PM, Dave Roberts
dvr...@ecology.msu.montana.edu mailto:dvr...@ecology.msu.montana.edu
wrote:

Hi Vaclav,

Happy to stay on list.  I'm grateful for all the help I've
received here.

So, the problem is not with compilation.  GRASS64 was working
well on my system (except for v.dissolve and lib gmath, see other
list issues).  Oddly, when I mistakenly entered d.mon wx0 it not
only didn't work (which should be expected), it disabled all the
other monitor options (seemingly permanently).  When I changed to
another location the problem persisted which really surprised me.

I'm not sure if I'm able to help more. One more thing. What do you have
in `$HOME/.grassrc6`?

I have:

GISDBASE: /.../grassdata
LOCATION_NAME: nc_spm_08
MAPSET: PERMANENT
MONITOR: x0
GRASS_GUI: wxpython

Fortunately I have other machines to work on, but this is my
primary machine for a large research project that emphasized GRASS.
  I'm in the process of moving to GRASS7, but I couldn't get it to
compile on this machine (Markus N is helping me with that), so I
stayed with GRASS64.

Thanks, Dave


On 02/21/2014 01:52 PM, Vaclav Petras wrote:

Hi Dave,

let's keep the conversation on list. I hope you don't mind.

On Fri, Feb 21, 2014 at 2:57 PM, Dave Roberts
dvr...@ecology.msu.montana.__edu
mailto:dvr...@ecology.msu.montana.edu
mailto:dvr...@ecology.msu.__montana.edu
mailto:dvr...@ecology.msu.montana.edu

wrote:

 Hi Vaclav,

  Thanks for your help.  I'm running Scientific Linux 6
 (EL6-based).  when I enter d.mon x0 it says there is no
such monitor.


Isn't there some problem with compilation? I'm not sure if this
is even
possible but maybe compilation can be set in the way that no
monitors
are included.

 The command

 d.mon -l



 generates

 no known monitors

Hm, now I understand what you are saying, -l behavior differs
for 6 and 7.

http://grass.osgeo.org/__grass64/manuals/d.mon.html
http://grass.osgeo.org/grass64/manuals/d.mon.html
http://grass.osgeo.org/__grass70/manuals/d.mon.html
http://grass.osgeo.org/grass70/manuals/d.mon.html

 So, no x0-9, no png, no nothing.

 Thanks, Dave



 On 02/21/2014 10:56 AM, Vaclav Petras wrote:

 What happens if you write

 d.mon x0

 ?

 Note that X monitors does not work on MS Windows.


 On Fri, Feb 21, 2014 at 12:17 PM, Dave Roberts
 dvr...@ecology.msu.montana.edu
 mailto:dvr...@ecology.msu.__montana.edu
mailto:dvr...@ecology.msu.montana.edu
 mailto:dvr...@ecology.msu.
mailto:dvr...@ecology.msu.__m__ontana.edu http://montana.edu

 mailto:dvr...@ecology.msu.__montana.edu
mailto:dvr...@ecology.msu.montana.edu

 wrote:

  Hi Martin,

  Thanks.  I do understand that.  But now I have
no X
 monitors
  (nor png or anything else for that matter).

  Dave


  On 02/21/2014 09:18 AM, Martin Landa wrote:

  Hi,

  2014-02-21 17:10 GMT+01:00 Dave
  Robertsdvr...@ecology.msu.__montana.edu
http://m__ontana.edu
 http://montana.edu
 mailto:dvr...@ecology.msu.
mailto:dvr...@ecology.msu.__m__ontana.edu http://montana.edu

 mailto:dvr...@ecology.msu.__montana.edu
mailto:dvr...@ecology.msu.montana.edu:


  d.mon wx0

  in GRASS64.  It not only did not display,
now no
 monitors
  exist, i.e.


  this is not possible in G6. Here d.mon works with
 X-based monitors,
  ie. d.mon x0.

  Martin


  --



~~__~~__~~__~~__
  David W. Roberts
   office
406-994-4548 tel:406-994-4548 tel:406-994-4548
tel:406-994-4548 tel:406-994-4548 tel:406-994-4548

 tel:406-994-4548 tel:406-994-4548
  Professor and Head
  FAX
406-994-3190 tel:406-994-3190 tel:406-994-3190

Re: [GRASS-user] libgrass_gmath

[Dave Roberts]

Markus,

   Despite (or perhaps because of) downloading and installing new 
wxPython, gdal, fftw, and others I have forgotten, compiling 
grass7_trunk generated numerous errors.  libgrass_gmath.7.0.svn.so 
compiled successfully, but then whether I set --with-fftw or 
--without=fftw libgrass_gnath generated numerous errors related to 
missing references in fftw.  E.g. in r.gwflow


/libgrass_gmath.7.0.svn.so: undefined reference to `fftw_execute'
/libgrass_gmath.7.0.svn.so: undefined reference to `fftw_plan_dft_2d'
/libgrass_gmath.7.0.svn.so: undefined reference to `fftw_destroy_plan'

  I noticed that the routines generating the errors are routines I 
don't call, so despite the errors I tried make install and it worked!

However, I still have the problem that v.dissolve doesn't work.

Oh well, at least I can get back to work, Dave


On 02/19/2014 04:05 PM, Markus Neteler wrote:

Thanks for the good words, Dave - no need for that!

Quick notes inline, it is already tomorrow here:

On Wed, Feb 19, 2014 at 11:52 PM, Dave Roberts
dvr...@ecology.msu.montana.edu wrote:

Hi Markus,

   You're a saint.  I'm at work right now, so I'll have to run the suggested
commands below when I get home.  I did cd into gmath, but I don't remember
the error, so I'll re-run.


sure - tomorrow I'll be travelling, so I may take some time to answer.


In the meantime, I built grass70-svn on my Arch box from the AUR
repository.  It had an unresolved dependency on liblas, which I thought was
perhaps a typo for libblas.  Nonetheless I deleted the reference to liblas
in the Makefile and it built successfully (at least as far as I can tell).


Please always post these errors so that we get the sorted out...


I prefer to run from the CLI, but I did think that d.mon x0 was a pretty
primitive beast.  Now with d.mon wx0 I have reversible zoom and pan, and
that's sweet!


Great, I am likewise happy about that for myself.


Apparently some of my 6.4.2 vectors are in topology 5.0 and need rebuilt,
so It looks like I shouldn't mix 6.4.2 and 7.0 on the same location.


Well, you can do (or simply keep it separated by mapset - a same
location is fine.

Nonetheless we have the easy thing to automate it all:
http://grasswiki.osgeo.org/wiki/Convert_all_GRASS_6_vector_maps_to_GRASS_7


You're a scholar and a gentleman, Dave


You are most welcome.

Markus



--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] libgrass_gmath

[Dave Roberts]

Hi Markus,

   Installing fftw-devel is what got libgrass_gmath to compile without 
errors, but it didn't help downstream.  I'm sure you're right about the 
cascade; I feel close, but can't quite get there yet.


Dave

On 02/23/2014 04:06 PM, Markus Neteler wrote:

Dave,

On Sun, Feb 23, 2014 at 11:58 PM, Dave Roberts
dvr...@ecology.msu.montana.edu wrote:

Markus,

Despite (or perhaps because of) downloading and installing new wxPython,
gdal, fftw, and others I have forgotten, compiling grass7_trunk generated
numerous errors.  libgrass_gmath.7.0.svn.so compiled successfully, but then
whether I set --with-fftw or --without=fftw libgrass_gnath generated
numerous errors related to missing references in fftw.  E.g. in r.gwflow

/libgrass_gmath.7.0.svn.so: undefined reference to `fftw_execute'
/libgrass_gmath.7.0.svn.so: undefined reference to `fftw_plan_dft_2d'
/libgrass_gmath.7.0.svn.so: undefined reference to `fftw_destroy_plan'


Do you have both fftw and fftw-devel installed?


   I noticed that the routines generating the errors are routines I don't
call, so despite the errors I tried make install and it worked!
However, I still have the problem that v.dissolve doesn't work.


This will be a cascaded dependency issue: once
libgrass_gmath.7.0.svn.so is right, also v.dissolve will start to
work.

Markus



--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] broken d.mon

[Dave Roberts]

Friends,

   I have broken my copy of GRASS 6.4.3.  Impressed with the GRASS70 
display, I foolishly tried


d.mon wx0

in GRASS64.  It not only did not display, now no monitors exist, i.e.

GRASS 6.4.3  d.mon -l
 no known monitors

It has affected all my locations, not just the one where I issued the 
command, so I don't think the change is in my PERMANENT.


   I looked through previous discussions of d.mon and X0, but they 
don't seem relevant to this problem.


Thanks, Dave
--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] broken d.mon

[Dave Roberts]

Hi Martin,

   Thanks.  I do understand that.  But now I have no X monitors (nor 
png or anything else for that matter).


Dave

On 02/21/2014 09:18 AM, Martin Landa wrote:

Hi,

2014-02-21 17:10 GMT+01:00 Dave Robertsdvr...@ecology.msu.montana.edu:

d.mon wx0

in GRASS64.  It not only did not display, now no monitors exist, i.e.


this is not possible in G6. Here d.mon works with X-based monitors,
ie. d.mon x0.

Martin


--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] broken d.mon

[Dave Roberts]

Hi Vaclav,

   Happy to stay on list.  I'm grateful for all the help I've received 
here.


   So, the problem is not with compilation.  GRASS64 was working well 
on my system (except for v.dissolve and lib gmath, see other list 
issues).  Oddly, when I mistakenly entered d.mon wx0 it not only didn't 
work (which should be expected), it disabled all the other monitor 
options (seemingly permanently).  When I changed to another location the 
problem persisted which really surprised me.


   Fortunately I have other machines to work on, but this is my primary 
machine for a large research project that emphasized GRASS.  I'm in the 
process of moving to GRASS7, but I couldn't get it to compile on this 
machine (Markus N is helping me with that), so I stayed with GRASS64.


Thanks, Dave

On 02/21/2014 01:52 PM, Vaclav Petras wrote:

Hi Dave,

let's keep the conversation on list. I hope you don't mind.

On Fri, Feb 21, 2014 at 2:57 PM, Dave Roberts
dvr...@ecology.msu.montana.edu mailto:dvr...@ecology.msu.montana.edu
wrote:

Hi Vaclav,

 Thanks for your help.  I'm running Scientific Linux 6
(EL6-based).  when I enter d.mon x0 it says there is no such monitor.


Isn't there some problem with compilation? I'm not sure if this is even
possible but maybe compilation can be set in the way that no monitors
are included.

The command

d.mon -l



generates

no known monitors

Hm, now I understand what you are saying, -l behavior differs for 6 and 7.

http://grass.osgeo.org/grass64/manuals/d.mon.html
http://grass.osgeo.org/grass70/manuals/d.mon.html

So, no x0-9, no png, no nothing.

Thanks, Dave



On 02/21/2014 10:56 AM, Vaclav Petras wrote:

What happens if you write

d.mon x0

?

Note that X monitors does not work on MS Windows.


On Fri, Feb 21, 2014 at 12:17 PM, Dave Roberts
dvr...@ecology.msu.montana.__edu
mailto:dvr...@ecology.msu.montana.edu
mailto:dvr...@ecology.msu.__montana.edu
mailto:dvr...@ecology.msu.montana.edu

wrote:

 Hi Martin,

 Thanks.  I do understand that.  But now I have no X
monitors
 (nor png or anything else for that matter).

 Dave


 On 02/21/2014 09:18 AM, Martin Landa wrote:

 Hi,

 2014-02-21 17:10 GMT+01:00 Dave
 Robertsdvr...@ecology.msu.__m__ontana.edu
http://montana.edu
mailto:dvr...@ecology.msu.__montana.edu
mailto:dvr...@ecology.msu.montana.edu:


 d.mon wx0

 in GRASS64.  It not only did not display, now no
monitors
 exist, i.e.


 this is not possible in G6. Here d.mon works with
X-based monitors,
 ie. d.mon x0.

 Martin


 --


~~__~~__
 David W. Roberts office
406-994-4548 tel:406-994-4548 tel:406-994-4548
tel:406-994-4548
 Professor and Head  FAX
406-994-3190 tel:406-994-3190 tel:406-994-3190
tel:406-994-3190
 Department of Ecology email
drobe...@montana.edu mailto:drobe...@montana.edu
mailto:drobe...@montana.edu mailto:drobe...@montana.edu

 Montana State University
 Bozeman, MT 59717-3460
 ___
 grass-user mailing list
grass-user@lists.osgeo.org mailto:grass-user@lists.osgeo.org
mailto:grass-user@lists.__osgeo.org
mailto:grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
http://lists.osgeo.org/__mailman/listinfo/grass-user
http://lists.osgeo.org/__mailman/listinfo/grass-user
http://lists.osgeo.org/mailman/listinfo/grass-user



--
~~__~~__
David W. Roberts office
406-994-4548 tel:406-994-4548
Professor and Head  FAX
406-994-3190 tel:406-994-3190
Department of Ecology email
drobe...@montana.edu mailto:drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460




--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman

Re: [GRASS-user] libgrass_gmath

[Dave Roberts]

Hi Hamish.  Thanks for the help.

g.version -r returns 6.4.3

echo $GISBASE returns  /usr/local/grass-6.4.3
echo $GRASS_LD_LIBRARY_PATH returns /usr/local/grass-6.4.3/lib
echo $LD_LIBRARY_PATH returns /usr/local/grass-6.4.3/lib

All good so far.  However,

ls $GISBASE/lib shows no libgrass_gmath

I compiled 6.4.3 from source (can't remember specifically why).  I run 
6.4.2 on my machine at work and it's fine.  It's odd that the error 
message specifically complains about 6.4.2 even when everything points 
to 6.4.3.


The v.dissolve script seems to run fine until it calls v.extract.  I've 
had a quick look at the source code, but I'm not so good at C.  I ran 
make in the lib directory with only a couple of warnings and I don't see 
anything really problematic.


Worst case scenario is I could go back to 6.4.2.  7.0 doesn't come close 
to compiling on this machine at present.


Thanks, Dave


On 02/17/2014 12:33 PM, Hamish wrote:

Dave wrote:

 I'm trying to do a simple dissolve on a vector map and getting a
library error

v.dissolve inp=vmap out=dom_mid_60 column=dom_mid_60
.  ..
.  ..
v.extract: error while loading shared libraries:
libgrass_gmath.6.4.2.so: cannot open shared object file: No such file or
directory

However

ls -l /usr/local/grass-6.4.2/lib

shows

-rwxr-xr-x. 1 root root 77615 Dec 21  2012 libgrass_gmath.6.4.2.so
lrwxrwxrwx. 1 root root23 Dec 21  2012 libgrass_gmath.so -
libgrass_gmath.6.4.2.so

just as I would expect, with read and execute permissions.

Oddly, I'm running GRASS 6.4.3, but all the libraries are 6.4.2.  This
is on Scientific Linux 6 (derived from RedHat Enterprise linux 6).


Hi,

try:

GRASS g.version -r

:)

GRASS echo $GISBASE
GRASS echo $GRASS_LD_LIBRARY_PATH
GRASS ls $GISBASE/lib
GRASS echo $LD_LIBRARY_PATH

that should show you where the grass install is located.

It's usually fine to have many versions of GRASS installed
at the same time, they can all run self-contained.

-- you might check if the 6.4.2 install is listed in /etc/ld.so.conf
or /etc/ld.so.conf.d/*, if so change it to the location of the 6.4.3
libraries and re-run `ldconfig` (as root).


good luck,
Hamish




--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] libgrass_gmath

[Dave Roberts]

Colleagues,

   I'm trying to do a simple dissolve on a vector map and getting a 
library error


v.dissolve inp=vmap out=dom_mid_60 column=dom_mid_60
 .  . .
 .  . .
v.extract: error while loading shared libraries: 
libgrass_gmath.6.4.2.so: cannot open shared object file: No such file or 
directory


However

ls -l /usr/local/grass-6.4.2/lib

shows

-rwxr-xr-x. 1 root root 77615 Dec 21  2012 libgrass_gmath.6.4.2.so
lrwxrwxrwx. 1 root root23 Dec 21  2012 libgrass_gmath.so -
libgrass_gmath.6.4.2.so

just as I would expect, with read and execute permissions.

Oddly, I'm running GRASS 6.4.3, but all the libraries are 6.4.2.  This 
is on Scientific Linux 6 (derived from RedHat Enterprise linux 6).


Thanks in advance for any help or suggestions, Dave
--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] compositing rasters

[Dave Roberts]

Friends,

   I did get an off-list solution (thanks Jiao) that works for two 
rasters but not for n (using the implied else).


   I think what GRASS needs is an r.update routine that works like an 
SQL update statement, i.e.


r.update map=composite.map value=1 where=map a = 1
r.update map=composite.map value=2 where=map b = 1
etc

This would solve my immediate problem but also have general 
utility.  I can export the grids and do it in FORTRAN easily enough, but 
I haven't cracked the GRASS API yet to actually make a GRASS function 
out of it.


Maybe there already is such a thing?

Thanks, Dave

On 12/31/2013 06:00 PM, Dave Roberts wrote:

Colleagues,

I know this must be easy, but I haven't found it.

Suppose I have three grids (a, b, and c) where each grid is 0 or 1,
and the 1s are mutually exclusive.  I want a new grid where if grid
a=1 then newgrid = 1; if grid b=1 then new grid = 2; if grid c=1 then
newgrid = 3.

 Something like  r.mapcalc new=if(a,1) || if(b,2) || if(c,3)

seems like it ought to work but I can't seem to use multiple input file
that way.

Thanks in advance for any help, Dave


--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] compositing rasters

[Dave Roberts]

Tyler,

Well, that's simply brilliant.  I knew it should be easy.  Plus, 
when I tested it I found out my rasters weren't truly mutually exclusive 
after all, as some cells = 3.  This is apparently an artifact of 
v.to.rast polygon boundary issues but it's a pretty small problem.


Nonetheless, I have begun work on the r.update function I mentioned 
in my last post.  It has general utility (e.g. fixing the non-exclusive 
problems I just mentioned) and seems easy enough as a crude hack.  If it 
shows general utility I'll post it and see if someone with GRASS coding 
skills wants to take it up in C with the API.


Thanks Tyler!

On 01/01/2014 09:56 AM, Tyler Smith wrote:

Dave Roberts dvr...@ecology.msu.montana.edu wrote:

Colleagues,

I know this must be easy, but I haven't found it.

Suppose I have three grids (a, b, and c) where each grid is 0 or 1,
and the 1s are mutually exclusive.  I want a new grid where if grid
a=1 then newgrid = 1; if grid b=1 then new grid = 2; if grid c=1 then
newgrid = 3.

Something like  r.mapcalc new=if(a,1) || if(b,2) || if(c,3)

seems like it ought to work but I can't seem to use multiple input file
that way.

Thanks in advance for any help, Dave


What about

r.mapcalc new=a + b*2 + c*3

If the maps are mutually exclusive, only one of the three will be
non-zero for each cell.

Tyler


--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] r.update

[Dave Roberts]

Friends,

After some alternative approaches to a simple problem of 
compositing rasters (see previous posts, esp. compositing rasters @9:32)

I developed a very crude function to update rasters

r.update target mask x y

updates raster target by substituting y everywhere that raster mask has 
x.  A more GRASS-like syntax would be


r.update target=string mask=string current=integer replace=integer

but my bash skills are pretty limited and I elected (for the time being) 
not to parse the arguments that way.  The current function relies on a 
short bash script and a FORTRAN executable.  The crude part is exporting 
both the target an mask rasters as ascii exports, creating a new ascii 
file, and doing an r.in.ascii to bring the updated raster back in.  It 
only works (at present) for integer rasters, but it's intended for 
thematic maps, so that seems OK.


r.update.sh just below.

r.out.ascii inp=$1 out=$1.asc null=-1
r.out.ascii inp=$2 out=$2.asc null=-1
g.remove rast=$1
r_update $1.asc $2.asc $3 $4
r.in.ascii  inp=tmp.file out=$1 nv=-1
rm $1.asc
rm $2.asc
rm tmp.file

You have to alias r_update 'sh r_update.sh' or name the script 
r.update and chmod +x r.update to make it run as shown.


The FORTRAN code for r_update is at

ecology.msu.montana.edu/GRASS/r_update.f90

The code compiles with gfortran.  The executable must be in your path, 
or you can modify the bash script with a full path to it.


It is my sincere hope that someone with GRASS chops will write a 
function for g.extension that uses the API and avoids all this ascii 
input and output, but this serves as a demo and useful (if clumsy) 
approach in the meantime.


Dave
--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.update

[Dave Roberts]

Hi Anna,

On 01/01/2014 01:50 PM, Anna Petrášová wrote:

Hi Dave,



On Wed, Jan 1, 2014 at 3:10 PM, Dave Roberts
dvr...@ecology.msu.montana.edu mailto:dvr...@ecology.msu.montana.edu
wrote:

Friends,

 After some alternative approaches to a simple problem of
compositing rasters (see previous posts, esp. compositing rasters @9:32)
I developed a very crude function to update rasters

r.update target mask x y

updates raster target by substituting y everywhere that raster mask
has x.  A more GRASS-like syntax would be

r.update target=string mask=string current=integer replace=integer



I'm not sure if I don't miss anything but why don't you use r.mapcalc
expression like this:

new = if(mask == x, y, target)

and then

g.rename new,target --overwrite

well probably because I'm not too bright.  Obviously your elegant 
solution would allow multiple sequential updates just the way I needed 
as long as I do the rename --overwrite very time.  I knew there had to e 
GRASS way to do this, I just hadn't figured it out yet.


Thanks!


Anna


but my bash skills are pretty limited and I elected (for the time
being) not to parse the arguments that way.  The current function
relies on a short bash script and a FORTRAN executable.  The crude
part is exporting both the target an mask rasters as ascii exports,
creating a new ascii file, and doing an r.in.ascii to bring the
updated raster back in.  It only works (at present) for integer
rasters, but it's intended for thematic maps, so that seems OK.

r.update.sh http://r.update.sh just below.

r.out.ascii inp=$1 out=$1.asc null=-1
r.out.ascii inp=$2 out=$2.asc null=-1
g.remove rast=$1
r_update $1.asc $2.asc $3 $4
r.in.ascii  inp=tmp.file out=$1 nv=-1
rm $1.asc
rm $2.asc
rm tmp.file

You have to alias r_update 'sh r_update.sh' or name the script
r.update and chmod +x r.update to make it run as shown.

The FORTRAN code for r_update is at

ecology.msu.montana.edu/GRASS/__r_update.f90
http://ecology.msu.montana.edu/GRASS/r_update.f90

The code compiles with gfortran.  The executable must be in your
path, or you can modify the bash script with a full path to it.

 It is my sincere hope that someone with GRASS chops will write
a function for g.extension that uses the API and avoids all this
ascii input and output, but this serves as a demo and useful (if
clumsy) approach in the meantime.

Dave
--
~~__~~__
David W. Roberts office
406-994-4548 tel:406-994-4548
Professor and Head  FAX
406-994-3190 tel:406-994-3190
Department of Ecology email
drobe...@montana.edu mailto:drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
_
grass-user mailing list
grass-user@lists.osgeo.org mailto:grass-user@lists.osgeo.org
http://lists.osgeo.org/__mailman/listinfo/grass-user
http://lists.osgeo.org/mailman/listinfo/grass-user




--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] compositing rasters

[Dave Roberts]

Colleagues,

   I know this must be easy, but I haven't found it.

   Suppose I have three grids (a, b, and c) where each grid is 0 or 1, 
and the 1s are mutually exclusive.  I want a new grid where if grid
a=1 then newgrid = 1; if grid b=1 then new grid = 2; if grid c=1 then 
newgrid = 3.


Something like  r.mapcalc new=if(a,1) || if(b,2) || if(c,3)

seems like it ought to work but I can't seem to use multiple input file 
that way.


Thanks in advance for any help, Dave
--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] multiple polygons with same cat

[Dave Roberts]

Thanks Markus.  This has me on the right track, but I haven't gotten it 
all to work yet.


v.category map=geo type=centroid op=add layer=2

refused to work without a new output map, so

v.category inp=geo  out=new_geo op=add layer=2

produced a new vector map where the cats are unique for each polygon.

doing d.what.vect new_geo shows the old data in layer 1 and the new data 
in layer 2


  Curiously, there are now 3938 polygons (instead of 1082).  If I do a
v.db.connect to a table in Postgres and then v.to.db move over the cat 
and coor data psql shows that the first 2725 records are null (except 
for cat) and the X,Y coordinates start at cat 2726, giving me 1212 
polygons with real data.


   I could maybe delete the first 2726 records and join this new table 
to the one with the stratigraphy data on the X and Y coordinates, but 
doing exact equality on floating point numbers is madness.


Any ideas?

Thanks, Dave

On 11/26/2013 02:25 AM, Markus Metz wrote:

On Tue, Nov 26, 2013 at 3:39 AM, Dave Roberts
dvr...@ecology.msu.montana.edu wrote:

Friends,

   I'm not exactly a newbie, but still yet quite naive in GRASS.  This seems
like a simple problem, but I suspect unforeseen problems with the simple
solution.

   I have imported a surficial geology map from a shapefile.  There are 1082
polygons.  Each of the polygons with the same surficial geology (e.g Agn,
Archean gneiss) has the same cat (i.e. there are 29 polygons with cat=3).  I
would like to add several columns to this table (e.g. geologic era and
primary lithology (e.g. granite vs limestone)).

I normally associate all vector maps with a table in PostgreSQL using cat
as the primary key (i.e. v.db.connect -o key=cat), but that clearly won't
work here.  I could rename the column 'cat' in the DBF file, and add a new
column with values 1-1082 as cat.


That does not work because the geometries don't get new categories.


If I save that as a new DBF file in a new
shapefile directory, when I re-import with v.in.ogr will it necessarily get
it right?  I.e, will GRASS associate the vertices the first polygon in the
shapefile with the first row in the DBF file?  I only ask because PostgreSQl
(like most DBMSs) does not guarantee the records to be in any specific
order, and perhaps shapefiles don't either?


Shapefiles (using DBF) require the records in a specific order. GRASS
vectors do not require records to be in a specific order, they link
geometries to the appropriate record with the key column.


 Is there a simple way to renumber the polygons 1 through 1082 that
maintains integrity and allows me to connect the vector coverage to
PostgreSQL instead of DBF?


v.category map=geo type=centroid op=add layer=2

That will create a new layer where each area has a unique category.
The original layer where several areas share the same category is
preserved. You can add a new table to this layer with v.db.addtable
layer=2. Then you can transfer attributes from one layer to another
with v.to.db.

HTH,

Markus M



--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] multiple polygons with same cat

[Dave Roberts]

 I would suggest to run

 v.category inp=geo type=centroid out=new_geo op=add layer=2 --o


Thanks Markus!  Now I'm getting somewhere.  v.info shows geo and new_geo 
in perfect correspondence for areas, islands, boundaries, etc.


d.what.vect shows new_geo with the original data in layer 1 and the new 
data in layer 2.  v.to.db successfully transferred the centroids (coor) 
and area to layer 2.  However, I still don't see how to get the 
surficial geology column (surgeo) out of layer 1 into layer 2 without a 
join item.  I know I'm missing something simple, but v.to.db just seems 
to allow a restricted set of values for option.


Thanks, Dave
--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] multiple polygons with same cat

[Dave Roberts]

Markus,

   Thanks a mill!  I'll try that when I get back to that machine.

   I really appreciate you time end expertise.  You're a scholar and a 
gentleman.


Dave

On 11/26/2013 08:48 AM, Markus Metz wrote:

On Tue, Nov 26, 2013 at 4:34 PM, Dave Roberts
dvr...@ecology.msu.montana.edu  wrote:

I would suggest to run

v.category inp=geo type=centroid out=new_geo op=add layer=2 --o



Thanks Markus!  Now I'm getting somewhere.  v.info shows geo and new_geo in
perfect correspondence for areas, islands, boundaries, etc.

d.what.vect shows new_geo with the original data in layer 1 and the new data
in layer 2.  v.to.db successfully transferred the centroids (coor) and area
to layer 2.  However, I still don't see how to get the surficial geology
column (surgeo) out of layer 1 into layer 2 without a join item.  I know I'm
missing something simple, but v.to.db just seems to allow a restricted set
of values for option.


v.to.db map=new_geo layer=2 column=surgeo option=query qlayer=1 qcolumn=surgeo

In this example, the column surgeo in layer 2 must exist and must be
of the same type like the column surgeo in layer 1.

Markus M



Thanks, Dave

--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460


--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] multiple polygons with same cat

[Dave Roberts]

Markus,

 v.to.db map=new_geo layer=2 column=surgeo option=query qlayer=1
 qcolumn=surgeo

 In this example, the column surgeo in layer 2 must exist and must be
 of the same type like the column surgeo in layer 1.

the qcolumn actually had a different name, but with that small 
correction this worked like a charm.


Thanks again, Dave

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

[GRASS-user] multiple polygons with same cat

[Dave Roberts]

Friends,

  I'm not exactly a newbie, but still yet quite naive in GRASS.  This 
seems like a simple problem, but I suspect unforeseen problems with the 
simple solution.


  I have imported a surficial geology map from a shapefile.  There are 
1082 polygons.  Each of the polygons with the same surficial geology 
(e.g Agn, Archean gneiss) has the same cat (i.e. there are 29 polygons 
with cat=3).  I would like to add several columns to this table (e.g. 
geologic era and primary lithology (e.g. granite vs limestone)).


   I normally associate all vector maps with a table in PostgreSQL 
using cat as the primary key (i.e. v.db.connect -o key=cat), but that 
clearly won't work here.  I could rename the column 'cat' in the DBF 
file, and add a new column with values 1-1082 as cat.  If I save that as 
a new DBF file in a new shapefile directory, when I re-import with 
v.in.ogr will it necessarily get it right?  I.e, will GRASS associate 
the vertices the first polygon in the shapefile with the first row in 
the DBF file?  I only ask because PostgreSQl (like most DBMSs) does not 
guarantee the records to be in any specific order, and perhaps 
shapefiles don't either?


Is there a simple way to renumber the polygons 1 through 1082 that 
maintains integrity and allows me to connect the vector coverage to 
PostgreSQL instead of DBF?


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

Re: [GRASS-user] polygons and centroids redux

[Dave Roberts]

Thanks Hamish.  It seems only likely that such a routine would exist.

Here's the part where I need a little help though.  It appears that

v.distance from=pnt to=area dmax=0 upload=cat column=areacat

will find and report the cat number of the polygon that points lie 
within, and I can use that in a database operation which is extremely 
handy.  So, I have done that, and now the area cat for each point is 
available in the database.  That works for points in a point vector 
feature.


Using d.what.vect or v.what, however, I cannot control whether the 
function reports a boundary or centroid.  This makes it hard to

replicate the behavior of v.distance for a few points on the fly.
Is there some way to access the existing point-in-polygon routine from 
an existing GRASS function to simulate what I'm after?


Looking at the progammer's manual, writing something like v.pip (= to 
d.what.vect reporting always area cat) appears to be a bit more than I 
want to bite off at present.


Perhaps one approach would be

d.where  file
(edit file as necessary for separator)
v.in.ascii in=file out=points fs=whatever
v.distance from=points to=area dmax=0 upload=cat column=areacat

That works but seems like a lot of work for what I'm after.

Thanks much, Dave


Hamish wrote:

Dave wrote:

I think it would indeed be handy if a switch
was added to v.what and
d.what.vect in GRASS 7.  In the meantime it might be
handy to write a v.pip command for GRASS 6.  I have
written a point-in-polygon routine for other software
(including R), but I would have to really study the file
structures of GRASS vectors to attempt that in
GRASS.   If any GRASS programmers are
interested let me know and perhaps we could work it out as
an add-on.


point in polygon is a standard function in the vector library for
years.


Hamish


  


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

[GRASS-user] polygons and centroids

[Dave Roberts]

Friends,

   If I understand correctly (based on experience with my own data), 
when GRASS calculates the topology for vector area data it doesn't 
actually ensure that the centroid lies within the area it represents. 
If the area is a torus, or at least hollow in a general way, then the 
centroid might actually lie in the void in the center of the polygon 
rather than within the interior of the polygon itself.  It seems like
it would be preferable to run a point-in-polygon check on the calculated 
centroid and move it of necessary to achieve correct point-in-polygon 
correspondence.


   This seems like it may also influence the results of v.what and 
d.what.vect as well, and not always identify the correct polygon if 
another centroid is nearer.  I assume this is a well-known situation, 
and that perhaps the solution for complex (sometimes hollow) polygons 
(following advice from Achim Kesseler)is to do a v.to.rast and sample 
the raster.   Is that considered best practice for complex area data, or 
are there better approaches?  Is v.what reliable in these situations, 
including in point-in-polygon mode?


Thanks, Dave
--

David W. Roberts office 406-994-4548
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] polygons and centroids redux

[Dave Roberts]

Friends,

 This is the second time in two days I have had to post an apology 
and retraction for hasty questions.  I apologize for testing everyone's 
patience.  Thanks Markus; I was composing this message when I saw your 
post.  I mistook a centroid of a polygon too small to plot at the 
current resolution as the centroid of the surrounding hollow area.  My 
mistake; sorry.


It does raise a question, however, of what the conditions are that 
cause d.what.vect to return a feature type of Boundary rather than 
Area when querying a map.  Is it simply proximity to the boundary, and 
can that behavior be suppressed in preference to always returning the 
data associated with the centroid?


Thanks, Dave
--

David W. Roberts office 406-994-4548
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] polygons and centroids redux

[Dave Roberts]

Thanks Markus!

I think it would indeed be handy if a switch was added to v.what and
d.what.vect in GRASS 7.  In the meantime it might be handy to write a 
v.pip command for GRASS 6.  I have written a point-in-polygon routine 
for other software (including R), but I would have to really study the 
file structures of GRASS vectors to attempt that in GRASS.   If any 
GRASS programmers are interested let me know and perhaps we could work 
it out as an add-on.


Thanks, Dave R


Markus Metz wrote:

Dave Roberts wrote:

   It does raise a question, however, of what the conditions are that cause
d.what.vect to return a feature type of Boundary rather than Area when
querying a map.


d.what.vect and v.what search for points and centroids first. If none
is found, they continue and search for lines, boundaries and faces. If
none is found, they continue and search for areas. This search order
causes any centroid or boundary to be returned if found, and not the
corresponding area. Currently there is no way to select the feature
type (point, centroid, line, boundary, area, face) to be searched.
This option could be added for v.what in 7.0 if desired.

Markus M


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

[GRASS-user] v.what.rast with centroids

[Dave Roberts]

Friends,

I have an vector area map with numerous polygons with centroids.  When I do

v.what.rast vector=A raster=B column=C

It appears to run, but doesn't actually enter any data into column C in 
the associated table in Postgres.  Reading the help file, I suspect this 
is because A is an area instead of a point map, but the areas do have 
centroids which I would expect v.what.rast to employ.


I could import the centroids as a separate points map, but then they're 
not associated with the table in Postgres.


What's considered best practices in associating polygon centroids with 
other rasters or vector areas?


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

[GRASS-user] r.neighbors with large neighborhoods

[Dave Roberts]

I'm working landform analysis using r.neighbors.  The help file says 
that size can go up to 25 (or +/1 12 pixels).  I need much bigger 
neighborhoods than that, so I just entered a large number and it seems 
to work (although it's slow).  Does anybody know what the true limits of 
the r.neighbors code really is?


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

[GRASS-user] r.neighbors

[Dave Roberts]

It appears that running r.neighbors with really large neighborhoods
results in mostly NULLs.  A neighborhood of 31 seemed to work, but 51 
returned only a tiny portion of the map.


Dave
--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] r.neighbors erroneous posting

[Dave Roberts]

Friends,

Sorry about an erroneous posting with respect to running 
r.neighbors with large neighborhoods (51 in this case).  My problem was 
the current region, not r.neighbors which seesm to work fine with large 
windows.


Dave
--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] grass 7 monitor

[Dave Roberts]

Fiends,

I'm a GRASS newbie trying to choose between GRASS6 and GRASS7 for a 
new project.  I'm working in R and PostgreSQL, but have lots of Arc 
stuff to import.


I realize that GRASS7 did away with d.mon, but is there really no 
replacement other than the full GUI?  If I enter


grass70 -text /path/to/GISDBASE/LOCATION/MAPSET

it starts up, but doesn't change the prompt to indicate it's actually 
running.  However, it obviously is, and responds to commands such as


g.list vect

as usual.  In response to

d.rast layer

it calculates %s and then ends with no output.  I tried, for example,

d.cairo

to get a window to plot into, but no such command exists.  So, in 
frustration I try


g.gui wxpython

and get the whole GUI (which I emphatically DO NOT want) just to get the 
map console.  At that point, commands such as


d.rast layer

run without error but produce no output,and the GUI seems corrupted and 
doesn't work either.


That's a long post, but the critical question is is GRASS 7 going to be 
strictly GUI driven?  I hoipe not.


Thnaks, Dave
--

David W. Roberts office 406-994-4548
Professor and Head  FAX 406-994-3190
Department of Ecology email drobe...@montana.edu
Montana State University
Bozeman, MT 59717-3460
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user