Re: [GRASS-dev] v.rast.stats: ERROR: Input window changed while maps are open for read.

2015-10-26 Thread Sören Gebbert 
Hi,
i messed up r.univar implementing a new flag. I will fix it in trunk
and implement some tests for v.rast.stats and a zone test for
r.univar.

Best regards
Soeren

2015-10-24 20:28 GMT+02:00 Helmut Kudrnovsky :
> Helmut Kudrnovsky wrote
>> hi,
>>
>> by testing the manual example of v.rast.stats, I get following error:
>>
>> v.rast.stats --verbose map=myzipcodes_wake@gbiftest
>> raster=elevation@PERMANENT column_prefix=elev
>> method=minimum,maximum,average,stddev,percentile
>> Adding columns '['elev_minimum DOUBLE PRECISION', 'elev_maximum DOUBLE
>> PRECISION', 'elev_average DOUBLE PRECISION', 'elev_stddev DOUBLE
>> PRECISION', 'elev_percentile_90 DOUBLE PRECISION']'
>> Adding column
>> 
>>  to the table
>> Adding column
>> 
>>  to the table
>> Adding column
>> 
>>  to the table
>> Adding column
>> 
>>  to the table
>> Adding column
>> 
>>  to the table
>> Processing data (13 categories)...
>> ERROR: Input window changed while maps are open for read. Map name
>> 
>> Updating the database ...
>> Statistics calculated from raster map elevation@PERMANENT and
>> uploaded to attribute table of vector map
>> 
>> .
>> DEBUG=3 output
>> 
>>
>> tested with
>>
>> System Info
>> GRASS version: 7.1.svn
>> GRASS SVN revision: 66569
>> Build date: 2015-10-22
>> Build platform: i686-pc-mingw32
>> GDAL: 1.11.3
>> PROJ.4: 4.8.0
>> GEOS: 3.5.0
>> SQLite: 3.7.17
>> Python: 2.7.4
>> wxPython: 2.8.12.1
>> Platform: Windows-7-6.1.7601-SP1 (OSGeo4W)
>
> also tested with
>
> GRASS Version: 7.1.svn
> GRASS SVN revision: 66581
> Build date: 2015-10-23
> Build platform: i686-pc-mingw32
> GDAL: 1.11.3
> PROJ.4: 4.8.0
> GEOS: 3.5.0
> SQLite: 3.7.17
> Python: 2.7.4
> wxPython: 2.8.12.1
> Platform: Windows-Vista-6.0.6002-SP2 (OSGeo4W)
>
> same error:
>
> ERROR: Input window changed while maps are open for read. Map name
> 
>
> but it is not in
> GRASS Version: 7.0.2RC1
> GRASS SVN Revision: 66536
>
> open a ticket
>
>
>
> -
> best regards
> Helmut
> --
> View this message in context: 
> http://osgeo-org.1560.x6.nabble.com/v-rast-stats-ERROR-Input-window-changed-while-maps-are-open-for-read-tp5232313p5232370.html
> Sent from the Grass - Dev mailing list archive at Nabble.com.
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2558: The 'Profile Surfae Map' tool does not function.

2015-10-26 Thread GRASS GIS 
#2558: The 'Profile Surfae Map' tool does not function.
--+-
  Reporter:  humu2015 |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  critical |  Milestone:  6.4.6
 Component:  wxGUI|Version:  unspecified
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Linux
--+-

Comment (by mlennert):

 Replying to [comment:7 annakrat]:
 > Replying to [comment:6 mlennert]:
 > > Is there really no other solution than to wait for the next release ?
 This makes many very nice GUI features completely unusable.
 >
 > The only solution I can see (beside rewriting it using matplotlib) is to
 copy and integrate the particular code with the fix in GRASS. Licence
 should be OK I hope. I can try to do that, but I fear I run into problems
 with different versions of wxPython on different computers. Do we know for
 which versions the code has this bug?

 AFAICT, it's only wxpython 3.0.2. The commit that the above patch corrects
 dates from Oct. 2014 [1], i.e. between the releases of 3.0.1.1 and 3.0.2
 [2].

 I actually tried to apply the proposed patch locally to my wxpython
 installation. I didn't get the same error messages in GRASS anymore, but
 others. But I currently have no time to investigate this any further.
 Sorry...


 [1] http://trac.wxwidgets.org/changeset/77995/svn-wx
 [2] http://www.wxpython.org/

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] r.in.lidar: read multiple LAS files in one run

