Re: [GRASS-dev] Regarding testing

2018-05-15 Thread Sanjeet 
On Tue, May 15, 2018 at 7:47 PM, Luca Delucchi  wrote:
> On 13 May 2018 at 08:12, Sanjeet  wrote:
> Hi Sanjeet
> What other devs think about the patches?
>
> They seem ok for me, I tested and they work
>
>> Please take a look here:
>> https://github.com/sanjeetbhatti/FullSupportPython3
>>
>> For other tests, I have created a google sheet:
>> https://docs.google.com/spreadsheets/d/1eAIJtegNWSbBscFChhQzMTl0vmbGPjmrW_013hSw9bI

Hi Luca,

Sorry about the access, I thought I already had given access, but it
is provided now. :)

> A comment about results, for me the test_doctest.py is working fine
> with Python 3.5.3
>
>  100%
>  100%
> Loading floating point data with 8 bytes ... (6x4x3)
>  100%
> Loading floating point data with 8 bytes ... (6x4x3)
>  100%
> .
> --
> Ran 1 test in 0.785s
> OK

I will test it again on the Python 3.6.5 as well as on the version
that you mentioned (3.5.3).

Thanks
-- 
Sanjeet Bhatti
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3563: v.in.ogr can't create tables in GRASS 7.4

2018-05-15 Thread GRASS GIS 
#3563: v.in.ogr can't create tables in GRASS 7.4
+-
  Reporter:  pierreroudier  |  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:
 Component:  Vector |Version:  7.4.0
Resolution: |   Keywords:
   CPU:  Unspecified|   Platform:  Unspecified
+-

Comment (by hellik):

 >ORDER: Real (0.0)

 Order may be a SQL reserved word. try to rename it before

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #3563: v.in.ogr can't create tables in GRASS 7.4

2018-05-15 Thread GRASS GIS 
#3563: v.in.ogr can't create tables in GRASS 7.4
---+-
 Reporter:  pierreroudier  |  Owner:  grass-dev@…
 Type:  defect | Status:  new
 Priority:  normal |  Milestone:
Component:  Vector |Version:  7.4.0
 Keywords: |CPU:  Unspecified
 Platform:  Unspecified|
---+-
 I don't seem to be able to import OGR sources (I tried both ESRI Shapefile
 and GPKG sources):


 {{{
 GRASS 7.4.0 (nz_soil_ph):~ > v.in.ogr in=river-flows.gpkg out=rivers --o
 Check if OGR layer  contains polygons...
  100%
 WARNING: Vector map  already exists and will be overwritten
 Creating attribute table for layer ...
 DBMI-SQLite driver error:
 Error in sqlite3_prepare():
 near "ORDER": syntax error

 DBMI-SQLite driver error:
 Error in sqlite3_prepare():
 near "ORDER": syntax error

 ERROR: Unable to create table: 'create table rivers (cat integer, ORDER
double precision, NZREACH double precision, MALFCumecs double
precision, MeanFlowCumecs double precision, Feb double precision,
FRE3 double precision, SpecMeanFlowCumecs double precision,
SpecMALFCumecs double precision, Shape_Length double precision)'

 }}}

 Here is more info about the dataset I'm using:

 {{{
 GRASS 7.4.0 (nz_soil_ph):~ > ogrinfo -al -so river-flows.gpkg
 INFO: Open of `Dropbox/projects/nz-national-grid-ph/covariates/river-
 flows.gpkg'
   using driver `GPKG' successful.

 Layer name: river_flows

 [...]

 Geometry: Multi Line String
 Feature Count: 576277
 Extent: (1090150.00, 4748850.00) - (2089110.00,
 6193370.00)
 Layer SRS WKT:
 PROJCS["NZGD2000 / New Zealand Transverse Mercator 2000",
 GEOGCS["NZGD2000",
 DATUM["New_Zealand_Geodetic_Datum_2000",
 SPHEROID["GRS 1980",6378137,298.257222101,
 AUTHORITY["EPSG","7019"]],
 TOWGS84[0,0,0,0,0,0,0],
 AUTHORITY["EPSG","6167"]],
 PRIMEM["Greenwich",0,
 AUTHORITY["EPSG","8901"]],
 UNIT["degree",0.0174532925199433,
 AUTHORITY["EPSG","9122"]],
 AUTHORITY["EPSG","4167"]],
 PROJECTION["Transverse_Mercator"],
 PARAMETER["latitude_of_origin",0],
 PARAMETER["central_meridian",173],
 PARAMETER["scale_factor",0.9996],
 PARAMETER["false_easting",160],
 PARAMETER["false_northing",1000],
 UNIT["metre",1,
 AUTHORITY["EPSG","9001"]],
 AUTHORITY["EPSG","2193"]]
 FID Column = fid
 Geometry Column = geom
 ORDER: Real (0.0)
 NZREACH: Real (0.0)
 MALFCumecs: Real (0.0)
 MeanFlowCumecs: Real (0.0)
 Feb: Real (0.0)
 FRE3: Real (0.0)
 SpecMeanFlowCumecs: Real (0.0)
 SpecMALFCumecs: Real (0.0)
 Shape_Length: Real (0.0)
 }}}

 This dataset is publicly available: https://data.mfe.govt.nz/layer/53309
 -river-flows/

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Regarding testing

