Re: [GRASS-user] v vol rst super slow

[Sören Gebbert]

Hi,
your region settings are interesting.
Do you really need a resolution of 5m in x,y plane and 1m in z direction?
As a result you have 23,507,876,616 voxel to compute, but only 76887
points for interpolation.

I would suggest you reduce the resolution of your region
significantly, at least to test the interpolation settings.

Best regards
Soeren

2018-05-23 13:09 GMT+02:00 Francois Chartier :
> see below
> g.region -3p
>
> projection: 1 (UTM)
> zone:   17
> datum:  nad83
> ellipsoid:  grs80
> north:  4870795
> south:  4825715
> west:   609204
> east:   651669
> top:352.
> bottom: 45.
> nsres:  5
> nsres3: 5
> ewres:  5
> ewres3: 5
> tbres:  1
> rows:   9016
> rows3:  9016
> cols:   8493
> cols3:  8493
> depths: 307
> cells:  76572888
> cells3: 23507876616
>
> for v.vol.rst command line - i am not sure where you get this so i just
> restarted the simulation.
> Wed May 23 07:07:59 2018)
> v.vol.rst input=BHMat1All_May12@Toronto wcolumn=cat dmin=0.1
> 25 records selected from table
> Processing all selected output files will require 0 bytes of disk space for
> temp files
> WARNING: Points are more dense than specified 'DMIN'--ignored 65 points
> (remain 76822)
> WARNING: Unable to create <(null)> raster map without cross_input raster map
> being specified
>
>
>
> v.info
> (Wed May 23 07:06:24 2018)
> v.info map=BHMat1All_May12@Toronto
>
> ++
>  | Name:BHMat1All_May12
> |
>  | Mapset:  Toronto
> |
>  | Location:Toronto
> |
>  | Database:C:\Users\Francois Chartier\Documents\grassdata
> |
>  | Title:
> |
>  | Map scale:   1:1
> |
>  | Name of creator: Francois Chartier
> |
>  | Organization:
> |
>  | Source date: Sat May 12 15:45:44 2018
> |
>  | Timestamp (first layer): none
> |
>
> ||
>  | Map format:  native
> |
>
> ||
>  |   Type of map: vector (level: 2)
> |
>  |
> |
>  |   Number of points:   76887   Number of centroids:  0
> |
>  |   Number of lines:0   Number of boundaries: 0
> |
>  |   Number of areas:0   Number of islands:0
> |
>  |   Number of faces:0   Number of kernels:0
> |
>  |   Number of volumes:  0   Number of holes:  0
> |
>  |
> |
>  |   Map is 3D:  Yes
> |
>  |   Number of dblinks:  1
> |
>  |
> |
>  |   Projection: UTM (zone 17)
> |
>  |
> |
>  |   N:   4870795S:   4825715
> |
>  |   E:651669W:609204
> |
>  |   B:45T:   352
> |
>  |
> |
>  |   Digitization threshold: 0
> |
>  |   Comment:
> |
>  |
> |
>
> ++
> (Wed May 23 07:06:24 2018) Command finished (0 sec)
>
>
> 2018-05-23 6:07 GMT-04:00 Moritz Lennert :
>>
>> Hi François,
>>
>> Please keep all discussions on the list.
>>
>> On 23/05/18 02:26, Francois Chartier wrote:
>>>
>>> Hi Moritz,
>>>
>>> see below.  seems like i have 6M cells
>>>
>>> projection: 1 (UTM)
>>> zone:   17
>>> datum:  nad83
>>> ellipsoid:  grs80
>>> north:  4868980
>>> south:  4829680
>>> west:   609620
>>> east:   651628
>>> nsres:  5
>>> ewres:  4.99976196
>>> rows:   7860
>>> cols:   8402
>>> cells:  66039720
>>
>>
>>
>> Sorry, my fault: as you are interpolating in 3D we need the 3D region, so
>> the output of 'g.region -3p'.
>>
>> And could you also provide us with:
>>
>> - the exact v.vol.rst command line you used
>> - the output of v.info on your point dataset
>>
>> ?
>>
>> Moritz
>>
>>>
>>> 2018-05-22 7:58 GMT-04:00 Moritz Lennert >> >:
>>>
>>>
>>>
>>> Am 22. Mai 2018 04:35:13 MESZ schrieb Francois Chartier
>>> mailto:fra.chart...@gmail.com>>:
>>>  >Hi,
>>>  >
>>>  >I am interpolating 2D data using V Vol RST.  After 90 min the
>>> process
>>>  >progressed 15%, and I stopped it.
>>>  >There are approx 370 points, and it should not take this long.  I
>>> am
>>>  >not
>>>  >sure what I am doing incorrectly.  I have set the g.region to
>>> match the
>>>  >vector, and joined the vector attribute to the database.
>>>
>>> What is the resolution of the region ?
>>>
>>> Please provide the output of g.region -p.
>>>
>>> Moritz
>>>
>>>
>>
>>
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Strange behavour of t.register command

[Sören Gebbert]

Hi,
the second command is the correct one, since the "unit" option in the
first command should only be used in case of "relative" time in an
STRDS.

You have to make sure that the "time_dataset" was created with the
correct temporal type, which in your case is "absolute "time.

Best regards
Sören

2018-05-10 11:05 GMT+02:00 Roberto Marzocchi :
>
> Dear lists,
>
> we are testing the command t.register
>
> t.register --o --q -i maps=(name of maps separated by comma)
> input=time_dataset start='2011-11-03 02:00:00' increment='120'
> unit='minutes'
>
> it run without error but when running g.gui.animation or g.gui.tplot using
> the time series dataset I have the following error: Topology of Space time
> dataset time_dataset@mapset is invalid.
>
>
> I tried the following command (reading the manual of t.register)
>
>  t.register --o --q -i maps=(name of maps separated by comma)
> input=time_dataset start='2011-11-03 02:00:00' increment='120 minutes'
>
> and
>
> - one PC I read the following error ERRORE: invalid literal for int() with
> base 10: '00+00'
> - on PC run correctly and I can run the gui commands witout any error
>
> I have the same GRASS package installed on both the PC (7.4.0-1~xenial1)
>
>
> R
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] ST{R,V}DS in different mapsets

[Sören Gebbert]

Dear Ken,
you have to add the required mapset to your mapset search path using
g.mapsets. This is a feature of the temporal framework to check only
for temporal databases of mapsets in your current mapset search path.

Best regards
Sören

2017-12-05 13:56 GMT+01:00 Ken Mankoff :
> Dear GRASS List,
>
> I'm working with some STRDS and STVDS and having trouble accessing an STRDS 
> located in a different mapset.
>
> I can provide a full MWE, but briefly:
>
> t.sample inputs=bar sample=foo@foo intype=strds samtype=strds method=contain
>
> Reports:
>
> ERROR: Unable to execute sql statement. You have no permission to access
> mapset , or mapset  has no temporal database. Accessible mapsets
> are: 
>
> Is this the expected behavior? I use different mapsets a lot to organize the 
> many rasters and vectors from different parts of the project, and I'd hate to 
> have to work all in one place just to use the time series features.
>
> Thanks,
>
>   -k.
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] How to sample an STVDS based on an STRDS

[Sören Gebbert]

Dear Ken,
there is no functionality for vector aggregation available in GRASS
GIS Temporal Framework. Dependent on your STVDS, maybe you can convert
it into a STRDS by using v.to.rast for each vector layer and then
organize the resulting raster layers in a new STRDS.

Best regards
Sören

2017-12-05 14:00 GMT+01:00 Ken Mankoff :
> Hi,
>
> I'm fairly new to the temporal features in GRASS. I think I'm looking for the 
> inverse of t.rast.aggregate.ds - that is, I have an STRDS with arbitrary 
> intervals (roughly, 24 day windows moving about every 6 days). I have an 
> STVDS with daily data. I'd like to aggregate the daily STVDS to match the 
> STRDS.
>
> I can do this using t.sample, parse that, and aggregate. But this seems to be 
> a fair amount of manual work, and it looks like GRASS abstracts much of this 
> if I were going the other way - subsetting a STRDS based on an STVDS.
>
> Is there a simple way to do this in GRASS - i.e. Is there a command I'm 
> missing or mis-understanding? Or does subsetting vectors take more work 
> because there is no analog to t.rast.aggregate.ds?
>
> Thanks,
>
>   -k.
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] t.rast.accdetect failing

[Sören Gebbert]

Hi,
This seems to be a bug in the name creation of the output raster maps. Can
you please try grass 7.3? Mybe it was already fixed there.

Best regards
Soeren


Am 10.07.2017 9:53 AM schrieb "Micha Silver" :

Hello:

I'm trying to do pattern detection of an STRDS (hourly precipitation from
radar images) with a cycle of 3 hrs. The last step, t.rast.accdetect errors
as follows (after finishing to create the pattern rasters):

Traceback (most recent call last):
  File "/usr/lib/grass72/scripts/t.rast.accdetect", line 592, in 
ERROR: Unable to main()
execute transaction:  File "/usr/lib/grass72/scripts/t.rast.accdetect",
line 437, in main

INSERT INTO raster_base ( name ,creator ,mapset ,creation_time
,temporal_type ,id ) VALUES ('pat_2016_07_12_10' ,'micha' ,'micha'
,'2017-07-09 23:51:24.106063' ,'absolute' ,'pat_2016_07_12_10@micha') ;
INSERT INTO raster_absolute_time ( start_time ,idregister_null,
empty_maps, dbif)
 ,end_time )  File "/usr/lib/grass72/scripts/t.rast.accdetect", line 479,
in create_strds_register_maps
 VALUES
('2016-07-12 10:00:00' ,'pat_2016_07_12_10@micha' ,'2016-07-12 11:00:00') ;
INSERT INTO raster_spatial_extent ( north ,bottom ,west ,top ,proj ,east
,id ,south ) VALUES (-3758645.00 ,0.00 ,-523462.00 ,0.00
,'XY' ,376538.00 ,'pat_2016_07_12_10@micha' ,-4658645.00) ;
INSERT INTO raster_metadata ( max ,rows map.insert(dbif)
,min   File 
"/usr/lib/grass72/etc/python/grass/temporal/abstract_map_dataset.py",
line 275, in insert
,datatype ,number_of_cells
,cols ,ewres ,nsres ,id ) VALUES (2.00 ,900 ,1.00 ,'CELL' ,81
,900 return AbstractDataset.insert(self, dbif=dbif, execute=execute)
,1000.00 ,1000.00  File "/usr/lib/grass72/etc/python/g
rass/temporal/abstract_dataset.py", line 405, in insert
 ,'pat_2016_07_12_10@micha') ;
INSERT INTO raster_stds_register ( id ,registered_stds ) VALUES
('pat_2016_07_12_10@micha' ,NULL) ;
dbif.execute_transaction(statement)
  File "/usr/lib/grass72/etc/python/grass/temporal/core.py", line 1021, in
execute_transaction
return self.connections[mapset].execute_transaction(statement)
  File "/usr/lib/grass72/etc/python/grass/temporal/core.py", line 1315, in
execute_transaction
self.cursor.executescript(statement)
sqlite3.IntegrityError: UNIQUE constraint failed: raster_base.id

If I understand correctly, the 'id' (Primary Key) in raster_base is created
from the raster name and mapset. So why am I getting this "UNIQUE
constraint failed" error? Any tips?


Thanks, Micha

-- 
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
052-3665918

___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Hardware requirements to run GRASS

[Sören Gebbert]

Hi,
Take the  minimum requirements that you use for your analysis. Otherwise
use this:

512MB RAM
Single core 1GHz 32Bit x86 CPU
10GB HD
Linux Debian 7 OS headless

Best regards
Soeren


Am 13.06.2017 11:33 AM schrieb "Luí­s Moreira de Sousa" <
luis.de.so...@protonmail.ch>:

> Dear all,
>
> A Journal editor is requesting the minimum hardware requirements to run
> GRASS. I found a 20 year old unsigned post [0] with some hints, but
> certainly things have changed since. Can anyone shed some light on modern
> requirements?
>
> Thank you.
>
> [0] https://www.gislounge.com/system-requirements-for-grass/
>
> --
> Luís Moreira de Sousa
> Im Grund 6
> CH-8600 Dübendorf
> Switzerland
>
> Phone: +41 (0)79 812 62 65 <+41%2079%20812%2062%2065>
> Email: luis.de.so...@protonmail.ch
> URL: https://sites.google.com/site/luismoreiradesousa
>
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] error in t.rast.accdetect

[Sören Gebbert]

Hi Vero,
this seems to be a bug introduced 14 month ago by someone who
implemented the time suffix. The indicator maps should have added
"_indicator" to their name to distinguish between occurrence and
indicator maps. I will fix this in trunk.

Ciao
Sören

2017-04-27 20:27 GMT+02:00 Veronica Andreo :
> An update:
>
> I investigated outputs a bit more... The output maps that are registered in
> the occurrence strds contain the range of values that is described for
> indicator strds (from 1 to 3), and are in fact generated by something like
> this: if(isnull(eip1_2005_09_28), if(isnull(eip1_2005_09_29), null(), 1),
> if(isnull(eip1_2005_09_29), null(), 2)) <<-- that seems to be the indicator.
> The occurrence maps that are supposed to store the time in days from the
> beginning of the cycle, are not there (or they are overwritten at some
> point, dunno).
>
> In summary, the indicator maps are generated and registered in the
> occurrence strds. The occurrence maps are not created (or they are
> overwritten, dunno) and indicator strds is empty.
>
> My question would however, if the output are two strds, wouldn't we need to
> provide two basenames??
>
> best,
> Vero
>
> 2017-04-27 19:22 GMT+02:00 Veronica Andreo :
>>
>> Hello list,
>>
>> I have accumulated a daily time series of temperatures with BEDD method by
>> means of t.rast.accumulate, and now, I need to identify where do the cycles
>> occur and how much do they last. However, when I run t.rast.accdetect, all
>> goes fine until I get this error:
>>
>> Traceback (most recent call last):
>>   File
>> "/home/veroandreo/software/grass7_trunk/dist.x86_64-pc-linux-gnu/scripts/t.rast.accdetect",
>> line 592, in 
>> ERROR: Unable to execute transaction:
>> INSERT INTO raster_base ( name ,creator ,mapset ,creation_timemain()
>>
>> ,temporal_type ,id   File
>> "/home/veroandreo/software/grass7_trunk/dist.x86_64-pc-linux-gnu/scripts/t.rast.accdetect",
>> line 437, in main
>> ) VALUES ('eip2_2003_08_01' ,'veroandreo' ,'lst'
>> ,'2017-04-27 18:55:42.175407' ,'absolute' ,'eip2_2003_08_01@lst') ;
>> INSERT INTO raster_absolute_time ( start_time ,id ,end_time ) VALUES
>> ('2003-08-01 00:00:00' ,'eip2_2003_08_01@lst' ,'2003-08-02 00:00:00') ;
>> INSERT register_null, empty_maps, dbif)
>> INTO  File
>> "/home/veroandreo/software/grass7_trunk/dist.x86_64-pc-linux-gnu/scripts/t.rast.accdetect",
>> line 479, in create_strds_register_maps
>>  raster_spatial_extent ( north ,bottom ,west ,top ,proj ,east
>> ,id ,south ) VALUES (2428000.00 ,0.00 ,4821000.00 ,0.00
>> ,'XY' ,6309000.00 ,'eip2_2003_08_01@lst' ,1312000.00) ;
>> INSERT INTO raster_metadata (map.insert(dbif)
>>  max  File
>> "/home/veroandreo/software/grass7_trunk/dist.x86_64-pc-linux-gnu/etc/python/grass/temporal/abstract_map_dataset.py",
>> line 283, in insert
>>  ,rows ,min ,datatype ,number_of_cells
>> ,cols ,ewres ,nsres ,id ) VALUES (3.00 ,1488 ,1.00 ,'CELL'
>> ,1660608
>> ,1116 return AbstractDataset.insert(self, dbif=dbif, execute=execute)
>> ,1000.00   File
>> "/home/veroandreo/software/grass7_trunk/dist.x86_64-pc-linux-gnu/etc/python/grass/temporal/abstract_dataset.py",
>> line 403, in insert
>> ,1000.00 ,'eip2_2003_08_01@lst') ;
>> INSERT INTO raster_stds_register ( id ,registered_stds ) VALUES
>> ('eip2_2003_08_01@lst' ,NULL) ;
>> dbif.execute_transaction(statement)
>>   File
>> "/home/veroandreo/software/grass7_trunk/dist.x86_64-pc-linux-gnu/etc/python/grass/temporal/core.py",
>> line 1020, in execute_transaction
>> return self.connections[mapset].execute_transaction(statement)
>>   File
>> "/home/veroandreo/software/grass7_trunk/dist.x86_64-pc-linux-gnu/etc/python/grass/temporal/core.py",
>> line 1314, in execute_transaction
>> self.cursor.executescript(statement)
>> sqlite3.IntegrityError: UNIQUE constraint failed: raster_base.id
>>
>> I have no clue of what is wrong... Here are the commands I'm using (I'm
>> following the example in t.rast.accumulate manual page)
>>
>> # accumulation
>> t.rast.accumulate -n input=reconstructed_lst output=daily_bedd \
>>  start="2003-04-01" stop="2005-09-30" \
>>  cycle="6 months" offset="6 months" granularity="1 day" \
>>  basename=daily_bedd suffix=gran method=bedd limits=14,32 \
>>  scale=0.02 shift=-273.15 --o
>>
>> # detect cycle 1:
>> t.rast.accdetect input=daily_bedd \
>>   occurrence=occurrence_eip1 start="2003-04-01" stop="2005-09-30" \
>>   cycle="6 months" offset="6 months" range=109,218 \
>>   basename=eip1 indicator=indicator_eip1
>>
>> The maps are created (basename=eip1) and they contain data, the occurrence
>> strds is also created and contains the eip1 maps, but the indicator strds is
>> empty. And this one (the indicator strds) is the one needed to identify
>> where do the target cycles occur.
>>
>> I would really appreciate any help and advice... please :)
>>
>> Thanks much
>> Vero
>
>
>
> ___
> grass-user mailing list
> grass-user@lists.osge

Re: [GRASS-user] error in t.rast.accdetect

[Sören Gebbert]

Hi,
is there already a map with the id "eip2_2003_08_01@lst" registered in
the temporal database? The module does not check for existent maps and
simply assumes that the ids are unique.

Ciao
Sören

2017-04-27 19:22 GMT+02:00 Veronica Andreo :
> Hello list,
>
> I have accumulated a daily time series of temperatures with BEDD method by
> means of t.rast.accumulate, and now, I need to identify where do the cycles
> occur and how much do they last. However, when I run t.rast.accdetect, all
> goes fine until I get this error:
>
> Traceback (most recent call last):
>   File
> "/home/veroandreo/software/grass7_trunk/dist.x86_64-pc-linux-gnu/scripts/t.rast.accdetect",
> line 592, in 
> ERROR: Unable to execute transaction:
> INSERT INTO raster_base ( name ,creator ,mapset ,creation_timemain()
>
> ,temporal_type ,id   File
> "/home/veroandreo/software/grass7_trunk/dist.x86_64-pc-linux-gnu/scripts/t.rast.accdetect",
> line 437, in main
> ) VALUES ('eip2_2003_08_01' ,'veroandreo' ,'lst'
> ,'2017-04-27 18:55:42.175407' ,'absolute' ,'eip2_2003_08_01@lst') ;
> INSERT INTO raster_absolute_time ( start_time ,id ,end_time ) VALUES
> ('2003-08-01 00:00:00' ,'eip2_2003_08_01@lst' ,'2003-08-02 00:00:00') ;
> INSERT register_null, empty_maps, dbif)
> INTO  File
> "/home/veroandreo/software/grass7_trunk/dist.x86_64-pc-linux-gnu/scripts/t.rast.accdetect",
> line 479, in create_strds_register_maps
>  raster_spatial_extent ( north ,bottom ,west ,top ,proj ,east
> ,id ,south ) VALUES (2428000.00 ,0.00 ,4821000.00 ,0.00
> ,'XY' ,6309000.00 ,'eip2_2003_08_01@lst' ,1312000.00) ;
> INSERT INTO raster_metadata (map.insert(dbif)
>  max  File
> "/home/veroandreo/software/grass7_trunk/dist.x86_64-pc-linux-gnu/etc/python/grass/temporal/abstract_map_dataset.py",
> line 283, in insert
>  ,rows ,min ,datatype ,number_of_cells
> ,cols ,ewres ,nsres ,id ) VALUES (3.00 ,1488 ,1.00 ,'CELL' ,1660608
> ,1116 return AbstractDataset.insert(self, dbif=dbif, execute=execute)
> ,1000.00   File
> "/home/veroandreo/software/grass7_trunk/dist.x86_64-pc-linux-gnu/etc/python/grass/temporal/abstract_dataset.py",
> line 403, in insert
> ,1000.00 ,'eip2_2003_08_01@lst') ;
> INSERT INTO raster_stds_register ( id ,registered_stds ) VALUES
> ('eip2_2003_08_01@lst' ,NULL) ;
> dbif.execute_transaction(statement)
>   File
> "/home/veroandreo/software/grass7_trunk/dist.x86_64-pc-linux-gnu/etc/python/grass/temporal/core.py",
> line 1020, in execute_transaction
> return self.connections[mapset].execute_transaction(statement)
>   File
> "/home/veroandreo/software/grass7_trunk/dist.x86_64-pc-linux-gnu/etc/python/grass/temporal/core.py",
> line 1314, in execute_transaction
> self.cursor.executescript(statement)
> sqlite3.IntegrityError: UNIQUE constraint failed: raster_base.id
>
> I have no clue of what is wrong... Here are the commands I'm using (I'm
> following the example in t.rast.accumulate manual page)
>
> # accumulation
> t.rast.accumulate -n input=reconstructed_lst output=daily_bedd \
>  start="2003-04-01" stop="2005-09-30" \
>  cycle="6 months" offset="6 months" granularity="1 day" \
>  basename=daily_bedd suffix=gran method=bedd limits=14,32 \
>  scale=0.02 shift=-273.15 --o
>
> # detect cycle 1:
> t.rast.accdetect input=daily_bedd \
>   occurrence=occurrence_eip1 start="2003-04-01" stop="2005-09-30" \
>   cycle="6 months" offset="6 months" range=109,218 \
>   basename=eip1 indicator=indicator_eip1
>
> The maps are created (basename=eip1) and they contain data, the occurrence
> strds is also created and contains the eip1 maps, but the indicator strds is
> empty. And this one (the indicator strds) is the one needed to identify
> where do the target cycles occur.
>
> I would really appreciate any help and advice... please :)
>
> Thanks much
> Vero
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] The GRASS GIS temporal framework: International Journal of Geographical Information Science

[Sören Gebbert]

I am not able to provide a free download link to the paper. There may be an
uncorrected preview version available in the future that can be used for
studying but not for referencing.

Ciao
Sören

Am 10.04.2017 2:39 PM schrieb "Rich Shepard" :

> On Mon, 10 Apr 2017, Sören Gebbert wrote:
>
> JFYI, a new publication about the temporal framework in Grass GIS is now
>> available:
>> http://www.tandfonline.com/doi/abs/10.1080/13658816.2017.130
>> 6862?journalCode=tgis20
>>
>
> Sören,
>
>   It looks intersting and is a good reference when the temporal tools are
> used in support of a client. Unfortunately, it requires a subscription to
> the journal to download a copy of the article.
>
>   Please advise when it might be freely available to all.
>
> Thanks,
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] The GRASS GIS temporal framework: International Journal of Geographical Information Science

[Sören Gebbert]

JFYI, a new publication about the temporal framework in Grass GIS is now
available:

http://www.tandfonline.com/doi/abs/10.1080/13658816.2017.1306862?journalCode=tgis20

Sören
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Temporal framework: calculating annual 5-day extremes

[Sören Gebbert]

Patching t.rast.to.rast3 to support file input requires the
modification of r.to.rast3 to implement file support. This may not
happen in the near future.
I would suggest to use t.rast.algebra or to compute the 5day rainfall
extrema in 5 year chunks using t.rast.to.rast3 + r3.mapcalc. Use
t.rast.extract and its "where" option to compute the 5year strds
chunks.

Best regards
Soeren

2017-04-07 13:37 GMT+02:00 Moritz Lennert :
> On 07/04/17 12:45, RichardCooper wrote:
>>
>> Many thanks for the suggestions.
>>
>> I'd really like to use the voxel approach but am getting the following
>> error
>> on running t.rast.to.rast3 to create a voxel.
>>
>> I've increased the hard and soft limits for open files to 4 on my
>> system, but I still am unable to convert a space time raster dataset  into
>> a
>> 3D raster map with only 5000 raster layers (note: I have 50K daily raster
>> layers that I need to analyse i voxel)
>>
>> $ cat /proc/sys/fs/file-max
>> 800532
>> $ ulimit -Sn
>> 40
>> $ ulimit -Hn
>> 40
>>
>
> AFAICT, the issue is not with the number of open files, but with a list of
> map names (arguments) that is too long for the run_command call that calls
> r.to.rast3. A solution to this could be to allow as input to r.to.rast3 a
> file with map names (such as for r.series).
>
> You should create a bug report for this.
>
> Moritz
>
>
>
>
>> Thanks,
>> Richard
>>
>>
>> Creation of STRDS and error on trying to convert to 3D data set:
>> t.create output=capha_test_5 temporaltype=relative semantictype=max
>> title=cahpa_test_5 description=cahpa_test_5
>>
>> t.register --overwrite --verbose input=capha_test_5@cahpa
>> file=/home/rcooper/grassdatacl/climdata/cahpa/.tmp/rcooper-dell/3528.4
>> start=1 unit=day increment=1
>> Gathering map information...
>> Registering maps in the temporal database...
>> Registering maps in the space time dataset...
>> Updating space time dataset...
>> Update metadata, spatial and temporal extent from all registered maps of
>> 
>> Update metadata, spatial and temporal extent from all registered maps of
>> 
>> Update metadata, spatial and temporal extent from all registered maps of
>> 
>> Update metadata, spatial and temporal extent from all registered maps of
>> 
>> Update metadata, spatial and temporal extent from all registered maps of
>> 
>>
>> t.rast.to.rast3 --overwrite --verbose input=capha_test_5@cahpa
>> output=cahpa_test_5_3d
>> Traceback (most recent call last):
>>   File "/usr/local/grass-7.2.0/scripts/t.rast.to.rast3",
>> line 194, in 
>> main()
>>   File "/usr/local/grass-7.2.0/scripts/t.rast.to.rast3",
>> line 152, in main
>> output=output, overwrite=grass.overwrite())
>>   File
>> "/usr/local/grass-7.2.0/etc/python/grass/script/core.py",
>> line 408, in run_command
>> ps = start_command(*args, **kwargs)
>>   File
>> "/usr/local/grass-7.2.0/etc/python/grass/script/core.py",
>> line 377, in start_command
>> return Popen(args, **popts)
>>   File
>> "/usr/local/grass-7.2.0/etc/python/grass/script/core.py",
>> line 74, in __init__
>> subprocess.Popen.__init__(self, args, **kwargs)
>>   File "/usr/lib/python2.7/subprocess.py", line 710, in
>> __init__
>> errread, errwrite)
>>   File "/usr/lib/python2.7/subprocess.py", line 1327, in
>> _execute_child
>> raise child_exception
>> OSError: [Errno 7] Argument list too long
>> (Fri Apr  7 17:30:33 2017) Command finished (2 sec)
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://osgeo-org.1560.x6.nabble.com/Temporal-framework-calculating-annual-5-day-extremes-tp5316014p5316291.html
>> Sent from the Grass - Users mailing list archive at Nabble.com.
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-user
>>
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Temporal framework: calculating annual 5-day extremes

[Sören Gebbert]

