Re: [GRASS-dev] GRASS & QGIS: the future

[Radim Blazek]

Dne 16.5.2014 18:36 "Glynn Clements"  napsal(a):
>
>
> Radim Blazek wrote:
>
> > There is a problem in G_fatal_error():
> >
> > static int busy
> > if (busy)
> > exit(EXIT_FAILURE);
> > busy = 1;
> >
> > second G_fatal_error() call always exits.
> >
> > The busy check is there for the case when print error routine itself
> > ends up with call to G_fatal_error()?
>
> It's there to prevent infinite recursion, whether from the printing
> code, a fatal error handler, or whatever.
>
> > May be the busy variable made global and added a function to clear it?
>
> That might be going a bit too far. OTOH, it can't be cleared prior to
> calling the handler because it's intended to protect against the case
> of a handler generating a fatal error.

I ment some G_fatal_error_recover() which would be called as last thing
from QGIS error routine.

> One possibility would be to add explicit support for longjmp()ing out,
> e.g. adding G_error_longjmp(jmp_buf env, int val) which would clear
> the busy flag then perform the longjmp. That would avoid exposing the
> internals more than is necessary.

Sounds good.

> Also, currently the global error handler (G_set_error_routine) is
> called before the non-exclusive handlers (G_add_error_handler), so
> those will never be called if the global handler lonjmp()s out. The
> global error handler isn't limited to fatal errors, but is also used
> for messages and warnings.

G_add_error_handler() is used by GRASS itself?

> Perhaps we need a dedicated fatal error handler for this purpose? It
> would be called immediately prior to the final exit() call. It would
> not be allowed to call GRASS functions or to return. The busy flag
> could be cleared before calling it.

Whatever allows to "recover" from fatal error will help. I would prefer
however not changing semantics too much so that GRASS 6, 7.0.0beta1 and
7.x.x may be easily supported by the same code with only few ifdefs.

Radim

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

Re: [GRASS-dev] r.in.lidar tuning

[Newcomb, Doug]

I pulled the latest 71 trunk ( 60278) , applied the patch, and the
intensity option appears to work.

Doug



On Fri, May 16, 2014 at 6:02 PM, Markus Neteler  wrote:

> (back to an older topic)
>
> On Tue, Oct 8, 2013 at 8:37 PM, Markus Neteler wrote:
> > On Tue, Oct 8, 2013 at 4:31 PM, Markus Metz  wrote:
> >> Markus Neteler wrote:
>
> [ wish for r.in.lidar: ]
> ...
> >>> filter   Only import points of selected return type
> >>>   If not specified, all points are imported
> >>>  options: first,last,mid
> >>>
> >>> which would be great for r.in.lidar as well to avoid that I need to
> >>> split the file with las2las beforehand.
> >>
> >> Why would you want to do filtering? The r.in.lidar methods min, max,
> >> mean, median, percentile are not sufficient?
>
> For some LAS files not.
>
> > I omitted to mention the sometimes existing classification of returns
> > and had in mind to be able to restrict the import to e.g. ground
> > points only, or the like. Then apply the methods min, max, etc only to
> > the selected subset of LiDAR points.
>
> I have implemented that now in
> http://trac.osgeo.org/grass/changeset/60247/grass/trunk/raster/r.in.lidar
>
> (hope I got it right over from v.in.lidar)
>
> Concerning Doug's intensity wish which also became mine yesterday:
> Attached a patch to import intensity values rather than z values (flag -i).
> Using -i all statistics are applied to intensity.
>
> The code is a bit simple ("ugly") since the variable names further on
> in the code remain related to "z" rather than e.g. become a generic
> "value". Not sure if all related variables should be renamed, hence I
> didn't commit that to SVN.
> Please try from svn + attached patch.
>
> markusN
>



-- 
Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-
The opinions I express are my own and are not representative of the
official policy of the U.S.Fish and Wildlife Service or Dept. of the
Interior.   Life is too short for undocumented, proprietary data formats.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.in.lidar tuning

[Newcomb, Doug]

Great!  I will test when I have a spare moment!

In the long term.. Any chance of filtering the input points through an
elevation raster to subtract to get height above ground before statistics?

las file---> subtract value of elevation grid generated from ground points
--> run statistics on modified z values of las points.

One problem I can see is that you generally have higher resolution
elevation rasters than the resolution of forest canopy structure you wish
to create.  6m elevation grid vs 18m canopy structure grids)  This might be
better as a separate function (r.lashag?) in which you have inputs of an
external las file and an elevation raster layer and an output of an las
file with the z value as height above ground.



I've done this externally with python scripts ( badly and slowly) . On the
upside, the resulting las datasets are quite promising for landscape -
level canopy structure analysis.