2018-05-15 Thread Luca Delucchi 
On 13 May 2018 at 08:12, Sanjeet  wrote:
> On Wed, May 9, 2018 at 3:30 AM, Luca Delucchi  wrote:
>> On 8 May 2018 at 07:39, Sanjeet  wrote:
>>> I made some minor changes in 'utils.py' in lib/python/script and
>>> 'test_utils.py' in its testsuite.
>>> https://github.com/sanjeetbhatti/FullSupportPython3/blob/master/patch.diff
>>>
>>> The Python 3's bytes cannot contain ASCII literal characters,
>>> therefore I can't seem to test it as such, I encoded it first before
>>> checking for an assertion, which I am not sure is a correct way to do
>>> so as we are ensuring that we do not pass any bytes with ASCII literal
>>> characters.
>>
>> could be this a problem with languages using strange accent mark?
>> We had and have problem with some languages in translations
>>
>>> Same thing is in test_start_command_functions.py.
>>> Moreover, I generalized the encode and decode functions by using
>>> string conversion for int and float values.
>>>
>>> Please let me know if this is the correct way to go about it.
>>>
>> It seems correct to me, but please Anna answer
>
> Hi Anna and Luca,
>

Hi Sanjeet

> I have been working with scripts and testing them with python3 and I
> made some changes in 2 different patches:
> 1. patch.diff -> has changes for unicode/bytes in utils and its
> test_utils.py along with test_start_command_functions.py (depending on
> the changes in utils)
> 2. raster.diff -> has changes for raster.py
>

What other devs think about the patches?

They seem ok for me, I tested and they work

> Please take a look here:
> https://github.com/sanjeetbhatti/FullSupportPython3
>
> For other tests, I have created a google sheet:
> https://docs.google.com/spreadsheets/d/1eAIJtegNWSbBscFChhQzMTl0vmbGPjmrW_013hSw9bI
>

A comment about results, for me the test_doctest.py is working fine
with Python 3.5.3

 100%
 100%
Loading floating point data with 8 bytes ... (6x4x3)
 100%
Loading floating point data with 8 bytes ... (6x4x3)
 100%
.
--
Ran 1 test in 0.785s
OK


> I'm working on few other testsuites and hoping to have a couple of
> patches submitted by tomorrow.
>
> Thanks
> --
> Sanjeet Bhatti



-- 
ciao
Luca

www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.1

2018-05-15 Thread Helmut Kudrnovsky 
Markus Neteler wrote
> On Tue, May 15, 2018 at 11:46 AM, Martin Landa 

> landa.martin@

>  wrote:
>> Hi Markus,
> ...
>> it's two weeks from RC1, I would go ahead with RC2. Any objections?
>> Martin
> 
> Yes, fine for me. I can tag it tomorrow night.

what are the main fixes to go from RC1 to RC2?

tested RC1 on windows and debian, so far ok.



-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3546: t.rast.what: issues in one_point_per_col_output()

2018-05-15 Thread GRASS GIS 
#3546: t.rast.what: issues in one_point_per_col_output()
---+-
  Reporter:  sbl   |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:  7.4.1
 Component:  Temporal  |Version:  7.4.0
Resolution:|   Keywords:  t.rast.what
   CPU:  All   |   Platform:  All
---+-

Comment (by sbl):

 Thanks for testing! If there is agreement on removing coordinates if cat
 is used, I can change that. Not sure if that can go to 7.4, though???

 Please also test attached new diff that fixes the empty column in the
 timerow output and an empty line if header is not requested...

 Looks now like this:

 {{{
 t.rast.what strds=A points=points layout=timerow -v
 1|115.004358627375|36.3593955782903|1|2|3|4
 2|79.681676382576|45.2391522852909|1|2|3|4
 3|97.4892579600048|79.2347263950131|1|2|3|4

 t.rast.what strds=A points=points layout=timerow -vn
 cat|x|y|1990-01-01 00:00:00;1990-02-01 00:00:00|1990-02-01
 00:00:00;1990-03-01 00:00:00|1990-03-01 00:00:00;1990-04-01
 00:00:00|1990-04-01 00:00:00;1990-05-01 00:00:00
 1|115.004358627375|36.3593955782903|1|2|3|4
 2|79.681676382576|45.2391522852909|1|2|3|4
 3|97.4892579600048|79.2347263950131|1|2|3|4

 t.rast.what strds=A points=points layout=timerow
 115.004358627375|36.3593955782903|1|2|3|4
 79.681676382576|45.2391522852909|1|2|3|4
 97.4892579600048|79.2347263950131|1|2|3|4

 echo "115 36 Loc1
 79 45 Loc2" | t.rast.what -i strds=A layout=timerow -n separator=','
 x,y,site,1990-01-01 00:00:00;1990-02-01 00:00:00,1990-02-01
 00:00:00;1990-03-01 00:00:00,1990-03-01 00:00:00;1990-04-01
 00:00:00,1990-04-01 00:00:00;1990-05-01 00:00:00
 115,36,Loc1,1,2,3,4
 79,45,Loc2,1,2,3,4
 }}}

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3546: t.rast.what: issues in one_point_per_col_output()

2018-05-15 Thread GRASS GIS 
#3546: t.rast.what: issues in one_point_per_col_output()
---+-
  Reporter:  sbl   |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:  7.4.1
 Component:  Temporal  |Version:  7.4.0
Resolution:|   Keywords:  t.rast.what
   CPU:  All   |   Platform:  All
---+-
Changes (by sbl):

 * Attachment "t.rast.what_timerow.diff" added.

 Fix empty column (and header)  in timerow outout

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] GSoC introduction Roberta Fagandini