Hi,

2017-04-06 11:09 GMT+02:00 RichardCooper :
> I have a time series of rainfall data, and for each year I want to calculate
> the five-day period with maximum rainfall. So I would need to calculate the
> sum of day1 to day5, then day2 to day6, then day3 to day7 etc for the whole
> year, and then output the maximum grid cell 5-day values for each year into
> a single raster.

What you need is a temporal moving window with the size of 5 days to
compute for each day the 5 day aggregate of the future.
You can convert your time series into a voxel dataset (3d raster) and
use r3.mapcalc with the neighbor index operator map[x][y][z] (if i
remember correctly):

agg_map3d = map3d[0][0][0] + map3d[0][0][1] + ... map3d[0][0][4]

Or you use t.rast.algebra [1] and the temporal neighbor operator strds[t]:

agg_strds = prec_strds[0] + prec_strds[1] + ... prec_strds[4]

Best regards
Soeren

[1] https://grass.osgeo.org/grass73/manuals/t.rast.algebra.html

>
> To do this in t.rast.accumulate, I can see how to set a temporal cycle of 1
> year (cycle= "12 months"), but not sure how to specify such a rolling sum
> calculation of 5 days as described above. The default method is the 'mean'
> as indicated in r.series.accumulation? I'm not too sure how the accumulation
> is applied in the module.
>
> Best regards,
> Richard
>
>
>
> --
> View this message in context: 
> http://osgeo-org.1560.x6.nabble.com/Temporal-framework-calculating-annual-5-day-extremes-tp5316014p5316076.html
> Sent from the Grass - Users mailing list archive at Nabble.com.
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Temporal framework: calculating annual 5-day extremes

[Sören Gebbert]

Hi,
i am not sure if i understand the problem correctly. However, you can use
t.rast.accumulate [1] to create the rolling sum for an arbitrary interval
(5 days, one year?) and then use t.rast.aggregate
to compute the yearly maximum value time series based on the time series
output of t.rast.accumulate.

Or you can use t.rast.aggregate two time, first to compute the 5 day
aggregation (sum of all values in 5 day interval) and then use
t.rast.aggregate to compute the yearly maximums on the output of the first
operation.

Best regards
Soeren

[1] https://grass.osgeo.org/grass72/manuals/t.rast.accumulate.html

Am 06.04.2017 06:31 schrieb "RichardCooper" :

> Hi,
>
> I have a data set containing multiple years of daily raster layers and
> would
> like to aggregate and output annual raster layers of 5-day extremes
> (maxima).
>
> Essentially, for each grid cell, I need to calculate rolling 5-day sums of
> each year and then find the annual max of the latter sums, and output as a
> series of raster layers of annual 5-day extremes.
>
> However, I'm trying to work out the best way in GRASS of doing this.
> Overall
> t.rast.aggregate comes closest to the type of functionality needed. I've
> also looked at t.rast3d.mapcalc, but unsure if calculating a rolling sum is
> possible.
>
> I'd be grateful for any suggestions on how I might approach this.
>
> Thanks,
>
> Richard
>
>
>
> --
> View this message in context: http://osgeo-org.1560.x6.nabbl
> e.com/Temporal-framework-calculating-annual-5-day-extremes-tp5316014.html
> Sent from the Grass - Users mailing list archive at Nabble.com.
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.mapcalc: compare two maps

[Sören Gebbert]

The difference is computed for each pixel.
Just visualize the new map "mapdiff" of run r.univar mapdiff.

2017-03-28 22:23 GMT+02:00 Rich Shepard :
>   I want to compare two raster maps for any differences. The r.mapcalc
> expression I used yielde no results ... unless getting the GRASS shell
> prompt means there are no differences.
>
>   Command and result:
>>
>> r.mapcalc "mapdiff = blocked_culvert - open_culvert"
>>
>
>   No differences? Wrong syntax?
>
> TIA,
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Interpreting t.info metadata

[Sören Gebbert]

2017-03-23 19:43 GMT+01:00 Rich Shepard :
> On Thu, 23 Mar 2017, Sören Gebbert wrote:
>
>> You have 24 maps and therefore 24 minimum values, one for each map, and 24
>> maximum values. t.info shows the minimums and maximums of these values.
>> The smallest minimum value of all 24 maps is 0.001, the largest maximum
>> value of all 24 maps is 3.01965.
>
>
> Soeren,
>
>   Those values make sense to me. But,
>
>>> Minimum value max:.. 0.001008
>>> Maximum value min:.. 0.47729
>

The largest minimum value of all 24 maps is 0.001008.
The smallest maximum value of all 24 maps is 0.47729.

>
> these two don't.
>
> Thanks,
>
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Itzi results have one day lead from input data

[Sören Gebbert]

The strds does not move any dates, it gathers all dates of the maps
and shows the first and last date. The interval time model of the
temporal framework is left closed right open. That means that the end
time is not part of the interval but the start time for a potential
predecessor. This avoids end times like: 2013-12-08 23:59:59.

Please use t.rast.list to inspect all time intervals of your raster maps.

Best regards
Soeren

2017-03-23 19:09 GMT+01:00 Rich Shepard :
>   I created a rainfall STRDS (in mm/hr) from 2013-11-15 through 2013-12-08.
> The Itzi model parameter file's start_time is 2013-11-15. t.register
> specifies the start date as 2013-11-15 and an increment of 1 day.
>
>   When the model was started the first day processed was 2013-11-15, and the
> last day was 2013-12-08.
>
>   When I look at the t.info output I see
> Start time:. 2013-11-16 00:00:00
> End time:... 2013-12-09 00:00:00
> Granularity: 1 day
>
>   Why does the STRDS move the dates ahead by one day?
>
> Rich
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Interpreting t.info metadata

[Sören Gebbert]

You have 24 maps and therefore 24 minimum values, one for each map,
and 24 maximum values. t.info shows the minimums and maximums of these
values. The smallest minimum value of all 24 maps is 0.001, the
largest maximum value of all 24 maps is 3.01965.

Best regards
Soeren

2017-03-23 18:43 GMT+01:00 Rich Shepard :
>   t.info metadata for the STRDS of water accumulation over 23 days are:
>
> North-South resolution min:. 1.3
> North-South resolution max:. 1.3
> East-west resolution min:... 0.999846
> East-west resolution max:... 0.999846
> Minimum value min:.. 0.001
> Minimum value max:.. 0.001008
> Maximum value min:.. 0.47729
> Maximum value max:.. 3.01965
> Aggregation type:... None
> Number of registered maps:.. 24
>
>   Input rainfall data for each day ranges from 0.0 mm/hr to 1.12 mm/hr. I
> want to learn what the min/min, min/max, max/min, and max/max values
> represent.
>
> TIA,
>
> Rich
>
>
>
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] t.register syntax

[Sören Gebbert]

Use the comma separator option for g.list since a comma separated list
of maps is required for the maps option in t.register.

2017-03-23 0:16 GMT+01:00 Rich Shepard :
>   I thought I had recorded the syntax for creating strds's from existing
> raster maps, but I neglected to do so. (t.create worked correctly and the
> strds exists.)
>
>   This command fails:
>
> t.register -i input=blocked_h maps=`g.list type=raster pattern=blocked_h_*`
> type=raster separator=comma start="2013-11-15" increment="1 days"
>
> with a series of error messages like this:
>
> ERROR: Sorry  is not a valid option
>
>   The maps to be registered are:
>
> g.list type=raster pattern=blocked_h_*
> blocked_h_0001
> blocked_h_0002
> blocked_h_0003
> blocked_h_0004
> blocked_h_0005
> blocked_h_0006
> blocked_h_0007
> blocked_h_0008
> blocked_h_0009
> blocked_h_0010
> blocked_h_0011
> blocked_h_0012
> blocked_h_0013
> blocked_h_0014
> blocked_h_0015
> blocked_h_0016
> blocked_h_0017
> blocked_h_0018
> blocked_h_0019
> blocked_h_0020
> blocked_h_0021
> blocked_h_0022
> blocked_h_0023
> blocked_h_max
>
>   I'm not seeing the parameter that I've not entered or the one that should
> be entered. Please correct my syntax and this time I'll be certain to write
> it down!
>
> TIA,
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] STRDS animation: failed to render

[Sören Gebbert]

Hi,
unfortunately renaming of raster layers with g.rename is not
recognized by the temporal framework. You have to remove the old strds
and register the renamed maps in a new strds. Using t.rast.list on the
old strds will give you a map list that you can use as template for
registering.

Best regards
Soeren

2017-03-22 22:31 GMT+01:00 Rich Shepard :
> On Wed, 22 Mar 2017, Anna Petrášová wrote:
>
>> ... and look if there are any messages in terminal. Can you reproduce that
>> behavior?
>
>
> Anna,
>
>   Yes, and yes. I missed seeing the details when the terminal was obscurred
> by the three GUI windows.
>
>   It's a name issue: the strds is named blocked_h (as are the individual
> raster maps) but the renderer is looking for open_h instead. For example,
>
> GRASS_INFO_WARNING(14315,1): Rendering failed:
> GRASS_INFO_WARNING(14315,1): GRASS_INFO_ERROR(14306,1): Raster map
>  not found
>
>   I used a bash script with sed to rename all raster maps from open_h_* to
> blocked_h_*, then used 't.rename in=open_h out=blocked_h'. The error message
> suggests that somewhere a name was not changed.
>
>   t.info does not indicate any name differences and t.list shows only
> blocked_h and blocked_wse so why the animator is looking for open_h puzzles
> me.
>
> Thanks,
>
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.water.outlet map does not display

[Sören Gebbert]

Am 06.03.2017 11:50 PM schrieb "Rich Shepard" :

  Using r.watershed specifying the input DEM and a name for the drainage map
I can view the drainage map. When I follow this command with r.water.outlet
specifying the drainage map as input, 'watershed' as the output map name,
and the coordinates of the designated outlet, no map is displayable.

  Could this be due to the very flat nature of the terrain?


Yes. The watershed computed via r.water.outlet may be only a single pixel
in size, if your outlet point is not located on a stream. Better use
r.watershed.


Rich
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] t.rast.algebra with strds of different granularity

[Sören Gebbert]

Hi,

2017-03-02 13:35 GMT+01:00 Veronica Andreo :
> Hi list,
>
> Just by mistake, I did an operation between two time series (strds) with
> t.rast.algebra, and only after a while I realized that they have different
> granularity (while I thought they had the same). One of them is daily (from
> 00:00:00 to 00:00:00, 24 hs intervals) and the other is also daily, but
> intervals are from 10:30 to 22:30 (12 hours). Anyway, the second one is
> temporally included/contained in the first one. However, when I make a
> substraction among them, I get an empty strds as result and no error nor
> warning message.

The default temporal-topological operator is "equal". The expression:

C = A - B

is the short form of:

C = A {-, equal, l} B

Since your timestamps are not equal, the result is an empty STRDS.
From my standpoint this is the correct result of this expression, no
need to raise an error or a warning. r.mapcalc for example will not
warn you, if the result of your expression is an empty raster map.

Using the correct temporal-topological operator is the key in your
case. Your suggestion below is correct. You need to specify the
"contains" relationship to compute the desired results.

The following expression:

C = A {-, contains} B

means, compute the difference between all maps from A and B that
fulfill the "contains" temporal relationship. The temporal topological
operation will be evaluated between all maps from A and B. If a map
from A has a contains relationship to one or several maps of B, then
the difference between the two/many maps will be computed and the
timestamp of the left side of the statement (timestamps from A) will
be used for the resulting maps. You can specify if the left or right
timestamps should be used for the result maps or the intersection or
union of the involved map timestamps. Be aware that implicit
aggregation will be performed if more than one map is found to compute
the difference.

Best regards
Soeren

>
> This is how I wrote the command:
>
> t.rast.algebra -n basename=lwr_minus_orig expression="abs_lwr_minus_orig =
> abs(LST_Day_2016_lwr1 - LST_Day_2016_orig)"
>
> How should it look like for the temporal topology to be considered, then?
> Something like:
>
> expression="abs_lwr_minus_orig = abs(LST_Day_2016_lwr1 { -, contains }
> LST_Day_2016_orig)"  ??
>
> Shouldn't a warning be raised when granularities are different and no
> temporal topology operator is used? Dunno if that's possible at all.
>
> Thanks for any tips
>
> Vero
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] t.register does not register anything in a STVDS

[Sören Gebbert]

2017-02-24 17:53 GMT+01:00 Laurent C. :
> Sören,
>
> I was sure I did. Anyway is it expected behaviour to be able to
> register maps in the DB without registering them in a STDS?

Yes, it is.

> I agree with Markus that a warning could be useful.

I don't think so, you will get a warning for expected behavior.

Best regards
Soeren

> Thanks for the tip.
>
> Laurent
>
>
>
> 2017-02-23 21:27 GMT-06:00 Sören Gebbert :
>> You need to specify the name of the stvds in t.register.
>>
>> Am 24.02.2017 02:48 schrieb "Laurent C." :
>>>
>>> Hello,
>>>
>>> I created an empty STVDS that looks fine:
>>>
>>> t.info input=water_levels_20150801@kolkata type=stvds
>>>  + Space Time Vector Dataset
>>> -+
>>>  |
>>> |
>>>  + Basic information
>>> -+
>>>  | Id:  water_levels_20150801@kolkata
>>>  | Name: .. water_levels_20150801
>>>  | Mapset:  kolkata
>>>  | Creator: ... laurent
>>>  | Temporal type: . absolute
>>>  | Creation time: . 2017-02-23 19:18:15.120512
>>>  | Modification time:.. 2017-02-23 19:18:15.120516
>>>  | Semantic type:.. mean
>>>  + Absolute time
>>> -+
>>>  | Start time:. None
>>>  | End time:... None
>>>  | Granularity: None
>>>  | Temporal type of maps:.. None
>>>  + Spatial extent
>>> +
>>>  | North:.. None
>>>  | South:.. None
>>>  | East:..  None
>>>  | West:... None
>>>  | Top: None
>>>  | Bottom:. None
>>>  + Metadata information
>>> --+
>>>  | Vector register table:..
>>> vector_map_register_c14262576ea94a78a55b48b65a72b3a6
>>>  | Number of points ... None
>>>  | Number of lines  None
>>>  | Number of boundaries ... None
>>>  | Number of centroids  None
>>>  | Number of faces  None
>>>  | Number of kernels .. None
>>>  | Number of primitives ... None
>>>  | Number of nodes  None
>>>  | Number of areas  None
>>>  | Number of islands .. None
>>>  | Number of holes  None
>>>  | Number of volumes .. None
>>>  | Number of registered maps:.. None
>>>  |
>>>  | Title:
>>>  | water_levels
>>>  | Description:
>>>  |
>>>  | Command history:
>>>  | # 2017-02-23 19:18:15
>>>  | t.create --overwrite output="water_levels_20150801"
>>>  | type="stvds" semantictype="mean" title="water_levels" description="
>>> "
>>>  |
>>>
>>> ++
>>>
>>> I have a maplist file in the form:
>>> water_levels_2015073100|2015-07-31 00:00:00
>>> water_levels_20150731001500|2015-07-31 00:15:00
>>> [snip]
>>> water_levels_20150801233000|2015-08-01 23:30:00
>>> water_levels_20150801234500|2015-08-01 23:45:00
>>>
>>> The vector maps look sane:
>>> v.info map=water_levels_20150731021500@kolkata
>>>
>>> ++
>>>  | Name:water_levels_20150731021500
>>> |
>>>  | Mapset:  kolkata
>>> |
>>>  | Location:UTM45N
>>> |
>>>  | Database:/home/laurent/grassdata
>>> |
>>>  | Title:
>>> |
>>>  | Map scale:   1:1
>>> |
>>>  | Name of creator: laurent
>>> |
>>>  | Organization:
>>> |
>>>  | Source date: Thu Feb 23 18:50:06 2017
>>> |
>>>  | Timestamp (first layer): 31 Jul 2015 02:15:00
>>> |
>>>
>>> ||
>>>  | Map format:  native
>>> |
>>>
>>> |-

Re: [GRASS-user] t.register does not register anything in a STVDS

[Sören Gebbert]

You need to specify the name of the stvds in t.register.
Am 24.02.2017 02:48 schrieb "Laurent C." :

> Hello,
>
> I created an empty STVDS that looks fine:
>
> t.info input=water_levels_20150801@kolkata type=stvds
>  + Space Time Vector Dataset
> -+
>  |
> |
>  + Basic information --
> ---+
>  | Id:  water_levels_20150801@kolkata
>  | Name: .. water_levels_20150801
>  | Mapset:  kolkata
>  | Creator: ... laurent
>  | Temporal type: . absolute
>  | Creation time: . 2017-02-23 19:18:15.120512
>  | Modification time:.. 2017-02-23 19:18:15.120516
>  | Semantic type:.. mean
>  + Absolute time --
> ---+
>  | Start time:. None
>  | End time:... None
>  | Granularity: None
>  | Temporal type of maps:.. None
>  + Spatial extent --
> --+
>  | North:.. None
>  | South:.. None
>  | East:..  None
>  | West:... None
>  | Top: None
>  | Bottom:. None
>  + Metadata information --
> +
>  | Vector register table:..
> vector_map_register_c14262576ea94a78a55b48b65a72b3a6
>  | Number of points ... None
>  | Number of lines  None
>  | Number of boundaries ... None
>  | Number of centroids  None
>  | Number of faces  None
>  | Number of kernels .. None
>  | Number of primitives ... None
>  | Number of nodes  None
>  | Number of areas  None
>  | Number of islands .. None
>  | Number of holes  None
>  | Number of volumes .. None
>  | Number of registered maps:.. None
>  |
>  | Title:
>  | water_levels
>  | Description:
>  |
>  | Command history:
>  | # 2017-02-23 19:18:15
>  | t.create --overwrite output="water_levels_20150801"
>  | type="stvds" semantictype="mean" title="water_levels" description="
> "
>  |
>  +---
> -+
>
> I have a maplist file in the form:
> water_levels_2015073100|2015-07-31 00:00:00
> water_levels_20150731001500|2015-07-31 00:15:00
> [snip]
> water_levels_20150801233000|2015-08-01 23:30:00
> water_levels_20150801234500|2015-08-01 23:45:00
>
> The vector maps look sane:
> v.info map=water_levels_20150731021500@kolkata
>  +---
> -+
>  | Name:water_levels_20150731021500
>|
>  | Mapset:  kolkata
>|
>  | Location:UTM45N
> |
>  | Database:/home/laurent/grassdata
>|
>  | Title:
>|
>  | Map scale:   1:1
>|
>  | Name of creator: laurent
>|
>  | Organization:
> |
>  | Source date: Thu Feb 23 18:50:06 2017
> |
>  | Timestamp (first layer): 31 Jul 2015 02:15:00
> |
>  |---
> -|
>  | Map format:  native
> |
>  |---
> -|
>  |   Type of map: vector (level: 2)
>|
>  |
> |
>  |   Number of points:   3   Number of centroids:  0
> |
>  |   Number of lines:0   Number of boundaries: 0
> |
>  |   Number of areas:0   Number of islands:0
> |
>  |
> |
>  |   Map is 3D:  No
>|
>  |   Number of dblinks:  1
> |
>  |
> |
>  |   Projection: UTM (zone 45)
> |
>  |
> |
>  |   N:  2495814.59574642S:  2492825.11903619
>|
>  |   E:   645063.06070329W:   641365.09898322
>|
>  |
> |
>  |   Digitization threshold: 0
> |
>  |   Comment:
>|
>  |
> |
>  +---
> -+
>
>
> t.register seems to works fine:
> t.register --overwrite --verbose type=vector
> file=/home/laurent/Datos_geo/kolkata/one_rainfall_event_of_
> 2015/wl_register_list.txt
> Gathering map information...
> Registering maps in the temporal database...
>
> But no map is added to the STVDS. If I run t.info again, I get the
> exact same results as above.
>
> Strangely, if I run t.register without the --overwrite flag, I get the
> following error:
> t.register --verbose type=vector
> file=/home/laurent/Datos_geo/kolkata/one_rainfall_event_of_
> 2015/wl_register_list.txt
> Gathering map information...
> WARNING: Map is already registered in temporal database. Unable to
> update vector map . Overwrite
> flag is not set.
> [snip]
>
> But again, t.info or t.vect.list don't show any map.
>
> By opening the S

Re: [GRASS-user] Temporal data issues need resolving

[Sören Gebbert]

Can you please run the following commands in the mapset that has the
error and send me the result?

r.info rainfall_20131115@precipitation
t.info rainfall

2017-02-23 22:53 GMT+01:00 Rich Shepard :
> On Thu, 23 Feb 2017, Rich Shepard wrote:
>
>>  That map _does_ exist. Now I'll re-create and re-register the rainfall
>> maps for the third time. Shouldn't need to keep doing this, should I?
>
>
> g.list type=raster pattern='rainfall_*' separator=comma
> rainfall_20131115,rainfall_20131116,rainfall_20131117,rainfall_20131118,rai
> nfall_20131120,rainfall_20131121,rainfall_20131122,rainfall_20131123,rainfa
> ll_20131124,rainfall_20131125,rainfall_20131126,rainfall_20131127,rainfall_
> 20131128,rainfall_20131129,rainfall_20131130,rainfall_20131201,rainfall_201
> 31202,rainfall_20131203,rainfall_20131204,rainfall_20131205,rainfall_201312
> 06,rainfall_20131207,rainfall_20131208,rainfall_20131209
>
>   Notice that the first map is rainfall_20131115 so why can't t.register
> find it?
>
> t.create output=rainfall type=strds temporaltype=absolute title='Rainfall'
> description='Daily rainfall in mm/hr.' --overwrite
> WARNING: Overwriting space time raster dataset  and unregistering
>  all maps
> GRASS 7.3.svn
> (Oregon-Dayton-meters):~/projects/oregon/washington-eichler/analyses >
> t.register -i input=rainfall maps=`g.list type=raster pattern="rainfall_*"
> separator=comma` start="2013-11-15" increment="1 days"
> Gathering map information...
> ERROR: Unable to update raster map . The
> map does not exist.
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Temporal data issues need resolving

[Sören Gebbert]

This error is related to the temporal topology of the rainfall strds, it
seems to lack interval time.
Am 23.02.2017 22:22 schrieb "Rich Shepard" :

> On Thu, 23 Feb 2017, Laurent C. wrote:
>
>
>>>   Because Itzi does not like maps to be in different mapsets.
>>>
>>
>> That is not true. You just have to provide Itzï with the fully
>> qualified ID in the form mapname@mapset, like every other GRASS
>> module.
>>
>
> Laurent,
>
>   The parameter file contains:
>
> [input]
> dem = open_culvert@topography
> friction = manning@topography
> rain = rainfall@precipitation
>
>   What's wrong with these? The model does not run with this parameter file:
>
> time itzi run itzi-open-culvert.txt
> Starting simulation of itzi-open-culvert.txt... WARNING:
> rainfall@precipitation: invalid topology WARNING: Error during execution:
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/itzi/itzi.py", line 183, in
> sim_runner_worker
> sim_runner.run()
>   File "/usr/lib/python2.7/site-packages/itzi/itzi.py", line 90, in run
> sim_param=self.conf.sim_param)
>   File "/usr/lib/python2.7/site-packages/itzi/simulation.py", line 77, in
> __init__
> self.gis.read(self.in_map_names)
>   File "/usr/lib/python2.7/site-packages/itzi/gis.py", line 189, in read
> if not self.stds_temporal_sanity(strds_id):
>   File "/usr/lib/python2.7/site-packages/itzi/gis.py", line 222, in
> stds_temporal_sanity
> if stds_start > sim_start:
> TypeError: can't compare datetime.datetime to NoneType
>
> Simulations complete. Elapsed times: itzi-open-culvert.txt: 0:00:00 Total:
> 0:00:00 Average: 0:00:00
>
> real0m0.871s
> user0m0.751s
> sys 0m0.129s
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Temporal data issues need resolving

[Sören Gebbert]

Can you please send me the grass location so that i can investigate the bug?

Best regards
Soeren

2017-02-23 20:13 GMT+01:00 Rich Shepard :
> On Thu, 23 Feb 2017, Sören Gebbert wrote:
>
>> This seems to be a bug.
>
>
> Sören,
>
>   Just my luck! :-(
>
>> However, in your last email you performed this task in the topology
>> mapset.
>
>
>   That's true.
>
>> Why do you need to have three rainfall strds? Are they differen? If
>> they are equal then you can reference to a single strds using the
>> @mapset approach like in raster or vector maps.
>
>
>   Because Itzi does not like maps to be in different mapsets.
>
>   My maps are in separate directories: data/precipitation/,
> /data/topography/, and analyses/. I tried running Itzi from the analyses/
> subdirectory and the model told me it could not find the DEM or manning's n
> maps or the precipitation STRDS. As I wrote earlier, I had to re-create and
> re-register the rainfall STRDS because it disappeared since yesterday
> afternoon.
>
> Thanks,
>
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Temporal data issues need resolving

[Sören Gebbert]

This seems to be a bug.
However, in your last email you performed this task in the topology mapset.
The module g.list will show all mas from all mapsets. This command
will only show maps from a specific mapset if you force it to: g.list
type=rast sep="," mapset=precipitation.

Why do you need to have three rainfall strds? Are they differen? If
they are equal then you can reference to a single strds using the
@mapset approach like in raster or vector maps.

2017-02-23 18:34 GMT+01:00 Rich Shepard :
> On Thu, 23 Feb 2017, Sören Gebbert wrote:
>
>> Are strds and raster maps located in the same mapset?  A restriction of
>> the
>> temporal framework is, that you can only register maps in stds from the
>> same mapset.
>
>
> Sören,
>
>   They should be:
>
> g.mapset -p
> precipitation
>
> g.list type=raster pattern=rainfall_* separator=comma
> rainfall_20131115,rainfall_20131116,rainfall_20131117,rainfall_20131118,rai
> nfall_20131120,rainfall_20131121,rainfall_20131122,rainfall_20131123,rainfa
> ll_20131124,rainfall_20131125,rainfall_20131126,rainfall_20131127,rainfall_
> 20131128,rainfall_20131129,rainfall_20131130,rainfall_20131201,rainfall_201
> 31202,rainfall_20131203,rainfall_20131204,rainfall_20131205,rainfall_201312
> 06,rainfall_20131207,rainfall_20131208,rainfall_20131209
>
> t.list type=strds
> --
> Space time raster datasets with absolute time available in mapset
> :
> rainfall@precipitation
> Space time raster datasets with absolute time available in mapset
> :
> rainfall@analyses
> Space time raster datasets with absolute time available in mapset
> :
> rainfall@topography
>
>
> Regards,
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Temporal data issues need resolving

[Sören Gebbert]

Are strds and raster maps located in the same mapset?  A restriction of the
temporal framework is, that you can only register maps in stds from the
same mapset.

Am 23.02.2017 18:03 schrieb "Rich Shepard" :

>   Yesterday I created and registered a STRDS. Today grass cannot find it. I
> tried re-creating and re-registering the dataset but the latter step fails.
>
>   All mapsets are available regardless of the current mapset:
>
> g.mapsets -p
> Accessible mapsets:
> precipitation PERMANENT analyses features soils topography
>
>   In the precipitation mapset the files are present:
>
> g.list type=raster pattern=rainfall_* separator=comma
> rainfall_20131115,rainfall_20131116,rainfall_20131117,rainfa
> ll_20131118,rai
> nfall_20131120,rainfall_20131121,rainfall_20131122,rainfall_
> 20131123,rainfa
> ll_20131124,rainfall_20131125,rainfall_20131126,rainfall_201
> 31127,rainfall_
> 20131128,rainfall_20131129,rainfall_20131130,rainfall_201312
> 01,rainfall_201
> 31202,rainfall_20131203,rainfall_20131204,rainfall_20131205,
> rainfall_201312
> 06,rainfall_20131207,rainfall_20131208,rainfall_20131209
>
> t.create runs with no errors:
>
> t.create output=rainfall type=strds temporaltype=absolute title='Rainfall'
> description='Daily rainfall in mm/hr.' --overwrite
> WARNING: Overwriting space time raster dataset  and unregistering
>  all maps
>
> But, t.register fails not finding the first rainfall map:
>
> t.register -i input=rainfall maps=`g.list type=raster pattern="rainfall_*"
> separator=comma start="2013-11-15" increment="1 days"
> Gathering map information...
> ERROR: Unable to update raster map . The
> map does not exist.
>
>   Nothing in grass73 changed from yesterday afternoon to this morning.
>
>   I need to resolve this problem so I can run a model. Your help is needed
> to understand what happed and how to fix it.
>
> Regards,
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Creating STRDS from scratch

[Sören Gebbert]

This is a good looking empty STRDS. All metadata that is set to "None"
will be updated if maps are added to the STRDS with t.register.

2017-02-22 16:28 GMT+01:00 Rich Shepard :
> On Tue, 21 Feb 2017, Laurent C. wrote:
>
>> In your case, it seems you want to have uniform rainfall. So you can set
>> the region, and then use mapcalc like so: r.mapcalc
>> exp='rainfall_2013115=0.1' And doing the same for each day.
>
>
>   The region is correctly set. I assume that what t.info reports is correct
> as the rainfall input to Itzi and would like confirmation or corrections:
>
> t.info type=strds input=rainfall
>  +--- Space Time Raster Dataset ---+
>  |
>  |
>  +--- Basic information ---+
>  | Id:  rainfall@topography
>  | Name: .. rainfall
>  | Mapset:  topography
>  | Creator: ... rshepard
>  | Temporal type: . absolute
>  | Creation time: . 2017-02-21 13:43:48.931376
>  | Modification time:.. 2017-02-21 13:43:48.931422
>  | Semantic type:.. mean
>  +--- Absolute time ---+
>  | Start time:. None
>  | End time:... None
>  | Granularity: None
>  | Temporal type of maps:.. None
>  +--- Spatial extent --+
>  | North:.. None
>  | South:.. None
>  | East:..  None
>  | West:... None
>  | Top: None
>  | Bottom:. None
>  +-- Metadata information -+
>  | Raster register table:..
> raster_map_register_7137018d99ba4dd29f94b620b8ca406e
>  | North-South resolution min:. None
>  | North-South resolution max:. None
>  | East-west resolution min:... None
>  | East-west resolution max:... None
>  | Minimum value min:.. None
>  | Minimum value max:.. None
>  | Maximum value min:.. None
>  | Maximum value max:.. None
>  | Aggregation type:... None
>  | Number of registered maps:.. None
>  |
>  | Title:
>  | Rainfall Rates
>  | Description:
>  | Daily rainfall rates in mm/hr.
>  | Command history:
>  | # 2017-02-21 13:43:49
>  | t.create type="strds" temporaltype="absolute"
>  | output="rainfall" title="Rainfall Rates"
>  | description="Daily rainfall rates in mm/hr."
>
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Creating STRDS from scratch

[Sören Gebbert]

If your data is accumulated for a time period (a day, ...), then you
have interval time.
If your data represent a value that is valid for a specific time
period (daily mean), you have interval time.
If your data represents a specific state at a point of time that has a
smaller period as a second, then you have time instances.

The next thing to consider is, what you want to do with the data. If
you want to compute interactions with other time series, then it makes
sense to use time intervals to compute temporal overlapping and
intersection.

Best regards
Soeren

2017-02-22 0:14 GMT+01:00 Rich Shepard :
> On Tue, 21 Feb 2017, Veronica Andreo wrote:
>
>> If your maps represent intervals, then yes, it is correct to use -i. What
>> -i does is create intervals of the given increment (1 day) starting from
>> the start date that you pass (2013-11-15).
>
>
> Vero,
>
>   Since this is the first time I've dealt with temporal datasets in GRASS I
> need to understand what more experienced analysts take for granted. In this
> case I'm trying to understand whether my data do represent intervals.
>
>   The data represent the hourly average rainfall rate calculated by dividing
> the daily total rainfall amount by 24. Therefore, for each day I have a
> single value, and the STRDS input file consists of that value for each date
> in sequence for a total of 25 days. The last day in the file is a filler to
> ensure the last meaningful day is included.
>
>   So I assume that since I have raster maps for each of 25 sequential dates
> they represent intervals. And, if I were to have a set of files with each
> one on a different day, but not sequential, then those maps would not
> represent intervals. Are these assumption correct?
>
> Thanks,
>
>
> Rich
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Creating STRDS from scratch

[Sören Gebbert]

Hi,

2017-02-21 17:35 GMT+01:00 Rich Shepard :
>   After reading the spatio-temporal introduction and t.create manual page I
> went to the wiki where an example workflow is presented. The example uses
> satellite raster data; my data are 25 days of daily precipitation (total and
> hourly rate) over an approximate 40 ha area. A bare earth LiDAR DEM for this
> area exists.
>
>   Do I make copies of the DEM for each day then replace the elevation with
> either the daily total or the hourly rate for each day?
>
>   For the t.create parameters I know type = strds but have no idea what
> temporaltype or semantictype to specify. (N.B. The manual page example has
> no value for semantictype and that's supposed to be required input.)

Temporal type can be absolute or relative. The semantic type is not
used for now.
absolute time -> calendar time with an absolute reference like
2017-01-01 12:00:00
relative time -> a second, three years, two minutes ...

>
>   Where do I find the information I need to create this temporal database?
>
> Rich
>
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Interpreting r.watershed accumulation map

[Sören Gebbert]

Hi,
i don't know why this happens. It may be a bug in the temporal framework or
in itzi. Testing the code in the temporal framework seems to work, but more
testing is needed.
However, the traceback is fine, but there must be an error message that
will tell you what mapset is missing and what mapsets are in the temporal
framework search path.

Something like:
"""
You have no permission to "
   "access mapset <%(mapset)s>, or "
   "mapset <%(mapset)s> has no temporal database. "
   "Accessable mapsets are: <%(mapsets)s>

"""

Best regards
Soeren


2016-10-16 22:03 GMT+02:00 Rich Shepard :
>
> On Sat, 15 Oct 2016, Sören Gebbert wrote:
>
>> Please try to put all mapsets that you use in your analysis into the
>> mapset search path. The temporal framework will only access strds in
>> mapsets that are located in the current search path.
>
>
> Soeren,
>
>   Current mapset is 'analyses':
>
>> g.mapset -p
>
> analyses
>
>   Some maps might be in other mapsets so ...
>
>> g.mapsets -p
>
> Accessible mapsets:
> analyses PERMANENT features soils topography precipitation
>
> which is all the mapsets in the location.
>
>   The file, itzi-param.txt, contains:
>
> [time]
> duration = 2:00:00
> record_step = 00:05:00
>
> [input]
> dem = be_cropped@topography
> friction = n
> rain = rain
>
> [output]
> prefix = pop
> values = h, wse, v, vdir, boundaries
>
> [statistics]
> stats_file = pop.csv
>
>   And this is the traceback:
>
>
>> itzi run itzi-param.txt
>
> Starting simulation of itzi-param.txt... WARNING: Error during execution:
Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/itzi/itzi.py", line 183, in
> sim_runner_worker
> sim_runner.run()
>   File "/usr/lib/python2.7/site-packages/itzi/itzi.py", line 90, in run
> sim_param=self.conf.sim_param)
>   File "/usr/lib/python2.7/site-packages/itzi/simulation.py", line 77, in
> __init__
> self.gis.read(self.in_map_names)
>   File "/usr/lib/python2.7/site-packages/itzi/gis.py", line 187, in read
> elif self.name_is_stds(self.format_id(map_name)):
>   File "/usr/lib/python2.7/site-packages/itzi/gis.py", line 138, in
> name_is_stds
> if tgis.SpaceTimeRasterDataset(name).is_in_db():
>   File
> "/usr/local/grass-7.3.svn/etc/python/grass/temporal/abstract_dataset.py",
> line 368, in is_in_db
> return self.base.is_in_db(dbif)
>   File "/usr/local/grass-7.3.svn/etc/python/grass/temporal/base.py", line
> 315, in is_in_db
> dbif.execute(sql, mapset=self.mapset)
>   File "/usr/local/grass-7.3.svn/etc/python/grass/temporal/core.py", line
> 981, in execute
> self._create_mapset_error_message(mapset)))
>   File
> "/usr/local/grass-7.3.svn/etc/python/grass/pygrass/messages/__init__.py",
> line 271, in fatal
> sys.exit(1)
> SystemExit: 1
>
> Simulations complete. Elapsed times: itzi-param.txt: 0:00:01 Total:
0:00:01 Average: 0:00:01
>
>   Please suggest what I should try modifying.
>
> Thanks,
>
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Interpreting r.watershed accumulation map

[Sören Gebbert]

Please try to put all mapsets that you use in your analysis into the mapset
search path. The temporal framework will only access strds in mapsets that
are located in the current search path.

Best
Soeren

2016-10-11 20:38 GMT+02:00 Rich Shepard :

> On Tue, 11 Oct 2016, Laurent C. wrote:
>
> - Your rainfall rate is very small.
>>
>
> Laurent,
>
>   Changed rain to 10 mm/h, time to 2 hrs with 5 min steps. Specified mapset
> for DEM map (be_cropped) as it's not in the analyses mapset.
>
> - By setting bctype=4 and bcvalue=0 on all your region, you're forcing
>> a water depth of zero everywhere. For a start, you can drop those
>> parameters.
>>
>
>   Removed both bctype and bcvalue.
>
> About the problem you encounter. Since GRASS does not support python3
>> (AFAIK), Itzï is only tested with python 2.7. It is strange that it
>> installed with python3. To force the installation with python2, you
>> can run the following command:
>> $ pip2 install itzi --user
>>
>
>   Yes, now itzi is installed for both python2 and python3.
>
>   There is an issue with the time-space databases that prevent the
> simulation from running:
>
> itzi run itzi-param.txt
>>
> Starting simulation of itzi-param.txt... WARNING: Error during execution:
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/itzi/itzi.py", line 183, in
> sim_runner_worker
> sim_runner.run()
>   File "/usr/lib/python2.7/site-packages/itzi/itzi.py", line 90, in run
> sim_param=self.conf.sim_param)
>   File "/usr/lib/python2.7/site-packages/itzi/simulation.py", line 77, in
> __init__
> self.gis.read(self.in_map_names)
>   File "/usr/lib/python2.7/site-packages/itzi/gis.py", line 187, in read
> elif self.name_is_stds(self.format_id(map_name)):
>   File "/usr/lib/python2.7/site-packages/itzi/gis.py", line 138, in
> name_is_stds
> if tgis.SpaceTimeRasterDataset(name).is_in_db():
>   File
> "/usr/local/grass-7.3.svn/etc/python/grass/temporal/abstract_dataset.py",
> line 368, in is_in_db
> return self.base.is_in_db(dbif)
>   File "/usr/local/grass-7.3.svn/etc/python/grass/temporal/base.py", line
> 315, in is_in_db
> dbif.execute(sql, mapset=self.mapset)
>   File "/usr/local/grass-7.3.svn/etc/python/grass/temporal/core.py", line
> 981, in execute
> self._create_mapset_error_message(mapset)))
>   File
> "/usr/local/grass-7.3.svn/etc/python/grass/pygrass/messages/__init__.py",
> line 271, in fatal
> sys.exit(1)
> SystemExit: 1
>
> Simulations complete. Elapsed times: itzi-param.txt: 0:00:00 Total:
> 0:00:00 Average: 0:00:00
>
>
> Rich
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] temporal dataset : register maps from other mapsets

[Sören Gebbert]

Hi,
I decided to use a mapset specific variable, since this will affect the
temporal database of this mapset and therefore all processes related to
this mapset. Hmmm ... there are pros an cons for booth solutions, but i
will stick with the current one. :)

Cheers
Soeren
Am 17.04.2016 13:05 schrieb "Martin Landa" :

2016-04-17 12:56 GMT+02:00 Sören Gebbert :
> Set it with:
> g.gisenv set="TGIS_DISABLE_TIMESTAMP_WRITE=True

probably better would be environment variable (export) rather than
GRASS variable? Ma

--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] temporal dataset : register maps from other mapsets

[Sören Gebbert]

Hi Vero,
I have send my mail just a second after i recieved your mail ... .

However, i would like to add that a second temporal GIS environmental
variable exists, that disables the write of map layer metadata:
TGIS_DISABLE_TIMESTAMP_WRITE

Set it with:
g.gisenv set="TGIS_DISABLE_TIMESTAMP_WRITE=True

This will avoid that time stamps are written as text files in the map layer
specific metadata directory by the temporal framework. The drawback is that
modules written in C are not able to determine if the map layer has a
timestamp using the C-API. The benefit is that map layer specific data in
other mapsets are not modified if the space time dataset are modified.

Best regards
Soeren


2016-04-17 12:40 GMT+02:00 Veronica Andreo :

> Ops, dismiss previous email... Eheh! :P
>
> Thanks for the explanation and hint, Sören!
> El abr 17, 2016 7:32 AM, "Veronica Andreo" 
> escribió:
>
> Hi Martin,
>
> What if you try running t.connect -d (set from default) in PERMANENT
> first? The error says there's no temporal database connection defined.
> Maybe that works.
>
> Cheers,
> Vero
> El abr 17, 2016 7:08 AM, "Martin Landa"  escribió:
>
>> Hi,
>>
>> I wonder why it's not possible to register in temporal dataset maps
>> from other mapsets?
>>
>> Module `t.register` fails to register maps from PERMANENT mapset in my
>> current mapset (`landa):
>>
>> t.create output=modis title="MODIS 2002" desc="Ukazkovy casoprostorovy
>> dataset MODIS"
>> g.list type=raster mapset=PERMANENT sep='newline' out=maps.txt -m
>> t.register input=modis file=maps.txt sep='newline'
>> ERROR: Unable to execute sql statement. There is no temporal database
>> connection defined for mapset 
>>
>> So I am able to register only maps from the current mapset. Why? Ma
>>
>> --
>> Martin Landa
>> http://geo.fsv.cvut.cz/gwiki/Landa
>> http://gismentors.cz/mentors/landa
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-user
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] temporal dataset : register maps from other mapsets

[Sören Gebbert]

Hi Martin,
by default the temporal databases are mapset specific. In addition the
temporal framework does not allow to register maps from other mapsets in a
space time dataset. Hence space time datasets are mapset specific as well.

The reason for this are permission considerations. Several temporal
commands that modify space time datasets will also modify the registered
map layers. Changing the time stamps for layers will always trigger the
modification of map layer metadata (time stamp files in the map layer
directories). If you do not have write permissions on the mapset from which
you have registered the maps, then all these commands will fail and maybe
the temporal database will have issues afterwards.

However, in "THEORY" you can set the database connection for each mapset to
point to a single database. Then you must set the TGIS_DISABLE_MAPSET_CHECK
environment variable, so that the temporal framework does allow that map
layers from different mapset can be registered in a single space time
dataset. I have not tested this and there are no gunittests  available yet
that check for this hidden feature.

Best regards
Soeren


2016-04-17 12:08 GMT+02:00 Martin Landa :