Doug


On Fri, May 16, 2014 at 6:02 PM, Markus Neteler  wrote:

> (back to an older topic)
>
> On Tue, Oct 8, 2013 at 8:37 PM, Markus Neteler wrote:
> > On Tue, Oct 8, 2013 at 4:31 PM, Markus Metz  wrote:
> >> Markus Neteler wrote:
>
> [ wish for r.in.lidar: ]
> ...
> >>> filter   Only import points of selected return type
> >>>   If not specified, all points are imported
> >>>  options: first,last,mid
> >>>
> >>> which would be great for r.in.lidar as well to avoid that I need to
> >>> split the file with las2las beforehand.
> >>
> >> Why would you want to do filtering? The r.in.lidar methods min, max,
> >> mean, median, percentile are not sufficient?
>
> For some LAS files not.
>
> > I omitted to mention the sometimes existing classification of returns
> > and had in mind to be able to restrict the import to e.g. ground
> > points only, or the like. Then apply the methods min, max, etc only to
> > the selected subset of LiDAR points.
>
> I have implemented that now in
> http://trac.osgeo.org/grass/changeset/60247/grass/trunk/raster/r.in.lidar
>
> (hope I got it right over from v.in.lidar)
>
> Concerning Doug's intensity wish which also became mine yesterday:
> Attached a patch to import intensity values rather than z values (flag -i).
> Using -i all statistics are applied to intensity.
>
> The code is a bit simple ("ugly") since the variable names further on
> in the code remain related to "z" rather than e.g. become a generic
> "value". Not sure if all related variables should be renamed, hence I
> didn't commit that to SVN.
> Please try from svn + attached patch.
>
> markusN
>



-- 
Doug Newcomb
USFWS
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-
The opinions I express are my own and are not representative of the
official policy of the U.S.Fish and Wildlife Service or Dept. of the
Interior.   Life is too short for undocumented, proprietary data formats.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.in.lidar tuning

[Markus Neteler]

(back to an older topic)

On Tue, Oct 8, 2013 at 8:37 PM, Markus Neteler wrote:
> On Tue, Oct 8, 2013 at 4:31 PM, Markus Metz  wrote:
>> Markus Neteler wrote:

[ wish for r.in.lidar: ]
...
>>> filter   Only import points of selected return type
>>>   If not specified, all points are imported
>>>  options: first,last,mid
>>>
>>> which would be great for r.in.lidar as well to avoid that I need to
>>> split the file with las2las beforehand.
>>
>> Why would you want to do filtering? The r.in.lidar methods min, max,
>> mean, median, percentile are not sufficient?

For some LAS files not.

> I omitted to mention the sometimes existing classification of returns
> and had in mind to be able to restrict the import to e.g. ground
> points only, or the like. Then apply the methods min, max, etc only to
> the selected subset of LiDAR points.

I have implemented that now in
http://trac.osgeo.org/grass/changeset/60247/grass/trunk/raster/r.in.lidar

(hope I got it right over from v.in.lidar)

Concerning Doug's intensity wish which also became mine yesterday:
Attached a patch to import intensity values rather than z values (flag -i).
Using -i all statistics are applied to intensity.

The code is a bit simple ("ugly") since the variable names further on
in the code remain related to "z" rather than e.g. become a generic
"value". Not sure if all related variables should be renamed, hence I
didn't commit that to SVN.
Please try from svn + attached patch.

markusN
Index: raster/r.in.lidar/main.c
===
--- raster/r.in.lidar/main.c(revision 60271)
+++ raster/r.in.lidar/main.c(working copy)
@@ -146,7 +146,7 @@
 struct Option *input_opt, *output_opt, *percent_opt, *type_opt, 
*filter_opt;
 struct Option *method_opt, *zrange_opt, *zscale_opt;
 struct Option *trim_opt, *pth_opt, *res_opt;
-struct Flag *print_flag, *scan_flag, *shell_style, *over_flag, 
*extents_flag;
+struct Flag *print_flag, *scan_flag, *shell_style, *over_flag, 
*extents_flag, *intens_flag;
 
 /* LAS */
 LASReaderH LAS_reader;
@@ -277,6 +277,11 @@
 shell_style->description =
_("In scan mode, print using shell script style");
 
+intens_flag = G_define_flag();
+intens_flag->key = 'i';
+intens_flag->description =
+_("Import intensity values rather than z values");
+
 if (G_parser(argc, argv))
exit(EXIT_FAILURE);
 
@@ -761,7 +766,11 @@
 
x = LASPoint_GetX(LAS_point);
y = LASPoint_GetY(LAS_point);
-   z = LASPoint_GetZ(LAS_point);
+   if (intens_flag->answer)
+   /* use z variable here to allow for scaling of intensity below 
*/
+   z = LASPoint_GetIntensity(LAS_point);
+   else
+   z = LASPoint_GetZ(LAS_point);
 
if (return_filter != LAS_ALL) {
int return_no = LASPoint_GetReturnNumber(LAS_point);
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1628: segfault in r.walk

[GRASS GIS]

#1628: segfault in r.walk
+---
 Reporter:  pertusus|   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  normal  |   Milestone:  6.4.4
Component:  Raster  | Version:  svn-releasebranch64  
 Keywords:  r.cost, r.walk  |Platform:  Linux
  Cpu:  x86-64  |  
+---

Comment(by neteler):

 Replying to [comment:5 glynn]:
 ...
 > In 7.x, the only clients of lib/sites are v.in.sites and v.vol.rst. The
 former only uses the G_oldsite_* functions to access genuine 5.x "sites"
 maps. The latter uses G_site_new_struct() to allocate a structure which is
 never used.

 (Unrelated to this ticket but to above comment):
 I have removed the lib/sites dependency of v.vol.rst in 7.x in r60272
 (trunk) and r60273 (relbr7).

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Metadata GRASS (GSOC)

[Martin Landa]

Hi,

2014-05-16 15:59 GMT+02:00 Matej Krejci :
>> With option 1) , would the tool also operate on externally linked datasets
>> ( via v.external and r.external) ?

GRASS libraries currently manage metadata for maps created as links to
external formats (r.extrenal/v.external) in the same way as for maps
in native format. So basically there is no difference.

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

Re: [GRASS-dev] [GRASS GIS] #576: i.pca fails to center data prior to analysis

[GRASS GIS]

#576: i.pca fails to center data prior to analysis
--+-
 Reporter:  nikos |   Owner:  
grass-dev@…  
 Type:  defect|  Status:  
new  
 Priority:  normal|   Milestone:  
6.4.4
Component:  Raster| Version:  
svn-develbranch6 
 Keywords:  i.pca, data centering, prcomp(), R, eigenvectors  |Platform:  
Unspecified  
  Cpu:  Unspecified   |  
--+-
Changes (by neteler):

  * milestone:  6.5.0 => 6.4.4


Comment:

 Has this been already backported to relbr6/develbr6?

 Potentially: r51647 and r52890.

 Please close the ticket if the issue got 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] #1318: DebCheck QA: Memory leaks

[GRASS GIS]

#1318: DebCheck QA: Memory leaks
+---
 Reporter:  hamish  |   
Owner:  grass-dev@…  
 Type:  defect  |  
Status:  new  
 Priority:  normal  |   
Milestone:  6.4.4
Component:  Compiling   | 
Version:  6.4.0
 Keywords:  gem, lib/bitmap, shapelib, lib/iostream, dglib, r.li, nviz  |
Platform:  Linux
  Cpu:  Unspecified |  
+---
Changes (by volter):

 * cc: volter (added)


-- 
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] #1628: segfault in r.walk

[GRASS GIS]

#1628: segfault in r.walk
+---
 Reporter:  pertusus|   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  normal  |   Milestone:  6.4.4
Component:  Raster  | Version:  svn-releasebranch64  
 Keywords:  r.cost, r.walk  |Platform:  Linux
  Cpu:  x86-64  |  
+---

Comment(by glynn):

 Replying to [comment:3 mlennert]:

 > I do not have the time right now to check if this is linked to a
 specific attribute or just the general number of attributes, but maybe
 someone else can continue on that path ?

 Could it be a problem with lib/sites?

 The 6.x version of r.walk uses that library to obtain the start/stop
 points from a vector map using the 5.x sites API. The 7.x version uses the
 vector library directly.

 In 7.x, the only clients of lib/sites are v.in.sites and v.vol.rst. The
 former only uses the G_oldsite_* functions to access genuine 5.x "sites"
 maps. The latter uses G_site_new_struct() to allocate a structure which is
 never used.

-- 
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 & QGIS: the future

[Glynn Clements]

Radim Blazek wrote:

> There is a problem in G_fatal_error():
> 
> static int busy
> if (busy)
> exit(EXIT_FAILURE);
> busy = 1;
> 
> second G_fatal_error() call always exits.
> 
> The busy check is there for the case when print error routine itself
> ends up with call to G_fatal_error()?

It's there to prevent infinite recursion, whether from the printing
code, a fatal error handler, or whatever.

> May be the busy variable made global and added a function to clear it?

That might be going a bit too far. OTOH, it can't be cleared prior to
calling the handler because it's intended to protect against the case
of a handler generating a fatal error.

One possibility would be to add explicit support for longjmp()ing out,
e.g. adding G_error_longjmp(jmp_buf env, int val) which would clear
the busy flag then perform the longjmp. That would avoid exposing the
internals more than is necessary.

Also, currently the global error handler (G_set_error_routine) is
called before the non-exclusive handlers (G_add_error_handler), so
those will never be called if the global handler lonjmp()s out. The
global error handler isn't limited to fatal errors, but is also used
for messages and warnings.

Perhaps we need a dedicated fatal error handler for this purpose? It
would be called immediately prior to the final exit() call. It would
not be allowed to call GRASS functions or to return. The busy flag
could be cleared before calling 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] #2035: v.kcv optimization

[GRASS GIS]

#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  |  
-+--

Comment(by neteler):

 Replying to [comment:5 mlennert]:
 > I strongly prefer the GRASS65 version of v.kcv, and so would support
 > backporting it, with one serious remark though:
 ...
 > In other words: I have just updated the attribute table of a vector map
 > that is not in the current mapset.

 I have added a test as used in v.build: r60263.

 Still you can override that :(

 {{{
 GRASS 6.5.svn (nc_spm_08):~ > v.kcv input=geonames_wake@PERMANENT
 column=part k=10
  100%
 ERROR: Bug: attempt to update map which is not in current mapset
 }}}

 This appears to affect also at least v.build:

 {{{
 GRASS 6.5.svn (nc_spm_08):~ > g.gisenv  | grep MAPSET
 MAPSET='neteler';
 GRASS 6.5.svn (nc_spm_08):~ > v.build geonames_wake@PERMANENT
 Building topology for vector map ...
 Registering primitives...
 1088 primitives registered
 ...
 }}}

 ... hence not scope of this ticket.

-- 
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] #2255: g.mlist warnings for layers found in other mapsets

[GRASS GIS]

#2255: g.mlist warnings for layers found in other mapsets
-+--
 Reporter:  pvanbosgeo   |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  normal   |   Milestone:  7.1.0
Component:  Default  | Version:  unspecified  
 Keywords:   |Platform:  Unspecified  
  Cpu:  Unspecified  |  
-+--

Comment(by hcho):

 Fixed in r60261.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Metadata GRASS (GSOC)

[Matej Krejci]

2014-05-14 22:54 GMT+02:00 Newcomb, Doug :

> With option 1) , would the tool also operate on externally linked datasets
> ( via v.external and r.external) ?
>
> Doug
>
>>
>>
>> Hi,
I think that first task is to make creator and editor of XML metadata
standards.
Fill in these XML by values from maps  is next step. I do not know at
current stage of project.

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

Re: [GRASS-dev] [GRASS GIS] #1628: segfault in r.walk

[GRASS GIS]

#1628: segfault in r.walk
+---
 Reporter:  pertusus|   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  normal  |   Milestone:  6.4.4
Component:  Raster  | Version:  svn-releasebranch64  
 Keywords:  r.cost, r.walk  |Platform:  Linux
  Cpu:  x86-64  |  
+---

Comment(by mlennert):

 Additional info: AFAICT, the segfault occurs in a call to get() (memory.c)
 within the insert() function (btree.c).

 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] #2295: import of large shapefile in GRASS-db crashes 6.4.3 + 7.0 beta2

[GRASS GIS]

#2295: import of large shapefile in GRASS-db crashes 6.4.3 + 7.0 beta2
-+--
 Reporter:  janhuizinga  |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  major|   Milestone:  6.4.4
Component:  Default  | Version:  6.4.3
 Keywords:   |Platform:  MSWindows 7  
  Cpu:  x86-64   |  
-+--
Changes (by janhuizinga):

  * cpu:  Unspecified => x86-64


-- 
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] #2295: import of large shapefile in GRASS-db crashes 6.4.3 + 7.0 beta2

[GRASS GIS]

#2295: import of large shapefile in GRASS-db crashes 6.4.3 + 7.0 beta2
-+--
 Reporter:  janhuizinga  |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  major|   Milestone:  6.4.4
Component:  Default  | Version:  6.4.3
 Keywords:   |Platform:  MSWindows 7  
  Cpu:  Unspecified  |  