2018-05-15 Thread Pierre Roudier 
Interesting to hear your results, Roberta -- the reason I brought this
up is that some of my colleagues (non-GRASS users :( ) tried it very
successfully.

Happy to follow up with them if need be,

P

On 15 May 2018 at 22:03, Roberta Fagandini  wrote:
> Hi Pierre!
> Thank you so much for your hints!
> I have already tested Fmask with Sentinel 2 images but I didn't have great
> results. However, it is worth investigating better!
> Thanks for all the references!
>
> Roberta
>
>
> 2018-05-15 0:51 GMT+02:00 Pierre Roudier :
>>
>> Hi Roberta,
>>
>> On top of the review linked by Vero, I thought I'd mention the Fmask
>> procedure -- it seems to give great results and there is a python
>> library on Github.
>>
>> *Relevant GRASS GIS tickets*:
>>
>> https://trac.osgeo.org/grass/ticket/3473
>> https://trac.osgeo.org/grass/ticket/3283
>>
>> *Papers*:
>>
>>
>> https://www.researchgate.net/publication/270596187_Improvement_and_expansion_of_the_Fmask_algorithm_Cloud_cloud_shadow_and_snow_detection_for_Landsats_4-7_8_and_Sentinel_2_images
>>
>> https://www.researchgate.net/publication/324836341_Improvement_of_the_Fmask_algorithm_for_Sentinel-2_images_Separating_clouds_from_bright_surfaces_based_on_parallax_effects
>>
>> *Software*:
>>
>> http://pythonfmask.org/en/latest/
>> https://github.com/prs021/fmask
>>
>> Hopefully this is helpful,
>>
>> Pierre
>>
>> On 7 May 2018 at 19:49, Roberta Fagandini  wrote:
>> >
>> >
>> > 2018-05-06 21:52 GMT+02:00 Veronica Andreo :
>> >>
>> >> Hey Robi,
>> >
>> >
>> > Hi Vero!!
>> >
>> >>
>> >>
>> >> I just found this review [0]. It is for Landsat, but maybe some
>> >> insights
>> >> could be also useful for you (?)
>> >
>> >
>> > Thank you so much! I know this paper and it could be very useful
>> > especially
>> > for the second part of the procedure.
>> > I'll read it carefully!
>> >
>> >>
>> >>
>> >> Cheers :),
>> >> Vero
>> >
>> >
>> > Thanks!
>> > Robi
>> >
>> >>
>> >>
>> >> [0]
>> >>
>> >> https://www.researchgate.net/publication/324975294_Cloud_and_Cloud_Shadow_Detection_for_Landsat_Images_The_Fundamental_Basis_for_Analyzing_Landsat_Time_Series
>> >>
>> >> El jue., 3 may. 2018 a las 22:06, Roberto Marzocchi
>> >> () escribió:
>> >>>
>> >>> Nice! The last step of the script you have written in python works as
>> >>> you
>> >>> expected.
>> >>>
>> >>> Now it is important to draw a diagram (or schema ) as a summary for
>> >>> you
>> >>> (you have worked a lot in the last few months) and to share it with
>> >>> Moritz
>> >>> and Markus.
>> >>>
>> >>> After that, test, test and test ;-) for validation/calibration of the
>> >>> automatic procedure.
>> >>>
>> >>> R
>> >>>
>> >>> 2018-05-03 18:48 GMT+02:00 Roberta Fagandini
>> >>> :
>> 
>> 
>>  2018-05-03 14:03 GMT+02:00 Moritz Lennert
>>  :
>> >
>> > Hi Roberta,
>> 
>> 
>>  Hi Moritz and Roberto!
>> 
>> >
>> >
>> > On 25/04/18 18:03, Roberta Fagandini wrote:
>> >>
>> >>
>> >>
>> >> 2018-04-25 16:03 GMT+02:00 Moritz Lennert
>> >> > >> >:
>> >> Looking at your bash scripts, I think the first thing to do
>> >> during
>> >> this bonding period is, as you planned yourself, to get
>> >> familiar
>> >> with the writing of GRASS modules in Python. You can have a
>> >> look
>> >> at
>> >> existing scripts [1, 2] to get feeling for this works and how
>> >> to
>> >> structure addon code in order to make it directly installable
>> >> with
>> >> g.extension.
>> >>
>> >> You can find the actual function definitions and documentation
>> >> of
>> >> the GRASS Python scripting library at [3]. The functions in
>> >> that
>> >> library should be more than enough to translate your scripts
>> >> into
>> >> a
>> >> (or several) modules.
>> >>
>> >> Be aware that GRASS modules create their own GUI. So, unless
>> >> you
>> >> need some interactive features in your modules, you will not
>> >> have
>> >> to
>> >> program your own GUI.
>> >>
>> >>
>> >> Thank you for your precious suggestions! I'll start studying how to
>> >> write a GRASS module in Python in the next days and at the same
>> >> time I will
>> >> keep on testing the procedures so as to show you some results and
>> >> fix some
>> >> open points.
>> >>
>> >>
>> >> Something else you should probably do during this bonding time
>> >> is
>> >> to
>> >> elaborate a schema of your algorithm, so that it is easier to
>> >> understand what it does at each step.
>> >>
>> >>
>> >> Yes, this could be very useful also for me in order to better
>>

