Re: [GRASS-dev] [GRASS-SVN] r66413 - grass-addons/grass7/vector/v.kriging

[Vaclav Petras]

On Mon, Oct 12, 2015 at 6:53 AM, Glynn Clements 
wrote:
>
> > Having la.h as a separate header would conveniently hide the compilation
> > issue on that Debian server.
> >
> > So, should I remove la.h from gmath.h?
>
> I think so.

la.h removed from gmath.h in r66485. I tested that with and without LAPACK
configured. Work as expected. Perhaps the #error can be removed from the
modules if it makes sense to have it in la.h (as I did that).

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

Re: [GRASS-dev] Error reading raster data for row xxx (only when using r.series and t.rast.series)

[Dylan Beaudette]

On Tue, Oct 13, 2015 at 4:25 PM, Dylan Beaudette
 wrote:
> On Tue, Oct 13, 2015 at 11:06 AM, Markus Neteler  wrote:
>>
>> On Oct 13, 2015 7:01 PM, "Dylan Beaudette" 
>> wrote:
>>>
>>> Hi Markus,
>>>
>>> GRASS version information:
>>>
>>>  ./configure  --without-odbc --without-mysql --with-readline
>>> --with-cxx --enable-largefile --with-freetype
>>> --with-freetype-includes=/usr/include/freetype2 --with-sqlite
>>> --with-python --with-pthread
>>
>> I would not use pthread.
>>
>
> Hi Markus,
>
> I have done some tests after re-compiling _without_ pthreads. So far,
> no errors from r.series. Also I seem to be getting better performance
> form r.mapcalc and t.rast.series, especially when working with files
> loaded via r.external. I don't know enough about pthreads to speculate
> further. Any ideas?
>
> I'll report back when the script finishes, probably 20 hours or so.
>

Reporting back, same error occurring in a seemingly random way.

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

Re: [GRASS-dev] installing v.mapcalc fails

[Sören Gebbert]

Hi,
the GSoC implementation of v.mapcalc is still available:
https://code.google.com/p/grass-gis-temporal-algebra/source/browse/#svn%2Ftrunk%2Fv.mapcalc

However, the approach in the GSoC v.mapcalc is very different from the
v.mapcalc addon from 2002.
The algebraic expressions are applied to whole vector maps, rather
than single points, list of points, lines or polygons.

Best regards
Soeren


2015-10-13 3:53 GMT+02:00 Vaclav Petras :
>
> On Mon, Oct 12, 2015 at 6:24 AM, Glynn Clements 
> wrote:
>>
>> Markus Neteler wrote:
>>
>> >  wrote:
>> > ...
>> > > Sorry for the late follow up. The add-on installs now. When trying to
>> > > run
>> > > it, however, nothing happens.
>> >
>> > It does not have a parser (yet?), so I suppose it reads from stdin.
>>
>> Yes.
>>
>> But it doesn't have any code to read or write GRASS vectors, either.
>> v.mapcalc appears to be a work-in-progress which hasn't actually made
>> noticeable progress since it was added.
>
> Then I suggest to remove it from the Makefile parent directory and also
> disable it in the addons build scripts if there is something more needed
> than r66406 [1] which is blacklisting it somehow already. It does not
> fulfill what user would expect (at least some functionality). Those who want
> to continue development will get it through svn.
>
> I'm not sure happened [2] with the v.mapcalc implemented as a test case in
> GSoC [3] and if the functionality can be still used. But this seems like a
> good alternative to the code in addons.
>
> Vaclav
>
> [1] https://trac.osgeo.org/grass/changeset/66406
> [2] https://lists.osgeo.org/pipermail/grass-dev/2013-October/065908.html
> [3]
> https://grasswiki.osgeo.org/wiki/GRASS_GSoC_2013_Temporal_GIS_Algebra_for_raster_and_vector_data_in_GRASS#v.mapcalc
>
> ___
> 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] Error reading raster data for row xxx (only when using r.series and t.rast.series)

[Moritz Lennert]

On 12/10/15 23:35, Dylan Beaudette wrote:

Hi,

Over the last couple of years I have noticed a very strange raster
corruption (?) issues when using r.series, and now more recently,
t.rast.series. Typically, I'll generate a large number of maps with
r.sun or t.rast.mapcalc and then aggregate the series with r.series or
t.rast.series. About 50% of the time the command runs as expected, the
other half of the time r.series or t.rast.series gives me an error
like this:

Error reading raster data for row xxx (testmap)

After this error, I can no longer perform any kind of operation on map
"testmap" without the dreaded Error reading raster data for row xxx...

The situation was worse when using a MASK map, possibly related to a
similar (fixed?) issue discussed in this thread:

http://lists.osgeo.org/pipermail/grass-dev/2015-July/075627.html

Within that thread, Glynn mentioned that this type of error was
probably related to pthreads and concurrent processes. The temporary
fix entailed:

export WORKERS=0

I have tried this on my machine but the results are the same,
non-deterministic corruption (?) of one input to r.series or
t.rast.series.

I have encountered this error on several disks, mirrored HDDs, single
HDD, and now on an SSD. I don't think that this is a disk problem,
rather, something that r.series or t.rast.series is "doing" to the
files it operates on.

Is there some possibility that one of these commands is leaving a file
"open" or in some kind of intermediate state that prevents subsequent
commands from accessing the file?

I'll try to create a sample dataset to send over. In the meantime is
there any kind of diagnostic information that I can report back with?


Are you using a mask, as was the case in the thread you cite ?

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

Re: [GRASS-dev] [GRASS GIS] #2758: i.gensigset error G_calloc: unable to allocate 115671215 * 8 bytes of memory at lib/imagery/sigset.c:24

[GRASS GIS]

#2758: i.gensigset error G_calloc: unable to allocate  115671215 * 8 bytes of
memory at lib/imagery/sigset.c:24
---+-
  Reporter:  shobhitpipil  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  critical  |  Milestone:  7.1.0
 Component:  Raster|Version:  7.0.1
Resolution:|   Keywords:
   CPU:  x86-64|   Platform:  MSWindows 8
---+-

Comment (by shobhitpipil):

 g.region -p
 projection: 1 (UTM)
 zone:   44
 datum:  wgs84
 ellipsoid:  wgs84
 north:  2923178.04346713
 south:  2890384.89306765
 west:   426739.68101223
 east:   500845.08464976
 nsres:  2.91650217
 ewres:  2.91650217
 rows:   11244
 cols:   25409
 cells:  285698796


 I am using windows 10 OS with 3.40 GHz 8 core processor and 16 GB RAM

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] shutil_which on windows

[Luca Delucchi]

Hi devs,

I have a problem with the function shutil_which (core.py) on windows
with grass 7.0.1 installed using OSGeo4W.

The function return None for each module of GRASS, the problem seems
to me that  C:\OSGeo4W\apps\grass\grass-7.0.1\bin is not in the path
variable

>>> print gcore.shutil_which('r.mask')
['.', 'C:\\OSGeo4W\\apps\\qgis\\bin', 'C:\\OSGeo4W\\bin',
'C:\\Windows\\system32', 'C:\\Windows', 'C:\\Windows\\WBem',
'C:\\OSGeo4W\\apps\\msys\\bin',
'C:\\OSGeo4W\\apps\\Python27\\Scripts']
['r.mask.py', 'r.mask.COM', 'r.mask.EXE', 'r.mask.BAT', 'r.mask.CMD',
'r.mask.VBS', 'r.mask.VBE', 'r.mask.JS', 'r.mask.JSE', 'r.mask.WSF',
'r.mask.WSH', 'r.mask.MSC']
None

do you have any idea?
are you able to get this problem on windows?

(On Linux everything is working)

-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Temporal framework: Proper way to register new maps from a python module?

[Laurent C.]

Hi Sören,

Thank you for your answer. I've made some tests with the second option
and it seems to works well. It looks like I don't need to use
.update() or .insert() before registering the RasterDataset list in
the DB. Could you please confirm that it is unnecessary?

Regards,
Laurent