-+--
 OS: Windows 7
 GRASS versions: 6.4 + 7.0 beta2

 I'm trying to import a shapefile containing 9,354,125 point of type 2.5D
 in a GRASS-db. Size of this shapefile: 328MB for shp-file + 301MB for dbf-
 file.
 If I try to import it WITH creating an attribute table it only loads half
 of the points and then exits with an error message (message attached
 below). Size of coor-file in GRASS is then 173MB.

 If I try to import the shapefile WITHOUT creating an attribute table it
 fully converts the points, but reports an memory error during "Registering
 primitives ..." Size of coor-file in GRASS is then 337MB (message attached
 below)

 Error messages in command console below:

 ++
 error 1:
 ++
 (Fri May 16 13:20:20 2014)
 v.in.ogr dsn=D:\Users\HKV2\PR2820_Mego\JanH\Gebouwen3\adreslocatie.shp
 layer=adreslocatie output=adreslocatie
 Check if OGR layer  contains polygons...
 Importing 9354125 features (OGR layer )...
 WARNING: System not initialized. Programmer forgot to call G_gisinit().
 dbmi: Protocol error
 dbmi: Protocol error
 dbmi: Protocol error
 ERROR: Cannot insert new row: insert into adreslocatie values ( 4802001,
 '036320223289', '1011LH', 3, 300 )
 (Fri May 16 13:28:58 2014) Command finished (8 min 38 sec)

 ++
 error 2:
 ++

 (Fri May 16 14:58:19 2014)
 v.in.ogr dsn=D:\Users\HKV2\PR2820_Mego\JanH\Gebouwen3\adreslocatie.shp
 layer=adreslocatie output=adreslocatie --overwrite -t
 Check if OGR layer  contains polygons...
 WARNING: Vector map  already exists and will be overwritten
 WARNING: Table  linked to vector map  does not
 exist
 Importing 9354125 features (OGR layer )...
 -
 Building topology for vector map ...
 Registering primitives...
 Current region rows: 516, cols: 790
 ERROR: G_realloc: unable to allocate 8148 bytes of memory at
 cindex.c:113
 (Fri May 16 15:08:04 2014) Command finished (9 min 44 sec)

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

[Moritz Lennert]

On 15/05/14 23:14, Markus Neteler wrote:

On Thu, May 15, 2014 at 12:56 AM, Markus Neteler  wrote:

On Mon, May 5, 2014 at 8:52 PM, Markus Neteler  wrote:

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:


Draft announcement to be updated:
http://trac.osgeo.org/grass/wiki/Release/6.4.4RC1-News


"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


Here some relevant ones:


Thanks for having solved some of the issues in the past 24 hours.


To test on Windows:
g.remove cannot remove vector map because of space in DB layer name
https://trac.osgeo.org/grass/ticket/1438


You note that this should be wontfix. What do you want to be tested ?


r.univar NaN
https://trac.osgeo.org/grass/ticket/2269


... missing output to be changed (all GRASS versions).


I see this more as an enhancement request than a bug. I don't think this 
should hold up a release.






-
r.walk backport
https://trac.osgeo.org/grass/ticket/1628


... not sure what to backport.


v.kcv backport
https://trac.osgeo.org/grass/ticket/2035


... any objections to submit the patch?


See my comment in the ticket.



And/or I can tag RC1 now and we do these issues later.


I think that except for the r.walk segfault, none are really 
showstoppers. And even that only seems to be reproducible in a very 
specific situation.


Moritz

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

Re: [GRASS-dev] GRASS created geotiff do not properly load into PostGIS (raster2pgsql)

[Blumentrath, Stefan]

Thanks Rémi,
For clarification. The remaining question is, is this a PostGIS or a GRASS 
issue?
Since GRASS and GDAL obviously manage to handle the NaN concept, maybe 
raster2pgsql should be able to do that too?

Cheers
Stefan

From: Rémi Cura [mailto:remi.c...@gmail.com]
Sent: 16. mai 2014 14:15
To: Blumentrath, Stefan
Cc: GRASS developers list (grass-dev@lists.osgeo.org); 
postgis-de...@lists.osgeo.org
Subject: Re: [GRASS-dev] GRASS created geotiff do not properly load into 
PostGIS (raster2pgsql)

OK gdal is out of the way.
Like you I had troubles with the 'nan' value ,
because 'nan' is actually platform dependent AND it get casted differently 
depending on the precision of the type.