Re: [GRASS-dev] [release planning] 7.4.1

2018-05-15 Thread Markus Neteler 
On Tue, May 15, 2018 at 11:46 AM, Martin Landa  wrote:
> Hi Markus,
...
> it's two weeks from RC1, I would go ahead with RC2. Any objections? Martin

Yes, fine for me. I can tag it tomorrow night.

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

Re: [GRASS-dev] [GRASS GIS] #3546: t.rast.what: issues in one_point_per_col_output()

2018-05-15 Thread GRASS GIS 
#3546: t.rast.what: issues in one_point_per_col_output()
---+-
  Reporter:  sbl   |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:  7.4.1
 Component:  Temporal  |Version:  7.4.0
Resolution:|   Keywords:  t.rast.what
   CPU:  All   |   Platform:  All
---+-

Comment (by veroandreo):

 I tested the fix following the example in trunk (with the fix) and in
 release branch. Personally, I would prefer to get only cat number when
 using -v flag. Default could still be the coords (-n) and -v only cat
 values.

 Moreover, testing different layouts, I found that when using
 `layout=timerow`, there's an extra empty column or line according if I use
 -vn or only -v (but this also happens in release branch, without the fix):

 {{{
 t.rast.what strds=A points=points layout=timerow -vn
 cat|x|y|1990-01-01 00:00:00;1990-02-01 00:00:00|1990-02-01
 00:00:00;1990-03-01 00:00:00|1990-03-01 00:00:00;1990-04-01
 00:00:00|1990-04-01 00:00:00;1990-05-01 00:00:00
 1|115.004358627375|36.3593955782903||1|2|3|4
 2|79.681676382576|45.2391522852909||1|2|3|4
 3|97.4892579600048|79.2347263950131||1|2|3|4

 t.rast.what strds=A points=points layout=timerow -v

 1|115.004358627375|36.3593955782903||1|2|3|4
 2|79.681676382576|45.2391522852909||1|2|3|4
 3|97.4892579600048|79.2347263950131||1|2|3|4
 }}}

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] new proj(4)/GDAL development/improvement

2018-05-15 Thread Helmut Kudrnovsky 
have a look into

https://lists.osgeo.org/pipermail/gdal-dev/2018-May/048552.html

for interesting new proj(4)/GDAL development





-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Community Bonding Period Activity Report "Full support of Python 3 in GRASS GIS"

2018-05-15 Thread Sanjeet 
Hi all,

I have completed the following tasks during the community bonding period:
* Introduction to Community
* Created Project Wiki page and added links on the official wiki pages
* Set up my code repository and my development environment.
* Had a discussion with mentors about the libraries' tests for the project
* Got familiar with the testing framework, python script library,
followed tutorials for it.
* Updated current tests of the python script library, adjust them to
work with Python3
* Read the documentation and practiced fixing bugs

You can find the details on my wiki page here:
https://trac.osgeo.org/grass/wiki/GSoC/2018/FullSupportPython3#CommunityBondingPeriodReport

Regards,
-- 
Sanjeet Bhatti
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] 7.4.1

2018-05-15 Thread Moritz Lennert 

Am 15.05.2018 11:46 schrieb Martin Landa:

Hi Markus,

2018-05-07 23:37 GMT+02:00 Martin Landa :

experimental package for Ubuntu Xenial also available in UbuntuGIS
Expr [1]. Will prepare package also for Bionic (18.04LTS). I am
planning drop support for Trusty (OldOld LTS) - build packages only on
request.


it's two weeks from RC1, I would go ahead with RC2. Any objections? 
Martin


None from me.

Moritz

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

Re: [GRASS-dev] GSoC introduction Roberta Fagandini

2018-05-15 Thread Roberta Fagandini 
Hi Pierre!
Thank you so much for your hints!
I have already tested Fmask with Sentinel 2 images but I didn't have great
results. However, it is worth investigating better!
Thanks for all the references!

