Re: [GRASS-dev] [GRASS GIS] #2024: r.li.setup generates incomplete r.li conf file

[GRASS GIS]

#2024: r.li.setup generates incomplete r.li conf file
-+--
  Reporter:  matmar  |   Owner:  rashadkm   
  Type:  defect  |  Status:  closed 
  Priority:  normal  |   Milestone:  6.4.4  
 Component:  Raster  | Version:  svn-releasebranch64
Resolution:  fixed   |Keywords:  r.li.setup 
  Platform:  Linux   | Cpu:  x86-64 
-+--
Changes (by matmar):

  * status:  assigned => closed
  * resolution:  => fixed


Comment:

 Replying to [comment:32 neteler]:
 > Matteo,
 >
 > is the issue "r.li.setup generates incomplete r.li conf file" solved?

 As far I'm concerned it is solved, then I close the ticket...


 Matteo

-- 
Ticket URL: 
GRASS GIS 

___
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

[GRASS GIS]

#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 sbl):

 Replying to [comment:1 glynn]:
 >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).

 Provided, that I have no idea how much work it would be to implement this,
 it sounds like a very nice solution to me.


 >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).

 I see that this is a bit tricky, as it might be necessary to distinguish
 maps linked to GRASS (for maps produced by other people or software which
 have been linked into GRASS using r.external (which should not be meddled
 with)) and maps/files produced from within GRASS. Furthermore, users may
 choose map names differing from file names when they link them to GRASS
 (r.external). However, an optional flag for keeping maps and files in sync
 would be nice, if that is feasible.

 Two other things to consider in this context are (maybe):

 1) Let`s say a user sets the external output path to ~/output for GeoTiffs
 with extension ."tif". Then the user produces a map with the name "map_a".
 Later this "map_a" is renamed to "map_b". The file "~/output/map_a.tif"
 will then be linked to "map_b", right? What happens in such a case, if
 another map with the name "map_a" is produced. The map name does not exist
 anymore in GRASS, but the file "~/output/map_a.tif" does, on the file
 system. Is it checked that "~/output/map_a.tif" is not overwritten in such
 a case.

 2) Let`s assume one wants to use maps produced in GRASS with
 r.external.out in other software. During map production the user finds
 out, that a different name for the map would have been more suitable.
 After running g.rename the new, more appropriate name is used in GRASS
 while other software will still have to work with the old filename. The
 way to sync that manually would be to remove the map (link) (instead of
 renaming it), rename the underlying file (mv), and then link that file
 again into GRASS (r.external). What happens to map history in such cases?

 In general, I think having an option for keeping maps and files in sync
 automatically would make it much more easy to maintain a tidy and clean
 data storage with external files...

-- 
Ticket URL: 
GRASS GIS 

___
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

[matteo marcantonio]

Hi Markus,

AFAIC it is solved!

Matteo


2014-05-05 22:48 GMT+02:00 GRASS GIS :

> #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: 
> GRASS GIS 
>
>
___
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

[GRASS GIS]

#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: 
GRASS GIS 

___
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

[Markus Neteler]

On Tue, May 6, 2014 at 12:02 AM, Markus Neteler  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

[GRASS-dev] Python: core.create_location() available but core.create_mapset() yet missing

[Markus Neteler]

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

[GRASS-dev] [GRASS GIS] #2283: wingrass: failure when loading addons

[GRASS GIS]

#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: 
GRASS GIS 

___
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

[GRASS GIS]

#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: 
GRASS GIS 

___
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

[GRASS GIS]

#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: 
GRASS GIS 

___
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

[GRASS GIS]

#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: 
GRASS GIS 

___
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

[GRASS GIS]

#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: 
GRASS GIS 

___
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

[GRASS GIS]

#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: 
GRASS GIS 

___
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

[GRASS GIS]

#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: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] 6.4.4 planning

[Martin Landa]

Hi Markus,

2014-05-05 20:52 GMT+02:00 Markus Neteler :

> 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

[GRASS GIS]

#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: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] 6.4.4 planning

[Markus Neteler]

On Tue, Apr 29, 2014 at 6:29 PM, Markus Neteler  wrote:
> On Sun, Apr 20, 2014 at 7:38 PM, Markus Neteler  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=assigned&status=new&status=reopened&group=status&milestone=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] [GRASS GIS] #2279: wingrass71: rendering problems with raster layers automatically added by finished modules

[GRASS GIS]

#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: 
GRASS GIS 

___
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

[Paulo van Breugel]

Ok, thanks for the feedback.
On 5 May 2014 16:18, "Anna Petrášová"  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 
> wrote:
>
>> 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

[Anna Petrášová]

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 wrote:

> 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] #2278: G__tempfile() lacks perror support

[GRASS GIS]

#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: 
GRASS GIS 

___
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

[GRASS GIS]

#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: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r60054

[Glynn Clements]

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 
___
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

[GRASS GIS]

#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: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r60054

[Glynn Clements]

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 
___
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)

[GRASS GIS]

#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: 
GRASS GIS 

___
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)

[GRASS GIS]

#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: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r60054

[Glynn Clements]

Martin Landa wrote:

> 2014-05-03 15:49 GMT+02:00  :
> > 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 
___
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

[Glynn Clements]

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 
___
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

[GRASS GIS]

#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: 
GRASS GIS 

___
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

[GRASS GIS]

#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: 
GRASS GIS 

___
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

[GRASS GIS]

#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: 
GRASS GIS 

___
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

[Paulo van Breugel]

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] #2143: d.legend: add option to output legend definition as text

[GRASS GIS]

#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: 
GRASS GIS 

___
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

[GRASS GIS]

#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: 
GRASS GIS 

___
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

[GRASS GIS]

#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: 
GRASS GIS 

___
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

[GRASS GIS]

#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: 
GRASS GIS 

___
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

[GRASS GIS]

#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
  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: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev