Re: [GRASS-user] grass-user Digest, Vol 132, Issue 28 [SEC=UNOFFICIAL]
Rich Shepard wrote: > as python2 has officially be deprecated. Python 2.7 will be supported by its developers until early 2020 AFAIK and I can find no reference on www.python.org to it officially being "deprecated" - could you point me at your source please? Thanks, Andrew. -> "These thoughts are mine alone!" <- Andrew MacIntyre Operations, Services and Technologies Branch tel: +61 2 6219 5356 Communications Infrastructure Division Australian Communications & Media Authority email: andrew.macint...@acma.gov.au http://www.acma.gov.au/ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problem accessing GRASS from GRASS from PostgreSQL9.1/PostGIS2.0 via pg-python or plpythonu [SEC=PERSONAL]
I don't have much experience with Postgres but it seems to me that it is a
server configuration issue - perhaps the server startup scripts may not be
pulling in the bashrc used by the interactive login, or the pg-python/plpythonu
interfaces start Python with separate environments without reference to that
bashrc. The fact that pg-python starts a different Python version to plpythonu
indicates distinct configuration settings for these.
- These thoughts are mine alone! -
Andrew MacIntyre Operations Branch
tel: +61 2 6219 5356 Communications Infrastructure Division
fax: +61 2 6253 3277 Australian Communications Media Authority
email: andrew.macint...@acma.gov.au http://www.acma.gov.au/
-Original Message-
Message: 3
Date: Thu, 19 Jul 2012 22:36:41 +1000
From: Mark Wynter m...@dimensionaledge.com
To: grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] Problem accessing GRASS from GRASS from
PostgreSQL9.1/PostGIS2.0 via pg-python or plpythonu
Message-ID: F57CA683-3E5B-49B1-A5FD-
412fa69ed...@dimensionaledge.com
Content-Type: text/plain; charset=us-ascii
{...}
OK, I've got two versions of python: 2.7 and 3.2...
Both python console and postgresql can see python 2.7 but plus it appears
the grass environmental variables are not finding their way into the
$pythonpath as seen by the postgresql server??
Any suggestions?
NOTICE: This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problem accessing GRASS from GRASS from PostgreSQL9.1/PostGIS2.0 via pg-python or plpythonu [SEC=UNCLASSIFIED]
I suggest running a test script that reports sys.path to confirm that the
actual Python module search path seen by the Postgres server's environment is
as expected.
- These thoughts are mine alone! -
Andrew MacIntyre Operations Branch
tel: +61 2 6219 5356 Communications Infrastructure Division
fax: +61 2 6253 3277 Australian Communications Media Authority
email: andrew.macint...@acma.gov.au http://www.acma.gov.au/
Message: 5
Date: Wed, 18 Jul 2012 22:58:59 +1000
From: Mark Wynter m...@dimensionaledge.com
To: grass-user@lists.osgeo.org
Subject: [GRASS-user] Problem accessing GRASS from
PostgreSQL9.1/PostGIS2.0via pg-python or plpythonu
Message-ID: 4D8125BB-F64C-4D07-8D4B-
69c64060c...@dimensionaledge.com
Content-Type: text/plain; charset=utf-8
My requirement is to connect to GRASS from PostgreSQL9.1/PostGIS2.0 via
the pg-python or plpythonu procedural language. I'm wondering whether I
have a permissions issue?
I'm running my stack on Ubuntu 12.04 LTS
I've added the following environmental variables to /etc/bash.bashrc
export GISBASE=/usr/local/grass-6.4.3svn
export PATH=$PATH:$GISBASE/bin:$GISBASE/scripts:$GISBASE/lib
export PYTHONPATH=${PYTHONPATH}:$GISBASE/etc/python/
export PYTHONPATH=${PYTHONPATH}:$GISBASE/etc/python/grass
export PYTHONPATH=${PYTHONPATH}:$GISBASE/etc/python/grass/script
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$GISBASE/lib
export GIS_LOCK=$$
export GISRC=$HOME/.grassrc6
If I log out and log in again, the following environment variables are now
available to the postgres user:
ubuntu@ip-10-252-74-140:~$ sudo su postgres
postgres@ip-10-252-74-140:/home/ubuntu$ echo $GISBASE
/usr/local/grass-6.4.3svn
postgres@ip-10-252-74-140:/home/ubuntu$ echo $PYTHONPATH
:/usr/local/grass-6.4.3svn/etc/python/:/usr/local/grass-
6.4.3svn/etc/python/grass:/usr/local/grass-6.4.3svn/etc/python/grass/script
postgres@ip-10-252-74-140:/home/ubuntu$ echo $HOME
/var/lib/postgresql
if I call the function import grass.script as grass from the python console,
there is no error. All seems ok.
postgres@ip-10-252-74-140:/$ python
Python 2.7.3 (default, Apr 20 2012, 22:39:59)
[GCC 4.6.3] on linux2
Type help, copyright, credits or license for more information.
import grass.script as grass
If I now log into PostgreSQL/PostGIS via psql, and try to run the same
command within in a postgresql plpythonu or pg-python function, I get the
following error messages.
psql -d test
CREATE OR REPLACE FUNCTION pythontest() RETURNS text AS
$$
import grass.script as grass
$$
LANGUAGE 'plpythonu' VOLATILE;
test=# select pythontest();
ERROR: ImportError: No module named grass.script
CONTEXT: Traceback (most recent call last):
PL/Python function pythontest, line 3, in module
import grass.script as grass
PL/Python function pythontest
test=#
I've also tried the pg-python language - in case it had something to do with
plpythonu:
CREATE OR REPLACE FUNCTION pgpython_test()
RETURNS text LANGUAGE python AS
$python$
import Postgres
import grass.script as grass
def main():
return (Hello World)
$python$;
test=# select pgpython_test();
ERROR: could not load Python function's module object
CONTEXT: [exception from Python]
Traceback (most recent call last):
File public.pgpython_test(), line 3, in module
ImportError: No module named grass.script
[public.pgpython_test() while loading function module]
test=#
I can however access GRASS from PostgreSQL9.1/PostGIS2.0 via pl/r and R.
For example, this function works...
CREATE OR REPLACE FUNCTION generate_viewshed() RETURNS text as
$$
library(spgrass6)
#initialise GRASS.
initGRASS(gisBase = ?/usr/local/grass-6.4.3svn/?, home = tempdir(),
gisDbase = ?/usr/local/share/grassdata/?, location =
?aust_dem_1sec_wgs84?, mapset = ?postgres?, SG=?aust_dem_1sec?,
override = TRUE)
#define the computational region for the analysis ? limiting the region to an
area slightly greater than the max_distance from the observation point.
execGRASS(?g.region?, parameters = list(n=?-34.9759927736275?, s=?-
34.9985728860995?, e=?138.641896696527?, w=?138.619947232807?,
align=?aust_dem_1sec?))
#run the viewshed module ? all of these parameters can be set dynamically
and parsed as plr function arguments ? the output is a raster file.
execGRASS(?r.viewshed?, parameters = list(input = ?aust_dem_1sec?,
output = ?viewshed_raster?, coordinate = ?138.630922,-34.987283?,
obs_elev = 25, max_dist = 1000), flags = c(?b?, ?overwrite?))
#convert the raster output to a vector.
execGRASS(?r.to.vect?, parameters = list(input = ?viewshed_raster?, output
= ?viewshed_vector?, feature = ?area?), flags = c(?overwrite?))
#write the vector data back to PostGIS.
execGRASS(?v.out.ogr?, parameters = list(input = ?viewshed_vector?, dsn =
?PG:host=localhost dbname=test user=postgres password=password?,
olayer = ?viewshed_vector
[GRASS-user] RE: Python scripts- How to call external bin [SEC=PERSONAL]
From: katrin eggert I want to integrate in a Python script a call to an external binary (a small fucntion that I have done). What can i use to do this? Python's subprocess module is the recommended way to do this for a generic external binary. - These thoughts are mine alone! - Andrew MacIntyre Operations Branch tel: +61 2 6219 5356 Communications Infrastructure Division fax: +61 2 6253 3277 Australian Communications Media Authority email: andrew.macint...@acma.gov.au http://www.acma.gov.au/ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] RE: grass-user Digest, Vol 61, Issue 42 [SEC=UNCLASSIFIED]
Date: Wed, 18 May 2011 14:53:25 +0200
From: Johannes Radinger jradin...@gmx.at
Subject: Re: [GRASS-user] Re: Using temp files in Grass Script
To: Glynn Clements gl...@gclements.plus.com
Cc: grass-user@lists.osgeo.org
Message-ID: 20110518125325.274...@gmx.net
Content-Type: text/plain; charset=utf-8
Original-Nachricht
Datum: Tue, 17 May 2011 13:11:41 +0100
Von: Glynn Clements gl...@gclements.plus.com
An: Johannes Radinger jradin...@gmx.at
CC: grass-user@lists.osgeo.org
Betreff: Re: [GRASS-user] Re: Using temp files in Grass Script
Johannes Radinger wrote:
I found that thread about temporary maps...
e.g in my case in my python script i use:
#Convert river from vector to raster format
grass.run_command(v.to.rast,
input = river_gen,
overwrite = True,
output = river_raster,
use = val,
value = res)
#Thinning the rastarized river
grass.run_command(r.thin,
input = river_raster,
overwrite = True,
output = river_raster_thin)
and here is the map river_raster only temporary for the thinning
process and the river_raster_thin is used for further calculations.
At the moment I have a g.remove to remove the river raster after
the thinning process but should I handle that with temporary files/maps
and if yes how is that exactly done in my python script?
1. In general, you should make an attempt at ensuring that temporary
map names won't conflict with any existing map name. The usual
approach is to include both .tmp and the PID in the map name, e.g.:
import os
...
global tmpmap
tmp_map = 'river_raster.tmp.%d' % os.getpid()
2. Deletion should ideally be handled using an exit handler, e.g.:
import os
import atexit
import grass.script as grass
tmp_map = None
def cleanup():
if tmp_map:
grass.run_command('g.remove', rast = tmp_map, quiet =
True)
def main():
global tmpmap
tmp_map = 'river_raster.tmp.%d' % os.getpid()
...
if __name__ == __main__:
options, flags = grass.parser()
atexit.register(cleanup)
main()
Using an exit handler ensures that the temporary map gets removed
regardless of how the script terminates (e.g. if it terminates due to
an exception).
Thank you for your nice examples how to do that with tmp files and the exit
handler.
Just some questions:
1) is the PID also used on windows systems? so can it be integrated in a
script
which also windows users want to use? Is it correct that the PID is the same
value for running the whole script one time?
2) what exactly does the global tmpmap?
3)I've got a lot of tmp-files which will be created during the process, so is
there and option to tell the g.remove that all maps containing .tmp.%d' %
os.getpid() in the end should be removed instead of typing all the tmp map
files into the list of g.remove.
4) so the whole thing works that in the end all the tmp maps are deleted
after the processing of the script and after an exception etc.
Rather than use a simple global variable as per Glynn's example, use a list:
tmp_map = []
Any time you create a temporary file name, append it to the list:
tmp_fn = '...'
tmp_map.append(tmp_fn)
In your cleanup handler, scan the list:
def cleanup():
while tmp_map:
tfn = tmp_map.pop()
grass.run_command('g.remove', rast = tfn, quiet = True)
Using a list like this removes the need for the global statements, as you only
manipulate the list rather than assign new objects to the global variable.
- These thoughts are mine alone! -
Andrew MacIntyre Operations Branch
tel: +61 2 6219 5356 Communications Infrastructure Division
fax: +61 2 6253 3277 Australian Communications Media Authority
email: andrew.macint...@acma.gov.auhttp://www.acma.gov.au/
NOTICE: This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
RE: [GRASS-user] Mac Requirements for GRASS [SEC=UNCLASSIFIED]
Tuesday, 22 June 2010 7:33 AM, William Kyngesburye wrote to Andrew Lewin: - memory size and speed - again, with the heavy use of temp files, faster and/or more memory may not help much. Though there are some things that can chew up a lot of memory. Memory is cheap. The memory speed between the current line of MacBooks, MacBook Pros, iMacs and Mac Pros are all the same, 1066MHz, so no real speed gain there. Memory maximum in the MacBooks and Pros is 8GB, vs 16GB in the iMacs and Mac Pros. Memory can sometimes be very useful even for a temp-file architected application like GRASS - a RAM disk or swap-backed file system can be very worthwhile in some situations when memory is plentiful. - These thoughts are mine alone! - Andrew MacIntyre Operations Branch tel: +61 2 6219 5356 Communications Infrastructure Division fax: +61 2 6253 3277 Australian Communications Media Authority email: andrew.macint...@acma.gov.au http://www.acma.gov.au/ If you have received this email in error, please notify the sender immediately and erase all copies of the email and any attachments to it. The information contained in this email and any attachments may be private, confidential and legally privileged or the subject of copyright. If you are not the addressee it may be illegal to review, disclose, use, forward, or distribute this email and/or its contents. Unless otherwise specified, the information in the email and any attachments is intended as a guide only and should not be relied upon as legal or technical advice or regarded as a substitute for legal or technical advice in individual cases. Opinions contained in this email or any of its attachments do not necessarily reflect the opinions of ACMA. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
RE: [GRASS-user] Import, project [SEC=PERSONAL]
Nikos Alexandris wrote: If I am not wrong even under @rc-gis the .prj is required to work properly. No, the .prj is not required but without it the dataset's coordinate system is undefined. The .prj file for a shapefile is in WKT (well known text) format, and generally the coordinate system details should be easily identifiable. - These thoughts are mine alone! - Andrew MacIntyre Operations Branch tel: +61 2 6219 5356 Communications Infrastructure Division fax: +61 2 6253 3277 Australian Communications Media Authority email: andrew.macint...@acma.gov.au http://www.acma.gov.au/ -Original Message- From: grass-user-boun...@lists.osgeo.org [mailto:grass-user- boun...@lists.osgeo.org] On Behalf Of Nikos Alexandris Sent: Friday, 18 June 2010 10:39 AM To: grass-user@lists.osgeo.org Subject: Re: [GRASS-user] Import, project (Apologies for the interference...) Hamish: you have to create a GRASS Location for each source map projection, then pull them all into the target Location with r.proj or v.proj. But in my (apparently very naive) view I this is completely not the point. If I have to use esri anyway then why bother taking data into grass ?? There are several reasons why one can/should use grass. Long discussion. To make the long story short, there are links which might be of your interest [1] [2][3]. If you are convinced that F(L)OSS is the way to go, then you have a *STRONG* reason to stick with grass and/or other open geo-spatial tools. What I would think is this: If I can find out the projection/coordinates etc of the shapefile by any manual means then this info MUST BE included in the shapefile itself. Along with the actual geodata. I think these infos are not integrated in the file. More so the import-program within grass cannot import even a single byte without thorough knowledge of the imported format, but i seems that it can only read objects but not their coordinate-system. grass-gis (in its entirety) is strict and clean, an honest friend which you can rely on, discuss, learn and find the way. So: If all the info is already in the shapefile there then why 1) do I have to manually find it by some way outside grass and 2) why doesn't the import-program simply read that info from the file, read the coordinates and projection from the current location and the call the appropriate projection-program to reproject the imported file to fit the current location. All the infos (proj/coord/bounds/etc) of import and target are there (says the naive man :-) It would useful/helpful to feed the list with the actual information (filenames for example) that are beforehand. If those are there (as separate files, which is the way they should exist) then it should fairly easy and strait to import the data clean(ly) in grass' database. , the sequence of operations is completely obvious and always exactly the same and yet everything has to be done manually. If I want to recode a moviefile to another format I tell the encoder what I want to have as an output and the encoder then looks by itself what format the original has. What is different about geodata ? I don't really mind doing that for one map. But somehow I expect lots more maps from different sources being added later and each one causing lots of work. What is it I don't understand here? 3) how to export an ascii/excel/csv-list of every raster-point with a) the corresponding scalar and b) the administrative region and c) the coordinates lat/long of the raster-point r.out.xyz, or r.to.vect + v.out.ascii maybe with some other custom magic along the way. Thanks, that sounds promising. I will try ASAP. from the command line GDAL's ogr2ogr and gdalwarp can reproject shapefiles and GeoTiffs etc directly. Tried that (on ubuntu) : u...@nb ~ $ gdalwarp file1.shp file1.out ERROR 4: `file1.shp' not recognised as a supported file format. and: gdalwrap --formats lists 88 formats including a few from esri, but no shapefile. hint: check the output of ogrinfo --formats ( gdal is a library of tools that handle raster data [4]. ogr tools are for vector stuff [5]. ) Good luck, Nikos --- [1] http://grass.osgeo.org/intro/firsttime.php [2] http://www.gnu.org/philosophy/categories.html [3] http://www.dwheeler.com/oss_fs_why.html [4] http://www.gdal.org/ and http://www.gdal.org/gdal_utilities.html [5] http://www.gdal.org/ogr/ and http://www.gdal.org/ogr_utilities.html ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user If you have received this email in error, please notify the sender immediately and erase all copies of the email and any attachments to it. The information contained in this email and any attachments
RE: [GRASS-user] Question with Python-SWIG example [SEC=UNCLASSIFIED]
From: Glynn Clements I also found ctypesgen: http://code.google.com/p/ctypesgen/ I finally got around to looking at this, and it took less than half an hour to generate working bindings. Obviously, it will need more testing, but unless any insurmountable problems show up, I intend to using this in place of SWIG. Glad you found something that you're comfortable with, and that the effort required appears to be so modest. Also, I've discovered that NumPy arrays have conversion methods, e.g. p = buf.ctypes.data_as(POINTER(raster.CELL)) One caveat: this *doesn't* appear to increment the reference count, so if you do e.g.: buf = buf.ctypes.data_as(POINTER(raster.CELL)) the array will be gc'd resulting in buf pointing at garbage. This sort of issue is something that catches people in Python (especially when using ctypes) until they learn what needs to be preserved - its sometimes easy to lose sight of whether you've got deep copies or shallow copies of the original. I haven't tried using ctypesgen for C++, though. The material on the above website makes no mention of C++... Regards, Andrew. - These thoughts are mine alone! - Andrew MacIntyre Operations Branch tel: +61 2 6219 5356 Communications Infrastructure Division fax: +61 2 6253 3277 Australian Communications Media Authority email: andrew.macint...@acma.gov.auhttp://www.acma.gov.au/ If you have received this email in error, please notify the sender immediately and erase all copies of the email and any attachments to it. The information contained in this email and any attachments may be private, confidential and legally privileged or the subject of copyright. If you are not the addressee it may be illegal to review, disclose, use, forward, or distribute this email and/or its contents. Unless otherwise specified, the information in the email and any attachments is intended as a guide only and should not be relied upon as legal or technical advice or regarded as a substitute for legal or technical advice in individual cases. Opinions contained in this email or any of its attachments do not necessarily reflect the opinions of ACMA. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
RE: [GRASS-user] Question with Python-SWIG example [SEC=UNCLASSIFIED]
-Original Message- From: Glynn Clements [mailto:gl...@gclements.plus.com] Sent: Wednesday, 12 May 2010 1:43 AM To: Andrew MacIntyre Cc: GRASS user list; grass-...@lists.osgeo.org Subject: RE: [GRASS-user] Question with Python-SWIG example [SEC=UNCLASSIFIED] Andrew MacIntyre wrote: From the SWIG examples I inferred the following type references for the pointers in question: CELL* = SWIGTYPE_p_CELL FCELL* = SWIGTYPE_p_FCELL DCELL* = SWIGTYPE_p_DCELL provided that CELL*/FCELL*/DCELL* are typedef'ed. So I expected that in pyobj_to_ptr() you could do something like But I still don't see what happens when a function returns a CELL* which is subsequently passed to a function accepting a void*, or vice-versa. This is common enough that if SWIG can't handle it, we need to use something other than SWIG. That seems to be what the SWIG Pointer Library function ptrcast() is for, according to http://www.swig.org/Doc1.1/HTML/Typemaps.html, so something like (in Python): import GrassMod pCELL = GrassMod.Returns_CELLptr() pvoid = GrassMod.castptr(pCELL, void *) result = GrassMod.Takes_voidptr(pvoid) (substitute the correct name of the GRASS SWIG module for GrassMod) If you decide to investigate using ctypes, the following links might be of interest: - http://starship.python.net/crew/theller/ctypes/old/codegen.html AFAICT, this has been superseded by ctypeslib: http://pypi.python.org/pypi/ctypeslib/ Thanks, the old page was something I had bookmarked. - http://www.language-binding.net/pygccxml/pygccxml.html I wasn't aware of this one. I also found ctypesgen: http://code.google.com/p/ctypesgen/ And that one's new to me, for which thanks. Cheers, Andrew. - These thoughts are mine alone! - Andrew MacIntyre Operations Branch tel: +61 2 6219 5356 Communications Infrastructure Division fax: +61 2 6253 3277 Australian Communications Media Authority email: andrew.macint...@acma.gov.auhttp://www.acma.gov.au/ If you have received this email in error, please notify the sender immediately and erase all copies of the email and any attachments to it. The information contained in this email and any attachments may be private, confidential and legally privileged or the subject of copyright. If you are not the addressee it may be illegal to review, disclose, use, forward, or distribute this email and/or its contents. Unless otherwise specified, the information in the email and any attachments is intended as a guide only and should not be relied upon as legal or technical advice or regarded as a substitute for legal or technical advice in individual cases. Opinions contained in this email or any of its attachments do not necessarily reflect the opinions of ACMA. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
RE: [GRASS-user] Question with Python-SWIG example [SEC=UNCLASSIFIED]
Bah! typo... But I still don't see what happens when a function returns a CELL* which is subsequently passed to a function accepting a void*, or vice-versa. This is common enough that if SWIG can't handle it, we need to use something other than SWIG. That seems to be what the SWIG Pointer Library function ptrcast() is for, according to http://www.swig.org/Doc1.1/HTML/Typemaps.html, so something like (in Python): import GrassMod pCELL = GrassMod.Returns_CELLptr() pvoid = GrassMod.castptr(pCELL, void *) above line should read: pvoid = GrassMod.ptrcast(pCELL, void *) result = GrassMod.Takes_voidptr(pvoid) (substitute the correct name of the GRASS SWIG module for GrassMod) Cheers, Andrew. - These thoughts are mine alone! - Andrew MacIntyre Operations Branch tel: +61 2 6219 5356 Communications Infrastructure Division fax: +61 2 6253 3277 Australian Communications Media Authority email: andrew.macint...@acma.gov.auhttp://www.acma.gov.au/ If you have received this email in error, please notify the sender immediately and erase all copies of the email and any attachments to it. The information contained in this email and any attachments may be private, confidential and legally privileged or the subject of copyright. If you are not the addressee it may be illegal to review, disclose, use, forward, or distribute this email and/or its contents. Unless otherwise specified, the information in the email and any attachments is intended as a guide only and should not be relied upon as legal or technical advice or regarded as a substitute for legal or technical advice in individual cases. Opinions contained in this email or any of its attachments do not necessarily reflect the opinions of ACMA. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
RE: [GRASS-user] Question with Python-SWIG example [SEC=UNCLASSIFIED]
That seems to be what the SWIG Pointer Library function ptrcast() is for, according to http://www.swig.org/Doc1.1/HTML/Typemaps.html, so something like (in Python): import GrassMod pCELL = GrassMod.Returns_CELLptr() pvoid = GrassMod.castptr(pCELL, void *) above line should read: pvoid = GrassMod.ptrcast(pCELL, void *) result = GrassMod.Takes_voidptr(pvoid) (substitute the correct name of the GRASS SWIG module for GrassMod) Just noticed that the docco I referenced was for SWIG 1.1, so the above is probably moot. However, the 2nd para of s5.3.2 of the SWIG 1.3 documentation at http://www.swig.org/Doc1.3/SWIG.html#SWIG_nn17 states Like C, void * matches any kind of pointer. which suggests to me that the casts from CELL*/FCELL*/DCELL to void* would be implicitly performed anyway - be worth testing. Cheers, Andrew. - These thoughts are mine alone! - Andrew MacIntyre Operations Branch tel: +61 2 6219 5356 Communications Infrastructure Division fax: +61 2 6253 3277 Australian Communications Media Authority email: andrew.macint...@acma.gov.auhttp://www.acma.gov.au/ If you have received this email in error, please notify the sender immediately and erase all copies of the email and any attachments to it. The information contained in this email and any attachments may be private, confidential and legally privileged or the subject of copyright. If you are not the addressee it may be illegal to review, disclose, use, forward, or distribute this email and/or its contents. Unless otherwise specified, the information in the email and any attachments is intended as a guide only and should not be relied upon as legal or technical advice or regarded as a substitute for legal or technical advice in individual cases. Opinions contained in this email or any of its attachments do not necessarily reflect the opinions of ACMA. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
RE: [GRASS-user] Question with Python-SWIG example [SEC=UNCLASSIFIED]
From: Glynn Clements
Andrew MacIntyre wrote:
In the case where SWIG is using its own objects to contain
returned
pointers, then I expect pyobj_to_ptr() needs to be changed to
use
SWIG_ConvertPtr() rather than PyCObject_AsVoidPtr() to retrieve
the
actual pointer, or the output typemaps for returned pointers
need to be
changed to use Python's CObjects rather than native SWIG wrapper
objects.
So, what do you suggest? Remove the PyCObject_Check() call,
explicitly
check for string, read buffer, write buffer, and sequence, then
call
SWIG_ConvertPtr() on anything which is left over?
That's what I would try.
Except ... SWIG_ConvertPtr() seems to require that you have access to
the type descriptor. The documentation seems to suggest (although, as
usual, it's unclear) that you need to know the actual type.
From the SWIG examples I inferred the following type references for
the pointers in question:
CELL* = SWIGTYPE_p_CELL
FCELL* = SWIGTYPE_p_FCELL
DCELL* = SWIGTYPE_p_DCELL
provided that CELL*/FCELL*/DCELL* are typedef'ed.
So I expected that in pyobj_to_ptr() you could do something like
int rc;
void *ptr;
...
switch (type_parm) {
case CELL_PTR:
rc = SWIG_ConvertPtr(PyObj, ptr,
SWIGTYPE_p_CELL, SWIG_POINTER_EXCEPTION);
break;
case FCELL_PTR:
rc = SWIG_ConvertPtr(PyObj, ptr,
SWIGTYPE_p_FCELL, SWIG_POINTER_EXCEPTION);
break;
case DCELL_PTR:
rc = SWIG_ConvertPtr(PyObj, ptr,
SWIGTYPE_p_DCELL, SWIG_POINTER_EXCEPTION);
break;
}
if (rc == -1)
return NULL;
...
type_parm is the type code parameter passed in to pyobj_to_ptr() - I
don't
have a link to the swig file to check the actual parameter name.
I don't think you need to get rid of the typemap - I suspect you
might
have to expand it to distinguish between the different types of
pointers
though (see below)...
I get the impression from the above linked documentation that, for
example, there should be an explicit typemap reference for CELL
pointers
(as returned by Rast_allocate_c_buf()) and that the typemap for CELL
pointers as an input argument should use SWIG_ConvertPtr(), which
will
set an exception if the inbound object is not a suitable input
GRASS uses void * to refer to any of CELL*/FCELL*/DCELL* quite
extensively.
I think that I'm not going to put any more effort into the SWIG
wrapper unless usable documentation materialises. In the meantime, I'm
going to look for alternatives.
If you decide to investigate using ctypes, the following links might be
of interest:
- http://starship.python.net/crew/theller/ctypes/old/codegen.html
- http://www.language-binding.net/pygccxml/pygccxml.html
The latter seems more focussed on C++. I haven't used either so can't
give
any guidance.
Cheers,
Andrew.
- These thoughts are mine alone! -
Andrew MacIntyre Operations Branch
tel: +61 2 6219 5356 Communications Infrastructure Division
fax: +61 2 6253 3277 Australian Communications Media Authority
email: andrew.macint...@acma.gov.auhttp://www.acma.gov.au/
If you have received this email in error, please notify the sender immediately
and erase all copies of the email and any attachments to it. The information
contained in this email and any attachments may be private, confidential and
legally privileged or the subject of copyright. If you are not the addressee it
may be illegal to review, disclose, use, forward, or distribute this email
and/or its contents.
Unless otherwise specified, the information in the email and any attachments is
intended as a guide only and should not be relied upon as legal or technical
advice or regarded as a substitute for legal or technical advice in individual
cases. Opinions contained in this email or any of its attachments do not
necessarily reflect the opinions of ACMA.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
RE: [GRASS-user] Question with Python-SWIG example [SEC=UNCLASSIFIED]
From: Glynn Clements Andrew MacIntyre wrote: In the case where SWIG is using its own objects to contain returned pointers, then I expect pyobj_to_ptr() needs to be changed to use SWIG_ConvertPtr() rather than PyCObject_AsVoidPtr() to retrieve the actual pointer, or the output typemaps for returned pointers need to be changed to use Python's CObjects rather than native SWIG wrapper objects. So, what do you suggest? Remove the PyCObject_Check() call, explicitly check for string, read buffer, write buffer, and sequence, then call SWIG_ConvertPtr() on anything which is left over? That's what I would try. Cheers, Andrew. - These thoughts are mine alone! - Andrew MacIntyre Operations Branch tel: +61 2 6219 5356 Communications Infrastructure Division fax: +61 2 6253 3277 Australian Communications Media Authority email: andrew.macint...@acma.gov.auhttp://www.acma.gov.au/ If you have received this email in error, please notify the sender immediately and erase all copies of the email and any attachments to it. The information contained in this email and any attachments may be private, confidential and legally privileged or the subject of copyright. If you are not the addressee it may be illegal to review, disclose, use, forward, or distribute this email and/or its contents. Unless otherwise specified, the information in the email and any attachments is intended as a guide only and should not be relied upon as legal or technical advice or regarded as a substitute for legal or technical advice in individual cases. Opinions contained in this email or any of its attachments do not necessarily reflect the opinions of ACMA. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
RE: FW: [GRASS-user] Question with Python-SWIG example [SEC=UNCLASSIFIED]
Sorry for this incomplete message - it was intended as a note to self (at another email address) about a more complete response and I didn't catch that it would be sent to the list. Andrew. - These thoughts are mine alone! - Andrew MacIntyre Operations Branch tel: +61 2 6219 5356 Communications Infrastructure Division fax: +61 2 6253 3277 Australian Communications Media Authority email: andrew.macint...@acma.gov.au http://www.acma.gov.au/ -Original Message- From: Andrew MacIntyre [mailto:andy...@bullseye.apana.org.au] Sent: Monday, 3 May 2010 11:05 PM To: Andrew MacIntyre Subject: Re: FW: [GRASS-user] Question with Python-SWIG example [SEC=UNCLASSIFIED] Andrew MacIntyre wrote: - These thoughts are mine alone! - Andrew MacIntyre Operations Branch tel: +61 2 6219 5356 Communications Infrastructure Division fax: +61 2 6253 3277 Australian Communications Media Authority email: andrew.macint...@acma.gov.auhttp://www.acma.gov.au/ -Original Message- From: Glynn Clements [mailto:gl...@gclements.plus.com] Sent: Saturday, 24 April 2010 2:34 AM To: Andrew MacIntyre Cc: GRASS user list Subject: RE: [GRASS-user] Question with Python-SWIG example [SEC=UNCLASSIFIED] Andrew MacIntyre wrote: That's what I suspect, namely that the typemap for pointers is getting in the way. Removing the typemap would mean that you couldn't pass a Python string, array, buffer, sequence, etc directly to a GRASS function, but would have to explicitly allocate and populate a block of memory. I don't think you need to get rid of the typemap - I suspect you might have to expand it to distinguish between the different types of pointers though (see below)... Yes, but I know how to get rid of it; I don't know how to expand it. In the SWIG wrapper? I see a note about SWIG_ConvertPtr() in http://www.swig.org/Doc1.3/Python.html#Python_nn64 ? That might help, although I still don't know how to test whether a given PyObject * is a SWIG-wrapped pointer. I get the impression from the above linked documentation that, for example, there should be an explicit typemap reference for CELL pointers (as returned by Rast_allocate_c_buf()) and that the typemap for CELL pointers as an input argument should use SWIG_ConvertPtr(), which will set an exception if the inbound object is not a suitable input (if the exception flag is used; returning NULL will then propagate the exception). As far as SWIGged pointers go, this seems to be the closest you can get to Python's *Check* APIs. But does that convert arrays, buffers, etc? FWIW, the typemaps are in swig/include/python/my_typemaps.i. -- Glynn Clements gl...@gclements.plus.com If you have received this email in error, please notify the sender immediately and erase all copies of the email and any attachments to it. The information contained in this email and any attachments may be private, confidential and legally privileged or the subject of copyright. If you are not the addressee it may be illegal to review, disclose, use, forward, or distribute this email and/or its contents. Unless otherwise specified, the information in the email and any attachments is intended as a guide only and should not be relied upon as legal or technical advice or regarded as a substitute for legal or technical advice in individual cases. Opinions contained in this email or any of its attachments do not necessarily reflect the opinions of ACMA. see pyobj_to_ptr() in typemap - what is being expected in the CObject case? - should this be changed to use above linked APIs to extract pointers from SWIGged pointer objects? (can't see a typemap that converts a returned pointer to a CObject). -- - Andrew I MacIntyre These thoughts are mine alone... E-mail: andy...@bullseye.apana.org.au (pref) | Snail: PO Box 370 andy...@pcug.org.au (alt) |Belconnen ACT 2616 Web:http://www.andymac.org/ |Australia If you have received this email in error, please notify the sender immediately and erase all copies of the email and any attachments to it. The information contained in this email and any attachments may be private, confidential and legally privileged or the subject of copyright. If you are not the addressee it may be illegal to review, disclose, use, forward, or distribute this email and/or its contents. Unless otherwise specified, the information in the email and any attachments is intended as a guide only and should not be relied upon as legal or technical advice or regarded as a substitute for legal or technical advice in individual cases. Opinions contained in this email or any of its attachments do
RE: [GRASS-user] Question with Python-SWIG example [SEC=UNCLASSIFIED]
From: Glynn Clements [mailto:gl...@gclements.plus.com] Sent: Saturday, 24 April 2010 2:34 AM To: Andrew MacIntyre Cc: GRASS user list Subject: RE: [GRASS-user] Question with Python-SWIG example [SEC=UNCLASSIFIED] Andrew MacIntyre wrote: That's what I suspect, namely that the typemap for pointers is getting in the way. Removing the typemap would mean that you couldn't pass a Python string, array, buffer, sequence, etc directly to a GRASS function, but would have to explicitly allocate and populate a block of memory. I don't think you need to get rid of the typemap - I suspect you might have to expand it to distinguish between the different types of pointers though (see below)... Yes, but I know how to get rid of it; I don't know how to expand it. In the SWIG wrapper? I see a note about SWIG_ConvertPtr() in http://www.swig.org/Doc1.3/Python.html#Python_nn64 ? That might help, although I still don't know how to test whether a given PyObject * is a SWIG-wrapped pointer. I get the impression from the above linked documentation that, for example, there should be an explicit typemap reference for CELL pointers (as returned by Rast_allocate_c_buf()) and that the typemap for CELL pointers as an input argument should use SWIG_ConvertPtr(), which will set an exception if the inbound object is not a suitable input (if the exception flag is used; returning NULL will then propagate the exception). As far as SWIGged pointers go, this seems to be the closest you can get to Python's *Check* APIs. But does that convert arrays, buffers, etc? FWIW, the typemaps are in swig/include/python/my_typemaps.i. I finally had the chance to look at this last night. I think the issue is that pyobj_to_ptr() in my_typemaps.i is expecting the SWIGged pointer as a Python CObject (though it does seem odd that a pointer object, previously returned from a SWIGged call, being passed in is at least accepted without a ValueError - which suggests that these objects are at least look like CObjects to Python). I would suggest that this isn't correct unless you can determine that SWIG is definitely generating CObjects to contain returned pointers (I couldn't find anything to suggest this). In the case where SWIG is using its own objects to contain returned pointers, then I expect pyobj_to_ptr() needs to be changed to use SWIG_ConvertPtr() rather than PyCObject_AsVoidPtr() to retrieve the actual pointer, or the output typemaps for returned pointers need to be changed to use Python's CObjects rather than native SWIG wrapper objects. Several other approaches occur to me: - use simple SWIG typemaps for the various pointer types and create helper functions which translate from Python objects to GRASS data structures and vice versa. It might be possible to use ctypes objects too, though that could be quite tricky as I couldn't find any direct API support. - go to the trouble of actually creating full Python object wrappers for the various data structures and use them exclusively instead of using thinly wrapped pointers (this has the potential advantage that memory management becomes a lot more automatic for the user). - ditch SWIG completely for Python and use ctypes exclusively. The ctypes approach is the one I myself would take, but I acknowledge there are downsides - the potential for sub-optimal performance in certain cases and the cost of initially generating the wrapper definitions being the most obvious. I haven't tried the gccxml based code generator that ctypes author Thomas Heller created, which might make the job a lot easier if it works on the GRASS headers. I suspect that the output typemaps change might be easiest to implement. Cheers, Andrew. - These thoughts are mine alone! - Andrew MacIntyre Operations Branch tel: +61 2 6219 5356 Communications Infrastructure Division fax: +61 2 6253 3277 Australian Communications Media Authority email: andrew.macint...@acma.gov.auhttp://www.acma.gov.au/ If you have received this email in error, please notify the sender immediately and erase all copies of the email and any attachments to it. The information contained in this email and any attachments may be private, confidential and legally privileged or the subject of copyright. If you are not the addressee it may be illegal to review, disclose, use, forward, or distribute this email and/or its contents. Unless otherwise specified, the information in the email and any attachments is intended as a guide only and should not be relied upon as legal or technical advice or regarded as a substitute for legal or technical advice in individual cases. Opinions contained in this email or any of its attachments do not necessarily reflect the opinions of ACMA. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman
RE: [GRASS-user] Question with Python-SWIG example [SEC=UNCLASSIFIED]
From: Glynn Clements Andrew MacIntyre wrote: That was what I tried first, but it results in Rast_get_c_row() segfaulting. Then it seems to me that there's some problem with the SWIG wrapper for Rast_get_c_row(), if it won't accept a valid SWIG pointer object returned from another wrapped function. That's what I suspect, namely that the typemap for pointers is getting in the way. Removing the typemap would mean that you couldn't pass a Python string, array, buffer, sequence, etc directly to a GRASS function, but would have to explicitly allocate and populate a block of memory. I don't think you need to get rid of the typemap - I suspect you might have to expand it to distinguish between the different types of pointers though (see below)... There is a typemap for pointers, which converts a CObject, string, buffer or sequence. I have no idea how to test for or convert a SWIG-wrapped pointer. In the SWIG wrapper? I see a note about SWIG_ConvertPtr() in http://www.swig.org/Doc1.3/Python.html#Python_nn64 ? That might help, although I still don't know how to test whether a given PyObject * is a SWIG-wrapped pointer. I get the impression from the above linked documentation that, for example, there should be an explicit typemap reference for CELL pointers (as returned by Rast_allocate_c_buf()) and that the typemap for CELL pointers as an input argument should use SWIG_ConvertPtr(), which will set an exception if the inbound object is not a suitable input (if the exception flag is used; returning NULL will then propagate the exception). As far as SWIGged pointers go, this seems to be the closest you can get to Python's *Check* APIs. Cheers, Andrew. - These thoughts are mine alone! - Andrew MacIntyre Operations Branch tel: +61 2 6219 5356 Communications Infrastructure Division fax: +61 2 6253 3277 Australian Communications Media Authority email: andrew.macint...@acma.gov.auhttp://www.acma.gov.au/ If you have received this email in error, please notify the sender immediately and erase all copies of the email and any attachments to it. The information contained in this email and any attachments may be private, confidential and legally privileged or the subject of copyright. If you are not the addressee it may be illegal to review, disclose, use, forward, or distribute this email and/or its contents. Unless otherwise specified, the information in the email and any attachments is intended as a guide only and should not be relied upon as legal or technical advice or regarded as a substitute for legal or technical advice in individual cases. Opinions contained in this email or any of its attachments do not necessarily reflect the opinions of ACMA. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
RE: [GRASS-user] Question with Python-SWIG example [SEC=UNCLASSIFIED]
From: Glynn Clements Andrew MacIntyre wrote: After some googling, it seems that the pointer address should be obtainable by using int() on the pointer object returned by the SWIG wrapper (i.e. int(p) in the above example), with the resulting value usable in ctypes' from_address() method. I might be wrong, but I think that e.g. ctypes.c_void_p(int(p)) might also work to create a ctypes void pointer instance. That doesn't seem to work either: import grass.lib.grass as gis import grass.lib.raster as rast import ctypes gis.G_gisinit() p = rast.Rast_allocate_c_buf() a = ctypes.cast(int(p), ctypes.POINTER(ctypes.c_int)) infd = rast.Rast_open_old(elevation.dem, ) rast.Rast_get_c_row(infd, a, 10) I think the above line should read: rast. Rast_get_c_row(infd, p, 10) That was what I tried first, but it results in Rast_get_c_row() segfaulting. Then it seems to me that there's some problem with the SWIG wrapper for Rast_get_c_row(), if it won't accept a valid SWIG pointer object returned from another wrapped function. There is a typemap for pointers, which converts a CObject, string, buffer or sequence. I have no idea how to test for or convert a SWIG-wrapped pointer. In the SWIG wrapper? I see a note about SWIG_ConvertPtr() in http://www.swig.org/Doc1.3/Python.html#Python_nn64 ? The fact that passing a doesn't segfault appears to indicate that it was successfully converted to a pointer. The fact that accessing a[0] afterwards leads me to suspect that it may be getting converted to a pointer to the container rather than to the array proper. Well, a is a ctypes object, so I wouldn't have expected a useful coercion. Sadly, I doubt I can contribute much more to this matter :( Andrew. - These thoughts are mine alone! - Andrew MacIntyre Operations Branch tel: +61 2 6219 5356 Communications Infrastructure Division fax: +61 2 6253 3277 Australian Communications Media Authority email: andrew.macint...@acma.gov.auhttp://www.acma.gov.au/ If you have received this email in error, please notify the sender immediately and erase all copies of the email and any attachments to it. The information contained in this email and any attachments may be private, confidential and legally privileged or the subject of copyright. If you are not the addressee it may be illegal to review, disclose, use, forward, or distribute this email and/or its contents. Unless otherwise specified, the information in the email and any attachments is intended as a guide only and should not be relied upon as legal or technical advice or regarded as a substitute for legal or technical advice in individual cases. Opinions contained in this email or any of its attachments do not necessarily reflect the opinions of ACMA. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
RE: [GRASS-user] Question with Python-SWIG example [SEC=UNCLASSIFIED]
[Oops - original inadvertently sent only to Glynn, again :-(] From: Glynn Clements Andrew MacIntyre wrote: After some googling, it seems that the pointer address should be obtainable by using int() on the pointer object returned by the SWIG wrapper (i.e. int(p) in the above example), with the resulting value usable in ctypes' from_address() method. I might be wrong, but I think that e.g. ctypes.c_void_p(int(p)) might also work to create a ctypes void pointer instance. That doesn't seem to work either: import grass.lib.grass as gis import grass.lib.raster as rast import ctypes gis.G_gisinit() p = rast.Rast_allocate_c_buf() a = ctypes.cast(int(p), ctypes.POINTER(ctypes.c_int)) infd = rast.Rast_open_old(elevation.dem, ) rast.Rast_get_c_row(infd, a, 10) I think the above line should read: rast. Rast_get_c_row(infd, p, 10) a[0] Then this might work. - These thoughts are mine alone! - Andrew MacIntyre Operations Branch tel: +61 2 6219 5356 Communications Infrastructure Division fax: +61 2 6253 3277 Australian Communications Media Authority email: andrew.macint...@acma.gov.au http://www.acma.gov.au/ If you have received this email in error, please notify the sender immediately and erase all copies of the email and any attachments to it. The information contained in this email and any attachments may be private, confidential and legally privileged or the subject of copyright. If you are not the addressee it may be illegal to review, disclose, use, forward, or distribute this email and/or its contents. Unless otherwise specified, the information in the email and any attachments is intended as a guide only and should not be relied upon as legal or technical advice or regarded as a substitute for legal or technical advice in individual cases. Opinions contained in this email or any of its attachments do not necessarily reflect the opinions of ACMA. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
RE: [GRASS-user] Question with Python-SWIG example [SEC=UNCLASSIFIED]
[Oops - original inadvertently sent only to Glynn]
From: Glynn Clements [mailto:gl...@gclements.plus.com]
Andrew MacIntyre wrote:
Glynn Clements wrote:
{...}
Nor can I figure out how to make use of any pointers returned from
functions. Typemaps exist to allow strings, arrays, etc to be
converted to pointers when passing them into functions, but it
isn't possible to do the reverse (converting to a pointer discards
the size and type; converting from a pointer would require some
way to obtain this information). The functions generated by
cpointer.i and carrays.i don't seem to work as expected (I get a
segfault).
Doesn't the ctypes cast() function work for you in making use of
returned pointers?
In case it wasn't clear, I was talking about SWIG-wrapped pointers,
e.g.:
import grass.lib.raster as rast
import grass.lib.grass as gis
import ctypes
gis.G_gisinit()
p = rast.Rast_allocate_c_buf()
p
Swig Object of type 'int *' at 0x912e5b8
q = ctypes.cast(p, ctypes.c_void_p)
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib/python2.6/ctypes/__init__.py, line 489, in cast
return _cast(obj, obj, typ)
ctypes.ArgumentError: argument 1: type 'exceptions.TypeError': wrong
type
Ahh, sorry for not paying close enough attention.
I've never used SWIG and don't profess to understand exactly what its
returning in the code for _wrap_Rast_allocate_c_buf in raster_wrap.c
(~line 12530).
If the pointer object being made available in Python can be made to
publish the pointer address, then the from_address() method of the
target ctypes type (such as a structure) can be used.
After some googling, it seems that the pointer address should be
obtainable by using int() on the pointer object returned by the SWIG
wrapper (i.e. int(p) in the above example), with the resulting value
usable in ctypes' from_address() method. I might be wrong, but I think
that e.g. ctypes.c_void_p(int(p)) might also work to create a ctypes
void pointer instance.
- These thoughts are mine alone! -
Andrew MacIntyre Operations Branch
tel: +61 2 6219 5356 Communications Infrastructure Division
fax: +61 2 6253 3277 Australian Communications Media Authority
email: andrew.macint...@acma.gov.auhttp://www.acma.gov.au/
If you have received this email in error, please notify the sender immediately
and erase all copies of the email and any attachments to it. The information
contained in this email and any attachments may be private, confidential and
legally privileged or the subject of copyright. If you are not the addressee it
may be illegal to review, disclose, use, forward, or distribute this email
and/or its contents.
Unless otherwise specified, the information in the email and any attachments is
intended as a guide only and should not be relied upon as legal or technical
advice or regarded as a substitute for legal or technical advice in individual
cases. Opinions contained in this email or any of its attachments do not
necessarily reflect the opinions of ACMA.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
RE: [GRASS-user] Question with Python-SWIG example [SEC=UNCLASSIFIED]
Glynn Clements wrote:
{...}
Nor can I figure out how to make use of any pointers returned from
functions. Typemaps exist to allow strings, arrays, etc to be
converted to pointers when passing them into functions, but it isn't
possible to do the reverse (converting to a pointer discards the size
and type; converting from a pointer would require some way to obtain
this information). The functions generated by cpointer.i and carrays.i
don't seem to work as expected (I get a segfault).
Doesn't the ctypes cast() function work for you in making use of
returned pointers?
- These thoughts are mine alone! -
Andrew MacIntyre Operations Branch
tel: +61 2 6219 5356 Communications Infrastructure Division
fax: +61 2 6253 3277 Australian Communications Media Authority
email: andrew.macint...@acma.gov.auhttp://www.acma.gov.au/
If you have received this email in error, please notify the sender immediately
and erase all copies of the email and any attachments to it. The information
contained in this email and any attachments may be private, confidential and
legally privileged or the subject of copyright. If you are not the addressee it
may be illegal to review, disclose, use, forward, or distribute this email
and/or its contents.
Unless otherwise specified, the information in the email and any attachments is
intended as a guide only and should not be relied upon as legal or technical
advice or regarded as a substitute for legal or technical advice in individual
cases. Opinions contained in this email or any of its attachments do not
necessarily reflect the opinions of ACMA.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
RE: [GRASS-user] bus error in v.in.ogr [SEC=PERSONAL]
A bus error is usually either an incorrectly aligned memory access or an attempt to access a memory address not in the process' memory map. I've mostly seen this when processes run out of stack space. If the cleaning process uses recursive code, that could be a source of a stack overflow. You might check your session limits to see how much stack space is permitted for each process. - These thoughts are mine alone! - Andrew MacIntyre National Licensing and Allocations Branch tel: +61 2 6219 5356 Inputs to Industry Division fax: +61 2 6253 3277 Australian Communications Media Authority email: andrew.macint...@acma.gov.auhttp://www.acma.gov.au/ If you have received this email in error, please notify the sender immediately and erase all copies of the email and any attachments to it. The information contained in this email and any attachments may be private, confidential and legally privileged or the subject of copyright. If you are not the addressee it may be illegal to review, disclose, use, forward, or distribute this email and/or its contents. Unless otherwise specified, the information in the email and any attachments is intended as a guide only and should not be relied upon as legal or technical advice or regarded as a substitute for legal or technical advice in individual cases. Opinions contained in this email or any of its attachments do not necessarily reflect the opinions of ACMA. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
RE: [GRASS-user] AVIRIS data in GRASS [SEC=UNCLASSIFIED]
Hamish wrote: also I suspect Python can do binary reads in a clean way, which may help if the expected format was known. Python's struct and array modules are a good starting point for handling binary data. Numpy (http://numpy.scipy.org/, can be built with NetCDF support) is a third party module of considerable utility. Andrew. - These thoughts are mine alone! - Andrew MacIntyre National Licensing and Allocations Branch tel: +61 2 6219 5356 Inputs to Industry Division fax: +61 2 6253 3277 Australian Communications Media Authority email: andrew.macint...@acma.gov.auhttp://www.acma.gov.au/ If you have received this email in error, please notify the sender immediately and erase all copies of the email and any attachments to it. The information contained in this email and any attachments may be private, confidential and legally privileged or the subject of copyright. If you are not the addressee it may be illegal to review, disclose, use, forward, or distribute this email and/or its contents. Unless otherwise specified, the information in the email and any attachments is intended as a guide only and should not be relied upon as legal or technical advice or regarded as a substitute for legal or technical advice in individual cases. Opinions contained in this email or any of its attachments do not necessarily reflect the opinions of ACMA. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
