Re: [GRASS-dev] Who wants GUI and who does not and why
Luca Delucchi lucadel...@gmail.com writes: On 18 April 2014 11:15, Pietro peter.z...@gmail.com wrote: Hi Vaclav, actually I'm a bit more extremist... :-) I would like to split GRASS in three main parts: - grass-lib - grass-cli - grass-gui I also like this idea... I think this would be a very good idea as it would make the whole GRASS ecosystem more transparent and easier (in my opinion) to maintain and to use certain aspects from different applications. Re functionality in the GUI: The question would be if the split is lib--cli--gui or |--cli lib| |--gui in other words, if the cli is just a non graphical UI or THE interface to the lib, through which the gui operates. I think the first design approach would be the better one. Cheers, Rainer At least should be possible to build these parts separately, leaving the decision to split in several packages to the package maintainer of each distribution (Debian, Fedora, etc.). I think that someone is already doing something like this. But I don't know more because I usually compile myself GRASS Regards Pietro -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxGUI data catalog
On 01/05/14 19:18, Martin Landa wrote:
Hi all,
one of my students (Tereza, cc'ed) started to work on simple version
of the data catalog implemented as a new tab in Layer Manager. This
tool will allow to manage maps in the current location (remove, copy,
or rename). Later could be added support for copying maps between
different locations (including automated reprojection), preview of
data and so on.
Currently we are facing to the question whether to use in her code
pyGRASS or just GRASS Python Scripting Library. pyGRASS is not
currently used in wxGUI at all (with only one exception - see
gui_core/gselect.py [1]). There are some wxGUI components which should
be rewritten using pygrass (those which already use ctypes), eg. wxGUI
vector digitizer, but it's another story.
So the question: do we start using pyGRASS in wxGUI more often even in
the code where we don't need ctypes access and calling GRASS commands
through GRASS Python Scripting Library is enough.
The sample code from data catalog (copying maps):
GRASS Python Scripting Library:
cur_mapset = grass.gisenv()['MAPSET']
grass.run_command('g.gisenv', set = 'MAPSET=%s' % dst_mapset)
grass.run_command('g.copy', rast='%s@%s,%s' % (src_map, src_mapset, dst_name))
grass.run_command('g.gisenv', set = 'MAPSET=%s' % cur_mapset)
pyGRASS:
cur_mapset = str(Mapset())
Mapset(dst_mapset).current()
g.copy(rast = '%s@%s,%s' % (src_map, src_mapset, dst_name)) # *
Mapset(cur_mapset).current()
* this could be replaced by something more fancy by modifying pyGRASS
What is you opinion?
Personally I incline to promote pyGRASS as interface for user scripts,
but in wxGUI I still prefer to use GRASS Scripting Library to call
GRASS commands on the background.
I don't know pyGRASS well enough to really judge. Could you explain your
preference ?
More generally, I think that unless the two really fulfill two different
purposes shouldn't we try to focus on one, instead of having the two ?
Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #2276: r.covar: output N (number of cells considered)
#2276: r.covar: output N (number of cells considered) -+-- Reporter: mlennert | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 6.4.4 Component: Default | Version: unspecified Keywords: |Platform: Unspecified Cpu: Unspecified | -+-- I just committed (r60035) a small addition to r.covar to output the N value. In light of recent discussions: What is our current policy on backporting this to grass70release and to grass64release ? It's a new feature, but extremely uninvasive (just an additional fprintf). Can I backport ? Moritz -- Ticket URL: https://trac.osgeo.org/grass/ticket/2276 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] #2277: graphically set up region bounds
#2277: graphically set up region bounds -+-- Reporter: vincent | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 6.4.4 Component: wxGUI| Version: unspecified Keywords: region |Platform: Unspecified Cpu: Unspecified | -+-- When using grass with wx gui, one can regret the lack of an interactive tool in map display window that would allow to graphically determine region bounds via a drag-n-drop box. I don't mean to interact with region resolutions, only with boundaries. If I refer to gui/wxpython/mapdisp/mapwindow.py, it would be a kind of mix between functions Zoom(self, begin, end, zoomtype) and DisplayToWind(self). The latter is nice except if you need to define a region whose dimensions don't fit with the map display frame ratio... My knowledge of python is too poor to propose any concrete coding, but I guess it should not be that tricky to implement. Does anyone else think it's a good idea that wxgui provides an on-the-fly method for region setting ? -- Ticket URL: http://trac.osgeo.org/grass/ticket/2277 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] Who wants GUI and who does not and why
I agree. grass-cli and grass-gui should be completely independent and at the same level. They are simply two different UIs that directly depend on grass-lib. The user wants either grass-cli grass-lib or grass-gui grass-lib. Now, my opinion is if we put analysis and modeling code in grass-lib, grass-lib would be too big or, for some users, it would contain too much irrelevant code if all they want is simply GIS operations. Very field-specific code such as hydrology, remote sensing, ... should be separated out from the grass-lib and put in another layer of the libraries. grass-cli/gui will interact with that layer directly. grass-lib - grass-plugins - grass-cli, grass-gui, other GISs: Full analysis/modeling suite grass-lib - other GISs: Simple GIS data manipulation very common in all fields. Regards, Huidae On Fri, May 2, 2014 at 4:32 AM, Rainer M Krug rai...@krugs.de wrote: Luca Delucchi lucadel...@gmail.com writes: On 18 April 2014 11:15, Pietro peter.z...@gmail.com wrote: Hi Vaclav, actually I'm a bit more extremist... :-) I would like to split GRASS in three main parts: - grass-lib - grass-cli - grass-gui I also like this idea... I think this would be a very good idea as it would make the whole GRASS ecosystem more transparent and easier (in my opinion) to maintain and to use certain aspects from different applications. Re functionality in the GUI: The question would be if the split is lib--cli--gui or |--cli lib| |--gui in other words, if the cli is just a non graphical UI or THE interface to the lib, through which the gui operates. I think the first design approach would be the better one. Cheers, Rainer At least should be possible to build these parts separately, leaving the decision to split in several packages to the package maintainer of each distribution (Debian, Fedora, etc.). I think that someone is already doing something like this. But I don't know more because I usually compile myself GRASS Regards Pietro -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 ___ 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] sample dataset for temporal data
One more thing, to test the dataset, look at the examples here: http://courses.ncsu.edu/mea592/common/Assign_GISmdmodel/a_temporal.html Anna On Tue, Apr 29, 2014 at 5:07 PM, Anna Petrášová kratocha...@gmail.comwrote: Hi, since more and more users are using temporal framework, we should consider creating a sample dataset for temporal data. This could be used in the manual pages of t.* modules. Some of them still don't have any example and the existing examples are based on tests with generated data which is not the best way. Some time ago I created a climate dataset for North Carolina from publicly available data, it has monthly temperature average and monthly precipitation from 2000 to 2012. You can download it from here: http://courses.ncsu.edu/mea592/common/media/02/nc_climate_spm_2000_2012.zip There are no temporal vector data, just the standard precip. stations vector from nc_spm_08. So I suggest to use this, because it's consistent with nc_spm_08 but feel free to suggest something else. Best, Anna ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2277: graphically set up region bounds
#2277: graphically set up region bounds -+-- Reporter: vincent | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.0.0 Component: wxGUI| Version: unspecified Keywords: region |Platform: Unspecified Cpu: Unspecified | -+-- Changes (by martinl): * milestone: 6.4.4 = 7.0.0 Comment: Slightly related, it's possible to set region extent from display, see `Various zoom options - Set computational region from display extent`. In any case milestone moved to GRASS 7. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2277#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
Re: [GRASS-dev] [GRASS GIS] #2277: graphically set up region bounds
#2277: graphically set up region bounds -+-- Reporter: vincent | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.0.0 Component: wxGUI| Version: unspecified Keywords: region |Platform: Unspecified Cpu: Unspecified | -+-- Comment(by vincent): Replying to [comment:1 martinl]: Slightly related, it's possible to set region extent from display, see `Various zoom options - Set computational region from display extent`. Yes I use that, but proceeding this way may not be very handy : you have to resize the map display frame if you need to define e.g. an especially narrow region. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2277#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
Re: [GRASS-dev] Who wants GUI and who does not and why
On 02/05/14 14:29, Huidae Cho wrote: I agree. grass-cli and grass-gui should be completely independent and at the same level. They are simply two different UIs that directly depend on grass-lib. The user wants either grass-cli grass-lib or grass-gui grass-lib. Now, my opinion is if we put analysis and modeling code in grass-lib, grass-lib would be too big or, for some users, it would contain too much irrelevant code if all they want is simply GIS operations. Very field-specific code such as hydrology, remote sensing, ... should be separated out from the grass-lib and put in another layer of the libraries. grass-cli/gui will interact with that layer directly. grass-lib - grass-plugins - grass-cli, grass-gui, other GISs: Full analysis/modeling suite grass-lib - other GISs: Simple GIS data manipulation very common in all fields. I don't think I understand: there is no such thing as grass-lib that can be called from either a grass-cli _or_ a grass-gui. The GUI actually calls grass modules. And these modules _are_ the CLI. And as many discussions have shown before, GRASS libs should not be called from anything else but GRASS modules. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] g.mremove: adding 'map name exclusion pattern' option
On Fri, May 2, 2014 at 3:01 AM, Huidae Cho gras...@gmail.com wrote: Well, the g.mremove interface looks convenient, but can be dangerous also. For example, yesterday, I almost deleted my raster files by using the positional parameter thing while trying to delete all my temporary vectors. g.mremove tmp* Whops! Did I want to delete tmp* rasters or vectors? I forgot to add vect= and my tmp* rasters were listed. Thanks to the -f option. The easiest workaround is that we reorder the parameter list. At time we have rast = 1st = default. See http://grass.osgeo.org/grass71/manuals/g.mremove.html Putting there, say, label will enforce the user to have to set rast= for deleting raster maps. This would require no extra efforts and minimize the risk except for those using labels (so we could even add a dummy parameter there. Or select another rather unknown parameter from that list to become the first in the list). Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Who wants GUI and who does not and why
I'm not talking about the current structure. Yes, the modules are the CLI right now and the GUI calls the CLI modules internally. What I'm saying is that it would great if we could separate the logic and CLI and put the logic in plugins and let the CLI and GUI calls the logic. GUI would be independent on CLI and directly call the logic plugin. Here, I'm saying plugin because each module could be implemented as a mod_*.so just like Apache modules. Then we could implement a CLI environment that can load mod_*.so as needed dynamically. In the same way, other programs can call mod_*.so without creating a separate process for individual modules. Actually, even now, GRASS libs are called directly from GDAL for handling raster/vector maps. On Fri, May 2, 2014 at 9:58 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 02/05/14 14:29, Huidae Cho wrote: I agree. grass-cli and grass-gui should be completely independent and at the same level. They are simply two different UIs that directly depend on grass-lib. The user wants either grass-cli grass-lib or grass-gui grass-lib. Now, my opinion is if we put analysis and modeling code in grass-lib, grass-lib would be too big or, for some users, it would contain too much irrelevant code if all they want is simply GIS operations. Very field-specific code such as hydrology, remote sensing, ... should be separated out from the grass-lib and put in another layer of the libraries. grass-cli/gui will interact with that layer directly. grass-lib - grass-plugins - grass-cli, grass-gui, other GISs: Full analysis/modeling suite grass-lib - other GISs: Simple GIS data manipulation very common in all fields. I don't think I understand: there is no such thing as grass-lib that can be called from either a grass-cli _or_ a grass-gui. The GUI actually calls grass modules. And these modules _are_ the CLI. And as many discussions have shown before, GRASS libs should not be called from anything else but GRASS modules. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Who wants GUI and who does not and why
On Fri, May 2, 2014 at 10:03 AM, Vaclav Petras wenzesl...@gmail.com wrote: On Fri, May 2, 2014 at 8:29 AM, Huidae Cho gras...@gmail.com wrote: I agree. grass-cli and grass-gui should be completely independent and at the same level. They are simply two different UIs that directly depend on grass-lib. The user wants either grass-cli grass-lib or grass-gui grass-lib. This of course makes sense. However, we are very far from anything like this. Functionality is in the modules (i.e. CLI), not library, and even Python libraries contains CLI calls. I don't see any chance of changing this state any time soon, although it would be beneficial. The grass-lib would no just contain very basic things (compared to what CLI would provide). Consequently there cannot be any GUI without CLI now. That's correctly. GUI is a wrapper around CLI because CLI has the logic. Other programs that want to use GRASS capabilities should also call CLIs by executing external programs (CLIs). Instead of calling external processes, we could dynamically link to the logic libraries and simply call functions if we could do further separations. Now, my opinion is if we put analysis and modeling code in grass-lib, grass-lib would be too big or, for some users, it would contain too much irrelevant code if all they want is simply GIS operations. Very field-specific code such as hydrology, remote sensing, ... should be separated out from the grass-lib and put in another layer of the libraries. grass-cli/gui will interact with that layer directly. As I said this is very theoretical and in fact, there was one refactoring which moved things from lib to modules. Anyway, it would be beneficial to know what would be concrete steps to do this, what are the issues this must solve, and, similarly to GUI, what is the general opinion on this. For example, the implementation of RPC interface for library (as discussed in another threads) would allow usage of grass-lib by any application, not only modules (CLI), so then GUI could depend directly on grass-lib. On the other hand, modules define a nice user interface for processing, so I don't think that GUI should define some other, it should just use the modules (the current state). The other question is what should be used to implement GUI. Regardless of purpose of grass-lib, there are some thing which should be moved to the library to be reused in more modules. Pietro recently suggested in some ticket that functionality of r.univar should be available in the library. grass-lib - grass-plugins - grass-cli, grass-gui, other GISs: Full analysis/modeling suite I still don't understand what do you mean by grass-plugins. What I mean by grass-plugins is that we can separate the current CLIs (UI and logic) into plugins (logic) and light-weight CLI that calls the plugins. GUI would also call the plugins. Think about Apache. httpd is an executable file that can load its modules as needed. We cannot call individual modules directly without using httpd and individual modules have the logic. I think that this plugin idea would make GRASS analysis/modeling capabilities more like libraries, not external programs, while maintaining clear separation of heavy analysis logic from the core grass-lib. And like you said, yes, we're far from this theoretical status. Huidae Vaclav grass-lib - other GISs: Simple GIS data manipulation very common in all fields. Regards, Huidae On Fri, May 2, 2014 at 4:32 AM, Rainer M Krug rai...@krugs.de wrote: Luca Delucchi lucadel...@gmail.com writes: On 18 April 2014 11:15, Pietro peter.z...@gmail.com wrote: Hi Vaclav, actually I'm a bit more extremist... :-) I would like to split GRASS in three main parts: - grass-lib - grass-cli - grass-gui I also like this idea... I think this would be a very good idea as it would make the whole GRASS ecosystem more transparent and easier (in my opinion) to maintain and to use certain aspects from different applications. Re functionality in the GUI: The question would be if the split is lib--cli--gui or |--cli lib| |--gui in other words, if the cli is just a non graphical UI or THE interface to the lib, through which the gui operates. I think the first design approach would be the better one. Cheers, Rainer At least should be possible to build these parts separately, leaving the decision to split in several packages to the package maintainer of each distribution (Debian, Fedora, etc.). I think that someone is already doing something like this. But I don't know more because I usually compile myself GRASS Regards Pietro -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10
Re: [GRASS-dev] [GRASS-SVN] r60048 - grass/trunk/vector/v.in.db
Hi, 2014-05-02 18:53 GMT+02:00 svn_gr...@osgeo.org: -Vect_open_new(Map, outvect-answer, with_z); +if (Vect_open_new(Map, outvect-answer, with_z) == -1) + exit(EXIT_FAILURE); + please provide more info where it fails. Also note that Vect_open_new calls G_fatal_error() so the most of modules don't check return code of this function. Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60048 - grass/trunk/vector/v.in.db
Segmentation fault when you do v.in.db ... output=a@other_mapset because Vect_open_new returns -1 with a warning, not a fatal error, unable to create new ... is not the current mapset. I didn't check why it's returning -1 instead of throwing a fatal error in this case. I believe that this warning has to be a fatal error if no modules rely on -1 return. Huidae On Fri, May 2, 2014 at 12:59 PM, Martin Landa landa.mar...@gmail.comwrote: Hi, 2014-05-02 18:53 GMT+02:00 svn_gr...@osgeo.org: -Vect_open_new(Map, outvect-answer, with_z); +if (Vect_open_new(Map, outvect-answer, with_z) == -1) + exit(EXIT_FAILURE); + please provide more info where it fails. Also note that Vect_open_new calls G_fatal_error() so the most of modules don't check return code of this function. Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60048 - grass/trunk/vector/v.in.db
More detail.. When this happens, Map is not fully initialized and following Vect_* calls with Map can fail unexpectedly, which caused a segmentation fault in this case. On Fri, May 2, 2014 at 1:15 PM, Huidae Cho gras...@gmail.com wrote: Segmentation fault when you do v.in.db ... output=a@other_mapset because Vect_open_new returns -1 with a warning, not a fatal error, unable to create new ... is not the current mapset. I didn't check why it's returning -1 instead of throwing a fatal error in this case. I believe that this warning has to be a fatal error if no modules rely on -1 return. Huidae On Fri, May 2, 2014 at 12:59 PM, Martin Landa landa.mar...@gmail.comwrote: Hi, 2014-05-02 18:53 GMT+02:00 svn_gr...@osgeo.org: -Vect_open_new(Map, outvect-answer, with_z); +if (Vect_open_new(Map, outvect-answer, with_z) == -1) + exit(EXIT_FAILURE); + please provide more info where it fails. Also note that Vect_open_new calls G_fatal_error() so the most of modules don't check return code of this function. Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wxGUI data catalog
On Thu, May 1, 2014 at 1:18 PM, Martin Landa landa.mar...@gmail.com wrote: one of my students (Tereza, cc'ed) started to work on simple version of the data catalog implemented as a new tab in Layer Manager. This tool will allow to manage maps in the current location (remove, copy, or rename). Later could be added support for copying maps between different locations (including automated reprojection), preview of data and so on. Hi, this could be a very helpful tool. There is one thing I strongly suggest to you. The tool should be available as g.gui.datacatalog (or whatever name is appropriate). There is several reason for this and we can discuss them in detail if you want but basically they include better code, possibility to not have it in main GUI at all, space for more feature-rich interface, and fast access to functionality if your primary interface is command line. Vaclav ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60048 - grass/trunk/vector/v.in.db
OK, I did a quick search and there are 104 calls to Vect_open_new. 63 calls don't check its return value and 41 calls check. 27 of the 41 that do the check do some cleaning work before finally throwing a fatal error. Most of the cleaning work is Vect_close(already open vectors), which I don't think is really necessary before throwing a fatal error. v.convert fcloses Digin and v.surf.rst deletes left-over files. Even Vect_close returns 1. Based on these observations, I think Vect_open_new needs to return what it's returning now on failure and the 63 calls that don't check its return value have to be fixed to avoid a potential segmentation fault. I'll fix them tonight if I didn't overlook something. 53 files that don't check the return value: ./display/d.extract/main.c ./lib/sites/sites.c ./raster/r.carve/vect.c ./raster/r.contour/main.c ./raster/r.random/random.c ./raster/r.stream.extract/close.c ./raster/r.stream.order/stream_vector.c ./raster/r.stream.segment/stream_vector.c ./raster/r.stream.snap/points_io.c ./raster/r.to.vect/main.c ./raster/r.volume/main.c ./raster/simwe/simlib/output.c ./vector/v.buffer/main.c ./vector/v.build.polylines/main.c ./vector/v.build/main.c ./vector/v.clean/main.c ./vector/v.distance/main.c ./vector/v.drape/main.c ./vector/v.edit/main.c ./vector/v.external/main.c ./vector/v.extract/main.c ./vector/v.extrude/main.c ./vector/v.in.ascii/main.c ./vector/v.in.dwg/main.c ./vector/v.in.lidar/main.c ./vector/v.in.ogr/main.c ./vector/v.in.region/main.c ./vector/v.in.sites/main.c ./vector/v.kernel/main.c ./vector/v.lrs/v.lrs.create/main.c ./vector/v.lrs/v.lrs.label/main.c ./vector/v.lrs/v.lrs.segment/main.c ./vector/v.net.alloc/main.c ./vector/v.net.iso/main.c ./vector/v.net.salesman/main.c ./vector/v.net.steiner/main.c ./vector/v.overlay/main.c ./vector/v.parallel/main.c ./vector/v.patch/main.c ./vector/v.perturb/main.c ./vector/v.proj/main.c ./vector/v.qcount/main.c ./vector/v.reclass/main.c ./vector/v.rectify/main.c ./vector/v.sample/main.c ./vector/v.segment/main.c ./vector/v.select/main.c ./vector/v.split/main.c ./vector/v.surf.rst/main.c ./vector/v.to.points/main.c ./vector/v.transform/main.c ./vector/v.vol.rst/main.c ./vector/v.voronoi/main.c On Fri, May 2, 2014 at 1:18 PM, Huidae Cho gras...@gmail.com wrote: More detail.. When this happens, Map is not fully initialized and following Vect_* calls with Map can fail unexpectedly, which caused a segmentation fault in this case. On Fri, May 2, 2014 at 1:15 PM, Huidae Cho gras...@gmail.com wrote: Segmentation fault when you do v.in.db ... output=a@other_mapset because Vect_open_new returns -1 with a warning, not a fatal error, unable to create new ... is not the current mapset. I didn't check why it's returning -1 instead of throwing a fatal error in this case. I believe that this warning has to be a fatal error if no modules rely on -1 return. Huidae On Fri, May 2, 2014 at 12:59 PM, Martin Landa landa.mar...@gmail.comwrote: Hi, 2014-05-02 18:53 GMT+02:00 svn_gr...@osgeo.org: -Vect_open_new(Map, outvect-answer, with_z); +if (Vect_open_new(Map, outvect-answer, with_z) == -1) + exit(EXIT_FAILURE); + please provide more info where it fails. Also note that Vect_open_new calls G_fatal_error() so the most of modules don't check return code of this function. Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Who wants GUI and who does not and why
Hi, if you allow me a user comment on this: The user wants either grass-cli grass-lib or grass-gui grass-lib. Actually, the combination of CLI and GUI is extremely handy in everyday work, which is why I regularly introduce students quite early to this combination. The possibility to copy the commands from GUI is here very helpful too. I missed having a CLI in parallel on Windows until it came with GRASS 7. Before I regularly started two grass sessions. First the GUI then the command line. It would be a pity if this perfectly matched team would be separated (in terms of user experience)… Cheers Stefan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2275: g.gui.timeline datasets with the same name
#2275: g.gui.timeline datasets with the same name +--- Reporter: martinl | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: wxGUI | Version: svn-trunk Keywords: g.gui.timeline, dataset with the same name |Platform: Unspecified Cpu: Unspecified | +--- Comment(by annakrat): Should be fixed in r60052. Please test. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2275#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
Re: [GRASS-dev] [GRASS GIS] #2273: g.gui.animation ignores search path for spatio-temporal datasets
#2273: g.gui.animation ignores search path for spatio-temporal datasets --+- Reporter: martinl | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 7.0.0 Component: wxGUI | Version: svn-trunk Keywords: g.gui.animation, search path |Platform: Unspecified Cpu: Unspecified | --+- Comment(by annakrat): Should be fixed in r60053. Please test. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2273#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
Re: [GRASS-dev] [GRASS GIS] #2273: g.gui.animation ignores search path for spatio-temporal datasets
#2273: g.gui.animation ignores search path for spatio-temporal datasets --+- Reporter: martinl | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 7.0.0 Component: wxGUI | Version: svn-trunk Keywords: g.gui.animation, search path |Platform: Unspecified Cpu: Unspecified | --+- Comment(by annakrat): Replying to [comment:2 annakrat]: Should be fixed in r60053. Please test. Not fixed yet, it still shows datasets from inaccessible mapsets. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2273#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
Re: [GRASS-dev] [GRASS GIS] #2275: g.gui.timeline datasets with the same name
#2275: g.gui.timeline datasets with the same name +--- Reporter: martinl | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: wxGUI | Version: svn-trunk Keywords: g.gui.timeline, dataset with the same name |Platform: Unspecified Cpu: Unspecified | +--- Comment(by annakrat): Replying to [comment:1 annakrat]: Should be fixed in r60052. Please test. Not fixed yet, it still shows datasets from inaccessible mapsets. The error after Cancel should be fixed. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2275#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
Re: [GRASS-dev] [GRASS GIS] #2267: t.list doesn't respect search path
#2267: t.list doesn't respect search path --+- Reporter: martinl | Owner: grass-dev@… Type: defect | Status: closed Priority: normal | Milestone: 7.0.0 Component: Temporal | Version: svn-trunk Resolution: fixed|Keywords: t.list, search path Platform: Unspecified | Cpu: Unspecified --+- Comment(by annakrat): I got confused from all the different functions for listing datasets. There are currently also [http://trac.osgeo.org/grass/browser/grass/trunk/lib/python/temporal/gui_support.py#L21 tgis.tlist_grouped] and [http://trac.osgeo.org/grass/browser/grass/trunk/lib/python/temporal/gui_support.py#L81 tgis.tlist]. These don't respect search path. Function `get_dataset_list` does not give you the right order of mapsets because it returns unordered dictionary. Perhaps ordered dict (I think it's in pygrass) or some tuples would be better? This function could also give you the option not to respect the search path (maybe useful for data catalog). `tgis.tlist` could then be a higher level wrapper, call `get_dataset_list` and return the dataset names instead of sql rows. I would then use it in g.gui.animation/timeline. `tgis.tlist_grouped` would then call `tgis.tlist` and group names by mapsets which is used in the selection widget. Does it sound too complicated? -- Ticket URL: http://trac.osgeo.org/grass/ticket/2267#comment:9 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] wxGUI data catalog
Hi,
On Thu, May 1, 2014 at 1:18 PM, Martin Landa landa.mar...@gmail.com wrote:
Hi all,
one of my students (Tereza, cc'ed) started to work on simple version
of the data catalog implemented as a new tab in Layer Manager. This
tool will allow to manage maps in the current location (remove, copy,
or rename). Later could be added support for copying maps between
different locations (including automated reprojection), preview of
data and so on.
Do you plan to discuss somewhere the design of the catalog? Perhaps
summarize the main points about the integration with layer manager and map
display, gui design, planned features etc on Trac?
Currently we are facing to the question whether to use in her code
pyGRASS or just GRASS Python Scripting Library. pyGRASS is not
currently used in wxGUI at all (with only one exception - see
gui_core/gselect.py [1]). There are some wxGUI components which should
be rewritten using pygrass (those which already use ctypes), eg. wxGUI
vector digitizer, but it's another story.
So the question: do we start using pyGRASS in wxGUI more often even in
the code where we don't need ctypes access and calling GRASS commands
through GRASS Python Scripting Library is enough.
The sample code from data catalog (copying maps):
GRASS Python Scripting Library:
cur_mapset = grass.gisenv()['MAPSET']
grass.run_command('g.gisenv', set = 'MAPSET=%s' % dst_mapset)
grass.run_command('g.copy', rast='%s@%s,%s' % (src_map, src_mapset,
dst_name))
grass.run_command('g.gisenv', set = 'MAPSET=%s' % cur_mapset)
pyGRASS:
cur_mapset = str(Mapset())
Mapset(dst_mapset).current()
g.copy(rast = '%s@%s,%s' % (src_map, src_mapset, dst_name)) # *
Mapset(cur_mapset).current()
* this could be replaced by something more fancy by modifying pyGRASS
What is you opinion?
Personally I incline to promote pyGRASS as interface for user scripts,
but in wxGUI I still prefer to use GRASS Scripting Library to call
GRASS commands on the background.
I agree with that, I am not sure if pyGRASS would give us some advantage in
the mapset/location management, I haven't used it for these tasks. But I
would like to hear from some who already used it like this.
Anna
Martin
[1]
http://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/gui_core/gselect.py#L55
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
___
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
