Re: [GRASS-user] r.info output after r.reclass
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, r.info 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.info -r' and r.univar show the correct values. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Question about Elevation Maps and Shaded Relief Maps
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 time? 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%. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GeoTIFF, EPSG and GRASS
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, GEOGCS[RGFG95, DATUM[Reseau_Geodesique_Francais_Guyane_1995, SPHEROID[GRS 1980,6378137,298.2572221010002, AUTHORITY[EPSG,7019]], TOWGS84[0,0,0,0,0,0,0], AUTHORITY[EPSG,6624]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4624]], PROJECTION[Transverse_Mercator], PARAMETER[latitude_of_origin,0], PARAMETER[central_meridian,-51], PARAMETER[scale_factor,0.9996], PARAMETER[false_easting,50], PARAMETER[false_northing,0], UNIT[metre,1, AUTHORITY[EPSG,9001]], AUTHORITY[EPSG,2972]] 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, GEOGCS[grs80, DATUM[unknown, SPHEROID[Geodetic_Reference_System_1980, 6378137, 298.257222101]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433]], PROJECTION[Transverse_Mercator], PARAMETER[latitude_of_origin,0], PARAMETER[central_meridian,-51], PARAMETER[scale_factor,0.9996], PARAMETER[false_easting,50], PARAMETER[false_northing,0], UNIT[metre,1, AUTHORITY[EPSG,9001]]] 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 Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] i.rectify (or gdalwarp -off topic)
Milton wrote: Following Markus Neteler (and other) suggestioins, I was able to automatically generate a ground control point file for a large set of images. 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. Hi, 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 regards, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] exporting raster map to kmz?
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. Hi, (see http://grasswiki.osgeo.org/wiki/AddOns/GRASS_6#r.out.kml ) 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. regards, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] create a common colour scale
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 GRASS. 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 r.info in a loop and copy out the min,max by hand. for MAP in `g.mlist rast pattern=rain*` ; do r.info -r $MAP done then make a dummy map with r.mapcalc with overall min and max range. min=1.2345 max=9.8765 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 done 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. regards, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.hazard.flood
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 init_vars.c:134 WARNING: Subprocess failed with exit code 1 Madi: This log suggests that r.watershed, called by r.hazard.flood, is not able to finish the job due to lack of memory. [@devs] 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? regards, -- Hamish hamish.webm...@gmail.com . 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. . http://www.ietf.org/mail-archive/web/ietf/current/msg87153.html http://www.spamresource.com/2014/04/up-in-arms-about-yahoos-dmarc-policy.html http://wiki.list.org/pages/viewpage.action?pageId=17891458 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS and Blender
Hamish wrote: the added interoperability with VTK-aware software is always welcome Vincent: 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 needed/useful. but I've no idea how much code or complication we're talking about in this case, so just my 2c. regards, -- Hamish hamish.webm...@gmail.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS and Blender
Giovanni wrote: - mantain (somehow) geographical references to import back from 3D authoring sw (e. g. v.in.blender). 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. regards, -- Hamish hamish.webm...@gmail.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] trouble exporting to spatialite
On Mon, 19 May 2014 21:35:43 +0200 Markus Neteler nete...@osgeo.org 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. MarkusN: See http://lists.osgeo.org/pipermail/gdal-dev/2013-May/036148.html http://lists.osgeo.org/pipermail/gdal-dev/2013-May/036152.html ...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| 1|3.7.13|3.0.0-beta 2|geometry_columns||table successfully created|2014-05-19 23:14:31| 2|3.7.13|3.0.0-beta 3|spatial_ref_sys||table successfully populated|2014-05-19 23:14:32| 3|3.7.13|3.0.0-beta 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. thanks, -- Hamish hamish.webm...@gmail.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS and Blender
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: http://trac.osgeo.org/grass/browser/grass-addons/grass6/vector/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: http://grasswiki.osgeo.org/wiki/GRASS_and_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. regards, Hamish -- Hamish hamish.webm...@gmail.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] trouble exporting to spatialite
Hi, 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. 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: http://thread.gmane.org/gmane.comp.gis.grass.devel/35027/ regards, -- Hamish hamish.webm...@gmail.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] GRASS website temporarily down
Hi, 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 blame. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS website temporarily down
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 blame. ok, they are back up now. continued on the grass-dev list. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] calculation valley floor width in GRASS or some index indicating valley floor width?
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. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] ps.map grids
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: https://www.flickr.com/photos/carex/13433924714/ Hi, 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 ps.map 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. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] projection issue
Vincent: the trouble I am currently experiencing is dealing partly with cs2cs, but partly with grass, so I post my question on this list... 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 ? Hi, 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 all. Next thing to know is the +nadgrids=@null hack to get around the datum transform. See http://trac.osgeo.org/proj/wiki/GenParms#ThenullGrid and this basically explains the rest: http://trac.osgeo.org/proj/wiki/FAQ#ChangingEllipsoidWhycantIconvertfromWGS84toGoogleEarthVirtualGlobeMercator 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 that..). good luck, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] new addon: r.patch.many
Hi, 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. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] issues with netCDF import
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) Moritz: Try running r.in.gdal 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, 'r.in.gdal -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 r.in.srtm) see also http://grasswiki.osgeo.org/wiki/NetCDF regards, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.net.allpairs on PostgreSQL
Markus Metz wrote: v.net.allpairs 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. https://trac.osgeo.org/grass/changeset?new=55985%40grass%2Ftrunk%2Fvector%2Fv.net.allpairsold=53379%40grass%2Ftrunk%2Fvector%2Fv.net.allpairs regards, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] ps.map - eps frame affect/hide border and legend
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 problem: * 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 cli. 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. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] ps.map - eps frame affect/hide border and legend
Domenico wrote: I'm trying to output a ps file with ps.map (GRASS 6.4.2). Results from the psmap.def are good, with border, colortable, vlegend, etc.. http://osgeo.codepad.org/NtM3oJy0 (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. Hi, 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 ps.map instructions? thanks, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.hazard.flood does not respect region settings?
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']) +
float(dict_region['ewres']))/2
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
settings?
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 r.info
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.
regards,
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] libgrass_gmath
Dave wrote: I'm trying to do a simple dissolve on a vector map and getting a library error v.dissolve inp=vmap out=dom_mid_60 column=dom_mid_60 . . . . . . v.extract: error while loading shared libraries: libgrass_gmath.6.4.2.so: cannot open shared object file: No such file or directory However ls -l /usr/local/grass-6.4.2/lib shows -rwxr-xr-x. 1 root root 77615 Dec 21 2012 libgrass_gmath.6.4.2.so lrwxrwxrwx. 1 root root 23 Dec 21 2012 libgrass_gmath.so - libgrass_gmath.6.4.2.so just as I would expect, with read and execute permissions. Oddly, I'm running GRASS 6.4.3, but all the libraries are 6.4.2. This is on Scientific Linux 6 (derived from RedHat Enterprise linux 6). Hi, try: GRASS g.version -r :) GRASS echo $GISBASE GRASS echo $GRASS_LD_LIBRARY_PATH GRASS ls $GISBASE/lib GRASS echo $LD_LIBRARY_PATH that should show you where the grass install is located. It's usually fine to have many versions of GRASS installed at the same time, they can all run self-contained. -- you might check if the 6.4.2 install is listed in /etc/ld.so.conf or /etc/ld.so.conf.d/*, if so change it to the location of the 6.4.3 libraries and re-run `ldconfig` (as root). good luck, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRIB2 r.in.gdal problem
Lee wrote: I upgraded gdal to 1.10 and used r.in.gdal -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. regards, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRIB2 r.in.gdal problem
(sorry for top posting, no time to deal with yahoo mail today) Hi, note for GRIB you need gdal 1.10 or newer, there were edge coordinate bugs in earlier versions. --- see: http://grasswiki.osgeo.org/wiki/GRIB note grass uses the cell-center for data value convention, not the data values at grid line confluences (nodes) convention for raster arrays. 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 'r.in.gdal -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) http://grasswiki.osgeo.org/wiki/GRASS_raster_semantics#Cell_Locations http://grasswiki.osgeo.org/wiki/GRASS_FAQ#Errors but the first thing to verify for the GRIB format is that your gdal version is 1.10 or newer. regards, Hamish On Wednesday, February 12, 2014 6:21 PM, Lee Eddington lee.w.edding...@gmail.com 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: http://www.ftp.ncep.noaa.gov/data/nccf/com/gfs/prod/gfs.2014021112/gfs.t12z.master.grbf72.10m.uv.grib2 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):~ r.in.gdal 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 gfs.t12z.master.grbf72.10m.uv.tif.aux.xml Size is 720, 361 Coordinate System is: GEOGCS[Coordinate System imported from GRIB file, DATUM[unknown, SPHEROID[Sphere,6371229,0]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433]] Origin = (-0.250,90.250) Pixel Size = (0.500,-0.500) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=PIXEL 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 Metadata: GRIB_COMMENT=u-component of wind [m/s] GRIB_ELEMENT=UGRD GRIB_FORECAST_SECONDS=259200 sec GRIB_PDS_PDTN=0 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_SHORT_NAME=10-HTGL GRIB_UNIT=[m/s] GRIB_VALID_TIME=1392379200 sec UTC Band 2 Block=720x1 Type=Float64, ColorInterp=Undefined Description = 10[m] HTGL=Specified height level above ground Metadata: GRIB_COMMENT=v-component of wind [m/s] GRIB_ELEMENT=VGRD GRIB_FORECAST_SECONDS=259200 sec GRIB_REF_TIME=139212 sec UTC GRIB_SHORT_NAME=10-HTGL GRIB_UNIT=[m/s] 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? Thanks, Lee ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] i.ortho.photo trouble
Buslers wrote: I have been having trouble trying to use i.ortho.photo. It has been a few years since I have last used GRASS GIS. I knew that the i.ortho.photo 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 i.ortho.photo was not working in 6.4.3, but you could use it on windows running Cygwin. Which website is that? i.ortho.photo should be working fine on 6.4.3 in Ubuntu. It's only if you really want to run i.ortho.photo on Windows that you need worry about Cygwin. (Cygwin provides UNIX's X11 X-Windows, i.ortho.photo 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 i.ortho.photo to run on Ubuntu? I attempted to install Cygwin and winGRASS using the instructions from here - http://grass.osgeo.org/grass64/binary/mswindows/cygwin/, 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 i.ortho.photo, 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. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] installation of grass 7 unknown-linux binaries
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. http://wiki.wxpython.org/CheckInstall. Why can't you simply use the wxpython offered by ubuntu? Hi, there are pre-made grass7 packages for ubuntu already built, (albeit a few weeks out of date) https://launchpad.net/~grass/+archive/grass-devel http://grasswiki.osgeo.org/wiki/Ubuntu_Packaging 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: https://trac.osgeo.org/grass/browser/grass/trunk/debian/README.debian http://grasswiki.osgeo.org/wiki/Compile_and_Install_Ubuntu regards, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] how to draw line with arrow mark to line top (tip)
sgw00...@nifty.com 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. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS Android apps
Nikos: Excerpt from twitter: --%--- @NikAlexandris: @JollaHQ Who can confirm/where is information regarding the possibility to run #grassgis (http://t.co/OV5tyS27gC) 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 ---%-- Vaclav: 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] Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Permission denied to access a mapset in Linux
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. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass 6.4.3 - can't launch wxpython interface on Ubuntu 13.10
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. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Suse 12.3, GRASS 6.4.3 - addons not possible to install - SOLVED!
Otto: 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: https://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/Makefile#L101 regards, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] trouble with r.in.gdal to georeference a NetCDF file
Lee wrote: I'm trying to import a NetCDF file from the WRF weather forecast model with r.in.gdal, 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, see http://grasswiki.osgeo.org/wiki/NetCDF http://www.gdal.org/frmt_netcdf.html 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 r.in.gdal 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 distribution? Hamish 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@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] GRASS Android apps
Hi, I recently added a new page on the wiki regarding GRASS + Android. http://grasswiki.osgeo.org/wiki/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. e.g. https://f-droid.org/repository/browse/?fdfilter=perlfdid=com.qubling.sidekick https://f-droid.org/repository/browse/?fdfilter=manual%20fdid=com.chmod0.manpages 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 quickly. http://calibre-ebook.com/ 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. ? regards, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] g7 svn58117 r.random ERROR: There aren't [n] non-NULL cells in the current region
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) Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Simple question
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 to do mkdir ~/bin then log out and back in again (that's added to your $PATH at login, but only if it exists), and put the custom program there. good luck, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Local Relief Model tool
Eric: To install in a linux environment, I followed the instructions at http://grasswiki.osgeo.org/wiki/GRASS_and_Python#Testing_and_installing_Python_extensions. 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 g.extension. 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 http://grasswiki.osgeo.org/wiki/Compile_and_Install#Scripts, 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.) regards, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.ascii : ERROR: write sidx
Yann wrote:
The command was :
v.in.ascii -z input=${FILE} output=${NAME_OUT} separator=${FS} z=3
--overwrite
Hi,
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.
regards,
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.in.ascii : ERROR: write sidx
Yann wrote: I tried v.in.ascii from the Layer manager (i use sqlite driver) : (Thu Sep 26 23:58:29 2013) v.in.ascii -z --overwrite --verbose input=/media/yann/DATA_SIG/3D_photo/menhir2_pc_88M.csv 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 points. May I ask what process you'd like to do with the data? Perhaps r.in.xyz + r.to.vect helps reduce the number of points to something more manageable. The v.in.ascii '-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 v.surf.rst 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? regards, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.in.lidar segfaulting
Micha wrote: I can run las2txt and then import the text file with v.in.ascii, but I'd like to work out what's wrong with the direct raster import. Any ideas how to further debug this? Hamish: does las2txt + r.in.xyz work? Micha: I'm using las2txt + v.in.ascii, then v.surf.rst 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 r.in.xyz would be less desirable? I'd think that the point density case you describe would be the ideal scenario for using r.in.lidar or r.in.xyz, 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 v.surf.rst's sub-cell resolution decimation method, but if it isn't doing that beware the close-proximity overshoots). (r.in.lidar uses the same binning method as r.in.xyz (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.) regards, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] How to changer map order with line command on a Monitor
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 'd.save -a draw.sh' 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. 'd.save remove=1,3,5 is also useful for removing commands from the middle of the stack. the other d.save outputs append a # 3 comment to let you know the numbering if there are many. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Impossible to install GRASS - problem with libgdal1
Hi Lucien, Following my previous message... I found the package libgdal1 but for installing it I have to uninstall libgdal1h and also qgis... I did it and then tried to install qgis again but synaptic had 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: http://lists.osgeo.org/mailman/listinfo/ubuntu The combination is known to work on 12.04. (as of ~last week) good luck, Hamish ps- look in /etc/apt/sources.list and /etc/apt/sources.list.d/ for the duplicate entry. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Tessellation of a set of polygons
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 https://dl.dropboxusercontent.com/u/8846569/tessellation.png MarkusN: 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 v.to.rast + r.grow + r.to.vect. (note the gridding artifacts) Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS and libgeos 3.1.1/3.3.3
Gary wrote: dpkg -l | grep libgdal ii libgdal1 1.9.0-3.1ubuntu4 amd64 Geospatial Data Abstraction Library ok, same as me 13.04, http://packages.ubuntu.com/search?suite=raringkeywords=libgdal 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/libgdal.so.1: no version information available (required by /usr/lib/grass64/bin/g.proj) ... /usr/local/lib/libgdal.so.1 ? Did you have a custom installed version of GDAL in /usr/local? That may be the conflict. libgeos_c.so.1 = /usr/lib/libgeos_c.so.1 (0x7fed2e466000) libgeos-3.1.1.so = not found libgeos-3.3.3.so = /usr/lib/libgeos-3.3.3.so (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. regards, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS and libgeos 3.1.1/3.3.3
Gary wrote: dpkg -l | grep libgdal ii libgdal1 1.9.0-3.1ubuntu4 amd64 Geospatial Data Abstraction Library ok, same as me 13.04, http://packages.ubuntu.com/search?suite=raringkeywords=libgdal 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: http://packages.ubuntu.com/search?suite=allkeywords=libgdal ? 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 ? Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS and libgeos 3.1.1/3.3.3
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. http://packages.ubuntu.com/search?keywords=libgeos 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. e.g. $ ldd /usr/lib/libgdal.so.1 | grep geos $ ldd /usr/lib/grass64/lib/libgdal.so | grep geos Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS and libgeos 3.1.1/3.3.3
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... ...libgeos-3.1.1.so: cannot open... Error 2 Error setting region... Error 3 same as error 1 So I think the problem is that I have libgeos-3.3.3.so not libgeos-3.1.1.so 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 lists.osgeo.org 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, http://packages.ubuntu.com/search?keywords=libgeos regards, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS and libgeos 3.1.1/3.3.3
[g.region failing on ubuntu 13.04 causing main startup to fail] Gary wrote: T hanks Hamish, grass-core: installed 6.4.2-2bui l ch candicate 6.4.2-2bui l ch version table: *** 6.4.2-2bui I ch libgeos-dev: 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 programs) 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 repositories? 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 libgeos-3.3.3 Reverse Depends: libgeos-3.3.3:i386 osmjs osm2pgsql libgeos-dbg libgeos-c1 libgeos++-dev $ apt-cache rdepends libgeos-c1 libgeos-c1 Reverse Depends: libgeos-c1:i386 spatialite-gui python-shapely python-mpltoolkits.basemap python-mapscript postgresql-9.1-postgis php5-mapscript mapserver-bin libspatialite3 libqgis1.7.5 libplayerwkb3.0 libmapscript-ruby1.9.1 libmapscript-ruby1.8 libmapscript-perl libmapnik2-2.0 libgeos-ruby1.8 libgeos-dev libgeos-dbg libgdal1 cgi-mapserver confused, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS and libgeos 3.1.1/3.3.3
[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 ? Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.overlay not working?
MarkusN wrote: You may reconnect the table with v.db.connect. Paolo: 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 v.in.ogr 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) see https://trac.osgeo.org/grass/ticket/1328 regards, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] failing to import table
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 debian/unstable in the coming days. remaining issue has to do with subtleties of http://packages.debian.org/sid/libtiff5-alt-dev regards, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.lidar.edgedetection, v.surf.bspline and visualization issues
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. :) thanks, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Opening a shape file in GRASS 6.4.3
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 ))' Hi, perhaps TIME is a SQL reserved keyword, so you have to change that column name. (maybe TYPE too) http://grasswiki.osgeo.org/wiki/SQL you can use the v.in.ascii columns= option to do that. [hint: cut and paste the above as a starting point] Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] upload long lat coordinates to attribute table
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? v.to.db upload coordinate but without reprojecting it's values. perhaps use v.db.select 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? Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Custom d.vect icons in WX-Python GUI
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 ps.map 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 structure. for sharing/backup/possibly get them installed by default consider to contribute them to http://grasswiki.osgeo.org/wiki/IconSymbols#Contributions or somewhere in addons svn. regards, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS6.4.3rc4 could not find r.bebrisflow function
Choosumrong wrote: I want to using r.debrisflow function to test the debris flow simulation. 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? http://grasswiki.osgeo.org/wiki/Natural_Hazards#Debris_Flow It's not an official module, and no sign of it at: http://grasswiki.osgeo.org/wiki/AddOns so I'm not sure what to tell you. The Natural Hazards wiki page only links to the paper about it. regards, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Interpolate grid(s) based on vector.
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. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Possible to switch off permissions check of mapsets?
ERROR: MAPSET PERMANENT - permission denied Any solution to this would be much appreciated. Glynn: 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) Tim: 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. Hamish ps- the build-time compiler flag version is -DSKIP_MAPSET_OWN_CHK ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] result from g.copy when layer exists
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. http://grass.osgeo.org/grass64/manuals/variables.html#enviro 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. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] interactive r.edit of rasters?
Chris wrote: just wondering, are there any basic tools for interactively editing rasters, (not just the categories) ? Hi, 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. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] hydro-flatenning process ?
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: http://trac.osgeo.org/grass/ticket/793 see the v.triangle addon module, http://grasswiki.osgeo.org/wiki/TIN_with_breaklines ticket updated. (breaklines in v.surf.rst would still be awesome :) Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS GIS 6.4.3RC4 released
Markus Neteler wrote: * ... further packages will follow shortly. if anyone needs .debs for Debian/Squeeze or Wheezy, just let me know. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Delete line segments smaller than threshold
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? try v.build.polylines v.db.addcol a new length column, double precision v.to.db 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? regards, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] dbase driver in grass7
MarkusM: 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.) Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GUI startup problems
Chiara wrote:
while starting grass, I get this message:
...
Starting GRASS ...
ERROR: G_getenv(): Variable LOCATION_NAME not set
Traceback (most recent call last):
...
self._set_properties()
File /usr/lib/grass64/etc/wxpython/gis_set.py, line 221,
in
_set_properties
not os.path.isdir(os.path.join(self.gisdbase, location)):
File /usr/lib/python2.7/posixpath.py, 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.
Chiara:
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.
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] dbase driver in grass7
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) Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GUI startup problems
Chiara wrote:
while starting grass, I get this message:
...
Starting GRASS ...
ERROR: G_getenv(): Variable LOCATION_NAME not set
Traceback (most recent call last):
...
self._set_properties()
File /usr/lib/grass64/etc/wxpython/gis_set.py, line 221, in
_set_properties
not os.path.isdir(os.path.join(self.gisdbase, location)):
File /usr/lib/python2.7/posixpath.py, 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.
Hamish
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS place data in Geoserver database
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: http://grasswiki.osgeo.org/wiki/GRASS_and_MapServer http://grasswiki.osgeo.org/wiki/AddOns/GRASS_6#r.colors.out_sld 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: http://live.osgeo.org 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 gdal2tiles.py script. just copy the resulting dir into /var/www/ and you're done. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.in.wms2: should this work on GRASS 6.4.3RC3?
Richard: Unfortunately I cannot get it to work. For example, attempting to connect to the following URL gives the following error on attempting to connect: http://neowms.sci.gsfc.nasa.gov/wms/wms? Traceback (most recent call last): File /usr/lib/grass64/etc/wxpython/modules/ogc_services.py, line 196, in OnConnect if 'style' not in layers[lastLayer]: KeyError : '' ... 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 ogc_services.py 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 r.in.wms script from the command line should still work. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.in.wms2: should this work on GRASS 6.4.3RC3?
Richard: I installed xml2 and can now partially run r.in.wms from the Command console, but it appears to get stuck calculating tiles: r.in.wms output=MOD_LSTD_CLIM_E mapserver=http://neowms.sci.gsfc.nasa.gov/wms/wms? 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 command. it's quite frustrating to support WMS, every WMS server likes to respond to query failures in its own different and unique way. In GRASS7 I can download the capabilities document, but not any layer, running from GRASS' Command console in the Layer Manager. 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. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.in.wms2: should this work on GRASS 6.4.3RC3?
Nikos: 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, http://ftp.de.debian.org/debian/pool/main/x/xml2/xml2_0.4.orig.tar.gz but it's kinda common, so I'd be surprised if there wasn't a rpm for it somewhere.. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.walk output and garray
Pierric: - while python is running I get the following error (but code keeps on running) : ERROR: Unable to create file C:\A_GRID\PM\Grass\GrassDB/Location_L3/PERMANENT/.tmp/1824.0 Nikos: Just wild guessing: here is ^^^ a slash in the path-name. Is this valid in Windows? 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. Hamish ps- using PERMANENT as the day-to-day working mapset is not recommended. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.in.wms2: should this work on GRASS 6.4.3RC3?
Richard wrote: I've installed r.in.wms2 into GRASS 6.4.3RC3, but I cannot import a layer. It's not working yet. https://trac.osgeo.org/grass/ticket/2010 Is the original r.in.wms also not working for you, or did you just want to try out the new improved version? regards, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.in.wms2: should this work on GRASS 6.4.3RC3?
Hamish: Is the original r.in.wms also not working for you, or did you just want to try out the new improved version? Richard: Unfortunately I cannot get it to work. For example, attempting to connect to the following URL gives the following error on attempting to connect: http://neowms.sci.gsfc.nasa.gov/wms/wms? Traceback (most recent call last): File /usr/lib/grass64/etc/wxpython/modules/ogc_services.py, line 196, in OnConnect if 'style' not in layers[lastLayer]: KeyError : '' 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 r.in.wms(.sh) 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), r.in.wms -l maps=http://neowms.sci.gsfc.nasa.gov/wms/wms?; 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. regards, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] version 6.4.3 and mysql
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. Hi, 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, http://trac.osgeo.org/osgeo4w/ 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? regards, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Extract a smaller image (sample) from a raster map
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. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.neighbors velocity
Hi, here are the same results for Soeren's test program, with the Open64 compiler from AMD: - Same AMD X6 CPU as below. - Open64 compiler 4.5.2.1 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 http://wiki.open64.net/index.php/Installation_on_Ubuntu 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.. Hamish 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 grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.neighbors velocity
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 similar. Glad to see -floop-parallelize-all in gcc 4.7, it will help us identify places to focus OpenMP work on. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Environment variables to use grass from python on windows
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, http://wingrass.fsv.cvut.cz/grass64/ http://grass.osgeo.org/download/software/ms-windows/ (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) Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.neighbors velocity
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) regards, Hamish 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 http://developer.amd.com/tools/open64/Pages/ ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] error while loading shared libraries
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 g.extension.rebuild.all.py 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. regards, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] How to plot a vector field?
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? Hi, use the d.barb module from GRASS 6 addons. http://grasswiki.osgeo.org/wiki/AddOns/GRASS_6#d.barb 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. Usage: 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] Flags: -r Rotate direction 180 degrees Useful for switching between atmospheric and oceanographic conventions --v Verbose module output --q Quiet module output Parameters: direction Raster map (or attribute column) containing velocity direction magnitude Raster map (or attribute column) containing velocity magnitude u Raster map (or attribute column) containing u-component of velocity v Raster map (or attribute column) containing v-component of velocity 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. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.le.out subdirectory
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. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.le.out subdirectory
Johannes wrote: I was not able to find out where this r.le.out subdirectory is located where all the result tables Marco: Maybe in ~/.r.li/ ? just fyi for grass 7 I'd plan to move both r.le.out and r.li dirs into ~/.grass7/. or, find out with locate (first run updatedb as root) always useful :) Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] access to multispectral landsat data for the UK
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] - http://earthexplorer.usgs.gov/ Nikos: Count also glovis.usgs.org in. not specifically limited to landsat, but these are great resources too: nice MODIS etc. data portal: http://oceancolor.gsfc.nasa.gov EOLi: http://earth.esa.int/EOLi/EOLi.html (`eolisa` java app) VISAT/BEAM: http://www.brockmann-consult.de/cms/web/beam/ (`visat` is yet another java app) Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] image spatial syncronization
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 http://regima.dpi.inpe.br 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? Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.surf.nnbathy with GRASS 7?
Ivan: I use it in Grass 7. it works. Adam wrote: Is r.surf.nnbathy compatible with GRASS 7.0? Hamish: 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! Adam: Thanks. It is working. Hamish: 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 r.surf.nnbathy 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. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] new north arrow symbols
Hellos, six new north arrow symbols to try out: http://grasswiki.osgeo.org/wiki/IconSymbols#New 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 Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Use of v.in.ascii in python with stdin
So I tried without: ascii = cat,X,Y,Name 1,10:20:08E,53:25:27N,mypoint cols = 'cat int, x varchar(10), y varchar(10), name varchar(10)' grass.write_command(v.in.ascii, overwrite=True, format=point, #flags=n, input=-, cat=1, x=2, y=3, stdin=ascii, columns=cols, output=mypoint, separator=,) 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. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.surf.nnbathy with GRASS 7?
Adam wrote: Is r.surf.nnbathy 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. regards, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] image spatial syncronization
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 repository). link: http://grasswiki.osgeo.org/wiki/Stereoscopic_analysis#See_also Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] help with testing the location wizard for the upcoming release
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. thanks, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Directed vector networks (e.g. river networks)
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 direction. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] problem add-ons and python (windows7)
Hamish wrote: another potential problem I see is that the Makefile for both modules are calling Script.make instead of Python.make. Margherita: Should I change it or is it working anyway? I wasn't aware of this. 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. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass 6.4.3 MSYS interface within windows 8
Miltinho: 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/grass64svn.sh -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. regards, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Merge parallel roads
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 points? I wonder if you could do v.to.db 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 v.build.polylines both before and after. ? Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] R: Re: problem add-ons and python (windows7)
Hamish: And/or the set PATHENV in \etc\Init.bat is not working properly. (it knows about .py but doesn't know to associateit with GRASS's python.exe) Mattia wrote: Honestly I have not found the PATHENV in \etc\Init.bat. Is it a problem? it should be there on line 69. I'm not sure if it means much without assoc and ftype (see below). I tryed to know which one is the path that corresponds to python.exe but I wasn't able. The command try to open .py file always with pythom.exe from \extrabin. On a copy of GRASS 6.4.3svn nightly build from today or yesterday, running echo $GRASS_PYTHON from the Msys terminal, or echo %GRASS_PYTHON% from the C:\ dosbox window (both in the GRASS section of the Start Menu) should show it. wrt finding Matplotlib, the %PYTHONPATH% (or $PYTHONPATH) variable may be interesting to look at as well. (apparently we don't ship it [yet]) you might also try this tip from the python docs, add this to C:\Program Files\GRASS...\etc\env.bat: (http://docs.python.org/2/using/windows.html#executing-scripts) assoc .py=Python.File ftype Python.File=%GRASS_PYTHON% %1 %* outside of the GRASS environment would probably be an error since PYTHONPATH wasn't set system-wide. you might also try changing the GRASS_PYTHON and PYTHONPATH to your system installed Python.exe and support files, and so matplotlib too. (change them together, keep them in sync) Secondly, there is a .bat wrapper called %ADDONS%/scripts/r.basin.py.bat which should be in %ADDONS%, and be named r.basin.bat. I wasn't able to find where to set %ADDONS% too. I saw only % GRASS_ADDON_PATH%. So confused :) sorry, I was in a rush and abbreviated it. %GRASS_ADDON_PATH% is correct. In addition, I used g.extension to get add-ons. And with that command there aren't make files in any folder. Have I to re-download them manually? In case, where have I to put make files? that part of my comment was mostly meant for the developers. Since most Windows users don't have the full compiler and osgeo4w build environment set up on Windows we (ie Martin) provides pre-built versions. For python and shell scripts it isn't a big deal since there's noting to build, but copying everything into the right spot and getting the extensions working correctly can be a pain, as you've experienced. You might also try to replicate the setup of e.g. d.rast3d.py and .bat in C:\Program Files\GRASS...\etc\gui\scripts\, I tried that but no luck. I know we're very close on python scripts + GRASS 6.4 + Windows, it's a bit frustrating missing that last piece of the puzzle... after all the g.extension.py script you used to download starts runs ok... Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Merge parallel roads
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 (v.net.spanningtree) - TODO: extract longest line (no idea) this is an approach I have not considered. will take a little thinking about. but if v.net.spanningtree solves the worst part of the problem then I think the longest line should not be so hard to solve with one of the v.net tools. there is a bit in the archives, as well as a user donated v.centerline module, http://thread.gmane.org/gmane.comp.gis.grass.devel/36271/focus=36290 http://thread.gmane.org/gmane.comp.gis.grass.devel/36294 More on the difficulties of the river mile problem and ideas about it: http://thread.gmane.org/gmane.comp.gis.grass.user/22063/focus=22097 see also: http://article.gmane.org/gmane.comp.gis.grass.devel/11504 http://thread.gmane.org/gmane.comp.gis.grass.user/24385 http://thread.gmane.org/gmane.comp.gis.grass.user/42693/focus=42722 http://search.gmane.org/?query=river+milegroup=gmane.comp.gis.grass.user regards, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] problem add-ons and python (windows7)
Mattia wrote: I'm trying to solve my problem for a long time. I hope someone can help me. I'm not expert but I really want to istall 2 add-on on grass 6.4.3RC3 on my win7. The add-ons are r.basin and r.ipso. I think there are problem with the python.exe and the PATHS. When I launch from console r.ipso I receive this error: C:\Program Files (x86)\GRASS GIS 6.4.3RC3\extrabin\python.exe: can't open file 'r.ipso.py': [Errno 2] No such file or directory the trouble with those two scripts are that they are written in python, and GRASS 6 does not handle python addon scripts as well as it does compiled C modules and UNIX shell scripts. the bad news is as you experience they don't work out of the box right now on Windows. The good news is that it is fixable. By moving and renaming some of the files I could get them to run locally on Windows XP. -- it's a solvable problem. I just ran r.basin. gory technical details: the basic one is Python.Make in GRASS 6's include/Make dir is not currently set up to create the .bat file wrappers needed to launch the scripts there. And/or the set PATHENV in \etc\Init.bat is not working properly. (it knows about .py but doesn't know to associate it with GRASS's python.exe) Secondly, there is a .bat wrapper called %ADDONS%/scripts/r.basin.py.bat which should be in %ADDONS%, and be named r.basin.bat. It contains a single line, but that is wrong too, it should be set up for a python script but it is created for a UNIX shell script. It should read like: @%GRASS_PYTHON% %GRASS_ADDON_PATH%/r.basin %* then the %ADDONS%\r.basin.py renamed to just r.basin, and finally the batch file run as r.basin.bat. Then it works. The better solution is to fix the .py association with python.exe, but care is needed to pick the right one, and not hijack that setting for the entire computer, since other software might be using another version of python. I note that there are 2 python.exe. One in C:\Program Files (x86)\GRASS GIS 6.4.3RC3\extrabin\ and one in C:\Program Files (x86)\GRASS GIS 6.4.3 RC3\Pyton27\. I think that last one is the right and I think that probably there is an error with the PATH. It is possible? do you really have a python.exe in your ...\GRASS GIS 6.4.3 RC3\Python27\ directory? For me it is only in ...\extrabin\ and in Python27\ there is only support files. As of last night's nightly build, 6.4.3svn explicitly expects to find its python.exe in the \extrabin\ dir. Can anyone drive me to the solution? I would need to know where setting the different path beacuse I'm noob! I also see that there is a folder in C: User\AppData\Roaming\GRASS6\addons... It is normal that the add-ons are istalled ther instead of in GRASS GIS 6.4.3RC3 directory? Yes, because the User can always write to their own AddData directly, but on a multi-user or managed (corporate) system the user may not have permission to change or add files to C:\Program Files. There is a %GRASS_ADDON_PATH% variable set which says where your personal scripts are stored. (can be set to multiple paths) When I launch r.basin I have an error that say aren't import sys, os and matplotlib. Even though I have istall matplotlib for Python27. I don't get that error, just the one from g.parser that it can't get the interface description (since it can't find the script). I'm surprised that sys and os can't be found, that indicates that your %PYTHONPATH% is broken since those two should always be built in. As for matplotlib I'm not sure if GRASS ships that, it might not so need to be installed manually. (however you do that on Windows) again, python + grass6 + MS Windows is a work in progress :) fortunately only a few of the addons for grass6 are written in python, so it's not a very widespread problem, but is certainly a pretty basic need and something we want to support for the future. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
