Re: [GRASS-dev] i.rectify still chokes on @mapset
On Wed, Apr 15, 2009 at 1:17 AM, Isaac Ullah iul...@asu.edu wrote: The error I get is like this: m...@mapset is not found in group map_group try using maps m...@mapset where my group is map_group, which contains only one map m...@mapset. I have now also tried 6.4.0svn on cmd line, no problem. But: This error comes after using both the tcltk and the wx georectifier when trying to do final georectififactaion after points are made, and is even replicated when i.rectify using from the original xy location after a correct points file is made. I am able to circumvent this error by specifying a map name in i.rectify, but stripping the @mapset. If I don't strip the @mapset, then same error occurs. I feel that the GUIs introduce the problem since it works on command line. For example: grep mapset gui/tcltk/gis.m/georect.tcl | grep -v '#' set cmd i.target group=$GRMap::xygroup location=$currloc mapset=$currmset -title [G_msg Select mapset of raster to georectify] \ Button $row.a -text [G_msg 1. Select mapset] \ Why $GRMap::xygroup ? suggestion: remove ::xygroup in both lines 292 and 294 in file etc/gm/georect.tcl from the i.target command and try again. I currently don't have the time to try the GUI based georectifier tools... perhaps taking off the mapset from the input helps? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #73: r.out.gdal tiff output does not work
#73: r.out.gdal tiff output does not work --+- Reporter: helena | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: critical | Milestone: 6.4.0 Component: Raster | Version: svn-trunk Resolution: |Keywords: r.out.gdal, tiff Platform: Unspecified | Cpu: Unspecified --+- Comment (by mmetz): Replying to [comment:31 mlennert]: Is this still an issue, or have Markus' patches solved the problem ? My patch only adds safety checks to make sure that the selected GDAL data type covers the range of the raster band to be exported and that the given null value is within the range of the selected GDAL data type. That would be an enhancement, not a bugfix. AFAICT, r.out.gdal as it is now (without the patch) can produce perfectly readable output, but it is possible to produce bogus output without these two safety checks. This is now a trade-off between code complexity and additional checks of user-specified options. I would opt to keep the code simple, also because the manual has been updated. In any case, it would be great if this ticket could be solved before the final release of 6.4. -- Ticket URL: http://trac.osgeo.org/grass/ticket/73#comment:32 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #73: r.out.gdal tiff output does not work
#73: r.out.gdal tiff output does not work --+- Reporter: helena | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: critical | Milestone: 6.4.0 Component: Raster | Version: svn-trunk Resolution: |Keywords: r.out.gdal, tiff Platform: Unspecified | Cpu: Unspecified --+- Comment (by mmetz): Replying to [comment:33 mlennert]: From the discussion, I gather that most of the problem is not a bug in r.out.gdal, but rather the incapacity of certain viewers to display certain types of data. Yes, that's one problem, but a problem of the viewers. Standard image viewers or editors like GIMP can only read type BYTE, and probably only 1 band or 3 bands in e.g. a tiff. Other types (e.g. INT16, FLOAT32) are not supported by these image viewers. Not sure about the number of bands. GIS software can usually both read, analyse, and visualize georeferenced raster data as produced by r.out.gdal. The tiff colortable problem is already solved. Some tests are in comment 13: http://trac.osgeo.org/grass/ticket/73#comment:13 -- Ticket URL: http://trac.osgeo.org/grass/ticket/73#comment:34 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #73: r.out.gdal tiff output does not work
#73: r.out.gdal tiff output does not work --+- Reporter: helena | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: critical | Milestone: 6.4.0 Component: Raster | Version: svn-trunk Resolution: |Keywords: r.out.gdal, tiff Platform: Unspecified | Cpu: Unspecified --+- Comment (by mmetz): Replying to [comment:35 mlennert]: Well, is this still an open bug then, or can we close it ? Or at least downgrade it so that it doesn't block 6.4 release ? Wait for feedback from Helena, Eric, Dylan, and Hamish before downgrading or closing the ticket ? -- Ticket URL: http://trac.osgeo.org/grass/ticket/73#comment:36 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #73: r.out.gdal tiff output does not work
#73: r.out.gdal tiff output does not work --+- Reporter: helena | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: critical | Milestone: 6.4.0 Component: Raster | Version: svn-trunk Resolution: |Keywords: r.out.gdal, tiff Platform: Unspecified | Cpu: Unspecified --+- Comment (by hamish): This was and is my main concern. MarkusM's patch could address this, I haven't run exaustive tests so don't know. Replying to [comment:20 hamish]: - oops, you are quite right. nodata must be set to something valid, otherwise the module doesn't know how to write out NULL values when it comes to them. It can't just skip them and nan is not an option for int maps. Thus, as you proposed, in the case where nodata= is out of range for the data type the module should exit with an error. I was just thinking of what to do for the metadata tag; not how the module would deal with NULL values. - if a Byte map has data 0-255 *and* NULL, it seems reasonable to me to default to nodata=255 + issue a warning. *But* if a map has 0-255 with *no* NULLs, nodata should not be set* to 255, as this would lead to a loss of fidelity. (improper removal of all cells with cat=255 for no gain) [*] ie should not be set, unless the user requests it explicitly with the nodata= opt sorry to be so thick, Hamish As for the other matter, I'm not worried if other software do not respect the GeoTiff spec, as long as we do. (it's all we have control over anyway) more in next post.. -- Ticket URL: http://trac.osgeo.org/grass/ticket/73#comment:37 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #536: memory corruption in vector modules
#536: memory corruption in vector modules --+- Reporter: martinl | Owner: grass-dev@lists.osgeo.org Type: defect | Status: reopened Priority: blocker | Milestone: 7.0.0 Component: Vector | Version: svn-trunk Resolution: |Keywords: Platform: Linux| Cpu: x86-32 --+- Changes (by hamish): * summary: memory corruption = memory corruption in vector modules -- Ticket URL: http://trac.osgeo.org/grass/ticket/536#comment:21 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #73: r.out.gdal tiff output does not work
#73: r.out.gdal tiff output does not work --+- Reporter: helena | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: critical | Milestone: 6.4.0 Component: Raster | Version: svn-trunk Resolution: |Keywords: r.out.gdal, tiff Platform: Unspecified | Cpu: Unspecified --+- Comment (by hamish): Replying to [comment:32 mmetz]: My patch only adds safety checks to make sure that the selected GDAL data type covers the range of the raster band to be exported and that the given null value is within the range of the selected GDAL data type. That would be an enhancement, not a bugfix. Pretend you are r.out.gdal iterating through the raster cells to output. You come across a NULL cell. You have to write down some value, and are completely constrained to options available in the output type. What do you write out? Overflow/wrap the type? type min? type max? well (as things were) whatever you do is going to be arbirtary, and thus could lead to data loss, which is grounds for a most serious blocker bug. also, because the manual has been updated. that is easily modified, so shouldn't stop us. In any case, it would be great if this ticket could be solved before the final release of 6.4. yup Hamish -- Ticket URL: http://trac.osgeo.org/grass/ticket/73#comment:38 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #73: r.out.gdal tiff output does not work
#73: r.out.gdal tiff output does not work --+- Reporter: helena | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: critical | Milestone: 6.4.0 Component: Raster | Version: svn-trunk Resolution: |Keywords: r.out.gdal, tiff Platform: Unspecified | Cpu: Unspecified --+- Comment (by mmetz): Replying to [comment:38 hamish]: Pretend you are r.out.gdal iterating through the raster cells to output. You come across a NULL cell. You have to write down some value, and are completely constrained to options available in the output type. What do you write out? Overflow/wrap the type? type min? type max? well (as things were) whatever you do is going to be arbirtary, and thus could lead to data loss, which is grounds for a most serious blocker bug. That would require an additional check that the nodata value is not present in the raster band to be exported. This is not too difficult. What would be more difficult is to select a nodata value that is not present in the raster band to be exported if type min and type max are present. Offhand, I can only think of a helper data structure (sorted heap/binary tree/hash table) where all raster values without duplicates are kept which can consume a lot of memory for large floating point rasters. This would also require two passes over each raster band, first investigating the values and selecting a proper nodata value, second replacing NULLs with this nodata value. Then, what to do if a user- specified nodata value is within the range of the selected GDAL data type but this value is present in the raster? Give a warning but let the user override the check, causing data loss? Sorry, I haven't thought about this problem of nodata value causing data loss, somehow left this to the user. Markus M -- Ticket URL: http://trac.osgeo.org/grass/ticket/73#comment:39 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #73: r.out.gdal tiff output does not work
#73: r.out.gdal tiff output does not work --+- Reporter: helena | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: critical | Milestone: 6.4.0 Component: Raster | Version: svn-trunk Resolution: |Keywords: r.out.gdal, tiff Platform: Unspecified | Cpu: Unspecified --+- Comment (by mlennert): Replying to [comment:34 mmetz]: Replying to [comment:33 mlennert]: From the discussion, I gather that most of the problem is not a bug in r.out.gdal, but rather the incapacity of certain viewers to display certain types of data. Yes, that's one problem, but a problem of the viewers. Standard image viewers or editors like GIMP can only read type BYTE, and probably only 1 band or 3 bands in e.g. a tiff. Other types (e.g. INT16, FLOAT32) are not supported by these image viewers. Not sure about the number of bands. GIS software can usually both read, analyse, and visualize georeferenced raster data as produced by r.out.gdal. The tiff colortable problem is already solved. Some tests are in comment 13: http://trac.osgeo.org/grass/ticket/73#comment:13 Well, is this still an open bug then, or can we close it ? Or at least downgrade it so that it doesn't block 6.4 release ? Moritz -- Ticket URL: http://trac.osgeo.org/grass/ticket/73#comment:35 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] r.terracost uploaded to grass-addons
Hi, If you need a faster module for computing shortest paths , I have uploaded a module called r.terracost in grass-addons. It runs Dijkstra algorithm, which is the standard algorithm for SP (all costs need to be non-negative). The user specifies the input and output grid, the grid of start points, and the number of tiles.If you give it numtiles=1, it runs the entire computation in memory. If numtiles1, it switches to an external version, where it computes on one tile at a time. This is efficient in the case the grid is large and does not fit in memory. To find the suggested number of tiles, runt it with flag -i. hope this is useful -Laura ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #475: r.stats: last bin always has a single cell
#475: r.stats: last bin always has a single cell ---+ Reporter: hamish| Owner: grass-dev@lists.osgeo.org Type: defect| Status: new Priority: critical | Milestone: 6.4.0 Component: Raster| Version: svn-develbranch6 Resolution:|Keywords: r.stats Platform: All | Cpu: All ---+ Comment (by hamish): request for help solving this critical bug: we are reporting bad statistical data from our core stats module. It is used by r.report, d.histogram, etc and on to users' work output. I'm horrified by this bug but unfamiliar with hash tables and don't know how to proceed with debugging. thanks, Hamish -- Ticket URL: http://trac.osgeo.org/grass/ticket/475#comment:3 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #73: r.out.gdal tiff output does not work
#73: r.out.gdal tiff output does not work --+- Reporter: helena | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: critical | Milestone: 6.4.0 Component: Raster | Version: svn-trunk Resolution: |Keywords: r.out.gdal, tiff Platform: Unspecified | Cpu: Unspecified --+- Comment (by mlennert): Replying to [comment:39 mmetz]: Sorry, I haven't thought about this problem of nodata value causing data loss, somehow left this to the user. And I think it should be. Just give a big fat warning in the man page, and possibly as output of the module saying which value is used for null data and that if there are non-null pixels which have the value given as nodata value, then you will lose the information contained in them. Moritz -- Ticket URL: http://trac.osgeo.org/grass/ticket/73#comment:40 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] i.rectify still chokes on @mapset
On Apr 15, 2009, at 12:10 AM, Markus Neteler wrote: grep mapset gui/tcltk/gis.m/georect.tcl | grep -v '#' set cmd i.target group=$GRMap::xygroup location=$currloc mapset=$currmset -title [G_msg Select mapset of raster to georectify] \ Button $row.a -text [G_msg 1. Select mapset] \ Why $GRMap::xygroup ? This calls a variable (xygroup) that identifies the group file. I think I see what the problem is, and I still don't think it is the GUI, especially be cause it causes a problem in both TclTk and wxPython. Sometime (recently??), i.rectify has been changed so that it now accepts map names as input; it used to only accept a group as input. The TclTk and wxPython GUI's only send a group to i.rectify, not a map or list of maps. Isaac, take a look at the relevant group file and see if it has the mapsets appended to the map names AND see if it has incorrect information like mapsets appended twice. Then run i.rectfy with group input, not map input. Also, try i.rectify with a map input that does use @mapset. I'm betting that it chokes on the first at least and either i.group is making the group wrong or i.rectify has trouble with groups in which the @mapset is part of the group name. A more general question Markus (or others) is which direction is i.rectify going now: inputting groups or just inputting maps? There has been off and on discussion about groups that I've only partly followed. I seem to remember that subgroups are now gone. It would simplify the GUI work some if we could skip the group creation and just rectify a map or list of maps. The group is there to rectify a batch of multiband imagery files. Is this still the way to go? Maybe we could just leave the more sophisticated way of running i.rectify (e.g., on groups) to the module itself and not worry about implementing groups in the GUI. Michael ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] what dependencies does GRASS actually need to run?
It would be useful to know for binary installations which dependencies that GRASS actually needs to *run* as a binary (i.e., not dependencies needed to compile). AFAICT, it must have PROJ and PROJ requires GDAL (though I don't think GRASS requires GDAL) Some other dependencies may be for specific I/O Anything else it needs just to run if is is already a compiled binary? Michael C. Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution Social Change Center for Social Dynamics Complexity Arizona State University Phone: 480-965-6262 Fax: 480-965-7671 www: www.public.asu.edu/~cmbarton ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [SoC] Proposal for wxGUI layout modifications
it is nice to keep a module gui open so you can tweak one parameter and run it again. it is nice to keep a couple open and switch between them if you are doing something on a multi-processor machine (if doing so within a single mapset, at your own responsibility and risk that the computation region etc is not changed of course :) for that reason you might want to have e.g. 3 r.in.xyz's running at the same time, each crunching along on a different statistical method. This is something that I do a lot and is extremely valuable when simultaneously bulk processing multiple return Lidar data for different statistics. Please keep this feature of the gui! Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of Interior. Life is too short for undocumented, proprietary data formats. Hamish hamis...@yahoo.c omTo Sent by: Martin Landa grass-dev-bounces landa.mar...@gmail.com, Michael @lists.osgeo.org Barton michael.bar...@asu.edu cc grass-dev@lists.osgeo.org, 04/14/2009 11:31 s...@lists.osgeo.org PMSubject [GRASS-dev] Re: [SoC] Proposal for wxGUI layout modifications Michael Barton wrote: Actually, I think what (I hope) was envisioned was not a true MDI--which has lost considerable popularity--but attaching the layer manager to the display window. Ideally, this could be done by docking or undocking. That said, Markus and I had some offline discussions about this since he was the proposer, in response to some user comments and his own experiences. The main complaint is having too many windows open in GRASS. After some talking about it, the real problem may not lie primarily with the layer manager/display windows but with all the module windows which a lot of people don't realize that you can set to close automatically when you push OK. Some possible solutions to this would include having all modules open in a single window with tabs or modally in a single window or modally in a window attached to the layer manager to keep down clutter. By focusing a bit much on the initial display configuration of a couple of other GIS programs (ArcGIS and QGIS, but not in a lot of others by the way), we may have missed the real cause of the perceived screen clutter. Anyway, it's something to think about. [we should probably move this to the grass-dev ML] Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev inline: graycol.gifinline: pic16105.gifinline: ecblank.gif___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] what dependencies does GRASS actually need to run?
On 15/04/09 17:13, Michael Barton wrote: It would be useful to know for binary installations which dependencies that GRASS actually needs to *run* as a binary (i.e., not dependencies needed to compile). AFAICT, it must have PROJ and PROJ requires GDAL (though I don't think GRASS requires GDAL) r.*.gdal, v.*.ogr require GDAL... Some other dependencies may be for specific I/O Anything else it needs just to run if is is already a compiled binary? Well, that kind of depends on how you compile it, i.e. the configure statement before compilation. AFAIK, most libraries used in GRASS (including the system libraries) are used as dynamic libraries, so you need those. It also depends on what parts of GRASS you want to use, as, for example, the gdal example shows. nviz has specific requirements and so do some other modules. As an example, check the required packages for the installation of the GRASS Debian package: http://packages.debian.org/lenny/grass Not all of these packages are actually required to run the grass binary, as long as you don't use all of the modules. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] i.rectify still chokes on @mapset
On 15/04/09 17:04, Michael Barton wrote: Sometime (recently??), i.rectify has been changed so that it now accepts map names as input; it used to only accept a group as input. The TclTk and wxPython GUI's only send a group to i.rectify, not a map or list of maps. Where do you see this ? If you mean the input= option, then this has been there ever since 6.0, and it is not required, whereas group= is. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [SoC] Proposal for wxGUI layout modifications
On Apr 15, 2009, at 8:21 AM, doug_newc...@fws.gov> wrote: >it is nice to keep a module gui open so you can tweak one parameter and >run it again. it is nice to keep a couple open and switch between them >if you are doing something on a multi-processor machine (if doing so >within a single mapset, at your own responsibility and risk that the >computation region etc is not changed of course :) for that reason you >might want to have e.g. 3 r.in.xyz's running at the same time, each >crunching along on a different statistical method. This is something that I do a lot and is extremely valuable when simultaneously bulk processing multiple return Lidar data for different statistics. Please keep this feature of the gui!Which feature?__C. Michael Barton,Professor of AnthropologyDirector of Graduate StudiesSchool of Human Evolution Social ChangeCenter for Social Dynamics ComplexityArizona State UniversityTempe, AZ85287-2402USAvoice: 480-965-6262; fax: 480-965-7671www: http://www.public.asu.edu/~cmbarton Doug Doug Newcomb USFWS Raleigh, NC 919-856-4520 ext. 14 doug_newc...@fws.gov - The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of Interior. Life is too short for undocumented, proprietary data formats. graycol.gif>Hamish hamis...@yahoo.com>Hamish hamis...@yahoo.com> Sent by: grass-dev-boun...@lists.osgeo.org 04/14/2009 11:31 PM ecblank.gif> Toecblank.gif> Martin Landa landa.mar...@gmail.com>, Michael Barton michael.bar...@asu.edu> ecblank.gif> ccecblank.gif> grass-dev@lists.osgeo.org, s...@lists.osgeo.org ecblank.gif> Subjectecblank.gif> [GRASS-dev] Re: [SoC] Proposal for wxGUI layout modifications ecblank.gif>ecblank.gif> Michael Barton wrote: > Actually, I think what (I hope) was > envisioned was not a true MDI--which has lost considerable > popularity--but attaching the layer manager to the display > window. Ideally, this could be done by docking or > undocking. > > That said, Markus and I had some offline discussions about > this since he was the proposer, in response to some user > comments and his own experiences. The main complaint is > having too many windows open in GRASS. > > After some talking about it, the real problem may not lie > primarily with the layer manager/display windows but with > all the module windows which a lot of people don't realize > that you can set to close automatically when you push OK. > Some possible solutions to this would include having all > modules open in a single window with tabs or modally in a > single window or modally in a window attached to the layer > manager to keep down clutter. By focusing a bit much on the > initial display configuration of a couple of other GIS > programs (ArcGIS and QGIS, but not in a lot of others by the > way), we may have missed the real cause of the perceived > screen clutter. Anyway, it's something to think about. [we should probably move this to the grass-dev ML]Hamish___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev inline: pic16105.gif___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] what dependencies does GRASS actually need to run?
Thanks Moritz, This is the kind of information I was trying to get at. Trying to get a feel for what is really necessary to make an installable binary on Mac and Windows. Michael __ C. Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution Social Change Center for Social Dynamics Complexity Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262; fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton On Apr 15, 2009, at 9:58 AM, Moritz Lennert wrote: On 15/04/09 18:40, Michael Barton wrote: On Apr 15, 2009, at 8:40 AM, Moritz Lennert wrote: On 15/04/09 17:13, Michael Barton wrote: It would be useful to know for binary installations which dependencies that GRASS actually needs to *run* as a binary (i.e., not dependencies needed to compile). AFAICT, it must have PROJ and PROJ requires GDAL (though I don't think GRASS requires GDAL) r.*.gdal, v.*.ogr require GDAL... I thought that GRASS now compiles its own r.out.gdal and r.in.gdal and so doesn't need GDAL for these. It doesn't need the GDAL binary tools (gdal_translate, etc), but it still needs the GDAL libaries which is what r.out.gdal is based on. I don't know about v.*.ogr ditto. Some other dependencies may be for specific I/O Anything else it needs just to run if is is already a compiled binary? Well, that kind of depends on how you compile it, i.e. the configure statement before compilation. Even if you compile with libtif do you need to have libtif to run? On Windows? On Mac? You can use libraries in a static or in a dynamic way. If you use them statically, then all of the library is compiled into your executable, making it easy to install without many dependencies, but often making it fairly big, especially since your dependencies might depend on something else and so on. And you have to do the same for all programs, even if they use the same libaries (e.g. GDAL for GRASS, QGIS, etc, etc) So, generally, the choice is to compile with dynamic libraries, meaning that the executable finds the relevant command in the libary binary during execution. This allows different programs to share one version of the library, which reduces size, but can lead to dependency issues, especially if you compile against a different version of the library than the one you use for running the program. AFAIK, most libraries used in GRASS (including the system libraries) are used as dynamic libraries, so you need those. It also depends on what parts of GRASS you want to use, as, for example, the gdal example shows. nviz has specific requirements and so do some other modules. As an example, check the required packages for the installation of the GRASS Debian package: http://packages.debian.org/lenny/grass Not all of these packages are actually required to run the grass binary, as long as you don't use all of the modules. This is what I'm asking about. What is a minimal set of dependencies to do most things? Define most things ;-) You definitely will need libc, I guess proj, don't know about zlib. Don't know if you could create a working GRASS installation (working, but stripped down in its functionality) with just those... If you want some sort of output, you probably need libnpng. But I'll leave this to the experts. Glynn ? Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] i.rectify still chokes on @mapset
On Wed, Apr 15, 2009 at 5:04 PM, Michael Barton michael.bar...@asu.edu wrote: On Apr 15, 2009, at 12:10 AM, Markus Neteler wrote: grep mapset gui/tcltk/gis.m/georect.tcl | grep -v '#' set cmd i.target group=$GRMap::xygroup location=$currloc mapset=$currmset -title [G_msg Select mapset of raster to georectify] \ Button $row.a -text [G_msg 1. Select mapset] \ Why $GRMap::xygroup ? This calls a variable (xygroup) that identifies the group file. I think I see what the problem is, and I still don't think it is the GUI, especially be cause it causes a problem in both TclTk and wxPython. Sometime (recently??), i.rectify has been changed so that it now accepts map names as input; it used to only accept a group as input. The TclTk and wxPython GUI's only send a group to i.rectify, not a map or list of maps. i.rectify was changed to use G_parser() in June 2008. I didn't check in detail but the interface is as before. Isaac, take a look at the relevant group file and see if it has the mapsets appended to the map names AND see if it has incorrect information like mapsets appended twice. Then run i.rectfy with group input, not map input. Also, try i.rectify with a map input that does use @mapset. I'm betting that it chokes on the first at least and either i.group is making the group wrong or i.rectify has trouble with groups in which the @mapset is part of the group name. A more general question Markus (or others) is which direction is i.rectify going now: inputting groups or just inputting maps? There has been off and on discussion about groups that I've only partly followed. Mhh, personally I don't recall any discussion. Why changes? we cannot, at least in the GRASS 6 version. I seem to remember that subgroups are now gone. They are pretty alive :) It would simplify the GUI work some if we could skip the group creation and just rectify a map or list of maps. The group is there to rectify a batch of multiband imagery files. Is this still the way to go? Maybe we could just leave the more sophisticated way of running i.rectify (e.g., on groups) to the module itself and not worry about implementing groups in the GUI. I am not sure but there should be no interface differences between 6.0 and 6.4. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] i.rectify still chokes on @mapset
On Wed, Apr 15, 2009 at 7:12 PM, Isaac Ullah iul...@asu.edu wrote: To clarify, the error is exactly this: i.rectify group=central_hasa_square_60...@permanent input=central_hasa_square_60_6...@permanent extension=rectify_test order=1 Input raster map central_hasa_square_60_6...@permanent does not exist in group central_hasa_square_60...@permanent. Try: central_hasa_square_60_69.1 central_hasa_square_60_69.alpha Exit! three questions: - in which mapset are you currently? (g.gisenv) - does the group really exist? (g.list group) - please post the content of the group file Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] what dependencies does GRASS actually need to run?
OSX generally uses dynamic libraries. There are a few static libraries available, but frameworks are *always* dynamic. Any (dynamic) libraries used from the system will always be available on all Mac systems of the same version, so there is no need to worry about those as requirements for the end user to worry about. For OSX, everything in the General Requirements (REQUIREMENTS.html), except GDAL and PROJ, is available in the system (though X11 is an optional install for OSX). So, you could get a basic functional CLI/ X11-based (no GUIs, a few missing/nonfunctional modules) GRASS with only GDAL and PROJ. Many of the optional requirements are not available in the OSX system and others are quite old, and must be installed separately. When you build the OSX application, you can bundle extra libraries in the application, so the user doesn't have to worry about downloading and installing them - this is what I do for my binaries, except that the frameworks are separate installs. Add install commands to macosx/ pkg/bundle.make and use make bindist to generate a bundled application and installer. On Apr 15, 2009, at 12:06 PM, Michael Barton wrote: Thanks Moritz, This is the kind of information I was trying to get at. Trying to get a feel for what is really necessary to make an installable binary on Mac and Windows. Michael __ C. Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution Social Change Center for Social Dynamics Complexity Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262; fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton On Apr 15, 2009, at 9:58 AM, Moritz Lennert wrote: On 15/04/09 18:40, Michael Barton wrote: On Apr 15, 2009, at 8:40 AM, Moritz Lennert wrote: On 15/04/09 17:13, Michael Barton wrote: It would be useful to know for binary installations which dependencies that GRASS actually needs to *run* as a binary (i.e., not dependencies needed to compile). AFAICT, it must have PROJ and PROJ requires GDAL (though I don't think GRASS requires GDAL) r.*.gdal, v.*.ogr require GDAL... I thought that GRASS now compiles its own r.out.gdal and r.in.gdal and so doesn't need GDAL for these. It doesn't need the GDAL binary tools (gdal_translate, etc), but it still needs the GDAL libaries which is what r.out.gdal is based on. I don't know about v.*.ogr ditto. Some other dependencies may be for specific I/O Anything else it needs just to run if is is already a compiled binary? Well, that kind of depends on how you compile it, i.e. the configure statement before compilation. Even if you compile with libtif do you need to have libtif to run? On Windows? On Mac? You can use libraries in a static or in a dynamic way. If you use them statically, then all of the library is compiled into your executable, making it easy to install without many dependencies, but often making it fairly big, especially since your dependencies might depend on something else and so on. And you have to do the same for all programs, even if they use the same libaries (e.g. GDAL for GRASS, QGIS, etc, etc) So, generally, the choice is to compile with dynamic libraries, meaning that the executable finds the relevant command in the libary binary during execution. This allows different programs to share one version of the library, which reduces size, but can lead to dependency issues, especially if you compile against a different version of the library than the one you use for running the program. AFAIK, most libraries used in GRASS (including the system libraries) are used as dynamic libraries, so you need those. It also depends on what parts of GRASS you want to use, as, for example, the gdal example shows. nviz has specific requirements and so do some other modules. As an example, check the required packages for the installation of the GRASS Debian package: http://packages.debian.org/lenny/grass Not all of these packages are actually required to run the grass binary, as long as you don't use all of the modules. This is what I'm asking about. What is a minimal set of dependencies to do most things? Define most things ;-) You definitely will need libc, I guess proj, don't know about zlib. Don't know if you could create a working GRASS installation (working, but stripped down in its functionality) with just those... If you want some sort of output, you probably need libnpng. But I'll leave this to the experts. Glynn ? Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ The beast is actively interested only in now, and, as it is always now and always shall be, there is an eternity of time for the accomplishment of
Re: [GRASS-dev] Re: [GRASS GIS] #73: r.out.gdal tiff output does not work
On 15/04/09 19:22, Dylan Beaudette wrote: On Wednesday 15 April 2009, GRASS GIS wrote: #73: r.out.gdal tiff output does not work --+ - Reporter: helena | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: critical | Milestone: 6.4.0 Component: Raster | Version: svn-trunk Resolution: |Keywords: r.out.gdal, tiff Platform: Unspecified | Cpu: Unspecified --+ - Comment (by hamish): Replying to [comment:32 mmetz]: My patch only adds safety checks to make sure that the selected GDAL data type covers the range of the raster band to be exported and that the given null value is within the range of the selected GDAL data type. That would be an enhancement, not a bugfix. Pretend you are r.out.gdal iterating through the raster cells to output. You come across a NULL cell. You have to write down some value, and are completely constrained to options available in the output type. What do you write out? Overflow/wrap the type? type min? type max? well (as things were) whatever you do is going to be arbirtary, and thus could lead to data loss, which is grounds for a most serious blocker bug. I haven't thought a great deal about this, but from what I have been reading and recalling past messages on the GDAL mailing list-- there just aren't any general approaches to preserving NULL values in a geotiff when you need the entire range of a given datatype to represent your information. I think that several things can be done to address this bug, some of which have been mentioned: 1. if there are any NULL cells, warn the user- possibly refuse to export the image in the current format (BYTE, etc.) 1a. if the selected output format cannot contain the entire range, or precision, of input map data (input is FCELL, output is BYTE) give a warning or fail with error message. 2. include a 'force' option to make r.out.gdal do exactly what your command line instructions suggest-- possibly leading to corruption of NULL data 3. Allow the user to specify what they would like NULL cells encoded as. Unless I am overlooking something, it would seem reasonable to export a CELL map to a signed integer format, and use some obvious negative value for NULL: # assuming that all REAL data is within 0-255 r.out.gdal in=CELLMAP out=map.tif format=SIGNEDINT null=-1 also, because the manual has been updated. that is easily modified, so shouldn't stop us. In any case, it would be great if this ticket could be solved before the final release of 6.4. yup I would like to see the above changes, however I cannot actually implement them. Thanks to everyone who has been working on this important module. AFAIK, except for number 1, all are implemented already. Currently there is an error if the null value does not fit into the data range of the selected output file type, but not if the selected value for null data is present in the data as a valid value. But as Markus explained, checking for this would be quite intense, so IMHO a warning that there are null values and that there is the possibility of loosing information if the user does not watch out should be enough. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] i.rectify still chokes on @mapset
On 15/04/09 19:14, Markus Neteler wrote:
On Wed, Apr 15, 2009 at 7:12 PM, Isaac Ullah iul...@asu.edu wrote:
To clarify, the error is exactly this:
i.rectify group=central_hasa_square_60...@permanent
input=central_hasa_square_60_6...@permanent extension=rectify_test order=1
Input raster map central_hasa_square_60_6...@permanent does not exist in
group central_hasa_square_60...@permanent.
Try:
central_hasa_square_60_69.1
central_hasa_square_60_69.alpha
Exit!
three questions:
- in which mapset are you currently? (g.gisenv)
- does the group really exist? (g.list group)
- please post the content of the group file
As the message says, the group file contains
central_hasa_square_60_69.1, but not
central_hasa_square_60_6...@permanent. I would guess that the problem is
in line 166 of imagery/i.rectify/main.c (ref to trunk) where you have
if (strcmp(ifile-answers[m], ref.file[n].name) == 0) {
without stripping the @mapset from the file name and so the comparison
with the files in the group fails.
Don't know how this is handled elsewhere, but should be fairly trivial
to correct, I would guess.
Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS GIS] #73: r.out.gdal tiff output does not work
On Wednesday 15 April 2009, Moritz Lennert wrote: On 15/04/09 19:22, Dylan Beaudette wrote: On Wednesday 15 April 2009, GRASS GIS wrote: #73: r.out.gdal tiff output does not work --+- --- - Reporter: helena | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: critical | Milestone: 6.4.0 Component: Raster | Version: svn-trunk Resolution: |Keywords: r.out.gdal, tiff Platform: Unspecified | Cpu: Unspecified --+- --- - Comment (by hamish): Replying to [comment:32 mmetz]: My patch only adds safety checks to make sure that the selected GDAL data type covers the range of the raster band to be exported and that the given null value is within the range of the selected GDAL data type. That would be an enhancement, not a bugfix. Pretend you are r.out.gdal iterating through the raster cells to output. You come across a NULL cell. You have to write down some value, and are completely constrained to options available in the output type. What do you write out? Overflow/wrap the type? type min? type max? well (as things were) whatever you do is going to be arbirtary, and thus could lead to data loss, which is grounds for a most serious blocker bug. I haven't thought a great deal about this, but from what I have been reading and recalling past messages on the GDAL mailing list-- there just aren't any general approaches to preserving NULL values in a geotiff when you need the entire range of a given datatype to represent your information. I think that several things can be done to address this bug, some of which have been mentioned: 1. if there are any NULL cells, warn the user- possibly refuse to export the image in the current format (BYTE, etc.) 1a. if the selected output format cannot contain the entire range, or precision, of input map data (input is FCELL, output is BYTE) give a warning or fail with error message. 2. include a 'force' option to make r.out.gdal do exactly what your command line instructions suggest-- possibly leading to corruption of NULL data 3. Allow the user to specify what they would like NULL cells encoded as. Unless I am overlooking something, it would seem reasonable to export a CELL map to a signed integer format, and use some obvious negative value for NULL: # assuming that all REAL data is within 0-255 r.out.gdal in=CELLMAP out=map.tif format=SIGNEDINT null=-1 also, because the manual has been updated. that is easily modified, so shouldn't stop us. In any case, it would be great if this ticket could be solved before the final release of 6.4. yup I would like to see the above changes, however I cannot actually implement them. Thanks to everyone who has been working on this important module. AFAIK, except for number 1, all are implemented already. Currently there is an error if the null value does not fit into the data range of the selected output file type, but not if the selected value for null data is present in the data as a valid value. But as Markus explained, checking for this would be quite intense, so IMHO a warning that there are null values and that there is the possibility of loosing information if the user does not watch out should be enough. Moritz Thanks for the notice on 2-3. Your approach sounds good to me. Cheers, Dylan -- Dylan Beaudette Soil Resource Laboratory http://casoilresource.lawr.ucdavis.edu/ University of California at Davis 530.754.7341 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #73: r.out.gdal tiff output does not work
#73: r.out.gdal tiff output does not work --+- Reporter: helena | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: critical | Milestone: 6.4.0 Component: Raster | Version: svn-trunk Resolution: |Keywords: r.out.gdal, tiff Platform: Unspecified | Cpu: Unspecified --+- Comment (by helena): as for me - I did not file it as critical, because I thought it was partially problem on my side (not using the correct options) - it was upgraded to critical later. I think we just need to keep around r.out.arc, r.out.tiff in case the software that you are trying to import the data to does not like the r.out.gdal geotiff as we cannot really solve other software issues with geotiff. I also agree that the warning about possible loss of data with badly chosen NULL as suggested by Moritz should take care of the null problem. All I really tried to do was convert the nc_spm raster data into something readable by other software tools and r.out.gdal worked but some rasters were not readable or came out black so it required change in color table etc. (e.g., in ArcGIS, gimp). We ended up using r.out.arc - and lost the color tables and projection info but otherwise it worked fine. I haven't tried the very latest version of r.out.gdal though. Helena -- Ticket URL: http://trac.osgeo.org/grass/ticket/73#comment:42 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #73: r.out.gdal tiff output does not work
#73: r.out.gdal tiff output does not work --+- Reporter: helena | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: critical | Milestone: 6.4.0 Component: Raster | Version: svn-trunk Resolution: |Keywords: r.out.gdal, tiff Platform: Unspecified | Cpu: Unspecified --+- Comment (by mlennert): Replying to [comment:42 helena]: All I really tried to do was convert the nc_spm raster data into something readable by other software tools and r.out.gdal worked but some rasters were not readable or came out black so it required change in color table etc. (e.g., in ArcGIS, gimp). We ended up using r.out.arc - and lost the color tables and projection info but otherwise it worked fine. Just out of curiosity: how is losing color table and projection info (r.out.arc) better than just a lost color table (r.out.gdal) ? Moritz -- Ticket URL: http://trac.osgeo.org/grass/ticket/73#comment:43 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS GIS] #73: r.out.gdal tiff output does not work
Moritz Lennert wrote: On 15/04/09 19:22, Dylan Beaudette wrote: On Wednesday 15 April 2009, GRASS GIS wrote: #73: r.out.gdal tiff output does not work --+ - Reporter: helena | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: critical | Milestone: 6.4.0 Component: Raster | Version: svn-trunk Resolution: |Keywords: r.out.gdal, tiff Platform: Unspecified | Cpu: Unspecified --+ - Comment (by hamish): Replying to [comment:32 mmetz]: My patch only adds safety checks to make sure that the selected GDAL data type covers the range of the raster band to be exported and that the given null value is within the range of the selected GDAL data type. That would be an enhancement, not a bugfix. Pretend you are r.out.gdal iterating through the raster cells to output. You come across a NULL cell. You have to write down some value, and are completely constrained to options available in the output type. What do you write out? Overflow/wrap the type? type min? type max? well (as things were) whatever you do is going to be arbirtary, and thus could lead to data loss, which is grounds for a most serious blocker bug. I haven't thought a great deal about this, but from what I have been reading and recalling past messages on the GDAL mailing list-- there just aren't any general approaches to preserving NULL values in a geotiff when you need the entire range of a given datatype to represent your information. I think that several things can be done to address this bug, some of which have been mentioned: 1. if there are any NULL cells, warn the user- possibly refuse to export the image in the current format (BYTE, etc.) 1a. if the selected output format cannot contain the entire range, or precision, of input map data (input is FCELL, output is BYTE) give a warning or fail with error message. 2. include a 'force' option to make r.out.gdal do exactly what your command line instructions suggest-- possibly leading to corruption of NULL data 3. Allow the user to specify what they would like NULL cells encoded as. Unless I am overlooking something, it would seem reasonable to export a CELL map to a signed integer format, and use some obvious negative value for NULL: # assuming that all REAL data is within 0-255 r.out.gdal in=CELLMAP out=map.tif format=SIGNEDINT null=-1 also, because the manual has been updated. that is easily modified, so shouldn't stop us. In any case, it would be great if this ticket could be solved before the final release of 6.4. yup I would like to see the above changes, however I cannot actually implement them. Thanks to everyone who has been working on this important module. AFAIK, except for number 1, all are implemented already. Currently there is an error if the null value does not fit into the data range of the selected output file type, but not if the selected value for null data is present in the data as a valid value. But as Markus explained, checking for this would be quite intense, so IMHO a warning that there are null values and that there is the possibility of loosing information if the user does not watch out should be enough. 1. warn the user only if no nodata value is given, otherwise (nodata value was given) assume that the user knows what she/he is doing? 1a. only in the patch which is not submitted, and no precision test. 2. suggested but nowhere implemented. why should we have a force option to override all the requested but not yet present safety checks? 3. was always possible I THINK calculating a reasonable nodata value is both time and memory expensive, maybe there is some ingenious way to avoid memory costs, but I'm pretty sure that two passes for each raster band are necessary, i.e. time intensive. r.out.gdal selects a file format, a suitable data type and a default nodata value if none of them were given, but that's more of a guess, and the user should know best what file format, data type and nodata value is appropriate. It gets all a bit more complicated because r.out.gdal can export several raster maps into one single file if supported by the selected file format. Therefore I would prefer some simple tests and abort with a helpful message if something goes wrong instead of doing fancy automated guessing that would make the code much more complex and thus more difficult to maintain. r.out.gdal supports all raster formats supported by gdal, and that's a lot, becoming more with every new version of gdal. IMHO, r.out.gdal should check if input options would cause corrupted output and otherwise refer to the gdal documentation. I'm busy working on an update for r.out.gdal and should be able to submit to trunk tomorrow. Changes are range-check
[GRASS-dev] Re: [GRASS GIS] #73: r.out.gdal tiff output does not work
On Wed, 2009-04-15 at 18:30 +, GRASS GIS wrote: #73: r.out.gdal tiff output does not work --+- Reporter: helena | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: critical | Milestone: 6.4.0 Component: Raster | Version: svn-trunk Resolution: |Keywords: r.out.gdal, tiff Platform: Unspecified | Cpu: Unspecified --+- Comment (by mlennert): Replying to [comment:42 helena]: All I really tried to do was convert the nc_spm raster data into something readable by other software tools and r.out.gdal worked but some rasters were not readable or came out black so it required change in color table etc. (e.g., in ArcGIS, gimp). We ended up using r.out.arc - and lost the color tables and projection info but otherwise it worked fine. Just out of curiosity: how is losing color table and projection info (r.out.arc) better than just a lost color table (r.out.gdal) ? the file produced by r.in.arc displayed OK right away with Arc default table so people who got the file were able to work with it although they did not get the same colors as were assigned in GRASS. The r.out.gdal result displayed black and unless you knew what was going on and how to change the table it was difficult to deal with - the file just looked broken because it would display black in other viewers too. This might have been fixed though, I just cannot get around to test it, Helena Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] what dependencies does GRASS actually need to run?
Moritz Lennert wrote: This is what I'm asking about. What is a minimal set of dependencies to do most things? Define most things ;-) You definitely will need libc, I guess proj, don't know about zlib. Don't know if you could create a working GRASS installation (working, but stripped down in its functionality) with just those... If you want some sort of output, you probably need libnpng. But I'll leave this to the experts. Glynn ? libgis (and thus all of GRASS) requires zlib. If you use --without-opengl, --without-x11, --without-wxwidgets and --without-tcltk, that eliminates a lot of dependencies at the expense of NVIZ, vdigit, xganim, and ximgview. For the GUI, wxPython will need some of those libraries, but you aren't hard-coding dependencies on specific versions into the package. If you still want NVIZ, building --without-ffmpeg may significantly reduce the number of dependencies. Building --without-cairo gets rid of a few more, as does --without-blas/lapack and --without-fftw (both of these add dependencies to the gmath library, which is used by ~34 modules). The PNG driver can be built --without-png; the GUI only needs PNM output, which doesn't require any libraries. Once you've done all of that, you're left with PROJ, GDAL, and whatever libraries GDAL requires. The main issue is that GDAL can require an almost open-ended set of libraries, depending upon which options it was built with. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS GIS] #73: r.out.gdal tiff output does not work
Dylan Beaudette wrote: 3. Allow the user to specify what they would like NULL cells encoded as. Unless I am overlooking something, it would seem reasonable to export a CELL map to a signed integer format, and use some obvious negative value for NULL: If you're exporting to a 32-bit (signed or unsigned) integer format, the obvious choice for null is 0x8000. That's what GRASS uses internally, so it can never occur as a legitimate value (if a computation ends up producing that value, it will get treated as a null in all regards). -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS GIS] #73: r.out.gdal tiff output does not work
On Wednesday 15 April 2009, Glynn Clements wrote: Dylan Beaudette wrote: 3. Allow the user to specify what they would like NULL cells encoded as. Unless I am overlooking something, it would seem reasonable to export a CELL map to a signed integer format, and use some obvious negative value for NULL: If you're exporting to a 32-bit (signed or unsigned) integer format, the obvious choice for null is 0x8000. That's what GRASS uses internally, so it can never occur as a legitimate value (if a computation ends up producing that value, it will get treated as a null in all regards). Thanks Glynn. It would be good to know about 'obvious' values for any given datatype. Cheers, Dylan -- Dylan Beaudette Soil Resource Laboratory http://casoilresource.lawr.ucdavis.edu/ University of California at Davis 530.754.7341 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] v.net.visibility memory leak? - was Re: [GRASS-user] traveling salesman problem in air
(moving to grass-dev) [Martina - we need to investigate a bit] On Wed, Apr 15, 2009 at 10:42 PM, Martina Schäfer martina.scha...@ebc.uu.se wrote: Interesting discussion!! I've created the centroids but unfortunately, the visibility network module repeatedly crashed (I am using GRASS 6.4 on Mac OS, but tried on Windows XP as well) with the message out of memory. I have run valgrind to check for a memory leak (Linux 64 bit box): Some funky uninitialised byte(s) problem appears... (inline also a debug msg?): GRASS 6.5.svn (spearfish60): CMD=v.net.visibility input=roads output=graph --o GRASS 6.5.svn (spearfish60): valgrind --tool=memcheck --leak-check=yes --show-reachable=yes $CMD --o ==3496== Memcheck, a memory error detector. ==3496== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==3496== Using LibVEX rev 1854, a library for dynamic binary translation. ==3496== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==3496== Using valgrind-3.3.1, a dynamic binary instrumentation framework. ==3496== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==3496== For more details, rerun with: -v ==3496== ==3496== Syscall param write(buf) points to uninitialised byte(s) ==3496==at 0x7035D70: write (in /lib64/libc-2.8.so) ==3496==by 0x6FD6EE9: _IO_file_write (in /lib64/libc-2.8.so) ==3496==by 0x6FD7DF8: _IO_do_write (in /lib64/libc-2.8.so) ==3496==by 0x6FD89F6: _IO_switch_to_get_mode (in /lib64/libc-2.8.so) ==3496==by 0x6FD736F: _IO_file_seekoff (in /lib64/libc-2.8.so) ==3496==by 0x6FCCDA9: ftell (in /lib64/libc-2.8.so) ==3496==by 0x5D41F4D: dig_ftell (file.c:40) ==3496==by 0x5D42963: dig__write_head (head.c:56) ==3496==by 0x4E57FE4: V1_open_new_nat (open_nat.c:127) ==3496==by 0x4E57434: Vect_open_new (open.c:565) ==3496==by 0x402EAF: main (main.c:85) ==3496== Address 0x4028009 is not stack'd, malloc'd or (recently) free'd Building topology for vector map graph... Registering primitives... 330643 primitives registered 661286 vertices registered primitives: 402.00 Building areas... 100% 0 areas built 0 isles built areas: 1.00 Attaching islands... isles: 0.00 Attaching centroids... 100% centroids: 1.00 areas to cidx: 0.00 --- should this be G_debug()? Number of nodes: 4491 Number of primitives: 330643 Number of points: 0 Number of lines: 330643 Number of boundaries: 0 Number of centroids: 0 Number of areas: 0 Number of isles: 0 ==3496== ==3496== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 1) ==3496== malloc/free: in use at exit: 489,152,702 bytes in 2,067,875 blocks. ==3496== malloc/free: 4,047,776 allocs, 1,979,901 frees, 1,604,422,635 bytes allocated. ==3496== For counts of detected errors, rerun with: -v ==3496== searching for pointers to 2,067,875 not-freed blocks. ==3496== checked 73,330,480 bytes. ==3496== ==3496== ==3496== 192 bytes in 8 blocks are possibly lost in loss record 1 of 21 ==3496==at 0x4C2136E: malloc (vg_replace_malloc.c:207) ==3496==by 0x529603E: G__malloc (alloc.c:41) ==3496==by 0x4E3E213: Vect__new_cats_struct (cats.c:62) ==3496==by 0x4E3E1C4: Vect_new_cats_struct (cats.c:44) ==3496==by 0x404EB4: report (visibility.c:212) ==3496==by 0x404E5B: handle (visibility.c:198) ==3496==by 0x4050E7: construct_visibility (visibility.c:278) ==3496==by 0x4030EF: main (main.c:125) ==3496== ==3496== ==3496== 256 bytes in 8 blocks are still reachable in loss record 2 of 21 ==3496==at 0x4C2136E: malloc (vg_replace_malloc.c:207) ==3496==by 0x4E4F2F2: Vect__new_line_struct (line.c:69) ==3496==by 0x4E4F2A8: Vect_new_line_struct (line.c:59) ==3496==by 0x404EAB: report (visibility.c:211) ==3496==by 0x404C70: handle (visibility.c:176) ==3496==by 0x4050E7: construct_visibility (visibility.c:278) ==3496==by 0x4030EF: main (main.c:125) ==3496== ==3496== ==3496== 480 bytes in 15 blocks are possibly lost in loss record 3 of 21 ==3496==at 0x4C2136E: malloc (vg_replace_malloc.c:207) ==3496==by 0x4E4F2F2: Vect__new_line_struct (line.c:69) ==3496==by 0x4E4F2A8: Vect_new_line_struct (line.c:59) ==3496==by 0x404EAB: report (visibility.c:211) ==3496==by 0x404C70: handle (visibility.c:176) ==3496==by 0x4050E7: construct_visibility (visibility.c:278) ==3496==by 0x4030EF: main (main.c:125) ==3496== ==3496== ==3496== 480 bytes in 1 blocks are still reachable in loss record 4 of 21 ==3496==at 0x4C2136E: malloc (vg_replace_malloc.c:207) ==3496==by 0x5296135: G__realloc (alloc.c:109) ==3496==by 0x4E46602: Vect_add_dblink (field.c:226) ==3496==by 0x4E47333: Vect_read_dblinks (field.c:645) ==3496==by 0x4E56D61: Vect__open_old (open.c:344) ==3496==by 0x4E57029: Vect_open_old (open.c:415) ==3496==by 0x402E5F: main (main.c:81) ==3496== ==3496== ==3496== 2,048 bytes in 4 blocks are definitely lost in loss record 5 of 21 ==3496==at 0x4C2136E: malloc (vg_replace_malloc.c:207) ==3496==
[GRASS-dev] [GRASS GIS] #553: wx and tcltk GUI: changing default GUI returns error
#553: wx and tcltk GUI: changing default GUI returns error
-+--
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major| Milestone: 6.4.0
Component: Python | Version: 6.4.0 RCs
Keywords: wxgui gis.m |Platform: MSWindows XP
Cpu: x86-32 |
-+--
Hi,
working with latest 6.4.0svn WinGrass from the osgeo4w installer.
1. Start up the wxGui in spearfish/user1.
In the Layer Manager GUI:
Config - GRASS Working Environment - Change default GUI
nothing happens, only this appears in the output window:
{{{
Traceback (most recent call last):
File C:/OSGeo4W/apps/grass/grass-6.4.0svn/etc/wxpython/wx
gui.py, line 515, in OnMenuCmd
menuform.GUI().ParseCommand(cmd, parentframe=self)
File C:\OSGeo4W\apps\grass\grass-6.4.0svn\etc\wxpython\gu
i_modules\menuform.py, line 1716, in ParseCommand
xml.sax.parseString( getInterfaceDescription(cmd[0]),
handler )
File C:\OSGeo4W\apps\grass\grass-6.4.0svn\etc\wxpython\gu
i_modules\menuform.py, line 1657, in
getInterfaceDescription
raise IOError, _(Unable to fetch interface description for
command '%s'.) % cmd
IOError
:
Unable to fetch interface description for command
'g.change.gui.py'.
}}}
2. startup the tcltk gui with grass64 -tcltk from the OSGeo4W shell
prompt.
In the GIS manager do
Config - GRASS Working Environment - Change default GUI
a tcltk popup Error window comes up which says:
{{{
couldn't execute
C:\OSFeo4W\apps\grass\grass-6.4.0svn\etc\gui\scripts\g.change.gui.sh:
no such file or directory [OK]
}}}
after you press OK an empty wish gui is there titled dialog0.
the file is in fact there. (it's a bash script)
??,
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/553
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #500: GUI menu item to swtich GUIs
#500: GUI menu item to swtich GUIs --+- Reporter: hamish | Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: new Priority: major| Milestone: 6.4.0 Component: default | Version: 6.4.0 RCs Resolution: |Keywords: gui Platform: All | Cpu: All --+- Comment (by hamish): not working in the latest wingrass installer, see bug #553. Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/500#comment:8 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #553: wx and tcltk GUI: changing default GUI returns error
#553: wx and tcltk GUI: changing default GUI returns error ---+ Reporter: hamish| Owner: grass-dev@lists.osgeo.org Type: defect| Status: new Priority: major | Milestone: 6.4.0 Component: Python| Version: 6.4.0 RCs Resolution:|Keywords: wxgui gis.m Platform: MSWindows XP | Cpu: x86-32 ---+ Comment (by hamish): see also wish #500 -- Ticket URL: https://trac.osgeo.org/grass/ticket/553#comment:1 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #553: wx and tcltk GUI: changing default GUI returns error
#553: wx and tcltk GUI: changing default GUI returns error
---+
Reporter: hamish| Owner: grass-dev@lists.osgeo.org
Type: defect| Status: new
Priority: major | Milestone: 6.4.0
Component: Python| Version: 6.4.0 RCs
Resolution:|Keywords: wxgui gis.m
Platform: MSWindows XP | Cpu: x86-32
---+
Comment (by hamish):
I guess all the scripts in $GISBASE/etc/gui/scripts/ need batch files like
are used for the scripts in $GISBASE/bin/:
e.g. the file C:\OSGeo4W\apps\grass\grass-6.4.0svn\bin\v.in.garmin.bat
contains the single line:
{{{
@%GRASS_SH% -c '%GISBASE%/scripts/v.in.garmin %*'
}}}
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/553#comment:2
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #554: wxGUI location wizard: Search in description with 0 hits
#554: wxGUI location wizard: Search in description with 0 hits
-+--
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major| Milestone: 6.4.0
Component: wxGUI| Version: 6.4.0 RCs
Keywords: location wizard |Platform: MSWindows XP
Cpu: x86-32 |
-+--
Hi,
in the latest 6.4.0svn wingrass build from osgeo4w--
- startup with wxgui.
- Define new location via location wizard.
- by epsg code (list comes up now, great to see that fixed!)
- Search in description: ___ something with no hits, eg 4326 or typo
At this point the list of codes is empty and the following error message
appears on the DOS console window:
{{{
Traceback (most recent call last):
File
C:\OSGeo4W\apps\grass\grass-6.4.0svn\etc\wxpython\gui_modules\location_wizard.py,
line 1365, in OnSearch
self.epsgcode = self.epsglist.Search(index=1, str=value)[0]
TypeError: 'NoneType' object is unsubscriptable
}}}
so I guess two things are needed:
- only try to grab epsg code to fill in EPSG code: box if =1
result was found, and
- automatically reload EPSG codes before each new search (if 0 hits then
the 'search in desc' box is unusable until you press the Reload EPSG Codes
button.
thanks,
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/554
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #554: wxGUI location wizard: Search in description with 0 hits
#554: wxGUI location wizard: Search in description with 0 hits ---+ Reporter: hamish| Owner: grass-dev@lists.osgeo.org Type: defect| Status: new Priority: major | Milestone: 6.4.0 Component: wxGUI | Version: 6.4.0 RCs Resolution:|Keywords: location wizard Platform: MSWindows XP | Cpu: x86-32 ---+ Comment (by hamish): also in the location wizard, it would be really nice for lat/lon locations if the Set default region extent and resolution would accept the DDD:MM:SS.SSSh format. (swig G_scan_northing()?) currently if you try that it gives an error: (e.g. for 48deg South lat) Invalid value: invalid literal for float(): 48S Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/554#comment:1 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [osgeo4w] #37: grass: wxpython gui issues
#37: grass: wxpython gui issues ---+ Reporter: jachym |Owner: osgeo4w-...@lists.osgeo.org Type: defect | Status: new Priority: major |Component: Package Version: | Resolution: Keywords: GRASS | ---+ Comment (by hamish): Hi, I have looked through the entire bug report and AFAICT these are the issues commented upon that remain open with the latest 6.4.0svn osgeo4w binary package release: * osgeo4w\bin\grass64.bat does not accept --help (or other) parameter. * wx-nviz (no error message, when you switch the monitor to 3D view, nothing happens). Cog and O/I icons come up and overlap the eyeball and full-rerender icons in top left of the view window toolbar. starting with a blank map display a Please wait, loading data... grey box comes up in the map display. but nothing. * wx-vdigit: [NEW] toolbar comes up but always No vector map selected for editing.. In layer list I can choose Start editing and a please wait while map is opened for editing message comes up on the bottom status bar, but the Stop editing menu item never ungreys. thanks, Hamish -- Ticket URL: https://trac.osgeo.org/osgeo4w/ticket/37#comment:32 OSGeo4W http://trac.osgeo.org/osgeo4w OSGeo4W is the Windows installer for the OSGeo stack.___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
