Re: [GRASS-dev] [GRASS GIS] #1049: optional histogram sidebar for legends
#1049: optional histogram sidebar for legends --+- Reporter: hamish| Owner: grass-dev@… Type: enhancement | Status: new Priority: minor | Milestone: 7.0.0 Component: Display | Version: svn-trunk Keywords: d.legend, ps.map |Platform: All Cpu: All | --+- Comment(by hamish): Hi, legend histogram sidebars added to d.legend in trunk with r60093. -- todo: support for CELL maps and constrained range=s. For CELL maps we can perhaps interpolate between dist_stats-mincat and dist_stats-maxcat ? I'm not sure how to get r.stats to deal with constrained range= while retaining pixel-height number of bins. Any ideas? Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/1049#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] #2083: Add 3D raster (volume) support to d.legend
#2083: Add 3D raster (volume) support to d.legend +--- Reporter: wenzeslaus | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.0.0 Component: Display | Version: svn-trunk Keywords: d.legend, raster3d |Platform: All Cpu: All | +--- Comment(by hamish): Replying to [comment:6 wenzeslaus]: Please review the patch, interface and tests here and/or test the new functionality (you can use GUI if you want). I would like to apply the patch soon and not to risk that some changes in GUI will break it. Hi, it's pretty good, I'll look at merging it ASAP. Other issue is that it is API break, since I'm replacing `map` by `rast`. This would be concern if this change would not be applied also to release branch. it's only for grass 7 which isn't released yet, so no problem to change the module options as long as a grep is done on scripts/, gui/, and grass- addons/ + html docs to make sure everything else is in sync. The module command line options for G7 are only hard frozen the day 7.0.0 ships. And then existing options will be completely frozen for many many years... thanks, Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/2083#comment:7 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] #2280: v.extract: allow random extraction based on feature ids, not only category values
#2280: v.extract: allow random extraction based on feature ids, not only
category
values
--+-
Reporter: mlennert | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal| Milestone: 7.0.0
Component: Vector| Version: svn-trunk
Keywords: v.extract category values random |Platform: Unspecified
Cpu: Unspecified |
--+-
I have a point vector file over 400,000 points) without attribute table.
The one relevant info is stored as a category value in layer 1.
I would like to extract at random a subset of 50,000 points. v.extract
random= seems like the ideal solution. However, there are only 687
different category values and thus v.extract bails out with
{{{
ERREUR :Random category count is larger or equal to uniq
point,line,boundary,centroid,area,face feature category count
687
}}}
When I add category values to layer=2, I can then do the v.extract with
random=5, but it only extracts layer 2, so I lose the info in layer 1.
I can see two solutions:
- allow random selection in feature id space, not only in category space
- add flag to keep info from all other layers when extracting (which then
allows to do the extraction with the extra v.category step mentioned
above)
Moritz
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2280
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] #2281: t.rast.aggregate unnecessaryly slow with limited number of maps
#2281: t.rast.aggregate unnecessaryly slow with limited number of maps -+-- Reporter: sbl | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: |Platform: Unspecified Cpu: Unspecified | -+-- I was having some trouble with t.rast.aggregate which was much slower than running the same operation directly in r.series, making t.rast.aggregate almost useless (see performance comparison below). I tracked the problem down to the usage of the z-flag in r.series. Please find attached a patch for aggregation.py, which adds a check for the number of maps to be opened in r.series and uses the z- only if there is a danger for hitting a limit for open files (fix number of 1000 in the patch). g.region -up projection: 1 (UTM) zone: 33 datum: etrs89 ellipsoid: grs80 north: 800 south: 645 west: -75000 east: 112 nsres: 1000 ewres: 1000 rows: 1550 cols: 1195 cells: 1852250 time t.rast.aggregate input=temperature method=average output=test base=test granularity=1 months sampling=during where=start_time = '2012-12-01' AND start_time '2013-01-01' --o --v Percent complete... 100% Update metadata, spatial and temporal extent from all registered maps of real25m23.127s user9m56.357s sys 15m22.446s time r.series input=$(g.mlist type=rast pattern=tm_2012_12* separator=,) output=test method=average --o 100% real0m4.588s user0m3.492s sys 0m0.764s -- Ticket URL: http://trac.osgeo.org/grass/ticket/2281 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] #2282: r.external.out: keep GRASS maps and external files in sync
#2282: r.external.out: keep GRASS maps and external files in sync -+-- Reporter: sbl | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.1.0 Component: Default | Version: unspecified Keywords: |Platform: Unspecified Cpu: Unspecified | -+-- At the moment, GRASS maps and external files produced using r.external.out are not fully kept in sync. This applies both when maps are renamed or removed. Names of external files are not changed by g.rename and files are not deleted by g.remove og g.mremove. If possible, it would be nice if GRASS maps and external files could be kept in sync in order to keep the relations between them clear and for not accumulating unused data (map files a user might think he deleted when running g.remove). At least for maps produced with r.external.out this would be nice (though maybe not for maps linked with r.external...). -- Ticket URL: http://trac.osgeo.org/grass/ticket/2282 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] #2083: Add 3D raster (volume) support to d.legend
#2083: Add 3D raster (volume) support to d.legend
+---
Reporter: wenzeslaus | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.0.0
Component: Display | Version: svn-trunk
Keywords: d.legend, raster3d |Platform: All
Cpu: All |
+---
Comment(by hamish):
ok, done in trunk, try = r60104.
I reworked most of the C code in the patch, but the python stuff was
applied verbatim.
some minor feedback/notes:
* changed enum defines to be less like official ones in include/*.h. Also
moved them into local_proto.h.
* to help code readability used TRUE and FALSE for boolean ints. (defined
in gis.h)
* no need to use {curly} brackets if the statement which follows is a
short one liner.
* if $(RASTER3DLIB) is added to the Makefile, $(RASTER3DDEP) needs to be
added too.
* still need to figure out the trick to launch the GUI when no options
are required but some option is required without asking the user to type '
--ui'.
* I added a new -c flag to `r3.stats` so that the new d.legend '-d'
histogram distribution flag will work for raster3d maps too.
please test.
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2083#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 GIS] #2143: d.legend: add option to output legend definition as text
#2143: d.legend: add option to output legend definition as text ---+ Reporter: wenzeslaus | Owner: grass-dev@… Type: enhancement| Status: new Priority: trivial| Milestone: 7.0.0 Component: Display| Version: svn-trunk Keywords: d.legend, text output |Platform: All Cpu: All| ---+ Comment(by hamish): the functionality asked for in this wish, as I understand it, seems already covered by r.colors.out and r.category, amongst others. ok to close it? Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/2143#comment:7 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] Multiple map frames in cartographic composer
Hi, I have no clue how difficult it would be to implement, but it would be great if there was the option in the cartographic composer to add more than one map frame (same goes for the other map items). Cheers, Paulo ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1049: optional histogram sidebar for legends
#1049: optional histogram sidebar for legends --+- Reporter: hamish| Owner: grass-dev@… Type: enhancement | Status: new Priority: minor | Milestone: 7.0.0 Component: Display | Version: svn-trunk Keywords: d.legend, ps.map |Platform: All Cpu: All | --+- Comment(by hamish): Hi, I've added to this ticket a screenshot of the new functionality. https://trac.osgeo.org/grass/attachment/ticket/1049/dleg_histo.png shown is a horizontal legend for elevation.10m from Spearfish drawn with a histogram (-d flag), flipped left-right (-f flag, but setting at= as max,min has the same effect [wxGUI currently seems to be sorting at=, so that isn't working from the mouse]), and since I set the data units= with r.support the legend now displays meters too without needing a separate call to d.text. the color rules there are a new addition as well, roygbiv. In the screenshot r.colors was run with the -e flag so the color scaling is set to equal areas under the histogram curve instead of a linear color transition from min to max. have fun, Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/1049#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] #2031: G_legal_filename() cleanup patch for GRASS 6
#2031: G_legal_filename() cleanup patch for GRASS 6 --+- Reporter: neteler | Owner: grass-dev@… Type: defect | Status: closed Priority: normal | Milestone: 6.4.4 Component: LibGIS | Version: svn-releasebranch64 Resolution: fixed|Keywords: Platform: All | Cpu: All --+- Comment(by glynn): Replying to [comment:8 martinl]: Is there any wiki (ideally on trac) page which collects ideas how to redesign the option descriptions? Not that I know of. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2031#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] [GRASS GIS] #2278: G__tempfile() lacks perror support
#2278: G__tempfile() lacks perror support -+-- Reporter: neteler | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: LibGIS | Version: svn-releasebranch70 Keywords: r.hants |Platform: Unspecified Cpu: Unspecified | -+-- Comment(by glynn): Replying to [ticket:2278 neteler]: For a better error message, perror() should be used: Ideally, strerror() (or similar) should be used, and the string included in the error message. Otherwise, the additional details will be omitted from any logfile ($GIS_ERROR_LOG) or email message ($GRASS_ERROR_MAIL). Except, strerror() isn't thread-safe (it returns a pointer to a static buffer). POSIX.1-2001 specifies strerror_r(), which requires the caller to supply a buffer. Windows doesn't have that, but it has strerror_s (same functionality, different argument order). So we'd need configure checks. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2278#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-SVN] r60048 - grass/trunk/vector/v.in.db
Huidae Cho wrote: BTW, I don't see Rast_open_old returning a negative value on failure as documented in the developer's manual. If this is clearly documented and fatal error is also mentioned, it would save unnecessary conditional checks against Rast_open_old. The 6.x versions (G_open_cell_old() etc) are documented as returning -1 on failure (at least in the Doxygen comments, which should end up in the manual). The 7.x versions (Rast_open_old() etc) raise fatal errors, so any checks for a negative return value would be redundant. Such checks should have been removed by r40215, but I can't rule out having missed some. In cases where the return value was purely a status indication, eliminating the status return resulted in the return type changing from int to void. Anything checking the (now-void) return value would result in a compilation error, so I doubt that I missed any. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r60054
Martin Landa wrote: 2014-05-03 15:49 GMT+02:00 svn_gr...@osgeo.org: Author: hcho Date: 2014-05-03 06:49:33 -0700 (Sat, 03 May 2014) New Revision: 60054 I would say that such invasive changes should be discussed in advance. Now the vector library goes in different direction that raster library The vector library has always used status returns; it's just that almost nothing bothered to actually check them. This patch just fixes many instances of a specific bug in one go. Personally, I would have fixed it by eliminating status returns; *that* would have qualified as an invasive change. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [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: closed Priority: normal | Milestone: 6.4.4 Component: Default | Version: unspecified Resolution: fixed|Keywords: Platform: Unspecified | Cpu: Unspecified --+- Changes (by mlennert): * status: new = closed * resolution: = fixed -- Ticket URL: https://trac.osgeo.org/grass/ticket/2276#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] #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 | -+-- Comment(by mlennert): Backported to all branches (including grass64_release). I still do think that we should develop a more clearcut policy on this, and have one person, or a team, decide what can and cannot go into a release branch. Moritz -- Ticket URL: https://trac.osgeo.org/grass/ticket/2276#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-SVN] r60054
Huidae Cho wrote: Simply calling fatal error and terminating the process may not be a good idea in some case where many leftover files need to be deleted. I believe at some point we need to standardize error handling. I feel that exit handlers (or similar) are the way to go here. We might want our own mechanism rather than using atexit(), so that it works even when longjmp()ing out of a fatal error handler. Apart from the global error handler (G_set_error_routine), we probably want to support multiple, non-exclusive handlers. [We may also want to support the ability to push/pop the global error handler so that it's possible to perform the equivalent of catching an exception then re-throwing it. But this needs feedback from anyone who happens to be using it (its only within GRASS is by 3 curses-based imagery modules, all of which are disabled, to restore the terminal).] For temporary files, I suggest adding a mode argument to the creation function to indicate whether the file should be: * deleted automatically upon fatal error * deleted automatically upon exit, successful or not * deleted (unlink()ed) immediately (on Unix) or on exit (Windows). * retained until explicitly deleted. Building this behaviour into the libraries rather than having the caller do it provides consistency. It also allows e.g. having an environment variable to suppress deletion of temporary files for debugging purposes. But still I agree that we need a better way to handle opening errors. I don't feel that it's worth attempting to recover from such errors, in the sense of continuing with normal execution. Clean up, then terminate. Users shouldn't specify non-existent or otherwise invalid maps as arguments, and shouldn't expect anything beyond an error message if they do. If there are specific cases where a map's existence shouldn't be taken for granted (e.g. the name was obtained from metadata which might be stale or otherwise inapplicable), we should use G_find_* before attempting to open it. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2278: G__tempfile() lacks perror support
#2278: G__tempfile() lacks perror support -+-- Reporter: neteler | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: LibGIS | Version: svn-releasebranch70 Keywords: r.hants |Platform: Unspecified Cpu: Unspecified | -+-- Comment(by mmetz): Replying to [ticket:2278 neteler]: (The problem arises from r.hants Addon use, reported on grass-user) Using r.hants (derived from r.series) on almost 600 raster maps generates an ERROR: no temp files available on Linux 64bit. r.series with the same number of input maps should fail with the same error. r.hants has been derived from r.series, and both modules have the -z flag (Don't keep files open) which should avoid this problem. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2278#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-SVN] r60054
Huidae Cho wrote: G_add_error_handler is a good way to do a cleanup, I had actually forgetten about the existence of this. But again, when they call fatal error internally, they don't have pointers to maps. It would be great if we could keep track of opened raster/vector maps and properly close existing maps and delete unfinished new maps inside G_fatal_error. And use G_add_error_handler to do a non-map related cleanup. Right. Anything related to raster maps is available through the R__ structure in lib/raster (R.h, init.c). R__.fileinfo is an array of fileinfo structures, with R__.fileinfo_count elements. The open_mode field of each structure will be -1 for unused slots, or one of the OPEN_* constants (1, 2, or 3) for an open map. We might want an OPEN_INCOMPLETE value for maps which are in the process of being opened; this would only be relevant for handling clean-up for fatal errors from within Rast_open_*. I'm not that familiar with the vector library, but it looks like everything relating to a map is stored in a Map_info structure which is passed in by the caller. There's no global table of vector maps, right? If so, I suggest changing that, however invasive it may be. I'd certainly suggest holding off on any 7.0 release until that's resolved. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2282: r.external.out: keep GRASS maps and external files in sync
#2282: r.external.out: keep GRASS maps and external files in sync -+-- Reporter: sbl | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.1.0 Component: Default | Version: unspecified Keywords: |Platform: Unspecified Cpu: Unspecified | -+-- Comment(by glynn): Replying to [ticket:2282 sbl]: At the moment, GRASS maps and external files produced using r.external.out are not fully kept in sync. This applies both when maps are renamed or removed. Names of external files are not changed by g.rename and files are not deleted by g.remove or g.mremove. This behaviour is intentional; well, maybe not entirely unintentional is more accurate. If that's to change, it would need to be e.g. an option set by r.external.out (for the default) and r.external (to allow it to be changed for individual maps). Certainly, it needs to be possible to delete the link which allows GRASS to treat the file as a raster map without deleting the file itself. And given that the existing g.remove behaviour is to remove the link but leave the actual data, I'm not sure that should change (i.e. removing both the link and the file needs a new flag, so no-one loses data unexpectedly). Essentially, GDAL-linked maps are somewhat like a symlink to a file. Using rm on a symlink deletes the symlink, not the file it refers to. Similarly for mv. The GRASS tools (g.remove, g.rename, g.copy etc) need to be able to manipulate the links. They don't necessarily have to be able to manipulate the files; the OS' own file-management tools can handle that. Although, in the case of renaming and copying, we should provide a convenient way to update/copy the links; running r.external requires providing all of the parameters again. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2282#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] #2278: G__tempfile() lacks perror support
#2278: G__tempfile() lacks perror support -+-- Reporter: neteler | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 7.0.0 Component: LibGIS | Version: svn-releasebranch70 Keywords: r.hants |Platform: Unspecified Cpu: Unspecified | -+-- Comment(by mmetz): Replying to [comment:2 mmetz]: Replying to [ticket:2278 neteler]: (The problem arises from r.hants Addon use, reported on grass-user) Using r.hants (derived from r.series) on almost 600 raster maps generates an ERROR: no temp files available on Linux 64bit. r.series with the same number of input maps should fail with the same error. r.hants has been derived from r.series, and both modules have the -z flag (Don't keep files open) which should avoid this problem. Sorry, the -z flag does not help here because r.hants creates a new output map for each input map, and these need to be kept open. For 600 input maps, the hard limit of the number of open files is usually exceeded. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2278#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] Multiple map frames in cartographic composer
Hi, ps.map doesn't support multiple map frames directly, only through eps instruction: http://grasswiki.osgeo.org/wiki/Psmap_multi_pane_example Composer is just a graphical front-end to ps.map. It could run ps.map on more map frames and display them via eps instruction (automate what the user has to do) but it seems to be quite a lot of work. So, so far you have to do it manually. Anna On Mon, May 5, 2014 at 7:14 AM, Paulo van Breugel p.vanbreu...@gmail.comwrote: Hi, I have no clue how difficult it would be to implement, but it would be great if there was the option in the cartographic composer to add more than one map frame (same goes for the other map items). Cheers, Paulo ___ 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] Multiple map frames in cartographic composer
Ok, thanks for the feedback. On 5 May 2014 16:18, Anna Petrášová kratocha...@gmail.com wrote: Hi, ps.map doesn't support multiple map frames directly, only through eps instruction: http://grasswiki.osgeo.org/wiki/Psmap_multi_pane_example Composer is just a graphical front-end to ps.map. It could run ps.map on more map frames and display them via eps instruction (automate what the user has to do) but it seems to be quite a lot of work. So, so far you have to do it manually. Anna On Mon, May 5, 2014 at 7:14 AM, Paulo van Breugel p.vanbreu...@gmail.comwrote: Hi, I have no clue how difficult it would be to implement, but it would be great if there was the option in the cartographic composer to add more than one map frame (same goes for the other map items). Cheers, Paulo ___ 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] [GRASS GIS] #2279: wingrass71: rendering problems with raster layers automatically added by finished modules
#2279: wingrass71: rendering problems with raster layers automatically added by finished modules -+-- Reporter: hellik | Owner: grass-dev@… Type: defect | Status: new Priority: critical | Milestone: 7.0.0 Component: wxGUI| Version: svn-trunk Keywords: wingrass, rendering |Platform: MSWindows 7 Cpu: x86-64 | -+-- Comment(by annakrat): Replying to [comment:5 hellik]: Replying to [comment:4 annakrat]: By artifacts you mean that you see different layers in map display and in the layer manager? I had no problems with this on Ubuntu, I will try it on Windows tomorrow. have a look at the screenshots. this blue raster layer is the artefact. this remains/persists although you toggle on/ off the several resultat output maps automatically added to the map display by a finished module like r.slope.aspect. it remains also if you zoom in/out. no, toggle no/off worked for me, otherwise I can confirm it. It basically doesn't show that the layer is checked when it is checked. I will try to look at it this week. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2279#comment:6 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] 6.4.4 planning
On Tue, Apr 29, 2014 at 6:29 PM, Markus Neteler nete...@osgeo.org wrote: On Sun, Apr 20, 2014 at 7:38 PM, Markus Neteler nete...@osgeo.org wrote: in order to prepare the 6.4.4RC1, please check: Important bugs concerning the next release https://trac.osgeo.org/grass/report/13 Here the full list of issues but none is a blocker: https://trac.osgeo.org/grass/query?status=assignedstatus=newstatus=reopenedgroup=statusmilestone=6.4.4 Ready to tag RC1, I would say. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] 6.4.4 planning
Hi Markus, 2014-05-05 20:52 GMT+02:00 Markus Neteler nete...@osgeo.org: Ready to tag RC1, I would say. one big +1. 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 GIS] #2019: v.voronoi Segmentation fault
#2019: v.voronoi Segmentation fault +--- Reporter: DmitryKolesov | Owner: grass-dev@… Type: defect | Status: closed Priority: normal | Milestone: 6.4.4 Component: Vector | Version: svn-releasebranch64 Resolution: fixed |Keywords: v.voronoi Platform: Unspecified| Cpu: Unspecified +--- Changes (by neteler): * status: new = closed * version: = svn-releasebranch64 * resolution: = fixed Comment: Replying to [comment:9 neteler]: ... The original crash reported above no longer occurs. Can the ticket be closed? Closing as fixed. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2019#comment:10 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] #2086: libgis build failure on alpha
#2086: libgis build failure on alpha ---+ Reporter: hamish | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 6.4.4 Component: Compiling | Version: 6.4.3 Keywords: alpha, libgis |Platform: Linux Cpu: Other | ---+ Comment(by neteler): GRASS 6.4.3 is now compiling on Alpha: http://buildd.debian-ports.org/status/package.php?p=grass -- Ticket URL: https://trac.osgeo.org/grass/ticket/2086#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] #2116: r.kappa: call to r.stats fails if spaces in path
#2116: r.kappa: call to r.stats fails if spaces in path ---+ Reporter: mlennert | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 6.4.4 Component: Raster | Version: svn-releasebranch64 Keywords: r.kappa, path |Platform: Unspecified Cpu: Unspecified| ---+ Comment(by neteler): Replying to [comment:5 glynn]: Replying to [comment:4 mlennert]: I hadn't applied the patch, yet, since you suggested G_vspawn_ex(), and I didn't find the time to look into that. Should that solution be preferred ? The spawn functions are preferable (that's what r.kappa uses in 7.0), as they avoid the shell altogether. Backported to 6.5 in r60121 and to 6.4 in r60122. The result is identical 7.0. Please test on Windows and close if solved. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2116#comment:6 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] #2155: r.sun.hourly: add flag for aggregating a series of output files
#2155: r.sun.hourly: add flag for aggregating a series of output files --+- Reporter: timmie| Owner: grass-dev@… Type: enhancement | Status: new Priority: normal| Milestone: 6.4.4 Component: Addons| Version: unspecified Keywords: r.sun.hourly |Platform: Unspecified Cpu: Unspecified | --+- Changes (by neteler): * keywords: = r.sun.hourly * type: defect = enhancement Old description: Use cases: * sum up the daily/monthly/annual radiation (kWh/m^2) * average sunlight duration per day during a month, etc. (h/d) discussion: http://permalink.gmane.org/gmane.comp.gis.grass.user/48687 New description: Use cases: * sum up the daily/monthly/annual radiation (kWh/m^2 ) * average sunlight duration per day during a month, etc. (h/d) discussion: http://permalink.gmane.org/gmane.comp.gis.grass.user/48687 -- Comment: (original report tracformatted) -- Ticket URL: https://trac.osgeo.org/grass/ticket/2155#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] #2073: help page temp files not cleaned by distclean and shipped in source tarball
#2073: help page temp files not cleaned by distclean and shipped in source
tarball
---+
Reporter: hamish | Owner: grass-dev@…
Type: defect | Status: new
Priority: minor | Milestone: 6.4.4
Component: Compiling | Version: 6.4.3
Keywords: distclean |Platform: Linux
Cpu: x86-64 |
---+
Comment(by neteler):
The issue remains for the wxGUI manual pages:
{{{
[neteler@oboe grass64]$ make distclean
[neteler@oboe grass64]$ find . -name '*.tmp.html'
./gui/wxpython/docs/wxGUI.Components.tmp.html
./gui/wxpython/docs/wxGUI.Modeler.tmp.html
./gui/wxpython/docs/wxGUI.PsMap.tmp.html
./gui/wxpython/docs/wxGUI.Nviz.tmp.html
./gui/wxpython/docs/wxGUI.Vector_Digitizer.tmp.html
./gui/wxpython/docs/wxGUI.GCP_Manager.tmp.html
./gui/wxpython/docs/wxGUI.tmp.html
./gui/wxpython/docs/wxGUI.Attribute_Table_Manager.tmp.html
}}}
Maybe a special clean: target is needed in
gui/wxpython/docs/Makefile
?
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2073#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] #2024: r.li.setup generates incomplete r.li conf file
#2024: r.li.setup generates incomplete r.li conf file +--- Reporter: matmar | Owner: rashadkm Type: defect | Status: assigned Priority: normal | Milestone: 6.4.4 Component: Raster | Version: svn-releasebranch64 Keywords: r.li.setup |Platform: Linux Cpu: x86-64 | +--- Comment(by neteler): Matteo, is the issue r.li.setup generates incomplete r.li conf file solved? -- Ticket URL: https://trac.osgeo.org/grass/ticket/2024#comment:32 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2277: graphically set up region bounds
#2277: graphically set up region bounds -+-- Reporter: vincent | Owner: martinl Type: enhancement | Status: assigned Priority: normal | Milestone: 7.0.0 Component: wxGUI| Version: unspecified Keywords: region |Platform: Unspecified Cpu: Unspecified | -+-- Comment(by martinl): Replying to [comment:3 martinl]: right, please try out r60055 (trunk, GRASS 7.1). Later I can backported to relbr70. for record: backported to relbr70 as r60125 -- Ticket URL: http://trac.osgeo.org/grass/ticket/2277#comment:11 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] #2283: wingrass: failure when loading addons
#2283: wingrass: failure when loading addons --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Addons| Version: svn-trunk Keywords: wingrass, launch |Platform: MSWindows 2K Cpu: Unspecified | --+- WinGRASS currently fails with not understandable error message attachment :addons-error.png when installed addons are incompatible with launched GRASS. Some better error tracking is needed. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2283 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] Python: core.create_location() available but core.create_mapset() yet missing
Hi, would it be possible to also add a convenient core.create_mapset() function? The code already exists: gui/wxpython/gis_set.py line 858: def CreateNewMapset(self, mapset): This would help folks who want to batch-process data and appears to be the missing piece to completely generate a new location in the Python way. thanks Markus PS: since it is wxGUI code I hesitate to modify it myself ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Python: core.create_location() available but core.create_mapset() yet missing
On Tue, May 6, 2014 at 12:02 AM, Markus Neteler nete...@osgeo.org wrote: Hi, would it be possible to also add a convenient core.create_mapset() function? The code already exists: gui/wxpython/gis_set.py line 858: def CreateNewMapset(self, mapset): This would help folks who want to batch-process data and appears to be the missing piece to completely generate a new location in the Python way. Is it possible, that create_location() only works *within* a GRASS session? How would I generate a location in Python when not having the location yet created but only a SHAPE/.prj file available or a GeoTIFF? Seems I am overlooking something. Pointers welcome! Markus ___ 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: martinl
Type: enhancement | Status: assigned
Priority: normal | Milestone: 7.0.0
Component: wxGUI| Version: unspecified
Keywords: region |Platform: Unspecified
Cpu: Unspecified |
-+--
Comment(by vincent):
Replying to [comment:11 martinl]:
Replying to [comment:3 martinl]:
right, please try out r60055 (trunk, GRASS 7.1). Later I can
backported to relbr70.
for record: backported to relbr70 as r60125
OK, a slight typo detail:
line 1235 in
grass/branches/releasebranch_7_0/gui/wxpython/mapdisp/frame.py:
{{{s/compulational/computational/}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2277#comment:12
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