2015-10-09 22:45 GMT+01:00 Sören Gebbert :
> Hi Laurent,
> please do not use the legacy r.timestamp module to set the time stamp
> for maps. The feature to use time stamps set by r.timestamp was only
> implemented, to migrate from old grass locations with time stamped
> maps to the temporal framework approach more easily. I am not sure if
> this works well with relative time.
>
> The easiest way is to generate a text file with name, start time and
> end time. If you insist to avoid using text files, then generate a
> list of RasterDataset[1] objects, set the time for these objects
> (set_absolute_time() or set_relative_time()) and use
> register_map_object_list() [2] to register them in a space time raster
> dataset.
>
> [1] 
> https://grass.osgeo.org/grass70/manuals/libpython/temporal.html#temporal.space_time_datasets.RasterDataset
> [2] 
> https://grass.osgeo.org/grass70/manuals/libpython/temporal.html#temporal.register.register_map_object_list
>
> Best regards
> Soeren
>
> 2015-10-09 17:13 GMT+02:00 Laurent C. :
>> Hello,
>>
>> I'm writing a module that generates raster maps and register them in
>> newly created strds.
>> The temporal type of the generated strds depends on the entry values
>> of the module.
>> I've seen in the documentation that
>> register_maps_in_space_time_dataset() can read the timestamp from the
>> GRASS raster, so my module is currently doing the following:
>>  - writes maps
>>  - assign timestamp, either absolute or relative with r.timestamp
>>  - at the end, register all the generated maps from a list using
>> register_maps_in_space_time_dataset()
>>
>> But I end up with the following error with relative time:
>> File "/home/lo/Programación/t_sim_flood/gis.py", line 286, in
>> register_maps_in_strds
>> strds_id, maps=map_lst_str, unit='seconds')
>>   File "/usr/lib/grass71/etc/python/grass/temporal/register.py", line
>> 289, in register_maps_in_space_time_dataset
>> statement += map.insert(dbif=dbif, execute=False)
>>   File "/usr/lib/grass71/etc/python/grass/temporal/abstract_map_dataset.py",
>> line 273, in insert
>> self.write_timestamp_to_grass()
>>   File "/usr/lib/grass71/etc/python/grass/temporal/space_time_datasets.py",
>> line 242, in write_timestamp_to_grass
>> self._convert_timestamp())
>>   File "/usr/lib/grass71/etc/python/grass/temporal/abstract_map_dataset.py",
>> line 124, in _convert_timestamp
>> start = datetime_to_grass_datetime_string(start_time)
>>   File "/usr/lib/grass71/etc/python/grass/temporal/datetime_math.py",
>> line 817, in datetime_to_grass_datetime_string
>> if dt.tzinfo is not None:
>> AttributeError: 'NoneType' object has no attribute 'tzinfo'
>>
>> The grass timestamp are well written and are visible with r.info.
>> If I give a start=0 to register_maps_in_space_time_dataset(), all the
>> maps are registered in the strds without generating errors, but they
>> all starts and ends at 0:
>>  + Relative time 
>> -+
>>  | Start time:. 0
>>  | End time:... 0
>>  | Relative time unit:. seconds
>>  | Granularity: 0
>>  | Temporal type of maps:.. point
>>  + Spatial extent 
>> +
>>
>> And the raster timestamps are overwritten.
>> I haven't tried yet with absolute type.
>> How should I proceed? Is there a way to avoid generating a temporary
>> text file to feed register_maps_in_space_time_dataset()?
>>
>> Regards,
>> Laurent
>> ___
>> 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 GIS] #2758: i.gensigset error G_calloc: unable to allocate 115671215 * 8 bytes of memory at lib/imagery/sigset.c:24

[GRASS GIS]

#2758: i.gensigset error G_calloc: unable to allocate  115671215 * 8 bytes of
memory at lib/imagery/sigset.c:24
--+-
 Reporter:  shobhitpipil  |  Owner:  grass-dev@…
 Type:  defect| Status:  new
 Priority:  critical  |  Milestone:  7.1.0
Component:  Raster|Version:  7.0.1
 Keywords:|CPU:  x86-64
 Platform:  MSWindows 8   |
--+-
 G_calloc: unable to allocate 115671215 * 8 bytes of memory at
 lib/imagery/sigset.c:24

--
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] #2758: i.gensigset error G_calloc: unable to allocate 115671215 * 8 bytes of memory at lib/imagery/sigset.c:24

[GRASS GIS]

#2758: i.gensigset error G_calloc: unable to allocate  115671215 * 8 bytes of
memory at lib/imagery/sigset.c:24
---+-
  Reporter:  shobhitpipil  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  critical  |  Milestone:  7.1.0
 Component:  Raster|Version:  7.0.1
Resolution:|   Keywords:
   CPU:  x86-64|   Platform:  MSWindows 8
---+-

Comment (by neteler):

 Your resolution shows 2.91650217m - is this intentional? Should it be
 perhaps 3m or even lower?

 Prior to i.gensigset it is recommended to align the computational region
 to the input map:

 g.region raster=inputmap -p

--
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] #2758: i.gensigset error G_calloc: unable to allocate 115671215 * 8 bytes of memory at lib/imagery/sigset.c:24

[GRASS GIS]

#2758: i.gensigset error G_calloc: unable to allocate  115671215 * 8 bytes of
memory at lib/imagery/sigset.c:24
---+-
  Reporter:  shobhitpipil  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  critical  |  Milestone:  7.1.0
 Component:  Raster|Version:  7.0.1
Resolution:|   Keywords:
   CPU:  x86-64|   Platform:  MSWindows 8
---+-
Changes (by shobhitpipil):

 * Attachment "Picture1.png" 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] #2757: r.import: ERROR: Input raster map is outside current region

[GRASS GIS]

#2757: r.import: ERROR: Input raster map is outside current region
--+-
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.0.2
 Component:  Python   |Version:  svn-trunk
Resolution:  fixed|   Keywords:  r.import
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by neteler):

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


Comment:

 Thanks, with -l we can successfully import the Bioclim data which slightly
 exceed the "world extent".

 (for the record, the -l flag was added in r37469 in r.in.gdal)

 So only the -n flag remains unclear to me but we didn't need to use it
 here.

 Closing since the original problem is 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] #2757: r.import: ERROR: Input raster map is outside current region

[Moritz Lennert]

On 13/10/15 12:48, GRASS GIS wrote:

#2757: r.import: ERROR: Input raster map is outside current region
--+-
   Reporter:  neteler  |  Owner:  grass-dev@…
   Type:  defect   | Status:  closed
   Priority:  normal   |  Milestone:  7.0.2
  Component:  Python   |Version:  svn-trunk
Resolution:  fixed|   Keywords:  r.import
CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by neteler):

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


Comment:

  Thanks, with -l we can successfully import the Bioclim data which slightly
  exceed the "world extent".

  (for the record, the -l flag was added in r37469 in r.in.gdal)

  So only the -n flag remains unclear to me but we didn't need to use it
  here.


The -n flag comes from r.proj and is explained as such in the r.proj man 
page:


"When reprojecting whole-world maps the user should disable map-trimming 
with the -n flag. Trimming is not useful here because the module has the 
whole map in memory anyway. Besides that, world "edges" are hard (or 
impossible) to find in projections other than latitude-longitude so 
results may be odd with trimming."


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

Re: [GRASS-dev] Temporal framework: Proper way to register new maps from a python module?

[Sören Gebbert]

Hi Laurent,

2015-10-13 11:26 GMT+02:00 Laurent C. :
> Hi Sören,
>
> Thank you for your answer. I've made some tests with the second option
> and it seems to works well. It looks like I don't need to use
> .update() or .insert() before registering the RasterDataset list in
> the DB. Could you please confirm that it is unnecessary?

You don't need to perform any insert() or update() yourself, the
register function takes care of that.
You only need to set the name, mapset and timestamp for the
RasterDataset objects, put them into a list and pass them to the
register function.

Have a look at this code from the temporal aggregation:
https://trac.osgeo.org/grass/browser/grass/trunk/lib/python/temporal/aggregation.py#L287

Line 287 to 296

Best regards
Soeren

> Regards,
> Laurent
>
>
> 2015-10-09 22:45 GMT+01:00 Sören Gebbert :
>> Hi Laurent,
>> please do not use the legacy r.timestamp module to set the time stamp
>> for maps. The feature to use time stamps set by r.timestamp was only
>> implemented, to migrate from old grass locations with time stamped
>> maps to the temporal framework approach more easily. I am not sure if
>> this works well with relative time.
>>
>> The easiest way is to generate a text file with name, start time and
>> end time. If you insist to avoid using text files, then generate a
>> list of RasterDataset[1] objects, set the time for these objects
>> (set_absolute_time() or set_relative_time()) and use
>> register_map_object_list() [2] to register them in a space time raster
>> dataset.
>>
>> [1] 
>> https://grass.osgeo.org/grass70/manuals/libpython/temporal.html#temporal.space_time_datasets.RasterDataset
>> [2] 
>> https://grass.osgeo.org/grass70/manuals/libpython/temporal.html#temporal.register.register_map_object_list
>>
>> Best regards
>> Soeren
>>
>> 2015-10-09 17:13 GMT+02:00 Laurent C. :
>>> Hello,
>>>
>>> I'm writing a module that generates raster maps and register them in
>>> newly created strds.
>>> The temporal type of the generated strds depends on the entry values
>>> of the module.
>>> I've seen in the documentation that
>>> register_maps_in_space_time_dataset() can read the timestamp from the
>>> GRASS raster, so my module is currently doing the following:
>>>  - writes maps
>>>  - assign timestamp, either absolute or relative with r.timestamp
>>>  - at the end, register all the generated maps from a list using
>>> register_maps_in_space_time_dataset()
>>>
>>> But I end up with the following error with relative time:
>>> File "/home/lo/Programación/t_sim_flood/gis.py", line 286, in
>>> register_maps_in_strds
>>> strds_id, maps=map_lst_str, unit='seconds')
>>>   File "/usr/lib/grass71/etc/python/grass/temporal/register.py", line
>>> 289, in register_maps_in_space_time_dataset
>>> statement += map.insert(dbif=dbif, execute=False)
>>>   File "/usr/lib/grass71/etc/python/grass/temporal/abstract_map_dataset.py",
>>> line 273, in insert
>>> self.write_timestamp_to_grass()
>>>   File "/usr/lib/grass71/etc/python/grass/temporal/space_time_datasets.py",
>>> line 242, in write_timestamp_to_grass
>>> self._convert_timestamp())
>>>   File "/usr/lib/grass71/etc/python/grass/temporal/abstract_map_dataset.py",
>>> line 124, in _convert_timestamp
>>> start = datetime_to_grass_datetime_string(start_time)
>>>   File "/usr/lib/grass71/etc/python/grass/temporal/datetime_math.py",
>>> line 817, in datetime_to_grass_datetime_string
>>> if dt.tzinfo is not None:
>>> AttributeError: 'NoneType' object has no attribute 'tzinfo'
>>>
>>> The grass timestamp are well written and are visible with r.info.
>>> If I give a start=0 to register_maps_in_space_time_dataset(), all the
>>> maps are registered in the strds without generating errors, but they
>>> all starts and ends at 0:
>>>  + Relative time 
>>> -+
>>>  | Start time:. 0
>>>  | End time:... 0
>>>  | Relative time unit:. seconds
>>>  | Granularity: 0
>>>  | Temporal type of maps:.. point
>>>  + Spatial extent 
>>> +
>>>
>>> And the raster timestamps are overwritten.
>>> I haven't tried yet with absolute type.
>>> How should I proceed? Is there a way to avoid generating a temporary
>>> text file to feed register_maps_in_space_time_dataset()?
>>>
>>> Regards,
>>> Laurent
>>> ___
>>> 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] #1434: g.extension: option to specify proxy server