> Hi,
>
> I wonder why it's not possible to register in temporal dataset maps
> from other mapsets?
>
> Module `t.register` fails to register maps from PERMANENT mapset in my
> current mapset (`landa):
>
> t.create output=modis title="MODIS 2002" desc="Ukazkovy casoprostorovy
> dataset MODIS"
> g.list type=raster mapset=PERMANENT sep='newline' out=maps.txt -m
> t.register input=modis file=maps.txt sep='newline'
> ERROR: Unable to execute sql statement. There is no temporal database
> connection defined for mapset 
>
> So I am able to register only maps from the current mapset. Why? Ma
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] problem with python scripting

[Sören Gebbert]

Please try gscript.mapcalc(expr... , overwrite=True)
Am 05.04.2016 09:02 schrieb "Leonardo Hardtke" :

> Hi Paulo and thanks for the answer... but It gives me a very similar error
> if I write the full flag (The only difference is TypeError... str if I
> use 'o' and int if I use 'overwrite' )
>
>  gscript.mapcalc('endmember_rstr.1 = null()', flags="overwrite")
>
> ERROR: output map  exists. To overwrite, use the
>--overwrite flag
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/grass70/etc/python/grass/script/raster.py", line 103, in
> mapcalc
> quiet=quiet, verbose=verbose, overwrite=overwrite)
>   File "/usr/lib/grass70/etc/python/grass/script/core.py", line 516, in
> write_command
> return handle_errors(returncode, returncode, args, kwargs)
>   File "/usr/lib/grass70/etc/python/grass/script/core.py", line 312, in
> handle_errors
> returncode=returncode)
>   File "/usr/lib/grass70/etc/python/grass/exceptions/__init__.py", line
> 68, in __init__
> msg = _("Module run %s %s ended with error") % (module, code)
> TypeError: 'int' object is not callable
>
> Thanks for your help!
>
> 2016-04-05 16:56 GMT+10:00 Paulo van Breugel :
>
>>
>>
>> On 05-04-16 08:53, Leonardo Hardtke wrote:
>>
>> Dear users,
>> I am writing a script and I'm having problems with the flags for mapcalc
>> gscript.mapcalc('endmember_rstr.1 = null()', flags="o")
>>
>>
>> If  you are using GRASS 7.+, the overwrite flag should be written in
>> full, i.e.,
>>
>> gscript.mapcalc('endmember_rstr.1 = null()', flags="overwrite")
>>
>>
>>
>> ERROR: output map  exists. To overwrite, use the
>>--overwrite flag
>> Traceback (most recent call last):
>>   File "", line 1, in 
>>   File "/usr/lib/grass70/etc/python/grass/script/raster.py", line 103, in
>> mapcalc
>> quiet=quiet, verbose=verbose, overwrite=overwrite)
>>   File "/usr/lib/grass70/etc/python/grass/script/core.py", line 516, in
>> write_command
>> return handle_errors(returncode, returncode, args, kwargs)
>>   File "/usr/lib/grass70/etc/python/grass/script/core.py", line 312, in
>> handle_errors
>> returncode=returncode)
>>   File "/usr/lib/grass70/etc/python/grass/exceptions/__init__.py", line
>> 68, in __init__
>> msg = _("Module run %s %s ended with error") % (module, code)
>> TypeError: 'str' object is not callable
>>
>> with other modules flags are working as I expect, like
>>
>> gscript.run_command("g.region", flags="p")
>> projection: 1 (UTM)
>> zone:   -20
>> datum:  wgs84
>> ellipsoid:  wgs84
>> north:  5326556.02809
>> south:  5228355.32592
>> west:   290546.512535
>> east:   444008.446334
>> nsres:  30.00326984
>> ewres:  30.0081998
>> rows:   3273
>> cols:   5114
>> cells:  16738122
>>
>> Am I missing something?
>>
>> Thanks!
>> --
>> Dr. Leonardo A. Hardtke
>> Laboratorio de Teledetección y S.I.G.
>> Centro Nacional Patagónico (CONICET)
>> Bvd. Brown 2825, 9120
>> Puerto Madryn, Chubut, Argentina
>>
>>
>> ___
>> grass-user mailing 
>> listgrass-user@lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/grass-user
>>
>>
>>
>
>
> --
> Dr. Leonardo A. Hardtke
> Laboratorio de Teledetección y S.I.G.
> Centro Nacional Patagónico (CONICET)
> Bvd. Brown 2825, 9120
> Puerto Madryn, Chubut, Argentina
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Examples of use of r.gwflow

[Sören Gebbert]

Hi,
please have a look at the test scripts that have been developed to
verify the correct computation of r.gwflow:

https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.gwflow/testsuite/validation_7x7_grid.py
https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.gwflow/testsuite/validation_excavation.py

Please be aware, that r.gwflow is a very simple groundwater
computation tool. Many steps in groundwater modelling must be
performed outside of r.gwflow, like calibration, temporally changing
of boundary conditions, weather conditions and so on.

Best regards
Soeren


2016-02-07 17:44 GMT+01:00 Markus Neteler :
> On Sat, Feb 6, 2016 at 4:39 PM, Huub Munstege  wrote:
>> Hello dear GRASS users community,
>> We're interested in using the "Groundwater modeling" in GRASS GIS. Searching
>> the net doesn't give many actual results / examples. One article of 2005
>> (http://hidro.ufcg.edu.br/twiki/pub/Disciplinas/GeotecnologiaAplicada/Renato.pdf)
>> uses an older version (r.gmtg that was based on MODFLOW). Has any of you
>> experience / examples of the use of the actual module r.gwflow? We are
>> looking for a way to model the groundwater recharge from small reservoirs in
>> Mali.
>
> I saw that the "Diplomarbeit" of the r.gwflow author is online (PDF,
> German language).
>
> Furthermore I saw this AGU poster:
> http://www.urbanmetabolism.asia/sites/default/files/mehta_etal_aguposter2_48x36_horz.pdf
>
> A related discussion with script snippets is here:
> https://lists.osgeo.org/pipermail/grass-user/2012-July/thread.html#65316
>
> Hope this helps (maybe others can post more),
>
> Markus Neteler
>
>
> --
> http://www.mundialis.de/
> http://gis.cri.fmach.it/neteler/
> http://courses.neteler.org/blog
>
>
>> Thanks in advance,
>> Huub
>>
>> 
>> Ir. H.F.M Munstege
>> Consultant indépendant - Gestion des ressources en eaux
>> mob. +223 - 78370695 (Mali)
>> mob. +227 - 91279637 (Niger)
>> Badalabougou, rue 108 - porte 679
>> Bamako
>> Rép. du Mali
>>
>>
>>
>>
>> 
>>
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-user
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] help t.rast.algebra

[Sören Gebbert]

Hi,
Sorry, i am unable to help here, since the algebra is a deep mistery for me
as well. I think that after i have finished a paper about it, the algebra
will be much better documented.

Ciao
Sören
Am 25.09.2015 16:40 schrieb "Veronica Andreo" :

> Hi Moritz,
>
> I eventually solved it like this:
>
> t.rast.aggregate -s input=cla granularity="1 years" method=minimum
> output=yearly_min basename=yearly_min
> t.rast.aggregate -s input=cla granularity="1 months" method=minimum
> output=monthly_min basename=monthly_min
>
> YEAR_I=2003 ; YEAR_F=2013
> MONTH_I=1 ;MONTH_F=12
>
> for YEAR in `seq $YEAR_I $YEAR_F` ; do
> for MONTH in `seq -w $MONTH_I $MONTH_F` ; do
> r.mapcalc expression="month_min_${YEAR}_${MONTH} =
> if(monthly_min_${YEAR}_${MONTH} == yearly_min_${YEAR}, ${MONTH}, null())"
> --o
> done
> done
>
> r.series input=`g.list type=raster pattern=*_ag sep=,`
> output=month_of_min_mode method=mode
>
> Alternatively,
>
> 1. t.rast.aggregate -s input=cla granularity="1 months" method=minimum
> output=monthly_min basename=monthly_min
>
> 2. t.rast.aggregate -s input=monthly_min granularity="1 years"
> method=min_rast output=yearly_min_index
>
> 3. r.series input=`g.list rast pat=yearly_min_ind* sep=,` method=mode
>
> 4. r.reclass with
>
> 0 = 1
> 1 = 2
> 2 = 3
> 3 = 4
> 4 = 5
> 5 = 6
> 6 = 7
> 7 = 8
> 8 = 9
> 9 = 10
> 10 = 11
> 11 = 12
>
> Meanwhile, I still think t.rast.algebra should do the job in one
> command... I just cannot
> figure it out (yet) from the manual page:
> https://grass.osgeo.org/grass71/manuals/t.rast.algebra.html
>
> I keep studying it, though
>
> Thanks a lot!
> Vero
>
>
> 2015-09-24 3:58 GMT-03:00 Moritz Lennert :
>
>> On 18/09/15 17:38, Veronica Andreo wrote:
>>
>>> Hi Soeren, list
>>>
>>> I need some help with t.rast.algebra. Well, if it is that my problem is
>>> really a t.rast.algebra problem...
>>>
>>> I have 2 strds with different granularities. A is an annual time series
>>> that contains the min annual temperature, B is a monthly time series
>>> containing the min monthly temperature. I want to compare the two of
>>> them, and when a pixel of B equals that of A, I need to get the
>>> start_month(B) but with the temporal resolution of A. So, what I want as
>>> output is a yearly time series containing the month in which the minimum
>>> temperature of each year occurs. Does that make any sense??
>>>
>>> I been studying t.rast.algebra all morning now and trying different kind
>>> of relationships (with no success), and I got lost in the different
>>> relationships and the different ways to express them.
>>>
>>> Can someone point me to the right way of using t.rast.algebra for this
>>> problem?
>>>
>>
>> No help for t.rast.algebra, but wouldn't looping over the years and
>> applying t.rast.series with method=min_raster get you what you want ?
>>
>> Moritz
>>
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] t.vect.observe.strds: OSError: [Errno 7] Argument list too long

[Sören Gebbert]

Hi,
The module t.rast.what in grass71 should not have this limitation and is
much faster. It does not create a STVDS as output, but plain text using
different formatting.

Best regards
Soeren
Am 01.06.2015 17:12 schrieb "RichardCooper" :

> A solution to this is to specify 'where' conditions under the optional tab,
> e.g.,
>
> start_time <= '2'
>
> I determined this figure by trial and error - not sure if it is my computer
> system that is the limiting factor requiring this be done in batches.
>
>
>
> --
> View this message in context:
> http://osgeo-org.1560.x6.nabble.com/t-vect-observe-strds-OSError-Errno-7-Argument-list-too-long-tp5208418p5208498.html
> Sent from the Grass - Users mailing list archive at Nabble.com.
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Aggregating daily maps in relative strds per month

[Sören Gebbert]

Hi Nikos,
being not able to recreate the temporal database in a mapset after
deleting it is definitely a bug in the temporal framework. I have to
investigate this.

Regarding ghost entries:

You can use "t.list type=rast" to list all raster map layer registered
in the temporal database, with or without STRDS association.
Use the "maps" option of module t.unregister to un-register any  kind
of map layers (existing, ghost, non-STRDS association, ...).

Best regards
Soeren

2015-05-19 9:54 GMT+02:00 Nikos Alexandris :
> I couldn't find my way out to clean the existing mess I created.  I am
> re-doing all from scratch.  It was all worth the time spent though.
>
> It there is interest for open questions (of mine), below an error
> message and a question.
>
> Thanks, Nikos
>
>
> Soeren:
>
>> > The tgis directory can be removed, all temporal commands will check if
>> > the mapset specific temporal database exists and will create one if
>> > needed.
>
> Nikos:
>
>> I removed the tgis directory manually (rm -rf). Then issued `t.connect -d` 
>> or/and
>> `t.connect -c`. Though this sets the connection driver/path in the VAR
>> file, the '-p' reports as if all is ok, I only receive the error
>>
>> ERROR: Unable to connect to sqlite3 database:
>> /geo/grassdb/ellas/oiti/wgs84_old/PERMANENT/tgis/sqlite.db
>> Exception: "unable to open database file"
>> Please use t.connect to set a read- and writable temporal database
>> backend
>>
>> from any of the t.connect or t.create commands I tried.
>
> + a more detailed message from withing a GRASS session and ipython,
> trying to force tgis.init():
>
> --%<---
> In [3]: %tb
> ---
> SystemExitTraceback (most recent call last)
>  in ()
> > 1 tgis.init()
>
> /osgeo/grass70/dist.x86_64-unknown-linux-gnu/etc/python/grass/temporal/core.pyc
>  in init(raise_fatal_error)
> 658 return
> 659
> --> 660 create_temporal_database(dbif)
> 661
> 662 
> ###
>
> /osgeo/grass70/dist.x86_64-unknown-linux-gnu/etc/python/grass/temporal/core.pyc
>  in create_temporal_database(dbif)
> 769 # Connect now to the database
> 770 if not dbif.connected:
> --> 771 dbif.connect()
> 772
> 773 # Execute the SQL statements for sqlite
>
> /osgeo/grass70/dist.x86_64-unknown-linux-gnu/etc/python/grass/temporal/core.pyc
>  in connect(self)
> 878 conn = self.connections[mapset]
> 879 if conn.is_connected() is False:
> --> 880 conn .connect(dbstring)
> 881
> 882 self.connected = True
>
> /osgeo/grass70/dist.x86_64-unknown-linux-gnu/etc/python/grass/temporal/core.pyc
>  in connect(self, dbstring)
>1077   "temporal database backend") % (
>1078 {"db": self.dbmi.__name__,
> -> 1079  "string": tgis_database_string, "ex": e, 
> }))
>1080
>1081 def close(self):
>
> /osgeo/grass70/dist.x86_64-unknown-linux-gnu/etc/python/grass/pygrass/messages/__init__.pyc
>  in fatal(self, message)
> 269 raise FatalError(message)
> 270 else:
> --> 271 sys.exit(1)
> 272
> 273 def debug(self, level, message):
>
> SystemExit: 1
> --->%--
>
>
>
> Nikos:
>
>> > > 2) although I remove strds-es via t.remove, the command `t.list rast` 
>> > > still
>> > > shows maps which do not exist anymore anywhere. How come?
>
> Soeren:
>
>> > Maps can be registered in several different STDS. Hence removing a
>> > STDS without explicitly removing the registered map layers (forced
>> > with -rf) will only un-register the maps from the specific STDS but
>> > not from the temporal database.
>> > Use t.unregister to simply un-register map layers from the temporal
>> > database (and all associated STDS) or use the -rf option in t.remove
>> > to fully remove map layers from the temporal and spatial database. The
>> > module g.remove will not delete the time stamps from the temporal
>> > database, since only temporal commands are aware of it. The module
>> > t.support allows to check STDS for removed or overwritten map layers
>> > to update the temporal database accordingly.
>
> What happens if ones removes the strds using t.remove without '-rf' or/and no
> t.support -m was executed. And, additionally, removes a series of (previously)
> registered maps as well using g.remove? It seems that this results in ghost 
> entries
> in the t-db (?).
>
> t.unregister will not work if the maps and the strds don't exist, right?
> t.remove -rf
>
> Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Aggregating daily maps in relative strds per month

[Sören Gebbert]

Hi Nikos,

2015-05-18 23:07 GMT+02:00 Nikos Alexandris :
> * Sören Gebbert  [2015-05-18 20:34:19 +0200]:
>
>> Hi Nikos,
>> You need to use t.remove to delete the time stamps from the temporal
>> database. The *.timestamp modules should not be used at all. They are not
>> connected with the temporal framework.
>> The error appears because the maps still have relative time stamps in the
>> temporal database which can not be overwritten with absolute time stamps.
>
> Thanks for spotting.  I am not sure about the following:
>
> 1) how does t.connect/t.create work if I erase the "tgis"
> directory manually?  Is it not possible to create a new tgis from
> scratch?

The tgis directory can be removed, all temporal commands will check if
the mapset specific temporal database exists and will create one if
needed.

>
> 2) although I remove strds-es via t.remove, the command `t.list rast` still
> shows maps which do not exist anymore anywhere. How come?

Maps can be registered in several different STDS. Hence removing a
STDS without explicitly removing the registered map layers (forced
with -rf) will only un-register the maps from the specific STDS but
not from the temporal database.
Use t.unregister to simply un-register map layers from the temporal
database (and all associated STDS) or use the -rf option in t.remove
to fully remove map layers from the temporal and spatial database. The
module g.remove will not delete the time stamps from the temporal
database, since only temporal commands are aware of it. The module
t.support allows to check STDS for removed or overwritten map layers
to update the temporal database accordingly.

Best regards
Soeren

>
> Danke, Nikos
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Aggregating daily maps in relative strds per month

[Sören Gebbert]

Hi Nikos,
You need to use t.remove to delete the time stamps from the temporal
database. The *.timestamp modules should not be used at all. They are not
connected with the temporal framework.
The error appears because the maps still have relative time stamps in the
temporal database which can not be overwritten with absolute time stamps.

Ciao
Sören
Am 18.05.2015 19:47 schrieb "Nikos Alexandris" :

> Nikos Alexandris:
>
> > Having absolute timestamps would make life easier with the
> > fantastic temporal framework. I'll re-do again my workflow and decide
> > upon a year. After all, I did extract the following for a specific year
> > (don't remember which one it was now :-?):
>
> I think it was 2009. So, I am trying to go 'absolute':
>
> # list maps
> g.list raster pattern=global_rad_zero_[0-9][0-9][0-9]
>
> global_rad_zero_001
> ..
> global_rad_zero_365
>
> # erase timestamps
> for Map in `g.list raster pattern=global_rad_zero_[0-9][0-9][0-9]` ;do
> r.timestamp map=${Map} date=none ;done
>
> # create an absolute strds
> t.create out=global_rad_zero title="Clearsky global irradiation"
> description="Clearsky global irradiation on a horizontal surface raster
> maps
> [Wh.m-2.day-1]" --o
>
> # register maps (which have no timestamp!)
> t.register -i input=global_rad_zero maps=`g.list raster
> pattern=global_rad_zero_[0-9][0-9][0-9] sep=,` start="2009-01-01"
> increment='1 days' --o
>
> 0..ERROR: invalid literal for int() with base 10: '2009-01-01'
>
> Why?  Nikos
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] [GRASS-dev] QGIS GRASS Plugin Upgrade Crowdfunding

[Sören Gebbert]

Dear all,
just a short reminder. The crowd funding period for the QGIS GRASS
Plugin is still running but will end soon. Everyone who may be
willingly to fund this great project can contribute funds until May
23.

Best regards
Soeren

2015-03-23 19:56 GMT+01:00 Radim Blazek :
> Hi all,
>
> I have finally launched the crowdfunding campaign to support the GRASS
> plugin upgrade. Briefly, it covers upgrade to GRASS 7, browser
> integration, drag-and-drop import and new vector editing. All the
> details are available here:
>
> http://www.gissula.eu/qgis-grass-plugin-crowdfunding/
>
> Please propagate this info to all relevant channels, national mailing lists 
> etc.
>
> Radim
> ___
> grass-dev mailing list
> grass-...@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Aggregating daily maps in relative strds per month

[Sören Gebbert]

Hi Nikos,
sorry for the late response.

The aggregation of daily relative time STRDS with Gregorian monthly
granularity is not possible, since in relative time mode, there is no
connection between daily and monthly calendar hierarchy. The reason is
that in relative time mode there is no starting point in calendar time
at which day 1,2 or n starts. Hence you never know to which month or
year a day is associated, because of the lack of a calendar hierarchy.
The number of days per month and per year are different in the
Gregorian calendar, hence the output of r.sun.daily should be in my
humble opinion yearly and monthly specific.

However, you can create a second STDS with relative time, that
contains of 12 maps with the according time intervals (31 days, 28/29
days, ...) and use t.rast.aggregate.ds to aggregate the first STRDS
based on the time intervals of the second STDS.

Best regards
Soeren

2015-05-16 13:41 GMT+02:00 Nikos Alexandris :
> Is there a better way to aggregate a *relative* spatio-temporal raster
> data set composed by daily maps (output from r.sun.daily) in monthly
> average strds-es?
>
> At the moment I use the following csv and script:
>
> --%<---
> # month_start_end_day.csv
> January|1|31
> February|32|59
> March|60|90
> April|91|120
> May|121|151
> June|152|181
> July|182|212
> August|213|243
> September|244|273
> October|274|304
> November|305|334
> December|335|365
> --->%--
>
> and
>
> --%<---
> # loop over spatio-temporal raster data sets of interest
> for STRDS in global_rad_zero beam_rad_zero diff_rad_zero insol_time
> do
> # loop over months (start day, end day, month name) in csv
> for LINE in `cat month_start_end_day.csv`
>
> do
> # set positional parameters
> set -- $(echo ${LINE} |tr "|" " ")
>
> # aggregate
> t.rast.aggregate input=${STRDS} output=${STRDS}_$1_average 
> basename=${STRDS}_$1_average where="start_time >= $2 AND start_time <= $3" 
> granularity=1 --o
> done
>
> done
> --->%--
>
> Any tip highly appreciated, Nikos
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] [GRASS-dev] QGIS GRASS Plugin Upgrade Crowdfunding

[Sören Gebbert]

Hi Radim,

2015-03-24 9:40 GMT+01:00 Radim Blazek :
> Hi Soeren,
> thanks for your reaction. I remember we already discussed the
> possibility to move to Python.
>
> On Mon, Mar 23, 2015 at 9:19 PM, Sören Gebbert
>  wrote:
>> Hi Radim,
>> this is a beautiful idea and i hope you will get plenty of funds.
>>
>> I have some questions regarding the implementation, since this is not
>> mentioned in the project description:
>>
>> Do you plan to implement the plugin in C++ only, or will you try to
>> combine C++ (data provider) and Python (all the rest)? The reason i am
>> asking is, that using Python for the user interaction, module calling,
>> vector editing and mapset/location handling would allow us GRASS
>> developer to provide possible improvements and bugfixes for the plugin
>> more easily. For example, the time series handling [1] in GRASS GIS is
>> mainly implemented in Python and provides a Python API that could be
>> used in the QGIS GRASS Plugin to implement time series analysis
>> support.
>> Using the QGIS Python plugin approach will reduce the need for
>> compilation, which allows much faster development of modifications and
>> bugfix testing.
>
>
> I completely agree that Python would be better, the advantages of
> Python are obvious and that would be definitely my choice if I had to
> start from scratch. Un(fortunately) the GRASS plugin + qgsgrassgislib
> have already 22500 lines of C++ so porting to Python is not an option
> and mixing C++ in single plugin either (as far to my knowledge).

Indeed, porting the C++ code to Python is a large effort. However,
maybe you can define a stretch-goal in the crowd funding campaign? If
this goal is met, then you have enough funds to port the C++ code to
Python and you can add more features?

I think that using C++ and Python in a Plugin shouldn't be a big
problem in my humble opinion. The main issue would be that the C++
code of the data provide will be part of QGIS and the Python code that
makes use of the GRASS data provider will be a separate GRASS Python
QGIS plugin. Maybe this approach will allow to implement several
independent Python plugins that make use of the GRASS data provider to
implement specific algorithms?

> Are there functions in time series implementation which need to be
> called directly from the plugin or everything may be done just calling
> t.rast.* modules?

Most of the temporal functionality is available through the temporal
modules. However some important algorithms (temporal re-sampling) are
available only in the Python framework. This is needed for time series
animation creation. Using the framework directly will speed things up,
because the module calls, the parsing and interpretation of the module
outputs can be avoided.

Many thanks for the QGIS GRASS Plugin
Best regards
Soeren

> Radim
>
>> The data provider and vector editing helper classes must be of course
>> implemented in C++ and should stay in the QGIS source tree.
>>
>> Best regards
>> Soeren
>>
>> [1] http://ifgi.uni-muenster.de/~epebe_01/tgrass.pdf
>>
>> Btw: Otto Dassau and i mentioned your crowd funding idea at the
>> FOSSGIS in Germany two weeks ago. It is on Youtube[2] but only in
>> German.
>>
>> [2] https://www.youtube.com/watch?v=rxmPbh2igmM&t=1407
>>
>> 2015-03-23 19:56 GMT+01:00 Radim Blazek :
>>> Hi all,
>>>
>>> I have finally launched the crowdfunding campaign to support the GRASS
>>> plugin upgrade. Briefly, it covers upgrade to GRASS 7, browser
>>> integration, drag-and-drop import and new vector editing. All the
>>> details are available here:
>>>
>>> http://www.gissula.eu/qgis-grass-plugin-crowdfunding/
>>>
>>> Please propagate this info to all relevant channels, national mailing lists 
>>> etc.
>>>
>>> Radim
>>> ___
>>> grass-dev mailing list
>>> grass-...@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] [GRASS-dev] QGIS GRASS Plugin Upgrade Crowdfunding

[Sören Gebbert]

Hi Radim,
this is a beautiful idea and i hope you will get plenty of funds.

I have some questions regarding the implementation, since this is not
mentioned in the project description:

Do you plan to implement the plugin in C++ only, or will you try to
combine C++ (data provider) and Python (all the rest)? The reason i am
asking is, that using Python for the user interaction, module calling,
vector editing and mapset/location handling would allow us GRASS
developer to provide possible improvements and bugfixes for the plugin
more easily. For example, the time series handling [1] in GRASS GIS is
mainly implemented in Python and provides a Python API that could be
used in the QGIS GRASS Plugin to implement time series analysis
support.
Using the QGIS Python plugin approach will reduce the need for
compilation, which allows much faster development of modifications and
bugfix testing.
The data provider and vector editing helper classes must be of course
implemented in C++ and should stay in the QGIS source tree.

Best regards
Soeren

[1] http://ifgi.uni-muenster.de/~epebe_01/tgrass.pdf

Btw: Otto Dassau and i mentioned your crowd funding idea at the
FOSSGIS in Germany two weeks ago. It is on Youtube[2] but only in
German.

[2] https://www.youtube.com/watch?v=rxmPbh2igmM&t=1407

2015-03-23 19:56 GMT+01:00 Radim Blazek :
> Hi all,
>
> I have finally launched the crowdfunding campaign to support the GRASS
> plugin upgrade. Briefly, it covers upgrade to GRASS 7, browser
> integration, drag-and-drop import and new vector editing. All the
> details are available here:
>
> http://www.gissula.eu/qgis-grass-plugin-crowdfunding/
>
> Please propagate this info to all relevant channels, national mailing lists 
> etc.
>
> Radim
> ___
> grass-dev mailing list
> grass-...@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Questions on TGRASS; t.rast.gapfill , GRASS 71

[Sören Gebbert]

Hi Sajid,
until today, t.rast.gapfill did not support interpolation by granularity.
However, please try revision r64651 in grass7.1 trunk. This feature
has now been implemented and should work as you would expect.
Of course, heavily testing is still needed.

I am still investigating the case when no gaps are found using the
where condition.

Best regards
Soeren

2015-02-05 19:23 GMT+01:00 sajid pareeth :
> Hi
> I am trying to use the module "t.rast.gapfill" to fill the gaps in my
> temporal datasets. I have couple of doubts on getting my tasks done.
>
> I am using GRASS 71 svn, latest.
>
> ##Q1:
>
> In my temporal data , there are multiple continuous gaps. In this case, I am
> not getting the interpolated results. Please check the below work flow:
>
> r.mapcalc expr="map1 = 1" --o
> r.mapcalc expr="map2 = 3" --o
> r.mapcalc expr="map3 = 5" --o
> r.mapcalc expr="map4 = 7" --o
> r.mapcalc expr="map5 = 9" --o
> t.register type=raster maps=map1 start=2012-08-20 end=2012-08-21 --o
> t.register type=raster maps=map2 start=2012-08-22 end=2012-08-23 --o
> t.register type=raster maps=map3 start=2012-08-25 end=2012-08-26 --o
> t.register type=raster maps=map4 start=2012-08-29 end=2012-08-30 --o
> t.register type=raster maps=map5 start=2012-09-03 end=2012-09-04 --o
> t.create type=strds temporaltype=absolute output=mapT1 title="test for all
> the gaps filled together" description="test for all the gaps filled
> together"
> t.register type=raster input=mapT1 maps=map1,map2,map3,map4,map5 --o
> t.rast.list input=mapT1 columns=name,start_time,min,max
> t.rast.list input=mapT1 method=gran
> id|name|mapset|start_time|end_time|interval_length|distance_from_begin
> map1@testtgrass|map1|testtgrass|2012-08-20 00:00:00|2012-08-21
> 00:00:00|1.0|0.0
> None|None|None|2012-08-21 00:00:00|2012-08-22 00:00:00|1.0|1.0
> map2@testtgrass|map2|testtgrass|2012-08-22 00:00:00|2012-08-23
> 00:00:00|1.0|2.0
> None|None|None|2012-08-23 00:00:00|2012-08-24 00:00:00|1.0|3.0
> None|None|None|2012-08-24 00:00:00|2012-08-25 00:00:00|1.0|4.0
> map3@testtgrass|map3|testtgrass|2012-08-25 00:00:00|2012-08-26
> 00:00:00|1.0|5.0
> None|None|None|2012-08-26 00:00:00|2012-08-27 00:00:00|1.0|6.0
> None|None|None|2012-08-27 00:00:00|2012-08-28 00:00:00|1.0|7.0
> None|None|None|2012-08-28 00:00:00|2012-08-29 00:00:00|1.0|8.0
> map4@testtgrass|map4|testtgrass|2012-08-29 00:00:00|2012-08-30
> 00:00:00|1.0|9.0
> None|None|None|2012-08-30 00:00:00|2012-08-31 00:00:00|1.0|10.0
> None|None|None|2012-08-31 00:00:00|2012-09-01 00:00:00|1.0|11.0
> None|None|None|2012-09-01 00:00:00|2012-09-02 00:00:00|1.0|12.0
> None|None|None|2012-09-02 00:00:00|2012-09-03 00:00:00|1.0|13.0
> map5@testtgrass|map5|testtgrass|2012-09-03 00:00:00|2012-09-04
> 00:00:00|1.0|14.0
>
> # Doing the gapfill:
> t.rast.gapfill input=mapT1 base=gap
> t.rast.list input=mapT1 method=gran
> id|name|mapset|start_time|end_time|interval_length|distance_from_begin
> map1@testtgrass|map1|testtgrass|2012-08-20 00:00:00|2012-08-21
> 00:00:00|1.0|0.0
> gap_10@testtgrass|gap_10|testtgrass|2012-08-21 00:00:00|2012-08-22
> 00:00:00|1.0|1.0
> map2@testtgrass|map2|testtgrass|2012-08-22 00:00:00|2012-08-23
> 00:00:00|1.0|2.0
> gap_11@testtgrass|gap_11|testtgrass|2012-08-23 00:00:00|2012-08-24
> 00:00:00|1.0|3.0
> gap_11@testtgrass|gap_11|testtgrass|2012-08-24 00:00:00|2012-08-25
> 00:00:00|1.0|4.0
> map3@testtgrass|map3|testtgrass|2012-08-25 00:00:00|2012-08-26
> 00:00:00|1.0|5.0
> gap_12@testtgrass|gap_12|testtgrass|2012-08-26 00:00:00|2012-08-27
> 00:00:00|1.0|6.0
> gap_12@testtgrass|gap_12|testtgrass|2012-08-27 00:00:00|2012-08-28
> 00:00:00|1.0|7.0
> gap_12@testtgrass|gap_12|testtgrass|2012-08-28 00:00:00|2012-08-29
> 00:00:00|1.0|8.0
> map4@testtgrass|map4|testtgrass|2012-08-29 00:00:00|2012-08-30
> 00:00:00|1.0|9.0
> gap_13@testtgrass|gap_13|testtgrass|2012-08-30 00:00:00|2012-08-31
> 00:00:00|1.0|10.0
> gap_13@testtgrass|gap_13|testtgrass|2012-08-31 00:00:00|2012-09-01
> 00:00:00|1.0|11.0
> gap_13@testtgrass|gap_13|testtgrass|2012-09-01 00:00:00|2012-09-02
> 00:00:00|1.0|12.0
> gap_13@testtgrass|gap_13|testtgrass|2012-09-02 00:00:00|2012-09-03
> 00:00:00|1.0|13.0
> map5@testtgrass|map5|testtgrass|2012-09-03 00:00:00|2012-09-04
> 00:00:00|1.0|14.0
>
> For example; between 2012-08-29 and 2012-09-03 there are 4 days of gap, but
> the gap filling is providing the same image at all the 4 gaps. It seems to
> be generating only one image between two valid temporal images, no matter
> how long the gap is!!
>
> So is the gap filling will work only for one gap between 2 valid temporal
> images?
>
>
> ###2.
>
> When I try to do gap fill with the "where" condition, I am getting no
> results in some cases.
> For example when I try:
>
> t.rast.gapfill input=mapT1 where="start_time = '2012-08-21 00:00:00'"
> base=gap
> No gaps found
>
> OR when I try;
>
> t.rast.gapfill input=mapT1 where="start_time > '2012-08-20 00:00:00'"
> base=gap
>
> It misses the first gap and fills the other gap, see below:
>
> t.rast.list inpu

Re: [GRASS-user] GRASS pygrass - composite

[Sören Gebbert]

Dear Pierric,
can you please check your region settings?

g.region -p

It should be identical to the raster maps you are trying to compose.

g.region rast=B5

Best regards
Soeren

2015-02-11 13:55 GMT+01:00 Pierric de Laborie :
> Dear Pietro,
>
> I ran the same command with the highest level of verbose. Unfortunately it
> didn't give much more information when blocking at the problematic step.
>
> I also started the same command from GRASS GUI on another debian machine and
> it got stuck also. It is like the installation on Debian Wheezy doesn't
> fully work (?)
>
>
> GRASS 7.0.0svn (222):~/Grass_test > g.gisenv set="DEBUG=5"
>
> D1/1: G_set_program_name(): g.gisenv
> D1/5: G_set_program_name(): g.gisenv
> D2/5: G_option_to_separator(): key = separator -> sep = '/'
>
> GRASS 7.0.0svn (222):~/Grass_test >  r.composite red=B5@PERMANENT
> green=B4@PERMANENT blue=B3@PERMANENT output=mycompo
>
> D1/5: G_set_program_name(): r.composite
> D2/5: G_file_name(): path = /tmp/grassdata/222/PERMANENT
> D2/5: G_file_name(): path = /tmp/grassdata/222/PERMANENT/cell/mycompo
> D2/5: G_file_name(): path = /tmp/grassdata/222/PERMANENT/WIND
> D2/5: G_file_name(): path = /tmp/grassdata/222/PERMANENT/WIND
> D2/5:   file open: read (mode = r)
> D2/5: G__read_Cell_head
> D2/5: G__read_Cell_head_array
> D3/5: region item: proj:   1
> D3/5: region item: zone:   32
> D3/5: region item: north:  3948015
> D3/5: region item: south:  0
> D3/5: region item: east:   841215
> D3/5: region item: west:   0
> D3/5: region item: cols:   841215
> D3/5: region item: rows:   3948015
> D3/5: region item: e-w resol:  1
> D3/5: region item: n-s resol:  1
> D3/5: region item: top:1.000
> D3/5: region item: bottom: 0.000
> D3/5: region item: cols3:  1
> D3/5: region item: rows3:  1
> D3/5: region item: depths: 1
> D3/5: region item: e-w resol3: 1
> D3/5: region item: n-s resol3: 1
> D3/5: region item: t-b resol:  1
> D1/5: G_find_raster2(): name=B5 mapset=PERMANENT
> D2/5: G_file_name(): path = /tmp/grassdata/222/PERMANENT/cell/B5
> D2/5: G_file_name(): path = /tmp/grassdata/222/PERMANENT/cellhd/B5
> D2/5: G_file_name(): path = /tmp/grassdata/222/PERMANENT/cellhd/B5
> D2/5:   file open: read (mode = r)
> D2/5: G_file_name(): path = /tmp/grassdata/222/PERMANENT/cellhd/B5
> D2/5: G_file_name(): path = /tmp/grassdata/222/PERMANENT/cellhd/B5
> D2/5:   file open: read (mode = r)
> D2/5: G_file_name(): path = /tmp/grassdata/222/PERMANENT/cellhd/B5
> D2/5: G_file_name(): path = /tmp/grassdata/222/PERMANENT/cellhd/B5
> D2/5:   file open: read (mode = r)
> D2/5: G__read_Cell_head
> D2/5: G__read_Cell_head_array
> D3/5: region item: proj:   1
> D3/5: region item: zone:   32
> D3/5: region item: north:  3948015
> D3/5: region item: south:  3716085
> D3/5: region item: east:   841215
> D3/5: region item: west:   613785
> D3/5: region item: cols:   7581
> D3/5: region item: rows:   7731
> D3/5: region item: e-w resol:  30
> D3/5: region item: n-s resol:  30
> D3/5: region item: format: 1
> D3/5: region item: compressed: 2
> D1/5: G_find_raster2(): name=B5 mapset=PERMANENT
> D2/5: G_file_name(): path = /tmp/grassdata/222/PERMANENT/cell/B5
> D2/5: G_file_name(): path = /tmp/grassdata/222/PERMANENT/fcell/B5
> D2/5: G_file_name(): path = /tmp/grassdata/222/PERMANENT/g3dcell/B5
> D1/5: G_find_raster2(): name=B5 mapset=PERMANENT
> D2/5: G_file_name(): path = /tmp/grassdata/222/PERMANENT/cell/B5
> D1/5: G_find_raster2(): name=B5 mapset=PERMANENT
> D2/5: G_file_name(): path = /tmp/grassdata/222/PERMANENT/cell/B5
> D2/5: G_file_name(): path = /tmp/grassdata/222/PERMANENT/fcell/B5
> D2/5: G_file_name(): path = /tmp/grassdata/222/PERMANENT/g3dcell/B5
> D2/5: G_file_name(): path = /tmp/grassdata/222/PERMANENT/cell/B5
> D2/5: G_file_name(): path = /tmp/grassdata/222/PERMANENT/cell/B5
> D3/5: create window mapping (841215 columns)
> D1/5: G_find_raster(): name=MASK mapset=PERMANENT
> D2/5: G_file_name(): path = /tmp/grassdata/222/PERMANENT/cell/MASK
> D1/5: G_find_raster2(): name=B5@PERMANENT mapset=
> D2/5: G_file_name(): path = /tmp/grassdata/222/PERMANENT/cell/B5
> D2/5: G_file_name(): path = /tmp/grassdata/222/PERMANENT/fcell/B5
> D2/5: G_file_name(): path = /tmp/grassdata/222/PERMANENT/g3dcell/B5
> D1/5: G_find_raster(): name=B5@PERMANENT mapset=
> D2/5: G_file_name(): path = /tmp/grassdata/222/PERMANENT/cell/B5
> D2/5: G_file_name(): path = /tmp/grassdata/222/PERMANENT/colr2/PERMANENT/B5
> D2/5: G_file_name(): path = /tmp/grassdata/222/PERMANENT/colr/B5
> D2/5: G_file_name(): path = /tmp/grassdata/222/PERMANENT/colr/B5
> D2/5:   file open: read (mode = r)
> D3/5: adding rule 0=0.00 0 0 0  34457=34457.00 255 255 255
> D1/5: G_find_raster2(): name=B4 mapset=PERMANENT
> D2/5: G_file_name(): path = /tmp/grassdata/222/PERMANENT/cell/B4
> D2/5: G_file_name(): path = /tmp/grassdata/222/PERMANENT/cellhd/B4
> D2/5: G_file_name(): path = /tmp/grassdata/222/PERMANENT/c

Re: [GRASS-user] t.register: ERROR: day is out of range for month

[Sören Gebbert]

Hi,
the problem is that the model year has 360 days, ignoring the
Gregorian calendar that is the based on absolute time in GRASS. Hence,
the 29. and 30. February do not exist in 1951.

You can use relative time with a daily resolution, so you don't have
to to deal with Gregorian calendar time.

t.create temporaltype=relative ...

t.register start=0 increment=1 unit="day" ...

Best regards
Soeren

2015-02-04 5:27 GMT+01:00 RichardCooper :
> Apologies for re-posting, but I noticed that much of the post's content
> disappeared in the email.
>
> Also, as an update I tried to add both a start and end date to the input
> file (following the t.register manual) but still get the same error on
> running t.register:
>
> ERROR: day is out of range for month
> ERROR: Unable to convert string "1951-02-29"into a datetime object
>
> The process in more detail:
> Aim: to process and analyse a 360 day (30 day/month) climate database
>
> t.create --overwrite output=cahpa05216fgh_stvds type=stvds semantictype=max
> title="cahpa_05216fgh_prcp_stvds" description="CAHPA05216 for MAPSETfgh
> Precipitation STVDS"
>
> t.register --overwrite input=test_stvds type=vector
> file=/home/rcooper/glist_fgh_vectors.out
> Gathering map information...
> ERROR: day is out of range for month
> ERROR: Unable to convert string "1951-02-29"into a datetime object
>
>
> Sample of 360 day file input to t.register:
> ...
> bnd_cahpa_f1jan_05216_nc_remapped_nc_28|1951-01-28
> bnd_cahpa_f1jan_05216_nc_remapped_nc_29|1951-01-29
> bnd_cahpa_f1jan_05216_nc_remapped_nc_30|1951-01-30
> bnd_cahpa_f1feb_05216_nc_remapped_nc_1|1951-02-01
> bnd_cahpa_f1feb_05216_nc_remapped_nc_2|1951-02-02
> bnd_cahpa_f1feb_05216_nc_remapped_nc_3|1951-02-03
> ...
> bnd_cahpa_f1feb_05216_nc_remapped_nc_28|1951-02-28
> bnd_cahpa_f1feb_05216_nc_remapped_nc_29|1951-02-29
> bnd_cahpa_f1feb_05216_nc_remapped_nc_30|1951-02-30
> bnd_cahpa_f1mar_05216_nc_remapped_nc_1|1951-03-01
> bnd_cahpa_f1mar_05216_nc_remapped_nc_2|1951-03-02
> bnd_cahpa_f1mar_05216_nc_remapped_nc_3|1951-03-03
> bnd_cahpa_f1mar_05216_nc_remapped_nc_4|1951-03-04
> ...
>
> GRASS version: 7.0.0svn
> GRASS SVN Revision: 64042
> Build Date: 2015-01-10
> Build Platform: i686-pc-linux-gnu
> GDAL/OGR: 1.11.1
> PROJ.4: 4.9.0
> GEOS: 3.4.2
> SQLite: 3.7.9
> Python: 2.7.3
> wxPython: 2.8.12.1
> Platform: Linux-3.2.0-31-generic-pae-i686-with-LinuxMint-13-maya
>
>
>
>
>
>
> --
> View this message in context: 
> http://osgeo-org.1560.x6.nabble.com/t-register-ERROR-day-is-out-of-range-for-months-tp5185155p5185370.html
> Sent from the Grass - Users mailing list archive at Nabble.com.
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] 10day accumulation which t.rast module to use?

[Sören Gebbert]

Hi Maning,
i think that the combination of t.rast.aggreagte and the new
t.rast.algebra will help you here. Be aware that you will need the
latest grass7.1 trunk version for this.

First you need to compute the daily rainfall sum with
t.rast.aggregate. All 3h map layer that are temporally contained in
the 1 day granule are summed up:

t.rast.aggregate input=3hr_rainrate output=prec1d method=sum
granularity="1 day" basename=prec1d sampling=contains

Then you need to use a temporal moving window of 9 day size in the
past (including the current layer that will be 10 map layers). The
granularity is one day so we can use the temporal neighbor index to
address the past map layers. Be aware that the "result" strds will
only contain map layers that have 9 map layers in the past:

t.rast.algebra basename="10d_acc" expression="result = prec1d[0] +
prec1d[-1] + ... + prec1d[-9]"


The temporal raster algebra module is very experimental, but i hope
that this will work.

Best regards
Soeren

ps.: The code is untested

2014-12-04 3:47 GMT+01:00 maning sambale :
> Dear Vero,
>
> Thanks for the reply.  But t.rast.aggregate does not do what I intend
> to do.  My rainrate is from a span of 20 days.
> t.rast.aggregate produces (as expected) two rasters, one for each of
> the 10day accumulation.  What I want for example is like a moving sum,
> where for each day, it calculates the sum for the past 10 days.
>
> On Thu, Dec 4, 2014 at 4:31 AM, Veronica Andreo  wrote:
>> Hi Emmanuel,
>>
>>> Hi,
>>>
>>> I have 3hourly rainrate data for a given region in a GRASS temporal
>>> database (strds).
>>>
>>> I want to aggregate the data by summing all raster from the previous
>>> 10 days to calculate the accumulated rainfall.
>>> The temporal modules have several tools:
>>> t.rast.series
>>> t.rast.accumulate
>>> t.rast.aggregate
>>> t.rast.mapcalc
>>>
>>> >From the manual, the appropriate module seems to be t.rast.accumulate
>>> but it does not have sum in the method parameters. Currently, I'm
>>> running several r.series commands for each day like below:
>>>
>>> r.series input=\
>>> "`t.rast.list input=3hr_rainrate where=\
>>> "('${DATE} 00:00:00' >= datetime(start_time, '3 hours')) \
>>> and ('${DATE} 00:00:00' <= datetime(start_time, '10 days')) " \
>>> col=name method=comma`" \
>>> output="test_2014-07-20" method=sum
>>>
>>> Then, register each layer in another strds:
>>>
>>> #Create a new STRDS
>>> t.create output='10day_accumulation' type='strds' temporaltype='absolute'
>>> \
>>> title='10day_accumulation' \
>>> description="10 day rainfall accumulation"
>>>
>>>
>>> g.mlist type='rast', pattern='test*', separator=','
>>>
>>> #Register the r.series output to the strds
>>> t.register -i type=rast input=10day_accumulation \
>>> start="2014-07-10 00:00:00" increment="1 days" separator="," \
>>> maps="`g.mlist type='rast', pattern='test*', separator=','`"
>>>
>>>
>>> Is there another approach using directly any of the t.rast.* modules.
>>> For a time-line visualization, here's what I want to do:
>>> https://dl.dropboxusercontent.com/u/2096185/sample_accumulation.png
>>>
>>> Thanks!
>>
>> If i understood right, something like
>>
>> t.rast.aggregate input=3hr_rainrate output=10day_rain basename=10day_rain
>> granularity='10 days' method=sum
>>
>> should do the what you need.
>>
>> HTH,
>>
>> Vero
>
>
>
> --
> cheers,
> maning
> --
> "Freedom is still the most radical idea of all" -N.Branden
> wiki: http://esambale.wikispaces.com/
> blog: http://epsg4253.wordpress.com/
> --
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Computing major and minor axes for polygons

[Sören Gebbert]

Hi Ben,

2014-11-24 22:50 GMT+01:00 Benjamin Ducke :
> Right, a PCA of the polygon vertices, I assume?

Exactly, create a covariance matrix from the vertices coordinates of
each polygon
and compute the eigenvectors and eigenvalues of these matrices.

Best regards
Soeren

> Maybe "v.to.db" could be enhanced to allow it to upload
> the lengths of the first two/three components to the
> attribute table?
>
> For a quick fix, I solved the problem in a shell script using
> a crude approximation. FWIW:
> 0. Set major axis length=-1
> 1. Rotate polygon by 10° (v.transform)
> 2. Fit region to polygon (g.region vect=).
> 3. Get width of region. If it is greater than major axis length,
>set "major axis length = width"
> 4. Repeat from 1, until polygon has been rotated 350°
> 5. Minor axis length = height of current region.
>
> Like I said, it's just a crude approximation (precision can
> be increased by using smaller rotation steps) and slow, too.
> But it's good enough for my purposes, which is basically to
> calculate "elongation=len(major)/len(min)".
>
> Best,
>
> Ben
>
> On 24/11/14 19:27, Sören Gebbert wrote:
>> IIRC is the code to compute the major and minor axes already in GRASS.
>> You need to perform a Karhunen-Loewe-Transformation for each Polygon.
>> This is also known as principal components analysis.
>>
>> Best regards
>> Soeren
>>
>> Am 21.11.2014 23:33 schrieb "Benjamin Ducke" > <mailto:bendu...@fastmail.fm>>:
>>
>> Hi All --
>>
>> Does anybody here know of an existing GRASS modules that
>> will compute the major and minor axes for the polygons of
>> a vector map?
>>
>> Thanks and best,
>>
>> Ben
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org <mailto:grass-user@lists.osgeo.org>
>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>
>
>
>
> --
> Dr. Benjamin Ducke
> {*} Geospatial Consultant
> {*} GIS Developer
>
> Spatial technology for the masses, not the classes:
> experience free and open source GIS at http://gvsigce.org
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Computing major and minor axes for polygons

[Sören Gebbert]

IIRC is the code to compute the major and minor axes already in GRASS. You
need to perform a Karhunen-Loewe-Transformation for each Polygon. This is
also known as principal components analysis.

Best regards
Soeren
Am 21.11.2014 23:33 schrieb "Benjamin Ducke" :

> Hi All --
>
> Does anybody here know of an existing GRASS modules that
> will compute the major and minor axes for the polygons of
> a vector map?
>
> Thanks and best,
>
> Ben
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] t.rast.mapcalc error

[Sören Gebbert]

Hi Veronica,
i have tested the strds/map comparison and it works for me with the
latest grass7.1 build. Can you please check if the max_my_strds map
exists and has valid values and that all maps in the strds exists and
have valid values?

Best regards
Soeren

2014-07-27 23:24 GMT+02:00 Veronica Andreo :
> Hi Soeren, Markus and list,
>
> I'm having trouble with t.rast.mapcalc... these are the commands I'm using:
>
> # get the max value for each pixel in the strds
> t.rast.series input=my_strds method=maximum output=max_my_strds
>
> # then, i need to compare all values in the strds with the map of maximums
> and whenever it's the same value, save the start_doy, otherwise null
> t.rast.mapcalc -n inputs=my_strds output=date_max_my_strds \
> expression="if(my_strds == max_my_strds,start_doy(),null())"
> basename=date_max_my_strds
>
> # to get a map with dates of maximum values afterwards
> t.rast.series input=date_max_my_strds method=maximum
> output=series_date_max_my_strds
>
> This is the error I'm getting in newly compiled GRASS 7
>
> Start temporal sampling
> Start mapcalc computation
> Invalid map 
> Parse error
> ERROR: parse error
> ERROR: Error while mapcalc computation
>
> However, when i follow the exact same steps, but using an older map of
> maximums (created a month ago or so), it works just fine... that's the only
> difference i've found... this used to work a couple of weeks ago...
>
> Am I doing something wrong? Or is it no longer possible to compare all maps
> in strds with a single map??? Please, help!
>
> Thanks much in advance!
>
> Best,
> Vero
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] t.rast.list use

[Sören Gebbert]

Hi Veronica,
sorry for the late response.

You can use the datetime[1] functionality of sqlite to perform this
task, this should work for Jannuary:

t.rast.list input=cla_null_mayor65 where='start_time >=
datetime(start_time, "start of year") and start_time <=
datetime(start_time, "start of year", "1 month")'

[1] https://www.sqlite.org/lang_datefunc.html

Best regards
Soeren

2014-06-17 20:40 GMT+02:00 Veronica Andreo :
> Hi list!
>
> I have a strds with 506 maps that correspond to 8-day composite products (11
> years).
>
> I want to get the list of maps where start_month is january, february and so
> on... to use as input in r.series (or t.rast.series), but i'm not finding
> the way to do that...
>
> i don't want to aggregate maps by month, i need to use the original maps
> belonging to each month... is there a way to obtain that (aside from
> manually :P)??
>
> Till now the only query that has worked in the desired direction is:
>
> t.rast.list input=cla_null_mayor65 where="start_time >= '2003-01' and
> start_time <= '2003-02'"
>
> cla_null_mayor65_1|clorofila|2003-01-01 00:00:00|2003-01-09 00:00:00
> cla_null_mayor65_2|clorofila|2003-01-09 00:00:00|2003-01-17 00:00:00
> cla_null_mayor65_3|clorofila|2003-01-17 00:00:00|2003-01-25 00:00:00
> cla_null_mayor65_4|clorofila|2003-01-25 00:00:00|2003-02-02 00:00:00
>
> but that's only for january 2003... and i would need january 2004, 2005...
> 2013 in the same list... when i add more clauses to the "where" query it
> stops working...
>
> What would be the right approach here?
>
> THANKS MUCH IN ADVANCE!
>
> Best,
> Vero
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] question about t.rast.aggregate

[Sören Gebbert]

Hi,

2014-07-10 18:34 GMT+02:00 Veronica Andreo :
> Hi list!
>
> Quick question (hopefully ;P)

Quick answer: If you specify a granularity of a year, then the start
time to perform the aggregation will always be shifted to the 1.
January of the current year and the end time the 1. January of the
next year (eg. 2002-01-01 - 2003-01-01).  If you wish to aggregate a
full year but shifting one month forward then simply use a granularity
of 12 months.

Best regards
Soeren

>
> I need to aggregate a strds with a granularity of 1 year, but shifting the
> start day one month in each run, i.e.: changing the start_time to
> 2003-02-01, 2003-03-01, 2003-04-01 and so on...
>
> My question is: if i recursively change start_time with the 'where'
> parameter, will the module t.rast.aggregate "aggregate" to the next
> february, march, april (what i'd wish) or just till the end of 2003
>
> Thanks much!!
>
> Best,
> Vero
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] t.rast.mapcalc for interpolate nulls

[Sören Gebbert]

Hi Diana,
you can try t.rast.mapcalc2 for interpolation:

In case A is your space time dataset of choice, then the expression to
interpolate null() cells
in A is:

t.rast.mapcalc2 --v expression="B = if(isnull(A), (A[-1] + A[1])/2.0, A)" base=b


B is the new space time datasets that will have interpolated values at
null() positions (in case there was data in the predecessor and
successor).

Be aware that t.rast.mapcalc2 is highly experimental. You have to
install the PLY Python module to get it to work.


Best regards
Soeren

2014-05-20 16:38 GMT+02:00 Diana Brito :
> Hi list!
>
> I have a problem with de mannagment of nulls values, i have a termporal
> serie of lst daily (MODIS), i want to interpolate each image in order to
> estimate de values of the nulls cells, I want to get the value of the null
> cell, by averaging the same position in xy but the previous time and the
> next, i don´t have any idea how to indicate the position of the null cell
> neither the way to calculate the average.
>
> Is it possible to do this with t.rast.mapcalc? how? another function?
>
> I,m using grass71
>
> thanks for your help in adnvance
> --
> Diana Marcela Brito Hoyos
> Biologa
> d.br...@javeriana.edu.co
>
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Continuously updating space time datasets

[Sören Gebbert]

Hi Stefan,

2014-04-29 18:11 GMT+02:00 Blumentrath, Stefan :
> Hi,
>
> I am trying to (re-) organize some of our climate data based on continuously 
> updated daily time series in the TGRASS framework which I plan to update in 
> chron-jobs.
>
> My question is, is there a recommended approach for updating existing 
> (aggregated) time series.
>
> I see mainly two different scenarios,
> 1) new maps may be added at the end of (aggregated) time series (e.g. monthly 
> temperature for new month aggregated from daily temperature raster) and

You can add new maps with un-ordered time stamps to a space time
datasets anytime, it is simply an entry in a database. The temporal
correct ordering is performed in case of a select query.

> 2) existing maps may be replaced for datasets which have been modified (e.g. 
> updated MODIS tiles) after a time series has been created.

You can overwrite existing maps and update the space time datasets in
which they are registered with t.support.

>
>  Am I right that 1) would require
> a) to simply to register new raw data (e.g. new days with temperature data) 
> while I
> b) would have to create a temporary time series which I use for aggregating, 
> for so being able to register the new aggregated maps to the monthly time 
> series?

Yes, that's the approach i would suggest.

> In order to avoid naming conflicts I would also have to use temporary names, 
> which I then can rename according to target
series, since new maps created with t.rast.aggregate will start with 0 again?

Yes, they will start with _0 again.

> Btw. is there a possibility to use e.g. start dates instead of the sequence 
> 0,1,2 ... (this would also make map names more intuitive)? In any case I 
> would like to avoid to update many years when I get new data only for a few 
> new month or weeks. So I am grateful for any hint in this direction.

Sure, you can simply add an option to t.rast.aggregate to start with a
specific offset when numbering the maps. The code shouldn't be to hard
to understand.

>
> For 2) changes can happen across the entire time series and for single time 
> periods (single days or weeks).  In this case I would have to unregister 
> outdated maps first and then proceed like in 2. Only that - for aggregated 
> time series - I would have to do so for every time period of a space time 
> data set which contains underlying modified data, right?

Right.You have to unregister outdated maps, unless the new maps have
exactly the same time stamp, then you can overwrite them and update
the space time dataset with t.support.

But you can also remove the outdated maps, add new maps and run
t.support to automatically detect removed maps and to update the space
time dataset.

>
> I hope my problem / aim is understandable and my approach is to some degree 
> reasonable. However, I wished there was a more elegant / efficient solution 
> for that?

I hope i could give a meaningful answer.

Best regards
Soeren

btw.
Please use the latest svn version of grass7.1. I made some performance
improvements at the end of last year so that the sqlite and postgresql
backends should work much faster with tens of thousands of maps.



>
> Thanks in advance.
> Stefan
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] invalid temporal topology

[Sören Gebbert]

Hi Martin,
you can inspect the temporal topology using "g.gui.timeline" or you
pipe the output of "t.topology -m input=STDS" into a file and search
for the temporal relationships that should not occur in a valid
temporal topology (only precedes, follows, before, and after are valid
relations). All temporal relationships that occur in a STDS are
counted and shown by "t.topology input=STDS".

Best regards
Soeren

2014-04-22 21:21 GMT+02:00 Martin Landa :
> Hi,
>
> 2014-04-22 20:28 GMT+02:00 Martin Landa :
>
> OK, solved - missing time in timestamps, anyway the module should
> print to the user reason of invalidity...
>
> Martin
>
> --
> Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] t.rast.aggregate

[Sören Gebbert]

Hi Veronica,

2014-04-01 16:07 GMT+02:00 Veronica Andreo :
> Hi Soeren,
>
> 2014-03-31 13:05 GMT-03:00 Sören Gebbert :
>> Hi Veronica,
>> you can use t.rast.series for this kind of task. Use a SQL expression
>> to select only specific months of a year. Please try this code
>> (untested, may contain errors):
>>
>> # January averages
>> t.rast.series input=monthly_aggregates \
>> output=jan_average method=average \
>> where="start_time = datetime(start_time, 'start_of_year', '0 month')"
>
> Thanks so much for your help! Worked perfectly just removing the
> underscore in 'start of year'

Ooops, sorry for the underscore's.

>
> Have one question though: is there a way to check which maps were used
> to estimate the average (or whatever operation t.rast.series perform)?
> Is that information stored somewhere? or is there a way to check prior
> to t.rast.series??

You can use the same SQL expression in any other temporal command that
support SQL where expressions. For example t.rast.list:

{{{
t.rast.list input=precipitation_1950_2013_monthly_mm@soeren
where="start_time = datetime(start_time, 'start of year', '0 month')"

precipitation_monthly_mm_0 soeren 1950-01-01 00:00:00 1950-02-01 00:00:00
precipitation_monthly_mm_12 soeren 1951-01-01 00:00:00 1951-02-01 00:00:00
...
precipitation_monthly_mm_732 soeren 2011-01-01 00:00:00 2011-02-01 00:00:00
precipitation_monthly_mm_744 soeren 2012-01-01 00:00:00 2012-02-01 00:00:00
precipitation_monthly_mm_756 soeren 2013-01-01 00:00:00 2013-02-01 00:00:00
}}}


Best regards
Soeren

>
> Thanks again!
> Best,
>
> Vero
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] t.rast.aggregate

[Sören Gebbert]

Hi Veronica,
you can use t.rast.series for this kind of task. Use a SQL expression
to select only specific months of a year. Please try this code
(untested, may contain errors):

# January averages
t.rast.series input=monthly_aggregates \
output=jan_average method=average \
where="start_time = datetime(start_time, 'start_of_year', '0 month')"

# February averages
t.rast.series input=monthly_aggregates \
output=feb_average method=average \
where="start_time = datetime(start_time, 'start_of_year', '1 month')"

# March averages
t.rast.series input=monthly_aggregates \
output=mar_average method=average \
where="start_time = datetime(start_time, 'start_of_year', '2 month')"

...


Best regards
Soeren

2014-03-31 17:43 GMT+02:00 Veronica Andreo :
> Hi all,
>
> I have this MODIS time series of 8-day composite of chlorophyll
> concentration from 2003 to 2013. I've already aggregated it by month
> (average), so from 506 images I now have 132 (12 x year, 11 years)
>
> but what I need doing now is to aggregate months over the years, what
> i want are 12 summary images (one for each month over the 11 years).
> How do i do that with t.rast.aggregate?
>
> Thanks a lot in advance! And CONGRATULATIONS on GRASS 7 release!! :)
>
> Vero
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] DOY support in t.register?

[Sören Gebbert]

Hi Veronica,

2014-03-05 20:49 GMT+01:00 Veronica Andreo :
> Dear list
>
> I'm working with ocean color data set from MODIS and starting to use t.*
> modules... I'm trying now to register the strds and as i'm working with
> 8-day products i specified start date as 2003-01-01 and interval as 8 days
> for a list of 506 maps. The time series should end by 2013-12-31 and t.info
> says
>
> ...
>  + Absolute time
> -+
>  | Start time:. 2003-01-01 00:00:00
>  | End time:... 2014-01-31 00:00:00
>  | Granularity: 8 days
>  | Temporal type of maps:.. interval
> 

Using Python shows that in case of an 8 day's interval, the end date
is computed correctly:

{{{
import datetime
print datetime.datetime(2003,1,1) + datetime.timedelta(506*8)
2014-01-31 00:00:00
}}}


> The problem arise because all products at the end of the year don't really
> cover an 8-days period... So, i understand i should add starting and ending
> date to each file in the list i use as input for t.register... Question is:
> Is it possible to use DOY instead of dates?? or what would be a (reasonably)
> easy way of transforming DOY in map names (for example:
> A20030732003080.L3m_8D_CHL_chlor_a_4km_arg) into the corresponding dates

So your time series has unequal time intervals? I would suggest to use
a single input file that lists all maps with time stamps as input for
a single t.register call.
DOY is not supported by t.register. I would suggest that you use the
following Python code to extract the exact start and end time from the
map names:

{{{
import datetime

#   012345678901234567890123456789012345678901
map_name = "A20030732003080.L3m_8D_CHL_chlor_a_4km_arg"
start_year = int(map_name[1:5])
start_day  = int(map_name[5:8])
end_year   = int(map_name[8:12])
end_day= int(map_name[12:15])

start = datetime.datetime(start_year, 1, 1) + datetime.timedelta(start_day - 1)
end = datetime.datetime(int(end_year), 1, 1) + datetime.timedelta(end_day - 1)

print map_name, "|", start, "|", end

}}}

Write each map name with start and end time into one file (a single
map name with start and end time each line) and register all maps at
once with "t.register input=my_strds file=my_maps.txt".

Best regards
Soeren

>
> Thanks a lot in advance!
>
> Best,
> Vero
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] help with temporal modules

[Sören Gebbert]

Dear Veronica,
it seems that the temporal database in the location that you use has
been created with an older version of grass7. I have modified grass7
in the last months to increase performance and reliability of the
temporal framework and therefore changed the database format. The new
API is not backward compatible.

Can you please create a fresh location from scratch with the latest
grass7 svn version? In case you want to use the same location, then
please make a backup of the existing  temporal database (in case you
have already data registered), by simple renaming it:

mv /home/veroandreo/grassdata//ll_wgs84/PERMANENT/tgis/sqlite.db \
 /home/veroandreo/grassdata//ll_wgs84/PERMANENT/tgis/sqlite.db.backup

A new temporal database with the same name will be created, when you
invoke any temporal command. You can access any data in the old
database using a sqlite client application, or open office. You will
need to install the grass7 svn version from August 2013, to use the
old temporal database within grass7.

Best regards
Soeren

2014-02-28 21:07 GMT+05:30 Veronica Andreo :
> Dear grass-users,
>
> HI! This is my first time writing to the list. I'm really interested in
> using the temporal modules for some spatio-temporal analysis of MODIS Cl-a
> mapped L3 product, but i can't even run the example in t.create manual page
> [0]. I'm using GRASS 7 (r59147, re-compiled yesterday) under Fedora 19.
>
> I'd like to know which are the steps I should follow to start working with
> these modules??? Do I need to install some extra package or library???
> Here's what I've tried and the messages I got:
>
> GRASS 7.0.svn (ll_wgs84):~ > t.connect -d
> Default driver / database set to:
> driver: sqlite
> database: /home/veroandreo/grassdata//ll_wgs84/PERMANENT/tgis/sqlite.db
>
> GRASS 7.0.svn (ll_wgs84):~ > t.connect -p
> driver:sqlite
> database:/home/veroandreo/grassdata//ll_wgs84/PERMANENT/tgis/sqlite.db
>
> GRASS 7.0.svn (ll_wgs84):~ > MAPS="map_1 map_2 map_3 map_4 map_5 map_6
> map_7"
> GRASS 7.0.svn (ll_wgs84):~ > for map in ${MAPS} ; do
>> r.mapcalc --o expr="${map} = rand(0, 10)"
>> echo ${map} >> map_list.txt
>> done
>
>  it creates the maps, of course, but then...
>
> GRASS 7.0.svn (ll_wgs84):~ > t.create type=strds temporaltype=absolute
> output=precipitation_daily title="Daily precipitation" description="Test
> dataset with daily precipitation"
> ERROR: Unable to receiving temporal database metadata.
> Current temporal database info:
> DBMI interface:. sqlite3
> Temporal database:..
> /home/veroandreo/grassdata//ll_wgs84/PERMANENT/tgis/sqlite.db
>
> GRASS 7.0.svn (ll_wgs84):~ > t.register -i type=rast
> input=precipitation_daily file=map_list.txt start=2012-08-20 increment="1
> days"
> ERROR: Unable to receiving temporal database metadata.
> Current temporal database info:
> DBMI interface:. sqlite3
> Temporal database:..
> /home/veroandreo/grassdata//ll_wgs84/PERMANENT/tgis/sqlite.db
>
> GRASS 7.0.svn (ll_wgs84):~ > t.info type=strds input=precipitation_daily
> ERROR: Unable to receiving temporal database metadata.
> Current temporal database info:
> DBMI interface:. sqlite3
> Temporal database:..
> /home/veroandreo/grassdata//ll_wgs84/PERMANENT/tgis/sqlite.db
>
> I've noticed there are 2 slashes in
> "/home/veroandreo/grassdata//ll_wgs84/PERMANENT/tgis/sqlite.db" --> tried
> changing that by defining it with t.connect, but when i run the example
> gain, I got the same messages as before...
>
> What am I doing wrong? or what am I lacking here??? Would you please help
> me???
>
> THANKS A LOT IN ADVANCE!
> And sorry for making (surely) a very silly question :P
>
> Vero
>
> [0] http://grass.osgeo.org/grass70/manuals/keywords.html
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] [GRASS-dev] Major changes in the temporal framework

[Sören Gebbert]

Hi Luca,

2013/12/30 Luca Delucchi :
> On 28 December 2013 03:33, Sören Gebbert  wrote:
>> Hi Luca,
>
> Hi Soeren
>
>> i will try to support your suggestion. I will introduce two GRASS
>> variables to be set via g.gisenv.
>>
>> Use:
>>
>> g.gisenv set="TGIS_DISABLE_MAPSET_CHECK=True"
>> g.gisenv set="TGIS_DISABLE_TIMESTAMP_WRITE=True"
>>
>> to disable the mapset check and the writing of the timestamps of each
>> map to the map metadata
>> in the spatial database as text files. You can set these variables
>> mapset specific.
>> Settings these variables "True" should (hopefully, because untested)
>> allow the registration of maps outside the current mapset, even if you
>> do not have the permission to modify the maps.
>>
>> A warning will be printed if these variables are set True.
>>
>
> this seams really cool, I'll test it when it will be on svn
>
>> BUT, be aware that this feature can lead to the corruption of the
>> temporal database and
>> unwanted side effects. You can mess up the temporal database if you
>> are not 100% sure what you are doing.
>
> can you specify a little bit more what can be the problems?

There are no tests yet that assure the correct function of this
feature and honestly i don't know what the side effects will be for
any circumstances, since the principle design is that space time
datasets are mapset specific, which is well tested and supported. :)

>
>> It is no longer possible to access the timestamp information of these
>> maps using the C-libraries, because
>> the timestamp information is not available in the map metadata text files.
>>
>
> sure ;-)

Well, unless you already set the timestamps using the C-library
functions or *.timestamp modules before.


Best regards
Soeren

>
>>
>> Best regards
>> Soeren
>>
>
> Thanks a lot
>
> --
> ciao
> Luca
>
> http://gis.cri.fmach.it/delucchi/
> www.lucadelu.org
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Major changes in the temporal framework

[Sören Gebbert]

Dear all,
just for your information:

I will commit several modification to the temporal framework (grass7
trunk) in a few minutes. :)

The modifications are not backward compatible, hence existing temporal
databases, independently from the used backend (sqlite or postgresql)
WILL NOT WORK with the new framework.

The modifications:
- Removed the creation of a register table for each registered map,
which speeds things up massively
- Added modification time to space time datasets
- Added aggregation type to space time datasets that will be set by
t.rast.aggregate
- Keeping the SQL scripts as simple as possible
- Removed foreign primary keys and created indexes for primary keys in
sqlite3 (postgreql does this automagically)
- Using delete trigger instead of foreign primary keys in postgresql backend
- Removed unneeded SQL scripts
- Using Python dateutil module for time string parsing if installed,
or a much more simpler parser without time zone support
- Added GRASS environmental variables to allow registration of maps
from different mapsets in a space time dataset
- Simplified code for map registration
- Code cleanup ...


Best regards
Soeren



2013/12/22 Sören Gebbert :
> Dear all,
> just for your information:
>
> I will commit several modification to the temporal framework (grass7
> trunk) in the next weeks, that will change the SQL database layout and
> the API. The goal is to make the temporal frameworks SQL database
> interaction much faster, reducing the number of tables to scale better
> with tens of thousand of maps, improving the PostgreSQL
> compatibility/performance and make it better maintainable.
>
> The changes will result in backward incompatibility. Hence, the new
> framework will not work with existing temporal databases. The changes
> are too drastic to provide backward compatibility. I will introduce
> new tables and columns and completely remove the creation of tables
> for each registered map. I will remove several functions from the API
> and introduce new classes and functions. To get an idea of the changes
> have a look at [2].
>
> Please use the export tools (t.rast.export and t.vect.export) to
> transfer your temporal data into the new temporal database, or simply
> use t.*.list[1] tools to create text files that can be used for
> re-registering of raster, vector and voxel maps in the new temporal
> framework.
>
> I will inform you before the first commit that will introduce the
> incompatibility.
>
> Best regards
> Soeren
>
> [1] "t.rast.list input=my_strds columns=name,start_time,end_time > 
> map_list.txt"
> [2] http://pastebin.de/38117
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] [GRASS-dev] Major changes in the temporal framework

[Sören Gebbert]

Hi Luca,
i will try to support your suggestion. I will introduce two GRASS
variables to be set via g.gisenv.

Use:

g.gisenv set="TGIS_DISABLE_MAPSET_CHECK=True"
g.gisenv set="TGIS_DISABLE_TIMESTAMP_WRITE=True"

to disable the mapset check and the writing of the timestamps of each
map to the map metadata
in the spatial database as text files. You can set these variables
mapset specific.
Settings these variables "True" should (hopefully, because untested)
allow the registration of maps outside the current mapset, even if you
do not have the permission to modify the maps.

A warning will be printed if these variables are set True.

BUT, be aware that this feature can lead to the corruption of the
temporal database and
unwanted side effects. You can mess up the temporal database if you
are not 100% sure what you are doing.
It is no longer possible to access the timestamp information of these
maps using the C-libraries, because
the timestamp information is not available in the map metadata text files.


Best regards
Soeren

2013/12/28 Luca Delucchi :
> On 22 December 2013 00:07, Sören Gebbert  wrote:
>> Dear all,
>
> Hi Soeren,
>
>> just for your information:
>>
>> I will commit several modification to the temporal framework (grass7
>> trunk) in the next weeks, that will change the SQL database layout and
>> the API. The goal is to make the temporal frameworks SQL database
>> interaction much faster, reducing the number of tables to scale better
>> with tens of thousand of maps, improving the PostgreSQL
>> compatibility/performance and make it better maintainable.
>>
>
> these changes could be useful for create temporal dataset using maps
> outside current mapset?
> this change for my point of view is really important, if you break the
> API could I suggest you add also this "feature" to temporal framework?
>
> Thanks a lot
>
>>
>> Best regards
>> Soeren
>>
>
> --
> ciao
> Luca
>
> http://gis.cri.fmach.it/delucchi/
> www.lucadelu.org
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Major changes in the temporal framework

[Sören Gebbert]

Dear all,
just for your information:

I will commit several modification to the temporal framework (grass7
trunk) in the next weeks, that will change the SQL database layout and
the API. The goal is to make the temporal frameworks SQL database
interaction much faster, reducing the number of tables to scale better
with tens of thousand of maps, improving the PostgreSQL
compatibility/performance and make it better maintainable.

The changes will result in backward incompatibility. Hence, the new
framework will not work with existing temporal databases. The changes
are too drastic to provide backward compatibility. I will introduce
new tables and columns and completely remove the creation of tables
for each registered map. I will remove several functions from the API
and introduce new classes and functions. To get an idea of the changes
have a look at [2].

Please use the export tools (t.rast.export and t.vect.export) to
transfer your temporal data into the new temporal database, or simply
use t.*.list[1] tools to create text files that can be used for
re-registering of raster, vector and voxel maps in the new temporal
framework.

I will inform you before the first commit that will introduce the
incompatibility.

Best regards
Soeren

[1] "t.rast.list input=my_strds columns=name,start_time,end_time > map_list.txt"
[2] http://pastebin.de/38117
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Organizing spatial (time series) data for mixed GIS environments

[Sören Gebbert]

Hi Stefan,
there is a FOSS4G presentation online as well:
http://elogeo.nottingham.ac.uk/xmlui/handle/url/288

Best regards
Soeren

2013/12/4 Sören Gebbert :
> Hi Stefan,
>
> 2013/12/3 Blumentrath, Stefan :
>> Dear all,
>>
>>
>>
>> On our Ubuntu server we are about to reorganize our GIS data in order to
>> develop a more efficient and consistent solution for data storage in a mixed
>> GIS environment.
>>
>> By “mixed GIS environment” I mean that we have people working with GRASS,
>> QGIS, PostGIS but also many people using R and maybe the largest fraction
>> using ESRI products, furthermore we have people using ENIV, ERDAS and some
>> other. Only few people (like me) actually work directly on the server…
>>
>> Until now I stored “my” data mainly in GRASS (6/7) native format which I was
>> very happy with. But I  guess our ESRI- and PostGIS-people would not accept
>> that as a standard…
>>
>>
>>
>> However, especially for time series data we cannot have several copies in
>> different formats (tailor-made for each and every software).
>>
>>
>>
>> So I started thinking: what would be the most efficient and convenient
>> solution for storing a large amount of data (e.g. high resolution raster and
>> vector data with national extent plus time series data) in a way that it is
>> accessible for all (at least most) remote users (with different GIS
>> software). As I am very fond of the temporal framework in GRASS 7 it would
>> be a precondition that I can use these tools on the data without
>> unreasonable performance loss. Another precondition would be that users at
>> remote computers in our (MS Windows) network can have access to the data.
>>
>>
>>
>> In general, four options come into my mind:
>>
>> a)  Stick to GRASS native format and have one copy in another format
>>
>> b)  Use the native formats the data come in (e.g. temperature and
>> precipitation comes in zipped ascii-grid format)
>>
>> c)   Use PostGIS as a backend for data storage (raster / vector) (linked
>> by (r./v.external.*)
>>
>> d)  Use another GDAL/OGR format for data storage (raster / vector)
>> (linked by (r./v.external.*)
>>
>>
>>
>> My question(s) are:
>>
>> What solutions could you recommend or what solution did you choose?
>
> I would suggest to use r.external and uncompressed geotiff files for
> raster data. But you have to make sure that external software does not
> modify these files, or if they do, that the temporal framework is
> triggered to update dependent space time raster datasets.
>
> I would suggest to use the native GRASS format, in case of vector
> data. Hence vector data needs to be copied. But maybe PostgreSQL with
> topology support will be a solution? I think Martin Landa may have an
> opinion here.
>
>>
>> Who is having experience with this kind of data management challenge?
>
> No experience here from my side.
>
>> How do externally linked data series perform compared to GRASS native?
>
> It will be slower than the native format for sure. But i don't know
> how much slower.
>
>>
>>
>> I searched a bit the mailing list and found this:
>> (http://osgeo-org.1560.x6.nabble.com/GRASS7-temporal-GIS-database-questions-td5054920.html)
>> where Sören recommended “postgresql as temporal database backend”. However I
>> am not sure if that was meant only for the temporal metadata and not the
>> rasters themselves…
>
> My recommendation was related to the temporal metadata only. The
> sqlite database will not scale very well for select requests if you
> have more than 30,000 maps registered in your temporal database.
> PostgreSQL will be much faster for select requests. But PostgreSQL
> performs very badly in managing (insert, update, delete) many maps. I
> am not sure what the reason for this is, but from my experience has
> PostgreSQL a scaling problem with many tables. Hence if you do not
> modify you data often, PostgreSQL is your temporal database backend of
> choice. Otherwise i would recommend Sqlite, even if its slower for
> select requests.
>
>> Furthermore in the idea collection for the Temporal framework
>> (http://grasswiki.osgeo.org/wiki/Time_series_development, Open issues
>
> This discussion is pretty old and does not reflect the current
> temporal framework implementation. Please have a look at the new
> TGRASS paper:
> https://www.sciencedirect.com/science/article/pii/S136481521300282X?np=y
> and the Geostat workshop:
> http://geostat-course.org/Topic_Gebbert
>
>> section) limitati

Re: [GRASS-user] Organizing spatial (time series) data for mixed GIS environments

[Sören Gebbert]

Hi Stefan,

2013/12/3 Blumentrath, Stefan :
> Dear all,
>
>
>
> On our Ubuntu server we are about to reorganize our GIS data in order to
> develop a more efficient and consistent solution for data storage in a mixed
> GIS environment.
>
> By “mixed GIS environment” I mean that we have people working with GRASS,
> QGIS, PostGIS but also many people using R and maybe the largest fraction
> using ESRI products, furthermore we have people using ENIV, ERDAS and some
> other. Only few people (like me) actually work directly on the server…
>
> Until now I stored “my” data mainly in GRASS (6/7) native format which I was
> very happy with. But I  guess our ESRI- and PostGIS-people would not accept
> that as a standard…
>
>
>
> However, especially for time series data we cannot have several copies in
> different formats (tailor-made for each and every software).
>
>
>
> So I started thinking: what would be the most efficient and convenient
> solution for storing a large amount of data (e.g. high resolution raster and
> vector data with national extent plus time series data) in a way that it is
> accessible for all (at least most) remote users (with different GIS
> software). As I am very fond of the temporal framework in GRASS 7 it would
> be a precondition that I can use these tools on the data without
> unreasonable performance loss. Another precondition would be that users at
> remote computers in our (MS Windows) network can have access to the data.
>
>
>
> In general, four options come into my mind:
>
> a)  Stick to GRASS native format and have one copy in another format
>
> b)  Use the native formats the data come in (e.g. temperature and
> precipitation comes in zipped ascii-grid format)
>
> c)   Use PostGIS as a backend for data storage (raster / vector) (linked
> by (r./v.external.*)
>
> d)  Use another GDAL/OGR format for data storage (raster / vector)
> (linked by (r./v.external.*)
>
>
>
> My question(s) are:
>
> What solutions could you recommend or what solution did you choose?

I would suggest to use r.external and uncompressed geotiff files for
raster data. But you have to make sure that external software does not
modify these files, or if they do, that the temporal framework is
triggered to update dependent space time raster datasets.

I would suggest to use the native GRASS format, in case of vector
data. Hence vector data needs to be copied. But maybe PostgreSQL with
topology support will be a solution? I think Martin Landa may have an
opinion here.

>
> Who is having experience with this kind of data management challenge?

No experience here from my side.

> How do externally linked data series perform compared to GRASS native?

It will be slower than the native format for sure. But i don't know
how much slower.

>
>
> I searched a bit the mailing list and found this:
> (http://osgeo-org.1560.x6.nabble.com/GRASS7-temporal-GIS-database-questions-td5054920.html)
> where Sören recommended “postgresql as temporal database backend”. However I
> am not sure if that was meant only for the temporal metadata and not the
> rasters themselves…

My recommendation was related to the temporal metadata only. The
sqlite database will not scale very well for select requests if you
have more than 30,000 maps registered in your temporal database.
PostgreSQL will be much faster for select requests. But PostgreSQL
performs very badly in managing (insert, update, delete) many maps. I
am not sure what the reason for this is, but from my experience has
PostgreSQL a scaling problem with many tables. Hence if you do not
modify you data often, PostgreSQL is your temporal database backend of
choice. Otherwise i would recommend Sqlite, even if its slower for
select requests.

> Furthermore in the idea collection for the Temporal framework
> (http://grasswiki.osgeo.org/wiki/Time_series_development, Open issues

This discussion is pretty old and does not reflect the current
temporal framework implementation. Please have a look at the new
TGRASS paper:
https://www.sciencedirect.com/science/article/pii/S136481521300282X?np=y
and the Geostat workshop:
http://geostat-course.org/Topic_Gebbert

> section) limitations were mentioned regarding the number of files in a
> folder, which would be possibly a problem both for file based storage. The
> ext2 file system had “"soft" upper limit of about 10-15k files in a single
> directory” but theoretically many more where possible. Other file systems
> may allow for more I guess… Will usage of such big directories > 10,000
> files lead to performance problems?

Modern file systems should not have problems with many files. I am
using ext4 and the temporal framework with 100.000 maps without
noticeable performance issues.

>
> The “Working with external data in GRASS 7” – wiki entry
> (http://grasswiki.osgeo.org/wiki/Working_with_external_data_in_GRASS_7)
> covers the technical part (and to some degree performance issues) very well.
> Would it be worth adding a part on the strat

Re: [GRASS-user] 3d vector cutting pane for 3d volumes ?

[Sören Gebbert]

Hi Peter,
you can use v.to.rast to create a raster surface from the vector
surface (as Maskus suggested) and then use r.to.rast3elev to fill the
upper volume and the lower volume of a new voxel map with different
values (upper = 1, lower = 2). Then use r3.mapcalc to perform
operations on the upper or lower volume (r3.mapcalc "lower_volume =
if(myvolume == 2, 1, null())").

Best regards
Soeren

2013/10/7 "Peter Löwe" :
> Hi,
> is there a feasible approach in GRASS 6.X or 7.X to apply a 3d vector surface 
> as a cutting pane to split 3D raster volume bodies ?
>
> Best,
> Peter
>
> 
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.neighbors velocity

[Sören Gebbert]

Hi Ivan,

2013/7/17 Ivan Marchesini :
> Dear Soeren, Hamish, Markus M., Markus N,.
> sorry for the delay in the answer but I didn't believe that my question
> could have determined so many answers and I was on holiday for 10 days
> with no way to test your code.
> First of all a quick answer to Markus N.
> My collegue is working on high resolution images and DEMs. In this case,
> in particular, he is working on a 1 meter resolution raster map
> concerning landslides. He said me that, due to the landslides
> dimensions, he need to use a kernel of 501*501 in order to catch the
> "signatures" of the phenomena (I don't know exactly the details.. I'm
> sorry).

I think it will be good if you could ask your colleague for more details,
since we are all very curious about his computational approach.

> I'm not a C developer but reading your e-mails it seems that the
> performances of the C codes (and r.neigbors is written in C) strongly
> depend on the compiler.
> does it mean that compiling in a different way (I don't know how) the
> r.neigbours module we can obtain better results?
>
> We have tested the last code of Soeren in the same machine where the
> proprietary software (it is ENVI 5.x) showed those good performances.

The performance is good indeed. Unfortunately you need to set the
moving windows size from 23 to 501, to receive a comparable result to
the computation of your colleague.

./neighbor 5000 5000 501

This will call the neíghbour computation with 25,000,000 cells and a
moving window with 501x501 pixel.

Best regards
Soeren

> These are the results:
>
> gcc -Wall -fopenmp -lgomp -Ofast main.c -o neighbor
> export OMP_NUM_THREADS=1
> time ./neighbor 5000 5000 23
> real0m16.598s
> user0m16.477s
> sys0m0.080s
>
> export OMP_NUM_THREADS=2
> time ./neighbor 5000 5000 23
> real0m8.977s
> user0m17.573s
> sys0m0.080s
>
> export OMP_NUM_THREADS=4
> time ./neighbor 5000 5000 23
> real0m5.993s
> user0m20.277s
> sys0m0.088s
>
> export OMP_NUM_THREADS=6
> time ./neighbor 5000 5000 23
> real0m4.784s
> user0m25.770s
> sys0m0.096s
>
>
> Many thanks for your answers
>>
>>
>>
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] dbase driver in grass7

[Sören Gebbert]

Hi,


2013/7/4 Hamish 

> Levente wrote:
>
> > I was wondering about re-compiling GRASS7. I don't know if it is
> > possible to compile it with the dbf connection as default.
>
> see include/dbmi.h: #define DB_DEFAULT_DRIVER "sqlite"
> and include/temporal.h: #define TGISDB_DEFAULT_DRIVER "sqlite"
>

The TGISDB_DEFAULT_DRIVER can not be set to dbf. It works only with sqlite
and postgresql (pg). But i am absolutely sure that you do not need to set
the TGIS default driver.

Best regards
Soeren


>
> change to "dbf".
>
>
> > I think that would solve my problem. What do you think?
> > Does it make any sense?
>
> typically just running db.connect early on to set the default database for
> the mapset in the $MAPSET/VAR file is enough. (or pre-seed that VAR file
> into the new mapset dir yourself)
>
>
>
> Hamish
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.neighbors velocity

[Sören Gebbert]

More benchmark results on core i5 2410M 2 cores 4 threads, 8GB RAM:

gcc -Wall -fopenmp -lgomp -O3 main.c -o neighbor
time ./neighbor 5000 5000 23

export OMP_NUM_THREADS=1
real 0m27.052s
user 0m26.882s
sys 0m0.128s

export OMP_NUM_THREADS=2
real 0m15.579s
user 0m30.466s
sys 0m0.124s

export OMP_NUM_THREADS=4
real 0m10.454s
user 0m40.711s
sys 0m0.120s

gcc -Wall -fopenmp -lgomp -Ofast -march=core-avx-i main.c -o neighbor
time ./neighbor 5000 5000 23

export OMP_NUM_THREADS=1
real 0m17.090s
user 0m16.953s
sys 0m0.108s

export OMP_NUM_THREADS=2
real 0m9.957s
user 0m19.437s
sys 0m0.136s

export OMP_NUM_THREADS=4
real 0m7.476s
user 0m28.698s
sys 0m0.124s

opencc -Wall -mp -Ofast -march=auto main.c -o neighbor
time ./neighbor 5000 5000 23

export OMP_NUM_THREADS=1
real 0m19.095s
user 0m18.909s
sys 0m0.152s

export OMP_NUM_THREADS=2
real 0m11.203s
user 0m22.097s
sys 0m0.136s

export OMP_NUM_THREADS=4
real 0m8.648s
user 0m33.670s
sys 0m0.160s

Best regards
Soeren



2013/6/29 Sören Gebbert 

> Hi,
> i have implemented a "real" average neighborhood algorithm that runs in
> parallel using openmp. The source code and the benchmark shell script is
> attached.
>
> The neighbor program computes the average moving window of arbitrary size.
> The size of the map rows x cols and the size of the moving window  (odd
> number cols==rows) can be specified.
>
> ./neighbor rows cols mw_size
>
> IMHO the new program is better for compiler comparison and neighborhood
> operation performance.
>
> This is the benchmark on my 5 year old AMD phenom 4 core computer using 1,
> 2 and 4 threads:
>
> gcc -Wall -fopenmp -lgomp -Ofast main.c -o neighbor
> export OMP_NUM_THREADS=1
> time ./neighbor 5000 5000 23
> real 0m37.211s
> user 0m36.998s
> sys 0m0.196s
>
> export OMP_NUM_THREADS=2
> time ./neighbor 5000 5000 23
> real 0m19.907s
> user 0m38.890s
> sys 0m0.248s
>
> export OMP_NUM_THREADS=4
> time ./neighbor 5000 5000 23
> real 0m10.170s
> user 0m38.466s
> sys 0m0.192s
>
> Happy hacking, compiling and testing. :)
>
> Best regards
> Soeren
>
>
>
>
> 2013/6/29 Markus Metz 
>
>> On Sat, Jun 29, 2013 at 1:26 PM, Hamish  wrote:
>> > Markus Metz wrote:
>> >
>> >> Some more results with Sören's test program on a Intel(R) Core(TM) i5
>> >> CPU M450 @ 2.40GHz (2 real cores, 4 fake cores) with gcc 4.7.2 and
>> >> clang 3.3
>> >>
>> >> gcc -O3
>> >> v is 2.09131e+13
>> >>
>> >> real2m0.393s
>> >> user1m57.610s
>> >> sys0m0.003s
>> >>
>> >> gcc -Ofast
>> >> v is 2.09131e+13
>> >>
>> >> real0m7.218s
>> >> user0m7.018s
>> >> sys0m0.017s
>> >
>> >
>> > nice. one thing we need to remember though is that it's not entirely
>> > free, one thing -Ofast turns on is -ffast-math,
>> > """
>> >  This option is not turned on by any -O option besides -Ofast since it
>> can
>> >  result in incorrect output for programs that depend on an exact
>> >  implementation of IEEE or ISO rules/specifications for math functions.
>> It
>> >  may, however, yield faster code for programs that do not require the
>> >  guarantees of these specifications.
>> > """
>> >
>> > which may not be fit for our purposes.
>> >
>> >
>> > With the ifort compiler there is '-fp-model precise' which allows only
>> > optimizations which don't harm the results. Maybe gcc has something
>> > similar.
>>
>> In gcc, you can turn of -ffoo with -fno-foo, maybe this way you can
>> use -Ofast -fno-fast-math to preserve IEEE specifications.
>> >
>> > Glad to see -floop-parallelize-all in gcc 4.7, it will help us identify
>> > places to focus OpenMP work on.
>> >
>> >
>> > Hamish
>> >
>>
>
>


benchmark.sh
Description: Bourne shell script
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.neighbors velocity

[Sören Gebbert]

Hi,
i have implemented a "real" average neighborhood algorithm that runs in
parallel using openmp. The source code and the benchmark shell script is
attached.

The neighbor program computes the average moving window of arbitrary size.
The size of the map rows x cols and the size of the moving window  (odd
number cols==rows) can be specified.

./neighbor rows cols mw_size

IMHO the new program is better for compiler comparison and neighborhood
operation performance.

This is the benchmark on my 5 year old AMD phenom 4 core computer using 1,
2 and 4 threads:

gcc -Wall -fopenmp -lgomp -Ofast main.c -o neighbor
export OMP_NUM_THREADS=1
time ./neighbor 5000 5000 23
real 0m37.211s
user 0m36.998s
sys 0m0.196s

export OMP_NUM_THREADS=2
time ./neighbor 5000 5000 23
real 0m19.907s
user 0m38.890s
sys 0m0.248s

export OMP_NUM_THREADS=4
time ./neighbor 5000 5000 23
real 0m10.170s
user 0m38.466s
sys 0m0.192s

Happy hacking, compiling and testing. :)

Best regards
Soeren




2013/6/29 Markus Metz 

> On Sat, Jun 29, 2013 at 1:26 PM, Hamish  wrote:
> > Markus Metz wrote:
> >
> >> Some more results with Sören's test program on a Intel(R) Core(TM) i5
> >> CPU M450 @ 2.40GHz (2 real cores, 4 fake cores) with gcc 4.7.2 and
> >> clang 3.3
> >>
> >> gcc -O3
> >> v is 2.09131e+13
> >>
> >> real2m0.393s
> >> user1m57.610s
> >> sys0m0.003s
> >>
> >> gcc -Ofast
> >> v is 2.09131e+13
> >>
> >> real0m7.218s
> >> user0m7.018s
> >> sys0m0.017s
> >
> >
> > nice. one thing we need to remember though is that it's not entirely
> > free, one thing -Ofast turns on is -ffast-math,
> > """
> >  This option is not turned on by any -O option besides -Ofast since it
> can
> >  result in incorrect output for programs that depend on an exact
> >  implementation of IEEE or ISO rules/specifications for math functions.
> It
> >  may, however, yield faster code for programs that do not require the
> >  guarantees of these specifications.
> > """
> >
> > which may not be fit for our purposes.
> >
> >
> > With the ifort compiler there is '-fp-model precise' which allows only
> > optimizations which don't harm the results. Maybe gcc has something
> > similar.
>
> In gcc, you can turn of -ffoo with -fno-foo, maybe this way you can
> use -Ofast -fno-fast-math to preserve IEEE specifications.
> >
> > Glad to see -floop-parallelize-all in gcc 4.7, it will help us identify
> > places to focus OpenMP work on.
> >
> >
> > Hamish
> >
>


benchmark.sh
Description: Bourne shell script
#include 
#include 

/* #define DEBUG 1 */

/* Prototypes for gathering and average computation */
static int gather_values(double **input, double *buff, int nrows, 
int ncols, int mw_size, int col, int row, int dist);

static double average(double *values, int size);

int main(int argc, char **argv)
{
int nrows, ncols, mw_size, size, dist;
double **input = NULL, **output = NULL;
int i, j;

/* Check and parse the input parameter */
if(argc != 4)
{

fprintf(stderr, "Warning!\n");
fprintf(stderr, "Please specifiy the number of rows and columns and the "
"\nsize of the moving window (must be an odd number)\n");
fprintf(stderr, "\nUsage: neighbor 5000 5000 51\n");
fprintf(stderr, "\nUsing default values: rows = 5000, cols = 5000, moving window = 51\n");
nrows = 5000;
ncols = 5000;
mw_size = 51;
} 
else 
{

sscanf(argv[1], "%d", &nrows);
sscanf(argv[2], "%d", &ncols);
sscanf(argv[3], "%d", &mw_size);

if(mw_size%2 == 0) {
fprintf(stderr,"The size of the moving window must be odd");
return -1;
}
}

size = mw_size * mw_size;
dist = mw_size / 2;

/* Allocate input and output */
input = (double**)calloc(nrows, sizeof(double*));
output= (double**)calloc(nrows, sizeof(double*));

if(input == NULL || output == NULL)
{
fprintf(stderr, "Unable to allocate arrays");
return -1;
}

for(i = 0; i < nrows; i++) 
{
input[i] = (double*)calloc(ncols, sizeof(double));
output[i]= (double*)calloc(ncols, sizeof(double));

if(input[i] == NULL || output[i] == NULL)
{
fprintf(stderr, "Unable to allocate arrays");
return -1;
}

#ifdef DEBUG
for(j = 0; j < ncols; j++)
input[i][j] = i + j;
#endif
}

#pragma omp parallel for private(i, j)
for(i = 0; i < nrows; i++) 
{
for(j = 0; j < ncols; j++)
{

/* Value buffer with maximum size */
double *buff = NULL;
buff = (double*)calloc(size, sizeof(double));

/* Gather value in moving window */
int num = gather_values(input, buff, nrows, ncols, mw_size, i, j, dist);

output[i][j] = average(buff, num);

free(buff);
}
}

#ifdef DEBUG
printf("\nInput\n");
for(i = 0; i < nrows; i++) 
{
for(j = 0; j < ncols; j++)
{
  

Re: [GRASS-user] r.neighbors velocity

[Sören Gebbert]

Hey Folks,
many thanks for pointing to the important influence of different compiler
and compiler options. But please be aware that my tiny little program is
not representative for a neighbor analysis implementation, it was simply a
demonstration of  12 billion ops:

1. I use fixed loop sizes, it is really easy for a compiler to optimize that
2. It is pretty simple to parallelize since only a simple reduction is done
in the inner loop

3. Most important: The statement of Ivan was a window size of 501 ... as
MarkusN IMHO correctly interpreted this leads to a moving window of 501x501
pixel if this is an option for r.neighbors. It is not the total number of
cells of a rectangular moving window, since it must must be an even number
in this case. Other shapes than rectangular are more complex to implement.

To be diplomatic i decided to use 501 pixel, which might represented a
23x21 pixel moving window, to show that this "small" number of operations
needs a considerable amount of time on modern CPU's.

If you use a 501x501 pixel moving window the computational effort is
roughly 501 times 12 billion ops. IMHO in this case a GPU or neighbor
algorithm specific FPGA/ASIC may be able to perform this operation in 2/3
seconds.

Best regards
Soeren
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.neighbors velocity

[Sören Gebbert]

Hi Ivan,
this sounds very interesting.

Your map has a size of 4312*5576 pixel? That's about 100MB in case of a
type integer or type float map or about 200MB in case of a type double map.
You must have a very fast HD or SSD to read and write such a map in under
2/3 seconds?

In case your moving window has a size of 501 pixel (not 501x501 pixel!),
the amount of operations that must be performed is at least 4312*5576*501.
That's about 12 billion ops. Amazing to do this in 2/3 seconds.
I have written a little program to see how my Intel core i5 performs
processing this amount of operations. Well it needs about 100 seconds.

Here the code, compiled with optimization:

#include 

int main()
{
unsigned int i, j, k;
register double v = 0.0;

for(i = 0; i < 4321; i++) {
for(j = 0; j < 5576; j++) {
for(k = 0; k < 501; k++) {
v = v + (double)(i + j + k)/3.0;
}
}
}
printf("v is %g\n", v);
}

soeren@vostro:~/src$ gcc -O3 numtest.c -o numtest
soeren@vostro:~/src$ time ./numtest
v is 2.09131e+13

real 1m49.292s
user 1m49.223s
sys 0m0.000s


Your proprietary software must run highly parallel using a fast GPU or an
ASIC to keep the processing time under 2/3 seconds?

Unfortunately r.neighbors is not able to compete with such a powerful
software, since it is not reading the entire map into RAM and does not run
on GPU's or ASIC's. But r.neighbors is able to process maps that are to
large to fit into the RAM. :)

Can you please tell us what software is so incredible fast?

Best regards
Soeren


2013/6/28 Ivan Marchesini 

> Hi Markus
> you are perfectly right
>
> the region is 4312*5576
> the moving window 501
> GRASS is the stable version on a machine with 8 core and 32 gb RAM.
> Ubuntu 12.04
>
> it seems that the proprietary software is able to perform the analysis
> in 2/3 seconds
>
> :-|
>
> ciao
>
>
> On Fri, 2013-06-28 at 00:02 +0200, Markus Neteler wrote:
> > On Thu, Jun 27, 2013 at 9:01 AM, Ivan Marchesini
> >  wrote:
> > > Hi all,
> > > A friend of mine (having skill also in some proprietary remote sensing
> > > softwares) is testing GRASS for some task.
> > > He is quite happy about the results but he was really surprised by the
> > > time interval that r.neighbor take for doing the analysis. The time is
> > > really large in his opinion
> >
> > Please post some indications: computational region size and
> > moving window size, also which hardware/operating system.
> > Otherwise it is hard to say anything...
> >
> > Markus
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] GRASS7 temporal GIS database questions

[Sören Gebbert]

Hi Rainer,


2013/5/22 Rainer M. Krug 

> Hi
>
> I am doing spatio-temporal simulations with R and GRASS and IO am
> thinking about using a temporal GIS database to store the resulting
> raster layers in.
>
> But I have a few questions about the temporal GIS database:
>
> 1) If I register a raster map in a temporal GIS database via r.register,
> can I delete the original raster map and the info is stored in the
> temporal GIS database?
>

Yes, the info is still stored in the temporal database, unless you call
t.support with -m option.


>
> 2) If 1) is possible, can I extract the raster layer again from the
> temporal GIS database?
>
> No, that's not possible since only the spatio-temporal extent and some
metadata is stored in the temporal database. The map data itself will not
copied.


> 3) Summarizing: Is the temporal GIS database a good archiving place for
> the layers I create during the simulation?
>

If you think that GRASS is a good archiving place then yes. But be aware
that a large temporal database with lots of maps with slow down the
temporal database access. If you want to store >10.000 maps, then you
should use postgresql as temporal database backend.


Best regards
Soeren


>
> Thanks,
>
> Rainer
>
>
> --
> Rainer M. Krug
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] [GRASS-dev] wxGUI toolboxes

[Sören Gebbert]

Hi Anna,


2013/5/2 Anna Kratochvílová 

> On Thu, May 2, 2013 at 9:52 AM, Sören Gebbert
>  wrote:
> > Hi,
> > this is really great, many thanks! I am looking forward to add a temporal
> > modules menu layout.
>
> I was about to suggest adding temporal framework to the toolboxes so
> that it can be optionally added to menu. Will you try it? The needed
> information should be in the programming manual. Or I can create the
> toolbox and you can improve it later. The main work beside creating
> the structure is to add menu labels.
>

That is nice, i would like to improve it later. :)

Best regards
Soeren

>
> Anna
>
> >
> > Best regards
> > Soeren
> >
> >
> > 2013/4/30 Vaclav Petras 
> >>
> >> Hi all,
> >>
> >> first version of toolboxes for wxGUI is released (for GRASS GIS 7) and
> >> is available in trunk. The main purpose of toolboxes is the wxGUI menu
> >> customization. The current implementation of toolboxes does not
> >> influence the set of installed or available modules. The toolboxes are
> >> the possibility to create different highly specialized menu layouts.
> >>
> >> Users, which are able to edit XML, can now create toolboxes which
> >> contain modules from GRASS distribution, existing toolboxes (from the
> >> distribution) and modules from addons or their own modules. These
> >> toolboxes or set of toolboxes (in the toolboxes file) can be copied
> >> and shared, and users, which are able to copy the file into the
> >> .grass7 directory, can use them. Note that distribution of toolboxes
> >> is now not connected to the distribution of modules itself. GUI
> >> front-end is not available.
> >>
> >> The main menu (main menubar) is treated separately in the separate
> >> file with slightly different structure but its very similar to toolbox
> >> and it follows the same concepts.
> >>
> >> Note that you need to create your custom toolboxes.xml file or
> >> main_menu.xml file into your $HOME/toolboxes directory to see
> >> toolboxes in action.
> >>
> >> For the detailed description please see Programmer's Manual [1] and
> >> for future consideration and development issues see Trac [2].
> >>
> >> Anna and Vaclav
> >>
> >> [1] http://grass.osgeo.org/programming7/wxguitoolboxes.html
> >> [2] http://trac.osgeo.org/grass/wiki/wxGUIDevelopment/Toolboxes
> >> (links will work soon)
> >> ___
> >> grass-dev mailing list
> >> grass-...@lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/grass-dev
> >
> >
> >
> > ___
> > grass-dev mailing list
> > grass-...@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] [GRASS-dev] wxGUI toolboxes

[Sören Gebbert]

Hi,
this is really great, many thanks! I am looking forward to add a temporal
modules menu layout.

Best regards
Soeren


2013/4/30 Vaclav Petras 

> Hi all,
>
> first version of toolboxes for wxGUI is released (for GRASS GIS 7) and
> is available in trunk. The main purpose of toolboxes is the wxGUI menu
> customization. The current implementation of toolboxes does not
> influence the set of installed or available modules. The toolboxes are
> the possibility to create different highly specialized menu layouts.
>
> Users, which are able to edit XML, can now create toolboxes which
> contain modules from GRASS distribution, existing toolboxes (from the
> distribution) and modules from addons or their own modules. These
> toolboxes or set of toolboxes (in the toolboxes file) can be copied
> and shared, and users, which are able to copy the file into the
> .grass7 directory, can use them. Note that distribution of toolboxes
> is now not connected to the distribution of modules itself. GUI
> front-end is not available.
>
> The main menu (main menubar) is treated separately in the separate
> file with slightly different structure but its very similar to toolbox
> and it follows the same concepts.
>
> Note that you need to create your custom toolboxes.xml file or
> main_menu.xml file into your $HOME/toolboxes directory to see
> toolboxes in action.
>
> For the detailed description please see Programmer's Manual [1] and
> for future consideration and development issues see Trac [2].
>
> Anna and Vaclav
>
> [1] http://grass.osgeo.org/programming7/wxguitoolboxes.html
> [2] http://trac.osgeo.org/grass/wiki/wxGUIDevelopment/Toolboxes
> (links will work soon)
> ___
> grass-dev mailing list
> grass-...@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Any tutorial(s) on the GRASS' space-time datasets?

[Sören Gebbert]

Hi,

2013/3/26 Rebecca Bennett :
> Hello Soeren and Grass Users,
>
> I am experimenting with some 3D export from GRASS to Paraview but note that
> the links to tutorials etc at the bottom of this page are broken
> http://grasswiki.osgeo.org/wiki/GRASS_and_Paraview

Thanks for the hint, i have removed the links, since the material is
no longer available.

> If someone could point me in the right direction of this or similar material
> that would be great.

Try the foss4g 2006 workshop material:
http://2006.foss4g.org/contributionDisplay9f8b.html?contribId=45&sessionId=59&confId=1

Best regards
Soeren

>
> Thanks for reading,
> Rebecca
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Any tutorial(s) on the GRASS' space-time datasets?

[Sören Gebbert]

Hi Nikos,
there are presentation and support material available in the
attachment section of the lecture description:
http://www.geostat-course.org/Topic_Gebbert

Best regards
Soeren

2013/3/2 Nikos Alexandris :
> Hi list!
>
> Are there any user-tutorial(s) -- intro or advanced -- upon the space-time
> data sets  (except of the t.* manuals)?
>
> Thanks, Nikos
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] [GRASS-dev] how to sample a series at one location?

[Sören Gebbert]

Hi,
Am 22.02.2013 21:44 schrieb "Newcomb, Doug" :
>
> t.create--> t.register--> t.vect.observer.strds   in GRASS7 ?   Looks
really nifty, could be useful with the Landsat Cube data sets
http://landsat.usgs.gov/documents/Oct27_29_2009_huang_LST_boston.ppt

Yes, thats the idea. I totally forgot, I made I short presentation and
tutorial at the geostat in 2012:
http://www.geostat-course.org/Topic_Gebbert

The presentation and the scripts are available there. The
t.vect.observe.strds example is in part three of the presentation. The cool
thing is that t.vect.observe.strds uses time stamped attribute tables to
store the values.

Best regards
Soeren
>
>
>
> Doug
>
>
> On Fri, Feb 22, 2013 at 2:53 PM, Michael Barton 
wrote:
>>
>> Thanks Doug,
>>
>> I knew I could do it with a script and v.what.rast.
>>
>> What I was hoping was that there is a shortcut already usable in GRASS
modules. Looks like the new temporal GIS tools may be able to do it.
>>
>> Michael
>> __
>> C. Michael Barton
>> Director, Center for Social Dynamics & Complexity
>> Professor of Anthropology, School of Human Evolution & Social Change
>> Arizona State University
>> Tempe, AZ  85287-2402
>> USA
>>
>> voice:  480-965-6262 (SHESC), 480-727-9746 (CSDC)
>> fax:  480-965-7671(SHESC), 480-727-0709 (CSDC)
>> www:  http://csdc.asu.edu, http://shesc.asu.edu
>> http://www.public.asu.edu/~cmbarton
>>
>> On Feb 22, 2013, at 12:31 PM, "Newcomb, Doug" 
>>  wrote:
>>
>>> Michael,
>>> You could use v.what.rast  in a python script , iterating the raster
layers with an sqlite database back end.  I think that would go up to 2000
columns for each point you have.
>>>
>>> Alternatively, you could use a bit of python with gdal.  I was trying
to do something similar in GRASS, to change the Z value of each point in a
text LiDAR file, from absolute above sea level to relative the elevation of
the ground.  For 25.5 billion text points and a Statewide 20 ft elevation
grid (6.5 ? billion cells) , it was a bit slow using r.what.  So I
converted the LiDAR data to (7)  3.3 billion point  LAS format files and
exported the GRASS layer to an Erdas imagine format file and wrote the
following ugly python script:
>>>
>>> #!/usr/bin/python
>>> import os,string,glob,re,gdal
>>> from liblas import file
>>> from liblas import header
>>> from liblas import point
>>> from gdalconst import *
>>> h=header.Header()
>>> #enter the LAS point file name
>>> infile=raw_input("Enter the input lidar data points file: ")
>>> #Hardcoded edras imagine file, you will have to use an array for the
different data layer names
>>> imgfile="/gisdata2/raster/allnc_20ft_el.img"
>>> #print "suggest /gisdata2/raster for output dir\n"
>>> inarr=infile.split('.')
>>> #This sets the LAS output file, substitute your output text file instead
>>> outfil=inarr[0]+"_norm.las"
>>> #outfil=raw_input("Enter output text file name: ")
>>> #This part reads the LAS file, if you
>>> l=file.File(infile,mode='r')
>>> #Outputs the LAS file
>>> lout=file.File(outfil,mode='w',header=h)
>>> # register all of the drivers, hopefully your gdal speaks GRASS
>>> gdal.AllRegister()
>>> #opening and closing the image layers might take some time if you are
reading thousands of images
>>> ds=gdal.Open(imgfile,GA_ReadOnly)
>>> if ds is None:
>>> print 'Could not open image'
>>> sys.exit(1)
>>> # get image size
>>> rows = ds.RasterYSize
>>> cols = ds.RasterXSize
>>> bands = ds.RasterCount
>>> # get georeference info, not sure how this would work for GRASS data
layers
>>> transform = ds.GetGeoTransform()
>>> xOrigin = transform[0]
>>> yOrigin = transformAsArray(xOffset, yOffset, 1, 1)
>>> pixelWidth = transform[1]
>>> pixelHeight = transform[5]
>>> for p in l:
>>> x=float(p.x)
>>> y=float(p.y)
>>> z=float(p.z)
>>> # compute pixel offset
>>> xOffset = int((x - xOrigin) / pixelWidth)
>>> yOffset = int((y - yOrigin) / pixelHeight)
>>> band = ds.GetRasterBand(1) # 1-based index 0? 1?
>>> data = band.Readr(value) :continue
>>> value = data[0,0]
>>> #print value,"11","\n"
>>> if "nan" in st[3]
>>> znorm = z-value
>>> #print znorm,"\n"
>>> pt=point.Point()
>>> pt.x=p.x
>>> pt.y=p.y
>>> pt.z=znorm
>>> lout.write(pt)
>>>
>>> l.close()
>>> lout.close()
>>> #25561312019 points in allreturns
>>>
>>> This managed to process everything over a weekend( in 7 parallel
threads), which was fast enough for me at the time.  Approaching your
problem , if your data layers are all n GRASS and your version of gdal can
read GRASS data layers,  I would grab the list of GRASS layers via glob and
iterate the layers , writing the name of the raster layer and the value of
the raster layer at the point coordinates out to a text file as you state
below.
>>>
>>> Hope this helps,
>>> Doug
>>>
>>>
>>> On Fri, Feb 22, 2013 at 1:23 PM, Michael Barton 
wrote:

 But I want to do it with a time series of hundreds or thousands of
maps.

 Michael
 _

Re: [GRASS-user] ValueError: too many values to unpack

[Sören Gebbert]

Hi Manish,
This error was solved recently (13.01.2013) [1] . Unfortunately is the
current snapshot to old for this changes. Soon a more recent snapshot
should be available.

Best regards
Soeren

[1] http://trac.osgeo.org/grass/changeset/54619
Am 18.01.2013 20:42 schrieb "Manish Gautam" :

> Hi,
>
> I have installed the latest version of GRASS 7 (updated as on Jan 12,
> 2013) from here http://grass.osgeo.org/grass70/source/snapshot/ on my
> ubuntu 11.04.
>
> while running the t.rast.mapcalc I am getting following error message:
>
> Start temporal sampling
>  100%
> Start mapcalc computation
> Traceback (most recent call last):
>   File
> "/home/manish/src/dist.x86_64-unknown-linux-gnu/scripts/t.rast.mapcalc",
> line 102, in 
> main()
>   File
> "/home/manish/src/dist.x86_64-unknown-linux-gnu/scripts/t.rast.mapcalc",
> line 97, in main
> base, method, nprocs, register_null, spatial)
>   File
> "/home/manish/src/dist.x86_64-unknown-linux-gnu/etc/python/grass/temporal/mapcalc.py",
> line 250, in dataset_mapcalculator
> start, end = sample_map_list[i].get_relative_time()
> ValueError: too many values to unpack
>
>
> Any help to resolve this issue?
>
> -
>
> Manish
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] installing Grass 7 on ubuntu 11.04

[Sören Gebbert]

Hi Manish,
please make sure that all requirements for GRASS are fulfilled. Using
./configure --help will show you all switches that can be set. In your
particular case is the libtiff-dev package from Ubuntu missing. Use this
command:

apt-get install libtiff-dev

to install the development files (header) for libtiff. This will solve the
tiff error.
Please have a look at [1] and install all missing dependencies using
apt-get or aptitude.

Best regards
Soeren


[1] http://grass.osgeo.org/wiki/Compile_and_Install_Ubuntu#Dependencies


2012/11/1 Manish Gautam 

> Hi,
>
> Thanks for your responses.
>
> I followed till this step
> http://grass.osgeo.org/wiki/Compile_and_Install_Ubuntu#GRASS_GIS
> (about the ./configure command not working earlier, this time it
> worked as I didn't use the ubuntu repository to install rest of the
> prerequisites, but downloaded manually and moved to the source code
> directory and then configured it accordingly).
>
> In the step of Grass_GIS, ./configure worked (but it says error:
> unabale to locate TIFF includes, rest worked).
>
> the  step -
>
> compile & install
>
> make -j2 && sudo make install && sudo ldconfig
>
> says "include/Make/Vars.make:1: include/Make/Platform.make: No such
> file or directory
> make: *** No rule to make target `include/Make/Platform.make'.  Stop."
>
> and here I am stuck.
>
> -
>
> Manish
>
>
> On 31 October 2012 22:44, Nikos Alexandris 
> wrote:
> >
> > [forgot to cc to the list]
> >
> > Manish Gautam:
> >
> >
> > > I am finding it difficult to install Grass 7 on my pc. I use Ubuntu
> 11.04.
> > > I have tried to install it using the instructions given in the link
> > > http://grass.osgeo.org/wiki/Compile_and_Install_Ubuntu. However, I am
> able
> > > to download and install the dependencies.
> >
> > Could you please post the exact command you instructed?  And, any
> positive or
> > negative output?
> >
> >
> > > Another thing is how the command ./configure is to be used on Ubuntu
> 11.04.
> > > the terminal says the ./configure command not found though the
> necessary
> > > compiler is already been installed on the machine.
> >
> > Actually, the "configure" executable file/program is to be ran from
> within the
> > directory in which it is located, i.e.  the grass source code root
> directory.
> >
> > From within which directory do you try to execute ./configure?  And
> along with
> > which parameters?
> >
> >
> > > (Can I download the binary file from here
> > > http://grass.fbk.eu/grass70/binary/linux/snapshot/ and install from
> here ?
> >
> > I haven't tried that yet. Maybe someone else can help with this.
> >
> >
> > > Though again I am unable to run the installation script given there or
> > > extracting the tar file)
> >
> > Nikos
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] new wxGUI Animation Tool in addons

