Re: [GRASS-user] output after r.reclass

2014-08-23 Thread Hamish
Hermann wrote:
 I am using [1] as rules for r.reclass to shift a map's value range of
 -100..100 to 0..200.

fyi, see also r.recode, r.rescale, and r.mapcalc.

 After reclassification, shows the result
 as quoted in [2]. I am missing the line saying that -100 has been
 reclassified to 0.
 Why is this line missing?

I don't know, you might look into the $MAPSET/cellhd/mapname file and
look for clues.

It may be a hold-over from before GRASS 5, when '0' was treated as NULL.

the important thing is that ' -r' and r.univar show the correct

grass-user mailing list

Re: [GRASS-user] Question about Elevation Maps and Shaded Relief Maps

2014-08-21 Thread Hamish
Ben wrote:
 I have created an elevation map and a shaded relief map for the same
 area. I know there is a way that they can both be viewed
 simultaneously so that you can see the elevations (as indicated by
 color) and the shaded relief at the same time.  Currently I am only
 able to view one at a time depending on which map is on top of the
 other.  How can I change that so that I can see both maps at the same

Using GRASS 6 and Xmonitors (d.mon), you can use the d.shadedmap
module, which is actually a wrapper for d.his. See the help page for
details on using the brightness option and an example.

For 3D, in NVIZ do:  nviz elev=dem color=overlay

In the wxGUI you can put the overlay map on top and then change its
opacity, right click on the map in the layer manager and select change
opacity level, then move the slider somewhere in the middle 50%.

grass-user mailing list

Re: [GRASS-user] GeoTIFF, EPSG and GRASS