[GRASS GIS]

#1434: g.extension: option to specify proxy server
-+-
  Reporter:  hamish  |  Owner:  grass-dev@…
  Type:  | Status:  new
  enhancement|
  Priority:  major   |  Milestone:  7.0.2
 Component:  |Version:  svn-trunk
  Installation   |
Resolution:  |   Keywords:  g.extension, urllib, wget, r.in.wms
   CPU:  All |   Platform:  All
-+-
Changes (by neteler):

 * milestone:  6.4.4 => 7.0.2


Comment:

 While the GRASS GIS 7's version of g.extension comes with proxy support,
 this crashes when the proxy requires authorization:


 {{{
 (Tue Oct 13 11:51:20 2015)
 g.extension -s extension=r.seg operation=add
 proxy=http=http://proxy.unige.it:8080
 Downloading precompiled GRASS Addons ...
 Traceback (most recent call last):
   File "C:\OSGeo4W\apps\grass\grass-7.1.svn/scripts/g.extens
 ion.py", line 1692, in 
 sys.exit(main())
   File "C:\OSGeo4W\apps\grass\grass-7.1.svn/scripts/g.extens
 ion.py", line 1675, in main
 install_extension(source=source, url=url, xmlurl=xmlurl)
   File "C:\OSGeo4W\apps\grass\grass-7.1.svn/scripts/g.extens
 ion.py", line 637, in install_extension
 ret += install_extension_win(module)
   File "C:\OSGeo4W\apps\grass\grass-7.1.svn/scripts/g.extens
 ion.py", line 895, in install_extension_win
 url_file = urlopen(zfile, proxies=PROXIES)
   File "C:\OSGeo4W\apps\Python27\lib\urllib.py", line 87, in
 urlopen
 return opener.open(url)
   File "C:\OSGeo4W\apps\Python27\lib\urllib.py", line 208,
 in open
 return getattr(self, name)(url)
   File "C:\OSGeo4W\apps\Python27\lib\urllib.py", line 359,
 in open_http
 return self.http_error(url, fp, errcode, errmsg,
 headers)
   File "C:\OSGeo4W\apps\Python27\lib\urllib.py", line 372,
 in http_error
 result = method(url, fp, errcode, errmsg, headers)
   File "C:\OSGeo4W\apps\Python27\lib\urllib.py", line 715,
 in http_error_407
 errcode, errmsg, headers)
   File "C:\OSGeo4W\apps\Python27\lib\urllib.py", line 381,
 in http_error_default
 raise IOError, ('http error', errcode, errmsg, headers)
 IOError: ('http error', 407, 'Proxy Authentication
 Required', )
 (Tue Oct 13 11:51:21 2015) Command finished (0 sec)
 }}}

 Can this please turned into a proper error message? Thanks.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Using a dynamic text in module header for parser

[Michel Wortmann]

Hi Stefan,
I have been meaning to implement something like this too and got your 
example to work with the additional step of setting the environment 
variable GRASS_ADDON_PATH (and under unix setting the permissions). Here 
is my example just parsing the first mapset it finds:


import os, tempfile, stat
import grass.script as grass

module = 'subbasins.py'

if __name__=='__main__':
answer = grass.mapsets(search_path = True)
available_mapsets = grass.mapsets()

script=file(module,'r').read()

with tempfile.NamedTemporaryFile(delete = False) as s:
s.write('''#!/usr/bin/env python
# -*- coding: utf-8 -*-

{script}

#%Option
#% key:{option}
#%end

'''.format(script=script,option=available_mapsets[0].lower()))

startcmd = 'python '+s.name
# set env variable
aoev='GRASS_ADDON_PATH'
tmpdir = os.path.basename(s.name)
if aoev in os.environ:
os.environ[aoev]=[tmpdir]+os.environ[aoev]
else:
os.environ[aoev]=[tmpdir]
# set permissions
os.chmod(s.name, os.stat(s.name).st_mode | stat.S_IEXEC)
# start module
os.system(startcmd)
os.remove(s.name)

Let me know if this works under Windows too.
Michel

On 10/12/2015 12:55 PM, Blumentrath, Stefan wrote:


Hi again,

Now I found out that the parser section in the inner python script was 
not formated properly.


However, when I now call the inner script with ‘--ui’ I get an error:

Unable to fetch interface description for command ‘tmpjksdfjiol’

Details:

Try to set up GRASS_ADDON_PATH or GRASS_ADDON_BASE variable.

It was neither possible to run the script using grass.run_command() 
(on Windows).


Cheers

Stefan

*From:*grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] *On Behalf 
Of *Blumentrath, Stefan

*Sent:* 12. oktober 2015 11:36
*To:* GRASS developers list (grass-dev@lists.osgeo.org) 


*Subject:* [GRASS-dev] Using a dynamic text in module header for parser

Hi,

I would like to fill:

#% options:

and

#% answer

in a parser option for a python script dynamically.  In particular I 
want to have tickboxes for available mapsets in the module GUI…


Meaning something like this  (but less complex / not interactive):

http://permalink.gmane.org/gmane.comp.gis.grass.gui/667

My amateur programming skills do unfortunately not allow me to really 
understand how to accomplish what Glynn describes in the post above…


I tried to generate and run a temporary python script from within my 
script like this:


def main():

answer = grass.mapsets(search_path = True)

available_mapsets = str(grass.mapsets())

with tempfile.NamedTemporaryFile(delete = False) as s:

s.write(''' #!/usr/bin/env python

# -*- coding: utf-8 -*-

# Here comes the full module with header for the parser

#% options: ''' + str(','.join(available_mapsets))

…

’’’)

startcmd = 'python ' + s.name

os.system(startcmd)

os.remove(s.name)

But that way the GUI never starts, when I call the outer script from 
GRASS and it seems that option never get parsed…


Any hints how to proceed?

Thanks for helping 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] shutil_which on windows

[Anna Petrášová]

On Tue, Oct 13, 2015 at 5:48 AM, Luca Delucchi  wrote:

> Hi devs,
>
> I have a problem with the function shutil_which (core.py) on windows
> with grass 7.0.1 installed using OSGeo4W.


> The function return None for each module of GRASS, the problem seems
> to me that  C:\OSGeo4W\apps\grass\grass-7.0.1\bin is not in the path
> variable
>
> >>> print gcore.shutil_which('r.mask')
> ['.', 'C:\\OSGeo4W\\apps\\qgis\\bin', 'C:\\OSGeo4W\\bin',
> 'C:\\Windows\\system32', 'C:\\Windows', 'C:\\Windows\\WBem',
> 'C:\\OSGeo4W\\apps\\msys\\bin',
> 'C:\\OSGeo4W\\apps\\Python27\\Scripts']
> ['r.mask.py', 'r.mask.COM', 'r.mask.EXE', 'r.mask.BAT', 'r.mask.CMD',
> 'r.mask.VBS', 'r.mask.VBE', 'r.mask.JS', 'r.mask.JSE', 'r.mask.WSF',
> 'r.mask.WSH', 'r.mask.MSC']
> None
>
> do you have any idea?
> are you able to get this problem on windows?
>

In standalone wingrass, it is working for me, returns C:\Program Files
(x86)\GRASS GIS 7.1.svn\bin\r.mask.BAT. In OSGeo4W as
well: 'C:\\OSGeo4W\\apps\\grass\\grass-7.0.1\\bin\\r.mask.BAT'

>
> (On Linux everything is working)
>
> --
> ciao
> Luca
>
> http://gis.cri.fmach.it/delucchi/
> www.lucadelu.org
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Using a dynamic text in module header for parser

[Anna Petrášová]

Hi,

you can look how Layer manager launches scripts:
https://trac.osgeo.org/grass/browser/grass/trunk/gui/wxpython/lmgr/frame.py#L841,
I think it requires setting the GRASS_ADDON_PATH

I remember this problem, maybe it's in parser. There might be a ticket
already, but I am not sure. If you can't find anything related, please
create a ticket.

On Tue, Oct 13, 2015 at 9:33 AM, Michel Wortmann 
wrote:

> Hi Stefan,
> I have been meaning to implement something like this too and got your
> example to work with the additional step of setting the environment
> variable GRASS_ADDON_PATH (and under unix setting the permissions). Here is
> my example just parsing the first mapset it finds:
>
> import os, tempfile, stat
> import grass.script as grass
>
> module = 'subbasins.py'
>
> if __name__=='__main__':
> answer = grass.mapsets(search_path = True)
> available_mapsets = grass.mapsets()
>
> script=file(module,'r').read()
>
> with tempfile.NamedTemporaryFile(delete = False) as s:
> s.write('''#!/usr/bin/env python
> # -*- coding: utf-8 -*-
>
> {script}
>
> #%Option
> #% key:{option}
> #%end
>
> '''.format(script=script,option=available_mapsets[0].lower()))
>
> startcmd = 'python '+s.name
> # set env variable
> aoev='GRASS_ADDON_PATH'
> tmpdir = os.path.basename(s.name)
> if aoev in os.environ:
> os.environ[aoev]=[tmpdir]+os.environ[aoev]
> else:
> os.environ[aoev]=[tmpdir]
> # set permissions
> os.chmod(s.name, os.stat(s.name).st_mode | stat.S_IEXEC)
> # start module
> os.system(startcmd)
> os.remove(s.name)
>
> Let me know if this works under Windows too.
> Michel
>
> On 10/12/2015 12:55 PM, Blumentrath, Stefan wrote:
>
> Hi again,
>
>
>
> Now I found out that the parser section in the inner python script was not
> formated properly.
>
>
>
> However, when I now call the inner script with ‘--ui’ I get an error:
>
> Unable to fetch interface description for command ‘tmpjksdfjiol’
>
>
>
> Details:
>
> Try to set up GRASS_ADDON_PATH or GRASS_ADDON_BASE variable.
>
>
>
> It was neither possible to run the script using grass.run_command() (on
> Windows).
>
>
>
> Cheers
>
> Stefan
>
>
>
>
>
>
>
> *From:* grass-dev [mailto:grass-dev-boun...@lists.osgeo.org
> ] *On Behalf Of *Blumentrath, Stefan
> *Sent:* 12. oktober 2015 11:36
> *To:* GRASS developers list (grass-dev@lists.osgeo.org)
>  
> *Subject:* [GRASS-dev] Using a dynamic text in module header for parser
>
>
>
> Hi,
>
>
>
> I would like to fill:
>
> #% options:
>
> and
>
> #% answer
>
> in a parser option for a python script dynamically.  In particular I want
> to have tickboxes for available mapsets in the module GUI…
>
>
>
> Meaning something like this  (but less complex / not interactive):
>
> http://permalink.gmane.org/gmane.comp.gis.grass.gui/667
>
> My amateur programming skills do unfortunately not allow me to really
> understand how to accomplish what Glynn describes in the post above…
>
>
>
> I tried to generate and run a temporary python script from within my
> script like this:
>
> def main():
>
>
>
> answer = grass.mapsets(search_path = True)
>
> available_mapsets = str(grass.mapsets())
>
>
>
> with tempfile.NamedTemporaryFile(delete = False) as s:
>
> s.write('''#!/usr/bin/env python
>
> # -*- coding: utf-8 -*-
>
> # Here comes the full module with header for the parser
>
> #% options: ''' + str(','.join(available_mapsets))
>
> …
>
> ’’’)
>
> startcmd = 'python ' + s.name
>
> os.system(startcmd)
>
> os.remove(s.name)
>
>
>
> But that way the GUI never starts, when I call the outer script from GRASS
> and it seems that option never get parsed…
>
>
>
> Any hints how to proceed?
>
>
>
> Thanks for helping in advance.
>
>
>
> Stefan
>
>
>
>
>
>
> ___
> grass-dev mailing 
> listgrass-dev@lists.osgeo.orghttp://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 mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2757: r.import: ERROR: Input raster map is outside current region

[Markus Neteler]

On Tue, Oct 13, 2015 at 3:37 PM, Anna Petrášová  wrote:
> On Tue, Oct 13, 2015 at 9:03 AM, Markus Neteler  wrote:
>
> It is sort of hidden in the Optional tab, I am not sure if we gain much by
> hiding it completely.

As mentioned, I don't even understand the meaning of -n in r.proj. If
anyone knows, please rephrase it in r.proj's manual.

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

Re: [GRASS-dev] [GRASS GIS] #2757: r.import: ERROR: Input raster map is outside current region

[Anna Petrášová]

On Tue, Oct 13, 2015 at 9:03 AM, Markus Neteler  wrote:

> On Tue, Oct 13, 2015 at 1:07 PM, Moritz Lennert
>  wrote:
> > The -n flag comes from r.proj and is explained as such in the r.proj man
> > page:
>
> Right.
>
> > "When reprojecting whole-world maps the user should disable map-trimming
> > with the -n flag. Trimming is not useful here because the module has the
> > whole map in memory anyway.
>
> ^^^ already here I am lost :-) Trimming is doing what (also compared to
> -l)?
>
> > Besides that, world "edges" are hard (or
> > impossible) to find in projections other than latitude-longitude so
> results
> > may be odd with trimming."
>
> All quite complicated and contradicting a bit the purpose of r.import.
> Can the usage of -n be made automated for r.import and not exposed to
> the user?
>

It can be there by default, but maybe it could be harmful in certain cases?

> (in case I suggest to hide -n for now for the 7.0.2 release, it can be
> introduced later if not avoidable).
>

It is sort of hidden in the Optional tab, I am not sure if we gain much by
hiding it completely.


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

Re: [GRASS-dev] Using a dynamic text in module header for parser

[Michel Wortmann]

Sorry, I thought I had tested it with some changes I made afterwards, 
this end part works better:


startcmd = 'python '+s.name
# set env variable
tmpdir = os.path.dirname(s.name)
os.environ['GRASS_ADDON_PATH']=tmpdir
# set permissions
os.chmod(s.name, os.stat(s.name).st_mode | stat.S_IEXEC)
# start module
os.system(startcmd)
os.remove(s.name)

On 10/12/2015 12:55 PM, Blumentrath, Stefan wrote:


Hi again,

Now I found out that the parser section in the inner python script was 
not formated properly.


However, when I now call the inner script with ‘--ui’ I get an error:

Unable to fetch interface description for command ‘tmpjksdfjiol’

Details:

Try to set up GRASS_ADDON_PATH or GRASS_ADDON_BASE variable.

It was neither possible to run the script using grass.run_command() 
(on Windows).


Cheers

Stefan

*From:*grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] *On Behalf 
Of *Blumentrath, Stefan

*Sent:* 12. oktober 2015 11:36
*To:* GRASS developers list (grass-dev@lists.osgeo.org) 


*Subject:* [GRASS-dev] Using a dynamic text in module header for parser

Hi,

I would like to fill:

#% options:

and

#% answer

in a parser option for a python script dynamically.  In particular I 
want to have tickboxes for available mapsets in the module GUI…


Meaning something like this  (but less complex / not interactive):

http://permalink.gmane.org/gmane.comp.gis.grass.gui/667

My amateur programming skills do unfortunately not allow me to really 
understand how to accomplish what Glynn describes in the post above…


I tried to generate and run a temporary python script from within my 
script like this:


def main():

answer = grass.mapsets(search_path = True)

available_mapsets = str(grass.mapsets())

with tempfile.NamedTemporaryFile(delete = False) as s:

s.write(''' #!/usr/bin/env python

# -*- coding: utf-8 -*-

# Here comes the full module with header for the parser

#% options: ''' + str(','.join(available_mapsets))

…

’’’)

startcmd = 'python ' + s.name

os.system(startcmd)

os.remove(s.name)

But that way the GUI never starts, when I call the outer script from 
GRASS and it seems that option never get parsed…


Any hints how to proceed?

Thanks for helping 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] r.in.lidar: height above ground

[Newcomb, Doug]

Thanks!  Will try it out!

Doug

On Sun, Oct 11, 2015 at 12:55 AM, Vaclav Petras 
wrote:

> Hi all,
>
> On Tue, Sep 8, 2015 at 11:54 PM, Vaclav Petras 
> wrote:
>
>> With the resolution option one case change the resolution of the output
>> while using computational region to set extent and resolution of the base
>> raster. However, after discussion with Doug, I see that it makes more sense
>> to match the output to the region, which can be nicely set beforehand to
>> align with some other raster. If this resolution would low (coarse) - we do
>> binning - it makes sense to use the input base raster at higher (finer)
>> resolution, the original resolution of the data is a clear choice. I'm not
>> sure if this should be the default but probably not, since it would violate
>> the region behavior.
>>
>> As a result, r.in.lidar output would respect region, optionally modified
>> by resolution (current behavior) and the input would use the region as
>> well, unless a flag would be set. This flag would be something like -d "Use
>> the resolution of the input base raster when reading it instead of using
>> current region (cells aligned to the raster)".
>>
>
>
> I've added the flag to use base raster resolution instead of the
> computation region resolution in r66468 to trunk. It is not by default
> since the region should be respected by default (and that has its own use
> cases). I've used -d for flag, since I had no better idea (r, a, b are used
> in often used other contexts).
>
> There is no documentation yet, but there is a test on artificial data
> which looks good. I was testing this on real data, but I was able to see
> some bigger differences only with ratio of raster and region resolution
> about 1/30, so I was not able to check the result in detail in this case.
> More testing is appreciated.
>
> The implementation should handle the the cases when region extent and
> raster extent are different in some better way, but for cases when region
> is the same or little bit smaller than the base raster, it will work fine.
>
> Vaclav
>
> https://trac.osgeo.org/grass/changeset/66468
>
>
> ___
> 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

Re: [GRASS-dev] [GRASS GIS] #2757: r.import: ERROR: Input raster map is outside current region

[Markus Neteler]

On Tue, Oct 13, 2015 at 1:07 PM, Moritz Lennert
 wrote:
> The -n flag comes from r.proj and is explained as such in the r.proj man
> page:

Right.

> "When reprojecting whole-world maps the user should disable map-trimming
> with the -n flag. Trimming is not useful here because the module has the
> whole map in memory anyway.

^^^ already here I am lost :-) Trimming is doing what (also compared to -l)?

> Besides that, world "edges" are hard (or
> impossible) to find in projections other than latitude-longitude so results
> may be odd with trimming."

All quite complicated and contradicting a bit the purpose of r.import.
Can the usage of -n be made automated for r.import and not exposed to
the user?
(in case I suggest to hide -n for now for the 7.0.2 release, it can be
introduced later if not avoidable).

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

Re: [GRASS-dev] [GRASS GIS] #2757: r.import: ERROR: Input raster map is outside current region

[Paulo van Breugel]

On 13-10-15 15:37, Anna Petrášová wrote:



On Tue, Oct 13, 2015 at 9:03 AM, Markus Neteler > wrote:


On Tue, Oct 13, 2015 at 1:07 PM, Moritz Lennert
> wrote:
> The -n flag comes from r.proj and is explained as such in the
r.proj man
> page:

Right.

> "When reprojecting whole-world maps the user should disable
map-trimming
> with the -n flag. Trimming is not useful here because the module
has the
> whole map in memory anyway.

^^^ already here I am lost :-) Trimming is doing what (also
compared to -l)?



I was asking myself the same some time ago. Perhaps this option does not 
need to be hidden, but it would be good to have a positive definition of 
what trimming means (also in the manual page of r.proj)? I would be 
inclined to think that if even Markus does not know what this means, 
many users won't know either ;-)




> Besides that, world "edges" are hard (or
> impossible) to find in projections other than latitude-longitude
so results
> may be odd with trimming."

All quite complicated and contradicting a bit the purpose of r.import.
Can the usage of -n be made automated for r.import and not exposed to
the user?


It can be there by default, but maybe it could be harmful in certain 
cases?


(in case I suggest to hide -n for now for the 7.0.2 release, it can be
introduced later if not avoidable).


It is sort of hidden in the Optional tab, I am not sure if we gain 
much by hiding it completely.



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 mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2757: r.import: ERROR: Input raster map is outside current region

[Moritz Lennert]

On 13/10/15 15:58, Markus Neteler wrote:

On Tue, Oct 13, 2015 at 3:37 PM, Anna Petrášová  wrote:

On Tue, Oct 13, 2015 at 9:03 AM, Markus Neteler  wrote:

It is sort of hidden in the Optional tab, I am not sure if we gain much by
hiding it completely.


As mentioned, I don't even understand the meaning of -n in r.proj. If
anyone knows, please rephrase it in r.proj's manual.


In r.proj, -n provokes a call to bordwalk(), which is described in the 
code (bordwalk.c) as doing the following:


 * bordwalk.c - projects the border cell centers of a map or region
 * to check whether they are inside the borders of another map/region
 * in a different location, and adjusts the cell header so
 * only overlapping areas are included. The function is called by main,
 * first to project the output region into the input map and trim the
 * borders of this in order to get a smaller map, and faster and less 
hungry

 * memory allocation. Then main calls the function again, but reversed,
 * to project the input map on the output region, trimming this down to
 * the smallest possible rectangular region.

So, IIUC, this means that -n already crops the input map in the input 
location before reprojection, instead of only writing those parts of the 
output map that fall into the current region. This makes reprojection 
faster if the target region is only a subset of the input map (again AFAIU).


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

Re: [GRASS-dev] Error reading raster data for row xxx (only when using r.series and t.rast.series)

[Dylan Beaudette]

One more piece of data:

This error only occurs when using "method=sum". I have not encountered
this error when using any of the other methods available to r.series
or t.rast.series.

Dylan

On Tue, Oct 13, 2015 at 10:00 AM, Dylan Beaudette
 wrote:
> Hi Markus,
>
> GRASS version information:
>
>  ./configure  --without-odbc --without-mysql --with-readline
> --with-cxx --enable-largefile --with-freetype
> --with-freetype-includes=/usr/include/freetype2 --with-sqlite
> --with-python --with-pthread --with-geos=/usr/local/bin/geos-config
> --without-opencl --with-opencl-includes=/usr/include/CL/
> --with-postgres --with-postgres-includes=/usr/include/postgresql/
> --with-postgres-libs=/usr/lib/
> --with-proj-share=/usr/local/share/proj/
>
> libgis Revision: 64732
> libgis Date: 2015-02-24 16:54:05 -0800 (Tue, 24 Feb 2015)
>
> PROJ.4: 4.8.0
> GDAL/OGR: 2.0.0
> GEOS: 3.4.2
> SQLite: 3.7.9
>
> I find it strange that I have encountered this mysterious error
> (occasionally) over the last couple of years while tracking
> grass_trunk.
>
> One other piece of data; I have never encountered this error with any
> other GRASS modules... just r.series and t.rast.series.
>
> Thanks,
> Dylan
>
>
>
> On Tue, Oct 13, 2015 at 3:09 AM, Markus Neteler  wrote:
>> Hi Dylan,
>>
>> please post to the list which GRASS GIS version you are using
>> (g.version or wxGUI HELP) and the OS.
>>
>> Best
>> Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Error reading raster data for row xxx (only when using r.series and t.rast.series)

[Dylan Beaudette]

Hi Markus,

GRASS version information:

 ./configure  --without-odbc --without-mysql --with-readline
--with-cxx --enable-largefile --with-freetype
--with-freetype-includes=/usr/include/freetype2 --with-sqlite
--with-python --with-pthread --with-geos=/usr/local/bin/geos-config
--without-opencl --with-opencl-includes=/usr/include/CL/
--with-postgres --with-postgres-includes=/usr/include/postgresql/
--with-postgres-libs=/usr/lib/
--with-proj-share=/usr/local/share/proj/

libgis Revision: 64732
libgis Date: 2015-02-24 16:54:05 -0800 (Tue, 24 Feb 2015)

PROJ.4: 4.8.0
GDAL/OGR: 2.0.0
GEOS: 3.4.2
SQLite: 3.7.9

I find it strange that I have encountered this mysterious error
(occasionally) over the last couple of years while tracking
grass_trunk.

One other piece of data; I have never encountered this error with any
other GRASS modules... just r.series and t.rast.series.

Thanks,
Dylan



On Tue, Oct 13, 2015 at 3:09 AM, Markus Neteler  wrote:
> Hi Dylan,
>
> please post to the list which GRASS GIS version you are using
> (g.version or wxGUI HELP) and the OS.
>
> Best
> Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Error reading raster data for row xxx (only when using r.series and t.rast.series)

[Dylan Beaudette]

On Tue, Oct 13, 2015 at 11:55 AM, Markus Neteler  wrote:
> On Tue, Oct 13, 2015 at 8:43 PM, Dylan Beaudette
>  wrote:
>> Dangit... This is strange, just did an 'svn up', make distclean, make,
>> make install, and now this:
>>
>> Welcome to GRASS GIS 7.1.svn (r66487)
>> GRASS GIS homepage:  http://grass.osgeo.org
>> This version running through:Bash Shell (/bin/bash)
>> Help is available with the command:  g.manual -i
>> See the licence terms with:  g.version -c
>> Start the GUI with:  g.gui wxpython
>> When ready to quit enter:exit
>>
>> GRASS 7.1.svn (prism):~/src/grass_trunk > g.version -r
>> GRASS 7.1.svn (2015)
>> libgis Revision: 64732
>> libgis Date: 2015-02-24 16:54:05 -0800 (Tue, 24 Feb 2015)
>>
>> Has it been so long since I have compiled GRASS that I have missed
>> something?
>
> Yep:
> https://trac.osgeo.org/grass/changeset/65591
> "Prevent concurrent raster reads when a mask is present"
>
> (which also got backported subsequently)
>
>> I see that the libgis is still "old".
>
> ... this is unrelated since the issue was in r.mapcalc (hence
> affecting all modules using it).
>
> The true revision number of interest is the one next to GRASS GIS
> 7.1.svn (r66487).
>
> I guess your issue is now solved.
>
> Markus

Maybe. I updated my local copy of grass_trunk last Monday, compiled,
and experienced the issues with r.series and t.rast.series... in the
absence of a MASK map.

Are the *.series modules a convenient front-end to r.mapcalc?

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

[GRASS-dev] [GRASS GIS] #2759: v.rast.stats and mySQL

[GRASS GIS]

#2759: v.rast.stats and mySQL
+-
 Reporter:  fpouw   |  Owner:  grass-dev@…
 Type:  defect  | Status:  new
 Priority:  normal  |  Milestone:
Component:  Default |Version:  7.0.1
 Keywords:  v.rast.stats mysql  |CPU:  x86-64
 Platform:  Linux   |
+-
 v.rast.stats fails to run when using a mysql database because it attempts
 to execute a BEGIN TRANSACTION command.
 This syntax is not supported by mysql which uses the syntax: START
 TRANSACTION.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Error reading raster data for row xxx (only when using r.series and t.rast.series)

[Sören Gebbert]

Hi Dylan,
r.series is a module implemented in C with no relations to r.mapcalc.
t.rast.series is a Python module that makes use of r.series internally.

Best regards
Soeren

2015-10-13 21:06 GMT+02:00 Dylan Beaudette :
> On Tue, Oct 13, 2015 at 11:55 AM, Markus Neteler  wrote:
>> On Tue, Oct 13, 2015 at 8:43 PM, Dylan Beaudette
>>  wrote:
>>> Dangit... This is strange, just did an 'svn up', make distclean, make,
>>> make install, and now this:
>>>
>>> Welcome to GRASS GIS 7.1.svn (r66487)
>>> GRASS GIS homepage:  http://grass.osgeo.org
>>> This version running through:Bash Shell (/bin/bash)
>>> Help is available with the command:  g.manual -i
>>> See the licence terms with:  g.version -c
>>> Start the GUI with:  g.gui wxpython
>>> When ready to quit enter:exit
>>>
>>> GRASS 7.1.svn (prism):~/src/grass_trunk > g.version -r
>>> GRASS 7.1.svn (2015)
>>> libgis Revision: 64732
>>> libgis Date: 2015-02-24 16:54:05 -0800 (Tue, 24 Feb 2015)
>>>
>>> Has it been so long since I have compiled GRASS that I have missed
>>> something?
>>
>> Yep:
>> https://trac.osgeo.org/grass/changeset/65591
>> "Prevent concurrent raster reads when a mask is present"
>>
>> (which also got backported subsequently)
>>
>>> I see that the libgis is still "old".
>>
>> ... this is unrelated since the issue was in r.mapcalc (hence
>> affecting all modules using it).
>>
>> The true revision number of interest is the one next to GRASS GIS
>> 7.1.svn (r66487).
>>
>> I guess your issue is now solved.
>>
>> Markus
>
> Maybe. I updated my local copy of grass_trunk last Monday, compiled,
> and experienced the issues with r.series and t.rast.series... in the
> absence of a MASK map.
>
> Are the *.series modules a convenient front-end to r.mapcalc?
>
> Thanks!
> Dylan
> ___
> 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] Error reading raster data for row xxx (only when using r.series and t.rast.series)

[Markus Neteler]

On Tue, Oct 13, 2015 at 8:59 PM, Dylan Beaudette
 wrote:
...
>>> libgis Revision: 64732

Ah, I read on mobile, not realizing that this was the libgis rev number.

...
> How does the "libgis" revision number relate to the version reported
> when starting GRASS (e.g. SVN revision)?

Not at all...

ok I find this libgis rev number continuously confusing and useless as
already posted some years ago.
In the end only the starting-GRASS-SVN-revision gives me true information.

@devs: I suggest to less prominently advertise the lib*gis* rev number
in g.version.

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

Re: [GRASS-dev] Error reading raster data for row xxx (only when using r.series and t.rast.series)

[Dylan Beaudette]

Dangit... This is strange, just did an 'svn up', make distclean, make,
make install, and now this:

Welcome to GRASS GIS 7.1.svn (r66487)
GRASS GIS homepage:  http://grass.osgeo.org
This version running through:Bash Shell (/bin/bash)
Help is available with the command:  g.manual -i
See the licence terms with:  g.version -c
Start the GUI with:  g.gui wxpython
When ready to quit enter:exit

GRASS 7.1.svn (prism):~/src/grass_trunk > g.version -r
GRASS 7.1.svn (2015)
libgis Revision: 64732
libgis Date: 2015-02-24 16:54:05 -0800 (Tue, 24 Feb 2015)

Has it been so long since I have compiled GRASS that I have missed
something? I see that the libgis is still "old".

?

Dylan






On Tue, Oct 13, 2015 at 11:06 AM, Markus Neteler  wrote:
>
> On Oct 13, 2015 7:01 PM, "Dylan Beaudette" 
> wrote:
>>
>> Hi Markus,
>>
>> GRASS version information:
>>
>>  ./configure  --without-odbc --without-mysql --with-readline
>> --with-cxx --enable-largefile --with-freetype
>> --with-freetype-includes=/usr/include/freetype2 --with-sqlite
>> --with-python --with-pthread
>
> I would not use pthread.
>
>> --with-geos=/usr/local/bin/geos-config
>> --without-opencl --with-opencl-includes=/usr/include/CL/
>> --with-postgres --with-postgres-includes=/usr/include/postgresql/
>> --with-postgres-libs=/usr/lib/
>> --with-proj-share=/usr/local/share/proj/
>>
>> libgis Revision: 64732
>
> This is fairly old. Trunk is r66487.
>
> Can you update?
>
>> libgis Date: 2015-02-24 16:54:05 -0800 (Tue, 24 Feb 2015)
>>
>> PROJ.4: 4.8.0
>> GDAL/OGR: 2.0.0
>> GEOS: 3.4.2
>> SQLite: 3.7.9
>
> Best
> Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Error reading raster data for row xxx (only when using r.series and t.rast.series)

[Dylan Beaudette]

Hi Moritz,

Not using a MASK in this case. Fairly basic work-flow, using "tmin"
and "tmax" (Space Time Raster Dataset) loaded via r.external.


# make a where clause for finding the current year
  wc="strftime('%Y', start_time) = '"$year"'"

  # extract current dataset: "copies" by reference
  t.rast.extract --q --o input=tmin output=tmin_subset
basename=tmin_subset where="$wc"
  t.rast.extract --q --o input=tmax output=tmax_subset
basename=tmax_subset where="$wc"

  # GDD for current year: slow from external rasters
  # NOTE: 2 CPUs so that disk isn't thrashed
  t.rast.mapcalc --o nprocs=2 method=equal
input=tmin_subset,tmax_subset output=gdd basename=gdd expr="(((
min((tmax_subset * 1.8 + 32.0), 86.0) + max((tmin_subset * 1.8 +
32.0), 50) ) / 2) - 50)"


... the error occurs at this step in a non-deterministic pattern.
Strangely enough, the errors are more frequent during the morning
hours vs. afternoon hours!

  # sum GDD for this year: fast from SSD, but only single CPU thread
  t.rast.series --o --q in=gdd out=gdd_$year method=sum


Thanks,
Dylan



On Tue, Oct 13, 2015 at 1:04 AM, Moritz Lennert
 wrote:
> On 12/10/15 23:35, Dylan Beaudette wrote:
>>
>> Hi,
>>
>> Over the last couple of years I have noticed a very strange raster
>> corruption (?) issues when using r.series, and now more recently,
>> t.rast.series. Typically, I'll generate a large number of maps with
>> r.sun or t.rast.mapcalc and then aggregate the series with r.series or
>> t.rast.series. About 50% of the time the command runs as expected, the
>> other half of the time r.series or t.rast.series gives me an error
>> like this:
>>
>> Error reading raster data for row xxx (testmap)
>>
>> After this error, I can no longer perform any kind of operation on map
>> "testmap" without the dreaded Error reading raster data for row xxx...
>>
>> The situation was worse when using a MASK map, possibly related to a
>> similar (fixed?) issue discussed in this thread:
>>
>> http://lists.osgeo.org/pipermail/grass-dev/2015-July/075627.html
>>
>> Within that thread, Glynn mentioned that this type of error was
>> probably related to pthreads and concurrent processes. The temporary
>> fix entailed:
>>
>> export WORKERS=0
>>
>> I have tried this on my machine but the results are the same,
>> non-deterministic corruption (?) of one input to r.series or
>> t.rast.series.
>>
>> I have encountered this error on several disks, mirrored HDDs, single
>> HDD, and now on an SSD. I don't think that this is a disk problem,
>> rather, something that r.series or t.rast.series is "doing" to the
>> files it operates on.
>>
>> Is there some possibility that one of these commands is leaving a file
>> "open" or in some kind of intermediate state that prevents subsequent
>> commands from accessing the file?
>>
>> I'll try to create a sample dataset to send over. In the meantime is
>> there any kind of diagnostic information that I can report back with?
>
>
> Are you using a mask, as was the case in the thread you cite ?
>
> Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Error reading raster data for row xxx (only when using r.series and t.rast.series)

[Markus Neteler]

On Oct 13, 2015 7:01 PM, "Dylan Beaudette" 
wrote:
>
> Hi Markus,
>
> GRASS version information:
>
>  ./configure  --without-odbc --without-mysql --with-readline
> --with-cxx --enable-largefile --with-freetype
> --with-freetype-includes=/usr/include/freetype2 --with-sqlite
> --with-python --with-pthread

I would not use pthread.

> --with-geos=/usr/local/bin/geos-config
> --without-opencl --with-opencl-includes=/usr/include/CL/
> --with-postgres --with-postgres-includes=/usr/include/postgresql/
> --with-postgres-libs=/usr/lib/
> --with-proj-share=/usr/local/share/proj/
>
> libgis Revision: 64732

This is fairly old. Trunk is r66487.

Can you update?

> libgis Date: 2015-02-24 16:54:05 -0800 (Tue, 24 Feb 2015)
>
> PROJ.4: 4.8.0
> GDAL/OGR: 2.0.0
> GEOS: 3.4.2
> SQLite: 3.7.9

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

Re: [GRASS-dev] [GRASS GIS] #2750: LZ4 when writing raster rows; better than double I/O bound r.mapcalc speed

[GRASS GIS]

#2750: LZ4 when writing raster rows; better than double I/O bound r.mapcalc 
speed
--+---
  Reporter:  sprice   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.1.0
 Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  ZLIB LZ4 ZSTD
   CPU:  OSX/Intel|   Platform:  MacOSX
--+---

Comment (by sprice):

 I considered writing a more general function for compression but I held
 off for two reasons:

 1) There seems to be a lot of very specific code depending on exactly what
 you're doing. For example, for read_data_fp_compressed() there was
 functionality hidden in G_zlib_read to save a header for each compressed
 row. Or the use of G_ZLIB_COMPRESSED_NO ('0') as a flag for FP
 compression, vs various integers defining CELL compression. To keep
 backwards compatibility, I delt with the different formats (CELL vs NULL
 vs FCELL/DCELL) on a case-by-case basis.

 2) I'm not familiar with the best practices for the code in GRASS GIS. I'd
 encourage someone else to create new files (or libraries) as required. I
 can help as required, but I'm concerned that as each edge case is
 considered (as mentioned above) there won't be all that much common code
 between the various compression uses.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Error reading raster data for row xxx (only when using r.series and t.rast.series)

[Dylan Beaudette]

On Tue, Oct 13, 2015 at 11:06 AM, Markus Neteler  wrote:
>
> On Oct 13, 2015 7:01 PM, "Dylan Beaudette" 
> wrote:
>>
>> Hi Markus,
>>
>> GRASS version information:
>>
>>  ./configure  --without-odbc --without-mysql --with-readline
>> --with-cxx --enable-largefile --with-freetype
>> --with-freetype-includes=/usr/include/freetype2 --with-sqlite
>> --with-python --with-pthread
>
> I would not use pthread.

OK, good to know. I will re-compile without it and report back.

>> --with-geos=/usr/local/bin/geos-config
>> --without-opencl --with-opencl-includes=/usr/include/CL/
>> --with-postgres --with-postgres-includes=/usr/include/postgresql/
>> --with-postgres-libs=/usr/lib/
>> --with-proj-share=/usr/local/share/proj/
>>
>> libgis Revision: 64732
>
> This is fairly old. Trunk is r66487.
>
> Can you update?

How does the "libgis" revision number relate to the version reported
when starting GRASS (e.g. SVN revision)?


>> libgis Date: 2015-02-24 16:54:05 -0800 (Tue, 24 Feb 2015)
>>
>> PROJ.4: 4.8.0
>> GDAL/OGR: 2.0.0
>> GEOS: 3.4.2
>> SQLite: 3.7.9
>
> Best
> Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Error reading raster data for row xxx (only when using r.series and t.rast.series)

[Markus Neteler]

On Tue, Oct 13, 2015 at 8:43 PM, Dylan Beaudette
 wrote:
> Dangit... This is strange, just did an 'svn up', make distclean, make,
> make install, and now this:
>
> Welcome to GRASS GIS 7.1.svn (r66487)
> GRASS GIS homepage:  http://grass.osgeo.org
> This version running through:Bash Shell (/bin/bash)
> Help is available with the command:  g.manual -i
> See the licence terms with:  g.version -c
> Start the GUI with:  g.gui wxpython
> When ready to quit enter:exit
>
> GRASS 7.1.svn (prism):~/src/grass_trunk > g.version -r
> GRASS 7.1.svn (2015)
> libgis Revision: 64732
> libgis Date: 2015-02-24 16:54:05 -0800 (Tue, 24 Feb 2015)
>
> Has it been so long since I have compiled GRASS that I have missed
> something?

Yep:
https://trac.osgeo.org/grass/changeset/65591
"Prevent concurrent raster reads when a mask is present"

(which also got backported subsequently)

> I see that the libgis is still "old".

... this is unrelated since the issue was in r.mapcalc (hence
affecting all modules using it).

The true revision number of interest is the one next to GRASS GIS
7.1.svn (r66487).

I guess your issue is now solved.

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

[GRASS-dev] odd behavior from t.register when loading from file and no "end date" is specified

[Dylan Beaudette]

Hi,

I recently notices something when working with t.register and a large
collection of daily files. My typical work-flow is something like
this:

# make some data
r.mapcalc expression="prec_1 = 100"
r.mapcalc expression="prec_2 = 200"
r.mapcalc expression="prec_3 = 300"
r.mapcalc expression="prec_4 = 400"
r.mapcalc expression="prec_5 = 500"
r.mapcalc expression="prec_6 = 600"

# create a new space-time data set
t.create --o type=strds temporaltype=absolute \
output=precip_abs title="Example" \
descr="Example"

# generate a file describing the raster names and start dates
echo "prec_1|1981-01-01|
prec_2|1981-01-02|
prec_3|1981-01-03|
prec_4|1981-01-04|
prec_5|1981-01-05|
prec_6|1981-01-06|" > precip_abs.files


... In many cases the list of raster and dates is generated by parsing
raster names, like this:

g.list type=rast pattern="file_*" | \
awk -F '_' '{print
$1"_"$2"|"substr($2,1,4)"-"substr($2,5,2)"-"substr($2,7,2)}' >
somefile

... this is really handy when you have a lot of files (>10k), but
cannot generate both "start" and "stop" dates for the t.register input
file.

OK, well (unless I am mistaken) t.register should be able to figure
this out when invoked with the "-i" flag:

# register maps from file, filling-in stop dates
t.register --o -i input=precip_abs file=precip_abs.files type=raster
increment="1 day"

... however, this results in the following:

# double-check start | stop dates:
t.rast.list precip_abs

name|mapset|start_time|end_time
prec_1|PERMANENT|1981-01-02 00:00:00|1981-01-03 00:00:00
prec_2|PERMANENT|1981-01-03 00:00:00|1981-01-04 00:00:00
prec_3|PERMANENT|1981-01-04 00:00:00|1981-01-05 00:00:00
prec_4|PERMANENT|1981-01-05 00:00:00|1981-01-06 00:00:00
prec_5|PERMANENT|1981-01-06 00:00:00|1981-01-07 00:00:00
prec_6|PERMANENT|1981-01-07 00:00:00|1981-01-08 00:00:00

... these maps are offset by 1 day into the future.

Is this the intended result?

I am able to get my expected result if I fully specify the start and
stop dates in the t.register input file. This get a little tricky, but
(insert your favorite scripting language) can make the process of
adding 1 day to each line simple.


This is with grass_trunk as of:

Last Changed Rev: 66487
Last Changed Date: 2015-10-13 02:54:55 -0700 (Tue, 13 Oct 2015)


Am I abusing t.register or otherwise misinterpreting the manual pages?

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

Re: [GRASS-dev] [GRASS GIS] #2750: LZ4 when writing raster rows; better than double I/O bound r.mapcalc speed

[GRASS GIS]

#2750: LZ4 when writing raster rows; better than double I/O bound r.mapcalc 
speed
--+---
  Reporter:  sprice   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.1.0
 Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  ZLIB LZ4 ZSTD
   CPU:  OSX/Intel|   Platform:  MacOSX
--+---

Comment (by wenzeslaus):

 Replying to [comment:15 sprice]:
 > I considered writing a more general function for compression but I held
 off for two reasons:
 >
 > 1) There seems to be a lot of very specific code depending on exactly
 what you're doing.

 My point is to put these specific cases into one function. So for example,
 whatever in the comment:13, should be in one function. What I suggest
 should be simple to moving of the existing code unless I miss some
 important part.

 > For example, for read_data_fp_compressed() there was functionality
 hidden in G_zlib_read to save a header for each compressed row.

 Here I perhaps hit my limited understanding of the code in question. What
 is doing this job now? Or it is not needed?

 > Or the use of G_ZLIB_COMPRESSED_NO ('0') as a flag for FP compression,
 vs various integers defining CELL compression.

 This is the kind of things which I would like to have hidden in one place.
 (In this way, we can keep the strange things at one place and e.g. easily
 replace, literals by defines (which we should do anyway, BTW).

 > To keep backwards compatibility, I delt with the different formats (CELL
 vs NULL vs FCELL/DCELL) on a case-by-case basis.

 You mean e.g. `read_data_compressed()` versus `read_data_fp_compressed()`?
 I had no time to actually try to identify all the differences, but the
 idea would be that these functions should deal with the differences among
 CELL, NULL and FCELL/DCELL while the proposed "`G_compresslib_write()`"
 function would deal with the differences between compression formats.

 > I'm concerned that as each edge case is considered (as mentioned above)
 there won't be all that much common code between the various compression
 uses.

 Another way to look at it is to think about, what do I have to replicate
 in 3D raster library where only `G_zlib_*` is used now. The things I need
 to replicate to enable other compressions should be in the
 "`G_compresslib_*()`" functions.

 I won't be able to give it attention it deserves in the following weeks,
 so please don't expect any actual code from me now. But feel free to
 oppose me or try it yourself in the mean time.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Error reading raster data for row xxx (only when using r.series and t.rast.series)

[Dylan Beaudette]

On Tue, Oct 13, 2015 at 11:06 AM, Markus Neteler  wrote:
>
> On Oct 13, 2015 7:01 PM, "Dylan Beaudette" 
> wrote:
>>
>> Hi Markus,
>>
>> GRASS version information:
>>
>>  ./configure  --without-odbc --without-mysql --with-readline
>> --with-cxx --enable-largefile --with-freetype
>> --with-freetype-includes=/usr/include/freetype2 --with-sqlite
>> --with-python --with-pthread
>
> I would not use pthread.
>

Hi Markus,

I have done some tests after re-compiling _without_ pthreads. So far,
no errors from r.series. Also I seem to be getting better performance
form r.mapcalc and t.rast.series, especially when working with files
loaded via r.external. I don't know enough about pthreads to speculate
further. Any ideas?

I'll report back when the script finishes, probably 20 hours or so.

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

Re: [GRASS-dev] Error reading raster data for row xxx (only when using r.series and t.rast.series)

[Dylan Beaudette]

Thank you for the clarification Sören.

Any ideas on how r.series could be leaving maps open or otherwise
corrupting inputs in those cases where:

1. there are a lot of maps (>100)
2. method=sum

Dylan

On Tue, Oct 13, 2015 at 12:11 PM, Sören Gebbert
 wrote:
> Hi Dylan,
> r.series is a module implemented in C with no relations to r.mapcalc.
> t.rast.series is a Python module that makes use of r.series internally.
>
> Best regards
> Soeren
>
> 2015-10-13 21:06 GMT+02:00 Dylan Beaudette :
>> On Tue, Oct 13, 2015 at 11:55 AM, Markus Neteler  wrote:
>>> On Tue, Oct 13, 2015 at 8:43 PM, Dylan Beaudette
>>>  wrote:
 Dangit... This is strange, just did an 'svn up', make distclean, make,
 make install, and now this:

 Welcome to GRASS GIS 7.1.svn (r66487)
 GRASS GIS homepage:  http://grass.osgeo.org
 This version running through:Bash Shell (/bin/bash)
 Help is available with the command:  g.manual -i
 See the licence terms with:  g.version -c
 Start the GUI with:  g.gui wxpython
 When ready to quit enter:exit

 GRASS 7.1.svn (prism):~/src/grass_trunk > g.version -r
 GRASS 7.1.svn (2015)
 libgis Revision: 64732
 libgis Date: 2015-02-24 16:54:05 -0800 (Tue, 24 Feb 2015)

 Has it been so long since I have compiled GRASS that I have missed
 something?
>>>
>>> Yep:
>>> https://trac.osgeo.org/grass/changeset/65591
>>> "Prevent concurrent raster reads when a mask is present"
>>>
>>> (which also got backported subsequently)
>>>
 I see that the libgis is still "old".
>>>
>>> ... this is unrelated since the issue was in r.mapcalc (hence
>>> affecting all modules using it).
>>>
>>> The true revision number of interest is the one next to GRASS GIS
>>> 7.1.svn (r66487).
>>>
>>> I guess your issue is now solved.
>>>
>>> Markus
>>
>> Maybe. I updated my local copy of grass_trunk last Monday, compiled,
>> and experienced the issues with r.series and t.rast.series... in the
>> absence of a MASK map.
>>
>> Are the *.series modules a convenient front-end to r.mapcalc?
>>
>> Thanks!
>> Dylan
>> ___
>> 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 will not not find laslib

[Michael Barton]

So far I've failed to compile boost with dual architectures. Below, I include 
an exchange with dev from the GeoDA lab here. It is not encouraging. So my 
options are to try dual architecture with an old version of boost if it is 
available in the archives, or try to figure out how to fix GRASS configure so 
it recognizes the library.

Michael


From: Xun Li >
Subject: Re: C++ compiling help
Date: October 13, 2015 at 3:36:33 PM MST
To: Michael Barton >

Hi Michael,

I just tried the options on my side and it seems not working. See a discussion 
here; 
http://stackoverflow.com/questions/19897761/how-to-make-boost-dylibs-universal-i386-x86-64-on-os-x

Xun


Xun Li, Ph.D

Research Scientist
GeoDa Center for Geospatial Analysis and Computation
School of Geographical Sciences and Urban Planning
Arizona State University
http://www.public.asu.edu/~xunli/cv.html

On Fri, Oct 9, 2015 at 3:51 PM, Michael Barton 
> wrote:
Can you give me an example? Here are the various compile commands I’ve used:

./bjam variant=release link=static --without-mpi -j4 macosx-version=10.7 
macosx-version-min=10.7 architecture=x86 address-model=64 install

## my version
./b2 variant=release link=static --without-mpi -j4 macosx-version=10.7 
macosx-version-min=10.7 cxxflags="-arch x86_64"

## from Xun Li
./b2 --with-thread --with-date_time --with-chrono --with-system link=static 
threading=multi toolset=darwin cxxflags="-arch x86_64" stage

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 
480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 
(CSDC)
www: http://www.public.asu.edu/~cmbarton, 
http://csdc.asu.edu


C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu















On Oct 8, 2015, at 6:33 PM, Michael Barton 
> wrote:

The first thing is to compile boost with 2 architectures. That might solve the 
whole thing

Michael Barton
School of Human Evolution  Change
Center for Social Dynamics & Complexity
Arizona State University

...Sent from my iPad

On Oct 8, 2015, at 5:14 PM, Anna Petrášová 
> wrote:



On Thu, Oct 8, 2015 at 8:02 PM, Michael Barton 
> wrote:
Nope.

It starts to launch and gets to the start up screen, but has this error:

Starting GRASS GIS...
Unable to import pyGRASS: 
dlopen(/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.1.dylib,
 10): no suitable image found.  Did find:
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.1.dylib:
 mach-o, but wrong architecture
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.1.dylib:
 mach-o, but wrong architecture
Some functionality will be not accessible


When I select a location/mapset and start GRASS, it bombs with the same error I 
reported the other day for the student with El Capitan:

GRASS 7.0.1 (Spain_fieldwork_medlands_ERTS89_Z30):~ > Unable to import pyGRASS: 
dlopen(/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.1.dylib,
 10): no suitable image found.  Did find:
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.1.dylib:
 mach-o, but wrong architecture
/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/lib/libgrass_gis.7.0.1.dylib:
 mach-o, but wrong architecture
Some functionality will be not accessible
Traceback (most recent call last):
  File 
"/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/gui/wxpython/wxgui.py",
 line 37, in 
from lmgr.frame import GMFrame
  File 
"/Users/cmbarton/grass_source/release_20150730_grass_7_0_1/macosx/dist/GRASS-7.0.app/Contents/MacOS/gui/wxpython/lmgr/frame.py",
 line 50, in 
from lmgr.layertreeimport LayerTree, LMIcons
  File