Roberta

2018-05-15 0:51 GMT+02:00 Pierre Roudier :

> Hi Roberta,
>
> On top of the review linked by Vero, I thought I'd mention the Fmask
> procedure -- it seems to give great results and there is a python
> library on Github.
>
> *Relevant GRASS GIS tickets*:
>
> https://trac.osgeo.org/grass/ticket/3473
> https://trac.osgeo.org/grass/ticket/3283
>
> *Papers*:
>
> https://www.researchgate.net/publication/270596187_Improveme
> nt_and_expansion_of_the_Fmask_algorithm_Cloud_cloud_shadow_
> and_snow_detection_for_Landsats_4-7_8_and_Sentinel_2_images
> https://www.researchgate.net/publication/324836341_Improveme
> nt_of_the_Fmask_algorithm_for_Sentinel-2_images_Separating_
> clouds_from_bright_surfaces_based_on_parallax_effects
>
> *Software*:
>
> http://pythonfmask.org/en/latest/
> https://github.com/prs021/fmask
>
> Hopefully this is helpful,
>
> Pierre
>
> On 7 May 2018 at 19:49, Roberta Fagandini  wrote:
> >
> >
> > 2018-05-06 21:52 GMT+02:00 Veronica Andreo :
> >>
> >> Hey Robi,
> >
> >
> > Hi Vero!!
> >
> >>
> >>
> >> I just found this review [0]. It is for Landsat, but maybe some insights
> >> could be also useful for you (?)
> >
> >
> > Thank you so much! I know this paper and it could be very useful
> especially
> > for the second part of the procedure.
> > I'll read it carefully!
> >
> >>
> >>
> >> Cheers :),
> >> Vero
> >
> >
> > Thanks!
> > Robi
> >
> >>
> >>
> >> [0]
> >> https://www.researchgate.net/publication/324975294_Cloud_and
> _Cloud_Shadow_Detection_for_Landsat_Images_The_Fundamental
> _Basis_for_Analyzing_Landsat_Time_Series
> >>
> >> El jue., 3 may. 2018 a las 22:06, Roberto Marzocchi
> >> () escribió:
> >>>
> >>> Nice! The last step of the script you have written in python works as
> you
> >>> expected.
> >>>
> >>> Now it is important to draw a diagram (or schema ) as a summary for you
> >>> (you have worked a lot in the last few months) and to share it with
> Moritz
> >>> and Markus.
> >>>
> >>> After that, test, test and test ;-) for validation/calibration of the
> >>> automatic procedure.
> >>>
> >>> R
> >>>
> >>> 2018-05-03 18:48 GMT+02:00 Roberta Fagandini  >:
> 
> 
>  2018-05-03 14:03 GMT+02:00 Moritz Lennert
>  :
> >
> > Hi Roberta,
> 
> 
>  Hi Moritz and Roberto!
> 
> >
> >
> > On 25/04/18 18:03, Roberta Fagandini wrote:
> >>
> >>
> >>
> >> 2018-04-25 16:03 GMT+02:00 Moritz Lennert
> >>  >>:
> >> Looking at your bash scripts, I think the first thing to do
> during
> >> this bonding period is, as you planned yourself, to get familiar
> >> with the writing of GRASS modules in Python. You can have a look
> >> at
> >> existing scripts [1, 2] to get feeling for this works and how to
> >> structure addon code in order to make it directly installable
> with
> >> g.extension.
> >>
> >> You can find the actual function definitions and documentation
> of
> >> the GRASS Python scripting library at [3]. The functions in that
> >> library should be more than enough to translate your scripts
> into
> >> a
> >> (or several) modules.
> >>
> >> Be aware that GRASS modules create their own GUI. So, unless you
> >> need some interactive features in your modules, you will not
> have
> >> to
> >> program your own GUI.
> >>
> >>
> >> Thank you for your precious suggestions! I'll start studying how to
> >> write a GRASS module in Python in the next days and at the same
> time I will
> >> keep on testing the procedures so as to show you some results and
> fix some
> >> open points.
> >>
> >>
> >> Something else you should probably do during this bonding time
> is
> >> to
> >> elaborate a schema of your algorithm, so that it is easier to
> >> understand what it does at each step.
> >>
> >>
> >> Yes, this could be very useful also for me in order to better
> organize
> >> and put in order everything!
> >>
> >
> > Have you advanced on any of this ? Do you have any questions ? Please
> > don't hesitate to ask on the mailing list.
> 
> 
>  Yes, I started working with GRASS Python scripting library. I'm
>  following the link [0] you suggested, I'm also looking at other
> existing
>  GRASS scripts [1,2] and moreover, Roberto gave me one of his scripts
> as an
>  example. I have just committed the first version of the python script
> I'm
>  working on, it works and I'm quite