2015-10-26 Thread Vaclav Petras 
On Mon, Oct 26, 2015 at 1:20 PM, Newcomb, Doug  wrote:

> multiple files at the 4.2 point las 1.2 limit! I can live with slow, just
> concerned about the memory demands working with larger areas.


The processing goes by row chunks. By default everything is in the memory.
You can say that only half of rows will be in the memory at a time by
percent=50 (you have to guess how much memory it will take). It will be
(much) slower because it will iterate over the files (twice in this case).
I was not able to do any tests with large amounts of points but the only
problem will be capacity of some counters for percentage and report. The
actual processing takes one point at a time, so there shouldn't be any
limit. This is by the way still the same as before, I haven't changed
anything in the way how this is handled. Let me know if this doesn't
address your concerns.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Open/close db drivers order

2015-10-26 Thread Glynn Clements 

Radim Blazek wrote:

> Should it better go to the original program between fork() and execve()
> or into the driver executable?

Ideally, it should be done by whatever creates the descriptor in the
first place.

Doing it when spawning a DBMI driver (whether in the parent or in the
child) only avoids the specific case where the process holding onto
the descriptor is a DBMI driver.

There are other types of child process which might be spawned
(possibly invisibly to GRASS, e.g. an external library spawning a
"helper" process), and the consequences are always the same.

If I was going to add a mechanism for closing all descriptors other
than 0/1/2, it would probably be as an option to G_spawn_ex().

Also, the situation is potentially worse on Windows, as handles can't
be enumerated (and even if they could, process creation is atomic;
there's no way to execute code in the child process prior to the start
of the new program). If CreateProcess() is called with bInheritHandles
set to TRUE (which is required for stdin/stdout/stderr to be
inherited), all inheritable handles are inherited.

> > The only robust solution is for the original program to systematically
> > set the close-on-exec flag on every descriptor *except* those which
> > are meant to be inherited.
> 
> The original program may be using third party libraries which will
> never care of.

For libraries, it's even more important that they set the
close-on-exec flag on "internal" descriptors, because nothing else
can.

Ultimately, you can have one library which creates "internal"
descriptors and another library which spawns "internal" helper
processes, and there's not much that the main program can do about the
interaction between these.

It's generally considered the responsibility of the code creating
descriptors to set the close-on-exec flag, because that's easier (and
safer) than expecting code which spawns child processes to close
descriptors which it knows nothing about.

In this case, the key issue is that the DBMI client library needs to
set the close-on-exec flag on p1[WRITE], as it's important that this
descriptor doesn't get duplicated.

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

Re: [GRASS-dev] Some wxPython 3 issues

2015-10-26 Thread Markus Neteler 
Hi,

using the scatterplot tool (I loaded two landsat channels), I found a new issue:

Settings: unable to get value 'scatter:rasters:None'
/usr/lib64/python2.7/site-
packages/wx-3.0-gtk3/wx/lib/plot.py:377: FutureWarning:
comparison to `None` will result in an elementwise object
comparison in the future.
  if coord == None:
/usr/lib64/python2.7/site-
packages/wx-3.0-gtk3/wx/lib/plot.py:1201: FutureWarning:
comparison to `None` will result in an elementwise object
comparison in the future.
  if xAxis == None or yAxis == None:

It seems to produce the plot anyway but maybe worthwhile fixing.
This happened in G7.0.svn of today.

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

Re: [GRASS-dev] Some wxPython 3 issues

2015-10-26 Thread Anna Petrášová 
On Mon, Oct 26, 2015 at 9:53 AM, Markus Neteler  wrote:

> Hi,
>
> using the scatterplot tool (I loaded two landsat channels), I found a new
> issue:
>
> Settings: unable to get value 'scatter:rasters:None'
> /usr/lib64/python2.7/site-
> packages/wx-3.0-gtk3/wx/lib/plot.py:377: FutureWarning:
> comparison to `None` will result in an elementwise object
> comparison in the future.
>   if coord == None:
> /usr/lib64/python2.7/site-
> packages/wx-3.0-gtk3/wx/lib/plot.py:1201: FutureWarning:
> comparison to `None` will result in an elementwise object
> comparison in the future.
>   if xAxis == None or yAxis == None:
>
> It seems to produce the plot anyway but maybe worthwhile fixing.
> This happened in G7.0.svn of today.
>

That's 'future warning', so it still works. It's coming from wxpython
library, so it's the similar problem as in
https://trac.osgeo.org/grass/ticket/2558#comment:8

>
> thanks
> Markus
> ___
> 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] r.in.lidar: read multiple LAS files in one run

2015-10-26 Thread Vaclav Petras 
Hi all,

r.in.lidar in trunk (r66601) can now read multiple LAS files specified in a
text file (similarly to what e.g. r.colors supports for raster maps). It is
nothing fancy, no indexing or something, but you can bin point from several
tiles without any edge effects. It is not particularly fast either, but it
is not worse than the original code.

Here is an example with custom resolution and extent derived from the data:

r.in.lidar file=list.txt output=raster method=mean -e res=30 zrange=-1,200

The file list.txt contains something like:

/home/johnuser/data/tile_55.las
/home/johnuser/data/tile_56.las
/home/johnuser/data/tile_57.las

A major refactoring of the code (r66593-r66596) was necessary for smooth
implementation. I did my best to test different combination of parameters
with comparison to original results, but I was not able to create an
automated test partially for the lack of standardized input data. More
testing appreciated.

The options and tabs were reorganized to accommodate new inputs, but the
documentation is missing.

Let me know what you think.

Vaclav


https://grass.osgeo.org/grass71/manuals/r.in.lidar.html
https://trac.osgeo.org/grass/changeset/66601
https://trac.osgeo.org/grass/changeset/66593
https://trac.osgeo.org/grass/changeset/66594
https://trac.osgeo.org/grass/changeset/66595
https://trac.osgeo.org/grass/changeset/66596
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.in.lidar: read multiple LAS files in one run

2015-10-26 Thread Newcomb, Doug 
Vaclav,

I cannot wait to try this with multiple files at the 4.2 point las 1.2
limit! I can live with slow, just concerned about the memory demands
working with larger areas.

Thank you very much!

Doug







On Mon, Oct 26, 2015 at 11:28 AM, Vaclav Petras 
wrote:

> Hi all,
>
> r.in.lidar in trunk (r66601) can now read multiple LAS files specified in
> a text file (similarly to what e.g. r.colors supports for raster maps). It
> is nothing fancy, no indexing or something, but you can bin point from
> several tiles without any edge effects. It is not particularly fast either,
> but it is not worse than the original code.
>
> Here is an example with custom resolution and extent derived from the data:
>
> r.in.lidar file=list.txt output=raster method=mean -e res=30 zrange=-1,200
>
> The file list.txt contains something like:
>
> /home/johnuser/data/tile_55.las
> /home/johnuser/data/tile_56.las
> /home/johnuser/data/tile_57.las
>
> A major refactoring of the code (r66593-r66596) was necessary for smooth
> implementation. I did my best to test different combination of parameters
> with comparison to original results, but I was not able to create an
> automated test partially for the lack of standardized input data. More
> testing appreciated.
>
> The options and tabs were reorganized to accommodate new inputs, but the
> documentation is missing.
>
> Let me know what you think.
>
> Vaclav
>
>
> https://grass.osgeo.org/grass71/manuals/r.in.lidar.html
> https://trac.osgeo.org/grass/changeset/66601
> https://trac.osgeo.org/grass/changeset/66593
> https://trac.osgeo.org/grass/changeset/66594
> https://trac.osgeo.org/grass/changeset/66595
> https://trac.osgeo.org/grass/changeset/66596
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
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.
As a federal employee, my email may be subject to FOIA request.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev