[GRASS-user] R: Re: problem add-ons and python (windows7)

GRASS GRASS user
1

And/or the set PATHENV in \etc\Init.bat is not
working properly. (it knows about .py but doesn't know to associate
it with GRASS's python.exe)

Honestly I have not found the PATHENV in \etc\Init.bat. Is it a problem? I
tryed to know which one is the path that corresponds to python.exe but I wasn't
able. The command try to open .py file always with pythom.exe from \extrabin.

Secondly, there is a .bat wrapper called %ADDONS%/scripts/r.basin.py.bat
which should be in %ADDONS%, and be named r.basin.bat.

I wasn't able to find where to set %ADDONS% too. I saw only %
GRASS_ADDON_PATH%. So confused :slight_smile:

Mattia

----Messaggio originale----
Da: hamish_b@yahoo.com
Data: 09/06/2013 13.33
A: <grass-user@lists.osgeo.org>, "Mattia Riccadonna"<Mattia_r@libero.it>
Ogg: Re: [GRASS-user] problem add-ons and python (windows7)

Mattia wrote:

I'm trying to solve my problem for a long time. I hope
someone can help me.
I'm not expert but I really want to istall 2 add-on on grass
6.4.3RC3 on my win7. The add-ons are r.basin and r.ipso. I think
there are problem with the python.exe and the PATHS. When I launch from
console r.ipso I receive this error:

C:\Program Files (x86)\GRASS GIS
6.4.3RC3\extrabin\python.exe: can't open file 'r.ipso.py':
[Errno 2] No such file or directory

the trouble with those two scripts are that they are written in python,
and GRASS 6 does not handle python addon scripts as well as it does
compiled C modules and UNIX shell scripts.

the bad news is as you experience they don't work out of the box right
now on Windows. The good news is that it is fixable. By moving and renaming
some of the files I could get them to run locally on Windows XP.
-- it's a solvable problem. I just ran r.basin.

gory technical details:
the basic one is Python.Make in GRASS 6's include/Make dir is not
currently set up to create the .bat file wrappers needed to launch
the scripts there. And/or the set PATHENV in \etc\Init.bat is not
working properly. (it knows about .py but doesn't know to associate
it with GRASS's python.exe)

Secondly, there is a .bat wrapper called %ADDONS%/scripts/r.basin.py.bat
which should be in %ADDONS%, and be named r.basin.bat. It contains a
single line, but that is wrong too, it should be set up for a python
script but it is created for a UNIX shell script. It should read like:

@"%GRASS_PYTHON%" "%GRASS_ADDON_PATH%/r.basin" %*

then the %ADDONS%\r.basin.py renamed to just r.basin, and finally
the batch file run as "r.basin.bat". Then it works.

The better solution is to fix the .py association with python.exe, but
care is needed to pick the right one, and not hijack that setting for
the entire computer, since other software might be using another version
of python.

I note that there are 2 python.exe. One in C:\Program Files
(x86)\GRASS GIS 6.4.3RC3\extrabin\ and one in C:\Program Files
(x86)\GRASS GIS 6.4.3 RC3\Pyton27\. I think that last one is the right
and I think that probably there is an error with the PATH. It is
possible?

do you really have a python.exe in your ...\GRASS GIS 6.4.3 RC3\Python27\
directory? For me it is only in ...\extrabin\ and in Python27\ there is
only support files.

As of last night's nightly build, 6.4.3svn explicitly expects to find
its python.exe in the \extrabin\ dir.

Can anyone drive me to the solution? I would need to know
where setting the different path beacuse I'm noob! I also see that
there is a folder in C: User\AppData\Roaming\GRASS6\addons... It is
normal that the add-ons are istalled ther instead of in GRASS GIS
6.4.3RC3 directory?

Yes, because the User can always write to their own AddData directly,
but on a multi-user or managed (corporate) system the user may not have
permission to change or add files to C:\Program Files.
There is a %GRASS_ADDON_PATH% variable set which says where your personal
scripts are stored. (can be set to multiple paths)

When I launch r.basin I have an error that say aren't import
sys, os and matplotlib. Even though I have istall matplotlib for
Python27.

I don't get that error, just the one from g.parser that it can't get
the interface description (since it can't find the script). I'm surprised
that sys and os can't be found, that indicates that your %PYTHONPATH% is
broken since those two should always be built in. As for matplotlib I'm
not sure if GRASS ships that, it might not & so need to be installed
manually. (however you do that on Windows)

again, python + grass6 + MS Windows is a work in progress :slight_smile:
fortunately only a few of the addons for grass6 are written in python,
so it's not a very widespread problem, but is certainly a pretty basic
need and something we want to support for the future.

Hamish

2

Hamish:

And/or the set PATHENV in \etc\Init.bat is not working properly.
(it knows about .py but doesn't know to associateit with GRASS's
python.exe)

Mattia wrote:

Honestly I have not found the PATHENV in \etc\Init.bat. Is it a problem?

it should be there on line 69. I'm not sure if it means much without
assoc and ftype (see below).

I tryed to know which one is the path that corresponds to python.exe
but I wasn't able. The command try to open .py file always with pythom.exe
from \extrabin.

On a copy of GRASS 6.4.3svn nightly build from today or yesterday,
running "echo $GRASS_PYTHON" from the Msys terminal, or
"echo %GRASS_PYTHON%" from the C:\> dosbox window (both in the GRASS
section of the Start Menu) should show it.

wrt finding Matplotlib, the %PYTHONPATH% (or $PYTHONPATH) variable may be
interesting to look at as well. (apparently we don't ship it [yet])

you might also try this tip from the python docs, add this to C:\Program
Files\GRASS...\etc\env.bat:
  (http://docs.python.org/2/using/windows.html#executing-scripts)

assoc .py=Python.File
ftype Python.File="%GRASS_PYTHON%" "%1" %*

outside of the GRASS environment would probably be an error since
PYTHONPATH wasn't set system-wide.

you might also try changing the GRASS_PYTHON and PYTHONPATH to your
system installed Python.exe and support files, and so matplotlib too.
(change them together, keep them in sync)

Secondly, there is a .bat wrapper called %ADDONS%/scripts/r.basin.py.bat
which should be in %ADDONS%, and be named r.basin.bat.

I wasn't able to find where to set %ADDONS% too. I saw only %
GRASS_ADDON_PATH%. So confused :slight_smile:

sorry, I was in a rush and abbreviated it. %GRASS_ADDON_PATH% is correct.

In addition, I used g.extension to get add-ons. And with that command
there aren't make files in any folder. Have I to re-download them
manually? In case, where have I to put make files?

that part of my comment was mostly meant for the developers. Since most
Windows users don't have the full compiler and osgeo4w build environment
set up on Windows we (ie Martin) provides pre-built versions. For python
and shell scripts it isn't a big deal since there's noting to build, but
copying everything into the right spot and getting the extensions working
correctly can be a pain, as you've experienced.

You might also try to replicate the setup of e.g. d.rast3d.py and .bat
in C:\Program Files\GRASS...\etc\gui\scripts\, I tried that but no luck.

I know we're very close on python scripts + GRASS 6.4 + Windows, it's a
bit frustrating missing that last piece of the puzzle... after all the
g.extension.py script you used to download starts runs ok...

Hamish

3

I am trying to export a vector point file that has a single label for each point. In the attribute table the labels are shown as being on layer 1. However when I export the file using v.out.dxf the labels are all -1. Is there another step to take before exporting the file such that it includes the label.

Thanks for any assistance.

Linda Edwards

4

After consulting several message boards the following steps were followed to provide a dxf-labeled vector point file initially created in GRASS. This involved the use of a free dxf converter available at:

http://freegeographytools.com/2007/converting-shapefiles-and-arcinfo-coverages-to-autocad-dxf-format

Note that this is a Windows .exe program

1. export the vector file as an ESRI-shape file using v.out.ogr. (Initially I had an issue with the column name being too long _over 8 characters_when corrected all worked well).
2. upload the data file to the dxfauthor converter using the File pull-down menu
3. the shapes will be displayed in the main window
3. select Convert to DXF and a series of several screens will allow you to select various options along with designating the location of the output dxf
4. select Finish

At this point you should have a labeled dxf.

On Jun 11, 2013, at 9:01 AM, Linda Edwards wrote:

I am trying to export a vector point file that has a single label for each point. In the attribute table the labels are shown as being on layer 1. However when I export the file using v.out.dxf the labels are all -1. Is there another step to take before exporting the file such that it includes the label.

Thanks for any assistance.

Linda Edwards

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

5

Hi –

This simple project involves digitizing and displaying the location of about 200 borings. There is a pair of state plane co-ordinates and an alpha-numeric boring designator - and of course a cat - for each of them. The borings were duly digitized using v.digit in GRASS 7 (OS X) and after a number of edits (relocations, modification of some attributes, and some deletions) the file displays correctly using d.vect. It has also been satisfactorily exported as a shapefile as part of an effort to create a labeled dxf CAD layer.

However, v.report creates a table that appears to randomly (unlikely, I know, but that’s how it appears) redistribute the pairs of co-ordinates among the points.

For example, at one boring location v.what generates:

v.what -a map=Borings@PERMANENT layer=-1 coordinates=1791366.79821,765499.232745 distance=2

East: 1791366.79821

North: 765499.232745

Map: Borings

Mapset: PERMANENT

Type: Point

Id: 117

Layer: 1

Category: 142

Driver: sqlite

Database: /Users/stu/grassdata/270test/PERMANENT/sqlite/sqlite.db

Table: Borings

Key column: cat

cat : 142

boringnumber : B-9-004-13

However, v.report gives:

142|B-9-004-13|1793470.46145773|765224.666245354|0

for cat 142 which is the location of one of the other borings. Almost all of the borings are incorrectly identified in the v.report table. I tried v.build before running v.report but the results were the same.

Any assistance would be much appreciated as I would like to have an accurate table of these locations.

thx

Stu

6

On Fri, Jun 14, 2013 at 2:23 AM, Stuart Edwards <sedwards2@cinci.rr.com> wrote:

Hi --

This simple project involves digitizing and displaying the location of about
200 borings. There is a pair of state plane co-ordinates and an
alpha-numeric boring designator - and of course a cat - for each of them.
The borings were duly digitized using v.digit in GRASS 7 (OS X) and after a
number of edits (relocations, modification of some attributes, and some
deletions) the file displays correctly using d.vect. It has also been
satisfactorily exported as a shapefile as part of an effort to create a
labeled dxf CAD layer.

So, just to be sure to understand: you have digitized circular polygons?

However, v.report creates a table that appears to randomly (unlikely, I
know, but that's how it appears) redistribute the pairs of co-ordinates
among the points.

For example, at one boring location v.what generates:

v.what -a map=Borings@PERMANENT layer=-1
coordinates=1791366.79821,765499.232745 distance=2

The coordinate pair specified here, where does it fall into the polygon?
Onto the boundary or onto the centroid or "anywhere" within the
polygon?

East: 1791366.79821
North: 765499.232745
Map: Borings
Mapset: PERMANENT
Type: Point <<<---- so you have points and not polygons?
Id: 117
Layer: 1
Category: 142
Driver: sqlite
Database: /Users/stu/grassdata/270test/PERMANENT/sqlite/sqlite.db
Table: Borings
Key column: cat
cat : 142
boringnumber : B-9-004-13

What does this print:

v.info -t Borings
?

However, v.report gives:

142|B-9-004-13|1793470.46145773|765224.666245354|0

for cat 142 which is the location of one of the other borings. Almost all of
the borings are incorrectly identified in the v.report table. I tried
v.build before running v.report but the results were the same.

Perhaps you could post a small map screenshot of the area of interest
along with the map scalebar put on.

Markus

7

Markus

Thanks for your response.

On Jun 16, 2013, at 4:29 AM, Markus Neteler wrote:

On Fri, Jun 14, 2013 at 2:23 AM, Stuart Edwards <sedwards2@cinci.rr.com> wrote:

Hi --

This simple project involves digitizing and displaying the location of about
200 borings. There is a pair of state plane co-ordinates and an
alpha-numeric boring designator - and of course a cat - for each of them.
The borings were duly digitized using v.digit in GRASS 7 (OS X) and after a
number of edits (relocations, modification of some attributes, and some
deletions) the file displays correctly using d.vect. It has also been
satisfactorily exported as a shapefile as part of an effort to create a
labeled dxf CAD layer.

So, just to be sure to understand: you have digitized circular polygons?

No, this becomes a vector points map that is then displayed over a raster photo base using the available symbols. The attributes provide the boring numbers that are also displayed.

However, v.report creates a table that appears to randomly (unlikely, I
know, but that's how it appears) redistribute the pairs of co-ordinates
among the points.

For example, at one boring location v.what generates:

v.what -a map=Borings@PERMANENT layer=-1
coordinates=1791366.79821,765499.232745 distance=2

The coordinate pair specified here, where does it fall into the polygon?
Onto the boundary or onto the centroid or "anywhere" within the
polygon?

This one is roughly in the middle of the 'cloud'

East: 1791366.79821
North: 765499.232745
Map: Borings
Mapset: PERMANENT
Type: Point <<<---- so you have points and not polygons?

yes -

Id: 117
Layer: 1
Category: 142
Driver: sqlite
Database: /Users/stu/grassdata/270test/PERMANENT/sqlite/sqlite.db
Table: Borings
Key column: cat
cat : 142
boringnumber : B-9-004-13

What does this print:

v.info -t Borings?

v.info -t Borings
nodes=0
points=212
lines=0
boundaries=0
centroids=0
areas=0
islands=0
primitives=212
map3d=0

Note - the total boring count is only 186 and there are no other features on this map.

However, v.report gives:

142|B-9-004-13|1793470.46145773|765224.666245354|0

for cat 142 which is the location of one of the other borings. Almost all of
the borings are incorrectly identified in the v.report table. I tried
v.build before running v.report but the results were the same.

Perhaps you could post a small map screenshot of the area of interest
along with the map scalebar put on.

Please see attached. The screen shot was taken with the cursor on the boring location (circled) and you can see that the co-ordinates correspond reasonably well with the result of v.what mentioned above.

Is it possible that the db is not keeping up with the edits that are made subsequent to digitization and that when a boring is moved, points are not properly deleted, although a new point is created, and all the following cats are thrown off by a corresponding amount? All of the co-ordinate pairs are perfectly represented - just with the wrong attribute.

Thanks again for your assistance ......

Stu

(attachments)

markus.jpg