Re: [GRASS-dev] An applicant for GSoC 2024
Welcome Chung-Yuan, Huidae wrote: > Please check this feature request at > https://github.com/OSGeo/grass/issues/2644 > for testing your skills and let me know if you have any questions. For whatever it is worth, it always struck me that v.surf.bspline was low hanging fruit for OpenMP parallelization, as the code already splits the data up into a manageable number of overlapping tiles/segments, then processes them serially before recombining them. See https://github.com/OSGeo/grass/blob/main/vector/v.surf.bspline/main.c#L529 and further comment on line 607 and debug message on line 475. all the best from deep in the South Pacific, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Access to mapset environment variable
Sören wrote: I am struggling to access GRASS mapset specific environmental variables from mapsets different than the current one in C. ... Is there a possibility to access mapset specific environmental variables in C from a different mapset as the current one? Hi, I would suggest to use the mapsets' VAR file, not gisrc (g.gisenv), to store per-mapset variables like that. Since gisrc is per-session and ephemeral, not per-mapset and remembered after the session is closed. hope it helps, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Tabs and spaces in C code
Vaclav wrote: What do you think? IMO it's just fine how it is now. I'm quite fond of it with 4 columns per indentation level and 8 spaces as a tab actually. I would ask to please not mess with it. I find all spaces for a 8-column tab in C to be quite wasteful in both disk space and scrolling time, and thus ugly, not to mention pointless -- Python cares about whitespace, C does not. Do not apply Python conventions to C code, and do not ask people to make adjustments to their text editor. Please let's focus our energies on the many open bugs in the trac'er instead of fixing things which are not broken. e.g. WinGrass needs all the time we can give to it to solve the last 2% of its problems. regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] status of grass6.4.4 debian packaging ?
Moritz wrote: Hamish and Frankie, What is the current status of packaging 6.4.4 for debian ? Hi, sorry for the delay, I've been largely out of the office for the last couple of weeks. Mainly notes to Frankie, but may as well cc everyone to keep y'all in the loop: As far as updates needed to the packaging files it's just dch to bump the version number, and as far as I can tell the barscale_ui and svn-any-version patches have been incorporated and are no longer needed. I've been building test packages since before release and AFAICT all seems well. We might need to keep an eye on the grass64.desktop file to make sure it gets included, but I think that's perhaps ok since the debian package does is not using 'make install'. The unpacked tarball lives in DebianGIS's git repo, http://anonscm.debian.org/cgit/pkg-grass/grass.git/ (with the notable addition of a debian/ dir) generally for this I think it is better for one person to drive the car at a time, so I let Frankie do the tarball swap-out part and then do any of my extra edits to the debain/ dir once the foundation is in solidly place. Others are threatening to commit over the top of our work on alioth right now and I'd rather pull in their patches than have to revert them, so we should perhaps get onto this soon... :-) @Frankie, a dependency on libgdal-dev (= 1.10.0-0~) snuck into the control file recently, can we just remove the versioning? AFAIK it's not actually needed and it makes backports to wheezy and the ubuntu LTSs that much more of a pain. Also if there isn't a hard API reason for needing the new version, explicitly stating it there can be deceptive since it indicates that there is. (even friendlier for backports: libgdal-dev | libgdal1-dev,) Anything we can do to help ? The highly time critical thing right now is to get the new package in ubuntugis's unstable repo in the next few days so the osgeo live dvd can ship the right version for the Portland OR FOSS4G conference. We need to send the final to the printers soon. If it comes down to it, I can manually override with my self-built packages but I worry that the qgis 2.4 grass-plugin package would then need to be rebuilt too. So it's better to do it in the common ubuntugis PPA where those things will automatically resolve themselves. In general I feel it better to let the changes flow downstream from debian/unstable instead of letting things get the order of progression get mixed up downstream and all the splintering confusion and lost edits that go along with that, but the timing might necessitate an exception to that.. Seb has a package, to avoid stepping on toes I think that might be the first upload to ubuntugis's PPA. thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS GIS 6.4.4 r.li modules
Hamish wrote: yes, the old r.li.* daemon/worker system required unix sockets, and so would only work in the cygwin build. We never figured out how to properly support those natively on MS Windows. Martin: r.li modules enabled in grass64 in r61153. Please test next build of grass64-dev (no.13). Thanks. I am unable to test for the next weeks, but would appreciate if someone else could try it. regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS GIS 6.4.4 r.li modules
Martin wrote: r.li modules are not simply built on Windows [1]. Any idea why? Martin [1] http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/raster/Makefile#L132 yes, the old r.li.* daemon/worker system required unix sockets, and so would only work in the cygwin build. We never figured out how to properly support those natively on MS Windows. I believe in the new backported version of r.li those things are all removed now so it could have the conditional removed from the Makefile and the modules tested in a nightly WinGrass build. If it works I'd suggest a setup_6.4.4-2.exe release be prepared with an altered Makefile. The source code isn't touched so it wouldn't introduce any platform dependent behavior which would need a new point release, instead it would only reduce platform differences. Luca: I would thought that author of r.li.* updates checked also availability on Windows. that's all of us; especially big jobs need many testers to check all angles. 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-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-PSC] GRASS6.4.4 release [was: Re: GRASS 7 release planning]
Hi, To be honest I think we will have to accept shipping OSGEOLive with 6.4.4... The focus there is a split between being a showcase for new features and super-stable introduction for new users. (power users might see past small transient bugs, but if a new user finds rough edges in the first 5-15 minutes, or before they get past the initial learning curve, the window of opportunity is lost and they'll give up) So far the balance on the disc has been to more favour stable over new. Feature freeze is in just a couple weeks, QGIS plugin would need to be 100% ready and rebuilt, and we'd not have a sample dataset included, would need to have a GRASS_BATCH_FILE import script to set one up from the data already on the disc. fyi I plan to write a script which will be on the disc which will automatically add the appropriate ppa repos and download+install the latest grass7 snapshot and sample data. What version does the foss4g workshop want to use? Note the NC dataset only ships in geotiff+shapefile form so it can be used by all the other projects too, due to disc space limitations the workshop setup will have to download that too. (spearfish is small enough to include for G6 though) There is a link on the live disc desktop to this URL: http://trac.osgeo.org/osgeo/wiki/Live_GIS_Workshop_Install fwiw I will also be writing a G6 script for pre-installing some G6 addon modules. If you have any you want included, place your orders in a osgeo trac ticket please (LiveDVD component), cc 'hamish'. Right, as far as I know Markus is off-line since 27/6. So let's start with idea to mark RC2 as a final and release it _this_week_! I don't know about any blockers. Any opinion? If you know about blockers let us know about that ASAP! I have been very busy with work recently, and will be for the next weeks too. In the past I've been able to review all commits to the stable branch, right now I am rather behind in that task. So if it goes out now just be warned that I might be asking for a small-change 6.4.5 release after a month as some sort of 6.4.4.1, since there are always some bugs to find. :-) I would also be a bit slow on the Debian packaging this time and not sure if I could write the release announcement. Work and GSoC has all my time right now, sorry. fwiw the debian rule for packages being accepted into the stable branch is not that they are perfect, only that they are less buggy than the old version. For the spatialite export bug I think that's fair advice to follow: it is not fixed, but no more broken than the previous release. Since v.out.ogr is such a critical module, and the fix requires the module to be improved with a bunch of 2D vs 3D export logic, my vote would be to release 6.4.4 without it, but then try hard soon after release to get it fixed, so maximum pre-release testing time. -- Even though it's pretty crazy/embarrassing that GRASS isn't supporting export to Spatialite currently. My thoughts on r.li are very similar, chances are that the big backport still has some maturing to do, but the earlier version was wrong so perhaps-problems-but-improving beats known-bad. best regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] MBTiles format export tool (halfway)
Hi, If it is useful to anyone I've just written an addon module which will let you export a grass raster map as a TMS tileset and uDig mapurl file ready to be copied into Geopaparazzi, which will then convert it to the MBTiles sqlite web tile database format. MBTiles is used for Tilemill and other web tile softwares to avoid 2^n number of tiny tiles clogging up your filesystem, handle deduplication, and other nice things. GDAL support (read-only) since 1.10. Relying on Geopaparazzi on Android to do the final conversion then copying back the results is a bit awkward/slow, so I'd enjoy to see the addon module create the MBTiles sqlite db directly. It looks pretty straight forward, but sadly my SQL foo is lacking. ( https://github.com/mapbox/mbtiles-spec/blob/master/1.2/spec.md ) once that is working the idea is to buy the co-author a beer and rename the module to r.out.mbtiles. The tile tree output would be preserved as an optional output since you can copy it to an apache dir and use with OpenLayers or do other post-processing directly. notes, screentshot, and code: http://grasswiki.osgeo.org/wiki/Android#Device_used_as_a_recording_slate_in_the_field http://grasswiki.osgeo.org/wiki/AddOns/GRASS_6#r.out.mbtiles_prep http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.out.mbtiles_prep After some initial tests right now I am chugging through a 5x5 GDAL .vrt virtual mosaic of a directory of geo-ref'd JPEG orthophotos, connected into a virtual raster layer with the r.external module. 180k+ tiles take a long time!, but I think it will (just) make it under the spatialite 2GB filesize limit on Android by the time it's done. (yay gdalbuildvrt + r.external + r.reclass) I'm not sure if I got all the uDig mapurl request_type= settings correct, I went for a throw everything at it and see what sticks approach. Other room-for-improvement areas are r,g,b band parallelizing in r.out.gdal (even if only 3x speedup it would be a good win and have very low throughput overheads), and also the parallelization patch for gdal2tiles currently in gdal trac. The tile tree scanning to remove unused metadata .aux.xml converting png - jpeg would probably be much faster in a python script, since unlink() and PIL could be used instead of all the expense of creating and destroying a zillion rm and NetPBM processes for all the tiles.. many CPUs don't help if you've already saturated the kernel %sys. It's one day old and lightly tested; feedback is welcome. regards, -- Hamish hamish.webm...@gmail.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] MBTiles format export tool (halfway)
Hamish wrote: If it is useful to anyone I've just written an addon module which will let you export a grass raster map as a TMS tileset and uDig mapurl file ready to be copied into Geopaparazzi, which will then convert it to the MBTiles sqlite web tile database format. MBTiles is used for Tilemill and other web tile softwares to avoid 2^n number of tiny tiles clogging up your filesystem, handle deduplication, and other nice things. GDAL support (read-only) since 1.10. Relying on Geopaparazzi on Android to do the final conversion then copying back the results is a bit awkward/slow, so I'd enjoy to see the addon module create the MBTiles sqlite db directly. It looks pretty straight forward, but sadly my SQL foo is lacking. ( https://github.com/mapbox/mbtiles-spec/blob/master/1.2/spec.md ) [correction 1.2 is unreleased, use spec v1.1] once that is working the idea is to buy the co-author a beer and rename the module to r.out.mbtiles. ok, I was able to add a flag to (experimentally) export MBTiles databases directly as long as sqlite3 is installed. Both gdalinfo 1.10 and qgis2 seem to be happy with it. It could still use improvement by replacing the image blobs with an index number view and having another table for storing the unique images. That way all ocean/wasteland tiles only need to be stored once in the database and the file can be quite a bit smaller. For well-cropped aerial imagery and satellite data I guess we wouldn't have much repeated data, but for categorical CELL maps it could help things a lot. If anyone wants to help with the fancy SQL views and ID lookup table I can provide as an example a sqlite db of the North Carolina soilsID raster converted by Geopaparazzi's TMS import background job. I'm afraid that much really is beyond my SQL. regards, -- Hamish hamish.webm...@gmail.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] #2031: G_legal_filename() cleanup patch for GRASS 6
Mortiz wrote: How about my proposal from a few weeks ago: Nobody commits to grass64release, only to grass6dev, and Hamish is the official maintainer of grass64release and decides what can be backported ? This obviously can only work if Hamish has the time, so that 6.4.4 is not stalled for lack of manpower. Well, I don't like being the sole gatekeeper, both for community and logistical reasons. I am happy and pleased for everyone to backport, as long as we can all be working from the same ideas about where we are in a freeze and what our expectations for it are. Which is primarily (and luckily) a solvable communication problem, and not a structural, technical, or personality one. Having said that, if people find backporting to 6 is too much of a pain, simply leave a ticket open with the next release as the target version and a request to backport and I'll try to take of it for them, in $unknown time. Through bitter experience and brown bags I'm now really strict with myself about committing anything, no matter how innocent looking, to the release branch. What has been driving me nuts is spending all these hours carefully testing and trying to spend a lot of energy on attention to detail, and to then observe other developers just come through with a bulldozer and commit stuff haphazard all over the garden I'd just spent so many hours cleaning up. If all that time ends up in a hole, why bother? I note a revert needed in devbr6 where a number of features-in-testing (64 bit support, stat() checks in libgis, ...) recently got blown away by a mass backwards-sync with relbr64. I can't tell you how demotivating it is to have all those hours of work ignored and removed. Now I have to spend even more hours putting them back by hand, because I doubt any one else would care enough about devbr6 to fix it. This is not fun, and if it is not fun I have to remind myself what I'm doing here. So in the last weeks instead of working or even thinking about that stuff I have concentrated on what I really do enjoy, the creative outlet aspect of coding. Having to be the guy who says no all the time really eats into my enjoyment of working in a team, I hate it, it's not a healthy way to be. For sure I play it a bit too conservatively some times, and unadvertised devil's advocate others, and it is noted that this slows down releases, which frustrates and drops motivation in others too. But I'm ok with not having to be right all the time about where the right balance is since I can relax knowing everyone is doing what they consider to be best and positive, and they are really smart and often right about it. And it is frustrating to me too for the releases to take so long, especially since I know some of it is me saying no but not having the extra time to do the review and edits to help solve the issues, many of which are of my own making. It's a classic question I don't have an answer to: we can use the time just before a release as a huge community motivator to get all the last minute bugs fixed and all the last minute things people wanted to see in before the next release. But at the same time it's the absolute worst time to make changes which can't have time for testing. So how to harness all that energy without breaking anything by accident? My personal strategy has been to divert non-critical things in to release+1, then soon after release go through the devbr and backport it all. Yes it slips a release which may be many months apart, but I treat it like AGU meetings: you can't be everywhere and do everything at once, so it's ok, do what you can and enjoy it guilt free. Then there are things like the parallelized shell scripts in devbr6 which are wonderful and seem to be working fine, but I've not backported them because I don't know the answer to allow SIGINT to also kill the subprocesses. From the command line with `top` and maybe gkrellm running as a cpu/process monitor it's pretty obvious they are still going. But from my testing of the msys/bash background a series of jobs + `wait` strategy with the wxGUI on MS Windows (it works!) that if you forget to change the computational region away from 1 meter, as is easy to do there, the r.univar job is going to take hours. So after a while on 1% done you press the stop button in the module's gui window but the children keep going in the background. Probably most Windows users wouldn't notice that, only that the machine got slow. So I don't have an answer to that problem and thus the new code remains waiting in devbr6. (I'd note parallelized python scripts in grass7, which by structural necessity of python only support multi-processes not multi-thread, have the same exact problem..) Martin: from my personal experience I would say that than we will probably never release any new GRASS 6 version. ;-) fwiw I felt that going into the recent code sprint we were ready for 6.4.4rc1, r.li was the last thing to solve. And now we're not. If we're ever going to get
Re: [GRASS-dev] r.in.lidar tuning
[ wish for r.in.lidar: ] ... filter Only import points of selected return type If not specified, all points are imported options: first,last,mid which would be great for r.in.lidar as well to avoid that I need to split the file with las2las beforehand. Markus Neteler wrote: I have implemented that now in http://trac.osgeo.org/grass/changeset/60247/grass/trunk/raster/r.in.lidar (hope I got it right over from v.in.lidar) Hi, you might look at the vrange= Filter range for alternate value column data (min,max) was implemented for r.in.xyz, I humbly think the approach there is pretty clean and useful. Besides filtering co-variant outliers, the use case there was to filter by z-range when building 3D slices as part of a raster3D import, when the import data value for the raster is not the z column; see the r3.in.xyz.py module for an example of how it is used. (unrelated, but I'd also note that the parallelization method for z-level slice import in r3.in.xyz works out to be surprisingly efficient) regards -- Hamish hamish.webm...@gmail.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60304 - grass/trunk/raster/r.colors
Huidae Cho wrote: I didn't do much backporting till now. I think it's time to read that wiki page. Thanks! Hi, handy tip: In svn/grass-addons/tools/ there are some backporting scripts, the relevant one here is svn7merge. to backport from trunk cd to the top relbr70 dir and after svn up type svn7merge REVNUM where revnum is the number of the commit to trunk you want to backport. then svn diff commit. all very quick. occasionally you have to do svn propdel svn:mergeinfo . to get rid of some unwanted tags, but as long as you don't do a 'svn commit' from the top of the source tree it's harmless. regards -- Hamish hamish.webm...@gmail.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GUI code dest dir
Vaclav: currently wxGUI code is placed by building system in `etc` directory. I would say that more appropriate would be to put `gui` directory into root, so at the same level as `bin` or `scripts`. Simirarly python libs are placed also in `etc` directory. They should probably go to `lib\python` instead of `etc\python`. probably not $GISBASE/lib/python/, as lib/ is for libgis et al. on UNIX systems. $GISBASE/python/grass/, or however python likes it, would be more appropriate. Martin: in the source code and it will work. Maybe separate directory for python libs in src root would enable this option? mmph, I think the basic src layout is ok, and $SRC/lib/python/ is where it is logically expected to be in the source. Note that for C/C++ code we have a similar issue. In the source code, includes are in `include` but in distribution they are in `include/grass` so you have to do #include grass/raster.h that's exactly how it should be, no? but if you are editing source code in some clever editor and you want to jump from the .c file to the header, you cannot since there is no `grass` directory in src. This applies also for code completion etc. maybe the editor program isn't as clever as it could be ;) 10 minutes of setup only has to be done once, and could be documented in the wiki. Another reason for having src and dist code with the same layout in case of Python is the documentation. The Doxygen is currently quite messy: http://grass.osgeo.org/programming7/namespaces.html contains grass, python, all GUI packages/namespaces individually and few others http://grass.osgeo.org/programming7/namespacegrass.html contains script and temporal but they are different from those in python http://grass.osgeo.org/programming7/namespacepython.html contains what is in src/lib/python I'm sure there will be a programmatic way around that. fyi, from the DebianGIS packaging TODO: = * The grass 'etc' directory contains a mixed arch/non-arch depending mess of files. They should be automatically classified in the install target and moved to /var/lib/grass or /usr/lib/grass, leaving symlinks so to not break things. = that is, Debian ships on 11 different hardware platforms or so, so platform independent files are split off into platform=all packages and shared between all platforms. since $GISBASE/etc/ is a mix of binaries and scripts it takes a lot of close work to make sure everything gets to where it needs to be for debian's particular rules (/var/lib/grass or /usr/lib/grass). this is a lot cleaner in trunk already. mv $GISBASE/etc/gui $GISBASE/ mv $GISBASE/etc/python $GISBASE/ seems ok to me. (although to be honest I don't really care) I notice $GISBASE/share/applications/grass.desktop, which seems silly. Just put it in gui/icons/ with the rest and let the packaging scripts move it to where it needs to be. regards, Hamish -- 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-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Handling of Python scripts on MS Windows
Markus Metz wrote: ESRI assumes that their system-wide Python installation will never change. That is rather ignorant. I don't think GRASS should mimik the aggnorant ignorance of ESRI. I think that's more a reflection on the way things are done in the MS Windows world: the last program to install itself wins. Which leads to the usual 1st trouble shooting step on Windows after seeing if a rebooting helps: try uninstalling then reinstalling the program. Then the program you are trying to use becomes the last thing to be installed and magically wins again (but by breaking the previously installed conflicting software). Of course with Linux rpm/deb package managed system uninstalling and reinstalling typically does not change anything, you usually would have more luck renaming away ~/.foorc/ and starting fresh that way. Hamish ps- wrt fubared email header handling explained in the links below, I notice gmail is now complaining about gmail addresses resent from Mailman too. (your post MarkusM showed up with a !spoof warning in gmail) See the last link for Mailman config workaround (they just put out a new band-aid release). -- 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-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] 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-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 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-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS website temporarily down
Hamish wrote: 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. what seems to have happened is the grass_addons.sh cron job that compiles the addons (or extracts strings for translating?) got stuck in a loop building the help page for /home/martinl/src/grass-addons/grass6/raster/r.rdfilter/r.rdfilter.py. r.rdfilter.py.tmp.html was inserting its own description.html over and over in a recursive loop until it filled the disk. I think I remember seeing a similar .tmp.html loop more than a year ago for some other module, probably not a Grass6 python addon, but I can't recall the exact circumstance other than it happened on my local system. I'm not sure why it happened this time, but we should either figure out what caused it or switch off the cron job before it happens all over again, probably tomorrow night. I manually killed the job that got stuck. Does it really have to run every 15 minutes? Ideally, future builds could be run on a dedicated build server away from anything important. I think there's already wide acknowledgment of the need for that in OSGeo SAC. Note there is also currently the adhoc VM for things that may be risky or low priority, but be kind to the disk i/o as that is shared among all the other VMs on the same host. regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Handling of Python scripts on MS Windows
Glynn: Batch files are a better solution, as they don't affect anything else, and it's a simple matter to either delete them or modify PATH to ignore them, and use the Python scripts directly. MMetz: Sounds good. Martin: I am not sure, what about user scripts? a new g.batwrap helper program (written in C) to create a .bat wrapper and put it in the same dir as the target python script? It's easier to check if the file is a python script and if so than to force to use bundled version of Python. This seems to be a better workarround than using bat files. what would do the checking, g.parser.exe? remember that any solution also needs to work 100% from the command line too, so having the GUI's pseudo-command line taking care of those things is not a real solution. Even if a user never uses the command line on Windows, they will at some point run into the old script-called-from-another-script problem. ? regards, Hamish ps- this part of g.extension.py is fundamentally broken: line = line.replace(%GISBASE%, %GRASS_ADDON_PATH%) # options['prefix']) It's equivalent to trying to do s+/usr/bin/+$PATH/+ and then run $PATH/g.module. The approach used in g.extension.sh is to split $GRASS_ADDON_PATH and use the first dir in the list as $GRASS_ADDON_PATH1, and then use that dir as the first-choice userland exedir destination. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 7: v.to.rast -d produces empty raster when used on areas
Stefan wrote: Converting areas from vector to raster with the -d flag (dense lines) in GRASS 7 results in an empty raster map. Both on Windows and Linux. Is that because boundaries are not lines or would you consider it as a bug? I think you are right, it is probably because boundaries are not lines. Or more specifically, in an area the centroid holds the category and attribute data, and the boundary is (typically) without category. (If a boundary is between two parcels of land, which farmer does the boundary belong to?) So if you wish to work on boundaries you have to v.extract them, then add categories with v.category. If you do that typically you'd want to run v.type as well to turn them into lines. It's probably worth a ticket in the trac system since in future others will try the same with type=area, just note that the thick raster line should probably be category 0 or so, not the adjoining area's cat number for the who does it belong to? reason above. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] GSoC mentor sign-up
Hi, as GSoC 2014 applications draw to a close, just a reminder for anyone wishing to mentor to please sign up in melange ASAP. We already have a number of interesting ideas to review. thanks regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSoC 2014: GRAS GIS Web UI
Massimo wrote: Is my understanding that the grass parsing code has to be “less restrictive” for the desktop app while the sanitizer has to be implemented on the web-ui side. the locally run grass session doesn't have to be more generous in what it can accept, it's just that the local user is trusted already, and so we can get away with not having to harden every possible input. Sure we should clean those up, but there are thousands of them to fix and avoiding giving shell access to users who already have it makes the job more a matter of helping them to avoid crashes than protecting themselves from their own user account. but, even if(/when :) we did think the code was safe from buffer overflows and injection attacks, the web ui should still sanitize inputs as an extra layer of protection, since no software can be trusted to be perfect. ? Is this not true: Any public http ipython notebook should be running in an isolated per-session chroot jail, much like many ftp servers do, and the ipython server's port should be firewalled off from accepting connections from anything other than localhost. And even in a chroot jail a few big loops could use up all the given RAM or disk space by mistake or on purpose. -- As a general thing- GSoC students are by definition still students, and I'm sure that most of us could stand to improve our coding habits too, and would welcome the opportunity. It is the mentors' role to review and teach as much as it is the student's summer job to produce code. The side goal of GSoC is to have a formal avenue to train and grow the future dev team. The more the student knows coming in the better, but we shouldn't expect them to always be experienced vetrans. Somewhere in the middle is a nice balance point. :) regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Fwd: Android Compilation
Vaclav wrote: But this is probably not important because there is no way to wxPython on Andriod. At least quick google search said so. So, perhaps GUI is the biggest challange for Android (which could be to certain extent solved by QGIS for Android bundled with GRASS for Android). one question I have a hard time answering is when I'd actually want to use GRASS from an android device? Chromebook makes a bit more sense since it is a bit more like a workstation experience. The main use-case I could think of was for data entry, or to aid with data accounting in an archeology grid. http://grasswiki.osgeo.org/wiki/Android#Device_used_as_a_recording_slate_in_the_field But if the UI must be written from scratch, what do we offer (as a processing and analysis engine) that gvSIG-mobile, QGIS-android, and OSM walking papers apps (as data entry, viewing, and nav apps) don't already do? The other use I can think of is if the ipython-notebook or whatever web UI to GRASS could launch jobs remotely on a server, like a light (or not so light) grid-engine or maui/torque cluster job submission queue. fwiw my lightweight web-grass solution has always been to ssh/putty in to the server into a GNU Screen session, then have GRASS_PNGFILE=/var/www/map.png, then just hit refresh in the web browser. works great for command line grass junkies. some ideas to think about where the end goal is and how/why that way would be useful for end users. regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Character encoding of module i.atcorr files
Maris wrote: The offending line is a reference in the comment section: http://trac.osgeo.org/grass/browser/grass/trunk/imagery/i.atcorr/computations.cpp#L1365 I browsed SUBMITTING file and didn't find any rules about source encoding. ... Glynn wrote Most files are ASCII. Those which aren't are almost evenly split between ISO-8859-1 and UTF-8: Files using ISO-8859-1: raster/r.sunmask/g_solposition.c U+00B0 DEGREE SIGN imagery/i.topo.corr/main.c U+00F1 LATIN SMALL LETTER N WITH TILDE imagery/i.landsat.toar/landsat.h U+00B5 MICRO SIGN imagery/i.evapo.pm/functions.c U+00B0 DEGREE SIGN imagery/i.atcorr/computations.cpp U+00E9 LATIN SMALL LETTER E WITH ACUTE lib/raster/color_look.c U+00AD SOFT HYPHEN lib/raster/color_set.c U+00AD SOFT HYPHEN Files using UTF-8: raster/r.sunmask/main.c U+00B0 DEGREE SIGN raster/r.watershed/ram/do_flatarea.c U+2013 EN DASH vector/v.net.salesman/main.c U+2013 EN DASH gui/wxpython/lmgr/frame.py U+00F6 LATIN SMALL LETTER O WITH DIAERESIS U+2019 RIGHT SINGLE QUOTATION MARK lib/python/pygrass/functions.py U+00B0 DEGREE SIGN lib/arraystats/class.c U+00E9 LATIN SMALL LETTER E WITH ACUTE Many of these are either gratuitous, e.g. use of soft hyphen or en-dash when an ASCII - (U+002D HYPHEN-MINUS) would suffice. Some are due to comments written in languages other than English (i.topo.corr = Spanish, lib/arraystats = French); these should be translated. All but one are in comments: the pygrass one is a string literal, which should really use escape notation (assuming that the is_clean_name() function is actually correct, and not a half-baked attempt at re-implementing G_legal_filename()). So, if those are fixed, it boils down to whether we actually want to have to deal with source-code encoding issue for the sake of comments which include: a) °C for degrees Celcius, b) µm for micrometres (microns), and c) proper names using the Latin script with accents (names using any other script will invariably be romanised). I've now removed most of these in trunk with r59172. remaining: imagery/i.atcorr/computations.cpp (someone's name) gui/wxpython/lmgr/frame.py (an example of something using UTF-8) and lib/python/pygrass/functions.py ... as for functions.py, hooking into G_legal_filename() would be best, but failing that, a white-list of allowed chars would seem much more robust than a small black-list of disallowed chars. Personally, I would prefer it if source code was 7-bit clean. Me too. Not sure how to deal with non-ASCII chars in people's names though. regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSoC ideas - vector legend, medial axis
Hi, (thanks for the great ideas pages everyone: osgeo gsoc 2014 is accepted and happening!) integrating an existing open source metadata library instead of starting from scratch would be faster and easier to maintain in the long run. :) e.g. try to cooperate with the GeoNetwork and pycsw teams. is qgis doing anything wrt metadata that we could share development with? Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSoC ideas - vector legend, medial axis
Hamish wrote: e.g. try to cooperate with the GeoNetwork and pycsw teams. is qgis doing anything wrt metadata that we could share development with? see also deegree, qgis MetaSearch plugin, and the OSWLib library. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Trac custom fields: Platform
Maris wrote: I would like to propose to merge all MS Windows platforms into one. I agree it has always been awkward, but can the trac DB handle the merge without losing information or making us have to reassign all tickets to the new joint platform by hand? is there any reason to do a search for e.g. XP but not Windows 8? (native wingrass is all XP+ so none that I know of) regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.profile limits in Windows 7
Hamish wrote: what we should do is explicitly look for profile=- for reading from stdin, to make it more clear that it exists. another more GUI friendly way is to add a new option for an input file, which would be mutually exclusive with the profile=[east,north[,east,north,...] method of using the module. Vaclav: I agree with more GUI friendly way. Actually it was the only way, since profile= expects comma separated pairs, and the parser (if it was working!) refuses to accept just one - for the option. So now in trunk r59033 profile= only accepts sets of coord pairs, and for stdin you have to use coordinate_file=-. Once done in r.profile, this functionality will be instantly available for MS Windows users (using only GUI). fwiw both stdin and command line are just as available and work in the same way on MS Windows as in Mac and UNIX. That the MS Windows users are not currently getting a command line dos box from the default desktop icon is debatably a mis-feature (there's a long discussion in a trac ticket about that). Note that currently when you forget to fill `profile` in GUI and press Run, you will get strange behavior. Now it should be better, you have to leave profile= blank and also add - to the coordinate_file= option. Still possible to get stuck waiting for stdin to close, but much less probable. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.profile interface changes
Vaclav wrote: Hamish and I did some changes in r.profile. X monitors-related parts of documentation removed, standard options introduced and most notably, Hamish added `coordinate_file` option to enable file input and make clear end checkable when standard input is used. I'm just unsure about names `coordinate_file` and `profile`. Predefined name for G_OPT_M_COORDS standard option is `coordinates`, so it will be good if `profile` would be renamed to `coordinates`. It would also improve r.profile call syntax from my point of view: - r.profile input=... profile= +r.profile input=... coordinates= Moreover, profile is the output of r.profile, not the input. So, do you agree with rename of `profile` to `coordinates`? sure, done in svn. I'm not sure about `coordinate_file` versus `coordinates_file`. What is more correct English here? I renamed it to file=. If you are using the command line having both coordinates= and coordinate(s)_file= means you have to type the whole word, which is really annoying. (yes, there's the c_f= trick, but it's not widely known. Note that Grass7/NewFeatures page was not updated yet. todo. And what about d.where and d.profile linked in r.profile manual? What they were doing at X monitors? Both now removed from the G7 help page. d.where lets you click on the map canvas and it prints the coord as text on the terminal. From there you could redirect them to a file or as in the commented out example in the r.profile help page, pipe it directly into r.profile for a do-it-yourself interactive input profile tool. d.profile is an interactive tool similar to the wxGUI profile tool, and is replaced by it. Note that there is currently no way to run wxGUI profile tool from command line. See also r.transect by the way, which is an alternate front-end to r.profile. regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.profile limits in Windows 7
Hamish: note WinGRASS binaries are still 32 bit, Helmut wrote: actually there is OSGeo4W-64bit ready for testing (http://trac.osgeo.org/osgeo4w/): (1) Download the 32bit or 64bit OSGeo4W network installer (previous 32bit only installer) winGRASS6.4.3.-64bit is included. great news! Has anyone tested with big data? Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Fwd: [OSGeo-Discuss] OSGeo Google Summer of Code 2014 - ideas needed!
Hi all, Thanks for making the GRASS GSoC ideas page come to life. :) It bodes well. Further tips about what is being looked for in the ideas pages: http://en.flossmanuals.net/GSoCMentoring/making-your-ideas-page/ Remember that Google will assess our application in large part on the ideas page(s), and that review will happen early next week. thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.profile limits in Windows 7
Enrico wrote: due to strange misbehaviours, we are doing some stress tests on r.profile under Grass 6.4 and Windows 7 Case A (less interesting, IMHO): r.profile fails with ERROR: G_malloc when the number of pixel queried is more than 1E6 our test: profile lenght: 300km, res=3 OK, res=2 failure ( example a river analysis on a lidar-derived DTM) can you provide the current region settings (g.region -p) and the exact command line parameters used? r.profile counts n as integer, but that should survive well past 1 million. ? note WinGRASS binaries are still 32 bit, and I see some float rows,cols work around in the r.profile code's do_profile() function. it would be good to also test in 64 bit linux on a machine with the same amount of RAM. As Maris noted, please open a bug report for this. Case B (more interesting): r.profile fails when profile input is a string larger than 8100 characters (more or less) I suppose the problem comes from a limit of cmd.exe (8191 characters) see [0] Please, consider that using UTM integer coordinates that means only 300 nodes, and this is not so unusual for profile analysis. Probably, using optionally a text file as profile input could solve the problem without refactoring the module... ... [0] http://support.microsoft.com/kb/830473 r.profile can read from the standard input stream if you leave off the profile coordinates option. so: GRASS r.profile in=elevation.dem output=- query_coords.txt will get you past the command line length limit (and is easier to work with too). what we should do is explicitly look for profile=- for reading from stdin, to make it more clear that it exists. another more GUI friendly way is to add a new option for an input file, which would be mutually exclusive with the profile=[east,north[,east,north,...] method of using the module. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] d.out.file
Anna wrote: I just added the support of exporting image from wxGUI and d.mon through command line. It does not support the advanced options of d.out.file in GRASS 64 (mainly because of different rendering mechanism). Testing (especially in d.mon) is welcome. Hi Anna, one very useful advanced option of the GRASS 6 d.out.file is the output format geotiff, that way you can compose a scene and export it, then reimport it as a georeferenced RGB image. Do we still have a way of doing that? The quadruple size is problematic for making poster sized output since the grid, barscale, vector line overlays are still exported as 1 px wide, which shrinks to 1/4 the size when you try and export as high quality. The cairo and vector-based output drivers may help, but the main solution I have for that is to encourage people to use ps.map for when they want hi-res hardcopy outputs. thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Change/update Python requirements for grass70?
Hi, Pietro wrote: So are you agree to change the requirements for grass70 from Python = 2.4 to Python = 2.7 or Python = 2.6? to add another me too for keeping support for python 2.6, Debian/Squeeze: Python 2.6.6 Ubuntu 10.04 LTS: Python 2.6.5 both still supported for a little while yet.. thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSoc Project on GRASS
Naveen wrote: I am a M.S. by research student from Lab for Spatial Informatics, International Institute of Information and Technology, Hyderabad, India. Last year I had proposed idea on GRASS magic extension for the IPython Notebook in GSOC-2013. But unfortunately the idea didn't get selected. Would it be a good idea to propose the same project this year also? Hi Naveen, Probably reusing the exact same proposal as last year may not improve results, but an enhanced and rewritten proposal could be interesting to look at. Also remember that Google lets you submit multiple proposals (maybe up to about 5(?)) so if you really wanted to work on the iPython extension, but are not sure if it matches the dev team's current needs and priorities, you could always make multiple proposals. I'd be careful not to put too many applications in though, often it is better to invest the time in a couple high-quality proposals instead of putting in a whole bunch of applications which aren't as well developed. Massimo (epi) is our iPython Notebook expert, it would be good to discuss any ideas with him. regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] m.nviz.image - Bad server connection
epi wrote: i'm tring to generate a 3d image with m.nviz.image, the following command works fine form a 'standard' GRASS session in text mode on my laptop but if try to run the same command on a sever while i'm connected via SSH i got the error : Bad server connection MarkusN: Many grass power users work like this, so that's well tested in general. I was doing it with m.nviz.image last weekend actually. Note wrt running remotely on a server, m.nviz.image is special. Have you any clue on how to fix this ? is there any environment var that needs to be exported in order to have m.nviz.image running during an SSH session ? GRASS 7.0.svn (nc_spm_08_grass7):~ m.nviz.image \ elevation_map=elevation \ output=elevation_3d \ perspective=15 \ height=2000 \ color_map=elevation \ resolution_fine=1 \ resolution_coarse=1 \ format=tif ERROR: Bad server connection Did you redirect the Display stream? ssh -Y yourserver Perhaps that solving the issue. Depending on if it's a local gigabit network or if you are calling in from home, I'd strongly suggest to use 'ssh -C' as well, since m.nviz.image will want to do about half of its processing on the *local* X server, not the remote computer, and that's a lot of network traffic! Last weekend's task was running m.nviz.image many times in a loop for an animation, and trying to do it remotely from my netbook via a GNU Screen session. But the network connection out at the farm wasn't that good and the several years old netbook's graphics hardware is pretty poor compared to the graphics card in the remote workstation. It took ~10 times as long running it remotely, but it did get there. m.nviz.image didn't work (entirely from the command line) when the DISPLAY enviro var wasn't set correctly in GNU Screen though, I had to reestablish the session to fix that first. good luck, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Fwd: [OSGeo-Discuss] OSGeo Google Summer of Code 2014 - ideas needed!
Martin wrote: thanks for hard work collecting the ideas. agreed! thank you Vaclav (and Helena and Yann). We have about one week before our ideas pages are reviewed by Google and they decide if they want to accept us as an org again or not, so everything must be ready by then. :) a willing to mentor: name1, name2 at the end of each idea is important for demonstrating interest from the dev pool. my personal wish is again for a project to add SVG support to the d.* system and ps.map. :) In thinking about what projects to do, I'd be careful and reserve deep structural or architectural projects for existing student-devs with a deep knowledge of the code and existing community buy-in/flameproof clothing, and have new users to grass work on stand-alone modules or gui tools in the sandbox or addons svn. thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Fwd: [OSGeo-Discuss] OSGeo Google Summer of Code 2014 - ideas needed!
Vaclav wrote:
This definitively sounds useful. I still don't understand why cairo
does not solve it for d.* system. As for the GSoC idea, you should
be more specific about relation to ps.map and which advantages it
would have over ps to pdf conversion (which is done g.gui.psmap)
and than something like pdf2svg tool (cleanness?).
the idea is to allow the user to import SVG graphics to use as icons and
decorations within GRASS cartography, in a similar manner to how eps files can
be used in ps.map already.
I didn't mean about SVG output, which as you mention the cairo driver and
ps2{foo} tools (e.g. inkscape from the command line) can theoretically do.
wrt student experience the Android + meta-data systems, I wouldn't totally
rule out students who bring other talents to the table but have no previous
experience with GRASS, or make it sound so hard that
a good student decides not to apply. I'm sure it will work itself out, I just
don't want to put a new student in a rough
position.
cheers,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] moving gsoc wiki pages
thanks, I don't mean to slow down your good cleanup work! Mostly I'd just like to make sure the change history gets preserved and the ideas pages past student-progress pages look wonderful (and if that means using mediawiki for presenting nicely presented media, so be it), no broken links during transition between wikis, etc. Feedback from Google is that one of the most important things they look at when deciding what orgs to accept into the GSoC program each year is a high quality ideas page for prospective students. Org applications for 2014 open in 3 days, so it's a really critical time right now to get everything in order any linked-to pages well curated. cheers, Hamish On Friday, January 31, 2014 4:58 PM, Vaclav Petras wenzesl...@gmail.com wrote: On Thu, Jan 30, 2014 at 10:23 PM, Hamish hamis...@yahoo.com wrote: Hi, [sorry yahoo mail trouble making me post out of thread] please hold off on moving any historical GSoC wiki pages until further discussion. Hi, just short answer to this thread: No problem, I don't plan to move them any time soon. Vaclav thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] change linear back to bilinear in grass7 ?
Helena wrote: As we are going through the class material I have noticed that in GRASS7 in r.resample.interp method bilinear was changed to linear and bicubic was changed to cubic. Martin: for the record, there was a discussion about that a while ago [1]. So probably we will to open this discussion again. ... [1] http://lists.osgeo.org/pipermail/grass-dev/2013-May/063855.html Hi all and happy new year. for my 2c wrt interpolations I seem to come across bilinear in the world-beyond grass more commonly, and to me it makes more sense. Is the bicubic truly considering x and y separately? i.e. is it actually correct to use the bi- prefix with it? If it's more of a buffer operation, cubic might be better. but whatever is chosen, consistency in use is good to help with the learning curves. I wouldn't object to bilinear + cubic though if each was considered best in its class. regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] new flag to interpolate from nearby raster cells for v.what.rast
Hi, Hamish wrote: I just added in the dev branches two new flags for v.what.rast. [...] The second flag changes the default containing-grid-cell method to a weighted avg. of the 4 nearest raster cell centers (IDW). The search radius is not very big [...] AFAIK, IDW takes as argument the radius which is fixed to 1 which is questionable. I'm not sure I follow what you mean, but the distance in the 4-way inverse distance weighting in the new v.what.rast -i interpolate flag is calculated for each of the closest four raster cells' center coord by running G_distance() vs. the vector point's position, and then the weighting in the weighted average for each of those four cells' data values is by 1/distance^2. It doesn't assume that the 4 surrounding cells are equally distant: weightsum = valweight = 0; weight[i] = 1.0 / (distance[i] * distance[i]); weightsum += weight[i]; valweight += weight[i] * nearby_d_val[i]; value = valweight / weightsum; // 0./0. == nan The other thing of note is that if any of the nearest four cells are null then it discards it from the weighted average, and proceeds with n-1 elements. I find this a preferable compromise between the null if-any-nulls and the fallback to nearest neighbor if-any-nulls methods below; YMMV. Since v.what.rast samples a raster value at a given location, why not use the standard raster sampling methods nearest: nearest neighbor linear: linear interpolation cubic: cubic convolution lanczos: lanczos filter linear_f: linear interpolation with fallback cubic_f: cubic convolution with fallback lanczos_f: lanczos filter with fallback which are used by r.proj and i.rectify? The concept is essentially the same: for a given location, estimate the corresponding raster value. what I've called IDW is similar to the bilinear method above, with the exception of how surrounding NULLs are handled, and nearest is similar to the default behavior of v.what.rast. If someone wants to take it up and expand the options to use Rast_interp_bicubic() co., I'm happy for it, but would like to preserve the null handling and speed. The main bug so far is if the print-only flag is used, it doesn't yet bypass the checks for if the vector map has a table, is in the current mapset (is alterable), and to remove the need for topology. regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Failure to build on Itanium + Debian/sid
Hi, coming back to and renaming this thread, Moritz wrote: Hamish, do you know what is going on for grass 6.4.3 ? I see that it hasn't migrated to testing, yet, because of failure to build on ia64: http://release.debian.org/migration/testing.pl?package=grass On Friday, November 1, 2013 Markus Neteler replied: ... https://buildd.debian.org/status/fetch.php?pkg=grassarch=ia64ver=6.4.3-2stamp=1380196645 shows ... /usr/bin/ld: OBJ.ia64-unknown-linux-gnu/driver.o: @gprel relocation against dynamic symbol db_driver_init /usr/bin/ld: OBJ.ia64-unknown-linux-gnu/driver.o: @gprel relocation against dynamic symbol db_driver_finish /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status make[5]: *** [/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/lib/libgrass_dbmidriver.6.4.3.so] Error 1 ... In an old thread here there is a suggestion: http://software.intel.com/en-us/forums/topic/267748 On Itanium-based systems running Linux, when the -shared switch is used to create a Dynamic Shared Object (.so), there may be some relocation against dynamic symbol messages generated during the ld phase ... To fix this problem, add the switches -i_dynamic and -nofor_main to the command line. see also http://www.opendx.org/cgi-bin/forum/YaBB.pl?num=1139610671/1 A Debian geek may know... Hi, fyi Paul Gevers from Debian figured out the where of this problem, and the fix, but the why is still a bit unknown. see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728150#25 It's a conflict beween -fPIC and -fPIE. The same conflict was happening for the previous Debian release so I had the work-around code in the package build rules, left as commented out for anyone wanting to build backported packages. Apparently the same work-around allows it to build on Itanium. I guess the short-term fix is to do some if [ `uname -m` = ia64 ] ; then ... in the debian/rules? (which is essentialy a Makefile not a shell script) Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] 6.4.4 planning
on the grass-user ML Markus N wrote: (and it is time to get 6.4.4 out...) fwiw, I've gone through the two branches with kdiff3 and selectively backported many of the differences between the branches. There are a number of experiments and minor cosmetic changes which I didn't backport. One big remaining hope I had for 6.4.4 was to backport the parallelization work in the imagery scripts, e.g. i.landsat.rgb. I think they are pretty good but I haven't tried them on WinGrass to learn how well MSys deals with backgrounding jobs with . I had planned to merge scripts/ first, to give them the maximum amount of testing in the stable branch, but it turned out to be too big a job for the small windows of time I could give to it. But now I am mostly waiting on testing them in 6.5 nightly WinGrass. Important bugs concerning the next release https://trac.osgeo.org/grass/report/13 The other two important tasks for 6.4.4 in my mind are to get python addon scripts working with 6.4's g.extension.py, both for Linux and WinGrass (#1768, just committed an experimental change to 6.5svn a few days ago; e.g. for r.threshold), and secondly to get the Cairo driver working on WinGrass (#943). The Cairo driver seems to need some G_spawn() pipe handling/closing in d.mon, using SF_BACKGROUND and other popen flags which I just stumble around in the dark with need some assistance. It's our busy field season right now and I'm just about to head back out to sea, so I won't be here to work on things for the next few weeks (... and then the holidays come). Are there critical bugs fixed in 6.4.4svn since 6.4.3 that demand we ship a fix for ASAP? If not, I'd like to put some energy into the above issues first. If there is some critical need to release now, I don't mind putting these other things off for a 6.4.5, but especially the 'running custom python scripts' in 6.4 WinGrass seems like an important thing to have working out of the box for end users. thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Understanding g.tempfile and resolving Illegal filename issues
Nikos wrote: I don't understand how to use g.tempfile. The manual simply refers to (for bash): temp1=`g.tempfile pid=$$` My attempts to use it like that, end up with: Illegal filename. Character / not allowed. Checking if the map's filename exists, returns for example: --%--- ERROR: Raster map /mnemosyne/geo/grassdb/nc_spm_08/landsat/.tmp/Resilience/26834.0 not found in current mapset ---%-- I have been through the mailing list and have found past references to the same problem. For example http://lists.osgeo.org/pipermail/grass-user/2012-March/063977.html. However, I can't get past the problem. I tried to use naming conventions such as i.fusion.hpf.tmp.$$ but I still have some problems. I would like to use g.tempfile as it seems to be a cleaner way(?). g.tempfile is for actual files like ascii text files, not for map names. the convention used in the grass scripts for temporary map names is arbitrary, but e.g. the g.module command might make one called: tmp_gmodule.$$.elev, for vector maps replace '.' with '_' and bring out your curly brackets. :) then cleanup is as simple as g.mremove 'tmp_gmodule.$$.*', and if maps are left behind it's obvious later that they are temporary and where they came from. there's no automatic handling, but I don't see where that would save any time. what problems did you have with i.fusion.hpf.tmp.$$ ? Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Understanding g.tempfile and resolving Illegal filename issues
Hamish: what problems did you have with i.fusion.hpf.tmp.$$ ? Nikos: I think the problem was (among my misunderstanding) that $$ was the same for a bunch of names fed as variables here and there. '$$' gets replaced with the PID of the calling process, so within a single script it will be consistent, and it should be unique among processes currently running on the system. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Using a multi-${GIS_OPT_X} input in a shell for loop
Nikos wrote:
for Image in `echo $GIS_OPT_MSX | tr , \ ` ; do echo ${Image} ; done
Curly brackets do nothing to protect the contents of a variable. Using them
tricks new bash coders into thinking they are protected when they are not.
To avoid propagating the damaging myth, only use them when you actually need
them (eg to protect the variable name from following characters, not its
contents).
Vaclav:
Is GIS_OPT_MSX also in GRASS 7 (trunk)?
That's just going to be the contents of a msx= command line option defined in
the
script header's #% definition.
regards,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Using a multi-${GIS_OPT_X} input in a shell for loop
Glynn:
Example:
$ hello='hi there'
$ echo $hello
hi there
$ echo $hello
hi there
here's another example:
FOO=a b
BAR=c d
mkdir ${FOO}
mkdir $BAR
ls -l
drwxr-xr-x a/
drwxr-xr-x b/
drwxr-xr-x c d/
Vaclav:
I remember that we had this conversation recently.
I tend to repost that lesson every time I see curly brackets, in a quixotic
attempt to stamp them out. :)
What about putting some (ba)sh(ell) primer into the manual?
My concern with that is where does it end? Do we add a UNIX primer too? I think
it's a very good idea to put links in the wiki to existing tutorials though,
but no need for us to rewrite what's already been written many times. Some tips
are already in the SUBMITTING_SCRIPTS files. Often the best advice is to just
use the existing GRASS scripts as a template. (be it python or bourne scripting)
However, I must say the same I said before. If you need some
advanced bash functionality such as `if` and `for` or even
functions it is better to use/learn Python instead.
I humbly disagree, but probably only on what would be
considered 'advanced functionality'. I'd put the bar more at
the subtle quoting for dynamic variable names needing `eval`
and nested multi-level $(``) executions, or needing to write
some complicated awk or regex statement. i.e. once it gets to
the point where it isn't human readable anymore.. but I guess
the discussion is highly academic since we're not proposing to
change anything from what we do now.
For manipulating huge amounts of ascii data there's not
much in the world that can beat the UNIX powertools piped
together in a shell script. Also it's hard to beat the
simplicity of cutting and pasting the last five lines
you entered onto the command line into a text editor
and saving the file with a .sh extension. i.e. a gentle
introduction to programming for command line users. (this
is why I really like having the command line self-assemble at the bottom of the
module GUIs)
Both python and shell scripting are fine tools, each with their
own niche; I would hope we could identify the best tool for the
job based on the niche, and not devolve into me trying to use
shell scripting for everything because I know it well, and
others trying to use python for everything because they know it
well. And rather both use the most appropriate tool for the job
on a needs basis, and get better in both. :)
2c,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] lib fn to set all of a raster row to NULL?
Hi, is there a lib function somewhere like Rast_get_row() which populates a row buffer, but instead of reading from a file just (re)sets all values in the row array to NULL? something like: Rast_fill_row_with_nulls(void *buf, RASTER_MAP_TYPE data_type) It's easy enough to write small for() loop to do it, but seems like the sort of thing a lib fn might help with, so might already exist somewhere. ? note this is for working with the cell array values, not writing an all-null row on the disk. thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] lib fn to set all of a raster row to NULL?
Hamish wrote: is there a lib function somewhere like Rast_get_row() which populates a row buffer, but instead of reading from a file just (re)sets all values in the row array to NULL? something like: Rast_fill_row_with_nulls(void *buf, RASTER_MAP_TYPE data_type) It's easy enough to write small for() loop to do it, but seems like the sort of thing a lib fn might help with, so might already exist somewhere. ? nevermind, found it: Rast_set_null_value(row_ptr, window.cols, map_type); Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS on Debian [was: Re: [GRASS-user] G7-gui and G64 add-on problems on Xubuntu (installation from grass/ubuntugis ppa)]
Hi, thanks for re-posting the '@gprel relocation against dynamic symbol' linking error on Itanium Markus, right now I'm still only able to get online for a few minutes every two or three days. cc'd to the DebianGIS list for a wider audience who might have come across this before. see also the bug against grass in the debian system re. building on big-endian systems, MarkusM posted about the two checkins to trunk which already fixed it there, those two commits should be considered for backport, or at least into the debian/patches/ list after testing in devbr6. But it seems the latest package build isn't complaining about ppc64 and s390x, so..? http://bugs.debian.org/728150 http://bugs.debian.org/672719 thanks, Hamish On Friday, November 1, 2013 2:28 AM, Markus Neteler wrote: On Thu, Oct 31, 2013 at 2:19 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: ... A bit off-topic, but since we're discussing packaging on Debian co: Hamish, do you know what is going on for grass 6.4.3 ? I see that it hasn't migrated to testing, yet, because of failure to build on ia64: http://release.debian.org/migration/testing.pl?package=grass Any idea what the trouble is ? In the build logs I see stuff like: Status: gcc -E -DPACKAGE=grasslibs -DPACKAGE=grasslibs -I/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/include -U __GNUC__ -dD -Dinline= -D__inline__= -D__extension__= -D_Bool=uint8_t -D__const=const -D__asm__(x)= -D__asm(x)= -DCTYPESGEN=1 /tmp/tmp3imMK2.h Status: Parsing /tmp/tmp3imMK2.h Error: /usr/include/GL/gl.h:109: Syntax error at '\n' Error: /usr/include/GL/gl.h:112: Syntax error at '\n' This happens on all Linux platforms and is not an issue usually. https://buildd.debian.org/status/fetch.php?pkg=grassarch=ia64ver=6.4.3-2stamp=1380196645 shows GRASS GIS compilation log - Started compilation: Thu Sep 26 11:30:48 UTC 2013 -- Errors in: /«PKGBUILDDIR»/lib/display /«PKGBUILDDIR»/lib/db/dbmi_driver ... which is really make[4]: Entering directory `/«PKGBUILDDIR»/lib/display' test -d OBJ.ia64-unknown-linux-gnu || mkdir -p OBJ.ia64-unknown-linux-gnu gcc -I/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/include -g -O2 -Wformat -Werror=format-security -fPIE -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security -Wno-error=format-security -Wall -O -fPIC -DPACKAGE=\grasslibs\ -DPACKAGE=\grasslibs\ -I/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/include -o OBJ.ia64-unknown-linux-gnu/cnversions.o -c cnversions.c ... gcc -I/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/include -g -O2 -Wformat -Werror=format-security -fPIE -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security -Wno-error=format-security -Wall -O -fPIC -DPACKAGE=\grasslibs\ -DPACKAGE=\grasslibs\ -I/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/include -o OBJ.ia64-unknown-linux-gnu/window.o -c window.c gcc -shared -o /«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/lib/libgrass_display.6.4.3.so -L/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/lib -Wl,--export-dynamic -Wl,-rpath-link,/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/lib OBJ.ia64-unknown-linux-gnu/cnversions.o OBJ.ia64-unknown-linux-gnu/color_list.o OBJ.ia64-unknown-linux-gnu/draw.o OBJ.ia64-unknown-linux-gnu/draw2.o OBJ.ia64-unknown-linux-gnu/get_win.o OBJ.ia64-unknown-linux-gnu/ident_win.o OBJ.ia64-unknown-linux-gnu/list.o OBJ.ia64-unknown-linux-gnu/popup.o OBJ.ia64-unknown-linux-gnu/raster.o OBJ.ia64-unknown-linux-gnu/raster2.o OBJ.ia64-unknown-linux-gnu/setup.o OBJ.ia64-unknown-linux-gnu/symbol.o OBJ.ia64-unknown-linux-gnu/tran_colr.o OBJ.ia64-unknown-linux-gnu/window.o -lgrass_gis.6.4.3 -lgrass_datetime.6.4.3 -lz -lgrass_raster.6.4.3 -lgrass_pngdriver.6.4.3 -lgrass_driver.6.4.3 -lgrass_gis.6.4.3 -lgrass_datetime.6.4.3 -lz -lfreetype -lgrass_gis.6.4.3 -lgrass_datetime.6.4.3 -lz -lpng -lz -lm -lgrass_psdriver.6.4.3 -lgrass_driver.6.4.3 -lgrass_gis.6.4.3 -lgrass_datetime.6.4.3 -lz -lfreetype -lgrass_gis.6.4.3 -lgrass_datetime.6.4.3 -lz -lgrass_driver.6.4.3 -lgrass_gis.6.4.3 -lgrass_datetime.6.4.3 -lz -lfreetype -lgrass_gis.6.4.3 -lgrass_datetime.6.4.3 -lz /usr/bin/ld: OBJ.ia64-unknown-linux-gnu/raster2.o: @gprel relocation against dynamic symbol D__overlay_mode /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status make[4]: *** [/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/lib/libgrass_display.6.4.3.so] Error 1 make[4]: Leaving directory `/«PKGBUILDDIR»/lib/display' and so on ... gcc -I/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/include -g -O2 -Wformat -Werror=format-security -fPIE -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security -Wno-error=format-security -Wall -O -fPIC -DPACKAGE=\grasslibs\ -I../dbmi_base -DPACKAGE=\grasslibs\ -I/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/include -o OBJ.ia64
Re: [GRASS-dev] [GRASS-user] G7-gui and G64 add-on problems on Xubuntu (installation from grass/ubuntugis ppa)
Tim wrote: Yes, latest QGIS (daily) packaged based on nightly GRASS builds. Th problem was that upstream was shipping the /debian files as templates. These would need to be replaced by the build script. apparently the trick is to to edit the debian/changelog file, and on the first line replace UNRELEASED with the name of the distro version (template extension) you wish to use. for anything resembling official/stable QGIS packages I'd strongly recommend to stay with an already released stable version of GRASS (i.e. 6.4.3, or for qgis development nightly builds the 6.4 release branch). for experimental/ development packages, do as you like as long as they are clearly labeled as such. thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] G7-gui and G64 add-on problems on Xubuntu (installation from grass/ubuntugis ppa)
Hamish wrote: What can we do to get an updated qgis package into upstream debian/sid? ... Jürgen: Me neither - I saw qgis activity on debian-gis and thought it was underway. I didn't notice that there are problems. hmm, you're right, Sebastiaan was working on it last month, starting from your upstream packaging rules. http://anonscm.debian.org/gitweb/?p=pkg-grass/qgis.git;a=log last contact seems to be: http://lists.debian.org/debian-gis/2013/10/msg5.html ...blocking OSG bug - http://bugs.debian.org/720816 thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] G7-gui and G64 add-on problems on Xubuntu (installation from grass/ubuntugis ppa)
Jürgen wrote: You mean based on a newer GRASS? Otherwise there is a nightly build of QGIS on qgis.org (or even two one on based on plain ubuntu and anther one based on ubuntugis). What can we do to get an updated qgis package into upstream debian/sid? right now it is stuck at 1.7.4 and so all downstream ubuntus friends are stuck there too. I am happy to help but I'm not sure if there was a reason for it being stuck? thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] G7-gui and G64 add-on problems on Xubuntu (installation from grass/ubuntugis ppa)
[sorry to break the thread but yahoo mail is more broken than usual today and won't let me reply to the other..] Cesar wrote: To be able to install grass addons in 6.4.3 you need to install the grass-dev package with sudo apt-get install grass-dev and then issue the g.extension command Vaclav wrote: Maybe, GRASS, namely g.extension, should identify the error (e.g. check the include/Make directory) and report an error with a suggestion (if on linux: Check that you have package ...). But this might be very different for various distributions. Hi, the master debian packaging rules for 6.4 do add such a warning already, but only for the command line version of g.extension (which I was more comfortable patching at the time; patch for the python version welcome). http://anonscm.debian.org/gitweb/?p=pkg-grass/grass.git;a=blob_plain;f=debian/patches/check4dev;hb=HEAD so when you run it without the grass-dev package installed the first warning you get is to install the missing package. I don't know how often the Ubuntu custom PPA packagers sync with the updates to the debiangis packaging rules, but the warning has been in there for a year and a half or so already. IMO this is a packaging issue; any fix/warning due to packaging splits belongs with the packaging rules that did the splitting. Probably also the package description and suggested/related packages should provide some information. this is also already done, http://anonscm.debian.org/gitweb/?p=pkg-grass/grass.git;a=blob;f=debian/control;h=9f1191080f0ee9a5dcbcd9ebe4e62d9203ed5f13;hb=HEAD#l162 grass-dev pkg description: This package contains the header files for developing with GRASS. Install this package if you wish to develop software that manipulates GRASS data sets or install addons using the g.extension module. ISTR there was an issue if grass-dev was installed but the grass-doc package wasn't, but I think that's a bit of a corner case (-if grass-core was installed but the grass package wasn't). I think the problem had to do with the missing logo or css file, or perhaps the missing dir structure? I too get the emails about the broken 7.0 ppa build, according to the error message the latest issue seems to be a ubuntu dependency tangle in the new trusty version, best to give that some time to sort itself out: State: Dependency wait https://launchpadlibrarian.net/154922788/buildlog.txt.gz https://launchpadlibrarian.net/155002197/buildlog.txt.gz earlier I saw errors which the build log suggested were gcc bugs when builing ccmath, I assume an update for gcc would solve that. Finally, and not really related but while I remember, there's a problem building 6.4.3 on Itanium which I don't understand; build log: https://buildd.debian.org/status/fetch.php?pkg=grassarch=ia64ver=6.4.3-2stamp=1380196645 ... gcc -I/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/include -g -O2 -Wformat -Werror=format-security -fPIE -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security -Wno-error=format-security -Wall -O -fPIC -DPACKAGE=\grasslibs\ -DPACKAGE=\grasslibs\ -I/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/include -o OBJ.ia64-unknown-linux-gnu/window.o -c window.c gcc -shared -o /«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/lib/libgrass_display.6.4.3.so -L/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/lib -Wl,--export-dynamic -Wl,-rpath-link,/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/lib OBJ.ia64-unknown-linux-gnu/cnversions.o OBJ.ia64-unknown-linux-gnu/color_list.o OBJ.ia64-unknown-linux-gnu/draw.o OBJ.ia64-unknown-linux-gnu/draw2.o OBJ.ia64-unknown-linux-gnu/get_win.o OBJ.ia64-unknown-linux-gnu/ident_win.o OBJ.ia64-unknown-linux-gnu/list.o OBJ.ia64-unknown-linux-gnu/popup.o OBJ.ia64-unknown-linux-gnu/raster.o OBJ.ia64-unknown-linux-gnu/raster2.o OBJ.ia64-unknown-linux-gnu/setup.o OBJ.ia64-unknown-linux-gnu/symbol.o OBJ.ia64-unknown-linux-gnu/tran_colr.o OBJ.ia64-unknown-linux-gnu/window.o -lgrass_gis.6.4.3 -lgrass_datetime.6.4.3 -lz -lgrass_raster.6.4.3 -lgrass_pngdriver.6.4.3 -lgrass_driver.6.4.3 -lgrass_gis.6.4.3 -lgrass_datetime.6.4.3 -lz -lfreetype -lgrass_gis.6.4.3 -lgrass_datetime.6.4.3 -lz -lpng -lz -lm -lgrass_psdriver.6.4.3 -lgrass_driver.6.4.3 -lgrass_gis.6.4.3 -lgrass_datetime.6.4.3 -lz -lfreetype -lgrass_gis.6.4.3 -lgrass_datetime.6.4.3 -lz -lgrass_driver.6.4.3 -lgrass_gis.6.4.3 -lgrass_datetime.6.4.3 -lz -lfreetype -lgrass_gis.6.4.3 -lgrass_datetime.6.4.3 -lz /usr/bin/ld: OBJ.ia64-unknown-linux-gnu/raster2.o: @gprel relocation against dynamic symbol D__overlay_mode /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status make[4]: *** [/«PKGBUILDDIR»/dist.ia64-unknown-linux-gnu/lib/libgrass_display.6.4.3.so] Error 1 make[4]: Leaving directory `/«PKGBUILDDIR»/lib/display' ... thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http
Re: [GRASS-dev] Email subject standards
Vaclav wrote: please note that changing subject when you reply an email breaks the email thread, so then there are two threads instead of one. Even adding some words to the subject line is usually considered as a change, so it creates a new thread. Hi, it depends on your software, many email clients and online archives know about use email header lines to signify the relationships regardless of the subject line. Other email clients ignore all that and simply go by the strict subject line or their own fuzzy intelligence sorting method (eg gmail?). see for example http://www.jwz.org/doc/threading.html http://people.dsv.su.se/~jpalme/ietf/message-threading.html regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Planetary option gone in GRASS 7 SVN WxGUI Location Wizard?
Yann wrote: wanted to make a Moon location and the option for Planetary Locations definitions is gone... Hi, How are you trying to access it? There should be a radio button to enable them on the ellipsoid selection page. regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass compile error on launchpad
Rashad: There are build failure on grass70 on GRASS PPA Launchpad. the part from error log: ... iscatt_core.c: In function 'compute_scatts_from_chunk_row': iscatt_core.c:580:4: warning: statement with no effect [-Wunused-value] iscatt_core.c:581:17: error: expected ';' before 'G_gettext' ... Is this only launchpad or anyone have problems because error message doesn't seems so Hi, I got cc'd on the launchpad error too and already fixed it in svn. Easy fix, just a missing (). Perhaps some other compiler warnings there to look at though. thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass compile error on launchpad
Štěpán wrote: Yesterday I tried to erase all compiler warning which gcc showed me. But I am not sure if I have correct setting of compiler to show me all warnings. Could you give me some advice with this? it's not so bad actually, after a svn up and 'make distclean' only one minor one remains from gcc 4.4.5 using CFLAGS=-g -march=native -Wall -Werror-implicit-function-declaration -fno-common -Wextra -Wunused iscatt_core.c: In function 'compute_scatts_from_chunk_row': iscatt_core.c:454: warning: unused parameter 'region' thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] v.in.ogr: how to force sqlite instead of dbf for output location ? SEG-Y input (Geology/Seismic Data)
Peter wrote: I'm evaluating the SEG-Y formate to exchange data between software packages from the exploration industry like Petrel and Gocad and GRASS. So far only demo data sets are used. I will inquire wether P1/90 is also available. links: http://grasswiki.osgeo.org/wiki/AddOns/GRASS_6#v.in.p190 For working with SEG-Y data, see also the v.in.mbsys_fnv addon. http://grasswiki.osgeo.org/wiki/AddOns/GRASS_6#v.in.mbsys_fnv the workflow for v.in.mbsys_fnv is to use MB-System to create ancillary support files from the SEG-Y trace headers (the navigation data ends up in a .fnv file), then use the addon module to import those as points or track lines. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] How to calculate mean coordinates from big point datasets?
Hamish wrote:
see also the v.points.cog addons script:
http://grasswiki.osgeo.org/wiki/AddOns/GRASS_6#v.points.cog
although I haven't tried it for anything as big as lidar data.
oops, I completely forgot to mention the r.cog addon script too:
https://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.cog
The main goal isn't just center-of-gravity, it's also to reduce the
dataset to a single trend plane. In that way you might subtract out the
principal component of the z-surface to show the underlying signal
(or bring the primary trend into focus). This is e.g. a common task in
working with magnetic data where the Earth's field dominates, but
is relatively smooth compared to the local signal.
A good sample data for it is spearfish's elevation rasters since there
is a strong N-S trend, and for categorical features using the spearfish
fields map + choosing different combinations of categories to move the
center-point around.
I suspect that it could be quite effective with lidar if used with
r.in.{xyz,lidar}, and would be interested to see how the results compare
numerically with MMetz's new module, especially if the 10% trimmed-mean
binning method was used to solve the mean vs. median outliers problem.
(for really big datasets that method has a non-trivial RAM cost though)
r.cog is not listed on the wiki yet since the dip angle and azimuth +
r.plane trend map is still a work in progress -- help welcome, I've
got the 3D pivot point and azimuth seemingly ok, but the mean slope
has proven tricky. My last attempt at it was to split the raster into
three equal-area triangular zones (sort of looking like the South African
flag) then do the COG for each (yes, a recursive script :) to get 3 3D
points, then fit a plane formula to them. IIRC the trouble I was having
with that was if there were large areas of NULL on one side it threw
the whole thing off.
see the example in the v.points.cog help page for an idea of what its
original target application was: placing labels in just the right spot,
while r.cog was written mainly with the idea to determine/create trend-
surfaces.
regards,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] How to calculate mean coordinates from big point datasets?
Moritz: Would be interesting to see results for big data. And AFAIK median is a bit more difficult to do in awk. I imagine that replacing the median by the mean in numpy is no problem (might be a flag to add to v.median). see the old r.univar.sh shell script for an idea of how to get a median using unix power tools, it's fairly trivial. https://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/scripts/r.univar.sh/r.univar.sh#L135 Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] How to access the value of each cell for every row column with pygrass?
Nick wrote: Using pygrass is it possible to create a matrix or a numpy array which will contain each cell's value? Something similar like gdals ReadAsArray function? have a look at the RasterNumpy class, https://trac.osgeo.org/grass/browser/grass/trunk/lib/python/pygrass/docs/raster.rst#L308 Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] v.mapcalc
Vaclav wrote: when I saw recent changes [1] in grass/trunk/vector/v.mapcalc/ I realized that there is a v.mapcalc in trunk (compilation is disabled). However, here is also a v.mapcalc in GSoC project for temporal algebra [2]. I'm wondering how they compare with each other for the old GRASS 5 v.mapcalc which is the subject of the trac ticket, you can read about it here: https://trac.osgeo.org/grass/browser/grass/trunk/vector/v.mapcalc/README and for the temporal GIS v.mapcalc Thomas's wiki page that you linked to does a nice job. AFAICT the old one is looking at math more than spatial, so perhaps a bit more like v.transform might be, than e.g. the functionality of v.overlay or v.select's GEOS tools as the temporal version might be more focused on? (I'm not really sure though, I'm just going from what I see in the README) How the eventual-goals of both of these modules compare with what general-purpose vector ops can be done using PostGIS would be interesting to know too. and what is the plan? I would suggest step 1 to be your question- understand and take an inventory of what we tools we already have, and what state they are in. Choosing the best names for things can come after that. Of course for the long run we should avoid name-space collisions if we can. regards, Hamish [1] https://trac.osgeo.org/grass/ticket/1321 [2] http://grasswiki.osgeo.org/wiki/GRASS_GSoC_2013_Temporal_GIS_Algebra_for_raster_and_vector_data_in_GRASS#v.mapcalc ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Size of the volume_layout image
Vaclav:
After consultation with Sören, I changed the image size (old size
file preserved). I also added simple README and renamed the images to
one unified name.
Hi,
anyone have hints if width=x or width=x% in the img src is enough
to take care of the scaling? (some browsers rescale ugly, others blend)
e.g. I put a fairly large dimension screenshot into the G6 d.correlate.sh
help page yesterday:
https://trac.osgeo.org/grass/changeset/57779
good/no good?
Changeset:
https://trac.osgeo.org/grass/changeset/57780
How about using svn symlinks? Then there is only wasted space on Windows and
the g_module_imgname.{png,jpg} naming convention for help page images could be
preserved.
(Subversion takes care of all the platform details)
or probably better just have the main r3 intro doc supply the image, then just
have the other help pages img src= to it assuming that it will be there in
$GISBASE/docs/. I don't think it even needs ../ since they all live in the
same install dir.
gimp can read+write compressed files directly, so suggest to keep any .xcf
files in svn as .xcf.bz2. (note mime-types remain on the internal content type,
not the compression type used.)
perhaps the README should mention that r3.out.vtk + Paraview was used to make
the screenshot? (it looks like it anyway) Also, I'd also suggest to rename the
README to something more specific as it sits in a top-level dir and one might
assume it contains high-level instructions.
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] redirect graphic output of r.spread
Margherita wrote: Any idea on how to (and IF it's possible to) redirect the graphic output of r.spread module to a gif or mov or avi file instead of to (or beside to) the monitor? Hamish: not directly, but you might see the screencast section in: http://grasswiki.osgeo.org/wiki/Movies Thanks for the link. But I don't understand how to put this in practice. I mean, as far as I understand, you're suggesting to run r.spread in a loop, each step producing a final map as image and then compose together as a video, right? nope, the screencast is to record the changes on the screen as they happen, like putting a movie camera pointed at the screen. (including the cursor if it happens to be in-shot) As-written I don't think there's a way to have r.spread write out static images per-iteration to encode later into a video from individual frames. regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] How to calculate mean coordinates from big point datasets?
Markus Neteler wrote: I came across this question: http://gis.stackexchange.com/questions/71734/how-to-calculate-mean-coordinates-from-big-point-datasets so wants to find the average coordinate? and wondered if this approach would be the fasted: # http://grass.osgeo.org/sampledata/north_carolina/points.las v.in.lidar input=points.las output=lidarpoints -o ... Number of points: 1287775 ... Now I would use v.univar -d lidarpoints type=point (still calculating here...) Is it the best way? see also the v.points.cog addons script: http://grasswiki.osgeo.org/wiki/AddOns/GRASS_6#v.points.cog although I haven't tried it for anything as big as lidar data. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] redirect graphic output of r.spread
Margherita wrote: Any idea on how to (and IF it's possible to) redirect the graphic output of r.spread module to a gif or mov or avi file instead of to (or beside to) the monitor? not directly, but you might see the screencast section in: http://grasswiki.osgeo.org/wiki/Movies Hamish ps- I just added a completely synthetic example to the wiki page, not as good as the sample download but you can run it directly from the NC sample dataset. http://grasswiki.osgeo.org/wiki/How_to_create_parameters_to_run_r.ros#Example ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Right way to use G_getl2
Markus Metz wrote: I would suggest to modify G_getl2() to read at most n (not n - 1) characters and include a check if the buffer is long enough: mmmph, to me G_get2() does the right thing, as long as people follow the given instructions all is fine. So I'd vote to keep it as-is. FWIW, at most one less than size characters from stream follows the behaviour of fgets() and (programmer)fails on the side of not overflowing the given output buffer. The \n and \r chars are not stored in the output string, and are not left in the input stream for the next line. (if this wasn't the case it's pretty hard to imagine that we wouldn't have noticed corrupted ascii file input over the last 4 years) is there a ticket for the 'v.in.ascii skip=' overflow problem? if not can someone open one with a problematic input file attached? I suspect the recent patch is perhaps fixing a problem actually rooted somewhere else.. thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GUI wizards reducing functionality [was: Re: Missing subgroup functionality in GRASS 7 wxGUI's i.group?]
Moritz wrote:
I do think that we should have a more general debate about how to handle
these issues. Personally, I'm very strongly opposed to this tendency of
dumbing-down the GUI menus. I have nothing against wizards, but I
think they should be an additional feature, not a replacing features.
Hi,
I don't think it needs a big debate, just a bit of finesse in the execution.
For example I think the Cartographic Composer tool does a nice job of hiding
the ps.map module GUI dialog behind a conceptual Advanced button using
its menu placement. New users would probably ignore the menu item not
knowing what it did; seasoned users would recognize what it was and use it
as needed, but for them too it wouldn't be cluttering up for normal use.
An example I keep coming back to is wrapper-subset scripts for d.vect (*see g6
addons d.stations, d.varea, and ~d.mark), since the main GUI controls begin
to resemble the complication of a Boeing 747 cockpit. Simplification in and
of itself is not always a bad thing.
wrt the steepness of the learning curve, I don't think you should have to know
the name of a module to launch its GUI (ie from the command line) instead of a
wizard, but the wizard should gently teach you the name of the module. For
me this was the self-assembling command lines at the bottom of the grass5
tcltkgrass module GUIs.
wrt r.import and r.export as fancy g.GUI wizards and r.{in|out}.gdal as
advanced full module dialog GUIs, the idea sounds nice to me.
regards,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS70 for Ubuntu in ppa
Hi, you might have a look at the grass7 startup script to see why 7.0 is looking for anything in the old /usr/lib/grass64/* directory. `which grass70` should tell you the file to start looking in. (eg /usr/bin/grass70) be sure you haven't manually set the GISBASE environment variable to anything. regards, Hamish Johannes wrote: Hi, yes grass-gui package is now also installed and this made grass64 working. However the grass-gui package did not solve the problem with launching the gui of grass70. ... Johannes: However when I try to launch both from the console (freshly installed precise) via grass64 or grass70 I get an error: python: can't open file '/usr/lib/grass64/etc/wxpython/gis_set.py': [Errno 2] No such file or directory ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Grass parallelization
Don wrote: Do you know if there is much interest in greater parallelization? Huge interest. Outside of the core libraries, GRASS is made up of ~500 individual processing modules, each doing their own thing well. Each utilizes their own algorithms and strategies which is why GRASS 7 has built-in support for OpenMP, pthreads, *and* OpenCL- the idea is that the right parallelization strategy can be matched to the nature of the problem which each individual module faces. Additionally our python scripting library has helper functions to make parallel discrete-processes easy to use, since a common use case is to run the same computation on three different Red,Green,Blue imagery bands, or all ~7-11 spectral bands from satellite data (e.g. LANDSAT). In those cases the number of natural processes are in the same neighborhood as the number of cores on a typical workstation, so backgrounding all but one of the jobs in bash or python then waiting for them all to finish works remarkably well and takes minimal programming effort and divergence from the single-thread case. That's not far from the MPI situation, instead of backgrounding jobs they could just as well be sent to other machines in the cluster. As Soeren mentioned the gmath and gpde libraries support OpenMP already; in addition Seth Price put together an OpenCL version of our r.sun module (GPU ray tracing sunbeams, seems like a natural fit!) but I/we still need to finish integrating that into the main build; and our r.mapcalc module has pthreads support. The r.mapcalc (raster array map calculator) case is a pretty typical one for GRASS modules actually, they are not entirely, but not far from, being I/O limited not CPU bound per se. For MPI this means that there's a *lot* of data to pass around the network, and unless you've got infiniband or some network infrastructure near to the speed of your RAID, I suspect you'll quickly saturate. The main highly-CPU-bound modules I am personally very keen to see get parallelized are our spline interpolation modules: v.surf.rst and v.surf.bspline. The LU decomposition parts of them are actually in the GRASS libraries not the modules, so that would also benefit e.g. v.vol.rst which does 3D voxel cube interpolations. The v.surf.rst module uses quadtree segmentation, and v.surf.bspline does its own splitting into ~ 12-120 processing segments, so those yell out to me as low hanging fruit. I am sure the vector network analysis modules could make good use of parallelization too, but I don't use those enough personally to be able to comment on their immediate needs and bottlenecks. Markus N. might be able to talk about what he's doing on the Top500 supercomputer (AIX); I'm not sure how much Maui/Torque or similar is handling the job submissions there and how much is manual scripting to break up/send out the jobs and then process the results. And have the Intel compilers and MPI been used with GRASS? Yes, I've built GRASS with icc ver 12.1.3 (-O2 -xHost -ipo -static-intel -parallel -Wall). Considering the size of the GRASS codebase it might be a little surprising that there weren't more problems :), but we do try pretty hard to keep the code straight ANSI/C89 C, which helps a lot with portability. For GRASS + icc build notes see: http://thread.gmane.org/gmane.comp.gis.grass.devel/47823 For GRASS I generally need to keep a close eye on the Debian packaging, so typically build it will gcc; outside of GRASS for I do use ifort a lot, and there the OpenMP auto-vectorization works really great. I understand that's a bit easier to do for FORTRAN than C though. As for MPI, there's a MPI version of the above mentioned v.surf.rst module for GRASS 5 floating around somewhere (probably under its old name of 's.surf.rst'); I actually run a medium sized cluster in my day job which is ~85% MPI usage, but I've never really been tempted to use it for GRASS things.. for what I personally do often saturating all cores/CPUs on the local workstation is enough. Also, the cluster setup can be non-trival for new users (NFS mounts, ssh keys, etc..), so out-of-the-box just works OpenMP style multi-threading probably gets us better bang for the buck when trying to support the 'Desktop GIS' user case, which is probably the bulk of our end users. But don't get me wrong, if the long-running modules like the spline interpolations and the r.cost module for search-paths were MPI-enabled they'd certainly get used by our power users teams using it for back-end server satellite image number crunching! regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] d.text -c
Martin wrote: `d.text` contains apparently unused flag -c Ignored (compatibility with d.text.freetype) Because `d.text.freetype` has been removed from GRASS 7, it seems to me that this flag can be removed without any harm. sure More strangely `d.text.freetype` in GRASS 6.4/6.5 says the same as `d.text`, ie. -c Ignored (compatibility with d.text.freetype) What you're seeing there is actually the options of d.text.new, not d.text.freetype. In 6.x the old d.text and d.text.freetype modules were both replaced by d.text.new. d.text.new is built with the d.text name, and d.text.freetype is a wrapper script calling d.text. I only see the -c flag in the d.text.freetype/ code currently, which was to put it into command mode (compatibility with a d.text(.old) feature which no longer exists). Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS GIS 7 tech-preview release preparations
Vaclav wrote: * For finding and running a module, user should use the module tree in the search modules tab. Hi, I welcome better presentation of the menus since they get rather big (platoon rule of thumb: any more than ~12 in any level/group gets a bit overwhelming), but wrt search to run as the primary instead of augmenting method, I fear that way is not very discoverable -- at least I'd like to avoid the situation where a new user needs to know the name of what they're looking for before they can find it, which isn't so good to explore learn about new modules you don't know exist yet. Especially for a software so big as ours which takes years to fully know. We are spatial creatures, so a spatial model for menu layout where we can use our spatial muscle memories helps I think. Our monitors are getting really wide these days, both desktop and laptop, and so top menu bars will fit even better than they used to, we just have to make the windows a bit wider to compensate. Luckily these days there's space for that. (2c) regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] g.remove rast prefered
Martin wrote: AFAR there was already discussion related to g.remove/g.copy/g.rename modules. Before we start releasing GRASS7 tech-preview I would prefer to change the current behaviour. g.remove x Removing raster x WARNING: Raster map x not found WARNING: x nothing removed to g.remove x ERROR: Invalid data element (valid options: rast,vect..) - g.remove rast=x What do you think? I'd personally prefer to have it stay as-was, but whatever. (Extra keystrokes just slow me down.) I wonder though, as long as rast= stays as the first option will your example of g.remove rast=x still just work as g.remove x anyway since the parser assumes the first option as the default? (this is what currently happens) And so does the change need some deeper parser override? If so I'd be very hesitant about touching that in libgis as it breaks predictability of parser usage. that consistency is a very strong selling point /or any inconsistency makes the learning curve that much harder and messier. To me that consistency is more important than the pain of the lesson of how the parser works. how would it be implemented? regards, Hamish ps- my big question prior to g7 preview: to reorganize raster elements into $MAPSET/raster/mapname/elements dir structure for g7 or not? if so as per Glynn's plan we need to clean-room/from scratch(spec) write a MIT/X licensed G6 raster map driver for gdal ASAP. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Why the parameters of g.region are defined as string?
Ben: It needs to be a string, so that you can use common lat/lon notations in the format °dd'mm''ss. technically it's like ddd:mm:ss.H. see the v.in.ascii man page. fwiw GMT mapping uses something similar. regards, Hamish ps- the wxgui loc'n wizard still doesn't support that? :-( ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] standalone installer cleanup
Hi, re. r57342, the PROJ_LIB variable is needed by e.g. cs2cs used by some scripts, and I'm not sure if the removal of tcl/tk from the PATH was intentional or just an over-merge, but fwiw a functioning gis.m should remain as an alternative in case there are multiple-python install problems (as ongoing) or just because someone likes to use it for whatever reason. thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.info in grass 7 misses the -m flag
Nikos: why was the r.info -m flag (in grass 6x) removed in grass 7? Difficult to implement, not useful? it was moved into 'r.info -e'. I think the idea was to have a less complicated view for the module GUI, but to me it makes it less useful from the command line. (2c) probably the none values for 'r.info -e' should just be empty, to make them easier to parse work with `eval` directly. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Fw: [Ubuntu] GeoGit
Hi, taking the liberty of fwd'd Tim's email here, as the basic idea can be quite an important one for maintainers of cadastral data. Paper-trails of changes and formal metadata hooks (eg for INSPIRE) remain major missing features in GRASS. regards, Hamish - Forwarded Message - From: Tim Michelsen timmichelsen gmx-topmail de To: ubu...@lists.osgeo.org Cc: Sent: Friday, August 2, 2013 10:32 AM Subject: [Ubuntu] GeoGit Hello, GeoGit seems to be a real nice addition to ou toolboxes: http://geogit.org/ Distributed Version Control for Geospatial Data View project on GitHub Welcome to the GeoGit project, exploring the use of distributed management of spatial data. GeoGit draws inspiration from Git, but adapts its core concepts to handle versioning of geospatial data. Users are able to import raw geospatial data (currently from Shapefiles, PostGIS or SpatiaLite) in to a repository where every change to the data is tracked. These changes can be viewed in a history, reverted to older versions, branched in to sandboxed areas, merged back in, and pushed to remote repositories. Now they plan to get into Debian: Debian installer https://github.com/opengeo/GeoGit/issues/365 How is packaging of java based applications done? regards, Timmie ___ UbuntuGIS mailing list Ubuntu lists.osgeo org http://lists.osgeo.org/mailman/listinfo/ubuntu http://trac.osgeo.org/ubuntugis/wiki ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] compilation of grass on AIX 7.1
Vaclav wrote: GCC warns me also about format not a string literal and no format arguments. I remember this was once discussed on the ML but I'm not sure what the result was: the call is correct but the G_warning function needs some GCC attributes to specify what it is? Glynn: G_warning() already has a format attribute, which is why gcc complains about the format string not being a string literal. However, G_gettext() needs a format_arg attribute to to tell gcc that one of arguments may be a format string, so that it stillcan perform argument checking (and not generate not a string literal warnings) when a format string is passed through that function (the _(...) macro expands to a G_gettext() call when --with-nls is used). Done in r57238. With that change there are still 208 such warnings, but most of them appear to indicate genuine bugs, i.e. passing arbitrary strings as format strings, which will fail (e.g. crash) if the string contains any % characters. Hi, is it appropriate to backport r57238 to 6.x? glocale.h: -extern char *G_gettext(const char *, const char *); +extern char *G_gettext(const char *, const char *) __attribute__((format_arg (2))); I'm seeing this pop up in Debian/unstable, where -Werror=format-security is now encouraged to be the default. there are also quite a few like G_fatal_error(buff);, can anything be done in the lib fn for them or do they all have to be changed to G_fatal_error(%s, buff); ? [* many of those are hold-overs from pre- GRASS 5 and a sprintf(buff,..) in the lines above can be moved into the G_fatal_error()] Lots of G_warning(msg); and G_debug(3, db_get_string(sql)); to consider too. thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] G7: landsat_met.c:103: undefined reference to `chrncpy'
Hi, I think it needs additional LDFLAGS too. here's an example from the debian/unstable build include /usr/share/hardening-includes/hardening.make CFLAGS=$(shell dpkg-buildflags --get CFLAGS) LDFLAGS=$(shell dpkg-buildflags --get LDFLAGS) # - CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security LDFLAGS=-Wl,-z,relro # then CFLAGS+=$(HARDENING_CFLAGS) LDFLAGS+=$(HARDENING_LDFLAGS) (I'll echo those out in the morning if you need them) # TODO: fix these CFLAGS+=-Wno-error=format-security ... gcc -I/home/hamish/src/grass/grass-6.4.3/dist.x86_64-pc-linux-gnu/include \ -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat \ -Werror=format-security -fPIE -fstack-protector --param ssp-buffer-size=4 \ -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security \ -Wall -O -fPIC -DPACKAGE=\grasslibs\ -D_FILE_OFFSET_BITS=64 \ -DGDAL_LINK=1 -DGDAL_DYNAMIC=1 -DPACKAGE=\grasslibs\ \ -I/usr/include/gdal -I/usr/include/gdal \ -I/home/hamish/src/grass/grass-6.4.3/dist.x86_64-pc-linux-gnu/include \ -o OBJ.x86_64-pc-linux-gnu/adj_cellhd.o -c adj_cellhd.c Hamish - Original Message - From: Markus Neteler nete...@osgeo.org To: GRASS developers list grass-dev@lists.osgeo.org Cc: Sent: Monday, July 29, 2013 10:29 PM Subject: [GRASS-dev] G7: landsat_met.c:103: undefined reference to `chrncpy' Hi, I changed my compiler flags to catch more potential errrors and got this one: [neteler@north i.landsat.toar]$ make gcc -g -Wall -fno-common -fexceptions -std=gnu99 -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector -m64 -mtune=generic -I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include -I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include -DPACKAGE=\grassmods\ -I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include -I/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/include -o OBJ.x86_64-unknown-linux-gnu/landsat_met.o -c landsat_met.c In file included from /usr/include/stdio.h:27:0, from landsat_met.c:1: /usr/include/features.h:330:4: warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Wcpp] : gcc -L/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/lib -L/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/lib -Wl,--export-dynamic -L/usr/lib64 -Wl,-rpath-link,/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/lib -o /home/neteler/grass70/dist.x86_64-unknown-linux-gnu/bin/i.landsat.toar OBJ.x86_64-unknown-linux-gnu/landsat_set.o OBJ.x86_64-unknown-linux-gnu/main.o OBJ.x86_64-unknown-linux-gnu/landsat.o OBJ.x86_64-unknown-linux-gnu/earth_sun.o OBJ.x86_64-unknown-linux-gnu/landsat_met.o -lgrass_raster.7.0.svn -lgrass_gis.7.0.svn -lm OBJ.x86_64-unknown-linux-gnu/landsat_met.o: In function `lsat_metadata': /home/neteler/grass70/imagery/i.landsat.toar/landsat_met.c:103: undefined reference to `chrncpy' /home/neteler/grass70/imagery/i.landsat.toar/landsat_met.c:112: undefined reference to `chrncpy' /home/neteler/grass70/imagery/i.landsat.toar/landsat_met.c:122: undefined reference to `chrncpy' collect2: error: ld returned 1 exit status make: *** [/home/neteler/grass70/dist.x86_64-unknown-linux-gnu/bin/i.landsat.toar] Error 1 Does anyone know how to fix that? Perhaps related to the use of -D_FORTIFY_SOURCE=2 Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Custom GRASS command line prompt
Hamish wrote: # example of adding an RGB border color with a #RRGGBB code: echo -ne \033]11;#53186f\007 ... But I think changing the border with a RGB color per mapset or location would scale better if you were having a different color for each mapset/location. Or, for the MASK present I'd prefer a red terminal border to the extra line on the command prompt, so it might be nice to search out what the different escape codes for gnome-terminal et al. might be. hmm, doesn't work so well. xterm: echo -e \e]11;#aa186f\007 CLEAR='\e[2J\e[1;1H' echo -ne \e[37m\e[40m$CLEAR unset CLEAR this sets the internalBorder resource (xterm -b) color, but as soon as something wraps around column 80 it stops being the border color and becomes the background color. it would be nice to figure a way to get the border color working properly though. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Custom GRASS command line prompt
Hamish wrote: # example of adding an RGB border color with a #RRGGBB code: echo -ne \033]11;#53186f\007 ... But I think changing the border with a RGB color per mapset or location would scale better if you were having a different color for each mapset/location. Or, for the MASK present I'd prefer a red terminal border to the extra line on the command prompt, so it might be nice to search out what the different escape codes for gnome-terminal et al. might be. hmm, doesn't work so well. this sets the border color in xterm: echo -e \e]11;#aa186f\007 CLEAR='\e[2J\e[1;1H' echo -ne \e[37m\e[40m$CLEAR unset CLEAR ..for the internalBorder Xresource (xterm -b), but as soon as something wraps around column 80 it stops being the border color and becomes the background color. it would be nice to figure a way to get the border color working properly though since it seems like a nice way to do it. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Custom GRASS command line prompt
Nikos:
Just a thought: would be nice to customise as to have a top or a
bottom info-line, or two info-lines below 80 chars (what's the
max that should be respected?),
see MarkusN's [Raster MASK present] command prompt magic using
$PROMPT_COMMAND (set in $GISBASE/etc/Init.sh).
or stuff can go in the terminals title-bar -- this, I
guess, works easily with a few terminals like xterm.
see $GISBASE/etc/grass-run.sh
re. using terminal colors, a web-search finds a number of pages like this:
http://superuser.com/questions/270214/how-can-i-change-the-colors-of-my-xterm-using-ansi-escape-sequences
# putting that into practice:
CLEAR='\e[2J\e[1;1H'
FG_CYAN='\e[36m'
BG_BLUE='\e[44m'
echo -en ${FG_CYAN}${BG_BLUE}$CLEAR
# example of adding an RGB border color with a #RRGGBB code:
echo -ne \033]11;#53186f\007
for me, xfce4-terminal and rxvt accepted the old EGA colors for fore/background,
but not the full RGB border -- I had to use xterm to see that work.
But I think changing the border with a RGB color per mapset or location would
scale better if you were having a different color for each mapset/location.
Or, for the MASK present I'd prefer a red terminal border to the extra line
on the command prompt, so it might be nice to search out what the different
escape codes for gnome-terminal et al. might be.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] i.latlong
I'm trying to understand the function of i.latlong: when would it be useful? r.sun optionally takes lat,long raster maps as input, and you could use r.mapcalc x(), y() to create those then use r.proj to bring them into your projected location. (or some v.mkgrid + m.proj + r.in.xyz magic) but it turns out that the overhead in opening and reading those maps is more work than just using the pj_() functions to calculate the cell-center coordinate values either per-row,column or even for each cell on-the-fly within the module. So it's a net loss and for grass7's r.sun I'd planned to remove those two r.sun input options. (it was otherwise added to r.sun in years past to allow r.sun to work in an XY location, but I don't think that justifies the extra module complexity) ? thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Custom GRASS command line prompt
Nikos: I want to alter the default GRASS command line prompt. For my needs, I find it better to have the current Mapset shown along with the Location. As a first experiment, I edited the corresponding file in place: grass7_trunk/dist.x86_64-unknown-linux-gnu/grass70.tmp, line 1039: - f.write(PS1='GRASS %s (%s):\w '\n % (grass_version, location_name)) + f.write(PS1='G %s (%s/%s):\w '\n % (grass_version, location_name, mapset)) Now it appears like: G 7.0.svn (utm_37s/post):~ . My understanding is that I probably need to edit the file: grass7_trunk/dist.x86_64-unknown-linux-gnu/grass70.tmp Do you have customised prompts? Any ideas for a more productive command line? I'd suggest to put the change in ~/.grass.bashrc instead. fwiw here's what I have there wrt the prompt: SHORT_VER=`echo $GRASS_VERSION | cut -f1,2 -d. | sed -e 's/\.//'` export PS1='G$SHORT_VER:\W ' export HISTSIZE=3000 .or. export PS1='G$SHORT_VER:\w ' export PROMPT_DIRTRIM=2 as full dir path gets much too long, especially on WinGrass where the terminal width is a pain to resize. For simplicity one of my favourites is still just: export PS1='GRASS$SHORT_VER ' If you do most of your work with a small set of locations, it might also be an idea to figure something out with Xresources to color the terminal background based on which one you're running in. regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] r57291: configure.in: disable pwd -W (WinGRASS)
Hi, re r57291, it's not safe to modify core files after the last RC :-( http://trac.osgeo.org/grass/changeset/57291/grass/branches/releasebranch_6_4/configure.in There's a missing quote at the end of line 110. One thousand times lucky this was in a commented out part!! Hamish ps- curly brackets do not work for quoting strings or paths, only variable names. if used when not actually needed it fools students of the code into thinking that they will be safe to use instead of real quotes, and so the misconception breakage gets propagated on and on. This is especially important for things touching MS Windows where spaces in the path names are common and the future reader may not be a veteran Bourne coder. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] compilation error GRASS 7.0
Paulo wrote: Hi, in the last few revisions (including the latest, v57276), I am getting an error when compiling from source. The error seems to lie in the v.krige script, running make gives the following error: .. Running make in the v.krige folder and then rerun make on the main folder solves the problem but I though I report it anyway. Moritz: I can confirm this. I'll run the build process again to get a log. Hi, the trouble is known, the reason is that gui/wxpython/scripts/vkridge.py gets run at build time (either to get translation strings or check syntax, I'm not sure which), and it includes $GISBASE/etc/gui/wxpython into the PYTHONPATH. But it gets run before that exists and you get an error. Run it again later after that exists and it's fine. I think the solution is just a minor tweak to the parent Makefile so that it knows what dependency needs to be built first. Or migrate it into gui/wxpython/modules/ with the others, vkridge.py is alone in scripts/. Another approach would be to add another try,except into the python script and sys.exit() if it fails, as is done a few lines away. [the above is from memory educated guessing from when I first saw it in the ubuntu ppa failed nightly build report; may not be entirely accurate] Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] G6.4.2: gis.m issue on Ubuntu
MarkusN: I got a request from an Ubuntu user related to gis.m/tcltk/sqlite but have no idea how to help: On Tue, Jul 23, 2013 at 10:01 AM, wrote: I am trying to run Grass 6.4 following instructions in chapter 3 of your book using the nc_spm_08 downloaded from your site. I am using Ubuntu 12.10 64-bit, with Grass 6.4 installed from the Ubuntu Software Center, and with SQLite 3. I get this message when trying to run - gis.m GRASS 6.4.2 (nc_spm_08):~ gis.m GRASS 6.4.2 (nc_spm_08):~ error reading package index file /usr/lib/sqlite/pkgIndex.tcl: expected version number but got 0.0. The line in pkgIndex.tcl is: package ifneeded sqlite 0.0. [list load [file join $dir libtclsqlite.so.0] sqlite] How can this be fixed? Does anyone have a suggestion for this user? not really, /usr/lib/sqlite/pkgIndex.tcl comes from the libsqlite-tcl package, but that is not used or required by the grass package(s) AFAIK. I just tried GIS.m in an Lubuntu 13.04 VM and gis.m worked ok. I did get the same error message if I manually installed the libsqlite-tcl package (even with dbf as the db.connect default), but other than the message in the terminal gis.m seemed to work ok. So I'd guess an error in the other package and grass users can ignore it? ?, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] start grass with only initializing the environment
Rainer wrote:
I would therefore suggest an additional startup argument for grass,
which only sets the environmental variables, including library paths,
so that GRASS commands can be executed afterwards,
just make your own batch file or function(){} for /etc/bash.bashrc?
and if the LOCATION_NAME and MAPSET are not provided, they will be
null and *have to be set manualy afterwards*.
that doesn't sound like a practice we should promote.
what part of the start up are you trying to avoid? ('grass64 -text'
works in 6 too, or 'g.gui text' to avoid the gui at startup)
see also the usage for GRASS_BATCH_JOB, which basically does that in
a non-interactive environment.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.3 release planning
Markus Neteler wrote: Today could be a great rlease-6.4.3-day :) since on the 24th we are +2 weeks since RC4 without any major bugs being reported I think we are ok to release any time now. I don't know about anyone else but I can't say I've really tested rc4 very much beyond making sure the debian package building still works. too busy :-/ Luca: we are so close to 30 July that we could wait a week and release in the same day of his born :-) It would be a nice little something for the release announcement too. :) Speaking of which, do we want to write the formal release announcement + 2 paragraph abstract as we have for earlier releases in grass-web svn, or do something different now? I think we need something higher-level than the trac wiki's detailed changelog highlights, and that it should be done before release. I might try a first draft tomorrow if no one else has started on it. Also MarkusN's visual changelog idea is nice, the trac news items for the earlier RCs should give some ideas. anyone like to start on screenshots for that? maybe host/compose in the more thumbnail- friendly/prettier grass mediawiki? fyi the only bug I'm actively thinking on in 6.x is m.proj (and so r.in.wms) on WinGrass when the location uses a grid transform file. It fails due to a cs2cs quoting problem + spaces in $GISBASE/etc/ path to the NTv2 grid file. I've got it close to working in 6.5svn (but not quite) and can prototype it working on the command line in wingrass 6.4, but still it gives bad results from the script. Things are quite busy for me right now so unless someone else wants to help I think that can wait for the next train. It's listed in the rc4 errata and I think the next step is working on some known-good transforms of modern and pre-satellite era datum transforms into a new m.proj test_suite/ script. best, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] d.rast3d not launching on windows
Anna:
Unable to fetch interface description for command 'd.rast3d.py'.
...
Details: C:\OSGeo4W_dev\bin\python.exe: can't open file
'd.rast3d.py': [Errno 2] No such file or directory
[1] http://trac.osgeo.org/grass/changeset/57218
...
os.chdir(...)
Hamish:
the Unable to fetch interface description for command error is typically
because the g.parser script-handling module can not find the script that
called it in the system $PATH.
(error message happens in lib/python/script/task.py)
The os.chdir() solution may work on Windows since . is usually in
%PATH% there, but on Unix . is typically not in your path.
I think it's better remove the os.chdir()s and replace them by adding
$GISBASE/etc/gui/scripts/ to the PATH when the wxGUI first starts up.
Going into the grass7 wxGUI's Python shell tab, and import os,
os.getenv('PATH') shows the last entry as etc/gui/scripts/ already.
(tested on linux) :-/ so that might not be it.
Anna:
the command is launched with python executable:
.../python.exe d.rast3d.py
so it seems that it expects the full path to the script and
therefore chdir before it made it work.
$GISBASE/etc/gui/scripts/ is already on the PATH.
if etc/gui/scripts/ is already in the PATH why does cd make any
difference? perhaps it needs to be in PYTHONPATH instead? as you
describe the reason is the way it is called, using:
/path/to/python.exe script.py
since script.py is the argument it never goes near $PATH, but maybe
python still checks $PYTHONPATH ?
or if it is just called like:
/path/to/python.exe /path/to/script.py
then the cd wouldn't be needed any more.
note g.parser (at least in 6.x) removes all but the basename from
the original $0 for the second pass, IIRC.
So we can keep this solution until someone finds something better.
I'm not really worried about special cases to make d.rast3d work since
it's a private/internal script, but for other regular scripts if a cd
is done it's a bug: scripts which write out an output file would no
longer write them to the current directory the script was run from,
the files would either end up in scripts/ or get an error about no
permission to write to scripts/.
In line 540 of trunk/gui/wxpython/core/gcmd.py it seems that bug
exists. (i.e. for: d.polar db.out.ogr i.spectral m.proj r.in.wms
r.out.xyz r.pack v.out.gps v.pack, ...)
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] G6.4.2: gis.m issue on Ubuntu
User wrote: I am using Ubuntu 12.10 64-bit, with Grass 6.4 installed from the Ubuntu Software Center, and with SQLite 3. I get this message when trying to run - gis.m GRASS 6.4.2 (nc_spm_08):~ gis.m GRASS 6.4.2 (nc_spm_08):~ error reading package index file /usr/lib/sqlite/pkgIndex.tcl: expected version number but got 0.0. Hamish: /usr/lib/sqlite/pkgIndex.tcl comes from the libsqlite-tcl package, but that is not used or required by the grass package(s) AFAIK. I just tried GIS.m in an Lubuntu 13.04 VM and gis.m worked ok. I did get the same error message if I manually installed the libsqlite-tcl package ... So I'd guess an error in the other package and grass users can ignore it? Markus: I just received an update: The issue got fixed in Ubuntu 12.10 https://bugs.launchpad.net/ubuntu/+source/sqlite/+bug/996644 but the user reported it from 12.10, and I saw the same in 13.04. I think the seems to work in 12.10 in the ubuntu ticket was not correct, and the earlier debian bug it linked to was from 2009. So it was not a GRASS bug... good to know. Right, to be continued elsewhere.. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] grass-addons repository
Vaclav wrote: Hi, I wonder what is the right way to addons to the GRASS installation and how then handle this in GRASS. If addons are handled by the packaging system there is no point to handle these addons by g.extension (this is how it works now if I understood correctly). However, in this case addons are not listed in the Addons entry in the Module tree in the Search modules tab in layer manager, since currently only modules available during compilation (using generated XML) and modules in .grass7/addons (using g.extension -a) are added to this tree. for a grass-addon package from e.g. the UbuntuGIS ppa, I'd suggest to treat them as a distribution toolbox and so as any other new toolbox. Then leave it up to the user to avoid re-downloading with g.extension.py. I don't see much point in trying to maintain them in a addon xml registry; or rather I still have a hard time understanding how such a registry deals with the theoretical 50% of addon modules which are personal scripts authored by the user and not in the grass repository. And following that line of thought how a time-frozen selection of addon modules from a PPA should co-exist with both user scripts and live /or updated addon modules direct from svn. Given all that grey area the best I can suggest is to stay as flexible as possible, and so my concern with the xml registry is that it can be quite brittle and so fragile. :-/ but really I have no better idea to suggest. the self- assembling freedesktop.org *.desktop menus + icon files used by Gnome/ KDE/Xfce/LXDE is one way to do it, but having worked with that a bit making the custom menus for the osgeo live disc, I'd observe that it works, but their way is rather abstruse and not very enjoyable to code. You might also explore how GEM + gis.m organized this in GRASS 6 for some ideas. where does the ubuntu recipe install them on the disk now? I am sure it is possible, somehow.. :) regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] d.rast3d not launching on windows
Anna wrote:
I get this error when launching d.rast3d from layer manager
toolbar on Windows.
I fixed it in r57218 [1] but it I was wondering if there is
some better solution?
...
Traceback (most recent call last):
...
Unable to fetch interface description for command 'd.rast3d.py'.
...
[1] http://trac.osgeo.org/grass/changeset/57218
...
os.chdir(...)
Hi,
the Unable to fetch interface description for command error is typically
because the g.parser script-handling module can not find the script that
called it in the system $PATH.
(error message happens in lib/python/script/task.py)
The os.chdir() solution may work on Windows since . is usually in %PATH%
there, but on Unix . is typically not in your path.
I think it's better remove the os.chdir()s and replace them by adding
$GISBASE/etc/gui/scripts/ to the PATH when the wxGUI first starts up.
Going into the grass7 wxGUI's Python shell tab, and import os,
os.getenv('PATH') shows the last entry as etc/gui/scripts/ already.
(tested on linux) :-/ so that might not be it.
On linux the script is installed as d.rast3d without the .py, I guess
it keeps the .py extension on Windows? perhaps check how the script is called:
is e.g. 'd.rast3d.py' requested but 'd.rast3d' found?
Maybe etc/gui/scripts/ needs to be added to PYTHONPATH with
wxscripts = os.path.join(os.getenv('GISBASE'), 'etc', 'gui', 'scripts')
if wxbase not in sys.path:
sys.path.append(wxbase)
?
(probably won't help, but worth a try)
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] mapset permissions: only owner should have write permissions
Markus Metz wrote: In this case, would it be ok to enforce umask to 0022 in the start up script? two rules to thumb: we shouldn't restrict others to the limits of our own imagination. (if someone wants to set their umask to allow 777 for whatever reason or need, why not let them?) it's not broken == don't fix it ... my suggestion is just leave the thing alone. why make work for people? regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] mapset permissions: only owner should have write permissions
Hi, Markus M: From within GRASS, only the owner of a mapset is allowed to start a GRASS session in this mapset, i.e. only the owner of a mapset has write permissions to this mapset. But a new mapset being a folder in the file system is created with mode 0777, thus granting write permissions to all. I suggest to change mode from 0777 to 0755 in G_mkdir() and add mode = 0755 in gis_set.py. Any objections? It's not created as 777 (I would have noticed that :), that's before the umask. So for me it gets created as drwxr-xr-x, as expected. $ man 2 mkdir: The argument mode specifies the permissions to use. It is modified by the process's umask in the usual way: the permissions of the created directory are (mode ~umask 0777). Other mode bits of the created directory depend on the operating system. [...] NOTES Under Linux apart from the permission bits, only the S_ISVTX mode bit is honored. That is, under Linux the created directory actually gets mode (mode ~umask 01777). See also stat(2). Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS GIS 7 tech-preview release preparations
- LFS handling in Windows https://trac.osgeo.org/grass/ticket/1131 MarkusM: Global LFS is enabled by default and working on all officially supported platforms, plus *BSD and some UNIX systems. Moritz: That means we can close this ticket ? it depends: is LFS working in MS Windows? i.e. has it been tested with the latest trunk code and passed? We shouldn't close tickets on assumptions. thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] grass and planetary science
Yann wrote: GRASS 7 now automatically recognizes ISIS installation and sets its running mode to ISIS-GRASS... Thanks to Vaclav, Martin and MarkusN ! http://grasswiki.osgeo.org/wiki/Planetary_mapping#GIS_Support I am not sure that the startup script should, by default, change e.g. the GRASS banner logo depending on what else is running. To play devil's advocate, should the same be done for R or QGIS, SEXTANTE, OSSIM, or ... running in the background too? What if multiple are running? I would think it better to need a new CLI flag for that, for example: grass7 --isis to trigger the tests + integration. Also, could you put links in the grass wiki page to ISIS3 the homepage (currently the USGS site seems offline?), and to the GRASS-ISIS bridge? thanks, Hamish ps- I'd vote for the original less-bright text :) ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 7 r.neighbours average method giving incorrect value
Glynn: For average, median, variance, standard deviation and interspersion, the output should always be floating-point (although I'm not entirely certain about median). why not for median? is there any other way to deal with even number of values in the list? if value will often be 0.5 then round() isn't ideal.. It seems better to consistently say median will output DCELL than to say depending on the number of input maps, and the number of scattered NULLs at each grid cell, sometimes median will save the map as CELL if it can. or is there some other reason or way to deal with that? ?, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] matplotlib as a wxGUI dep [was: [SoC] Weekly report #3 - GRASS Interactive Scatter Plot Tool]
Michael wrote: Are you planning to use wxPlot for the scatterplot display? This provides a consistent graphical interface with the other plotting modules. Stepan: currently matplotlib [1] is used. The library provides events [2], which allows you to find out where the user clicked. With this information you are able to keep track of selected regions in a scatter plot. Michael: OK. I originally wanted to use matplotlib because it is a much richer environment, but it was nixed by the dev team because it added a new dependency. If we start using it, it will make numerous, powerful analytical functions accessible. Hi, fwiw I wouldn't mind matplotlib being around, since I already know the Matlab plotting commands very well, and matplotlib is not dissimilar. But I've been quiet on pushing that since I'm sure there are other things (java, C++, ruby, whatever) that other grass devs know well, but may not be generally in line with the project's needs. So +0 from me. I don't know much about PyPlot or how the wx profile tool is done, so I can't really comment on the pros and cons. Just that trunk/scripts/i.spectral/i.spectral.py would be a good test case (currently uses gnuplot or d.linegraph). Another idea is to replace the d.linegraph module with a python wrapper function, and d.histogram too. I would add that adding a dependency for the wxGUI is not adding the dependency to GRASS, since GRASS can be built and run without the wxGUI. 2c, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.3 release planning
MarkusN: Maybe fail message is better for 6.4.3 and then we (once in a decade) will have 6.4.4 shortly, i.e. less than 6 months? Once wxPython 2.10 is released and starts making it into distros, that will be a good motivation for us to release a 6.4.4 version of GRASS without waiting too long. :-) regards, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