Like you said the only way to get it working was manually assign a number 
instead of Nan :-(
Cheers,
Rémi-C

2014-05-16 11:40 GMT+02:00 Blumentrath, Stefan 
mailto:stefan.blumentr...@nina.no>>:
Hi,

And thanks for the swift response!
My GDAL version is:
GDAL 1.11.0, released 2014/04/16.

I recompiled GDAL recently (but not PostGIS). Can that be the source of error?
However, ASCII and Tiffs with assigned NoData work…

Cheers
Stefan



From: Rémi Cura [mailto:remi.c...@gmail.com]
Sent: 16. mai 2014 11:24
To: Blumentrath, Stefan
Cc: GRASS developers list 
(grass-dev@lists.osgeo.org); 
postgis-de...@lists.osgeo.org
Subject: Re: [GRASS-dev] GRASS created geotiff do not properly load into 
PostGIS (raster2pgsql)

Hey,
what is your version of gdal (type `gdalinfo --version`)
Cheers,
Rémi-C

2014-05-16 11:14 GMT+02:00 Blumentrath, Stefan 
mailto:stefan.blumentr...@nina.no>>:
Hi,

And sorry for posting on two lists. Just don`t know where the issue belongs to…

I tried to load a set of raster maps in Geotiff format, which I created in 
GRASS using r.external.out, into PostGIS 2.1.2dev.

In PostGIS the raster datasets only contain NoData values, while gdalinfo 
–stats produces reasonable statistics for the respective GeoTiffs.

I did some trouble shooting and found that the problem was that GRASS did not 
assign a numerical NoData value to the GeoTiff, but “nan”.

When I gdal_translate same GeoTiff with –a_nodata -, raster2pgsql loads the 
resulting file just fine.

Is raster2pgsql supposed to read rasters with nan as NoData values (using –N 
- in raster2pgsql had no effect btw.) or should GRASS (r.external.out) 
assign a NoData value to the produced raster datasets?

Many thanks in advance,
Stefan



___
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] #1628: segfault in r.walk

[GRASS GIS]

#1628: segfault in r.walk
+---
 Reporter:  pertusus|   Owner:  grass-dev@…  
 Type:  defect  |  Status:  new  
 Priority:  normal  |   Milestone:  6.4.4
Component:  Raster  | Version:  svn-releasebranch64  
 Keywords:  r.cost, r.walk  |Platform:  Linux
  Cpu:  x86-64  |  
+---

Comment(by mlennert):

 I tried with the test script and can confirm the crash. Testing a bit
 further the difference between the v.in.ascii and v.in.ogr imports, I saw
 that the latter has many more attribute columns. When I reduce the number
 of attribute columns, I get r.walk to work:


 {{{
 v.info -c stop_points_ogr
 Displaying column types/names for database connection of layer 1:
 INTEGER|cat
 INTEGER|cat_point
 INTEGER|cat_relocated
 DOUBLE PRECISION|lon_relocated
 DOUBLE PRECISION|lat_relocated
 INTEGER|cat_
 DOUBLE PRECISION|value
 DOUBLE PRECISION|orig_lon
 DOUBLE PRECISION|orig_lat
 }}}

 Running v.db.droptable before r.walk also makes r.walk work.

 I do not have the time right now to check if this is linked to a specific
 attribute or just the general number of attributes, but maybe someone else
 can continue on that path ?

 Backporting from grass7 seems quite invasive at this stage, unless the two
 modules are self-contained.

 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 created geotiff do not properly load into PostGIS (raster2pgsql)

[Rémi Cura]

OK gdal is out of the way.

Like you I had troubles with the 'nan' value ,
because 'nan' is actually platform dependent AND it get casted differently
depending on the precision of the type.


Like you said the only way to get it working was manually assign a number
instead of Nan :-(

Cheers,
Rémi-C


2014-05-16 11:40 GMT+02:00 Blumentrath, Stefan :

>  Hi,
>
>
>
> And thanks for the swift response!
>
> My GDAL version is:
>
> GDAL 1.11.0, released 2014/04/16.
>
>
>
> I recompiled GDAL recently (but not PostGIS). Can that be the source of
> error?
>
> However, ASCII and Tiffs with assigned NoData work…
>
>
>
> Cheers
>
> Stefan
>
>
>
>
>
>
>
> *From:* Rémi Cura [mailto:remi.c...@gmail.com]
> *Sent:* 16. mai 2014 11:24
> *To:* Blumentrath, Stefan
> *Cc:* GRASS developers list (grass-dev@lists.osgeo.org);
> postgis-de...@lists.osgeo.org
> *Subject:* Re: [GRASS-dev] GRASS created geotiff do not properly load
> into PostGIS (raster2pgsql)
>
>
>
> Hey,
>
> what is your version of gdal (type `gdalinfo --version`)
>
> Cheers,
> Rémi-C
>
>
>
> 2014-05-16 11:14 GMT+02:00 Blumentrath, Stefan  >:
>
> Hi,
>
>
>
> And sorry for posting on two lists. Just don`t know where the issue
> belongs to…
>
>
> I tried to load a set of raster maps in Geotiff format, which I created in
> GRASS using r.external.out, into PostGIS 2.1.2dev.
>
>
>
> In PostGIS the raster datasets only contain NoData values, while gdalinfo
> –stats produces reasonable statistics for the respective GeoTiffs.
>
>
>
> I did some trouble shooting and found that the problem was that GRASS did
> not assign a numerical NoData value to the GeoTiff, but “nan”.
>
>
>
> When I gdal_translate same GeoTiff with –a_nodata -, raster2pgsql
> loads the resulting file just fine.
>
>
>
> Is raster2pgsql supposed to read rasters with nan as NoData values (using
> –N - in raster2pgsql had no effect btw.) or should GRASS
> (r.external.out) assign a NoData value to the produced raster datasets?
>
>
>
> Many thanks in advance,
>
> Stefan
>
>
>
>
>
>
> ___
> 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] #2035: v.kcv optimization

