Re: [GRASS-dev] [GRASS GIS] #1909: remove deleted layer from layer tree
#1909: remove deleted layer from layer tree -+-- Reporter: timmie | Owner: grass-dev@… Type: defect | Status: closed Priority: normal | Milestone: 7.0.0 Component: wxGUI | Version: 6.4.3 RCs Resolution: fixed |Keywords: layer manager, map display Platform: All | Cpu: Unspecified -+-- Changes (by marisn): * status: new = closed * resolution: = fixed Comment: I would vote for wontfix. GRASS GUI layers are not tightly coupled with datasets (maps). I can change displayed data for any of layers or recreate map and only then trigger map canvas update. As long as GUI can handle missing layers, I would suggest to keep current functionality. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1909#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] #1909: remove deleted layer from layer tree
#1909: remove deleted layer from layer tree -+-- Reporter: timmie | Owner: grass-dev@… Type: defect | Status: reopened Priority: normal | Milestone: 7.0.0 Component: wxGUI | Version: 6.4.3 RCs Resolution: |Keywords: layer manager, map display Platform: All | Cpu: Unspecified -+-- Changes (by marisn): * status: closed = reopened * resolution: fixed = Comment: Closed by accident! Wops! -- Ticket URL: http://trac.osgeo.org/grass/ticket/1909#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] GRASS QGIS: the future
Hi all. I learned during dinner that GRASS7 RC1 is due very soon. This opens the issue of its functioning in QGIS. IMHO: * the qgis-grass-plugin might stop working (this has to be tested) * some of the module options will be different * new modules will not be available in QGIS. I think we can deal with this in several ways: * dropping the plugin, and concentrate the work on Processing * upgrading both the plugin and Processing. In the first case, we have two major issues: * upgrading Processing GRASS modules * changing the current Processing behaviour, avoiding the import-export phase when piping consecutive GRASS commands; this makes GRASS modules slower than the equivalent commands of other backends. While the first issue can be solved easily by a couple of people in a few days, the second one is more tricky, and requires hard coding skills. In addition, we'll no longer be able to edit GRASS vectors directly. In the second case, we'll have more work, and a not-so-nice duplication. I would like to have an open discussion on this, avoiding things to just happen, with the possible negative consequences. All the best. -- Paolo Cavallini - www.faunalia.eu QGIS PostGIS courses: http://www.faunalia.eu/training.html ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS QGIS: the future
Hi Paolo, (note: I'm not ready qgis-dev, not sure if this email reaches it) On Thu, Mar 27, 2014 at 11:18 AM, Paolo Cavallini cavall...@faunalia.it wrote: Hi all. I learned during dinner that GRASS7 RC1 is due very soon. This opens the issue of its functioning in QGIS. IMHO: * the qgis-grass-plugin might stop working (this has to be tested) * some of the module options will be different For the time being people can certainly continue to work with GRASS 6. I think that the plugin needs to be cloned for GRASS 7. * new modules will not be available in QGIS. There might be only a few which could be of interest here (e.g. the highly specialized evapotranspiration modules not but some others yes). For an overview, see http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures I think we can deal with this in several ways: * dropping the plugin, and concentrate the work on Processing * upgrading both the plugin and Processing. (the second: yes) In the first case, we have two major issues: * upgrading Processing GRASS modules I'll do that. I already started with Pirmin and Victor to discuss it. * changing the current Processing behaviour, avoiding the import-export phase when piping consecutive GRASS commands; this makes GRASS modules slower than the equivalent commands of other backends. ... this would not be a good idea. While the first issue can be solved easily by a couple of people in a few days, the second one is more tricky, and requires hard coding skills. In addition, we'll no longer be able to edit GRASS vectors directly. In the second case, we'll have more work, and a not-so-nice duplication. I would like to have an open discussion on this, avoiding things to just happen, with the possible negative consequences. I expect that we'll come up with a Processing prototype for which supports GRASS 7 soon. Best Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS QGIS: the future
Il 27/03/2014 12:18, Markus Neteler ha scritto: * upgrading Processing GRASS modules I'll do that. I already started with Pirmin and Victor to discuss it. good news * changing the current Processing behaviour, avoiding the import-export phase when piping consecutive GRASS commands; this makes GRASS modules slower than the equivalent commands of other backends. ... this would not be a good idea. could you please explain why? all the best. -- Paolo Cavallini - www.faunalia.eu QGIS PostGIS courses: http://www.faunalia.eu/training.html ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [Qgis-developer] GRASS QGIS: the future
Il 27/03/2014 12:33, Nathan Woodrow ha scritto: I would vote for dropping the plugin and just updating the processing plugin. Having both ways is bad for us and bad for users, even worse when some functions are missing from one but not in the other. I understand well the point; however, the plugin has additional functions, e.g.: * a grass shell * a grass data browser * a grass digitizing environment. Whether these are important or not, it's a matter of users. All the best. -- Paolo Cavallini - www.faunalia.eu QGIS PostGIS courses: http://www.faunalia.eu/training.html ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS QGIS: the future
On 27 March 2014 11:18, Paolo Cavallini cavall...@faunalia.it wrote: Hi all. Hi all, I learned during dinner that GRASS7 RC1 is due very soon. This opens the issue of its functioning in QGIS. IMHO: * the qgis-grass-plugin might stop working (this has to be tested) I test to compile QGIS master with GRASS7 but it doesn't work, the GRASS7 directory it seems not be recognized bu QGIS. Can I open a ticket on QGIS bug tracker? * some of the module options will be different * new modules will not be available in QGIS. I think we can deal with this in several ways: * dropping the plugin, and concentrate the work on Processing * upgrading both the plugin and Processing. In the first case, we have two major issues: * upgrading Processing GRASS modules * changing the current Processing behaviour, avoiding the import-export phase when piping consecutive GRASS commands; this makes GRASS modules slower than the equivalent commands of other backends. While the first issue can be solved easily by a couple of people in a few days, the second one is more tricky, and requires hard coding skills. In addition, we'll no longer be able to edit GRASS vectors directly. In the second case, we'll have more work, and a not-so-nice duplication. I'm not using at all GRASS from QGIS, so I think could be useful make a poll to know what the user need All the best. -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [Qgis-developer] GRASS QGIS: the future
Dear all, From my user perspective (I am using both GRASS and QGIS, or the other way around, depends on topic), processing is not really a replacement for the GRASS plugin. It is handy and probably better for those who do not use GRASS but are interested in single functions / modules. Yet, once you have a GRASS database with a considerable amount of data, the GRASS plugin is very valuable for accessing those data in QGIS (e.g. for cartography). Also users with no or little GRASS experience benefit from the GRASS plugin in cases where they have access to a GRASS database. That way they can work on it without acquainting themselves with a new GIS in depth... Concluding, if you have the possibility to maintain it, keep the GRASS plugin in QGIS! Cheers Stefan -Original Message- From: qgis-developer-boun...@lists.osgeo.org [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Paolo Cavallini Sent: 27. mars 2014 12:41 To: Nathan Woodrow Cc: qgis-developer; grass-dev Subject: Re: [Qgis-developer] GRASS QGIS: the future Il 27/03/2014 12:33, Nathan Woodrow ha scritto: I would vote for dropping the plugin and just updating the processing plugin. Having both ways is bad for us and bad for users, even worse when some functions are missing from one but not in the other. I understand well the point; however, the plugin has additional functions, e.g.: * a grass shell * a grass data browser * a grass digitizing environment. Whether these are important or not, it's a matter of users. All the best. -- Paolo Cavallini - www.faunalia.eu QGIS PostGIS courses: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list qgis-develo...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1915: v.out.ogr: problem to export certain column(s)
#1915: v.out.ogr: problem to export certain column(s) --+- Reporter: neteler | Owner: grass-dev@… Type: defect | Status: closed Priority: normal | Milestone: 7.0.0 Component: Vector | Version: svn-trunk Resolution: invalid |Keywords: v.out.ogr, wxGUI Platform: Linux| Cpu: All --+- Changes (by neteler): * status: new = closed * resolution: = invalid -- Ticket URL: http://trac.osgeo.org/grass/ticket/1915#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] #578: quote column names to avoid SQL reserved word collision
#578: quote column names to avoid SQL reserved word collision ---+ Reporter: hamish | Owner: grass-dev@… Type: enhancement| Status: new Priority: minor | Milestone: 7.0.0 Component: Vector | Version: svn-develbranch6 Keywords: v.in.ogr, SQL |Platform: All Cpu: All| ---+ Comment(by neteler): For SQL reserved word collisions, see also #1755 -- Ticket URL: http://trac.osgeo.org/grass/ticket/578#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] #1755: Need error message to indicate reserved words in SQLite
#1755: Need error message to indicate reserved words in SQLite ---+ Reporter: cmbarton | Owner: grass-dev@… Type: enhancement| Status: new Priority: normal | Milestone: 7.0.0 Component: Vector | Version: unspecified Keywords: v.net.centrality, SQL |Platform: Unspecified Cpu: Unspecified| ---+ Changes (by neteler): * keywords: v.net.centrality = v.net.centrality, SQL Comment: For SQL reserved word collisions, see also #578 -- Ticket URL: http://trac.osgeo.org/grass/ticket/1755#comment:4 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] #1930: Quote column names when creating tables via sqlite
#1930: Quote column names when creating tables via sqlite -+-- Reporter: scw | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Database | Version: unspecified Keywords: sqlite, SQL |Platform: Unspecified Cpu: Unspecified | -+-- Changes (by neteler): * keywords: sqlite = sqlite, SQL Comment: For SQL reserved word collisions, see also #1755 and #578 -- Ticket URL: http://trac.osgeo.org/grass/ticket/1930#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] #2235: r.param.scale crashes during compile for revision 59387 on Ubuntu 12.0.4 x64
#2235: r.param.scale crashes during compile for revision 59387 on Ubuntu 12.0.4 x64 ---+ Reporter: dnewcomb | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Raster | Version: svn-trunk Keywords: r.param.scale |Platform: Linux Cpu: x86-64 | ---+ Comment(by annakrat): Replying to [comment:2 hamish]: A small tweak was needed to the recent r59345, The string '3-499\0' needs room for at least 6 chars and it was only given 4. Try #59389. Sorry for that, I had there just 499 and I changed it later without enlarging the buffer. And it didn't crash for me. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2235#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] #2235: r.param.scale crashes during compile for revision 59387 on Ubuntu 12.0.4 x64
#2235: r.param.scale crashes during compile for revision 59387 on Ubuntu 12.0.4 x64 ---+ Reporter: dnewcomb | Owner: grass-dev@… Type: defect| Status: closed Priority: normal| Milestone: 7.0.0 Component: Raster| Version: svn-trunk Resolution: fixed |Keywords: r.param.scale Platform: Linux | Cpu: x86-64 ---+ Changes (by annakrat): * status: new = closed * resolution: = fixed -- Ticket URL: https://trac.osgeo.org/grass/ticket/2235#comment:4 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] #1828: v.kernel's Standard deviation in map units field is not clear
#1828: v.kernel's Standard deviation in map units field is not clear -+-- Reporter: arencambre | Owner: grass-dev@… Type: defect | Status: closed Priority: normal | Milestone: 7.0.0 Component: Vector | Version: 6.4.2 Resolution: fixed |Keywords: v.kernel Platform: All | Cpu: x86-64 -+-- Changes (by mlennert): * status: new = closed * resolution: = fixed Comment: Replying to [comment:3 neteler]: Is this solved? AFAIU, yes, so closing. Moritz -- Ticket URL: https://trac.osgeo.org/grass/ticket/1828#comment:4 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.stream.* to trunk - what about r.stream.basins?
hi, at the Vienna Code Sprint we're discussing moving the r.stream.* -modules to trunk. transition most of the r.stream.* is clear, but there may be some overlapping between r.water.outlet, r.watershed and r.stream.basins. short comparison - r.water.outlet [2] generates a watershed basin from a drainage direction map and a set of coordinates representing the outlet point of watershed. - r.stream.basins [1] is prepared to delineate basins and subbasins with different input data. It can delineate basins with three methods: Using coordinates: this option simply copies functionality of r.water.outlet. Using vector points: it allow to manually point outlets with any method Using streams (most advanced): it allow on lots of modifications. See examples for more details. This module is prepared to delineate unrestricted number of basins in one step. - r.watershed [3]: basin Output map: Unique label for each watershed basin. Each basin will be given a unique positive even integer. Areas along edges may not be large enough to create an exterior watershed basin. 0 values indicate that the cell is not part of a complete watershed basin in the current geographic region. as cloning/doubling functionality should be avoided, how to proceed now to with these partly overlapping modules? to the aim of avoiding duplicates in the core, we would like to have your feedback about the following options: 1) to keep r.stream.basins as an add-on, demanding the delineation of multiple subbasins from coordinates to a user´s script looping r.water.outlet; 2) to include r.stream.basins and keep also r.water.outlet; 3) to include r.stream.basins in the core and remove r.water.outlet as obsolete. 4) ? regards from Vienna Madi, Helmut [1] http://grass.osgeo.org/grass70/manuals/addons/r.stream.basins.html [2] http://grass.osgeo.org/grass70/manuals/r.water.outlet.html [3] http://grass.osgeo.org/grass70/manuals/r.watershed.html - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/r-stream-to-trunk-what-about-r-stream-basins-tp5131543.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1247: v.to.rast should provide SQL WHERE filtering option
#1247: v.to.rast should provide SQL WHERE filtering option --+- Reporter: marisn | Owner: grass-dev@… Type: enhancement | Status: closed Priority: minor| Milestone: 7.0.0 Component: Vector | Version: unspecified Resolution: fixed|Keywords: v.to.rast Platform: Unspecified | Cpu: Unspecified --+- Changes (by neteler): * keywords: = v.to.rast * status: new = closed * resolution: = fixed Comment: This has been implemented some time ago: http://grass.osgeo.org/grass70/manuals/v.to.rast.html Closing. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1247#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] #1058: d.geodesic,d.rhumbline
#1058: d.geodesic,d.rhumbline --+- Reporter: paoloC | Owner: grass-dev@… Type: enhancement | Status: closed Priority: normal | Milestone: 7.0.0 Component: Vector | Version: svn-trunk Resolution: fixed|Keywords: rhumbline, geodesic Platform: All | Cpu: All --+- Changes (by neteler): * status: new = closed * resolution: = fixed Comment: Replying to [ticket:1058 paoloC]: d.geodesic and d.rhumbline are two interesting tools, especially in educational courses, but they are no longer supported in grass 7.0. Is it possible to have them in wxGUI ? Yes, they are available for some time through the Add various overlays icon. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1058#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] [Qgis-developer] GRASS QGIS: the future
That sounds very reasonable to me. Proper GDAL/OGR handling for GRASS 7 would be very nice in any case (see http://trac.osgeo.org/gdal/ticket/2953). As for a GRASS data browser, I think, a plugin would be required with regards to user friendliness, because one needs to know what files to access from a GRASS data base when using GDAL. I also understand that at some point in time one will have to use GRASS directly in order to access full functionality (e.g. ortho-rectification, nviz, mapswipe, animation and stuff), which makes the way Moritz suggests maybe even more reasonable... Cheers Stefan -Original Message- From: Moritz Lennert [mailto:mlenn...@club.worldonline.be] Sent: 27. mars 2014 13:36 To: Blumentrath, Stefan Cc: Paolo Cavallini; Nathan Woodrow; qgis-developer; grass-dev Subject: Re: [GRASS-dev] [Qgis-developer] GRASS QGIS: the future I'm not much of a QGIS-as-GRASS-frontend user, either, but from a general point of view I also think that duplication is a problem and that the current way to go in QGIS is the processing framework. So; On 27/03/14 12:49, Blumentrath, Stefan wrote: I understand well the point; however, the plugin has additional functions, e.g.: * a grass shell couldn't this be implemented within the processing environment ? * a grass data browser If we are talking about accessing GRASS data for loading into QGIS, wouldn't it be a better idea to improve the GDAL/OGR handling in order to be able to load GRASS data just like any other data format ? * a grass digitizing environment. Maybe this could be split out into a specific plugin ? Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1078: v.split needs metric lengths options in LAT/LON
#1078: v.split needs metric lengths options in LAT/LON --+- Reporter: achim| Owner: grass-dev@… Type: enhancement | Status: closed Priority: normal | Milestone: 7.0.0 Component: Vector | Version: svn-trunk Resolution: fixed|Keywords: v.split, lat/lon, length Platform: Unspecified | Cpu: Unspecified --+- Changes (by neteler): * status: new = closed * resolution: = fixed -- Ticket URL: http://trac.osgeo.org/grass/ticket/1078#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] #1361: GSoC v.net.* modules should have nlayer option
#1361: GSoC v.net.* modules should have nlayer option -+-- Reporter: mlennert | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.0.0 Component: Vector | Version: unspecified Keywords: vector, network, node costs |Platform: All Cpu: Unspecified | -+-- Comment(by neteler): What is the state of the backport to relbranch64? -- Ticket URL: http://trac.osgeo.org/grass/ticket/1361#comment:4 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] #1789: v.hull: should not use
#1789: v.hull: should not use --+- Reporter: neteler | Owner: grass-dev@… Type: enhancement | Status: closed Priority: normal | Milestone: 7.0.0 Component: Vector | Version: svn-releasebranch64 Resolution: fixed|Keywords: v.hull Platform: All | Cpu: All --+- Changes (by neteler): * status: new = closed * resolution: = fixed -- Ticket URL: http://trac.osgeo.org/grass/ticket/1789#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 7: v.to.rast -d produces empty raster when used on areas
Hi, Converting areas from vector to raster with the -d flag (dense lines) in GRASS 7 results in an empty raster map. Both on Windows and Linux. Is that because boundaries are not lines or would you consider it as a bug? If the latter is the case, should I file a ticket? Cheers Stefan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1860: v.extract should support 'group by' sql statement
#1860: v.extract should support 'group by' sql statement -+-- Reporter: lucadelu | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.0.0 Component: Vector | Version: svn-trunk Keywords: v.extract|Platform: All Cpu: All | -+-- Changes (by neteler): * keywords: = v.extract -- Ticket URL: http://trac.osgeo.org/grass/ticket/1860#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] #2035: v.kcv optimization
#2035: v.kcv optimization -+-- Reporter: mmetz| Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 6.4.4 Component: Vector | Version: svn-trunk Keywords: v.kcv|Platform: Unspecified Cpu: Unspecified | -+-- Changes (by neteler): * milestone: 7.0.0 = 6.4.4 Comment: Replying to [comment:3 mmetz]: The attached patch is for GRASS 6.4.3 for those interested. Backported to devbranch65 in r59417. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2035#comment:4 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] [Qgis-developer] GRASS QGIS: the future
On Thu, Mar 27, 2014 at 9:38 AM, Blumentrath, Stefan stefan.blumentr...@nina.no wrote: I also understand that at some point in time one will have to use GRASS directly in order to access full functionality (e.g. ortho-rectification, nviz, mapswipe, animation and stuff), which makes the way Moritz suggests maybe even more reasonable... I hope that we find the way to start these tools from QGIS. Tck/Tk nviz is starting in this way. I hope that it will be possible to do the same for g.gui.* modules. Also, it would be nice if the QGIS GRASS vector digitizer (plugin/tool) would use the same backend as vector digitizer in GRASS wxGUI (Python subprocessing exit-safe wrapper). Now the first problem is that there is no reusable backend in wxGUI. Vaclav ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [Qgis-developer] GRASS QGIS: the future
In the gvSIG CE project, we had to make the same
type of decisions and came to our own conclusions.
Allow me to summarize our reasoning, maybe it will be
useful for the QGIS project, as well:
1. The number one cause of irritations among novice
users is having to set up a GRASS mapset and having
to understand how GRASS data management works.
2. The number two cause of irritations are the effects
of importing vector data with bad topology into a
GRASS mapset.
3. The original QGIS plugin does nothing to alleviate (1).
No plug-in, however cleverly designed, can do anything
about (2): garbage in, garbage out.
4. GRASS power users gain very little (if anything)
from running GRASS through a host GIS, such as QGIS
or gvSIG. But they do lose functionality, such as the
d.* family of modules.
Therefore, we gave up trying to design a plug-in for
advanced users. We assume that such users will use
GRASS through its native CLI and/or native GUI.
The resulting design of the original SEXTANTE-GRASS
interface (which is now also mirrored in the Python
re-write that became QGIS' Processing) addresses users
that either don't care much for GRASS' CLI capabilities
and internal data management, or are willing to switch to
native GRASS as needed.
If you want to change this and address another type
of user, then you will need to re-examine the entire design
of the current SEXTANTE/Processing approach, which is to use
only temporary mapsets and perform data import/export every
time a GRASS module is run.
You can optimize the I/O performance of Processing by using
r.external to directly access raster input maps. But there
is little you can do about vector data with the current
design, as GRASS needs to build its own topological data
structures (and rebuild them every time you run a GRASS module
on non-topological input!).
In any case, I do not think that it is worth maintaining
the original QGIS plugin, since it is neither very well
suited for novice nor advanced users, IMHO.
Best,
Ben
On 27/03/14 14:38, Blumentrath, Stefan wrote:
That sounds very reasonable to me.
Proper GDAL/OGR handling for GRASS 7 would be very nice in any case (see
http://trac.osgeo.org/gdal/ticket/2953).
As for a GRASS data browser, I think, a plugin would be required with
regards to user friendliness, because one needs to know what files to access
from a GRASS data base when using GDAL.
I also understand that at some point in time one will have to use GRASS
directly in order to access full functionality (e.g. ortho-rectification,
nviz, mapswipe, animation and stuff), which makes the way Moritz suggests
maybe even more reasonable...
Cheers
Stefan
-Original Message-
From: Moritz Lennert [mailto:mlenn...@club.worldonline.be]
Sent: 27. mars 2014 13:36
To: Blumentrath, Stefan
Cc: Paolo Cavallini; Nathan Woodrow; qgis-developer; grass-dev
Subject: Re: [GRASS-dev] [Qgis-developer] GRASS QGIS: the future
I'm not much of a QGIS-as-GRASS-frontend user, either, but from a general
point of view I also think that duplication is a problem and that the current
way to go in QGIS is the processing framework. So;
On 27/03/14 12:49, Blumentrath, Stefan wrote:
I understand well the point; however, the plugin has additional functions,
e.g.:
* a grass shell
couldn't this be implemented within the processing environment ?
* a grass data browser
If we are talking about accessing GRASS data for loading into QGIS, wouldn't
it be a better idea to improve the GDAL/OGR handling in order to be able to
load GRASS data just like any other data format ?
* a grass digitizing environment.
Maybe this could be split out into a specific plugin ?
Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
bendu...@fastmail.fm
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2121: v.rast.stats: allow choice of statistics
#2121: v.rast.stats: allow choice of statistics --+- Reporter: mlennert | Owner: grass-dev@… Type: enhancement | Status: closed Priority: normal | Milestone: 7.0.0 Component: Vector | Version: svn-trunk Resolution: fixed|Keywords: v.rast.stats Platform: Unspecified | Cpu: Unspecified --+- Changes (by lucadelu): * status: new = closed * resolution: = fixed Comment: Ticket completed, closing it. Please reopen if needed -- Ticket URL: http://trac.osgeo.org/grass/ticket/2121#comment:14 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 QGIS: the future
Hi Paolo, 2014-03-27 11:18 GMT+01:00 Paolo Cavallini cavall...@faunalia.it: Hi all. I learned during dinner that GRASS7 RC1 is due very soon. This opens the issue of its functioning in QGIS. IMHO: * the qgis-grass-plugin might stop working (this has to be tested) Yes, it will stop working, since the API in GRASS7 has changed (Raster API functions have now Rast_ as prefix). Besides of that must the cmake files be modified to detect GRASS7. * some of the module options will be different * new modules will not be available in QGIS. Yes, but this shouldn't be a problem if the module interface description created by the GRASS modules itself was used to generate the module interface in QGIS. New and modified modules will not work if the interfaces are handcrafted. I think we can deal with this in several ways: * dropping the plugin, and concentrate the work on Processing That is IMHO not a good idea. I think to provide the full functionality of GRASS7 to QGIS user, this plugin should be maintained and updated to support the new GRASS7 API. Handling and processing of massive datasets, especially time series, is only meaningful if GRASS is used as data storage as well. The processing interface will add massively overhead in data processing. The temporary location/mapset creation approach is not well suited to process massive data, even though r.external and v.external are used to link external data temporary into GRASS. * upgrading both the plugin and Processing. Yes, that's the way to go. In the first case, we have two major issues: * upgrading Processing GRASS modules * changing the current Processing behaviour, avoiding the import-export phase when piping consecutive GRASS commands; this makes GRASS modules slower than the equivalent commands of other backends. While the first issue can be solved easily by a couple of people in a few days, the second one is more tricky, and requires hard coding skills. In addition, we'll no longer be able to edit GRASS vectors directly. In the second case, we'll have more work, and a not-so-nice duplication. I would like to have an open discussion on this, avoiding things to just happen, with the possible negative consequences. My suggestion would be: Full integration of the GRASS7 into QGIS via C++ or Python plugin. This includes the temporal GIS capabilities as well. The existing plugin is a very good start point, lots its functionality can be reused, especially the vector editing, grass shell and map management. But there is a major problem with the GRASS QGIS plugin: it links directly to the grass libraries and calls plenty of functions that can QGIS cause to crash in case of an error. We face the same problem in GRASS with the vector editing tools. My solution would be to use a RPC (Remote Procedure Call) interface to calls GRASS library functions in a remote process using binary data for inter-process communication. IMHO the best tool for this is apache thrift[1] which allows us to implement a RPC interface in GRASS7 to the needed library functions. IMHO the number of RPC functions is limited since only vector editing, raster map rendering and some map/stds management functions are needed for direct access, all other functionality is provided by GRASS modules. So the first step is to implement an RPC interface in GRASS7, that supports C/C++, Java, Python and JavaScript on the client side out of the box. This interface can be used by the GRASS GUI itself to implement exit safe vector editing and it can be used by QGIS and other nice GIS desktop systems to provide GRASS database access, fast raster rendering and vector edit functionality. The beauty of this approach is, that the client side (the QGIS plugin for example) do not need to link against GRASS libraries, since it will communicate via pipes or sockets with one or several persistent GRASS7 processes, which can be restarted in case of a fatal error. The client side do not need to be updated in case the GRASS7 API changes again, only the server side which will be implemented in GRASS7 must be updated. Implementation effort In case of the QGIS plugin: All direct GRASS dependencies and function calls must be removed and replaced by the client RPC solution. Hence the provider classes needs to be rewritten, the C++ plugin code itself needs to be modified to support the new interface datatypes that are used for inter-process communication. Access to the temporal GIS functionality must be implemented to list space time datasets. What do you think about this approach? Best regards Soeren [1] https://thrift.apache.org/ All the best. -- Paolo Cavallini - www.faunalia.eu QGIS PostGIS courses: http://www.faunalia.eu/training.html ___ 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
Re: [GRASS-dev] [GRASS GIS] #2230: 'g.region -p' writes new WIND file, causes race condition for parallel jobs
#2230: 'g.region -p' writes new WIND file, causes race condition for parallel jobs --+- Reporter: hamish| Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 6.4.4 Component: Default | Version: svn-develbranch6 Keywords: g.region |Platform: Linux Cpu: x86-64| --+- Comment(by wenzeslaus): So, looking at r59383, r59386, r59387 and r59391, what is the set of `g.region` flags which should be used by default when scripting. If the region (WIND file) cannot be changed by default, why `g.region` is changing it? If the region (WIND file) needs to be changed by default, we should put a big warning to documentation about scripting (which can be always parallelized). I think that the issue is essentially that people don't realise that g.region always sets the region unless -u is given. Again, as in previous paragraph, this is a documentation issue. This is not expected behavior and it is not properly documented. Also I don't understand why it is necessary to write the WIND file in `g.region` if the content was not changed. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2230#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] #1910: GIS manager: allow dataset managing directly
#1910: GIS manager: allow dataset managing directly ---+ Reporter: timmie | Owner: grass-dev@… Type: enhancement| Status: new Priority: normal | Milestone: 7.0.0 Component: wxGUI | Version: unspecified Keywords: map management, layer manager |Platform: Unspecified Cpu: Unspecified| ---+ Comment(by pvanbosgeo): If I may add my opinion, I think adding these 2-3 items to the context menu would be a great addition. The easy of use this would offer would easily outweigh, i.m.h.o., the possible disadvantage of a longer context menu (I actually think it isn't that long in any case). If the length of the context menu is really a problem, an alternative could maybe to have two or three buttons next to the layer name (now there is one, which offers the same context menu as when using right click). Using e.g., three buttons, one can have one for all options related to the visualization (opacity, zoom, rename, remove, etc), one for report options (profile, metadata, histogram) and one for file / data-set operations. Just my 2ct. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1910#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] #2152: cd command does not work in GUI Command console
#2152: cd command does not work in GUI Command console -+-- Reporter: wenzeslaus | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.0.0 Component: wxGUI| Version: 6.4.3 Keywords: cd, command console |Platform: All Cpu: Unspecified | -+-- Comment(by glynn): Replying to [comment:6 wenzeslaus]: There is really no `cd` executable. If the shell runs an external program, it has to do so in a child process. A cd program would change the current directory of the child process running the cd program, which is of no use to anyone. Some built-in shell commands are built-in for convenience or efficiency. cd is built in because it has to be; only the shell itself can change its current directory. Likewise for export and ulimit. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2152#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
Re: [GRASS-dev] GRASS QGIS: the future
Hi, This approach is pretty to what the IPython developers implemented with their HTM5+JS interface to the IPython Kernel. (IPython Notebook) As RPC interface, IPython is using pyzmq (based on zeromq). IPython has a already a QtConsole with “inline plot” that can easily replace the Qgis python shell. This will give us inline plot to implement the ,missed d.* capabilities of grass 5.* and 6.* as well as direct call to grass commands (in IPython any system call can be performed using the prefix “!”) and using the “!” prefix or the %%BASH magic we can call any grass module, if the GRASS envs are properly exported. I’m on a mac osx 64 bit, is almost 3 years i can not use grass GUI because of the WxPython interface that doesn’t support 64 bit on osx, and i found in this approach the only way to let me use GRASS in a productive way(now that tcltk is removed) Recent development in IPYthon enabled the ability to build complex widget based on query or othe r JS libs thanks to the “interact-widget” API I was planning to reuse part of this technologies for the WebGRASS interface, mixing IPython and PyWT. I’m catching a fight right now, this video is almost “old” but shows how the widget interact API works : http://www.frequency.com/video/ipython-attributes-ofsoftware-how-they/135236136/-/5-1851523 i like the RPC approach, and i guess we can reuse the ipython sw to implement this capabilities. please apologize me if i went OFF topic .. Massimo. On Mar 27, 2014, at 11:17 AM, Sören Gebbert soerengebb...@googlemail.com wrote: Hi Paolo, 2014-03-27 11:18 GMT+01:00 Paolo Cavallini cavall...@faunalia.it: Hi all. I learned during dinner that GRASS7 RC1 is due very soon. This opens the issue of its functioning in QGIS. IMHO: * the qgis-grass-plugin might stop working (this has to be tested) Yes, it will stop working, since the API in GRASS7 has changed (Raster API functions have now Rast_ as prefix). Besides of that must the cmake files be modified to detect GRASS7. * some of the module options will be different * new modules will not be available in QGIS. Yes, but this shouldn't be a problem if the module interface description created by the GRASS modules itself was used to generate the module interface in QGIS. New and modified modules will not work if the interfaces are handcrafted. I think we can deal with this in several ways: * dropping the plugin, and concentrate the work on Processing That is IMHO not a good idea. I think to provide the full functionality of GRASS7 to QGIS user, this plugin should be maintained and updated to support the new GRASS7 API. Handling and processing of massive datasets, especially time series, is only meaningful if GRASS is used as data storage as well. The processing interface will add massively overhead in data processing. The temporary location/mapset creation approach is not well suited to process massive data, even though r.external and v.external are used to link external data temporary into GRASS. * upgrading both the plugin and Processing. Yes, that's the way to go. In the first case, we have two major issues: * upgrading Processing GRASS modules * changing the current Processing behaviour, avoiding the import-export phase when piping consecutive GRASS commands; this makes GRASS modules slower than the equivalent commands of other backends. While the first issue can be solved easily by a couple of people in a few days, the second one is more tricky, and requires hard coding skills. In addition, we'll no longer be able to edit GRASS vectors directly. In the second case, we'll have more work, and a not-so-nice duplication. I would like to have an open discussion on this, avoiding things to just happen, with the possible negative consequences. My suggestion would be: Full integration of the GRASS7 into QGIS via C++ or Python plugin. This includes the temporal GIS capabilities as well. The existing plugin is a very good start point, lots its functionality can be reused, especially the vector editing, grass shell and map management. But there is a major problem with the GRASS QGIS plugin: it links directly to the grass libraries and calls plenty of functions that can QGIS cause to crash in case of an error. We face the same problem in GRASS with the vector editing tools. My solution would be to use a RPC (Remote Procedure Call) interface to calls GRASS library functions in a remote process using binary data for inter-process communication. IMHO the best tool for this is apache thrift[1] which allows us to implement a RPC interface in GRASS7 to the needed library functions. IMHO the number of RPC functions is limited since only vector editing, raster map rendering and some map/stds management functions are needed for direct access, all other functionality is provided by GRASS modules. So the first step is to implement an RPC interface in GRASS7, that
Re: [GRASS-dev] [GRASS GIS] #1719: GRASS 7 Monitor command line support
#1719: GRASS 7 Monitor command line support --+- Reporter: annalisapg | Owner: grass-dev@… Type: enhancement | Status: reopened Priority: normal | Milestone: 7.0.0 Component: wxGUI| Version: svn-trunk Resolution: |Keywords: d.mon, display, d.* commands, rendering Platform: Unspecified | Cpu: Unspecified --+- Comment(by glynn): Replying to [comment:27 hamish]: We want to use the d.* commands on a real command line without the GUI, as is done with Xmons in earlier GRASSes. So in a separate, super light- weight window with no toolbar or other visual clutter. Just a command line and a viewport window. i.e. enhance something similar to ximgview or wximgview with a right click menu for minimal interactivity. See comment:4 and d.mon2.py in grass7 addons for a partial hack of making it a bit easier to achieve this. An alternative approach is to modify D_open_driver() to allow display commands to be redirected. E.g. if the environment variable GRASS_RENDER_COMMAND is set, D_open_driver() would treat its value as the name of a program. It would execute the specified program with the original command line (program name and arguments) as arguments, then exit. Such a program would typically be a remote control program which sends the command line (via DDE, TCP, or whatever) to a display server (which could be wxGUI or something simpler). The main reason for delegating to an external command is that it avoids enforcing a specific communication protocol, or embedding the details into lib/display, which would be an issue for high-level protocols such as Windows' DDE or Python's pickle format. Display commands which are implemented as scripts using other d.* commands would need to implement this mechanism themselves, so that the display server sees the original script, not the individual d.* commands. -- Ticket URL: https://trac.osgeo.org/grass/ticket/1719#comment:28 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] #2230: 'g.region -p' writes new WIND file, causes race condition for parallel jobs
#2230: 'g.region -p' writes new WIND file, causes race condition for parallel jobs --+- Reporter: hamish| Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 6.4.4 Component: Default | Version: svn-develbranch6 Keywords: g.region |Platform: Linux Cpu: x86-64| --+- Comment(by glynn): Replying to [comment:3 wenzeslaus]: what is the set of `g.region` flags which should be used by default when scripting. If you only want to read the region, use the -u flag. This is not expected behavior and it is not properly documented. Agreed; I overlooked it when writing the grass.script.core Python module. Also I don't understand why it is necessary to write the WIND file in `g.region` if the content was not changed. It's not simple to tell whether the content was changed, i.e. whether the region which is printed will match the contents of the WIND file. When the region is changed explicitly (via the -d flag or any option other than save=), it's reasonable to assume that the updated region doesn't match the WIND file. But the absence of those options doesn't necessarily mean that writing to WIND (or $WIND_OVERRIDE) will be a no-op. If the behaviour was changed so that WIND was only written when one of those options was used, that would technically be a change to the long- standing behaviour, but we would probably get away with it. Probably. Maybe that's close enough; I have no particular opinion on that. However: we'd need to add a -f (force) flag, otherwise there'd be no way to copy the $GRASS_REGION value to WIND/$WIND_OVERRIDE, or to perform just the adjustment (G_adjust_Cell_head3). -- Ticket URL: https://trac.osgeo.org/grass/ticket/2230#comment:4 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] #2235: r.param.scale crashes during compile for revision 59387 on Ubuntu 12.0.4 x64
#2235: r.param.scale crashes during compile for revision 59387 on Ubuntu 12.0.4 x64 ---+ Reporter: dnewcomb | Owner: grass-dev@… Type: defect| Status: closed Priority: normal| Milestone: 7.0.0 Component: Raster| Version: svn-trunk Resolution: fixed |Keywords: r.param.scale Platform: Linux | Cpu: x86-64 ---+ Comment(by hamish): Replying to [comment:3 annakrat]: And it didn't crash for me. a guess- recent versions of Debian (and thus Ubuntu) packaging rules add hardening flags to the compiler CFLAGS. I believe one of the results of this is that it forces programs to crash instead of continuing on in a memory-corrupted state. It also adds a number of warnings to the compile log when it suspects something bad could happen. see https://wiki.debian.org/Hardening You only get those flags for a self-compile if you add them manually or if you use the package build scripts. regards, Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/2235#comment:5 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 7.0.0beta1 released
Greetings from the Vienna Code Sprint! We have prepared a first beta release of GRASS GIS 7.0.0: Source code package: http://grass.osgeo.org/grass70/source/ - grass-7.0.0beta1.tar.gz SVN branch: http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_7_0 SVN tag: http://trac.osgeo.org/grass/browser/grass/tags/release_20140327_grass_7_0_0beta1 Please test on any platform. Regards, Markus and the GRASS GIS community sprinters ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1789: v.hull: should not be region sensitive (was: v.hull: should not use)
#1789: v.hull: should not be region sensitive --+- Reporter: neteler | Owner: grass-dev@… Type: enhancement | Status: closed Priority: normal | Milestone: 7.0.0 Component: Vector | Version: svn-releasebranch64 Resolution: fixed|Keywords: v.hull Platform: All | Cpu: All --+- -- Ticket URL: http://trac.osgeo.org/grass/ticket/1789#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 7: v.to.rast -d produces empty raster when used on areas
Stefan wrote: Converting areas from vector to raster with the -d flag (dense lines) in GRASS 7 results in an empty raster map. Both on Windows and Linux. Is that because boundaries are not lines or would you consider it as a bug? I think you are right, it is probably because boundaries are not lines. Or more specifically, in an area the centroid holds the category and attribute data, and the boundary is (typically) without category. (If a boundary is between two parcels of land, which farmer does the boundary belong to?) So if you wish to work on boundaries you have to v.extract them, then add categories with v.category. If you do that typically you'd want to run v.type as well to turn them into lines. It's probably worth a ticket in the trac system since in future others will try the same with type=area, just note that the thick raster line should probably be category 0 or so, not the adjoining area's cat number for the who does it belong to? reason above. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Compilation: hardening
Comment(by hamish): a guess- recent versions of Debian (and thus Ubuntu) packaging rules add hardening flags to the compiler CFLAGS. I believe one of the results of this is that it forces programs to crash instead of continuing on in a memory-corrupted state. It also adds a number of warnings to the compile log when it suspects something bad could happen. see https://wiki.debian.org/Hardening This might be very useful. Do you have some exact suggestion what flags to use? On Ubuntu 12.04 I get: $ dpkg-buildflags CFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security CPPFLAGS=-D_FORTIFY_SOURCE=2 CXXFLAGS=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security FFLAGS=-g -O2 LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro So, I will put this into my configure script wrapper. Vaclav You only get those flags for a self-compile if you add them manually or if you use the package build scripts. regards, Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/2235#comment:5 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 mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.statistics in G7
Hi, 2013-08-04 23:51 GMT+02:00 Martin Landa landa.mar...@gmail.com: would be nice to decide before we start releasing tech-previews. Martin for the record, after discussion in OSGeo Vienna Code Sprint - `r.statistics2` has been renamed in trunk to `r.stats.zonal` and `r.statistics3` to `r.stats.quantile`. Martin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] C and C++ standards used by GRASS
Hello, which C and C++ standards we are using? And which we want to use? Do we even care? Since we can always fix it if somebody wants to build GRASS on some other compiler than relatively new GCC. For example, lib/gis build fails with gcc option -std=c89 [1] because of missing `hypot` buildin [2]. I'm not sure if I already asked about it but I found only KR function discussion. Thanks, Vaclav [1] http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#Other-Builtins [2] http://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html#C-Dialect-Options PS: For Python, we have particular version specified (but for Python, it is more critical). ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1719: GRASS 7 Monitor command line support
#1719: GRASS 7 Monitor command line support --+- Reporter: annalisapg | Owner: grass-dev@… Type: enhancement | Status: reopened Priority: normal | Milestone: 7.0.0 Component: wxGUI| Version: svn-trunk Resolution: |Keywords: d.mon, display, d.* commands, rendering Platform: Unspecified | Cpu: Unspecified --+- Comment(by wenzeslaus): Replying to [comment:27 hamish]: Reopening, because it is an interesting unresolved discussion and should not be forgotten/flushed. see also comment:22. Please, create a new tickets with specification what you want and comparison with what we have. I'm not so experienced in `d.*` commands and older X monitors to know what exactly does comments here mean. Moreover, if we want some other people get involved, we should make tickets clear and doable (speaking for example about recent [http://lists.osgeo.org/pipermail/grass-dev/2014-March/067795.html request for GUI development ideas]). We don't want to type d.* commands into the wxGUI console and have them work in the GUI, (as works in the old gis.m tcl/tk GUI); that's nice, but I think it misses the point. Now I don't understand, I though you were proposing `d.*` commands for wxGUI in #893. We want to use the d.* commands on a real command line without the GUI, as is done with Xmons in earlier GRASSes. So in a separate, super light- weight window with no toolbar or other visual clutter. Just a command line and a viewport window. i.e. enhance something similar to ximgview or wximgview with a right click menu for minimal interactivity. I'm afraid that there will never be a right click in `ximgview`, `wximgview`, `wxpyimgview` because there will be no will to reimplement what is in wxGUI (although any patch would be accepted). For these modules, all `d.*` commands are working (if png or cairo divers are used), so there is nothing to implement. The non-working commands are the ones involving mouse, and this is the case of right click menu. Anyway, I like the idea of light weight GUI, it could be actually created now from existing wxGUI classes but it would duplicate a lot code from the main GUI map display, so it would be actually better to do some refactoring or customization for map display to achieve light weight GUI. On the other hand, the precise specification of the minimal functionality would really help in this case. With the precise information we can determine the minimal work which needs to be done to achieve the goal. See comment:4 and d.mon2.py in grass7 addons for a partial hack of making it a bit easier to achieve this. So, the only missing piece is to create `x`/`simple` driver in `d.mon` which would do what `d.mon2` is doing? regards, Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/1719#comment:29 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-user] GRASS GIS 7.0.0beta1 released
Hi devs, On Thu, Mar 27, 2014 at 4:13 PM, Markus Neteler nete...@osgeo.org wrote: Greetings from the Vienna Code Sprint! We have prepared a first beta release of GRASS GIS 7.0.0: thanks for your hard work! Source code package: http://grass.osgeo.org/grass70/source/ - grass-7.0.0beta1.tar.gz SVN branch: http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_7_0 SVN tag: http://trac.osgeo.org/grass/browser/grass/tags/release_20140327_grass_7_0_0beta1 Download from SVN: svn checkout https://svn.osgeo.org/grass/grass/branches/releasebranch_7_0 Please test on any platform. In the past months we have been using GRASS 7 for Helena's class assignments originally created for 6.4 and we haven't had any problems. Thanks again, Anna and Vaclav Regards, Markus and the GRASS GIS community sprinters ___ grass-user mailing list grass-u...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1719: GRASS 7 Monitor command line support
#1719: GRASS 7 Monitor command line support --+- Reporter: annalisapg | Owner: grass-dev@… Type: enhancement | Status: reopened Priority: normal | Milestone: 7.0.0 Component: wxGUI| Version: svn-trunk Resolution: |Keywords: d.mon, display, d.* commands, rendering Platform: Unspecified | Cpu: Unspecified --+- Comment(by wenzeslaus): Replying to [comment:28 glynn]: Replying to [comment:27 hamish]: We want to use the d.* commands on a real command line without the GUI, as is done with Xmons in earlier GRASSes. So in a separate, super light-weight window with no toolbar or other visual clutter. Just a command line and a viewport window. i.e. enhance something similar to ximgview or wximgview with a right click menu for minimal interactivity. See comment:4 and d.mon2.py in grass7 addons for a partial hack of making it a bit easier to achieve this. An alternative approach is to I'm afraid that we have more problems with the servers than with the connection. However, the wxGUI-based d.mon backend could use some alternative. Now `d.*` are writing to the file which the wxGUI application reads in regular time intervals. Approach you suggested might be more than a better replacement. modify D_open_driver() to allow display commands to be redirected. E.g. if the environment variable GRASS_RENDER_COMMAND is set, D_open_driver() would treat its value as the name of a program. It would execute the specified program with the original command line (program name and arguments) as arguments, then exit. It would be great if you would elaborate more on this idea now or in the future. (I'm not sure if I can extend it and consider all the issues.) For example, how switching between different `wx*` monitors and other applications (ximgview, g.gui) would be solved? Such a program would typically be a remote control program which sends the command line (via DDE, TCP, or whatever) to a display server (which could be wxGUI or something simpler). I think Soeren was actually suggesting this (Python multiprocessing communication for display commands and servers) somewhere but without this library calls another program part. This additional command might slow things down (?) but it seems necessary. The main reason for delegating to an external command is that it avoids enforcing a specific communication protocol, or embedding the details into lib/display, which would be an issue for high-level protocols such as Windows' DDE or Python's pickle format. But still, wouldn't be Windows' DDE or Python's pickle even more fragile (in any sense) than the current file-based approach? Display commands which are implemented as scripts using other d.* commands would need to implement this mechanism themselves, so that the display server sees the original script, not the individual d.* commands. Once there would be function in the library for it, this should not be a problem. -- Ticket URL: https://trac.osgeo.org/grass/ticket/1719#comment:30 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