[Sören Gebbert]

Hi Anna,
you have implemented a great tool! I was able to visualize two space
time raster datasets with different temporal granularity  (mixing year
and month) synchronously. :)
This is really cool.

Having such a great tool raises many wishes that could be implemented
in addition. :)
Here just a few of them:

* It would be great if vector time series are available to visulaize too
  (as vector map list or space time vector datasets). So we can visualize
  for example temperature maps and vector contours at the same
  time in the same frame?

* Having a legend for the raster maps would be very handy for comparison.
  I am preparing a tool to set the color table for a space time raster datasets
  computed from all registered maps. So the maps of a dataset would have
  all the same color table representing the data range of the space
time raster dataset.

* A stepper would be great to step through the time series data
  using the lowest temporal granularity of the visualized space time datasets

* Exporting animation as mp4 or similar :)

* Starting the animation tool from comand line


I have prepared some datasets which you can play with:
http://www-pool.math.tu-berlin.de/~soeren/tmp/

These datasets are derived form the ECA&D project E-OBS gridded data[1].
Usage policy od ECAD data is available here [2].


You can simply import the datasets in a Lat/lon location using t.rast.import.

Best regards
Soeren


[1] http://eca.knmi.nl/download/ensembles/ensembles.php
[2] http://eca.knmi.nl/documents/ECAD_datapolicy.pdf

2012/10/19 Anna Kratochvílová :
> Hi all,
>
> I would like to announce that new wxGUI Animation Tool is available
> for testing in GRASS 7 Addons. You can install it with the g.extension
> dialog (or in the command line: g.extension -s
> extension=wx.animation). You can animate a series of raster maps or
> better, a space time raster dataset created by the new GRASS 7
> temporal framework.
> Please, have a look at the videos on the wiki page [1] and the manual
> page. I would like to demonstrate the functionality on some more
> interesting data which I don't have, so I would be glad if someone
> could help.
>
> Best,
>
> Anna
>
> [1] http://grass.osgeo.org/wiki/WxPython-based_GUI_for_GRASS#Animation_Tool
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] urgently:(((please

[Sören Gebbert]

Simply specify the location and mapset with absolute path at the
command line in "text" mode:

grass70 -text /home/soeren/grassdata/LL/PERMANENT



grass70 --help

Usage:
  grass70 [-h | -help | --help] [-v | --version] [-c | -c geofile | -c
EPSG:code]
  [-text | -gui] [--config param]
  [[[/]/]]

Flags:
  -h or -help or --help  print this help message
  -v or --versionshow version information and exit
  -c create given database, location or
mapset if it doesn't exist
  -text  use text based interface
   and set as default
  -gui   use wxpython graphical user interface
   and set as default
  --config   print GRASS configuration parameters
   options: arch,build,compiler,path,revision

Parameters:
  GISDBASE   initial database (path to GIS data)
  LOCATION_NAME  initial location
  MAPSET initial mapset

  GISDBASE/LOCATION_NAME/MAPSET  fully qualified initial mapset directory

Environment variables relevant for startup:
  GRASS_GUI  select GUI (text, gui)
  GRASS_WISH set wish shell name to override 'wish'
  GRASS_HTML_BROWSER set html web browser for help pages
  GRASS_ADDON_PATH   set additional path(s) to local GRASS
modules or user scripts
  GRASS_ADDON_BASE   set additional GISBASE for locally
installed GRASS Addons
  GRASS_BATCH_JOBshell script to be processed as batch job
  GRASS_PYTHON   set python shell name to override 'python'


2012/10/1 Albert Saribekyan :
>
>
>
>
>
> Albert Saribekyan.
>>
>>
> Sorry I forgot to mention I must do it in GRASS7.0,   in 6.* i did it!!
> so help me..
> my GRASS starts following:
>
>  __  ___   _____
> / / __ \/   | / ___/ ___/   / /  _/ ___/
>/ / __/ /_/ / /| | \__ \\_  \   / / __ / / \__ \
>   / /_/ / _, _/ ___ |___/ /__/ /  / /_/ // / ___/ /
>   \/_/ |_/_/  |_///   \/___///
>
> Welcome to GRASS 7.0.svn
> GRASS 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.0.svn (orinak):~ >
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] help with r.gwflow

[Sören Gebbert]

Hi,

2012/7/19 Vishal Mehta :
> Thanks Soren,
> for your script.
>
> i'm using r.gwflow in v6.5svn, which does not have the budget parameter
> option. do you know how i can get the 7 version to work in my 6.5 version?

Unfortunately the grass7 version of r.gwflow does not run in grass6.5
and i have no plans o back port the budget feature.
So maybe you would like to switch to grass7 to compute the budget?

> also, i'd like to know how all th rest if it is set up - the river_bed
> parameters etc. do you have complete documentation of it? i'm trying to

You need three parameters to model the river:
1.) The water table of the river in [m], mostly derived from a river
vector map and converted into a raster map
2.) The bed of the river in [m], mostly derived from the river water
table: r.mapcalc "river_bed = river_table - 2"
3.) The leakage coefficient of the river bed in [1/s]

River table, river bed and leakage are occupying the same pixels.

Simple and stupid example:

# River with a water table of 20m and the bed at 18m with a
# leakage coefficient of 0.0001 1/s

# First convert the stream network into a raster map
v.to.rast input=streams output=streams type=line

# Then compute the water table of the river at 20m
# and the height of the bed that is 2m lower than
# the water table of the river
r.mapcalc "river_head = if(isnull(streams), null(), 20)"
r.mapcalc "river_bed = river_head - 2"

# The river leakage coefficient can be computed from the hydraulic conductivity
# of the river bed (0.0001m/s) and the thickness of the river bed (1m)
r.mapcalc "river_leakage = if(isnull(streams), null(), 0.0001/1)"

> model the coupled water supply-extraction and groundwater system of a city,
> so more complex real world examples of the use of r.gwflow would be really,
> really useful. have you used it in a ocomplex setting perhaps for your
> dissertation?

The only documentation that is available is the r.gwflow manual page
and my diploma thesis [1] (in German)
that describes the mathematical details. I never utilized r.gwflow to
compute large complex real world problems.

Best regards
Soeren

[1] 
http://www.hydrogeologie.tu-berlin.de/fileadmin/fg66/_hydro/Diplomarbeiten/2007_Diplomarbeit_Soeren_Gebbert.pdf