[GRASS GIS]

#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  |  
-+--

Comment(by mlennert):

 I strongly prefer the GRASS65 version of v.kcv, and so would support
 backporting it, with one serious remark though:


 {{{
 > g.gisenv
 GISDBASE=/data/GRASS/DATA
 LOCATION_NAME=nc_spm_08
 MAPSET=user1

 > v.info -c elev_lid792_randpts@PERMANENT
 Displaying column types/names for database connection of layer 1:
 INTEGER|cat
 DOUBLE PRECISION|value

 > v.kcv elev_lid792_randpts@PERMANENT k=10 col=partition
  100%
 ERROR: Bug: attempt to update map which is not in current mapset

  > v.info -c elev_lid792_randpts@PERMANENT
 Displaying column types/names for database connection of layer 1:
 INTEGER|cat
 DOUBLE PRECISION|value
 INTEGER|partition
 }}}

 In other words: I have just updated the attribute table of a vector map
 that is not in the current mapset. That looks like a serious breach of our
 general rules here !

 Trying the same in trunk, I get:


 {{{
 ERREUR :Vector map  not found in current mapset
 }}}


 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 created geotiff do not properly load into PostGIS (raster2pgsql)

[Rémi Cura]

Hey,
what is your version of gdal (type `gdalinfo --version`)
Cheers,
Rémi-C


2014-05-16 11:14 GMT+02:00 Blumentrath, Stefan :

>  Hi,
>
>
>
> And sorry for posting on two lists. Just don`t know where the issue
> belongs to…
>
>
> I tried to load a set of raster maps in Geotiff format, which I created in
> GRASS using r.external.out, into PostGIS 2.1.2dev.
>
>
>
> In PostGIS the raster datasets only contain NoData values, while gdalinfo
> –stats produces reasonable statistics for the respective GeoTiffs.
>
>
>
> I did some trouble shooting and found that the problem was that GRASS did
> not assign a numerical NoData value to the GeoTiff, but “nan”.
>
>
>
> When I gdal_translate same GeoTiff with –a_nodata -, raster2pgsql
> loads the resulting file just fine.
>
>
>
> Is raster2pgsql supposed to read rasters with nan as NoData values (using
> –N - in raster2pgsql had no effect btw.) or should GRASS
> (r.external.out) assign a NoData value to the produced raster datasets?
>
>
>
> Many thanks in advance,
>
> Stefan
>
>
>
>
>
> ___
> 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 created geotiff do not properly load into PostGIS (raster2pgsql)

[Blumentrath, Stefan]

Hi,

And thanks for the swift response!
My GDAL version is:
GDAL 1.11.0, released 2014/04/16.

I recompiled GDAL recently (but not PostGIS). Can that be the source of error?
However, ASCII and Tiffs with assigned NoData work…

Cheers
Stefan



From: Rémi Cura [mailto:remi.c...@gmail.com]
Sent: 16. mai 2014 11:24
To: Blumentrath, Stefan
Cc: GRASS developers list (grass-dev@lists.osgeo.org); 
postgis-de...@lists.osgeo.org
Subject: Re: [GRASS-dev] GRASS created geotiff do not properly load into 
PostGIS (raster2pgsql)

Hey,
what is your version of gdal (type `gdalinfo --version`)
Cheers,
Rémi-C

2014-05-16 11:14 GMT+02:00 Blumentrath, Stefan 
mailto:stefan.blumentr...@nina.no>>:
Hi,

And sorry for posting on two lists. Just don`t know where the issue belongs to…

I tried to load a set of raster maps in Geotiff format, which I created in 
GRASS using r.external.out, into PostGIS 2.1.2dev.

In PostGIS the raster datasets only contain NoData values, while gdalinfo 
–stats produces reasonable statistics for the respective GeoTiffs.

I did some trouble shooting and found that the problem was that GRASS did not 
assign a numerical NoData value to the GeoTiff, but “nan”.

When I gdal_translate same GeoTiff with –a_nodata -, raster2pgsql loads the 
resulting file just fine.

Is raster2pgsql supposed to read rasters with nan as NoData values (using –N 
- in raster2pgsql had no effect btw.) or should GRASS (r.external.out) 
assign a NoData value to the produced raster datasets?