Re: [GRASS-dev] [release planning] 7.4.1

2018-05-15 Thread Martin Landa 
Hi Markus,

2018-05-07 23:37 GMT+02:00 Martin Landa :
> experimental package for Ubuntu Xenial also available in UbuntuGIS
> Expr [1]. Will prepare package also for Bionic (18.04LTS). I am
> planning drop support for Trusty (OldOld LTS) - build packages only on
> request.

it's two weeks from RC1, I would go ahead with RC2. Any objections? Martin

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

Re: [GRASS-dev] [GRASS GIS] #3546: t.rast.what: issues in one_point_per_col_output()

2018-05-15 Thread GRASS GIS 
#3546: t.rast.what: issues in one_point_per_col_output()
---+-
  Reporter:  sbl   |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:  7.4.1
 Component:  Temporal  |Version:  7.4.0
Resolution:|   Keywords:  t.rast.what
   CPU:  All   |   Platform:  All
---+-

Comment (by sbl):

 Can be tested with example from the
 [https://grass.osgeo.org/grass74/manuals/t.rast.what.html manual]:


 {{{
 # Create test data
 g.region s=0 n=80 w=0 e=120 b=0 t=50 res=10

 # Generate data
 r.mapcalc expression="a_1 = 1" -s
 r.mapcalc expression="a_2 = 2" -s
 r.mapcalc expression="a_3 = 3" -s
 r.mapcalc expression="a_4 = 4" -s

 t.create type=strds output=A title="A test" descr="A test"

 t.register -i type=raster input=A maps=a_1,a_2,a_3,a_4 \
 start='1990-01-01' increment="1 month"

 v.random output=points n=3 seed=1
 }}}


 {{{
 #Query STRDS (please try this with and without r72636
 t.rast.what strds=A points=points layout=col -nv
 }}}

 Pay attention to the changes in the separators for the coordinates and cat
 in the header (and the different number of resulting columns)...

 Another option could be to remove coordinates from output, when cat is
 used (v-flag), cause coordinates would be redundant.

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #3562: wx.metadata not showing in g.extension

2018-05-15 Thread GRASS GIS 
#3562: wx.metadata not showing in g.extension
-+-
 Reporter:  sbl  |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:
Component:  Addons   |Version:  unspecified
 Keywords:  wx.metadata  |CPU:  All
 Platform:  Unspecified  |
-+-
 Just discovered, that wx.metadata addons are not showing in g.extension -l

 See:

 {{{
 g.extension -g | grep "g.gui"
 }}}
 or
 {{{
 g.extension -l | grep "g.gui"
 }}}

 Did not check how complete listing is otherwise...

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3361: v.select: very slow using GEOS operators

2018-05-15 Thread GRASS GIS 
#3361: v.select: very slow using GEOS operators
--+---
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  closed
  Priority:  normal   |  Milestone:  7.6.0
 Component:  Vector   |Version:  svn-trunk
Resolution:  fixed|   Keywords:  v.select GEOS within slow
   CPU:  Unspecified  |   Platform:  Unspecified
--+---
Changes (by neteler):

 * milestone:  7.4.1 => 7.6.0


-- 
Ticket URL: 
GRASS GIS 

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