Re: [GRASS-user] ignoring .gislock and consequences?
Jonathan Greenberg wrote: > I recall some time ago there was a way to "hack" grass (is this a more > formal boot-time option now?) and have it ignore .gislock to run concurrent > processes in the same mapset. I'm curious if this is still possible, The easiest way to get around the locking is to delete the .gislock file. > and, if so, if it would be safe to do this with multiple r.mapcalc > runs which use different input files and different output names? This case should be safe. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] d.* command problems
Hi, I'm running GRASS 6.4.0RC6 on Windows XP SP1. Working my way through the book "Open Source GIS a GRASS GIS Approach" 3rd ed. by Markus Neteler and Helena Mitasova, I have noticed problems with some d.* commands. For example, when I type d.histogram into the GUI layer manager command line, I get the response "Command 'd.histogram' not yet implemented in the GUI. Try adding it as a command layer instead." When I add the command layer, I can't see what I'm typing and I can't find a way to adjust the display so that I can see what's going on. d.histogram is still ok because I can view the output in the msys folder. However, d.correlate seems to output multiple files that overwrite one another. Is there a way around this? Thanks Hanlie ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] ignoring .gislock and consequences?
Jonathan Greenberg wrote: > I recall some time ago there was a way to "hack" grass (is this a more > formal boot-time option now?) and have it ignore .gislock to run > concurrent processes in the same mapset. I'm curious if this is still > possible, and, if so, if it would be safe to do this with multiple > r.mapcalc runs which use different input files and different output > names? Thanks! all in all it is much simpler+cleaner to just background the job by putting an "&" at the end of the unix shell line. for simple use on a multi-core CPU see the "poor-man's multi-processing trick": http://grass.osgeo.org/wiki/R.sun#Automation if there is a chance processes may interact, use multiple mapsets with @othermapset and g.mapset, g.mapsets, and temporarily creating new mapsets + GRASS_BATCH_FILE: cd $LOCATION/ grass64 -c temp_mapset_$$/ see Markus N's cluster & batch job pages/scripts on the wiki for more details. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] d.* command problems
Hanlie Pretorius wrote: > However, d.correlate seems to output multiple files that overwrite one > another. > > Is there a way around this? Try making this change to the d.correlate script: --- d.correlate (revision 41749) +++ d.correlate (working copy) @@ -97,6 +97,8 @@ fi d.erase +GRASS_PNG_READ=TRUE +export GRASS_PNG_READ if [ $? != 0 ] ; then exit 1 fi -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Importing Landsat images with different coordinates
Greetings I need to import Landsat images (r.in.gdal) to my location but, my Landsat images are in a specific Coordinate system (WGS84) that is different from mine. Could anyone explain me (briefly ) the steps to import this images? Thanks Jenny ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] nearmap WMS
Tony Bazeley wrote: > I'm new to GRASS, even newer to WMS and am trying to import > some nearmap tiles. I have some partial success as shown below. > > Could the solution be changing file extensions and running > gdalwarp with appropriate parameters? > > If so I have no idea of the next step. > > I've tried changing the file extension to .tiff but the > file is unreadable by GIMP ... > GRASS 6.4.0RC5 (NorthernLP):~ > r.in.wms > layers=Adelaide_Australia > mapserver=http://wms.nearmap.com output=nearmap01 > Calculating tiles > Requesting 4 tiles. > Downloading tiles > Downloading data > 2010-05-09 17:45:23 URL:http://wms.nearmap.com/ [89012/89012] > -> > "/home//grassdata/wms_download/nearmap01__0.geotiff" > [1] > . > . > All tiles downloaded successfully > ERROR 4: > `/home/../grassdata/wms_download/nearmap01__0.geotiff' > not > recognised as a supported file format. > > ERROR: r.in.gdalwarp: gdalwarp failure. > ERROR: r.in.gdalwarp failed see https://trac.osgeo.org/grass/ticket/1025 an error occurred and the error detection logic failed so you don't see the useful error message explaining what went wrong. the downloaded "tiff" image probably contains some text file. you'll have to remove it otherwise it will think the tile is already downloaded. as it generally works for me, I'd need to know the output of: cd $GISBASE/wms_cache/ file -b really_a_xml.tif in order to improve it. what operating system + version do you use? often the "-g" flag helps when working with older WMS servers. good luck, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Importing Landsat images with different coordinates
On 10 May 2010, at 18:00, Jenny Turner wrote: > Greetings > I need to import Landsat images (r.in.gdal) to my location but, my Landsat > images are in a specific Coordinate system (WGS84) that is different from > mine. Could anyone explain me (briefly ) the steps to import this images? > Thanks > Jenny Dear Jenny, If your images are in TIFF, you can convert the coordinate system to the one that you have, with gdalwarp. As an example, if my coordinate system is UTM Zone 48S (32748) and my data is in lat-long (4326), I will use gdalwarp command like this: gdalwarp -t_srs "EPSG:32748" -s_srs "EPSG:4326" source.tif target.tif Cheers, Firman Hadi Center for Remote Sensing - ITB Jl. Ganesha No. 10, Labtek IX-C, 3rd Floor Bandung - 40132 INDONESIA Phone: +62-22-2530701 Fax: +62-22-2530702 Website : http://crs.itb.ac.id ; www.sigro.org Blog : http://jalmiburung.wordpress.com JepratJepret: http://jalmiburung.fotografer.net ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Import GRIB files to GRASS
António I have does this; I think it's helpful to first extract the fields you need and group them together, otherwise you will probably end up with a lot of unwanted fields being imported. I have written a Perl script to do this if you want it. I'm sure you would need to edit it to meet your needs. Regards, Tom Hamish wrote: António wrote: I'm planning on using some global meteo datasets that are distributed in GRIB format. has anyone ever tried to parse GRIB NCEP files to GRASS? maybe this helps- http://grass.osgeo.org/wiki/GRIB Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Thomas E Adams National Weather Service Ohio River Forecast Center 1901 South State Route 134 Wilmington, OH 45177 EMAIL: thomas.ad...@noaa.gov VOICE: 937-383-0528 FAX:937-383-0033 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Landsat Stack import and export
Greetings Regarding the possibility of exporting an GROUp, using r.in.gldal, the groups are not listed in that menu. So the user cannot see the available groups. It's still processing but IO have one question: The processing bar restarted at least 3 times, what is happening? Because it file, now, it seems that it's not "growing". Is it doing some file-check or something? Thanks Antonio Markus Metz wrote: 2010/5/7 Markus Neteler : 2010/5/7 António Rocha : Greetings I've a Landsat image with 6 bands in Tif format. I need to import into grass, do some processing and export the same band in a Stack. The import is easy using r.in.gdal but my difficulty is to export 6 bands in one single file. Is it possible using GRASS? To my knowledge no. Sure it is. Create a group in GRASS, export the group (r.out.gdal input=) to a file format that supports multiple bands, e.g. GeoTIFF. Markus M __ Information from ESET NOD32 Antivirus, version of virus signature database 5094 (20100507) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 5100 (20100510) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Landsat Stack import and export
2010/5/10 António Rocha : > Greetings > > Regarding the possibility of exporting an GROUp, using r.in.gldal, r.out.gdal you mean? > the groups are not listed in that menu. So the user cannot see the available > groups. g.list type=group will list all groups > It's still processing but IO have one question: The processing bar restarted > at least 3 times, what is happening? If you export a group, each raster map is exported separately, even if they all end up in one file. If you use r.out.gdal --verbose, there would be several messages like Exporting raster map (band )... and for each, the progress bar starts anew. > Because it file, now, it seems that > it's not "growing". Is it doing some file-check or something? Depending on the grass version you are using, there might be some checks first to prevent potential data loss (latest 6.4+). Note that r.out.gdal uses the current computational region (resolution and extends) for export. Markus M > > Markus Metz wrote: >> >> 2010/5/7 Markus Neteler : >> >>> >>> 2010/5/7 António Rocha : >>> >>>> >>>> Greetings >>>> I've a Landsat image with 6 bands in Tif format. I need to import into >>>> grass, do some processing and export the same band in a Stack. >>>> The import is easy using r.in.gdal but my difficulty is to export 6 >>>> bands in >>>> one single file. Is it possible using GRASS? >>>> >>> >>> To my knowledge no. >>> >> >> Sure it is. Create a group in GRASS, export the group (r.out.gdal >> input=) to a file format that supports multiple bands, >> e.g. GeoTIFF. >> >> Markus M >> >> >> __ Information from ESET NOD32 Antivirus, version of virus >> signature database 5094 (20100507) __ >> >> The message was checked by ESET NOD32 Antivirus. >> >> http://www.eset.com >> >> >> >> >> > > > > __ Information from ESET NOD32 Antivirus, version of virus signature > database 5100 (20100510) __ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Two questions about r.stream.*
Hello everyone, before beginning to write script from scratch I'd like to know if I can use the r.stream.* for my tasks. What I need to this is: - For each subbasin in a certain area extract each subbasin-outlet; - Input a certain number of points and extract the subbasins using the points as outlets; For the second point I tried r.stream.basins, but the problem is that if one of the points is also the basin outlet, it creates just one subasin that includes the entire area. Thanks Luca -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Two-questions-about-r-stream-tp5031327p5031327.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] v.out.ogr and region
Greetings I'm exporting data from GRASS to Gtif and Shapefiles. While r.out.gdal obays my Region definition v.out.org no. It exports all extent not the specified region. Wasn't it suppose to export only for defined region? Thanks __ Information from ESET NOD32 Antivirus, version of virus signature database 5102 (20100510) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] hardware requirements for running r.sun
Dylan: ... > Not trying to honk one's own horn, but an application of r.sun and time > requirements was recently published here: > http://soil.scijournals.org/cgi/content/abstract/73/4/1345 > Let me know if you want a PDF > Dylan Dylan, in the past I (and colleagues) have used r.sun(2) to get the job done (estimations of global rad over a "small" study area in central greece). Now we are re-doing this for another (smaller) study area but for a larger period of time. If you have no objections, we would like to have that ".pdf" ;-) Cheers, Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.out.ogr and region
António Rocha wrote: Greetings I'm exporting data from GRASS to Gtif and Shapefiles. While r.out.gdal obays my Region definition v.out.org no. It exports all extent not the specified region. Wasn't it suppose to export only for defined region? No, AFAIK, none of the v.in.* nor v.out.* are limited to the region. If you want to easily export only vector features within the region, one approach could be: #create a polygon vector of current region v.in.region out=cur_region #select overlayed features v.select ain= bin=cur_region out=vector_in_region #then export v.out.ogr ... Thanks __ Information from ESET NOD32 Antivirus, version of virus signature database 5102 (20100510) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user This mail was received via Mail-SeCure System. -- Micha Silver Arava Development Co. +972-52-3665918 http://surfaces.co.il ___ 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]
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. > 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. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Shapefile Export - run out of memory
Dear all, I am trying to export some point data to a shapefile (admittedly a large number of points, in the region of 195 but I'm sure I have exported larger files before) and keep getting an error abut 1/3 of the way through the export regarding running out of memory (error message below). I initially thought this was a database issue so I have copied into a new mapset (and created a new database) for a smaller number (2) of the files. This didn't solve the issue, so I am now wondering if it is a computer memory problem? "Exporting 1958623 points/lines... DBMI-SQLite driver error: Cannot select attributes for cat = 401760 Error in sqlite3_prepare():SELECT * FROM Everleigh_p_from_IDW WHERE cat = 401760 out of memory" Has anyone come across a similar error before / does anyone have any advice on how I might resolve / work around this? I am running GRASS 6.4 on Ubuntu Hardy and windows XP with the same issue (apparently) on both. Many thanks for your time, Rebecca ___ 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