Many thanks in advance,
Stefan



___
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

[GRASS-dev] GRASS created geotiff do not properly load into PostGIS (raster2pgsql)

[Blumentrath, Stefan]

Hi,

And sorry for posting on two lists. Just don`t know where the issue belongs to…

I tried to load a set of raster maps in Geotiff format, which I created in 
GRASS using r.external.out, into PostGIS 2.1.2dev.

In PostGIS the raster datasets only contain NoData values, while gdalinfo 
–stats produces reasonable statistics for the respective GeoTiffs.

I did some trouble shooting and found that the problem was that GRASS did not 
assign a numerical NoData value to the GeoTiff, but “nan”.

When I gdal_translate same GeoTiff with –a_nodata -, raster2pgsql loads the 
resulting file just fine.

Is raster2pgsql supposed to read rasters with nan as NoData values (using –N 
- in raster2pgsql had no effect btw.) or should GRASS (r.external.out) 
assign a NoData value to the produced raster datasets?

Many thanks in advance,
Stefan


___
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:  closed 
  Priority:  normal   |   Milestone:  7.0.0  
 Component:  wxGUI| Version:  unspecified
Resolution:  fixed|Keywords:  region 
  Platform:  Unspecified  | Cpu:  Unspecified
--+-

Comment(by neteler):

 Replying to [comment:19 mlennert]:
 ...
 > Does the GUI internally redefine the region for display and then
 > applies that region in that call to g.region ?

 This reminds me of my question posted in grass-dev:

 On Wed, Apr 16, 2014 at 6:09 PM, Markus Neteler  wrote:
 > Hi,
 >
 > when trying to render a large raster map with d.rast in the "command
 > line version"  (d.mon wx0), then it tries to use the current region
 > which leads to a cairo memory error.
 >
 > It seems that the wxGUI is initializing the display in a more
 > reasonable way to downsample the map to be rendered on the fly since
 > it makes no sense to render it at original resolution. This "magic" is
 > yet missing in d.mon.
 >
 > Where is that calculated in wxGUI to get an idea about the calculation
 > of map display window size versus raster map size/resolution?

 Maybe related, maybe not. In any case a resolution/region issue.

-- 
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:  closed 
  Priority:  normal   |   Milestone:  7.0.0  
 Component:  wxGUI| Version:  unspecified
Resolution:  fixed|Keywords:  region 
  Platform:  Unspecified  | Cpu:  Unspecified
--+-

Comment(by mlennert):

 Replying to [comment:18 martinl]:
 > Replying to [comment:17 mlennert]:
 > > > Do you suggest to use this flag by default?
 > >
 > > Yes.
 >
 > please try out r60251 (trunk).
 >

 Doesn't work for me. I still get values such as;

 {{{
 nsres:  9.9953005
 ewres:  9.99522706
 }}}

 while working with the 10m resolution elevation data from the NC dataset.
 I've tried playing with the different constrain settings in the wxGUI
 MapDisplay ("Constrain display resolution to computational settings" and
 "Align region extent based on display size"), but no combination of the
 two seemed to do the trick.

 Does the GUI internally redefine the region for display and then applies
 that region in that call to g.region ?

 Moritz

-- 
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] #2294: t.rast.aggregate: Name output rasters based on start-time

[GRASS GIS]

#2294: t.rast.aggregate: Name output rasters based on start-time
--+-
 Reporter:  sbl   |   Owner:  grass-dev@…  
 Type:  enhancement   |  Status:  new  
 Priority:  normal|   Milestone:  7.1.0
Component:  Default   | Version:  svn-trunk
 Keywords:  t.rast.aggregate  |Platform:  Unspecified  
  Cpu:  Unspecified   |  
--+-
 Using a numerical suffix for aggregated time series data makes it less
 intuitive to use the results outside the TGRASS framework. One has to look
 up the time stamp for e.g. a rastermap "temperature_avg_months_317" in
 order to know which time periode it refers to (even those people who
 produced it), while "temperature_avg_months_1989_09" already tells
 something.

 Please find attached a proposal for naming output rasters based on start
 time - truncated according to granularity, implemented in a flag (s).

 The attached patch is a modification of a patch I made for GRAS 7.0 wich I
 currently use and where it works fine for absolute time datasets. Not sure
 if it is suitable for relative or cyclic time though and it has not been
 tested with GRASS 7.1. So it needs a critical review in any case.

 I do not know if such a solution would be relevant for t.rast.accumulate
 too (I have not used the module yet)...

 If you find it useful I can send a patch for GRASS 7.0 too.

-- 
Ticket URL: 
GRASS GIS 

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