2014-08-21 Thread Hamish
Adrien wrote:
 with GDAL i use EPSG:2972 to reproject any new raster i'm lead to
 work with.
 gdalinfo says:
 Coordinate System is:
 PROJCS[RGFG95 / UTM zone 22N,
 SPHEROID[GRS 1980,6378137,298.2572221010002,
 I've created the GRASS location from this same code, and all imports
 are successful.
 After exporting, the gdalinfo output is different:
 Coordinate System is:
 PROJCS[UTM Zone 22, Northern Hemisphere,
 SPHEROID[Geodetic_Reference_System_1980, 6378137,
 The PROJCS has lost its AUTHORITY parameter.

GRASS doesn't store the EPSG number in the location settings (well
it can, but that's just for informational purposes) and only uses
the actual coefficients used in the projection math. Literally
the output of the 'g.proj -p' command.

As definitive as EPSG codes are, they aren't always exact representations. 
(e.g. precision issues or added datum transform
grid selection is sometimes used but not specified in the actual
code definition. If you are lucky in these cases the extra terms
are stored in a PROJ.4 string within the WKT, but that's a non-
official extension AFAIK)

 Would someone know why this happens? Is there a way to fix this?

perhaps this will do it:
  gdal_translate -a_srs +init=epsg:2972 in.tif out.tif

grass-user mailing list

Re: [GRASS-user] i.rectify (or gdalwarp -off topic)

2014-07-30 Thread Hamish
Milton wrote:
 Following Markus Neteler (and other) suggestioins, I was able to
 automatically generate a ground control point file for a large set of
 Now I have (at least) two directions.
 1. rectify the image using i.rectify
 2. use gdalwarp out of grass
 In both ways I face the same issues: a) how can I input my text file
 for a certain image and b) what is the proper format that I need to
 follow when preparing the file (for both i.rectify and gdalwarp)?
 Detail: the images are JPG fotos taken using a fixed camera in the
 top of a tower, so the images are nearly the same scene.


If are familair with Bourne shell scripting, you might have a look in the 
grass6 addons SVN for i.warp and i.points.reproj scripts.

(i.warp is a bit of a mess, but uses gdalwarp with grass's POINTS gcp file)

the grass POINTS gcp file is pretty easy format, 

#   image  target   status
#east   northeast   north   (1=ok)
 2.537267   10.230953  1393516.34  4902494.781
 8.038078   10.219225  1419326.28  4903305.401
13.531500   10.212226  1445136.43  4904007.831
 8.0297182.291376  1420414.87  4866269.911
 2.5310902.302488  1394760.64  4865459.671
19.005416   10.198488  1470946.75  4904602.121
18.9879682.271928  1471724.12  4867566.031
13.5192342.281374  1446060.02  4867342.381
 6.186646   14.579820  1410021.804000  4923820.6670001
 5.233682   14.892164  1403912.826000  4925688.7450000
 4.728343   14.134303  1403217.899000  4921427.9140001
 8.716253   13.454576  1421998.543000  4918833.2690001

grass-user mailing list

Re: [GRASS-user] exporting raster map to kmz?

2014-07-28 Thread Hamish
Vishal wrote:
 I'm trying to classify a LANDSAT8 image. In the process, i'd like to
 export an unsupervised classification i did (using i.cluster,
 followed by i.maxlik) raster (type:CELL) into kml/kmz, so that I
 could get some visual idea of the classification. the classification
 is from 1 to 10, with null data present.
 r.out.gdal -c input=lsat2014_unsupervised@PERMANENT
 output=C:\Users\Vishal\Documents\GIS\file3.kmz format=KMLSUPEROVERLAY
 type=Byte nodata=0
 but no matter what flags i try, i get a black box on google earth.
 I'm just using the GUI options, Grass7svn on Windows. FYI, I do know
 how to do this by modifying add-on r.out.kml in Linux, but it would
 be good if i could just do my entire workflow on one platform.


(see )

The r.out.kml addon module should work with GRASS 6.4 on MS Windows
as far as I can tell. If you want to export as JPEG instead of PNG
you'll need to install the Windows build of the NetPBM programs to
get pnmtojpeg.exe though.

It uses r.out.png which exports as colors not values, so the color
table should be preserved.

It is not ported to python for GRASS 7 yet, but it's a pretty simple
script, so shouldn't be too hard.

grass-user mailing list

Re: [GRASS-user] create a common colour scale

2014-07-28 Thread Hamish
Raphael wrote:
 I wonder if anyone knows how to create a common colour scale for
 different raster maps? I want to display all six maps on the same
 page with the single colour scale but I cannot find how to do this in
 More specifically, I have six raster maps of rainfall for different
 time periods (each has a different range of values) and I would like
 to display them all with the same colour scale. The colour scale
 needs to be constructed using the min and max values of the set of
 six maps (and not just individual maps.

For only 6 maps I wouldn't bother with scripting a mix,max variable,
just run in a loop and copy out the min,max by hand.

for MAP in `g.mlist rast pattern=rain*` ; do -r $MAP

then make a dummy map with r.mapcalc with overall min and max range.

r.mapcalc color_map = if(row  10, $min, $max)

and then apply it with:

for MAP in `g.mlist rast pattern=rain*` ; do
   r.colors $MAP rast=color_map

Or run r.colors with the rules= option to set up some color rules
by hand, then apply to all in a loop.

But what I usually do these days in GRASS 6 is to use the r.stack
addon module to temporarily consider all the maps together, which
allows for the nice 'r.colors -e' equalized histogram color scaling.
You can copy the color map to a small dummy raster with the r.colors
rast= option then delete the stacked raster map if you want to save
space, then apply it to all maps as in the Bourne shell loop above.

grass-user mailing list

Re: [GRASS-user] r.hazard.flood

2014-07-08 Thread Hamish
Leo wrote:
  Cellsize : 118.28096836
  SECTION 1a (of 4): Initiating Memory.
  Current region rows: 17433, cols: 17539
  ERROR: G_malloc: unable to allocate 2448854040 bytes of memory at
  WARNING: Subprocess failed with exit code 1

 This log suggests that r.watershed, called by r.hazard.flood, is not
 able to finish the job due to lack of memory.

in bash you can do a test if [ $? -ne 0 ] ; then to see if r.watershed
finished correctly and go to a 'g.message -e' and 'exit 1' if it
failed. r.hazard.flood is a python script, how to apply the same to
grass.run_command() before claiming success and continuing?


Thought I should join the Yahoo mail diaspora before 30 days
worth of my emails got flushed from everyone's spam boxes never
to be seen again. In the last weeks some have made it to the ML
archives at least, if not to end recipients. Others seem to have
just disappeared into /dev/null. It didn't help that the web
interface had become an unusable gibberish of broken JavaScript
and their IMAP would only transfer the oldest 4% of my inbox.
grass-user mailing list

Re: [GRASS-user] GRASS and Blender

2014-05-19 Thread Hamish
Hamish wrote:
  the added interoperability with VTK-aware software is always welcome

 regarding this incredible interoperability in open source projects, I
 am thinking about the lack of 3d vector digitizing tools in GRASS.
 Typically when I need to model a dam or a wedge on a topographic
 surface, I move to blender: maybe some portions of blender interface
 code (written in python) could be used as a basis for further
 improvement of v.digit... 

the main question is the maintenance load and what we can value-add
to it. if we lack the developers to maintain any specialist code and it
is just a clone of an external foss4g program, sometimes it is better
to outsource and let the 3rd party experts maintain the stuff they are
experts at, and link into it as a dependency or use the two programs
together in the workflow (as many do for gdal command line tools +
grass). if we can add/integrate some geo-* smarts to their tool then it
gets very interesting to put in the core grass. We could also probably
have some success requesting API hooks into their libraries if

but I've no idea how much code or complication we're talking about in
this case, so just my 2c.


grass-user mailing list

Re: [GRASS-user] GRASS and Blender

2014-05-19 Thread Hamish
Giovanni wrote:
 - mantain (somehow) geographical references to import back from 3D
 authoring sw (e. g.

one thing which was a problem in the past, and so to be careful of now,
was some 3D model software only had the option to save coordinates as
single precision floats, when for geographic data we generally want to
keep the values as doubles. IIRC this was a trouble we ran into with
r.out.vrml. For visualization-only data it probably is not required to
maintain such precision.


grass-user mailing list

Re: [GRASS-user] trouble exporting to spatialite

2014-05-19 Thread Hamish
On Mon, 19 May 2014 21:35:43 +0200
Markus Neteler wrote:

Hamish wrote:
  I'm have trouble exporting in spatialite format in GRASS 6,
  wondering if anyone else has been able to have it work? Seems like
  a common task.
  using the SQLite driver with v.out.ogr works ok, but when I
  add the spatialite option as described in the OGR format page
  it gives an error for every data point:
  # NC08 dataset
  v.out.ogr in=usgsgages dsn=usgsgages.sqlite \
format=SQLite type=point dsco='SPATIALITE=yes'
  the error message is:
  ERROR 1: sqlite3_step() failed:
usgsgages.GEOMETRY violates Geometry constraint [geom-type or SRID
  not allowed] (19)
  and looking inside the resulting file with sqlitebrowser it seems no
  points are uploaded to the table.

 ...perhaps a pointer.

yes, thanks, that looks quite helpful.

Even wrote on gdal-dev:
 The driver takes responsibility of assigning the SRID automatically
 from the layer SRS. So the error is likely due to an attempt of
 inserting a geometry whose type doesn't match the layer geometry
 type. Spatialite is really strict on that: POLYGON != MULTIPOLYGON,
 and (perhaps I'm not sure) 2D != 2.5D

Here I'm using type=point, and the usgsgages vector map is 2D, so
seems like the most simple case.

from the partially created sqlite file created by v.out.ogr here's the
creation log:

$ echo SELECT * from spatialite_history; | sqlite3 usgsgages4.sqlite
1|spatial_ref_sys||table successfully created|2014-05-19 23:14:31|
2|geometry_columns||table successfully created|2014-05-19 23:14:31|
3|spatial_ref_sys||table successfully populated|2014-05-19 23:14:32|
4|usgsgages|GEOMETRY|Geometry [POINT,XY,SRID=40004] successfully
4|usgsgages|GEOMETRY|created|2014-05-19 23:14:33|3.7.13|3.0.0-beta
5|usgsgages|GEOMETRY|R*Tree Spatial Index successfully created|
2014-05-19 23:14:34|3.7.13|3.0.0-beta

In the gdal-dev thread the solution was to pick the correct one
of OGR_G_SetPoint() vs. OGR_G_SetPoint_2D(), maybe that helps here?

Same trouble with
 census_wake2000, type=area
 roadsmajor, type=line

One thing I notice is that SRID 40004 is a custom one added at the
end of the spatial_ref_sys table, after four other custom ones from
Italy. I'm not sure if that is relevant or not.

Anyway, I'll take this to a ticket.


grass-user mailing list

Re: [GRASS-user] GRASS and Blender

2014-05-18 Thread Hamish
Vincent wrote:
 here's a little script intended for GRASS users in search of various
 output tools and methods. The 3d computer graphics software Blender
 offers a full featured solution to produce high quality images and
 animations. Besides the existing v.out.ply add-on, I needed a
 custom-made module, that I called v.out.blend:
 It comes with a short Tutorial explaining how to run the add-on in
 GRASS and mostly how to get things to work in Blender:
 Remarks/suggestions are welcome,

Thanks Vincent, the added interoperability with VTK-aware software is always 
welcome, and the wiki tutorial is very nicely done too.


grass-user mailing list

[GRASS-user] trouble exporting to spatialite

2014-05-18 Thread Hamish

I'm have trouble exporting in spatialite format in GRASS 6, wondering
if anyone else has been able to have it work? Seems like a common

using the SQLite driver with v.out.ogr works ok, but when I
add the spatialite option as described in the OGR format page
it gives an error for every data point:

# NC08 dataset
v.out.ogr in=usgsgages dsn=usgsgages.sqlite \
  format=SQLite type=point dsco='SPATIALITE=yes' 

the error message is:

ERROR 1: sqlite3_step() failed:
  usgsgages.GEOMETRY violates Geometry constraint [geom-type or SRID
not allowed] (19)

and looking inside the resulting file with sqlitebrowser it seems no
points are uploaded to the table.

Installed GDAL is 1.9.0 so should be new enough. (debian/wheezy)

On the same system with self-compiled qgis 2.2* I can use the GRASS
toolbox to load in the grass map and right click it in the layer list
to 'Save As..' a seemingly-good copy.

any ideas?

[*] if anyone wants qgis 2.2 packages for amd64 deb/stable, just ask.

Ben had trouble with sqlite3_step() a while ago, but it's not quite
the same error:


grass-user mailing list

[GRASS-user] GRASS website temporarily down

2014-04-24 Thread Hamish

the grass website and wiki are both temporarily down due to a full disk. Hope 
to have it back up ASAP,it should be a quick fix after we figure out what's to 


grass-user mailing list

Re: [GRASS-user] GRASS website temporarily down

2014-04-24 Thread Hamish

 the grass website and wiki are both temporarily down due to a full disk. Hope 
 have it back up ASAP,it should be a quick fix after we figure out what's to 

ok, they are back up now.

continued on the grass-dev list.


grass-user mailing list

Re: [GRASS-user] calculation valley floor width in GRASS or some index indicating valley floor width?

2014-04-04 Thread Hamish
Helmut wrote:

  any hint or pointer to some grass gis procedure/literature/web
  link/etc how to caculate valley floor width in GRASS or some index
  indicating valley floor width.
  the idea is to get some measure how wide or narrow a valley is.

JWDougherty wrote:
 That is a very involved question, starting with how you define the
 valley floor quantitatively to begin with.  You could calculate an index
 of concavity or average slope and plot the point where the measure (e.g.
 concavity of slope, or average slope) drops below a certain value that
 would be a valley floor boundary by definition.  There should be
 several grass tools that could be applied.

e.g. run 'r.param.scale param=feature' to pull out channels, then
r.watershed to make a rivers map and r.cost to calculate distance
from the center-line (rivers) to the edge of the valley. Of course
rivers are not always in the center of the valley, perhaps take the
r.param.scale valleys and run r.cost to find the cost to the middle.
Then extract the 'ridge lines' of the distance-cost map, again with
r.param.scale, and double the peak values along the ridge.

It is very similar to the classic 'river mile' problem, to define well
a line down the center of the channel when nature isn't as simple as
a pipe and valleys merge, islands happen, etc.


grass-user mailing list

Re: [GRASS-user] grids

2014-03-26 Thread Hamish
Tyler wrote:

 I'm trying to make a ps make, which I'll then tweak in Inkscape. The
 basic map looks almost correct, but the geogrid labels are placed
 slightly off the page. Is there a way to instruct GRASS to move the
 labels inwards so they are readable?
 The map is here:


it falls off the screen in map projections where the angle between grid
north and true north becomes large. This was recently fixed for d.grid's
version of geo-grids, but it seems still needs similar treatment.

For now your best bet is to open the resulting .ps file in your favourite
industrial strength text editor and search near the end of the file for
the line with the ZB (50N) PB text. The line after it starts with two
numbers. These are points (1/72) from the left side of the paper.
Changing the number by 10 will move it the same distance on the page as
the size of a 10 pt font. So try reducing the first number (x coord)
by about 10 and check the results. For the 80W on the bottom you'll have
to change the second number of course.


grass-user mailing list

Re: [GRASS-user] projection issue

2014-03-24 Thread Hamish

 the trouble I am currently experiencing is dealing partly with
 cs2cs, but partly with grass, so I post my question on this
 Being within a Mercator location, defined with the location
 wizard (calling epsg:3857), I type :
 I can't figure what is going wrong. Would anyone have an idea ?


First of all, avoid using Google's spherical mercator projection for anything 
other than necessary data import/export if you can possibly help it. But 
sometimes we don't have a choice, so..

Google's spherical Mercator projection (formerly the unofficial
epsg-ish code 900913 from the esri.extra file) isn't really WGS84, it just 
borrows the major axis of the Earth used in WGS84 for both the major and minor 
axes of the ellipsoid, making it a sphere larger than Earth really is. So it's 
just a simple Mercator on a sphere, which happens to have a particular radius.

Different ellipsoids (and a sphere being a type of ellipsoid) squash the Earth 
north-south, so the northing value changes the most. Since Mercator doesn't 
deform east-west (lines of longitude are all parallel and perfectly vertical), 
in that projection changing the ellipsoid does not change the easting value at 

Next thing to know is the +nadgrids=@null hack to get around the datum 
transform. See

and this basically explains the rest:

fyi, +wktext has to do with well known text .prj file text, and requests to 
software in-the-know that the non-standard +nadgrids=@null projection term 
gets recorded when you export in that way. The default (without +wktext) is to 
only export official spec. terms, for compatibility with brittle software which 
might have to import it later and can't deal with anything beyond the official 
WKT spec (or ESRI's diversions from it, but there's another g.proj flag for 

good luck,

grass-user mailing list

[GRASS-user] new addon: r.patch.many

2014-03-23 Thread Hamish

for anyone running big r.patch jobs (e.g. 100 maps) on a multi-core system, I 
just added a new addon for grass 6 called r.patch.many which allows it to 
automatically run in parallel. Obviously if you have fewer maps than cores it 
won't help much; I'm not sure how many maps you need to make it worth the extra 
processing overhead, maybe 2x or 3x the number of cores. This just aids 
wall-clock processing time; cumulative CPU time will be some fraction worse 
than r.patch alone.

You can use the g.md5sum addon script to test that the results of r.patch and 
r.patch.many are identical.

The same technique could easily be adapted for 'r.series max=' and similar 
operations, btw.

testers welcome.


grass-user mailing list

Re: [GRASS-user] issues with netCDF import

2014-03-22 Thread Hamish
Damian wrote:

  Origin = (-180.000,90.000)
  Pixel Size = (0.00833767951,-0.00833767951)
  Corner Coordinates:
  Upper Left  (-180.000,  90.000)
  Lower Left  (-180.000, -90.094)
  Upper Right ( 180.188,  90.000)
  Lower Right ( 180.188, -90.094)
  Center      (   0.094,  -0.047)

 Try running with the -l flag to force fit within -180,180.

technically it's the illegal 90 deg latitude it is unhappy with, GRASS's 
raster engine can deal with wrapping around 180 longitude (0-360 is supported 
too). keep an eye on g.region, sometimes minor +/- adjustments are needed to 
tell it which way to go around the world, the long way or the (very) short way!

In this case it looks like simple cumulative rounding error because 'Pixel 
Size' got cast to single precision floating point somewhere along the way (3's 
don't repeat to infinity as they should), and as Moritz explains, ' 
-l' will fix it.

In other cases where the convention is grid-centered not cell-centered you get 
half a cell of overlap at the poles and it's a bit uglier to clean up. (note to 
self: need to work on a script to handle that automatically; see

see also


grass-user mailing list

Re: [GRASS-user] on PostgreSQL

2014-03-12 Thread Hamish
Markus Metz wrote: does not work properly in GRASS 6.

Markus Neteler wrote:
 Should we drop it from G6?

the changes look contained and non-fatal, so good candidate for backport.


grass-user mailing list

Re: [GRASS-user] - eps frame affect/hide border and legend

2014-03-07 Thread Hamish
Domenico wrote:

 The frame is inside the map region.
 I cleaned the eps frame with eps2eps. But now I think it is a ps reader
 * with gv no problems with the eps frame (clean and no-clean)
 * with evince problems only with the no-clean eps frame. No stderr
 differences between clean and no-clean ps, launching evince from the

as another cleaning step/exercise you might try converting to PDF with ps2pdf 
and see if the conversion or PDF readers get upset. (see wiki for 
publish-quality options)

it could be the eps is calling showpage or otherwise causing an end-of-file 
situation when it is embedded in the main output postscript file?

 Thank you very much!

hope it helps.


grass-user mailing list

Re: [GRASS-user] - eps frame affect/hide border and legend

2014-03-06 Thread Hamish
Domenico wrote:

 I'm trying to output a ps file with (GRASS 6.4.2). Results from
 the psmap.def are good, with border, colortable, vlegend, etc.. (pasted def file)
 But when I add an eps frame border, colortable and vlegend disappear.
 I changed the order, putting eps before or after the vlegend
 instruction, but without successful.


could you post a bug in the trac system? an example made using one of the 
standard grass datasets (Spearfish or North Carolina) would help a lot too.

is the eps file inside or outside the map frame? sometimes it helps to move it.

the used-added eps file is just copied verbatim within the final output file; 
it might help to keep it simple or clean with eps2eps first?

did you put a final 'end' after all the instructions?


grass-user mailing list

Re: [GRASS-user] r.hazard.flood does not respect region settings?

2014-03-06 Thread Hamish
maning wrote:

 I'm testing r.hazard.flood and noticed that it computes the flood and
 mti layers on the full region of the elevation raster instead of the
 pre-defined region settings.
 The relvant code I found from the r.hazard.flood is this:
    # Detect cellsize of the DEM
     info_region = grass.read_command('g.region', flags = 'p', 
 rast =
 '%s' % (r_elevation))
     dict_region = grass.parse_key_val(info_region, ':')
     resolution = (float(dict_region['nsres']) + 
     grass.message(Cellsize : %s  % resolution)
 Would it be possible to either respect the current region settings or
 add a flag to choose between the dem region settings or current region

if it needs to detect the original raster cell resolution (usually that's only 
needed to avoid aliasing artifacts in certain situations) it should use 
to get the answer. I'm guessing due to the averaging of the ew and ns 
resolutions avoiding aliasing isn't the case.

if a module wants to change the region (and almost none should ever do that 
except for g.region by itself) it should set up a temporary WIND_OVERRIDE 
first, in the case of python scripting there is an easy grass python function 
to make that and clean it up at the end. (otherwise parallel jobs get their 
regions messed up mid-run, and region changes without you expecting it will)

I suspect grass.raster's raster_info() is the better way for r.hazard.flood to 
do what it's trying to do now. But also just querying the current g.region info 
without changing anything is probably even better, as that is what the other 
raster commands will expect to use. If the user should align perfectly with the 
input map first, it should be noted in the help page for them to do it manually 
before running the module.


grass-user mailing list

Re: [GRASS-user] libgrass_gmath

2014-02-17 Thread Hamish
Dave wrote:
    I'm trying to do a simple dissolve on a vector map and getting a
 library error

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


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


 -rwxr-xr-x. 1 root root 77615 Dec 21  2012
 lrwxrwxrwx. 1 root root    23 Dec 21  2012 -

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

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



GRASS g.version -r



that should show you where the grass install is located.

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

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

good luck,

grass-user mailing list

Re: [GRASS-user] GRIB2 problem

2014-02-15 Thread Hamish
Lee wrote:

 I upgraded gdal to 1.10 and used -l and was able to read the
 file and display it with no problems.

Great. The edge row cropping and fixing with r.region can be a little
tricky, as can managing a region aligned to the 1/2 cell offset raster,
not one rounded to the raster resolution, but as long as you're careful
everything should end up aligning ok. Check against a coastline like
Natural Earth's.


grass-user mailing list

Re: [GRASS-user] GRIB2 problem

2014-02-13 Thread Hamish
(sorry for top posting, no time to deal with yahoo mail today)


note for GRIB you need gdal 1.10 or newer, there were
edge coordinate bugs in earlier versions.

--- see:

note grass uses the cell-center for data value convention,
not the data values at grid line confluences (nodes) convention for raster 

and so in grass the region's e,w,s,n values are at the outer edge of the raster 
cells, while gridline-centered arrays* would give coords overhanging the edges 
of the region by half a cell.

sometimes when loading in gridline-centered data you need to crop away the data 
row at 90N,S and one of the two at 0,360 or +-180 longitude. See the MODIS page 
in the wiki perhaps.
the way there is to use ' -l' to force it to fit into 90N,S, then 
carefully use g.region + r.mapcalc to crop away the two rows, then use r.region 
to fix the map bounds back to where they should.

resolution ends up with bounds at e.g. 25,75m with a cell size of 50m, you have 
to be careful that d.zoom or 'g.region -a' doesn't realign the bounds to 
0,50,100m instead of 25,75 (so silently shifted by 1/2 a cell). 

* (usually can spot them as they have like 501x1001 cells not 500x1000)

but the first thing to verify for the GRIB format is that your gdal version is 
1.10 or newer.



On Wednesday, February 12, 2014 6:21 PM, Lee Eddington wrote:

I’m trying to import some GRIB2 data into GRASS (6.4.3 on a Mac) and am having 
a problem with the range of the latitude coordinates.  I’m working with the 
following file:

I used gdal_translate to create a GeoTiff file, but when I try to import it 
into a lat/lon location I get the following:

GRASS 6.4.3 (GFS_from_grib):~ 
input=gfs.t12z.master.grbf72.10m.uv.tif output=gfs
WARNING: Datum unknown not recognised by GRASS and no parameters found
Projection of input dataset and current location appear to match
WARNING: G_set_window(): Illegal latitude for North

Here is the output from gdalinfo:

lees-mbp:GFS Lee$ gdalinfo gfs.t12z.master.grbf72.10m.uv.tif
Driver: GTiff/GeoTIFF
Files: gfs.t12z.master.grbf72.10m.uv.tif
Size is 720, 361
Coordinate System
GEOGCS[Coordinate System imported from GRIB file,
Origin = (-0.250,90.250)
Pixel Size = (0.500,-0.500)
Image Structure Metadata:
Corner Coordinates:
Upper Left  (  -0.250,  90.250) (  0d15' 0.00W, 90d15' 0.00N)
Lower Left  (  -0.250, -90.250) (  0d15' 0.00W, 90d15' 0.00S)
Upper Right (     359.750,      90.250) (359d45' 0.00E, 90d15' 0.00N)
Lower Right (     359.750,     -90.250) (359d45' 0.00E, 90d15' 0.00S)
Center      ( 179.750,   0.000) (179d45' 0.00E,  0d 0' 0.01N)
Band 1
Block=720x1 Type=Float64, ColorInterp=Gray
  Description = 10[m] HTGL=Specified height level above ground
    GRIB_COMMENT=u-component of wind [m/s]
    GRIB_PDS_TEMPLATE_NUMBERS=2 2 2 0 96 0 0 0 1 0 0 0 72 103 0 0 0 0 10 255 0 
0 0 0 0
    GRIB_REF_TIME=139212 sec UTC
    GRIB_VALID_TIME=1392379200 sec UTC
Band 2 Block=720x1 Type=Float64, ColorInterp=Undefined
  Description = 10[m] HTGL=Specified height level above ground
    GRIB_COMMENT=v-component of wind [m/s]
    GRIB_REF_TIME=139212 sec UTC
    GRIB_VALID_TIME=1392379200 sec UTC

So it’s showing the north and south bounds of 90.25 N and -90.25 S.  I’m 
almost positive that this would be the values of the edges of the cells and 
that the cells are centered at 90 N and 90 S.

Is there a way to import this data?


grass-user mailing list

grass-user mailing list

Re: [GRASS-user] trouble

2014-02-09 Thread Hamish
Buslers wrote:
 I have been having trouble trying to use  It has
 been a few years since I have last used GRASS GIS.  I knew that the module was not available for winGRASS, so I attempted
 to install on Ubuntu. After several hours of failed attempts to run
 the module, I found a website saying that was not
 working in 6.4.3, but you could use it on windows running Cygwin.

Which website is that? should be working fine on 6.4.3
in Ubuntu. It's only if you really want to run on Windows
that you need worry about Cygwin. (Cygwin provides UNIX's X11 X-Windows, needs an X-monitor)  Generally it's probably easier to
run Ubuntu directly or in a virtual machine (VirtualBox is pretty
popular) than bother with setting Cygwin. Many roads to Rome though.

What was the error you were having trying to get 6.4.3's
to run on Ubuntu?

 I attempted to install Cygwin and winGRASS using the instructions from
 here -, but
 I kept getting an error saying unable to get setup.ini from

I think that file is the cygwin download mirror's manifest, you might
try another mirror?

 I did add the -X to the target in the properties menu.  I then tried
 to install GRASS 7.0, but Ubuntu's repositories did not include
 7.0.  I added the ubuntugis testing repository and I still get a
 message saying that grass70 could not be located. 

GRASS 7 doesn't include, since Xmonitors were removed
there. I'm not sure if anyone is working on a wxGUI replacement for
it or not.

UbuntuGIS only supplies official GRASS releases, so 6.4.3 is the latest.
There is another grass team ppa which has grass7 development snapshot
packages for ubuntu, the latest build is from December last time I looked.


grass-user mailing list

Re: [GRASS-user] installation of grass 7 unknown-linux binaries

2014-02-03 Thread Hamish
José wrote:

  thanks for your quick reply.
  My ubuntu is 64bits in fact.

Markus N:
 I have no Ubuntu, so I cannot say much here. But we build the snapshot
 binaries in a Debian box.
  Now I have to build wxpython yet (hope 3.0.0 is supported)
  This tutorial seams ok.
 Why can't you simply use the wxpython offered by ubuntu?


there are pre-made grass7 packages for ubuntu already built, (albeit
a few weeks out of date)

but I would always encourage users who wish to try development versions
of code to build GRASS from source themselves, it's not so bad; these
instructions should work:


grass-user mailing list

Re: [GRASS-user] how to draw line with arrow mark to line top (tip)

2014-01-27 Thread Hamish a écrit :
 I do not find how to draw line with arrow mark to line top (tip).

I'm not sure if it matches your needs or not, but see also d.rast.arrow and the 
d.barb addon (d.barb can take either raster or vector maps as input); for a 
single arrow symbol the d.mark addon script might help.


grass-user mailing list

Re: [GRASS-user] GRASS Android apps

2013-11-14 Thread Hamish

Excerpt from twitter:
@JollaHQ Who can confirm/where is information regarding the possibility to 
run #grassgis ( under #sailfishOS?
02:26 PM - 14 Nov 13
Jolla @JollaHQ
@NikAlexandris If you can make it run on Linux with Qt UI, why not.
02:28 PM - 14 Nov 13

 This is of course unrealistic. There is wxQt but not sure if
 this was ever used. Then you can rewrite wxGUI in the way that
 you can add Qt widgets but the is work for years. However, you
 can use QGIS (for example there is QGIS for Andrioid) and make
 the connection between QGIS and GRASS working.

there are of course a great many applications of GRASS which are just fine to 
use without any GUI or Xmon or even graphics at all, just run the processing 
from the command line, so that should be ok. Rough graphics can be had as long 
as the GRASS PNG driver and apache work: you present the png output dir to the 
web server. Then you just swap out of your terminal session to a web browser 
and hit refresh as needed. :)  [I've actually done this in the field over a 
flaky satellite connection, and it worked remarkably well]


grass-user mailing list

Re: [GRASS-user] Permission denied to access a mapset in Linux

2013-11-13 Thread Hamish
António wrote:
 How can I change the owner of a mapset directory?

It's at the filesystem level. See 'man chown' and 'ls -l'.

If it is on an external hard drive, there are mount options to set the owner of 
the drive when you plug it in.


grass-user mailing list

Re: [GRASS-user] grass 6.4.3 - can't launch wxpython interface on Ubuntu 13.10

2013-11-13 Thread Hamish
Filipe wrote:
 The main problem is that this behaviour interferes with QGIS/Processing
 (Sextante) and it doesnt allow me to run grass algorithms.

 I had a similar problem with Ubuntu 12.04 but when I run
 grass --wxpython, GRASS started loading wxpython without requiring me
 to press Enter everytime.

fyi you can change the default startup GUI method with the g.gui module.

but explicitly specifying -gui or -wxpython from the command line to
start should record the preference permanently in your ~/.grassrc6 file.


grass-user mailing list

Re: [GRASS-user] Suse 12.3, GRASS 6.4.3 - addons not possible to install - SOLVED!

2013-11-13 Thread Hamish

 after we fixed to integrate the g.html2man script to the grass package, it
 is now no longer possible to install the grass package itself, without
 manually ignoring this error:
 failed on file /opt/grass/tools/g.html2man: cpio: rename failed - Is a
 directory error: grass-6.4.3-4.4.x86_64: install failed error:
 grass-6.4.3-3.19.x86_64: erase skipped
 We haven't found a solution to fix this yet, and because many people
 recently complained, that grass can't be updated/installed automatically, we
 decided to revert the g.html2man fix for now.
 We will build and integrate the g.html2man script to the grass package
 again, once we find a solution for the error above. 

Hi Otto,

the script used to be installed into $GISBASE/tools/g.html2man/g.html2man, but 
we simplified things (a long time ago now) by removing the extra dir. If you 
install on a clean computer it's fine. If you try to install over the top of an 
older grass installation you get the error. the solution is to clean out the 
old version before installing the new one, luckily in grass this is very easy, 
just delete the grass dir. the problem was annoying enough that now we 
specifically try a rmdir in the 'make install' just before copying that file 
over. That's in 6.4.3. see:


grass-user mailing list

Re: [GRASS-user] trouble with to georeference a NetCDF file

2013-11-13 Thread Hamish
Lee wrote:
 I'm trying to import a NetCDF file from the WRF weather forecast model
 with, but I can't get it to georeference.  Instead I end
 up with a x,y coordinate system of rows and columns.  The file
 georeferences fine in a number of other weather graphics programs.

Hi Lee,


can you get the WRF data in GRIB format instead of NetCDF? I'm doing
that and it is working well. (note for GRIB you should have GDAL version
1.9 or newer to avoid a bug)

if not, try using gdal_translate to extract the subband to a geotiff
or other intermediate format before loading into grass.
if you can get working directly, also consider r.external
to avoid a zillion maps everywhere on the disk.

see also ncdump and I've got a small program here called ncreformat.c that
extracts wrf NetCDF to an ascii file. It might be from an old WRF code


ps- see also the d.barb addon module for GRASS 6. Also there might be
some discussion in the mailing list archive about smoothing isobar
lines created with r.contour using the v.generalize module: you need
to be careful that the tight inner lines don't pinch closed and that
the fine eye of a storm doesn't get discarded with discarded small
noise loops. if it's not online maybe I'll have some private notes
somewhere I could try to dig out.
grass-user mailing list

[GRASS-user] GRASS Android apps

2013-11-13 Thread Hamish

I recently added a new page on the wiki regarding GRASS + Android.

please feel free to add ideas, suggestions, and wishes to it.

For now I'm mostly just thinking about reference manuals and ebooks,
for when you are in the field on a laptop without much screen space
for lots of help pages.


Calibre seems good for going from HTML to ePub and Mobi, and probably
PDF too.  PDF-eBook is apparently not a pretty thing. HTML actually
seems the preferred starting format, so we should be able to make progress

At first I thought about a single large eBook with volumes within it
for quick intros, module synopsis+menu location, and man pages, but now
I am thinking separate ebooks for each of those topics. Perhaps it
depends on how easy + powerful the TOC structures are in Calibre?

The nice thing about an eBook is that it is more cross platform and so
with a cross-platform program like FBreader or a pdf reader could be used
on iPads, laptops, unrooted mobile devices, workstations, whatever.

but you got to love the instant search features of a native app :), and
there is already some basic template code in github (see manpages link above) 
so it should be quick to impliment.

I would tend to leave any actual GIS-on-tablet tasks to osgeo projects
which are already written in java, but would love to hear ideas and needs.



grass-user mailing list

Re: [GRASS-user] g7 svn58117 r.random ERROR: There aren't [n] non-NULL cells in the current region

2013-10-31 Thread Hamish
Eric wrote:
 rows:   64019
 cols:   65916
 cells:  4219876404

64019 * 65916  signed 32bit integer so it overflows

is your system+grass 32 or 64 bit?

 Cell Count:  -75090892
 Null Cells:  2130552315

 A negative cell count? hmmm

that may just be a cosmetic issue in the printf'ing of the variables.

the first thing I'd try is to go to line 124 in main.c and (1) remove
the two casts to (int), then (2) change the two %d to %ld.
(nCells and nNulls are defined as long in local_proto.h)

grass-user mailing list

Re: [GRASS-user] Simple question

2013-10-29 Thread Hamish
Luis wrote:
 I'm trying to install r.denoise, but asked me for mdenoise software,
 I've downloaded this extra software, compile it, but I don't understand
 the last step, where it says...

 ln -s `pwd`/mdenoise /some/directory/on/the/$PATH
 Wich path is this? I'm using Ubuntu 12.04 ang GRASS 6.4.3.
copy the mdenoise executable into /usr/local/bin/.

type echo $PATH to see other suitable places to put it. Another common one is 
do mkdir ~/bin then log out and back in again (that's added to your $PATH at 
but only if it exists), and put the custom program there.

good luck,

grass-user mailing list

Re: [GRASS-user] Local Relief Model tool

2013-09-26 Thread Hamish
 To install in a linux environment, I followed the instructions at

 I haven't been able to find solid information on how users who don't
 compile themselves can install an addon that isn't available via

In general it's quite simple, users maintain a directory with all of
their executable scripts in it and before starting GRASS add
export GRASS_ADDON_PATH=/path/to/files
to their ~/.bashrc. (~/.grass.bashrc is no good, the variable has to
be set before grass starts)

Then it magically finds them. The g.extension module(s) just fits itself
into that and creates you an addon dir if one wasn't already set.
For scripts there is no other install or compiling needed, just put
it in a dir somewhere which is in the $PATH.

Python might be a problem, but if you just call your module by its full
name it should be ok (so with or without .py, just be sure to match
the exact filename).

 There is, but I'm
 not sure how that applies to Windows users. Any advice in this area
 would be much appreciated.

The GRASS 6 make system is still missing build support for python
scripts (often it tries to reuse the shell Script.make, which mostly
works on Linux). Smooth building with correct .bat file wrappers
on Windows remains an issue. It can be done, I've seen it work, but
still needs a new PythonScript.make to work smoothly. (similarly user-
created personal shell scripts for GRASS 7 should have a ShellScript.make
to help folks who need that, even if there are none in the main release.)


grass-user mailing list

Re: [GRASS-user] : ERROR: write sidx

2013-09-26 Thread Hamish
Yann wrote:
 The command was : -z input=${FILE} output=${NAME_OUT} separator=${FS} z=3 


just to note -- the {curly} brackets do nothing to
protect from spaces in filenames in this situation,
double quotes should be used for that.

the curly brackets protect the variable name, not its
contents, so are mostly useful for when a letter,
number, or _ follows the variable name.

I actually think it is dangerous to use the curly
brackets because it tricks people into thinking they
are protected when they are not.


grass-user mailing list

Re: [GRASS-user] : ERROR: write sidx

2013-09-26 Thread Hamish
Yann wrote:

 I tried from the Layer manager (i use sqlite driver) :

(Thu Sep 26 23:58:29 2013)
-z --overwrite --verbose 
output=PTS_menhir2_pc_88M separator=  z=3
WARNING: Vector map PTS_menhir2_pc_88M already exists and will be overwritten
Using native format
Scanning input for column types...
Maximum input row length: 30
Number of columns: 3
Importing points...
Building topology for vector map PTS_menhir2_pc_88M@menhir2...
Registering primitives...
88509169 primitives registered
88509169 vertices registered
Building areas...
0 areas built
0 isles built
Attaching islands...
Attaching centroids...
Topology was built
Number of nodes: 0
Number of primitives: 88509169
Number of points: 88509169
Number of lines: 0
Number of boundaries: 0
Number of centroids: 0
Number of areas: 0
Number of isles: 0
ERROR: write sidx: wrong node position in file
(Fri Sep 27 00:44:28 2013) Command finished (45 min 59 sec)

 I have some disk space, but i looked at my system monitor and my RAM
 went to SWAP (i have only 16 Go RAM, 15 Go SWAP) The swap don't seems
 to have been totally used (but at least half) and i have not in front
 of my PC when the error occurred.

 I will try this again with more RAM.

Ok, 88 million points and running 64bit Linux. Since 3D points
and no additional data columns columns I think it will default
to not creating a database, so you don't have to worry about the
-t flag or the memory needed for that, just the finite amount of
RAM per point for topology. Maybe 64GB RAM will be enough for 88M,
perhaps more, but it will need a lot to build topology for all those

May I ask what process you'd like to do with the data? Perhaps + helps reduce the number of points to something
more manageable. The '-r' flag can be helpful for importing
only those points within the current computational region of interest,
and if importing without building topology (the '-b' flag you tried
before) many of the LiDAR modules and have been modified
to work without needing it.
If it is some other vector module maybe we can modify it to load data
without topology too.
Is it sparse x,y data or gridded?


grass-user mailing list

Re: [GRASS-user] segfaulting

2013-09-24 Thread Hamish
Micha wrote:
 I can run las2txt and then import the text file with, but
 I'd like to work out what's wrong with the direct raster import. Any
 ideas how to further debug this?
 does las2txt + work?
 I'm using las2txt +, then That works as expected.

 The spread of the point cloud is very irregular, some cells (1x1 m)
 with 50+ points, and some with none, so I guess that would
 be less desirable?

I'd think that the point density case you describe would be the ideal
scenario for using or, so if anything I'd suggest
it was more desirable to conflate all the points within the sq. meter
to a single one as a pre-processing step than trying to fit a spline
to all of them (n.b. I'm not entirely familiar with's sub-cell
resolution decimation method, but if it isn't doing that beware the
close-proximity overshoots).

( uses the same binning method as (using libLAS for
the input stream instead of an ascii file) so you can expect the use
cases to be near identical, it just saves you the las2txt step. They are
mostly the same code.)

grass-user mailing list

Re: [GRASS-user] How to changer map order with line command on a Monitor

2013-09-23 Thread Hamish
Lucien wrote:

 I would like to know if there is a way to change
 the map order on a Monitor with line command (i.e
 with a d.* command).

Use ' -a' to save the monitor's command
list to a file, then edit that file, and either run (source)
the script or cut  paste to the terminal.

' remove=1,3,5 is also useful for removing commands
from the middle of the stack. the other outputs append
a # 3 comment to let you know the numbering if there are many.


grass-user mailing list

Re: [GRASS-user] Impossible to install GRASS - problem with libgdal1

2013-09-11 Thread Hamish
Hi Lucien,

 Following my previous message...
 I found the package libgdal1 but for installing it I have to uninstall 
 and also qgis... I did it and then tried to install qgis again but synaptic 
 to uninstal grass and libgdal1...
 It now impossible to work with GRASS and Qgis simultanuously.
 Any idea?

I'd suggest to check in with the UbuntuGIS mailing list, since they handle
the packaging for that PPA:

The combination is known to work on 12.04. (as of ~last week)

good luck,

ps- look in /etc/apt/sources.list and /etc/apt/sources.list.d/ for the
duplicate entry.

grass-user mailing list

Re: [GRASS-user] Tessellation of a set of polygons

2013-09-10 Thread Hamish
Thomas wrote:

  Let's consider a set of input polygons (represented by dark gray polygonal
  footprints in the enclosed screenshot [1]).
  [1] this screenshot of about 11 KB is also downloadable at
 just curious (given that GRASS GIS 7 now offers this functionality),
 with which GIS software did you create your example?

To make a guess I'd say it looks like + r.grow +
(note the gridding artifacts)


grass-user mailing list

Re: [GRASS-user] GRASS and libgeos 3.1.1/3.3.3

2013-09-04 Thread Hamish
Gary wrote:

 dpkg -l | grep libgdal
 ii  libgdal1             1.9.0-3.1ubuntu4   amd64        Geospatial Data
 Abstraction Library

ok, same as me  13.04,

 rc  libgdal1-1.5.0   1.5.4-4                 amd64        Geospatial Data
 Abstraction Library
 rc  libgdal1-1.6.0   1.6.3-3build2         amd64        Geospatial Data
 Abstraction Library
 rc  libgdal1-1.7.0   1.7.3-6ubuntu3      amd64        Geospatial Data
 Abstraction Library

(all removed)
 ldd /usr/lib/grass64/bin/g.proj | grep geos
 /usr/lib/grass64/bin/g.proj: /usr/local/lib/ no version
 information available (required by /usr/lib/grass64/bin/g.proj)

... /usr/local/lib/ ? Did you have a custom installed version
of GDAL in /usr/local? That may be the conflict. = /usr/lib/ (0x7fed2e466000) = not found = /usr/lib/ (0x7fed2b4dc000)
 So the problem is with the absense of 3.1.1, any way to tell grass to only
 use 3.3.3? 

I think it's actually GDAL which wants GEOS 3.1.1, the problem comes
along to GRASS through there when GRASS loads in GDAL.

 All this happened after upgrading ubuntu and upgrading packages,

I'd heard it prefers fresh installs to in-place upgrades, but I've never
tried it myself.

 I hadn't checked grass for a few months until I came to use it, it
 would be nice to get to my PhD data! I have backed up the mapsets on
 another drive,

I'd be confident that your data is ok, GRASS can be loaded onto any other
computer of opportunity to access it in an emergency.

 I tried completely removing grass and reinstalling but it didnt solve
 the problem.

Look for files related to an old GDAL version in the /usr/local/ dirs.


grass-user mailing list

Re: [GRASS-user] GRASS and libgeos 3.1.1/3.3.3

2013-09-04 Thread Hamish
 Gary wrote:

  dpkg -l | grep libgdal
  ii  libgdal1             1.9.0-3.1ubuntu4   amd64        Geospatial Data
  Abstraction Library
 ok, same as me  13.04,

er, hang on: you've got 1.9.0-3.1ubuntu4? 

me  ubuntu 13.04 have 1.9.0-3.1ubuntu1.

The 1.9.0-3.1ubuntu4 package looks like it comes from Saucy Salamander
(aka 13.10) which isn't released yet, due next month:

? any clues about the ubuntu version in /etc/apt/sources.list and 
/etc/apt/sources.list.d/ ?

what does this say about installed vs. available GDAL versions:

$ apt-cache policy libgdal1



grass-user mailing list

Re: [GRASS-user] GRASS and libgeos 3.1.1/3.3.3

2013-09-04 Thread Hamish
Gary wrote:

 the -d has caused it to use the development version! But as GRASS had the
 same problem with 12.10 this shouldnt be the source of the main problem, is
 there anyway to revert to the 1.9.0-3.1ubuntu1?

I suspect the immediate problem is the extra+outdated GDAL version in
/usr/local/. It would be strange if a newer version of the GDAL ubuntu
package were depending on an older version of GEOS, right?

In addition, I don't see GEOS 3.1.1 available in any of the recent
ubuntu versions, so suspect the /usr/local/ custom installed version
is to blame for the bulk of the trouble.

You can use ldd on the libraries found with:

$ locate libgdal | grep '\.so'

to verify which one(s) are looking for libgeos 3.1.1.

$ ldd /usr/lib/ | grep geos
$ ldd /usr/lib/grass64/lib/ | grep geos


grass-user mailing list

Re: [GRASS-user] GRASS and libgeos 3.1.1/3.3.3

2013-09-03 Thread Hamish
Hi Gary,

 I have recently updated Ubuntu to 13.04, now I find when I open grass and
 select a mapset I get the following errors:
 Error 1
 g.proj or projection error... cannot open...
 Error 2
 Error setting region...
 Error 3
 same as error 1
 So I think the problem is that I have not
 So I guess two solutions, either install libgeos-3.1.1 or correct grass to
 search for 3.3.3.
 How would/should I do this?

where did you get your GRASS package from? UbuntuGIS?

working here with the stock 6.4.2-2build1 ubuntu grass package on Mint 15
(aka ubu 13.04) all's ok. (but that doesn't depend on geos at all- too old)

if the ubuntuGIS package please file a bug on their PPA or post to ubuntu at asking for a rebuild.

have a look at available dependencies  versions with:

apt-cache policy grass-core
apt-cache policy libgeos-dev

packages for GEOS 3.1.1 don't seem available on Raring as standard pkgs,


grass-user mailing list

Re: [GRASS-user] GRASS and libgeos 3.1.1/3.3.3

2013-09-03 Thread Hamish
[g.region failing on ubuntu 13.04 causing main startup to fail]

Gary wrote:

T hanks Hamish,
 installed 6.4.2-2bui l ch
 candicate 6.4.2-2bui l ch
 version table:
 *** 6.4.2-2bui I ch
 installed 3.3.3-1.1
 candicate 3.3.3-1.1
 version table:
 *** 3.3.3-1.1 0
 I installed grass through synaptic on Ubuntu (with R and other associated

That is strange, 6.4.2-2build1 doesn't depend on GEOS.

(apt-cache show grass-core and look at the Depends line)

What version of GDAL are you using? Is that from the standard ubuntu 
No PPAs in your list of software sources?

I see g.region only depends on PROJ.4 though, not GDAL..
(what version of the libproj is installed?)

 Could I remove libgeos and simply install version 3.1.1? Or could I
 reinstall GRASS (whilst keeping all my mapsets?)

As far as I can tell a 3.1.1 package doesn't exist.

here are the reverse package dependencies, anything look familiar?

$ apt-cache rdepends libgeos-3.3.3
Reverse Depends:

$ apt-cache rdepends libgeos-c1   
Reverse Depends:


grass-user mailing list

Re: [GRASS-user] GRASS and libgeos 3.1.1/3.3.3

2013-09-03 Thread Hamish
 [g.region failing on ubuntu 13.04 causing main startup to fail]

oops, that was g.proj failing.

 I see g.region only depends on PROJ.4 though, not GDAL..
 (what version of the libproj is installed?)

g.proj depends on GDAL libs which depends on GEOS.

what version of GDAL is installed? 1.9.0-3.1ubuntu1?

$ dpkg -l | grep libgdal

what does this say:

$ ldd /usr/lib/grass64/bin/g.proj | grep geos



grass-user mailing list

Re: [GRASS-user] v.overlay not working?

2013-09-01 Thread Hamish
MarkusN wrote:

  You may reconnect the table with v.db.connect.
 Done, it works.
 Unclear how the spurious cat crept in, however.
 So, apparently spaces in file name cause the issue.

right, the old vector/.../dbln file used spaces as the delim so out-of-spec(? 
[dbf]) layer names caused that trouble. In GRASS 7 that's been changed to a 
pipe (|), and support for reading dbln files using pipe as the field separator 
has been backported to GRASS 6. Also in 6.x _should_ be replacing 
whitespace in dsn names with underscores now, but if the problem still seen in 
a new import maybe that isn't working? (fixed in relbr64 1 year ago)



grass-user mailing list

Re: [GRASS-user] failing to import table

2013-09-01 Thread Hamish
Paolo wrote:
 GRASS 6.4.2-2 from Debian unstable.

just to note that Frankie  me hope to have the 6.4.3 package into 
in the coming days.

remaining issue has to do with subtleties of


grass-user mailing list

Re: [GRASS-user] v.lidar.edgedetection, and visualization issues

2013-08-27 Thread Hamish
In any case, if v.lidar.edgedetection or bspline is broken in WinGrass we 
should fix that. Is the trac bug ticket up to date on the matter? Luis could 
you post your error messages and versions there? maybe with some small test 
data or a link to download some?

A long term goal is to get rid of black box processing in science, a short term 
goal is to get our work done and move onto the next discovery. :)



grass-user mailing list

Re: [GRASS-user] Opening a shape file in GRASS 6.4.3

2013-08-21 Thread Hamish
Sonali wrote:
 I have redone the shape file, I am attching it again, and this is the
 error I get when I am trying to open it. The location is in india
 and spans two UTM zones and therefore I used lat lons

Projection of input dataset and current location appear to match
Layer: Meghalay
DBMI-DBF driver error:
ERROR: Unable to create table: 'create table Meghalay (cat integer, TYPE 
varchar ( 10 ), IDENT varchar ( 24 ), LAT double precision, LONG double 
precision, Y_PROJ double precision, X_PROJ double precision, NEW_SEG varchar ( 
10 ), DISPLAY varchar ( 10 ), COLOR varchar ( 10 ), ALTITUDE double precision, 
DEPTH double precision, TEMP double precision, TIME varchar ( 20 ), MODEL 
varchar ( 20 ), FILENAME varchar ( 254 ), LTIME varchar ( 20 ))'


perhaps TIME is a SQL reserved keyword, so you have to change that column name. 
(maybe TYPE too)

you can use the columns= option to do that. [hint: cut and paste the 
above as a starting point]


grass-user mailing list

Re: [GRASS-user] upload long lat coordinates to attribute table

2013-08-06 Thread Hamish
Pierluigi De Rosa wrote:

  I have a vector map into a mapset of projected CRS (epsg 3004). I have
  some issue to upload long/lat coordinates into attribute table of the
  vector map.
  What is the best/easy way to to that? upload coordinate but without reprojecting it's values.

perhaps use to print out the epsg:3004 coords and pipe
those through 'm.proj -o' to get long/lat, then either write that to
a formatted SQL file for db.execute or into a `while read` loop for
v.db.update (slower).

is it a points map?


grass-user mailing list

Re: [GRASS-user] Custom d.vect icons in WX-Python GUI

2013-08-02 Thread Hamish
Casey wrote:
 I have a series of custom icons/symbols that I often use when I create
 maps or display layers inside of the wx-gui. Older versions of the
 d.vect UI would recognize my grass-6.4.x/etc/symbol/CustomDirName
 directory and the list of CustomIcons inside of it.

note you can also use $MAPSET/symbol/group/name, but it has to be done
for each mapset. (perhaps we should also search ~/.grassX/symbols/ or
$GRASS_ADDON_PATH/symbols/ ? [tricky if multiple paths in ADDON_PATH])

the idea is to have custom addon items installed for you install-wide,
and survive a version upgrade or 'make distclean' without being deleted.

 With newer enhancements to the GUI which now displays the icon itself
 as opposed to directory/name only, I am no longer able to select any
 custom icons. 
 Note: I can still use the command line to display vector layers using a
 custom icon (e.g. d.vect map=camp icon=custom/camp)

d.vect will get them if the module was built after they were installed.
d.graph might work directly with a newly installed symbol.
the d.mark addon script needs to be edited by hand, but just the (unique)
symbol name, not the group name.

 How can I build my version of GRASS to allow me to choose icons in a
 custom symbol directory using the d.vect UI.

to see them in the GUI you need to make a thumbnail image with 
andinkscape. See gui/images/symbols/README in the grass source code for a 
script to do that. Put the pngs in that same ./gui/images/symbols/ dir 

for sharing/backup/possibly get them installed by default consider to
contribute them to

or somewhere in addons svn.


grass-user mailing list

Re: [GRASS-user] GRASS6.4.3rc4 could not find r.bebrisflow function

2013-08-01 Thread Hamish
Choosumrong wrote:
 I want to using r.debrisflow function to test the debris flow
 But, I could not find this function in GRASS 6.4.3RC4.

 Does it change the function name to the others name or where
 do I find this function?

I guess it is this?

It's not an official module, and no sign of it at:

so I'm not sure what to tell you. The Natural Hazards wiki page only links to 
the paper about it.



grass-user mailing list

Re: [GRASS-user] Interpolate grid(s) based on vector.

2013-08-01 Thread Hamish
Hi Bob,

 I have a set of rasters (ground acceleration, modal mag., and
 distance) that I want to interpolate based on the location of
 my point features (borehole location) and update my point feature
 with the values from this interpolation.  I see that v.what.rast
 might help, but I'm not sure what kind of interpolation it uses
 (probably nearest neighbor?).  I also see that v.sample can be
 used, but it does not work with geographic coordinate system locations.
 So, I was hoping that the list might have other ideas in solving my problem.

I think it is best to approach the problem in two steps. First
do your interpolations using a method appropriate to your data type,
sampling density, sensitivity to outliers, etc.
Then once you have your interpolated surface run v.what.rast, or
v.rast.stats, or from addons v.rast.stats2 or v.what.rast.buffer
depending if you want to pick off the exact interpolated value
at a given site, a statistical indicator for values around that
site (e.g. variance) as either a buffer distance or within a
given vector polygon.

By the way, we are currently discussing / upgrading the v.krige
offerings, you're most welcome to weigh in on the conversation
if that's what you're after.


grass-user mailing list

Re: [GRASS-user] Possible to switch off permissions check of mapsets?

2013-07-31 Thread Hamish
  ERROR: MAPSET PERMANENT - permission denied
  Any solution to this would be much appreciated.

  In any of the current SVN versions,
 setting the environment variable  GRASS_SKIP_MAPSET_OWNER_CHECK
 to any non-empty string will suppress  the check.

(that also includes 6.4.3-final by the way)

 Yes, but what for the people who wanna rely on the precompiled packages?
 And this could be a switch in the .grassrc or elsewhere.

it still works at run time. you can make it locally permanent on a
single user setup with:

echo export GRASS_SKIP_MAPSET_OWNER_CHECK=true  ~/.grass.bashrc

As with anything else, be sure to extra take care when disabling
safety mechanisms.


ps- the build-time compiler flag version is -DSKIP_MAPSET_OWN_CHK

grass-user mailing list

Re: [GRASS-user] result from g.copy when layer exists

2013-07-23 Thread Hamish
Nick wrote:

 Since we're talking about grass errors, is there a way to redirect the
 warnings/errors ?
 e.g. r.mapcalc ... 2error.log

see the GIS_ERROR_LOG file and/or environment variable.

simply touch ~/GIS_ERROR_LOG and it will start keeping a log of
all warnings and errors.

I am slightly suspicious that some recent changes may have broken
that, but give it a try.

grass-user mailing list

Re: [GRASS-user] interactive r.edit of rasters?

2013-07-22 Thread Hamish
Chris wrote:
 just wondering, are there any basic tools for interactively editing
 rasters, (not just the categories) ?


the module d.rast.edit should help. If using GRASS 6.4 on Windows you'll
want to use the 6.4.3 RC4 version since it was recently
fixed there.


grass-user mailing list

Re: [GRASS-user] hydro-flatenning process ?

2013-07-11 Thread Hamish
Jed wrote:

 None of these, or any of GRASS's other surface interpolation tools that 
 I'm aware of, consider breaklines. Although a feature request was filed
 4 years ago:

see the v.triangle addon module,

ticket updated. (breaklines in would still be awesome :)


grass-user mailing list

Re: [GRASS-user] GRASS GIS 6.4.3RC4 released

2013-07-11 Thread Hamish
Markus Neteler wrote:
* ... further packages will follow shortly.

if anyone needs .debs for Debian/Squeeze or Wheezy, just let me know.


grass-user mailing list

Re: [GRASS-user] Delete line segments smaller than threshold

2013-07-07 Thread Hamish
Jon wrote:
 I know I've done this before, but I can't for the life of me
 find the functionality again.
 I am trying to manage some contours generated from LIDAR.
 Even with using just last returns I have lots of spurious contours. 
 Before, I was able to delete segments shorter than a given length
 threshold.  But I can't remember how.  v.edit allows removal *areas*
 smaller than certain sizes, and it also removes dangles but not
 just regular line segments?

v.db.addcol a new length column, double precision upload the line lengths to the attr column
v.extract where the line length is only greater than some threshold.

it's not great, but it works to get rid of the small loops.

re. the non-greatness about it, if you wish to keep things like the
tight contours at a mountain peak or isobars in the eye of a
hurricane, but throw away similar-sized loops out on the edges.. how
to do that?

see also v.generalize, but care must be taken around peaks not to
average the lines too much or else they pull together, artificially
cusping the feature. somewhere I've got v.generalize terms that try to
smooth the tightening rings using v.generalize without moving them
inwards much. I don't think the solution was really great though, and
was sensitive to the digitization resolution/scale.

 Semi-related: LIDAR data from Erie County, NY used to be available
 for download as bare earth, and even you could specify a contour
  interval and download that as a shapefile.  Can't for the life of
 me find that either!

there used to be a NY State wide clearinghouse website for geodata,
with all of the DEC data and a bunch of county stuff linked from it.
If that's still around maybe a good place to look?

grass-user mailing list

Re: [GRASS-user] dbase driver in grass7

2013-07-04 Thread Hamish

 Note that the dbf/ subdirectory in the mapset must exist or must be
 created by the user.

I think that usually it gets created as needed automatically. There
may still be a few places it doesn't, if so file a ticket to fix..
(did a long audit for that in grass6 some time ago, tested in grass7
last week  it was automatically created as needed.)


grass-user mailing list

Re: [GRASS-user] GUI startup problems

2013-07-04 Thread Hamish
  Chiara wrote:
  while starting grass, I get this message:
  Starting GRASS ...
  ERROR: G_getenv(): Variable LOCATION_NAME not set
  Traceback (most recent call last):
     File /usr/lib/grass64/etc/wxpython/, line 221, 
       not os.path.isdir(os.path.join(self.gisdbase, location)):
     File /usr/lib/python2.7/, line 66, in join
       if b.startswith('/'):
  AttributeError: 'NoneType' object has no attribute 
  Error in GUI startup. If necessary, please
  report this error to the GRASS developers.
  Switching to text mode now.


 g.gui works correctly, and also X0 is there
 actually I could export the jpeg as I wanted
 so... the error causes no problem but it's there
 maybe will fix it installing the next version or updates
 yes, its GRASS 6.4.3 and i have the repositories of ubuntugis enabled
 thanks for the tips!!! :)

maybe try removing the ~/.grassrc6 file? does your user name, or mapset
path have accented letters in it? It doesn't like that much.


grass-user mailing list

Re: [GRASS-user] dbase driver in grass7

2013-07-04 Thread Hamish
Levente wrote:

 I was wondering about re-compiling GRASS7. I don't know if it is
 possible to compile it with the dbf connection as default.

see include/dbmi.h: #define DB_DEFAULT_DRIVER sqlite
and include/temporal.h: #define TGISDB_DEFAULT_DRIVER sqlite

change to dbf.

 I think that would solve my problem. What do you think?
 Does it make any sense?

typically just running db.connect early on to set the default database for the 
mapset in the $MAPSET/VAR file is enough. (or pre-seed that VAR file into the 
new mapset dir yourself)


grass-user mailing list

Re: [GRASS-user] GUI startup problems

2013-07-03 Thread Hamish
Chiara wrote:

 while starting grass, I get this message:
 Starting GRASS ...
 ERROR: G_getenv(): Variable LOCATION_NAME not set
 Traceback (most recent call last):
    File /usr/lib/grass64/etc/wxpython/, line 221, in 
      not os.path.isdir(os.path.join(self.gisdbase, location)):
    File /usr/lib/python2.7/, line 66, in join
      if b.startswith('/'):
 AttributeError: 'NoneType' object has no attribute 'startswith'
 Error in GUI startup. If necessary, please
 report this error to the GRASS developers.
 Switching to text mode now.

no idea.. once you are in the GRASS text session, will the GUI
start with g.gui ?

 it is a while (3-4 weeks) bus I usually work with script so I do not 
 use the GUI but I would possibly do it soon using the d.out.file...
 I tried it but I cannot enable the graphic display wiht d.mon so
 maybe something weird is happening in my computer...
 I work on Ubuntu 12.04

what does 'd.mon -L' say about x0 - x7?
  x0   X-windows graphics display
is it there?

which version of GRASS? from the main ubuntu packages or UbuntuGIS's ppa or 
GRASS Team ppa?

note d.out.file only works with d.mon start=x0, not the wxGUI.


grass-user mailing list

Re: [GRASS-user] GRASS place data in Geoserver database

2013-07-03 Thread Hamish
Kat wrote:
 I would like to know if there is any method (or suggestion)
 on how to place GRASS's processed data in a Geoserver
 using GRASS tools? if not, does anyone suggests any alternative?

it's a bit thin on details, but have a look here:

hopefully the MapServer hints translate to other Geoservers easily.
you can play around with the various geoserver softwares with
short tutorials (not grass specific) on the osgeo live dvd:

If someone knows how, a GRASS - Tilemill - Web tutorial in the GRASS wiki 
would be nice :)

probably the simplest/fastest grass - web method for raster maps is 'r.out.png 
-wt' + gdal's script. just copy the resulting dir into /var/www/ 
and you're done.


grass-user mailing list

Re: [GRASS-user] should this work on GRASS 6.4.3RC3?

2013-07-02 Thread Hamish

  Unfortunately I cannot get it to work. For example, attempting
  to connect to the following URL gives the following error on
  attempting to connect:
  Traceback (most recent call last):
  line 196, in OnConnect
  if 'style' not in layers[lastLayer]:
 that's an error in the 6.4 wxGUI front-end. Can you try to build
 the latest 6.4.3svn from source and see if it still breaks?
 (the old version did not gracefully handle the `xml2` parser
 program being missing, but now it tells you about it in an error
 message instead of failing with the traceback)

I believe the above error is from a missing `xml2`, but there is
another trouble with the module after that, that WMS server returns
subsection Titles (e.g. the next 4 layers are about ozone, and 
some explanation about what it is), which is confusing the parser which expects only Titles subordinate to
and following Layers. Even after testing to see if the layer is
set it still gets out of order as the subsection Title overwrites
the layer's title before the next Layer is created.

I'll open a bug for that.

But the script from the command line should still work.


grass-user mailing list

Re: [GRASS-user] should this work on GRASS 6.4.3RC3?

2013-07-02 Thread Hamish

 I installed xml2 and can now partially run from
 the Command console,
 but it appears to get stuck calculating tiles: output=MOD_LSTD_CLIM_E
 mapserver= layers=MOD_LSTD_CLIM_E
 format=geotiff maxcols=1024 maxrows=1024 method=nearest
 Calculating tiles
 I can see a  0 byte file in the LOCATION's .tmp directory.

also look in /or clear out files in ~/grassdata/wms_download/.
For me the instead of a PNG image the file actually contains
WMS XML capabilities with little indication of what was wrong
that I could see. for debug you get a .wget file in the
wms_download/ cache directory with the tile's raw download

it's quite frustrating to support WMS, every WMS server likes
to respond to query failures in its own different and unique

 In GRASS7 I can download the capabilities document, but not
 any layer, running from GRASS' Command console in the Layer

fwiw in qgis 1.8.0 I could get that server to return data, but
something wasn't quite right with the positioning.

I believe the grass 7 version lets you try a number of different
methods? maybe more luck with something other than the default.


grass-user mailing list

Re: [GRASS-user] should this work on GRASS 6.4.3RC3?

2013-07-02 Thread Hamish
 See above -- Can't find which is package to be installed in openSUSE
 12.3 yet.

no idea, in Debian/Ubuntu-land it's in the xml2 package.

it's a series of small CLI programs, so easy to build from source
if needed,

but it's kinda common, so I'd be surprised if there wasn't a
rpm for it somewhere..

grass-user mailing list

Re: [GRASS-user] r.walk output and garray

2013-07-02 Thread Hamish
  - while python is running I get the following error (but code keeps on
  running) :  ERROR: Unable to create file

 Just wild guessing: here is ^^^ a slash in the path-name. Is this valid in 

Yeah I think it is valid in that context actually, even if it looks weird.

I'd check if the .tmp/ directory really exists and if you can create new files 
there by hand.


ps- using PERMANENT as the day-to-day working mapset is not recommended.

grass-user mailing list

Re: [GRASS-user] should this work on GRASS 6.4.3RC3?

2013-07-01 Thread Hamish
Richard wrote:

 I've installed into GRASS 6.4.3RC3, but I cannot
 import a layer. 

It's not working yet.

Is the original also not working for you, or did you just
want to try out the new  improved version?


grass-user mailing list

Re: [GRASS-user] should this work on GRASS 6.4.3RC3?

2013-07-01 Thread Hamish

 Is the original also not working for you, or did
 you just want to try out the new  improved version? 

 Unfortunately I cannot get it to work. For example, attempting
 to connect to the following URL gives the following error on
 attempting to connect:
 Traceback (most recent call last):
 line 196, in OnConnect
 if 'style' not in layers[lastLayer]:
 I tested the URL in QGIS and the server is active.

that's an error in the 6.4 wxGUI front-end. Can you try to build
the latest 6.4.3svn from source and see if it still breaks?
(the old version did not gracefully handle the `xml2` parser
program being missing, but now it tells you about it in an error
message instead of failing with the traceback)

But I'm wondering if the shell script that comes
default with GRASS 6.4.svn is working for you or not. It works
for me from the 6.4 command line (nicer with xml2 installed), -l maps=; out=dummy

note you'll get an error message at the start since their server
doesn't support http POST, but it automatically fails-over to the
GET method and tries again. you could use the -g flag for that:
  -g   Use GET method instead of POST data method
    This may be needed to connect to servers which lack POST capability
and avoid the warning/save one second or two.

and/or install `xml2` and the GUI version should start working.


grass-user mailing list

Re: [GRASS-user] version 6.4.3 and mysql

2013-06-30 Thread Hamish
Mike wrote:
 I have a question about Version 6.4.3 for Windows 7. Is there a
 way to access MySql databases from within the software? I don't
 see it listed as one of the drivers in the GUI, but am hoping
 there is a means by which to connect and retrieve or update data.


looking at 'g.version -b' there it seems that the Windows installer
was not built with MySql support. (Sqlite, PostgreSQL, DBF, and
ODBC are there) I don't think there's any big reason for it not
being there except that the packager didn't add that option
when they were building it. (it's a bit more that just adding
the --with-mysql switch in the configuration, we also have to
build and ship the needed mysql libraries)
I'm not sure how much extra work it would be to add it, but it's
just a matter of rebuilding the package as far as I know. If you
are familiar with that sort of thing all the instructions are on
the wiki and build scripts in the tools directory our addons repo-
sitory and mswindows/ directory in the main source code. It relies
on the osgeo4w build infrastructure,

Otherwise please feel free to file a wish ticket in the trac system,
and hopefully someone with talents in the area can enable it for
you. I think MySql on Windows is a pretty common combination, so
it sounds like a reasonable request to me.

For now you might see if you can communicate with mysql through 

the common ODBC driver?


grass-user mailing list

Re: [GRASS-user] Extract a smaller image (sample) from a raster map

2013-06-30 Thread Hamish
Nikos wrote:

 2. set the computational region using g.region, e.g.
   - g.region rast=YourRastMap will set the computational region to 
      match the extent of your raster map (which is _not_ what you are
      after, if I got it right)
   - g.region w= e= s= n= to set a custom defined computational region

just a little side note, at this point in the process it is always
good to check the computational region result with 'g.region -p',
if the bounds and or resolution got messy you can fix it with the
'g.region align=original_map' command, or 'g.region -a res=...' at
the chosen resolution.

also, if you changed anything with r.region it is probably best to
delete the first attempt and re-import the map from the raw file.


grass-user mailing list

Re: [GRASS-user] r.neighbors velocity

2013-06-29 Thread Hamish

here are the same results for Soeren's test program, with the Open64
compiler from AMD:

 - Same AMD X6 CPU as below.
 - Open64 compiler from AMD  (GPLv2, LGPL)

I just downloaded the pre-built RHEL5 binary tarball and they worked
on Debian/squeeze, I just made an alias to the executable in the un-
tarred bin/ dir to get it to work.
 see also
Source is available of course, but according to the Debian ITP ticket
it's a bit of a pain to build there.

straight opencc:

real  0m59.015s | 0m58.972s | 0m58.963s
user  0m58.760s | 0m58.812s | 0m58.624s
sys   0m0.248s  | 0m0.136s  | 0m0.300s

opencc -O3:

real    0m35.203s | 0m35.173s | 0m35.204s
user    0m35.206s | 0m35.174s | 0m35.206s
sys     0m0.000s  | 0m0.000s  | 0m0.000s

opencc -Ofast (with or without -march=auto for native bytecode)

real  0m13.389s | 0m13.402s | 0m13.435s
user  0m13.389s | 0m13.405s | 0m13.437s
sys   0m0.000s  | 0m0.000s  | 0m0.000s

opencc -Ofast -march=auto -apo on a 6-(real)-core CPU
v is 2.09131e+13

real  0m2.552s  | 0m2.595s  | 0m2.591s
user  0m14.857s | 0m14.725s | 0m14.725s
sys   0m0.008s  | 0m0.024s  | 0m0.016s

'-apo' is autoparallelization, poorly documented, but it works!
it adds OpenMP pragmas where it thinks it can  where it will
cause a gain; I'm glad to see it's not just for the fotran
compiler anymore.

So the Open64 compiler is not quite as fast as Intel's one for this
test case, but it's pretty close versus the more versatile gcc in the
far distance. Executable file size for all of the above was less than
12kb, since it can link to local OS shared libs.

I haven't tried it with llvm/clang.

Now I wonder which flags to use to recreate -Ofast in gcc to make it
a fairer comparison..


 I also ran it on an AMD Phenom II X6 1090T  (icc -xHost -- -xSSSE3 ?)
 All times real; all output was v is 2.09131e+13.
 gcc 4.4.5 with standard-opts: 7kb binary
  == near parity single-threaded performance with the new i7 chip from
 the 2 year old AMD Phenom and older copy of gcc! (stock debian/squeeze)
   1m16.175s | 1m15.634s | 1m16.029s
 icc 12.1 with standard-opts:
   0m32.975s | 0m33.079s | 0m33.249s
 icc with -fast opt: (700kb binary)
   0m9.577s | 0m9.572s | 0m9.583s
 icc with -parallel auto-MP: (31kb binary)
  == again near parity with the new i7 chip! even with the Intel-biased
 compiler.  user cpu-time was actually less. the advantage of 6 real
 cores vs 4 real+4virtual ones.*
   0m6.406s  | 0m6.404s  | 0m6.404s
   0m37.106s | 0m37.170s | 0m37.106s
   0m0.044s  | 0m0.040s  | 0m0.028s
 icc with -fast and -parallel: (2mb binary)
   0m2.002s  | 0m2.002s  | 0m2.002s
   0m10.765s | 0m10.769s | 0m10.769s
   0m0.016s  | 0m0.012s  | 0m0.008s
grass-user mailing list

Re: [GRASS-user] r.neighbors velocity

2013-06-29 Thread Hamish
Markus Metz wrote:

 Some more results with Sören's test program on a Intel(R) Core(TM) i5
 CPU M450 @ 2.40GHz (2 real cores, 4 fake cores) with gcc 4.7.2 and
 clang 3.3
 gcc -O3
 v is 2.09131e+13
 real    2m0.393s
 user    1m57.610s
 sys    0m0.003s
 gcc -Ofast
 v is 2.09131e+13
 real    0m7.218s
 user    0m7.018s
 sys    0m0.017s

nice. one thing we need to remember though is that it's not entirely
free, one thing -Ofast turns on is -ffast-math, 

 This option is not turned on by any -O option besides -Ofast since it can
 result in incorrect output for programs that depend on an exact
 implementation of IEEE or ISO rules/specifications for math functions. It
 may, however, yield faster code for programs that do not require the
 guarantees of these specifications.

which may not be fit for our purposes.

With the ifort compiler there is '-fp-model precise' which allows only
optimizations which don't harm the results. Maybe gcc has something

Glad to see -floop-parallelize-all in gcc 4.7, it will help us identify
places to focus OpenMP work on.


grass-user mailing list

Re: [GRASS-user] Environment variables to use grass from python on windows

2013-06-28 Thread Hamish
Pierric wrote:

 Hence the Grass main folder is located in C:\Program Files (x86)\Quantum 
 GIS Lisboa\apps\grass\grass-6.4.2  
 Unfortunately when running the last line import grass.script , I get 
 an error message saying that grass library could not be found. I have tried 
 different things but I cant figure out what I am missing.

I believe the python library was formally introduced, and definitely refined,
after the 6.4.2 release. So the one that came with your copy of QGIS is too
old. Please try a recent nightly build of 6.4.3svn,

(and let us know how it goes, python scripts on Windows suffer from
filename extension confusion when multiple copies of Python are
installed by different programs, each of which wish to be associated
with .py, and so any feedback that helps us navigate through that
maze is quite valuable, especially from anyone who knows the Python
on Windows quirks well)


grass-user mailing list

Re: [GRASS-user] r.neighbors velocity

2013-06-28 Thread Hamish
    compiler.  user cpu-time was actually less. the advantage of 6 real
    cores vs 4 real+4virtual ones.*
  0m6.406s  | 0m6.404s  | 0m6.404s
  0m37.106s | 0m37.170s | 0m37.106s
  0m0.044s  | 0m0.040s  | 0m0.028s

icc with -fast and -parallel: (2mb binary)
  0m2.002s  | 0m2.002s  | 0m2.002s
  0m10.765s | 0m10.769s | 0m10.769s
  0m0.016s  | 0m0.012s  | 0m0.008s

(* I know from some earlier tests that hyperthreading is computationally
overheady, on a 12 real + 12virtual core Xeon, using about 11 real cores
took the same wall-clock time as 12 real + 5 virtual cores, it only beat
the 12 real cores as I got up to about 19 total cores, and full 24 cores
was in the new percentage points gain  very much diminishing returns)


ps- we have to pay for icc/ifort academic (research) licenses now, but
the student (homework/classroom) license for linux is still gratis
if you dig around their dev website. Also AMD has their Open64
compiler to play with
grass-user mailing list

Re: [GRASS-user] error while loading shared libraries

2013-06-27 Thread Hamish
Richard wrote:

 Resolved by completely uninstalling and reinstalling (via Synaptic
 Package manager) and then re-installing the addon.

It is expected that when you install a new version of GRASS you'll
have to rebuild any self-compiled addons modules written in C or C++.
Bash and Python scripts should be ok, it's only the internal API/ABI
which is not guaranteed. (change frequency seems to be once per 6
months or year in the stable branch; currently it's stable since Feb 2012)

You'll find a menu item if you are using
the wxGUI extension manager. If running from the command line I think
just rerunning g.extension to remove then reinstall the module is enough.


grass-user mailing list

Re: [GRASS-user] How to plot a vector field?

2013-06-27 Thread Hamish
David wrote:

 I would like to plot data which consist of a number of points, each of 
 which has a latitude, a longitude, an x-velocity, and a y-velocity.  I 
 want to plot an arrow for each point that starts at the proper latitude 
 and longitude, and has a length and direction that show the velocity.  I 
 used to think of these as vector values, but in GRASS a vector is 
 something else.  What is the proper GRASS terminology for this kind of 
 data?  What modules do this kind of plot?


use the d.barb module from GRASS 6 addons.

x and y components of velocity are given using attribute column names
in the u= and v= parameters when a GRASS vector (i.e. sparse points)
input= map is given.

vector maps mean defined by coordinates, so points, lines, and areas.
raster maps mean defined by 2D or 3D array, so constant grids and pixels.

d.barb will work with both GRASS raster and vector points maps,
the meaning of the u=, v= parameters changes according to the context.

 d.barb [-r] [direction=name] [magnitude=name] [u=name] [v=name]
   [input=name] [layer=value] [style=string] [color=name] [skip=value]
   [scale=value] [peak=value] [aspect_type=string]
   [legend_at=x,y[,x,y,...]] [legend_velo=value[,value,...]]
   [legend_fontsize=value] [--verbose] [--quiet]

  -r   Rotate direction 180 degrees
    Useful for switching between atmospheric and oceanographic conventions
 --v   Verbose module output
 --q   Quiet module output

    direction   Raster map (or attribute column) containing velocity 
    magnitude   Raster map (or attribute column) containing velocity 
    u   Raster map (or attribute column) containing u-component of 
    v   Raster map (or attribute column) containing v-component of 
    input   Name of input vector map
    layer   Layer number
 A single vector map can be connected to multiple database 
tables. This number determines which table to use.
    default: 1
    style   Style
    options: arrow,barb,small_barb,straw
    default: arrow
    color   Color
 Either a standard color name or R:G:B triplet
    default: black
 skip   Draw arrow every Nth grid cell
    default: 10
    scale   Scale factor for arrow rendering
    default: 1.0
 peak   Maximum value for scaling (overrides map's maximum)
  aspect_type   Direction map aspect type
    options: cartesian,compass
    default: cartesian
    legend_at   Screen percentage for legend barb ([0,0] is bottom-left)
 Draws a single barb and exits
    options: 0-100
    default: 10.0,10.0
  legend_velo   Velocity for legend key arrow
  legend_fontsize   Font size used in legend
    default: 14

it's still a work in progress, but ~90% of the features are working.


grass-user mailing list

Re: [GRASS-user] r.le.out subdirectory

2013-06-20 Thread Hamish
Johannes wrote:
 I just wanted to try out the r.le.* tools for a simple
 analysis of habitat patch patterns. In this context,
 I was not able to find out where this r.le.out
 subdirectory is located where all the result tables 

 are stored? Should this be a subdirectory
 within the mapset?

I'm not sure, maybe relative to the
directory you start the module from.
Try 'mkdir'-ing r.le.out/ first, then
running from pwd. (make sure you have
write permissions there.


grass-user mailing list

Re: [GRASS-user] r.le.out subdirectory

2013-06-20 Thread Hamish
 Johannes wrote:

  I was not able to find out where this r.le.out
  subdirectory is located where all the result tables

 Maybe in ~/ ?

just fyi for grass 7 I'd plan to move both r.le.out and
dirs into ~/.grass7/.
 or, find out with locate (first run updatedb as root)

always useful :)


grass-user mailing list

Re: [GRASS-user] access to multispectral landsat data for the UK

2013-06-20 Thread Hamish
Daniel wrote:

  I don't know where you are looking for these landsat images but they are
  free of cost for everyone. Take a look at the Earth Explorer[1] site from
  USGS. Even Landsat 8 data is available. I just cheched and found about 60
  Landsat8 images over UK and Ireland with less then 30% cloud cover.
  [1] -

 Count also in.

not specifically limited to landsat, but these are great resources too:

nice MODIS etc. data portal:

EOLi:   (`eolisa` java app)

(`visat` is yet another java app)


grass-user mailing list

Re: [GRASS-user] image spatial syncronization

2013-06-19 Thread Hamish
Daniel wrote:
 You could also try a software called regimy (or some other
 spelling). If I recall correctly, it was developed by some
 guys at inpe

this seems to be the one: REGEEMY

 and it finds matching control points between a set of images.
 We have been using it for some old landsat images. 

Restrictive license, no linux binary since 2006 and no source
code to recompile it for 64bit, so I won't bother to add it
to the wiki (but if it's super useful I don't mind), but seeing
they haven't touched in in years maybe the authors could be
convinced to set it free?


grass-user mailing list

Re: [GRASS-user] with GRASS 7?

2013-06-18 Thread Hamish
 I use it in Grass 7. it works. 

Adam wrote:
 Is compatible with GRASS 7.0?


I don't think there is a newer version, but there's
a good chance that the GRASS 6 one still works. Give
it a try and let us know!

 Thanks.  It is working.


 In general cloned code is to be avoided, and svn
 supports symlinking, so a possible solution for
 known working addons (scripts) is to symlink in
 the parent directory. Hopefully the build system
 is not too grumpy about mixed python and shell
 scripts. If it is we should come up with a solution
 to fix that.

I've just added a new dir in the grass7/raster addons, with 
symlinks back to the grass6 dir. I had to do each file individually instead of 
jus the dir since description.html needs to be renamed to [g.module].html. Svn 
stores it as a link file internally, and I believe a checkout on Windows will 
make a full copy of the files since there are no symlinks there.

if it works it will be a nice temporary solution to avoid the extra maintenance 
overhead and divergence.


grass-user mailing list

[GRASS-user] new north arrow symbols

2013-06-18 Thread Hamish

six new north arrow symbols to try out:

I'm not toally happy with n_arrow5: I didn't figure a way
to make a hole in the filled-arc, so the N is hardcoded
to filled-with-white. (so you can't set inverse colors on
that one. the big triangle in it is transparent btw)

hmm, maybe I could leave a sliver to the outside space
then mask over it with a polygon with no border color
and background color matching the main body?  ... TBC


grass-user mailing list

Re: [GRASS-user] Use of in python with stdin

2013-06-17 Thread Hamish
So I tried without:

ascii = cat,X,Y,Name

cols = 'cat int, x varchar(10), y varchar(10), name varchar(10)'


which at least executes but gives me following error:
 GRASS_INFO_ERROR(13239,2): Unparsable longitude
value in column num 2: X

you need skip=1 or put a # in front of the first line, it's trying
to parse the header line.

style: since the stdin= option is a virtual one for
grass.write_command(), consider putting it last.


grass-user mailing list

Re: [GRASS-user] with GRASS 7?

2013-06-17 Thread Hamish
Adam wrote:

 Is compatible with GRASS 7.0?  It doesn't seem to
 be listed on the GRASS7 Raster AddOns page.  And, the install
 instructions that I have found all refer to GRASS 6.  

 I have the nnbathy binary from 6 working fine.  Can I just copy over
 the script and binary?  Is there a new version?

I don't think there is a newer version, but there's
a good chance that the GRASS 6 one still works. Give
it a try and let us know!

In general cloned code is to be avoided, and svn
supports symlinking, so a possible solution for
known working addons (scripts) is to symlink in
the parent directory. Hopefully the build system
is not too grumpy about mixed python and shell
scripts. If it is we should come up with a solution
to fix that.


grass-user mailing list

Re: [GRASS-user] image spatial syncronization

2013-06-16 Thread Hamish
Markus Neteler wrote:

 The easiest thing might be to use a SIFT algorithm in order to find the
 GCPs automatically. Then use those as an input for i.rectify or similar.
 SIFT is used by Hugin for example.
 I used autopano-sift-C for a similar task (Fedora, rpmfusion-free 



grass-user mailing list

Re: [GRASS-user] help with testing the location wizard for the upcoming release

2013-06-15 Thread Hamish
Nikos wrote:
 Below, maybe not exactly something that helps the testing
 process... but, anyway here it goes: 

everything helps :)

 I guess it is not possible to follow the good old text-
 based way in building a custom coordinate system.

So I guess you are missing the ability to set the datum
transform terms? (+towgs84=)

- Select coord sys parms from a list
- tmerc
- enter coeff's
- ellipsoid only
- grs80
- summary: +towgs84=0.0,0.0,0.0  :-(

 All is ok using the correct epsg code (e.g. 2100). 
 However, what about replicating the above process
 with the new Wizard?

epsg gives +datum=GGRS87, but that is not known to 'proj -ld'
or GRASS's datum.table and datumtransform.table AFAICS.

so the first thing to do is add it to datum*.table, then
make the location wizard aware of datumtransform.table, and
also have the location wizard have an option to prompt for
custom datum transform terms.

grass-user mailing list

Re: [GRASS-user] Directed vector networks (e.g. river networks)

2013-06-14 Thread Hamish
Pietro wrote:
 A possible way to check the right direction using pygrass is
 Of course you can implement the same in C.

also try 'd.vect display=dir' to draw arrows on lines showing

grass-user mailing list

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

2013-06-14 Thread Hamish
Hamish wrote:
 another potential problem I see is that the Makefile for both
 modules are calling Script.make instead of Python.make.

 Should I change it or is it working anyway? I wasn't aware of

no, don't change it yet, grass6's Python.make is still needs a
bit of work. A lot of it seems to be unused left-overs from the
old SWIG interface, and I am unsure what a final install for a
python module on WinGrass should look like. (does it need a .bat
file wrapper? should that .bat wrapper call GRASS_SH or
GRASS_PYTHON? if we keep the .py extension there can g.parser
be aware of PATHEXT and so call the program without adding .py?)

likewise, shell script addon modules need to be tested with
grass7's make system.

grass-user mailing list

Re: [GRASS-user] grass 6.4.3 MSYS interface within windows 8

2013-06-13 Thread Hamish
 how can I start msys console to run shell script mode within
 grass gis 6.4.3 on windows 8?

I haven't tried GRASS on Windows 8 myself, but from what I
understand there is a feature where you can type in what you
want to run and it will find the menu shortcut for you.

The Start Menu link you are looking for is called:

  GRASS GIS 6.4.3svn GUI with MSYS

the shortcut launches:
C:\Program Files\GRASS GIS 6.4.3svn\msys\msys.bat /grass/ -wx

and is started from this directory:
C:\Program Files\GRASS GIS 6.4.3svn\msys

if all else fails I hear there are a number of 3rd party
addons to Windows 8 that restore the Start button and menus.

If you discover any secret tricks in getting it to work smoothly,
please let the list know.

grass-user mailing list

Re: [GRASS-user] Merge parallel roads

2013-06-12 Thread Hamish
Hendrik wrote:
 BTW, is there a way to connect the end points of two lines
 that are close together, but not any of the vertices along the
 lines? So something like v.clean tool=snap, but only for the end

I wonder if you could do to extract the line-end node
positions, then run v.distance with a carefully set threshold to
make lines between them, then v.patch it all back together.
You'd probably want to run both before and after.

grass-user mailing list

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

2013-06-11 Thread 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

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

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/
 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 :)

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. 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 script you used to download starts runs ok...

grass-user mailing list

Re: [GRASS-user] Merge parallel roads

2013-06-09 Thread Hamish
Markus N wrote:
 I have an unsubmitted module v.centerline which extracts
 the centerline from irregular vector polygon(s). Perhaps this
 approach could be used here as well. It works like this
 (I would be pleased to make this script available to a user
 who wants to make it production ready as I don't find the time):

is the prototype working well? or is it still at the theoretical/
experimental stage?

I have thought about this problem a lot, it is related to the
classic river mile problem which requires defining the center
line of the river in a non-arbitrary way.

the basic idea is to combine both parallel lines into a single map,
run v.buffer to enclose them both, then get a big mosquito to pull
all the volume out of the buffer until it is thinned to a single line.
for two parallel lines it is not so bad, but when you get splits and
convergences and islands it gets ugly. actually the raster tools are
pretty good for it but they don't work well when the length:width ratio
are so very different as they are for a road or a river. maintaining
a similar digitization scale/vertex resolution as the original polygon
is another tricky but not critically important final detail.

 - skeletonize (
 - TODO: extract longest line (no idea)

this is an approach I have not considered. will take a little thinking
about. but if solves the worst part of the problem
then I think the longest line should not be so hard to solve with one
of the tools.

there is a bit in the archives, as well as a user donated v.centerline

More on the difficulties of the river mile problem and ideas about it:

see also:

grass-user mailing list

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

2013-06-09 Thread Hamish
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 '':
 [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/
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:


then the %ADDONS%\ 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

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

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 :)
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.

grass-user mailing list

  1   2   3   4   5   6   7   8   9   10   >