>
> thanks again,
> Vishal
>
>
> On Wed, Jul 18, 2012 at 2:47 PM, Sören Gebbert
>  wrote:
>>
>> Hi Vishal,
>>
>> 2012/7/18 Vishal Mehta :
>> > hi Soren,
>> >
>> > my constan head boundary conditions on the edges are causing water
>> > tables to
>> > build up everywhere else. so i estimated a constant flux 0f 0.0019 m3/s
>> > that
>> > i want to apply for edge cells. this is what i am trying in order to
>> > impose
>> > a constant flux on the edges
>> >
>> > r.mapcalc "sink.init=if(row()==1 || row()==444 ||col()==1
>> > ||col==477,-0.0019,null())
>> >
>> > #sink.init is the constant flux on edges
>> > # my r.gwflow script runs at monthly time step- ihave a loop
>> > $month-here's
>> > the r.gwflow snippet
>> >
>> > r.gwflow --o -s solver=cg top=top bottom=bottom status=bc2 hc_x=k.1
>> > hc_y=k.1
>> > s=s.1 type=unconfined dt=2592000 error=0.05 phead=sim.$((prevmonth))
>> > r=gwnaturalms.$((month)) q=sink.init output=sim.$((month))
>> >
>> > my boundary condition map (bc2) has contant head in strea pixels. all
>> > else
>> > are calculated.
>> >
>> > do you think the above implementation will correctly impose the constant
>> > flux on the edges? it seems though that since this is not a boundary
>> > condition, how can it ensure a constant flux at edges?
>>
>> Your script looks reasonable, except that the error term is much to large.
>> You may need to use a smaller number like 10⁻7,
>> otherwise your results my be wrong.
>>
>> I have attached a small r.gwflow example to show you how to estimate
>> the constant flux at
>> a western boundary using the budget computation. Since the flow will
>> be specified
>> as a source term, it will be constant the whole computational time.
>>
>> Maybe you can apply this method to estimate the boundary flux in your
>> area?
>>
>> JFYI i am using r.gwflow of GRASS 7.
>>
>> Best regards
>> Soeren
>>
>> >
>> > Thanks for any help you can provide,
>> > Vishal
>> >
>> > On Mon, Jul 16, 2012 at 1:46 PM, Vishal Mehta 
>> > wrote:
>> >>
>> >> Thanks Soren,
>> >> From you response, can you please tell me how to do the following two
>> >> tasks (which i dont find in the on

Re: [GRASS-user] help with r.gwflow

[Sören Gebbert]

Hi Vishal,

2012/7/18 Vishal Mehta :
> hi Soren,
>
> my constan head boundary conditions on the edges are causing water tables to
> build up everywhere else. so i estimated a constant flux 0f 0.0019 m3/s that
> i want to apply for edge cells. this is what i am trying in order to impose
> a constant flux on the edges
>
> r.mapcalc "sink.init=if(row()==1 || row()==444 ||col()==1
> ||col==477,-0.0019,null())
>
> #sink.init is the constant flux on edges
> # my r.gwflow script runs at monthly time step- ihave a loop $month-here's
> the r.gwflow snippet
>
> r.gwflow --o -s solver=cg top=top bottom=bottom status=bc2 hc_x=k.1 hc_y=k.1
> s=s.1 type=unconfined dt=2592000 error=0.05 phead=sim.$((prevmonth))
> r=gwnaturalms.$((month)) q=sink.init output=sim.$((month))
>
> my boundary condition map (bc2) has contant head in strea pixels. all else
> are calculated.
>
> do you think the above implementation will correctly impose the constant
> flux on the edges? it seems though that since this is not a boundary
> condition, how can it ensure a constant flux at edges?

Your script looks reasonable, except that the error term is much to large.
You may need to use a smaller number like 10⁻7,
otherwise your results my be wrong.

I have attached a small r.gwflow example to show you how to estimate
the constant flux at
a western boundary using the budget computation. Since the flow will
be specified
as a source term, it will be constant the whole computational time.

Maybe you can apply this method to estimate the boundary flux in your area?

JFYI i am using r.gwflow of GRASS 7.

Best regards
Soeren

>
> Thanks for any help you can provide,
> Vishal
>
> On Mon, Jul 16, 2012 at 1:46 PM, Vishal Mehta  wrote:
>>
>> Thanks Soren,
>> From you response, can you please tell me how to do the following two
>> tasks (which i dont find in the online manual for r.gwflow): the remainder
>> of your comments i have figured out.
>>
>> - How can i compute the flux in [m^3/s] for each cell with r.mapcalc?
>> and
>>
>> - i have set the bc of the edges and stream cells at constant head for
>> now- how can i get the budget raster maps you mention?
>>
>> thanks again,
>> Vishal
>>
>>
>> On Sat, Jul 14, 2012 at 12:05 PM, Sören Gebbert
>>  wrote:
>>>
>>> Hi,
>>> sorry for the delay.
>>>
>>> 2012/7/11 Vishal Mehta :
>>> > Thanks Soren,
>>> > That explains some of the results i'm getting, with water piling up
>>> > above
>>> > the surface in the edges in low-lying areas.
>>> >
>>> > Can you please tell me how i can change that to constant flux or
>>> > constant
>>> > head? If constant flux, should that be in m/s units?
>>>
>>> Constant flux can currently only be defined using sources/sinks with
>>> unit [m^3/s], that is option q.
>>> But i can add two new options (fn, fe) that defines the flux in
>>> northern or eastern direction using the unit [m/s]
>>> that will be multiplied internally with the northern or eastern face
>>> area of the cell?
>>>
>>> Otherwise you need to compute the flux in [m^3/s] for each cell with
>>> r.mapcalc.
>>>
>>> >
>>> > My problem though is that i dont know what a constant flux or head at
>>> > the
>>> > edges should be set to. For now the only bc i have put in there
>>> > deliberately
>>> > (beyond the default you mention) is that i have set constant head in
>>> > stream
>>> > pixels. I'll have to let flow through at the edges but i have no idea
>>> > what
>>>
>>> You can use the river boundary condition to specify the flux in stream
>>> pixel.
>>>
>>> > that flow should be. Are there some ways of setting the edge conditions
>>> > such
>>> > that the gw evolution in the central areas of interest are not highly
>>> > influenced?
>>>
>>> You can set the boundary of interest to constant head pixel and
>>> compute the flow throw the boundary pixel using the budget option.
>>> The resulting budget raster map shows the flow from active cell into
>>> sources, sinks and constant heads in [m^3/s].
>>>
>>> Best regards
>>> Soeren
>>
>>
>>
>>
>> --
>> Vishal K. Mehta, PhD
>> Scientist
>> Stockholm Environment Institute - US
>> 133 D St Suite F
>> Davis CA 95616
>> www.sei-us.org
>
>
>
>
> --
> Vishal K. Mehta, PhD
> Scientist
> Stockholm Environment Institute - US
> 133 D St Suite F
> Davis CA 95616
> www.sei-us.org


groundwater.sh
Description: Bourne shell script
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] help with r.gwflow

[Sören Gebbert]

Hi,
as default the boundaries are no flow boundary conditions called
"homogeneous Neumann". Hence the default flux is 0.

Best regards
Soeren

2012/7/11 Vishal Mehta :
> Hi all,
>
> I've been trying to use r.gwflow recently, for groundwater modeling in urban
> environments.
>
> The r.gwflow help says that the default boundary conditions at the edges of
> the region are Neumann conditions, which i understand are fixed flux
> conditions. However the help does not include the value of the default flux
> conditions at the boundary. Can someone help me figure out what that is?
>
> Also, if there is anyone actively using r.gwflow who is interested in
> engaging a bit more, please let me know.
> Thanks,
> Vishal
>
> --
> Vishal K. Mehta, PhD
> Scientist
> Stockholm Environment Institute - US
> 133 D St Suite F
> Davis CA 95616
> www.sei-us.org
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Grass 7 compile errors

[Sören Gebbert]

Hi Daniel,
i faced the same problem. OGR_L_GetGeomType was introduced in r51126 [1].
I solved this by removing the default Ubuntu gdal package and
compiling+installing the gdal version 1.9.0 from sources. I would have
expected an announcement about this changes, since OGR_L_GetGeomType
was introduced recently in gdal version > 1.7.2?

A gdal version check should be provided to detect this dependency at
configuration time or at least an announcement in the
REQUIREMENTS.html file (... dear Martin).

Best regards
Soeren

[1] https://trac.osgeo.org/grass/changeset/51126

2012/3/23 Daniel Victoria :
> Hi all,
>
> Just updated to the latest svn version of grass 7. Configure went OK
> but I got a bunch off errors on make, the first one being in
> display/d.path. So I went into that directory and issued make. The
> output is the following:
>
> daniel@debian:~/grass/grass_trunk/display/d.path$ make
> : && gcc -L/home/daniel/grass/grass_trunk/dist.i686-pc-linux-gnu/lib
> -L/home/daniel/grass/grass_trunk/dist.i686-pc-linux-gnu/lib
> -Wl,--export-dynamic
> -Wl,-rpath-link,/home/daniel/grass/grass_trunk/dist.i686-pc-linux-gnu/lib
>  -o /home/daniel/grass/grass_trunk/dist.i686-pc-linux-gnu/bin/d.path
> OBJ.i686-pc-linux-gnu/main.o OBJ.i686-pc-linux-gnu/select.o
> -lgrass_display.7.0.svn -lgrass_vector.7.0.svn -lgrass_gis.7.0.svn
> -lm
> /home/daniel/grass/grass_trunk/dist.i686-pc-linux-gnu/lib/libgrass_vector.7.0.svn.so:
> undefined reference to `OGR_L_GetName'
> /home/daniel/grass/grass_trunk/dist.i686-pc-linux-gnu/lib/libgrass_vector.7.0.svn.so:
> undefined reference to `OGR_L_GetGeomType'
> collect2: ld returned 1 exit status
> make: *** [/home/daniel/grass/grass_trunk/dist.i686-pc-linux-gnu/bin/d.path]
> Error 1
> daniel@debian:~/grass/grass_trunk/display/d.path$
>
> Am I missing some library? I could not understand anything from the
> error message. I'm running grass on a Debian system
>
> Thanks
> Daniel
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] GRASS 7 Bottleneck

[Sören Gebbert]

Hi Seth,
more inline:

2012/2/28 Seth Price :
> I'm running a few instances of GRASS, and I've hit an extreme bottleneck. The 
> problem is that I can't figure out what it is.
>
> I have a module that I wrote in the GRASS 7.0 environment that should be I/O 
> bound. It normally takes about 10 minutes to finish running. I have seven 
> instances running from one disk, and each one is taking on the order of 10 
> hours to finish. Why?
>
> NOTE:
> - The processes aren't I/O bound. 'iostat' lists a constant 30 MB/s transfer 
> rate. It should be able to handle twice that. The transfers per second are < 
> 100, and I've seen it handle triple that (at 60 MB/s).
> - The load average is currently below 1. I have 16 processors, so CPU 
> shouldn't be a problem.
> - I have 16 GB of RAM, and it's full, but not thrashing.

Since you have plenty of RAM, the Linux system might buffer a lot of
the module input/output in the main memory. So the bottleneck may
appear when Linux tries to write the buffered output to the disc.
Does the load value not change in the 10h of processing? Is the
transfer rate constant over the 10h?
My guess is that when your module reads and writes permanently to the
file system it is IO bound and your hard disk is the limiting factor
not the GRASS (raster, vector or voxel) IO implementation.

I assume the seven instances writing to different maps?

For comparison: I have a 24 Core + 64Gig Ram number cruncher, running
24 parallel processes of v.surf.idw for interpolation purpose. HD's
are 4x256GB SSD's in a fast raid configuration. Max write speed i have
measured is about 400MByte/s with large files. This scales very well
without any performance issues with 24 processes which are not IO
bound.

Best regards
Soeren

>
> If it's not I/O, CPU, or RAM, then what is it slowing GRASS?
> Thanks,
> Seth___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Python programming manual is down?

[Sören Gebbert]

Many thanks Markus.

Cheers
Soeren

2012/2/14 Markus Neteler :
> On Tue, Feb 14, 2012 at 3:58 PM, Markus Neteler  wrote:
>> On Tue, Feb 14, 2012 at 3:11 PM, Jeff Heard  
>> wrote:
>>> I'm getting 404s for both http://grass.osgeo.org/programming7/pythonlib.html
>>> and http://grass.osgeo.org/programming6/pythonlib.html .  Has the manual
>>> been moved?
>>
>> After the Debian upgrade of the machine I have to update the cronjobs, too.
>
> Done - both manuals are back.
>
> Markus
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Re: GRASS EXAMPLE

[Sören Gebbert]

Hi Hrachya,
make sure you started a valid grass session before you execute any
grass command.
Does only r.example segfault or any other command too?

Best
Soeren

Hint:
I would avoid to use the root account when working with grass 

2012/1/21 Hrachya Astsatryan :
> After the compilation, r.example gives "Segmentation fault"
>
> [root@wn1 r.example]# /usr/local/grass-6.4.2svn/bin/r.example
> Segmentation fault
>
>
>
> On 1/21/12 11:03 PM, Martin Landa wrote:
>
> Hi,
>
> 2012/1/21 Hrachya Astsatryan :
>
> I have installed successfully the Grass via elgis.repo (see below)
> [root@wn1 grass-6.4.1]# yum list|grep grass|more
> grass.x86_64 6.4.1-2.el5.elgis
> installed
> grass-devel.x86_64   6.4.1-2.el5.elgis
> installed
> grass-libs.x86_64    6.4.1-2.el5.elgis
> installed
>
> So What should I do else?
>
> well, GRASS 6.4.2 has been released yet, you could try to compile
> GRASS [1] on your own or to wait for 6.4.2 release. Quick solution
> could be to copy `Make` directory from SVN [2] to your `include`
> directory. Anyway `grass-devel` seems to be incomplete in this repo.
>
> Martin
>
> [1] http://trac.osgeo.org/grass/wiki/BuildingOnUnix
> [2]
> http://svn.osgeo.org/grass/grass/tags/release_20110412_grass_6_4_1/include/Make/
>
>
>
> --
> Hrachya Astsatryan
> Head of HPC Laboratory,
> Institute for Informatics and Automation Problems,
> National Academy of Sciences of the Republic of Armenia
> 1, P. Sevak str., Yerevan 0014, Armenia
> t: 374 10 284780
> f: 374 10 285812
> e: hr...@sci.am
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Draping of Raster images

[Sören Gebbert]

Hi Anna,
what you are looking for is a visualization task -> putting a texture
on a 2.5D surface.
Luckily this can be done using the combination of GRASS and VTK/Paraview[1].

Use r.out.vtk to export your elevation and satellite image as a single VTK file.
Then visualize this file with Paraview:

r.out.vtk input=satelite_image elevation=my_elev_map output=data.vtk

paraview --data=data.vtk

You need to chose a color table in paraview to color the satellite image.
In case you have RGB color use the rgbmaps option of r.out.vtk:

r.out.vtk rgbmaps=redmap,greenmap,bluemap elevation=my_elev_map output=data.vtk

Best regards
Soeren

[1] http://www.paraview.org

2011/11/3 Anna Hodgkinson :
> Hi,
>
> I tried r.to.rast3elev, however, that creates 3D volumes, rather than 
> surfaces, doesn't it? And nviz has problems displaying those, I've never 
> managed it.
>
> Yes, I would like to "drape" a flat 2D raster image over 3D raster surfaces 
> or vector data. However, I would like to retain that elevation information, 
> basically create a 3D (or 2.5D) raster image from a flat one.
>
>
> Here's the case study:
> I have a flat satellite image for my site.
> I also have topological survey data, in the shape of a points vector layer, 
> with z-values in the attribute table. I have a 3D layer of the same, created 
> by using v.to.3d
> I furthermore have an interpolated raster surface from the points survey 
> data, which is 2.5D.
>
> I would now like to drape the 2D satellite image over either the vector 
> points or their interpolated surface and thus create a 2.5 / 3D version of 
> the same satellite image, which I can then visualize in 3D, standalone.
>
> Many thanks!
>
> Anna
>
>
> - Original Message -
> From: "Markus Metz" 
> To: "Anna Hodgkinson" 
> Cc: "grass-user grass-user" 
> Sent: Thursday, 3 November, 2011 2:45:18 PM
> Subject: Re: [GRASS-user] Draping of Raster images
>
> On Thu, Nov 3, 2011 at 3:32 PM, Anna Hodgkinson
>  wrote:
>> Thank you, but neither of those would work for me - what I'm trying to
>> do is to make a 2D raster image 3D.
>> And I don't mean visualisation, I mean assigning cell values for
>> elevation from either another 3D surface or vector layer (both of
>> which I have).
>
> Do you mean something like r.to.rast3elev?
> http://grass.osgeo.org/grass64/manuals/html64_user/r.to.rast3elev.html
>
> The link you gave only shows how to drape a 2D raster over elevation,
> it does not show how to assign z-coordinates and create a 3D raster.
>
> Maybe the confusion goes away if you could explain what you want to do
> with the 3D raster.
>
> Markus M
>
>>
>> Sorry!
>>
>> Anna
>>
>>
>> - Original Message -
>> From: "Saber Razmjooei" 
>> To: "Anna Hodgkinson" 
>> Cc: "Saber Razmjooei" , "grass-user
>> grass-user" 
>> Sent: Thursday, 3 November, 2011 2:21:23 PM
>> Subject: Re: [GRASS-user] Draping of Raster images
>>
>> Alternatively, you can use:
>>
>> r.shaded.relied
>>
>> That will be 2D only.
>>
>>
>>
>>
>>> Thanks, but there doesn't seem to be a way of elevating a 2D raster
>>> surface. Do you have any experience with this, and would know what
>>> command to use?
>>>
>>> Many thanks,
>>>
>>> Anna
>>>
>>>
>>> - Original Message -
>>> From: "Saber Razmjooei" 
>>> To: "Anna Hodgkinson" 
>>> Cc: grass-user@lists.osgeo.org
>>> Sent: Thursday, 3 November, 2011 1:52:36 PM
>>> Subject: Re: [GRASS-user] Draping of Raster images
>>>
>>> This page might be helpful:
>>>
>>> http://grass.osgeo.org/wiki/Help_with_3D
>>>
>>>
>>> Cheers
>>> Saber
>>>
 Dear all,

 I was wondering whether it is possible to use GRASS to drape raster
 images over existing 3D surfaces or vector layers.

 I know ArcGIS is capable of this, is seems a fairly straight-forward
 procedure there
 (http://webhelp.esri.com/arcgisdesktop/9.3/tutorials/3D_analyst/3D_5.htm),
 so I was hoping to achieve the same using open source GIS.

 GRASS has a v.drape module, which can drape vector layers over 3D
 surfaces, NVIZ seems to do the same.

 It would be great if someone could tell me that GRASS (or any other
 open source GIS package) is capable of draping raster images over
 either other
 rasters or vectors containing elevation information.

 Many thanks and all the best,

 Anna

 __ Anna Kathrin
 Hodgkinson MA MSt (Oxon) AIFA EES
 Supervisor Geomatics

 Oxford Archaeology: Exploring the Human Journey
 Mobile: +44 (0)7906 638308 (personal)
 Direct Dial: +44 (0)1865 980 855
 http://thehumanjourney.net

 Files attached to this email may be in ISO 26300 format (OASIS Open
 Document Format). If you have difficulty opening them, please visit
 http://iso26300.info for more information.

 This email has been processed by SmoothZap - www.smoothwall.net

 ___ grass-user mailing
 list grass-user@

Re: [GRASS-user] create a new vector map and add attributes

[Sören Gebbert]

http://trac.osgeo.org/grass/browser/grass/trunk/vector/v.random/main.c

2011/10/27 Mohammed Rashad :
> How to create a new vector map by code and define its attribute table?
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] cloud removal

[Sören Gebbert]

http://glovis.usgs.gov/

2011/10/14 Mohammed Rashad :
>
> thanks
> can you provide some sample data
> 2011/10/14 Sören Gebbert 
>>
>> http://grass.osgeo.org/wiki/GRASS_AddOns#i.landsat.acca
>>
>> 2011/10/14 Mohammed Rashad :
>> >
>> > How to remove cloud from a satellite imagery maybe landsat using GRASS
>> > GIS
>> > --
>> > Regards,
>> >    Mohammed Rashad K M
>> >    M.S. (By Research) student
>> >    Lab for Spatial Informatics
>> >    Department of CSE
>> >    International Institute of Information Technology
>> >    Hyderabad, India
>> >
>> > ___
>> > grass-user mailing list
>> > grass-user@lists.osgeo.org
>> > http://lists.osgeo.org/mailman/listinfo/grass-user
>> >
>> >
>
>
>
> --
> Regards,
>    Mohammed Rashad K M
>    M.S. (By Research) student
>    Lab for Spatial Informatics
>    Department of CSE
>    International Institute of Information Technology
>    Hyderabad, India
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] cloud removal

[Sören Gebbert]

http://grass.osgeo.org/wiki/GRASS_AddOns#i.landsat.acca

2011/10/14 Mohammed Rashad :
>
> How to remove cloud from a satellite imagery maybe landsat using GRASS GIS
> --
> Regards,
>    Mohammed Rashad K M
>    M.S. (By Research) student
>    Lab for Spatial Informatics
>    Department of CSE
>    International Institute of Information Technology
>    Hyderabad, India
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Re: [GRASS-dev] Re: wiki down

[Sören Gebbert]

Many thanks Martin.

Sören
 Am 22.09.2011 21:00 schrieb "Martin Landa" :
> Hi,
>
> 2011/9/22 Martin Landa :
>> user-wiki is down due to maintenance for some time (hours). Please use
>> read-only mirror instead
>
> wiki is available again and updated to 1.17
>
> Enjoy, Martin
>
> --
> Martin Landa  * http://geo.fsv.cvut.cz/~landa
> ___
> grass-dev mailing list
> grass-...@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] problems with r.to.rast3elev

[Sören Gebbert]

Hi Carlos,
please try svn revision 48398 of grass7.

I think the reason was the wrong computation of the tile size, because
the chosen variable types are not large enough. This should be fixed
now.

I hope it works now.

Best regards
Soeren



2011/9/21 Carlos Grohmann :
> Thanks Soeren,
>
> As a side note, it did run on my Mac, using Kygschaos package (6.4.1, I
> guess)...
>
> here is the output if g.region -p3:
>
> GRASS 7.0.svn (santa_catarina@dunas2):~ > g.region -p3
> projection: 1 (UTM)
> zone:   -22
> datum:  wgs84
> ellipsoid:  wgs84
> north:  6901400
> south:  6899300
> west:   731900
> east:   732900
> top:    60.
> bottom: 0.
> nsres:  0.5
> nsres3: 0.5
> ewres:  0.5
> ewres3: 0.5
> tbres:  0.5
> rows:   4200
> rows3:  4200
> cols:   2000
> cols3:  2000
> depths: 120
> cells:  840
> cells3: 100800
>
>
>
> and here of gdb:
>
> GRASS 7.0.svn (santa_catarina@dunas2):~ >  r.to.rast3elev --overwrite
> input=mask_volume_garopaba elevation=garopaba_SOLO_bicubic
> output=garopaba_vol05m lower=1
> Creating 3D raster map
> Segmentation fault
> GRASS 7.0.svn (santa_catarina@dunas2):~ > gdb `which r.to.rast3elev`
> GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
> Copyright (C) 2010 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "i686-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from /usr/local/grass-7.0.svn/bin/r.to.rast3elev...(no
> debugging symbols found)...done.
> (gdb) run  input=mask_volume_garopaba elevation=garopaba_SOLO_bicubic
> output=garopaba_vol05m lower=1
> Starting program: /usr/local/grass-7.0.svn/bin/r.to.rast3elev
> input=mask_volume_garopaba elevation=garopaba_SOLO_bicubic
> output=garopaba_vol05m lower=1
> Creating 3D raster map
>    0%
> Program received signal SIGSEGV, Segmentation fault.
> 0xb7fb5ae4 in Rast_set_d_null_value () from
> /usr/local/grass-7.0.svn/lib/libgrass_raster.7.0.svn.so
> (gdb) bt full
> #0  0xb7fb5ae4 in Rast_set_d_null_value ()
>    from /usr/local/grass-7.0.svn/lib/libgrass_raster.7.0.svn.so
> No symbol table info available.
> #1  0xb7fd3611 in Rast3d_set_null_value ()
>    from /usr/local/grass-7.0.svn/lib/libgrass_g3d.7.0.svn.so
> No symbol table info available.
> #2  0xb7fd6a92 in Rast3d_set_null_tile_type ()
>    from /usr/local/grass-7.0.svn/lib/libgrass_g3d.7.0.svn.so
> No symbol table info available.
> #3  0xb7fd6e3e in Rast3d_read_tile () from
> /usr/local/grass-7.0.svn/lib/libgrass_g3d.7.0.svn.so
> No symbol table info available.
> #4  0xb7fc9288 in ?? () from
> /usr/local/grass-7.0.svn/lib/libgrass_g3d.7.0.svn.so
> No symbol table info available.
> #5  0xb7fc89fb in Rast3d_cache_elt_ptr () from
> /usr/local/grass-7.0.svn/lib/libgrass_g3d.7.0.svn.so
> No symbol table info available.
> #6  0xb7fd642d in Rast3d_get_tile_ptr () from
> /usr/local/grass-7.0.svn/lib/libgrass_g3d.7.0.svn.so
> No symbol table info available.
> #7  0xb7fd4761 in Rast3d_put_double () from
> /usr/local/grass-7.0.svn/lib/libgrass_g3d.7.0.svn.so
> No symbol table info available.
> #8  0x08049880 in elev_raster_to_g3d ()
> No symbol table info available.
> #9  0x08049e6e in main ()
> No symbol table info available.
> (gdb) l
> No symbol table is loaded.  Use the "file" command.
> (gdb) frame 2
> #2  0xb7fd6a92 in Rast3d_set_null_tile_type ()
>    from /usr/local/grass-7.0.svn/lib/libgrass_g3d.7.0.svn.so
> (gdb) l
> No symbol table is loaded.  Use the "file" command.
> (gdb)
>
>
>
> best,
>
> Carlos
>
>
>
> 2011/9/21 Sören Gebbert 
>>
>> Hi Carlos,
>> can you please provide more information about the grass7 segfault?
>>
>> Can you please print your region settings (g.region -p3)?
>>
>> Can you please use gdb or valgrind to check at which line in the code
>> the segfault appears?
>>
>> I will try to fix this issue in grass7, but i cant reproduce it on my
>> system.
>>
>> Best regards
>> Soeren
>>
>> 2011/9/20 Carlos Grohmann :
>> > Hello all,
>> >
>> > I'm experiencing some issues with r.to.rast3elev , that I didn't had
>> > before.
>> > I'm trying to reprocess some volume calculation
>> &

Re: [GRASS-user] problems with r.to.rast3elev

[Sören Gebbert]

Hi Carlos,
can you please provide more information about the grass7 segfault?

Can you please print your region settings (g.region -p3)?

Can you please use gdb or valgrind to check at which line in the code
the segfault appears?

I will try to fix this issue in grass7, but i cant reproduce it on my system.

Best regards
Soeren

2011/9/20 Carlos Grohmann :
> Hello all,
>
> I'm experiencing some issues with r.to.rast3elev , that I didn't had before.
> I'm trying to reprocess some volume calculation
> on dune fields in southern Brazil (see this:
> http://geomorphometry.org/Grohmann2011) so I can evolve what I presented in
> the Geomorphometry Meeting into a full paper, but at this point I can't
> calculate the volumes any more!
>
> (BTW, Helena, I'm thinking about comparing the volumes from r.volume and
> r.to.rast3elev, since I think there will be differences..)
>
> OS: Linux, Ubuntu 11.04
> In GRASS 6.4.1, installed from Ubuntu repositories, I got this (running
> inside a python session):
>
>  grass.run_command('r.to.rast3elev', input=clump, elevation=dem,
> output=dem3d, lower=1, overwrite=True)
> Creating 3D raster map
> ERROR: G3d_cache_hash_remove_name: name not in hashtable
>
> and in GRASS 7.0svn updated today, I got a segmentation fault.
>
> the region is set to match the 'clump' map (which is the same as the mask,
> to limit the calculations to the active dunes).
>
> any help is appreciated
>
> Carlos
>
>
>
>
> --
> Prof. Carlos Henrique Grohmann - Geologist D.Sc.
> Institute of Geosciences - Univ. of São Paulo, Brazil
> ---
> http://www.igc.usp.br/pessoais/guano
> http://digitalelevation.wordpress.com/
> http://lattes.cnpq.br/5846052449613692 (CV)
> ---
> Twitter: @CarlosGrohmann
> http://carlosgrohmann.tumblr.com/
> Linux User #89721
> 
> Can’t stop the signal.
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user