Re: [GRASS-dev] GSoC Ideas

[Maris Nartiss via grass-dev]

f user
cancels the wizard, just fine. Let him enjoy the demo project and
display first time screen also on the next startup iff there is no
project with data in the GISDBASE. This would not interfere with a
big, fat warning if someone tries to import external data into sample
projects (NC, Spearfish, ...) or any other enhancements that could be
done.

Huh, I think I answered most of points from previous emails (except
going into details of potential architecture (thus Anna for wxPython
expertise) or user friendliness (thus Vero)). Thank you to everyone
who read this far and sorry for all unintentional fuss I caused.
Probably Linda you are right – it is too ambitious for an experimental
project that might get tossed away at the end. I see that Anna has
already removed the idea from the wiki, most likely for good. Do not
restore it, let it be so. We can return to this idea at any point
later if we feel need for it. I have plenty to do to fix pointer
juggling bugs in the new module I have almost finished (anisotropic
smoothing).
Māris.

piektd., 2024. g. 16. febr., plkst. 10:41 — lietotājs Linda Kladivová
() rakstīja:
>
> Hello Māris,
>
> just to add some other info, we did several surveys among GRASS users about 
> first-time user experience with Anna, Martin and Vashek and we also tested 
> old and new startup mechanisms in a real environment within the usability 
> testing - you can have a look at our article: 
> https://www.mdpi.com/2220-9964/12/9/376.
>
> As Anna has already written, the results of usability testing were indeed 
> mixed but I would like to emphasize one thing - most of the usability 
> participants (first-time users) said to me that they simply expect they will 
> be directly redirected to the main software window where they can start 
> working without knowing anything about the software. The current "info bar" 
> solution goes in that direction and although I have to admit that it has 
> flaws there are ways how to make it better and Anna has already written some 
> points.
>
> I think it would be nice to focus on how to make the current solution better 
> (it is definitely doable and even desirable) and not go back to some 
> alternatives to the old solution.
> Above that, it would be extremely time-consuming to implement any dialog 
> wizards and at the same time the impact of that "dialog" solution is very 
> uncertain - one important thing we also learned from surveys and discussions 
> inside/outside the community is that the one good generally acceptable 
> solution simply does not exist here - it will always be a compromise.
>
> Just my two cents. :-)
> Linda
>
> -- Původní e-mail --
> Od: Maris Nartiss via grass-dev 
> Komu: Anna Petrášová , Veronica Andreo 
> 
> Kopie: GRASS-dev 
> Datum: 15. 2. 2024 13:04:24
> Předmět: Re: [GRASS-dev] GSoC Ideas
>
> Hello Anna, Vero.
> I added the welcome screen idea we discussed during our Prague
> meeting. I think it would be a good GSOC project as it is quite easy
> and at the same time will allow to understand if it is the way to go.
> Anna, would you be able to be a co-mentor as it is a GUI project? Or
> who else could be?
> Vero, your user-centric view also would be valuable.
> Please edit the wiki accordingly.
>
> Thanks,
> Māris.
>
> sestd., 2024. g. 3. febr., plkst. 06:34 — lietotājs Anna Petrášová via
> grass-dev () rakstīja:
> >
> > Hi,
> >
> > I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac wiki, 
> > which I think we should be moving away from):
> > https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024
> >
> > It's not updated yet, I plan to add more topics. If you want to mentor a 
> > topic, we can discuss it here.
> >
> > Anna
> > ___
> > grass-dev mailing list
> > grass-dev@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-dev
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Ideas

[Maris Nartiss via grass-dev]

Hello Anna, Vero.
I added the welcome screen idea we discussed during our Prague
meeting. I think it would be a good GSOC project as it is quite easy
and at the same time will allow to understand if it is the way to go.
Anna, would you be able to be a co-mentor as it is a GUI project? Or
who else could be?
Vero, your user-centric view also would be valuable.
Please edit the wiki accordingly.

Thanks,
Māris.

sestd., 2024. g. 3. febr., plkst. 06:34 — lietotājs Anna Petrášová via
grass-dev () rakstīja:
>
> Hi,
>
> I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac wiki, which 
> I think we should be moving away from):
> https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024
>
> It's not updated yet, I plan to add more topics. If you want to mentor a 
> topic, we can discuss it here.
>
> Anna
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS Windows issues

[Maris Nartiss via grass-dev]

Windows issues are hard to debug as most of developers are on Linux boxes.
Do you have an ArcGIS install by any chance? In the past ArcGIS was a
source of different problems for GRASS as it would register its Python
globally and then GRASS would pick wrong Python version resulting
myriad of strange errors.

M.

svētd., 2023. g. 10. dec., plkst. 17:25 — lietotājs Gandalf the Gray
via grass-dev () rakstīja:
>
> Hi Jeff
>
> Thanks for the link.  I installed the 8.4 dev version. and it gives exactly 
> the same error as with GRASS standalone from grass,osgeo.org, GRASS installed 
> with OSGeo4W, and from the QGIS standalone installer.
>
> I am now suspecting that it might not be the wxpython included in the 
> installers, but my pc itself.
>
> Regards
>
> Pieter
>
> On Sun, Dec 10, 2023 at 2:52 PM Jeff McKenna via grass-dev 
>  wrote:
>>
>> Hi Pieter,
>>
>> I personally always recommend using WinGRASS, it is very reliable.
>> (thanks to MartinL)  https://wingrass.fsv.cvut.cz/grass84/
>>
>> Merry Christmas to you and the GRASS GIS family,
>>
>> -jeff
>>
>>
>>
>> --
>> Jeff McKenna
>> GatewayGeo: Developers of MS4W, & offering MapServer Consulting/Dev
>> co-founder of FOSS4G
>> http://gatewaygeo.com/
>>
>>
>>
>> On 2023-12-09 12:17 a.m., Gandalf the Gray via grass-dev wrote:
>> > Hi guys.
>> >
>> > In desperation I am posting to this list.  I have posted on the OSGeo4W
>> > list a week ago to no avail.
>> >
>> > I hope someone can help me.
>> >
>> > On a clean install of OSGeo4W (and for that matter standalone QGIS and
>> > GRASS installers), I get the following error (see attached screenshot)
>> > starting any version of GRASS.
>> >
>> > On GRASS 7, I can do a mapset selection before crash, but the other 2
>> > just crashes.
>> >
>> > Install is on a machine that ran GRASS up until a week ago, until I
>> > uninstalled the OSGeo4W stack, and deleted everything.  There is nothing
>> > strange about my Windows Setup
>> >
>> > I hope anyone can help me, and I hope you can see the screenshot.
>> >
>> > Regards
>> >
>> > Pieter
>> >
>> > _
>>
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Bugs in i.cca module

[Maris Nartiss via grass-dev]

Thanks, Markus.
I managed to compile version before the ccmath library in a VM. I
managed to get results with steps from that e-mail. But as soon as I
try to repeat the steps after the ccmath introduction commit, I get a
segfault. With my fix, there is no segfault but the results are nan
when the original version gives some numbers.
Thus although my PR would eliminate a segfault, it does not fix i.cca.
I'm not certain if it is worth to merge as segfault at least is a
clear sign that something is really wrong :D

Unless someone can look into the code to see what's wrong with it, I'd
say we disable compilation of i.cca and remove it from the GUI menu.
Māris.

trešd., 2023. g. 15. nov., plkst. 11:50 — lietotājs Markus Neteler
() rakstīja:
>
> Hi Māris, all,
>
> On Wed, Nov 15, 2023 at 8:35 AM Maris Nartiss via grass-dev
>  wrote:
> >
> > Hello devs,
> > Just playing around I decided to run i.cca module. Seems that it has
> > been broken since 2009(!) (there is a bug report from 2014 in Trac
> > [1]). I managed to fix the segfault [2] but it left me with a
> > different problem – the module runs just fine but produces NULLs as an
> > output. This boils down to at one point trying to calculate sqrt from
> > negative numbers. I am not that familiar with the CCA algorithm
> > implemented in the module and thus have no idea if it is a bug in the
> > code or just bad input data.
> >
> > I hope somebody can help me to sort this out or provide a working example,
> > Māris.
>
> Digging in my inbox I found this thread from 2009:
> https://lists.osgeo.org/pipermail/grass-dev/2009-August/045656.html
>
> It contains some discussion and examples. Maybe not much of a help but
> a kind of pointer.
>
> Markus
>
> > 1. https://trac.osgeo.org/grass/ticket/2297
> > 2. https://github.com/OSGeo/grass/pull/3239
> > ___
> > grass-dev mailing list
> > grass-dev@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-dev
>
> --
> Markus Neteler, PhD
> https://www.mundialis.de - free data with free software
> https://grass.osgeo.org
> https://neteler.org/blog
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Bugs in i.cca module

[Maris Nartiss via grass-dev]

Hello devs,
Just playing around I decided to run i.cca module. Seems that it has
been broken since 2009(!) (there is a bug report from 2014 in Trac
[1]). I managed to fix the segfault [2] but it left me with a
different problem – the module runs just fine but produces NULLs as an
output. This boils down to at one point trying to calculate sqrt from
negative numbers. I am not that familiar with the CCA algorithm
implemented in the module and thus have no idea if it is a bug in the
code or just bad input data.

I hope somebody can help me to sort this out or provide a working example,
Māris.

1. https://trac.osgeo.org/grass/ticket/2297
2. https://github.com/OSGeo/grass/pull/3239
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [EXTERNAL] [release planning] GRASS GIS 8.3.1

[Maris Nartiss via grass-dev]

If I read the log file correctly, the actual error message is:
/usr/bin/install: cannot create regular file
'/builddir/build/BUILD/grass-8.3.1/dist.x86_64-redhat-linux-gnu/docs/html/raster3d_layout.png':
File exists
make[3]: *** [../../include/Make/HtmlRules.make:14:
/builddir/build/BUILD/grass-8.3.1/dist.x86_64-redhat-linux-gnu/docs/html/raster3d_layout.png]
Error 1

Could it be related to the fact that we ship three(!) copies of this file?
Maris.

piektd., 2023. g. 27. okt., plkst. 13:32 — lietotājs Markus Neteler
via grass-dev () rakstīja:
>
> Dear all,
> I am trying to build G8.3.1 for Fedora (F40) but get a strange error:
>
> GRASS GIS 8.3.1 exported compilation log
> --
> Started compilation: Thu Oct 26 12:52:40 UTC 2023
> --
> Errors in:
> /builddir/build/BUILD/grass-8.3.1/raster3d/r3.in.ascii
>
> Related to
> gcc  x86_64  13.2.1-4.fc40
> ?
>
> The log is here, help quite welcome:
> https://kojipkgs.fedoraproject.org//work/tasks/2196/108132196/build.log
>
> Thanks,
> Markus
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] GRASS GIS 8.3.0

[Maris Nartiss]

otrd., 2023. g. 21. febr., plkst. 21:11 — lietotājs Vaclav Petras
() rakstīja:
>
> I still agree that it is a potentially big change for those who actually 
> followed the version numbering, but I hope if there is some criticism of 
> that, we would know already.
>

Or simply they don't know yet that 8.3 will not be a development
testing version ;-) Before announcement of upcoming 8.3.0 release it
was not even communicated to the -dev ML.
In practice though I do agree – most likely nobody cares about version
numbers anyway.

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

Re: [GRASS-dev] how to derive polygons (bounding boxes) from text strings

[Maris Nartiss]

I did some tinkering around the potential interface for such module:
https://github.com/marisn/grass-addons/tree/v_text_bbox/src/vector/v.text.bbox

Uwe, if nobody else has stepped up to help you, poke me after
Christmas as I might have some spare evening before the New Years eave
to do more fiddling.
Māris.

trešd., 2022. g. 14. dec., plkst. 22:16 — lietotājs Markus Neteler
() rakstīja:
>
> Hello Uwe,
>
> On Fri, Dec 9, 2022 at 10:29 AM  wrote:
> >
> > Hello list,
> >
> > I have a point feature layer with attributes for a text string (call it 
> > 'label') and the fontsize in map units (which are meters in my case).
> >
> > Is there a way in Grass to derive polygons (like boundig boxes) from this 
> > input information which enclose the label string letter  when those are 
> > used to label the points?
> >
> > For those who know ArcMap: what I mean is exactly what happens when you 
> > export Annotation features as Shapes in ArcCatalog: you get a polygon layer 
> > in which each text string has a polygon hull which fits the height and 
> > width, respectively.
> >
> > From a developer, I heard that this can be done d_get_text_box from display 
> > library, which is not exposed to the end user.
>
> Well, it is exposed to the "C language" end user :-)
>
> For a local test, I have added these lines (as a simple debug output):
>
> git diff display/d.text/
> diff --git a/display/d.text/main.c b/display/d.text/main.c
> index a5fb7fec7..0aab3db8d 100644
> --- a/display/d.text/main.c
> +++ b/display/d.text/main.c
> @@ -626,10 +626,12 @@ static void draw_text(char *text, double *x,
> double *y, double size,
> D_text_rotation(0.0);
>
>  D_get_text_box(text, , , , );
> +fprintf(stdout, "t: %.2f, b: %.2f, l: %.2f, r: %.2f\n", t, b, l, r);
>  t = D_u_to_d_row(t);
>  b = D_u_to_d_row(b);
>  l = D_u_to_d_col(l);
>  r = D_u_to_d_col(r);
> +fprintf(stdout, "t: %.2f, b: %.2f, l: %.2f, r: %.2f\n", t, b, l, r);
>
>  if (rotation != 0.0)
> D_text_rotation(rotation * 180.0 / M_PI);
>
>
> I guess it would do what you need - tested in North Carolina sample
> data location:
>
> GRASS nc_spm_08_grass7/user1:d.text >
>
> g.region raster=zipcodes_elev_avg
> d.mon wx0
>
> # test 1: font size 4
> d.text text="This is a test of d.text" color=yellow bgcolor=gray size=4
> t: 228897.44, b: 228500.00, l: 626709.08, r: 634951.64
> t: -26.02, b: 0.00, l: 3.39, r: 543.13
>
> # test 2: font size 6
> d.text text="This is a test of d.text" color=yellow bgcolor=gray size=6
> t: 229096.16, b: 228500.00, l: 626735.00, r: 639098.84
> t: -39.04, b: 0.00, l: 5.09, r: 814.69
>
>
> > Since I am not a programmer, I am looking for help how to use 
> > d_get_text_box. My goal ist o integrate it in a
> > simple Python script which I already have. This script can import 
> > Shapefiles, do simple GIS processing using
> > GRASS modules and write the shapes back.
>
> The (current) pity is that there is no Python wrapper around the
> display library in
>
> https://github.com/OSGeo/grass/tree/main/python/grass/pygrass
> https://github.com/OSGeo/grass/tree/main/python/grass/script
>
> > Of course, if coding is necessary to accomplish this, I will pay for it.
>
> Maybe not a hard task to write this Python access to the C function
> D_get_text_box() but unfortunately I am lacking time.
> Hopefully someone else here is willing to pick up the task.
>
> Best,
> Markus
>
> > thank you and best regards, Uwe
> >
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Debugging, parallelism, etc.

[Maris Nartiss]

There is no issue with supporting both OpenMP and pthreads as most of
libraries use neither of them. There are a few modules with some
parallelism implemented and in such case they use only one of options
thus bypassing any compatibility issues per se.

As for valgrind noise – it comes from design decisions made decades a
go – each module is a short running independent program and thus it is
left to OS to reclaim memory at exit. Analysis tools sometimes also
report potential uninitialized use but in cases that can not be
reached during a normal GRASS module run. Unfortunately improving
GRASS quite often is like restoring an ancient artefact where it is
hard to tell bugs from features apart.

Māris.

svētd., 2022. g. 9. okt., plkst. 19:37 — lietotājs Brad ReDacted
() rakstīja:
>
> Hello,
>
> I'm working on adding parallelism to modules, but debugging is turning
> out to be a logistical nightmare:
>
> Why do I not get any reporting from GCC option '-fsanitize=address|thread"?
>
> I am also having trouble getting the profiler to work properly inside
> GRASS (I assume due to shell?). The gmon.out file produced has no usable
> data.
>
> OpenMP is extremely poorly supported by most tools. valgrind with
> helgrind reports a lot of nonsense. I can't seem to get the Intel linux
> tools to work properly, either.
>
> BTW, we are supporting both pthreads and OpenMP. While this isn't an
> issue in most cases, there can be races and deadlocks if not handled
> properly. Pthreads aren't entirely portable. OpenMP is. However,
> pthreads gives us a more control. May I suggest using OpenMP for most
> modules and reserve Pthreads to libraries, etc? Or should we start
> moving away from pthreads?
>
> Any suggestions would be greatly appreciated!
>
>
> --
> Best Regards,
> -Brad
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Replace GNU Indent with ClangFormat?

[Maris Nartiss]

pirmd., 2022. g. 21. marts, plkst. 16:01 — lietotājs Nicklas Larsson
via grass-dev () rakstīja:
>
> Now the question is first of all: is using ClangFormat something the GRASS 
> dev community (you) would want or could live with for this project?

Yes! +1 from me – helps to avoid accidental reformatting of files
while changing small things.

> Best,
> Nicklas
Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Band references need a better name and definition

[Maris Nartiss]

Cross-posting for those who do not get notifications from GH. The
discussion is happening in GH:
https://github.com/OSGeo/grass/issues/1868
As the issue needs to be solved before 8.0 release, it would be nice
to get the feedback till 26th of September.
--

The issue

The term band reference was introduced with #63. There, perhaps, the
word reference was referring to the fact that the text is referring to
the band description stored in the file g.bands gives access to.
However, now an arbitrary band reference can be stored for any raster
map, i.e., it is more general than just bands from a predefined (or
possibly in the future, registered) list of bands associated with
particular sensors.

The band references can now be used (optionally assuming #1866) to
label any rasters (raster maps or bands) in an imagery group so that
signatures are associated with given set of bands rather than just a
fixed set of raster data.

Going even further, the usage does not have to limited to image
processing. For example, in modeling, standardized names such as
topographic__elevation and sea_surface_air__temperature are used to
describe inputs and outputs of models (see Landlab Standard Name
Definitions and CSDMS Standard Names).

Overall, band references quickly outgrew their original definition and
there is a potential to have good name suggesting the potential use.
At the same time, there is a potential for ending up with a cryptic
term which is difficult to explain and difficult to link to its
application.

The issues with the current name are:

The word band, although often used quite generally, might be tight too
much to remote sensing and may overlap with other usages of the term.
The word reference is the cryptic part. Name, label, band and id are
words people may have different ideas about, but they generally be
somewhat right. Reference, on the other hand, is a very special term,
loaded for some, meaningless for others.
The term band reference seems to be too long, resulting in modules and
functions using different combinations of band and bandref in the
interface instead of full band reference. Notably, bandref is not a
word. The word band by itself may be too ambiguous. Interestingly, I
don't think there is reference used as the only word, although that's
really the noun in the term.

Since the current system is not part of any release yet, now is the
time to get it right.

Naming options

band label
band name
band tag
band reference
band id
band identifier
semantic label
semantic name
semantic tag
standard variable name
standard field name
...

Expected resolution

We decide on a name for what these things are and even if it stays as
band references we are sure that that's how we want to call them.
The usage is consistent in documentation and in the interface (option
names, function names).

Additional context

We discussed this during the last call, but decided to open this as an
issue to discuss this in written form and asynchronously.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] nc_spm_08_grass8?

[Maris Nartiss]

Had to resent the mail due to size limitations. You can take a look at
the attachments here:
https://karlsons.gisnet.lv/~marisn/imagery_classification_G7.png
https://karlsons.gisnet.lv/~marisn/imagery_classification_G8.png


2021-09-10 5:56 GMT+03:00, Vaclav Petras :
>
> Why not to have both? Classify thousands of scenes while providing a simple
> way of doing things?

Because GRASS metadata handling implementation is inferior. See
Sentinel SAFE usage in SNAP for a correct one (XML/Java discussion
aside).

> If all import tools assigned band references, having them ready in the
> dataset for landsat could be perhaps justified. That's the answer I was
> hoping for, but that's not the case. Still, the question would be what if
> you can't use such a tool.

Depends on the format. If imported format has band references (e.g.
SAFE), they should be written in GRASS as band references too. Still
this is a TODO for another day.

> As for getting closer to the original behavior where 5 commands were enough
> to classify, i.group could add the band references since one needs to deal
> with both groups and bands anyway or the signature handling could assign
> them on the fly. I'm probably missing some important details you know
> about, but here are some options I can think of:

To better understand my answer, take a look at two attached graphs –
how imagery groups and signature files work in G7 and how they have
been changed for G8. In G7 imagery group is only consistent
internally. In G8 signature files from one group are consistent in any
group.

> Option 1) i.group has a new option bandref. It assigns band references to
> the rasters. User needs to provide as many band references as inputs. Still
> quite long, but i.group call is long already and it is at least technically
> one step.

+ One long call instead of multiple calls to r.support
- Raster band must be set for each group separately (think NDVI or
slope map in multiple groups)
- User must set the same labels in a correct order also for any other
group where signature file is used
= Not a big difference from existing implementation

> Option 2) i.group has a new flag to auto-assign band references 1,2,3,...
> (2a). Or perhaps an option taking a prefix/basename (2b). Simple to set.
> Minimal change from the current workflows. Almost feels like band
> references are optional.

+ Works well if one classifies the same group only
- Signature file can not be used to classify any other group as there
is no guarantee of band order in groups
= This is a GRASS 7 approach with a hack of copying SIG file from one
group to other group

> Option 3) i.group auto-assigns automatically when band references are not
> present. No dealing with band references unless one needs to.

+ Works well if one classifies the same group only
- Signature files must be modified to contain group name
- User will be able to select a signature file for classification of a
different group but action will be refused if band references are
missing
= Confusing as one can not know in advance if signature file can or
can not be used to classify a group (should we call it a pythonic way
– try...except?)

> Option 4) i.gensigset et al. labels the bands 1,2,3,... on the fly only in
> the signature file and i.smap et al. uses the same numbering scheme when
> the rasters don't have band references. Band references are handled only
> when needed even on the module level in addition to the user level.

Didn't understood how this differs from option #2.

> With all options users still may take advantage of the flexible signature
> file system if being careful about order. (Keeping the order right is
> likely not an issue while scripting, so having a list of auto-assigned
> numbers is just fine.) All options hide details of the actual reference
> handling at least a little bit providing more space for changes later on.
> The options 3 and 4 make dealing with band references completely optional.
> Option 4 avoids mixing groups and band references and while option 3 hides
> that part.

There is no guarantee of order of bands in a REF file. If band order
stays the same, you are lucky, if it isn't, you just got an incorrect
result without a warning (a.k.a. flipping a coin to determine if
output is correct or total bollocks as band order was messed up).
Assigning band reference via scripting is not a problem if e.g. it is
present in the raster name.

> Other options would be modules such as r.number.bands/i.auto.bands (kind of
> like options 2 and 3 but standalone) and i.band.identify (some heuristic to
> determine band names from raster names perhaps taking an example or a
> sensor).

This is the correct way to go. I would say:
1) enhance import tools to generate band references (if possible). I
assume specialized Sentinel, Landsat, Modis etc. import modules could
be enhanced easily to do so.
2) provide an easy GUI tool to assign band references. Here bands from
g.bands would come handy. Probably i.bands 

Re: [GRASS-dev] nc_spm_08_grass8?

[Maris Nartiss]

2021-09-09 19:19 GMT+03:00, Vaclav Petras :
> On Thu, Sep 9, 2021 at 4:46 AM Maris Nartiss  wrote:
>
> In the documentation, we moved from (5 calls):
>
> ```
> g.region raster=lsat7_2002_10
> i.group group=lsat7_2002 subgroup=res_30m input=...
> v.to.rast input=training output=training use=cat label_column=label
> i.gensigset trainingmap=training group=lsat7_2002 subgroup=...
> i.smap group=lsat7_2002 subgroup=res_30m signaturefile=...
> ```
>
> to (16 calls):
>
> ```
> g.mapset mapset=PERMANENT
> r.support map=lsat7_2002_10 bandref=TM7_1
> r.support map=lsat7_2002_20 bandref=TM7_2
> r.support map=lsat7_2002_30 bandref=TM7_3
> r.support map=lsat7_2002_40 bandref=TM7_4
> r.support map=lsat7_2002_50 bandref=TM7_5
> r.support map=lsat7_2002_61 bandref=TM7_61
> r.support map=lsat7_2002_62 bandref=TM7_62
> r.support map=lsat7_2002_70 bandref=TM7_7
> r.support map=lsat7_2002_80 bandref=TM7_8
> g.mapset mapset=user1
> g.region raster=lsat7_2002_10
> i.group group=lsat7_2002 subgroup=res_30m input=...
> v.to.rast input=training output=training use=cat label_column=label
> i.gensigset trainingmap=training group=lsat7_2002 subgroup=...
> i.smap group=lsat7_2002 subgroup=res_30m signaturefile=...
> ```
>
> This seems to be making GRASS more difficult to use instead of making it
> easier to use or at least keeping the status quo.

And we gained ability to use signatures from one scene to classify
different scenes. Sucks if all you do is just tutorials and do not
attempt to use GRASS for any serious work. Have you been trying to use
GRASS to classify a large set of satellite imagery? In GRASS 7 you
must digitize training areas for each scene separately as you can not
use signatures from one scene (imagery group) to classify other scene
(signatures are located inside an imagery group). In GRASS 8 it is no
more – draw training areas once, generate signatures once and apply
signatures to as many scenes as you have (including in a different
mapset!). Heck, they would work out of box even in a different
location (import/export/management module is still a TODO).

> Changing the sample dataset sounds like hiding the issue rather than
> solving it. Having an ultra convenient sample dataset doesn't make the
> software easier to use.

Simplicity is not an end goal. GRASS is a tool for serious data
analysis and thus having to prepare data is nothing unusual. There are
other easier to use tools out there that will happily allow to do
shit-in, shit-out data analysis if one does not care about quality.
(Just take a look at the terrible hack i.signature.copy in addons – a
silent data corruption waiting to happen.)

> Additionally, given that the band references seem highly experimental, I
> don't think they should be required for any workflow at least from the user
> point of view.

Band references could be assigned automatically during import iff the
source has complete metadata (e.g. importing from Sentinel SAFE
format).
Portability of signature files depends on band references. I will not
see any reason why to land i.svm into main if I will not be able to
use portable signatures for automatic classification of large
datasets. Think big and not on a tutorial level. GRASS 7 imagery
classification tools are not HPC ready, GRASS 8 are (for data-parallel
approach).

Looking forward to my task of classifying 66100 imagery scenes with GRASS,
Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] nc_spm_08_grass8?

[Maris Nartiss]

Hello Anna, Veronica.

2021-09-08 23:09 GMT+03:00, Veronica Andreo :
> Hi Anna, all
>
> Good point! Thanks for raising this!
>
> Seems we are all trying to better understand band references and how they
> integrate with existing functionality :)

Band reference usage in the context of classification of imagery is
explained in a scheme in the most recent GRASS 8 feature presentation:
https://veroandreo.github.io/grass-gis-talks/wageningen2021.html#/4/6

> In
> https://github.com/OSGeo/grass/pull/1844/ we discuss temporal framework and
> band references.

I can not comment on band references in t.* modules as I do not
understand their role there. Some changes might be needed there.

> Indeed, we have a problem if all examples using Landsat will stop working
> in grass 8, so if this is the case, then we might need a new version of the
> sample data which by the way might also include the MODIS LST mapset (~10
> Mb) to do some time series stuff.

A new version of sample dataset would be good. Still existing version
also works OK as long as you do an extra step of assigning band
references at the first time. You'll find usage examples in manual
pages of i.cluster with following in i.maxlik; and a full example in
i.smap.

https://github.com/OSGeo/grass/blob/main/imagery/i.cluster/i.cluster.html#L265
https://github.com/OSGeo/grass/blob/main/imagery/i.maxlik/i.maxlik.html
https://github.com/OSGeo/grass/blob/main/imagery/i.smap/i.smap.html#L144

> In my opinion, band reference should be something optional, no?

They are optional as long as you are not using i.maxlik or i.smap or
i.svm.predict (and respective signature generation modules for them).
Can't comment on t.* modules.

> On the
> other hand, I think I understood from Maris that with r.support we could
> add band references and that the restrictions were relaxed but these
> changes are not yet documented. There's this thread:
> https://lists.osgeo.org/pipermail/grass-dev/2021-September/095377.html

Band reference rules are relaxed and now any word can be a band
reference as long as its length does not exceed GNAME_MAX and its
symbol set is limited to a-Z 0-9 and "-", "_".
https://github.com/OSGeo/grass/blob/main/lib/raster/raster_metadata.c#L149
Can not comment on t.* modules as they are bypassing C library and
doing some magick in Python instead of fully integrating with the rest
of GRASS.

It is pity that the PR relaxing band reference requirements got merged
although it didn't change the documentation to reflect changes in the
code. It is my fault as I wasn't fast enough to stop Markus Metz from
merging without required changes. I hope Markus M. will fix his
blunder and provide changes also to the documentation to reflect
changes in the code made by him.
https://github.com/OSGeo/grass/pull/1796

> Band references need some further discussion IMHO

Harmonization of t.* Python based band reference handling with C
library based one should be done by someone who completely understands
the Python part in t.* (as an idea and not only code). As
functionality is required in both C and Python code, C has precedence
over Python (functionality in C + wrapper functions for Python or just
plain ctypes as it is done in tests).

From the i.* module point of view, modules g.bands and i.bands are not
required and are not used at all. Besides i.bands is a bad module name
as bands are assigned to rasters and not groups thus it should be
r.bands but the management functionality is already covered with
r.support leaving only printing for i.bands without an alternative. I
would drop i.bands completely unless it is completely reworked.
g.bands is a nice idea but, unless someone implements editing part, it
is of limited use.

> my 2 cents
> Vero

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

Re: [GRASS-dev] lib/gis/band_reference.c ?

[Maris Nartiss]

Band reference rules were totally relaxed 7 days a go:
https://github.com/OSGeo/grass/commit/abe194dce78adf5f63885a6a09c452fc7ae4f735

New relaxed rule changes haven't propagated to the documentation yet
(PR's welcome).

Band reference editing via r.support was added on 4th of July:
https://github.com/OSGeo/grass/commit/ca1551206eaa0fc462f4849a06ebb035808470da

Still – keep in mind – there are no changes in band metadata as
managed by g.bands. Changes only deal with ability to have a band
reference without extended metadata in json files. Thus limitation of
not being able to define your own band reference is still in place,
now only you can assign a band reference without having a definition
(and thus any extended metadata apart from its name).

Māris.

2021-08-24 11:18 GMT+03:00, Stefan Blumentrath :
> Thanks Maris for the reply.
>
> I could not find that option in r.support.
>
> i.band allows to add e.g. S2_12 as band reference, but nothing custom. And
> the g.bands manual says that user-defined band references are not yet
> supported.
>
> Has that been added recently? Or would I have to edit the bands json file of
> the system first?
>
> My system is:
> g.version -ger
> version=8.0.dev
> date=2021
> revision=dd9d36830
> build_date=2021-07-08
> build_platform=x86_64-pc-linux-gnu
> build_off_t_size=8
> libgis_revision=d2a5e8e8f
> libgis_date=2021-06-16T04:05:21+00:00
> proj=7.0.0
> gdal=3.0.4
> geos=3.8.0
> sqlite=3.22.0
>
> Cheers
> Stefan
>
> -Original Message-
> From: Maris Nartiss 
> Sent: tirsdag 24. august 2021 09:03
> To: Stefan Blumentrath 
> Cc: Martin Landa ; Markus Metz
> ; GRASS developers list
> 
> Subject: Re: [GRASS-dev] lib/gis/band_reference.c ?
>
> GRASS supports arbitrary band reference names. Just make them unique enough
> to not mix together apples with oranges by accident (e.g. "min"
> is a bad idea, "min_t_c" is better; "NDVI" would work; "elevation" – bad,
> "elevation_m" – better).
> You can set band references after import with r.support module.
>
> Have fun,
> Māris.
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] lib/gis/band_reference.c ?

[Maris Nartiss]

GRASS supports arbitrary band reference names. Just make them unique
enough to not mix together apples with oranges by accident (e.g. "min"
is a bad idea, "min_t_c" is better; "NDVI" would work; "elevation" –
bad, "elevation_m" – better).
You can set band references after import with r.support module.

Have fun,
Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 7.8.5 compile errors

[Maris Nartiss]

Don't forget to run make distclean before reconfiguring and
recompiling GRASS. If you would be on a Gentoo, I would suggest to run
revdep-rebuild that would rebuild all packages linking to proj. On
Ubuntu you just have to look for a PPA with GIS packages compiled with
the right proj version.

Māris.

2021-08-12 20:00 GMT+03:00, Thomas Adams :
>
> It's a mystery where libproj.so.15 references are coming from. I have never
> had this kind of problem before.
>
> Tom
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 7.8.5 compile errors

[Maris Nartiss]

Hello Thomas,
I gave you a wrong path. Try this one:
ldd /home/teaiii/grass-7.8.5/dist.x86_64-pc-linux-gnu/lib/libgrass_gproj.so

The problem still boils down to having different incompatible system
libraries during compilation and runtime. You can also search for
libproj.so files in /usr/lib(64) or just dpkg -l | grep proj and if
you see multiple proj versions, remove one.

Māris.

2021-08-12 13:11 GMT+03:00, Thomas Adams :
> Hi Māris,
>
> When I run the command ldd /home/teaiii/grass-7.8.5/lib/libgrass_gproj.so |
> grep proj , I get:
>
> ldd: /home/teaiii/grass-7.8.5/lib/libgrass_gproj.so: No such file or
> directory
>
> There is no libgrass_gproj.so file in /home/teaiii/grass-7.8.5/lib/l in
> fact just subdirectories along with Makefile and README
>
> Tom
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 7.8.5 compile errors

[Maris Nartiss]

This is a know issue. Most likely you have two versions of PROJ
library installed. Make sure to have only one llibproj.so file
present.
Here's a check for it (one line – good, more than one – bad):
ldd /home/teaiii/grass-7.8.5/lib/libgrass_gproj.so | grep proj

Here's a old bug report:
https://github.com/OSGeo/grass/issues/435#issuecomment-688807074

Good luck,
Māris.


2021-08-11 22:06 GMT+03:00, Thomas Adams :
> Hi Anna,
>
> Thank you for your help sorting this out... Not surprisingly, I get the
> same errors in grass-7.8.6RC2
>
> *Error in /home/teaiii/grass-7.8.5/lib/python/ctypes:*
>
> Error: /usr/include/stdio.h:246: Syntax error at '__filename'
> Error: /usr/include/stdio.h:247: Syntax error at '__modes'
> Error: /usr/include/stdio.h:252: Syntax error at '__filename'
> Error: /usr/include/stdio.h:253: Syntax error at '__modes'
> Error: /usr/include/stdio.h:254: Syntax error at '__stream'
> Error: /usr/include/stdio.h:304: Syntax error at '__stream'
> Error: /usr/include/stdio.h:304: Syntax error at '__buf'
> Error: /usr/include/stdio.h:308: Syntax error at '__stream'
> Error: /usr/include/stdio.h:308: Syntax error at '__buf'
> Error: /usr/include/stdio.h:309: Syntax error at 'size_t'
> Error: /usr/include/stdio.h:314: Syntax error at '__stream'
> Error: /usr/include/stdio.h:314: Syntax error at '__buf'
> Error: /usr/include/stdio.h:326: Syntax error at '__stream'
> Error: /usr/include/stdio.h:327: Syntax error at '__format'
> Error: /usr/include/stdio.h:332: Syntax error at '__format'
> Error: /usr/include/stdio.h:334: Syntax error at '__s'
> Error: /usr/include/stdio.h:335: Syntax error at '__format'
> Error: /usr/include/stdio.h:341: Syntax error at '__s'
> Error: /usr/include/stdio.h:341: Syntax error at '__format'
> Error: /usr/include/stdio.h:347: Syntax error at '__format'
> Error: /usr/include/stdio.h:349: Syntax error at '__s'
> Error: /usr/include/stdio.h:349: Syntax error at '__format'
> Error: /usr/include/stdio.h:354: Syntax error at '__s'
> Error: /usr/include/stdio.h:355: Syntax error at 'const'
> Error: /usr/include/stdio.h:355: Syntax error at '__format'
> Error: /usr/include/stdio.h:358: Syntax error at '__s'
> Error: /usr/include/stdio.h:359: Syntax error at 'const'
> Error: /usr/include/stdio.h:359: Syntax error at '__format'
> Error: /usr/include/stdio.h:379: Syntax error at '__fmt'
> Error: /usr/include/stdio.h:382: Syntax error at '__fmt'
> Error: /usr/include/stdio.h:391: Syntax error at '__stream'
> Error: /usr/include/stdio.h:392: Syntax error at '__format'
> Error: /usr/include/stdio.h:397: Syntax error at '__format'
> Error: /usr/include/stdio.h:399: Syntax error at '__s'
> Error: /usr/include/stdio.h:400: Syntax error at '__format'
> Error: /usr/include/stdio.h:416: Syntax error at '__stream'
> Error: /usr/include/stdio.h:417: Syntax error at '__format'
> Error: /usr/include/stdio.h:418: Syntax error at '__format'
> Error: /usr/include/stdio.h:419: Syntax error at '__s'
> Error: /usr/include/stdio.h:420: Syntax error at '__format'
> Error: /usr/include/stdio.h:432: Syntax error at '__s'
> Error: /usr/include/stdio.h:432: Syntax error at '__format'
> Error: /usr/include/stdio.h:440: Syntax error at '__format'
> Error: /usr/include/stdio.h:444: Syntax error at '__s'
> Error: /usr/include/stdio.h:445: Syntax error at '__format'
> Error: /usr/include/stdio.h:465: Syntax error at '__s'
> Error: /usr/include/stdio.h:466: Syntax error at '__format'
> Error: /usr/include/stdio.h:468: Syntax error at '__format'
> Error: /usr/include/stdio.h:470: Syntax error at '__s'
> Error: /usr/include/stdio.h:471: Syntax error at '__format'
> Error: /usr/include/stdio.h:564: Syntax error at '__s'
> Error: /usr/include/stdio.h:564: Syntax error at 'FILE'
> Error: /usr/include/stdio.h:603: Syntax error at '__lineptr'
> Error: /usr/include/stdio.h:604: Syntax error at '__n'
> Error: /usr/include/stdio.h:605: Syntax error at 'FILE'
> Error: /usr/include/stdio.h:606: Syntax error at '__lineptr'
> Error: /usr/include/stdio.h:607: Syntax error at '__n'
> Error: /usr/include/stdio.h:608: Syntax error at 'FILE'
> Error: /usr/include/stdio.h:616: Syntax error at '__lineptr'
> Error: /usr/include/stdio.h:617: Syntax error at '__n'
> Error: /usr/include/stdio.h:618: Syntax error at '__stream'
> Error: /usr/include/stdio.h:626: Syntax error at '__s'
> Error: /usr/include/stdio.h:626: Syntax error at '__stream'
> Error: /usr/include/stdio.h:646: Syntax error at '__ptr'
> Error: /usr/include/stdio.h:647: Syntax error at 'size_t'
> Error: /usr/include/stdio.h:647: Syntax error at '__stream'
> Error: /usr/include/stdio.h:652: Syntax error at '__ptr'
> Error: /usr/include/stdio.h:653: Syntax error at 'size_t'
> Error: /usr/include/stdio.h:653: Syntax error at '__s'
> Error: /usr/include/stdio.h:673: Syntax error at '__ptr'
> Error: /usr/include/stdio.h:674: Syntax error at 'size_t'
> Error: /usr/include/stdio.h:674: Syntax error at '__stream'
> Error: /usr/include/stdio.h:675: Syntax error at '__ptr'
> Error: 

Re: [GRASS-dev] [release planning] GRASS GIS 8: create new release branch

[Maris Nartiss]

2021-07-27 18:26 GMT+03:00, Vaclav Petras :
>
> From what has the milestone 8.0 and is not mentioned below and is major, I
> see only #1454 and #1501 which are related to band references. Maybe we
> should again consider reverting the band references in order to get 8.0 out
> or how do you see the status of #1454 and #1501, Martin and Maris?
>
> https://github.com/OSGeo/grass/milestone/4
> https://github.com/OSGeo/grass/pull/1454
> https://github.com/OSGeo/grass/pull/1501
>

For #1454 the main remaining (and unsolvable) issue is semantics of a
mapset layout and its management functions. I just commited a more
clean workaround and thus it should be ready for a merge. A proper
solution will have to wait for GRASS 9 when we could reorganize mapset
structure and thus also clean-up naming, handling functions etc.

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

Re: [GRASS-dev] [SoC] GSoC 2021 - Parallelization of raster modules for GRASS GIS

[Maris Nartiss]

Hello Aaron,

2021-07-12 18:23 GMT+03:00, Aaron Saw Min Sern :
> Hi everyone,

> 2) What do I plan on doing next week?
>
>   *   Complete rework of r.neighbors implementation
>   *   Compare benchmark between the two implementations

To make most impact of your GSoC I strongly support your idea of
getting your implementations right. Better to have fewer modules
parallelized than having unstable code in them and thus risking
potential removal of the parallel code.
Anna was testing your code in r.mfilter and it was failing for her.
You should look into it as similar problem could also affect your work
in r.neighbors.

Good luck & keep up good work,
Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] GRASS GIS 8: create new release branch

[Maris Nartiss]

Hello all.

2021-07-09 21:39 GMT+03:00, Markus Neteler :
> Hi Anna, all,

> So, from my point of view, as you suggest:
>
> - get g.extension working, then
> - create a new release branch
> - after that the GSoC merge into master.

There are a few PRs to merge but they are stuck due to failing tests –
Windows build & test is just bad (no bug or PR so far?), CentOS is too
old (#1709) & needs auto tools update to fix it (or at least env
variable in build script as I just have done to enable testing in
#1501), Ubuntu based test scripts use g.download.location extension
that is not operational at the moment (fixed by #1715?).

I would also strongly advocate merging ctypes upgrade before 8.0

> Best,
> Markus

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

Re: [GRASS-dev] Fwd: [OSGeo-Discuss] [FOSS4G] OSGeo Projects swag

[Maris Nartiss]

2021-07-06 11:50 GMT+03:00, Luca Delucchi :
> Hi devs,
>
> Does anyone have any ideas?
>

Tired of your lawn looking like a mess? Check out best gardening tips
at https://grass.osgeo.org

GRASS – taking care of lawns since 1982.


Designing an advertisement around logo I leave to more skill full artists.
Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] FIXED: Re: compiling GRASS-latest - configure fails with Unable to locate PostgreSQL includes

[Maris Nartiss]

Hello Denis,
please create a PR.

Māris.


2021-06-22 16:32 GMT+03:00, Denis Ovsienko :
> On Mon, 21 Jun 2021 23:24:40 +0200
> Markus Neteler  wrote:
>
>> Maybe others here have suggestions how to improve the current
>> (message) situation?
>
> As far as I understand it, since GRASS C source includes ,
> it uses FreeType 2. FreeType 2 documentation suggests using pkg-config
> to tell where the headers are:
> https://www.freetype.org/freetype2/docs/tutorial/step1.html#section-1
>
> On my system (Ubuntu 18.04) the headers are in /usr/include/freetype2
> (and not just):
>
> $ pkg-config --cflags freetype2
> -I/usr/include/freetype2 -I/usr/include/libpng16
>
> FWIW, running configure with
> --with-freetype-includes=/usr/include/freetype2 was always mandatory and
> sufficient for building GRASS on my PC. I didn't always remember this
> detail, so some of my builds were slightly more difficult than the
> others.
>
> GRASS configure script uses pkg-config, but not for FreeType 2
> detection. So it defaults to a hard-coded path,
> which is now /usr/include/freetype. It is worth checking how many
> distributions put FreeType 2 headers there instead
> of /usr/include/freetype2. In other words, this default path might be
> well out of date.
>
> In terms of improving this situation (such that GRASS configure "just
> works" for most users), the following changes could add to a more
> useful error message:
>
> 1. Default to /usr/include/freetype2 if that's the most common location
>in supported distributions now.
> 2. Use pkg-config to detect the necessary FreeType 2 CFLAGS
>automatically.
>
> As a side note, it might be a good time to migrate to a current version
> of autoconf (2.69 seems to be a popular choice).
>
> --
> Denis Ovsienko
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] FIXED: Re: compiling GRASS-latest - configure fails with Unable to locate PostgreSQL includes

[Maris Nartiss]

2021-06-22 0:24 GMT+03:00, Markus Neteler :
>
> Maybe others here have suggestions how to improve the current
> (message) situation?

We are free to change messages in configure.in file, still it would be
hard to customize for all potential failure scenarios. One option
would be to create a longer version of message like: "FOO not found.
Consult configure.log for exact reason of failure and seek in GRASS
WIKI for potential solutions."

> Best,
> Markus
Māris
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] compiling GRASS-latest - configure fails with Unable to locate PostgreSQL includes

[Maris Nartiss]

Please include relevant part of configure.log where exact reasons of
failure will be seen.

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

Re: [GRASS-dev] [release planning] GRASS GIS 8: create new release branch

[Maris Nartiss]

Hello Veronica,
thanks for pushing this forward.

Looking from a "it is ready when it is ready" perspective – what we
are missing from functionality to call 8.0 ready? (I mean only things
that are expected to be ready in less than a month)

From my side:
Band references and integration with signature files are ready to be
merged (please review!), missing functionality can wait for 8.2.
https://github.com/OSGeo/grass/pull/1272
https://github.com/OSGeo/grass/pull/1501

I'll try to work on r.in.pdal this Friday (I need to do some LiDAR
work myself). It is almost merge ready (as long as we add extra
functionality in 8.2)
https://github.com/OSGeo/grass/pull/1200

Then from my side I'd call 8.0 ready.
Māris.



2021-06-08 17:09 GMT+03:00, Veronica Andreo :
> Hello devs,
>
> As you all know, grass birthday is approaching... July 29th is just around
> the corner. I'd love to celebrate GRASS' bday with a new release, with a
> big release ;)
> Do you think that is doable? How much is missing for GRASS 8 release?
>
> The next important date is FOSS4G 2021 on September 27th - October 2nd,
> where we have proposed GRASS 8 talks and workshops. If we can't make it for
> GRASS GIS' birthday, do you think it's feasible to release before FOSS4G,
> say August for example?
>
> I think it's really important to agree on a date so we can all manage our
> reduced time and focus our efforts towards that aim.
> What do you say?
>
> Best,
> Vero
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] GRASS GIS 8: create new release branch

[Maris Nartiss]

Hello Makrus et al.

2021-05-15 16:40 GMT+03:00, Markus Neteler :
> On Sat, May 15, 2021 at 4:05 AM Vaclav Petras  wrote:
>> On Fri, May 14, 2021 at 11:10 AM Markus Neteler 
>> wrote:
>>> Let me suggest to create a new release branch in the next two weeks
>>> ...
>>>
>>> Now, the question is, also to avoid excessive cherry-picking of fixes
>>> and changes from master (to be called 8.1 then), which of the open PR
>>> may be merged soon?
>>
>>
>> I actually expected that you would be a "beta" release, not an RC, marked
>> by tagging a commit on master branch with the code as is.
>> This would avoid any backporting,
>
> Yes, that's an alternative idea.
>
>> but perhaps, it is not creating enough focus for 8.0 and having a 8.0
>> branch gives more freedom in what goes into the master branch.
>
> Indeed, a full blown new release branch for G800 would open the master
> branch for new (radical) changes.
>
> @All: your opinion?

I would like to get PR #1501 (depends on #1272) into master before
branching as it is already quite large and disruptive.
It is almost ready (today I wrote first of three management
functions). I want to finish lib part before merging – management
module can be then created as a separate PR at some point later.

I would go with branching 8 off just before release. Do we have some
large PRs coming in for 8.1 that can not wait?

> Markus

Māris.

https://github.com/OSGeo/grass/pull/1501
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Management of signature files

[Maris Nartiss]

Hello Luca,
I would also love to hear your personal vote on an approach we should
take with signature management tools in G8.

2021-04-28 13:33 GMT+03:00, Luca Delucchi :
> Hi Maris,
>
> On Wed, 28 Apr 2021 at 07:38, Maris Nartiss  wrote:
>>
>> These are only band-aids for current situation.
>> i.signature.copy is dangerous to use – one has to be certain that
>> raster map order in REF files of both groups match. If one group has
>> different order, it still will copy over signature file without
>> complaints (think – use data of green band to analyse content of red
>> band).
>
> I opened a ticket https://github.com/OSGeo/grass-addons/issues/517 if
> you have any better idea please add it to the issue

Warning would do as there is nothing you can do without checking band
references but they are not available in GRASS 7.

>> i.signature.list only lists signatures of type sig but ignores sigset
>> – nothing to see here.
>>
> https://github.com/OSGeo/grass-addons/issues/518

I guess same applies to copy and remove too. At least i.signatures.*
case is a bit better as these are specific tools for the task and thus
an extra option of "signature type" can be added to distinguish sig
from sigset.

>> Māris.

> Luca

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

Re: [GRASS-dev] Management of signature files

[Maris Nartiss]

Hello Veronica.
Thank you for your reply.

2021-04-27 15:22 GMT+03:00, Veronica Andreo :
> There are 3 add-ons that Luca wrote at OSGeo code sprint in Bonn 2018:
> i.signature.copy, i.signature.list, i.signature.remove.
> Would they be of help for any of the options proposed?

These are only band-aids for current situation.
i.signature.copy is dangerous to use – one has to be certain that
raster map order in REF files of both groups match. If one group has
different order, it still will copy over signature file without
complaints (think – use data of green band to analyse content of red
band).
i.signature.list only lists signatures of type sig but ignores sigset
– nothing to see here.

Thank you for this comment, but it is more about what we call "doing
the right thing" than how to implement it.

> In any case, thanks for your impressive work!

Its not over yet.

> Cheers,
> Vero

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

[GRASS-dev] Management of signature files

[Maris Nartiss]

Hello list,
I have been working on moving automatic classification signature files
(ones used by i.maxlik and i.smap) out of imagery groups. Existing
approach was not flexible enough as there was no official way of how
to reuse signatures from one imagery group in another group (train on
one, classify many).
At the moment I have managed to implement all internal bits of fully
reusable signatures – at the time of creation, band references are
written to the signature file; before signature use, band references
are used to reorder signatures to match band order in the new group
(or bail out if bands do not match).
https://github.com/OSGeo/grass/pull/1501

There are only two bits left before this work is complete:
1) remove current special signature file handling in GUI;
2) signature management.

I would like to hear some feedback on how to proceed with signature
management. At the moment I have placed signature files into following
structure:
///signatures//
As you can see, this structure differs from the canonical GRASS
approach of having single level to represent type (e.g. raster,
vector, ...) as there is a need to differentiate various signature
file types (at the moment there are two types – sig and sigset. I'll
finish work on a third (svm) after merging this PR).

Options for signature file managemet are:

#1 In GRASS 7 there are no options to manage signature files at all.
Once file is created, it can be only removed with OS file management
tools. g.list|copy|rename|remove have no idea of signature files. Pro:
easy to implement (=works already). Con: poking around mapset should
be done only by those who understand consequences.

#2 A variation of #1. Add a separate signature file management tool
(i.signatures?). We do have a precedent already – imagery groups are
managed by i.group module as g.* modules only see group but not
subgroups inside a group; time datasets. Pro: still easy to implement.
Con: needs special handling in GUI; one has to remember to use a
special module that differs from the rest (vect, raster, raster3d).

#3 Modify management library (g.* tools) to accept two level
specifiers e.g. "/(@)". Pro: one can use usual
g.* tools as with other data elements. Con: tricky to implement
without significant changes to lib/management; needs special handling
in GUI (show items matching SIG_TYPE); element syntax differs from
other data elements.

#4 A variation of #3. Change signature storage to
"/signatures/." Pro: easy to
add to g.* tools with element syntax ".(@)".
Con: needs special handling in GUI (show items matching SIG_TYPE);
element syntax differs from other data elements.

Let me know your preferred option or other ideas regarding signature
files. When I started to work on the issue, I was leaning towards #3
but now #4 seems to be even easier from implementation point of view,
although #2 is always an option.

After merging this PR, I have only r.in.pdal on my agenda and then
I'll remind everyone that GRASS 8.0 is long overdue ;-)
Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Need a mentor for GSoC parallelization topic

[Maris Nartiss]

2021-02-17 18:28 GMT+02:00, Anna Petrášová :
>
> we need a co-mentor and ideally it wouldn't be me, since I
> may be a mentor elsewhere.

I don't have experience with OpenMP (yet), but if nobody more skilled
steps up, I could be a co-mentor. I already filled the contact form
and added myself (with a ? mark) in the wiki.

> Thanks again!
> Anna

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

Re: [GRASS-dev] Min. req. of programming language standard support, GRASS GIS 8

[Maris Nartiss]

2021-02-01 9:56 GMT+02:00, Moritz Lennert :
>
> @those who want to use more recent standards: what are your reasons for that
> ?

Many of GRASS contributors are programmers by chance and not by trade.
(I still consider it to be a miracle that I can spew out reasonably
working C code) A lot of online tutorials and SO answers do not
clarify if features presented in examples are confirming to a certain
standard. Thus demanding conformance to an older C standard would just
increase extra burden on PR reviewers to check conformance and provide
guidance on changing code to confirm with an older C standard.
Automatic checks will not generate alternative versions of code to
comply with older standards. As we have only a few C folks who can
write really advanced code, I would love to see them developing new
exciting features instead of guarding code base from code confirming
to more recent C standard.

Just my 0.02,
Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Min. req. of programming language standard support, GRASS GIS 8

[Maris Nartiss]

Our C code base de facto is not C90. I just run clean compilation with
-Wall -Wextra -pedantic -std=C90 -g -O2 and it generated 405
non-unique ISO C warnings. In comparison C99 and C17 gives 1274
warnings. Compiling with gnu90 and gnu17 gives more warnings.
I guess some of gnu90 warnings will go away when PRs dealing with
compiler warnings will be merged, but many are to stay (long long,
%lf, __func__, variable length arrays). Most of warnings are just
harmless (C++ comments in C code), although some of them are not
(sensu strict C90 conformance e.g. assignment between function pointer
and ‘void *’).

Thus question is – C99 or C17 (as I understood, C11 is not worth as
C17 just relaxes some C11 requirements).
As I am not that strong in C standards, no recommendation from my
side, but can anyone name a platform that is expected to run G8 and
does not have C11/C17 compiler?

In my opinion for G8 we should drop GDAL < 3, PROJ < 6 and C < 11.
Yes, that would reduce our bragging potential as GRASS will not run on
PDP any more, but lets be realistic here on our expectations.

At the end as this seems to be a bit more of political than technical
issue, I would suggest the new PSC to come up with clarification on
our position regarding G8.

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

[GRASS-dev] Statement Māris Nartišs

[Maris Nartiss]

Dear GRASS GIS community,
I am honoured to be nominated for the PSC.

I am a geographer (Dr.geog.) and self-taught programmer. My first
introduction to GRASS was around autumn of 2004 (5.x time). I remember
being fascinated by its 3D visualisation capabilities. I decided to
get to know GRASS better although the learning curve at that time was
really steep. Within recent years there has been a lot of work done to
make GRASS user friendly, especially for inexperienced users. This is
great as now getting started with GRASS requires little effort in
comparison to "good ol' days".

As a member of PSC I plan to keep an eye on meeting power user
requirements. We can not compete with QGIS (or a well known
proprietary GIS) in terms of man and financial power and thus main
focus of GRASS should be on its strengths – being a powerful and
versatile geospatial data analysis toolset. Any user-friendliness
improvements should not take away power from its power users.

As a native speaker of large language (Latvian with ~1M native
speakers), I am proud to have GRASS GIS in Latvian. As long as I will
be involved with GRASS, I plan to keep an eye on GRASS being any
language friendly.

Māris Nartišs.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] grass python problem

[Maris Nartiss]

Please provide more information:
GRASS version
Python version
exact error message

I did not observe any errors while running command you provided (of
course I used different map names to match map names I had on my
system).
Māris.

otrd., 2020. g. 17. nov., plkst. 06:04 — lietotājs ming han
() rakstīja:
>
> Hi Everyone
>
> Hope this email finds you well.
> I can run r.cross in console with following command:
> "r.cross -z --overwrite --quiet 
> input=Connect_Lake@PERMANENT,str_grass_r@PERMANENT output=test"
>
> But I got error by run r.cross in python with following command:
> grass.run_command('r.cross', input = 
> ['str_grass_r@PERMANENT','Connect_Lake@PERMANENT'],output = 'test', quiet = 
> True)
>
>  What is the correct format to use r.cross function in Python? and how to 
> obtain the output table generated by r.cross?
>
> Thanks
> Ming
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Website does not work with www for me

[Maris Nartiss]

piektd., 2020. g. 14. aug., plkst. 02:17 — lietotājs Markus Neteler
() rakstīja:
>
> Do we want that, too? I'd find it confusing, with and without www. But let's 
> hear opinions!
>
> Markus

I would vote for setting up a wildcard DNS entry (*.grass.osgeo.org) +
redirect to grass.osgeo.org thus
any.domain.that.ends.with.grass.osgeo.org is a valid redirect to GRASS
main page. Subdomains with explicit DNS records are not affected by
wildcard entry.

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

Re: [GRASS-dev] Source code layout reorganization for G8

[Maris Nartiss]

Thank you Vaclav for your input!

otrd., 2020. g. 9. jūn., plkst. 04:34 — lietotājs Vaclav Petras
() rakstīja:
>
> Hi Maris,
>
> Well, technically, source code layout is generally not part of an API and we 
> don't promote it that way, so changing it anytime shouldn't be a problem. 
> Practically, there might be build and packaging scripts and local patches 
> people use which may break, but perhaps minor versions are a good match for 
> this work too.

Yes and no. Keep in mind — serious reordering of source code might
break things on our side for some time and might require updating
scripts for packagers. Thus it would be better to do it for G8 as
everyone should expect major breakage on a major release.

> Even just getting the "module families" from the root dir would help. Plus 
> there is couple of issues with the current include, lib/python, and 
> gui/wxpython directories.
>
> I have extended the page couple of days ago.

Thanks for the good points on problematic places.

> Other things like splitting into multiple files, formatting, or even moving 
> things around also make searching history more complicated and I think this 
> fits into the line with things which are worth it.
>
> A lot of the changes is independent, so that makes it simpler, but having an 
> overall vision where these would fall in is helpful.
>
> Best,
> Vaclav

Thanks once more,
Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Source code layout reorganization for G8

[Maris Nartiss]

Hello list,
as G8 release is a great opportunity to break things, we could
reorganize our source code directory layout. At the moment we have
docker together with documentation and library intermingled with
MS-Windows for MacOSX. Bringing to a separate thread from "where to
make compiling instructions available"
https://www.mail-archive.com/grass-dev@lists.osgeo.org/msg59974.html

I have created an initial proposal page in Trac (linked to GRASS 8
planning page): https://trac.osgeo.org/grass/wiki/G8SourceLayout

Feel free to express your opinion — is it worth? How the new directory
layout should look like? Any technical restrictions?

Yes, it would break history, scripts, Make files = no fun. But if we
don't do it now, we'll be stuck till G9 release.

Waiting for feedback,
Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] where to make compiling instructions available

[Maris Nartiss]

On a more general note — it seems to be a good idea to completely
reorganize GRASS source tree structure for G8. I have already added it
to the list of G8 ideas:
https://trac.osgeo.org/grass/wiki/Grass8Planning#Codeorganisationcodingstyles
At the moment we have actual source intermingled with compilation and
packaging related stuff and with every new way how to deliver GRASS it
gets only worse. Feel free to add your ideas on potential new source
tree layout to the trac.

Māris.

piektd., 2020. g. 29. maijs, plkst. 04:14 — lietotājs Vaclav Petras
() rakstīja:
>
> A script in the source code preferably executed in GitHub Actions seems like 
> a good place for a build of a primary distribution for macOS. It would not 
> only show which latest change to the source code breaks the build, but it 
> would also clearly show that the script itself works over and over again in 
> at least one environment.
>
> Vaclav
>
> On Wed, May 27, 2020 at 5:19 PM Michael Barton  wrote:
>>
>> I've put together a step by step guide to compiling Mac binaries, using 
>> Anaconda. Because it uses Anaconda, it probably does not belong in the 
>> source code (though it might help someone create instructions for the source 
>> code). However, it would probably be helpful to at least some people. Any 
>> suggestions as to where I should put this?
>>
>> Michael
>> 
>> C. Michael Barton
>> Director, Center for Social Dynamics & Complexity
>> Director, Network for Computational Modeling in Social & Ecological Sciences
>> Professor of Anthropology, School of Human Evolution & Social Change
>> Head, Graduate Faculty in Complex Adaptive Systems Science
>> Arizona State University
>>
>> voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
>> fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
>> www: 'http://www.public.asu.edu/~cmbarton, https://complexity.asu.edu/csdc'
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Calling all imagery (especially i.maxlik and i.smap) users

[Maris Nartiss]

Hello Brad.
piektd., 2020. g. 8. maijs, plkst. 05:36 — lietotājs Brad ReDacted
() rakstīja:
>
> Hello,
>
> IIRC, signatures cannot be handled as colors without significant modification 
> to api.
>
> Is there a particular reason for not improving the API to be map portable and 
> remove subgroups from modules that do not explicitly require it?

Thanks also to Veronica and Sajid for feedback :-)
Yes, that's the whole point of this thread — to find out more how
people use GRASS image groups so they can be changed (requiring
breaking API, GRASS database structure).

Last night I couldn't sleep and came up with a sound idea of replacing
subgroups with semantically sounder alternative that would allow to
make group independent signature files. Concept still needs some
thinking over and writing/drawing. If anyone is willing to help in
changing imagery support for GRASS 8, let me know.

Māris.

PS. More user stories are still welcome :-)
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Let's talk about releases - 7.8.3, 7.10, 8.0

[Maris Nartiss]

Thanks, Vaclav, for taking initiative into your hands. Please send us
approximate time of the new startup screen discussion meeting.

All best,
Māris.

otrd., 2020. g. 5. maijs, plkst. 21:10 — lietotājs Vaclav Petras
() rakstīja:
>
> New URL (Zoom):
>
> https://ncsu.zoom.us/j/95921808290?pwd=UnVOa0VHN2gvbWJLbDExNEJ4TWU3Zz09
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Calling all imagery (especially i.maxlik and i.smap) users

[Maris Nartiss]

Hello lists (sorry for cross-posting),
as GRASS 8 starts to look less Duke Nukem Forever (a.k.a. never), it
is a chance to change some things in imagery part. Thus if you heavy
relay on imagery part of GRASS GIS, please find some time to give
small feedback.

GRASS 7.8.0 imagery groups gained functionality of fully qualified
maps and thus could be used from other mapsets, still some issues
popped up.

#1 Should there be subgroups at all?
There has been a call to completely eliminate subgroups [1] and stick
only with groups. If you are using subgroups, this is the right moment
to share your user story (and not hypothetical one!).

#2 Should i.maxlik add its output to the group?
Current implementation of i.maxlik adds classification result to the
input group [2]. This prevents use of i.maxlik with imagery group from
other mapset. I would vote to remove such feature. If you have a use
case where such functionality is needed, speak now, or forever hold
your peace.

#3 Should signature files be handled similarly to raster colors?
i.cluster, i.gensig and i.gensigset write signature files to imagery
subrgoup. This is not possible if group is located in other mapset. My
proposal — handle signatures as raster colours — signatures are always
saved in current mapset. Thus signatures created for a group in other
mapset would be not visible in other mapsets.

Thank you in advance for your feedback,
Māris.

1. https://trac.osgeo.org/grass/ticket/3440
2. https://trac.osgeo.org/grass/ticket/3525
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Fwd: New Defects reported by Coverity Scan for grass

[Maris Nartiss]

Hello Vaclav.

otrd., 2020. g. 4. febr., plkst. 19:51 — lietotājs Vaclav Petras
() rakstīja:
>
> Hi Maris and Markus,
>
> On Tue, Feb 4, 2020 at 3:39 AM Maris Nartiss  wrote:
>>
>> Hello Markus,
>> as most of errors reported are legit, some of them are useless at the
>> current philosophy of GRASS GIS. We are OK with small memory leaks, as
>> modules are intended to be short running and then memory is reclaimed
>> by the OS (this is faster than freeing it before exit). Of course,
>> this would not be OK for long-running apps.
>
>
> Most of them will be like what you describe, but are there some where memory 
> could be freed during the processing making space for more processing (e.g. 
> by another process)? Also the library should not leak as it should be 
> possible to write module which is long-running (without leaks and checkable 
> by Coverity or valgrind).

As I wrote, it is more about philosophical approach as most of leaks
are small (i.e. not freeing a mapset / location name after use etc.).
If we adopt a new policy of no leaks, code could be changed in a
slowly manner (case by case as need arises).

>
>>
>> Unless we change our
>> approach, resource leaks are just a noise.
>
>
> One approach might be marking the places for Coverity to ignore making the 
> leak explicit (i.e., clearly intentional). Another approach might be some 
> G_optional_free() which could be G_free() in debug mode, but empty otherwise.

This is interesting idea. I recently was thinking about having
different build types. I haven't been doing any profiling, but getting
rid of G_debug could be an option for release version. Having GRASS
scripts running for more than 400 CPU days forces to be creative ;-)

>>
>>
>> I would vote against integrating Coverty scan into CI — just to keep
>> noise level down. It is useless to get regular reports if we do not
>> plan (lack of manpower) to react to them.
>
>
> I agree that the current number of errors is high, but if I understand it 
> correctly (and Markus can correct me here), the integration with CI is not 
> about having the errors visible for each PR on GitHub, but rather pushing 
> things automatically to Coverity from Travis, so that Markus does not have to 
> upload that manually.

+1 if it reduces load of Markus.

>
> Best,
> Vaclav

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

Re: [GRASS-dev] Workshop a FOSS4G 2020

[Maris Nartiss]

Keep in mind also FOSS4G Europe (ideal for those who do not want to
take a step out of Schengen area).

Māris.

pirmd., 2020. g. 3. febr., plkst. 18:38 — lietotājs Luca Delucchi
() rakstīja:
>
> Hi everybody,
>
> Is someone thinking to submit a workshop proposal for FOSS4G 2020?
>
> --
> ciao
> Luca
>
> www.lucadelu.org
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Fwd: New Defects reported by Coverity Scan for grass

[Maris Nartiss]

Hello Markus,
as most of errors reported are legit, some of them are useless at the
current philosophy of GRASS GIS. We are OK with small memory leaks, as
modules are intended to be short running and then memory is reclaimed
by the OS (this is faster than freeing it before exit). Of course,
this would not be OK for long-running apps. Unless we change our
approach, resource leaks are just a noise.

I would vote against integrating Coverty scan into CI — just to keep
noise level down. It is useless to get regular reports if we do not
plan (lack of manpower) to react to them.

Just my 0.02 cents,
Māris.

pirmd., 2020. g. 3. febr., plkst. 21:50 — lietotājs Markus Neteler
() rakstīja:
>
> Hi devs,
>
> I have re-run the coverity scan on master, results below.
>
> There is also the option of Travis integration which might be a good idea.
> Anyone to support this?
>
> Markus
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Error in GRASS GUI startup

[Maris Nartiss]

Also a precise version of GRASS GIS (7.8.1 or 7.8.2).
There where some start-up related issues fixed in 7.8.2 (see 1, 2 & 3).

One thing you can try out is to completely delete ~/.grass7 directory.

1. https://github.com/OSGeo/grass/pull/155
2. https://github.com/OSGeo/grass/pull/185
3. https://github.com/OSGeo/grass/pull/167

Māris.

sestd., 2019. g. 21. dec., plkst. 09:28 — lietotājs Huidae Cho
() rakstīja:
>
> Hello Kiersten,
>
> First, we need to know which OS you are using. Are you on MS Windows, Linux, 
> or Mac? How did you install GRASS if it's Windows? OSGeo4W or stand-alone 
> (https://grass.osgeo.org/download/software/ms-windows)?
>
> Thanks,
> Huidae
>
> On Fri, Dec 20, 2019 at 6:27 PM Kiersten  wrote:
>>
>> Hello devs,
>>
>> I'm very new to GRASS-GIS. Many jobs in my field want some level of
>> familiarity with GIS so, I wanted to get ahead and try seeing if I can learn
>> a free version of GIS on my own (since I know that non-GRASS GIS systems can
>> be costly).
>>
>> I followed along the step-by-step tutorial and had GRASS 7.8 installed.
>> Everything was fine until I downloaded the NC dataset (using the "location
>> wizard"). I tried to then start a GRASS session with that data, and all of a
>> sudden the program closed out. I tried to re-open GRASS, when I was hit with
>> the following message:
>>
>> ERROR: Error in GUI startup. See messages above (if any) and if necessary,
>> please report this error to the GRASS developers.
>> On systems with package manager, make sure you have the right GUI package,
>> probably named grass-gui, installed.
>> To run GRASS GIS in text mode use the --text flag.
>> Use '--help' for further options
>>  grass78 --help
>> See also: https://grass.osgeo.org/grass78/manuals/helptext.html
>>
>> I tried and tried to download the GUI package, but the websites led me in
>> circles and nothing was working. I tried the sites recommended, I tried
>> downloading aptitude in case I was doing anything wrong, but nothing. I'm
>> pulling my hair out!
>>
>> I'm really not sure what to do. Technology is not my strong point (heck,
>> even running R or SAS for classes is still a struggle for me), so I figured
>> I would turn to asking real people for help, since the websites haven't been
>> much help for me. Please let me know if I should ask this on a different
>> part of the forum.
>>
>> I would really appreciate some help. I've found with computer stuff, there
>> is no such thing as over-explaining it to me! Thank you very much in
>> advance.
>>
>>
>>
>> --
>> 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
>
>
>
> --
> Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE
> Open Source GIS Developer, GRASS GIS Development Team
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] any special reason why choice of raster compression method is done via environmental variable ?

[Maris Nartiss]

What should be the solution? Moving to choice set by g.gisenv?

Māris.

trešd., 2019. g. 4. dec., plkst. 11:28 — lietotājs Moritz Lennert
() rakstīja:
>
> Hi Markus,
>
> In recent days, I've been confronted several times with the issue of
> people trying to share data among themselves, but using different
> versions of GRASS, and so raster data compressed in a more recent
> version of GRASS was not usable in an older version of GRASS.
>
> Now, I agree that generally the solution is to tell people to use the
> latest and greatest, but this is not always possible / it is not
> necessarily highest on the list of priorities of people to see how they
> can install the latest version of GRASS within their particular environment.
>
> Obviously, those with the latest version of GRASS can simple recompress
> using ZLIB. However, compression method is defined as an environment
> variable. This is somewhat daunting to many MS Windows users out there.
> Is there any specific reason that lead to the choice of not using a
> parameter to allow the choice of compression method (possibly to
> override a default that is still defined by an environment variable) ?
>
> Moritz
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] PyCharm 2019 with Grass 7.8.1

[Maris Nartiss]

I have been dealing with similar large file count issue by splitting
processing into two parts — processing script for a single file
launched with "grass --exec python my_processing_script
params_for_script" — no need for setting up session in advance etc.;
launcher script starting multiple processing scripts in parallel (one
file = one mapset).
Afterwards it is easy to modify launcher script to be started by srun
or sbatch and migrate to more than one PC, when your tasks outgrows
single system resources.

Good luck,
Māris.

otrd., 2019. g. 26. nov., plkst. 15:04 — lietotājs Stefan Blumentrath
() rakstīja:
>
> Hi Zoltan,
>
> did you try https://github.com/zarch/grass-session
> That should simplify running GRASS algorithms using GRASS more as a library.
>
> Cheers
> Stefan
> 
> Fra: grass-dev  på vegne av Zoltan Szecsei 
> 
> Sendt: tirsdag 26. november 2019 13:34
> Til: grass-dev@lists.osgeo.org 
> Emne: [GRASS-dev] PyCharm 2019 with Grass 7.8.1
>
> Hi,
> I've just installed QGIS/GRASS etc with Osgeo4w64, but am struggling to
> find out how to set up PyCharm to do some grasspy scripting with.
> (import grass.scripting as gscript fails - I have set GISBASE, GRASSBIN
> and PATH to various C:\OSGeo4W64\apps\grass\grass78 folders)
>
> I need to run r.thin over 2800 tif images, so figured a python loop
> should do it.
>
> Any pointers would be welcome.
>
> Thanks and regards,
> Zoltan
>
> --
>
> =
> Zoltan Szecsei GPrGISc 0031
> Geograph (Pty) Ltd.
> GIS and Photogrammetric Services
>
> P.O. Box 7, Muizenberg 7950, South Africa.
>
> Mobile: +27-83-6004028 (WhatsApp only)
> Qatar:  +974 5083 2722 www.geograph.co.za
> =
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GitHub: how to fwd pull requests to this list?

[Maris Nartiss]

The biggest question is – do we need PR notifications here. I would
vote for no. Better let's keep discussions in one place.

And no, PRs don't get lost. They all are on GitHub. If a PR was lost,
that is a bug in GitHub and needs to be addressed ASAP.

When we moved to the new workflow, those with rights to merge PRs
(implicitly) agreed to go over PR list on a (semi)regular basis and
merge them if they are good.

Have a nice day,
Māris.

piektd., 2019. g. 12. jūl., plkst. 17:10 — lietotājs Huidae Cho
() rakstīja:
>
> Markus,
>
> I don't think that list has PR notifications. That's only for actual merges, 
> not everything, if I'm not wrong.
>
> Best,
> Huidae
>
>
> On Fri, Jul 12, 2019 at 9:58 AM Markus Neteler  wrote:
>>
>> Hi,
>>
>> On Fri, Jul 12, 2019 at 6:12 AM Huidae Cho  wrote:
>> >
>> > Markus,
>> >
>> > I think I have a workaround. In the worst case scenario, if GitHub doesn't 
>> > support notification forwarding, we could create a dummy GitHub account 
>> > just for notifications and set its email address to 
>> > grass-dev@lists.osgeo.org.
>>
>> Well, we do have this list:
>>
>> https://lists.osgeo.org/pipermail/grass-commit/
>>
>> which contains everything from GitHub (I had set it up like this).
>>
>> But I would like to see _only_ the PRs also here and not clutter this
>> list with the other GH emails.
>> Not sure how to do that...
>>
>> Best
>> Markus
>
>
>
> --
> Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE
> Open Source GIS Developer, GRASS GIS Development Team
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] (no subject)

[Maris Nartiss]

Hello,
usually it indicates on some remnants of previous version lying around
somewhere. Check out also for all extensions or your own custom
modules as they need to be rebuilt too.

Māris.

piektd., 2019. g. 24. maijs, plkst. 18:18 — lietotājs Paulo van
Breugel () rakstīja:
>
> Hi devs
>
> I just did a completely fresh install of grass 7.6.2. The whole compilation 
> is completed without issues. But when starting grass up, I am getting the 
> following message.
>
> GRASS 7.6.2svn (nc_spm_08_grass7):~ > ERROR 1: libgrass_raster.7.5.svn.so: 
> cannot open shared object file: No such file or directory
> ERROR 1: libgrass_raster.7.5.svn.so: cannot open shared object file: No such 
> file or directory
>
> I started completely anew, removed everything before compiling (as far as I 
> know), including the .grass7 folder, so I wonder what else I could have done 
> wrong? Any idea how I can find out where the problem lies?
>
> Cheers,
>
> Paulo
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] OSGeo4W winGRASS77svn: TypeError: endswith first arg must be bytes or a tuple of bytes, not str

[Maris Nartiss]

Same error on Vista with same version. Locale is set to Latvia.

Māris.

sestd., 2019. g. 27. apr., plkst. 14:58 — lietotājs Helmut Kudrnovsky
() rakstīja:
>
> Helmut Kudrnovsky wrote
> > Hi,
> >
> > just tried to start the latest OSGeo4W winGRASS77svn daily build:
> >
> > 
> > C:\>grass77svn
> > Starting GRASS GIS...
> > Traceback (most recent call last):
> >   File "C:\OSGEO4~1\apps\grass\grass77\gui\wxpython\gis_set.py", line 34,
> > in
> > 
> > from core import globalvar
> >   File "C:\OSGEO4~1\apps\grass\grass77\gui\wxpython\core\globalvar.py",
> > line
> > 35, in
> > 
> > from core.debug import Debug
> >   File "C:\OSGEO4~1\apps\grass\grass77\gui\wxpython\core\debug.py", line
> > 77,
> > in
> > 
> > Debug = DebugMsg()
> >   File "C:\OSGEO4~1\apps\grass\grass77\gui\wxpython\core\debug.py", line
> > 39,
> > in __init__
> > self.SetLevel()
> >   File "C:\OSGEO4~1\apps\grass\grass77\gui\wxpython\core\debug.py", line
> > 45,
> > in SetLevel
> > self.debuglevel = int(grass.gisenv().get('WX_DEBUG', 0))
> >   File "C:\OSGEO4~1\apps\grass\grass77\etc\python\grass\script\core.py",
> > line 1074, in gisenv
> > s = read_command("g.gisenv", flags='n', env=env)
> >   File "C:\OSGEO4~1\apps\grass\grass77\etc\python\grass\script\core.py",
> > line 494, in read_command
> > process = pipe_command(*args, **kwargs)
> >   File "C:\OSGEO4~1\apps\grass\grass77\etc\python\grass\script\core.py",
> > line 463, in pipe_command
> > return start_command(*args, **kwargs)
> >   File "C:\OSGEO4~1\apps\grass\grass77\etc\python\grass\script\core.py",
> > line 393, in start_command
> > return Popen(args, **popts)
> >   File "C:\OSGEO4~1\apps\grass\grass77\etc\python\grass\script\core.py",
> > line 54, in __init__
> > cmd = shutil_which(args[0])
> >   File "C:\OSGEO4~1\apps\Python37\lib\shutil.py", line 1151, in which
> > if any(cmd.lower().endswith(ext.lower()) for ext in pathext):
> >   File "C:\OSGEO4~1\apps\Python37\lib\shutil.py", line 1151, in
> > 
> > if any(cmd.lower().endswith(ext.lower()) for ext in pathext):
> > TypeError: endswith first arg must be bytes or a tuple of bytes, not str
> > ERROR: Error in GUI startup. See messages above (if any) and if necessary,
> > please report this error to the GRASS developers.
> > On systems with package manager, make sure you have the right GUI package,
> > probably named grass-gui, installed.
> > To run GRASS GIS in text mode use the --text flag.
> > Use '--help' for further options
> >  grass77 --help
> > See also: https://grass.osgeo.org/grass77/manuals/helptext.html
> > Exiting...
> > Drücken Sie eine beliebige Taste . . .
> > 
> >
> > anyone any idea?
>
> C:\>g.version -g
> version=7.7.svn
> date=2019
> revision=r74428M
> build_date=2019-04-26
> build_platform=x86_64-w64-mingw32
> build_off_t_size=8
>
>
>
> -
> 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 mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Trunk breakage with Python 2

[Maris Nartiss]

Hello everyone,
is Python 2 still supported or trunk is already 3 only? If it is
supported, then a serious fixing is required. If it is Python 3 only,
then it should run on Python 3 and not 2.

After recent changes, most of GUI functionality is more-less broken
with console filling with various UnicodeDecodeError errors. Startup
screen works (sort of), autogenerated GUIs – only partial
functionality, layer manager & map window – fail to start.

python --version
Python 2.7.15

LANG=lv_LV.UTF-8
LC_CTYPE=lv_LV.utf8
LC_NUMERIC=lv_LV.utf8
LC_TIME=lv_LV.utf8
LC_COLLATE=lv_LV.utf8
LC_MONETARY=lv_LV.utf8
LC_MESSAGES=lv_LV.utf8
LC_PAPER=lv_LV.utf8
LC_NAME=lv_LV.utf8
LC_ADDRESS=lv_LV.utf8
LC_TELEPHONE=lv_LV.utf8
LC_MEASUREMENT=lv_LV.utf8
LC_IDENTIFICATION=lv_LV.utf8

[IP-] [  ] app-eselect/eselect-wxwidgets-20180529:0
[IP-] [  ] dev-python/wxpython-3.0.2.0:3.0
[IP-] [  ] x11-libs/wxGTK-3.0.4-r1:3.0
[IP-] [  ] x11-libs/wxGTK-3.0.4-r301:3.0-gtk3

bin.x86_64-pc-linux-gnu/grass77
Startē GRASS GIS...
/usr/lib64/python2.7/site-packages/wx-3.0-gtk2/wx/_core.py:16629:
UserWarning: wxPython/wxWidgets release number mismatch
  warnings.warn("wxPython/wxWidgets release number mismatch")
Traceback (most recent call last):
  File 
"/home/maris/soft/grass_trunk/dist.x86_64-pc-linux-gnu/gui/wxpython/gui_core/widgets.py",
line 545, in DoGetBestSize
self._updateLabel()
  File 
"/home/maris/soft/grass_trunk/dist.x86_64-pc-linux-gnu/gui/wxpython/gui_core/widgets.py",
line 565, in _updateLabel
GenStaticText.SetLabel(self, newLabel)
  File "/usr/lib64/python2.7/site-packages/wx-3.0-gtk2/wx/lib/stattext.py",
line 58, in SetLabel
wx.PyControl.SetLabel(self, label)
  File "/usr/lib64/python2.7/site-packages/wx-3.0-gtk2/wx/_core.py",
line 9207, in SetLabel
return _core_.Window_SetLabel(*args, **kwargs)
  File "/usr/lib64/python2.7/encodings/utf_8.py", line 16, in decode
return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xc4 in position
27: invalid continuation byte
Traceback (most recent call last):
  File 
"/home/maris/soft/grass_trunk/dist.x86_64-pc-linux-gnu/gui/wxpython/gui_core/widgets.py",
line 545, in DoGetBestSize
self._updateLabel()
  File 
"/home/maris/soft/grass_trunk/dist.x86_64-pc-linux-gnu/gui/wxpython/gui_core/widgets.py",
line 565, in _updateLabel
GenStaticText.SetLabel(self, newLabel)
  File "/usr/lib64/python2.7/site-packages/wx-3.0-gtk2/wx/lib/stattext.py",
line 58, in SetLabel
wx.PyControl.SetLabel(self, label)
  File "/usr/lib64/python2.7/site-packages/wx-3.0-gtk2/wx/_core.py",
line 9207, in SetLabel
return _core_.Window_SetLabel(*args, **kwargs)
  File "/usr/lib64/python2.7/encodings/utf_8.py", line 16, in decode
return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xc5 in position 7:
invalid continuation byte
Traceback (most recent call last):
  File 
"/home/maris/soft/grass_trunk/dist.x86_64-pc-linux-gnu/gui/wxpython/gui_core/widgets.py",
line 556, in OnSize
self._updateLabel()
  File 
"/home/maris/soft/grass_trunk/dist.x86_64-pc-linux-gnu/gui/wxpython/gui_core/widgets.py",
line 565, in _updateLabel
GenStaticText.SetLabel(self, newLabel)
  File "/usr/lib64/python2.7/site-packages/wx-3.0-gtk2/wx/lib/stattext.py",
line 58, in SetLabel
wx.PyControl.SetLabel(self, label)
  File "/usr/lib64/python2.7/site-packages/wx-3.0-gtk2/wx/_core.py",
line 9207, in SetLabel
return _core_.Window_SetLabel(*args, **kwargs)
  File "/usr/lib64/python2.7/encodings/utf_8.py", line 16, in decode
return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xc5 in position
145: unexpected end of data
Traceback (most recent call last):
  File 
"/home/maris/soft/grass_trunk/dist.x86_64-pc-linux-gnu/gui/wxpython/gui_core/widgets.py",
line 556, in OnSize
self._updateLabel()
  File 
"/home/maris/soft/grass_trunk/dist.x86_64-pc-linux-gnu/gui/wxpython/gui_core/widgets.py",
line 565, in _updateLabel
GenStaticText.SetLabel(self, newLabel)
  File "/usr/lib64/python2.7/site-packages/wx-3.0-gtk2/wx/lib/stattext.py",
line 58, in SetLabel
wx.PyControl.SetLabel(self, label)
  File "/usr/lib64/python2.7/site-packages/wx-3.0-gtk2/wx/_core.py",
line 9207, in SetLabel
return _core_.Window_SetLabel(*args, **kwargs)
  File "/usr/lib64/python2.7/encodings/utf_8.py", line 16, in decode
return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xc5 in position
145: unexpected end of data
Traceback (most recent call last):
  File 
"/home/maris/soft/grass_trunk/dist.x86_64-pc-linux-gnu/gui/wxpython/gui_core/widgets.py",
line 556, in OnSize
self._updateLabel()
  File 
"/home/maris/soft/grass_trunk/dist.x86_64-pc-linux-gnu/gui/wxpython/gui_core/widgets.py",
line 565, in _updateLabel
GenStaticText.SetLabel(self, newLabel)
  File "/usr/lib64/python2.7/site-packages/wx-3.0-gtk2/wx/lib/stattext.py",
line 58, in 

Re: [GRASS-dev] introduce EOL policy

[Maris Nartiss]

Hello,

ceturtd., 2019. g. 11. apr., plkst. 23:46 — lietotājs Markus Neteler
() rakstīja:
> On Fri, Mar 29, 2019 at 8:42 AM Martin Landa  wrote:
> > 7.7 -> develpment
> > 7.6 -> stable
> > 7.4 -> maintenance
> > What do you think?
I think we should stop adding LTS to releases unless we plan to
support them for several years (~one full Debian/Ubuntu LTS cycle).
One year a go we released 7.2.3 and labelled it as a LTS.
I am fine with Martin's proposal as long as we are clear what we mean with LTS.

> Markus
> > Ma
Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Proposal: Python package for topology tools

[Maris Nartiss]

Hello Facundo,
the easiest way would be moving functions of v.generalize into a
library (e.g. grass_generalize) and thus make available for calling
via ctypes.
In the past I have had a good success manipulating GRASS vectors via
ctypes. It takes more skill than a plain Python implementation but it
is easier than a full blown C code and faster than pure Python one.

Māris.

ceturtd., 2019. g. 28. marts, plkst. 03:13 — lietotājs Facundo Ferrin
() rakstīja:
>
> Hi Luca!
>
> Thanks for replying! In my job, there were things we had to do 
> programmatically. For example, to manipulate geometries that reach the 
> backend from a GeoJSON we use tools like these:
>
> https://pcjericks.github.io/py-gdalogr-cookbook/geometry.html#create-geometry-from-wkt
>
> However, polygon simplification does not work very well because it does not 
> take topology into account. My idea was to port part of the GRASS algorithms 
> to be able to use them without needing the graphical interface or command 
> line, but only importing a library in a Python script.
>
> Is it something that you have in mind to do or that might be useful to you?
>
>
> El jue., 28 de mar. de 2019 a la(s) 00:32, Luca Delucchi 
> (lucadel...@gmail.com) escribió:
>>
>> On Tue, 26 Mar 2019 at 03:11, Facundo Ferrin  
>> wrote:
>> >
>> > Hi there!
>>
>> Hi Facundo,
>> >
>> >
>> > My name is Facundo Ferrin. I am a nuclear engineer who is taking a master 
>> > in Computer Vision in Barcelona, and finally I found my opportunity to 
>> > contribute to OSGeo by applying two things that I really like: Python and 
>> > Backend development . I do not know exactly what I should write in this 
>> > first email, so I'll start by listing the projects I'm interested in.
>> >
>> > I'm working in a company that is developing a platform for precision 
>> > agriculture called Auravant (https://www.auravant.com/). I work as a 
>> > backend developer and data analyst and I use daily almost every tool that 
>> > you post in the ideas: GeoServer, PostGIS, QGis. I'm also porting a tool 
>> > for polygon simplification called topoJSON 
>> > (https://github.com/fferrin/topojson).
>> >
>> > ---
>> > MY MAIN IDEA is to start porting GRASS tools into a python package that 
>> > can be used in other projects (beyond the client to use by command line). 
>> > I don't know if it's something you have in mind but for offline and 
>> > automated analysis it would be very useful. I particularly had problems 
>> > when I tried to simplify geometries since the geometry of polygons was not 
>> > taken into account.
>> > ---
>>
>> Your idea is not clear to me, there are already two Python library to
>> work with GRASS. you can find some ideas in the proposal page
>> https://trac.osgeo.org/grass/wiki/GSoC/2019 (for example
>> Neweasy-to-useCLIandAPIforGRASSGIS) and
>> https://trac.osgeo.org/grass/wiki/GSoC/2018 (Improve GRASS integration
>> in QGIS 3)
>>
>> > Hope to hear from you soon!
>> >
>>
>> --
>> ciao
>> Luca
>>
>> www.lucadelu.org
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Introduction and Idea ( GSOC 2019 )

[Maris Nartiss]

Hello,
svētd., 2019. g. 3. marts, plkst. 08:50 — lietotājs Luca Delucchi
() rakstīja:
>
> On Sat, 2 Mar 2019 at 18:48, Soumya kanta Das
>  wrote:
> >
> > Hello,
>
> Hi,
>
> > Myself Soumya Kanta Das, studying Geo-informatics. Currently i work on 
> > automating geospatial workflow and Machine learning applications. I have 
> > previously worked on automated identification of buildings in Satellite 
> > imagery using Deep learning. I have language proficiency in python.
> >
> > I would like to develop a Deep learning module for grass using tensorflow 
> > library and python 3. Which would be very helpful for end-users.
> >
>
> something already exists in GRASS GIS addons using tensorflow [0], you
> can have look there..

I have a working prototype of GRASS – Keras bridge (still needs a lot
of work to fix all edge cases + support of second image_data_format).
My first approach was to use pure Python code, but it turned out to be
reay slooow. Large parts have to be written in C (linked via
ctypes). Currently there still is a speed penality due to GRASS raster
code not supporting mutlithreaded applications. It all can be worked
around.

Developing any high speed interface between ML libraries and GRASS
needs some (good) understanding of working with multidimensional
arrays in C and GRASS rasters in C.

> > Thank you.
> >
>
> [0] https://grass.osgeo.org/grass74/manuals/addons/i.ann.maskrcnn.html
>
> --
> ciao
> Luca

Just FYI,
Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r73982 - in grass/trunk/include: . defs

[Maris Nartiss]

otrd., 2019. g. 22. janv., plkst. 13:04 — lietotājs Martin Landa
() rakstīja:
>
> Hi,
>
> this macro is causing compilation error on Windows [1]. I took liberty
> to modify macro in r73998.
Thanks!

> Ma
Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] GRASS GIS 7.8.0 with Python3 support

[Maris Nartiss]

trešd., 2019. g. 9. janv., plkst. 18:47 — lietotājs Markus Neteler
() rakstīja:
>
> On Wed, Jan 9, 2019 at 4:01 PM Maris Nartiss  wrote:
> ...
> > Too late. Python is already broken (I had to fix my scripts;
> > previously working tests are now broken). Do not expect your 7.2/7.4
> > Python scripts to work with 7.6/7.8 without modifications (depends on
> > functionality in use).
>
> This is weird. Can you elaborate?
Unfortunately I just fixed my code and moved on (as transitioning to
Python 3 has to be done). But here are two examples from the top of my
head:
https://trac.osgeo.org/grass/ticket/3707
grass.script.parse now returns unicode strings, previously – byte
strings (too lazy to search for a specific revision when it was
introduced). Took a while to understand why calls to an external
library started to fail.

> > Still – it is not so bad – some Python parts never have been working
> > correctly anyway ;-)
>
> Please open ticket(s) if you want to see it fixed.
This is really tricky as for many aspects of GRASS Python code there
are no working examples in the GRASS source or add-ons and thus it is
hard to understand if it is broken or just "I'm holding it the wrong
way" ;-)
I'll try to come up with a test case for raster.history, as it is one
of things I can not get working at the moment.

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

Re: [GRASS-dev] [release planning] GRASS GIS 7.8.0 with Python3 support

[Maris Nartiss]

trešd., 2019. g. 9. janv., plkst. 14:18 — lietotājs Laurent C.
() rakstīja:
>
> I believe that only a major release could be allowed to break a previously 
> working functionality. It would be very confusing to have a code that work on 
> one version stops working after a minor version bump.
> I my humble opinion it would be contrary to semver that GRASS mostly follows.
Too late. Python is already broken (I had to fix my scripts;
previously working tests are now broken). Do not expect your 7.2/7.4
Python scripts to work with 7.6/7.8 without modifications (depends on
functionality in use).

Still – it is not so bad – some Python parts never have been working
correctly anyway ;-)
> Laurent
Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] GRASS GIS 7.8.0 with Python3 support

[Maris Nartiss]

pirmd., 2019. g. 7. janv., plkst. 12:51 — lietotājs Markus Neteler
() rakstīja:
>
> On Mon, Jan 7, 2019 at 11:48 AM Martin Landa  wrote:
> > po 7. 1. 2019 v 11:41 odesílatel Markus Neteler  napsal:
> > > - Proposal of release: 7 Jan 2019
> > > - Creation of release branch: 24 Jan 2019
> > > - RC1: 1 Feb 2019
> > > - RC2: 7 Feb 2019 - if needed
> > > - Final release: ~14 Feb 2019
This really does not seem to be realistic.

> > I am afraid that more realistic release date for 7.8 version is
> > ~May/June 2019. Python3 support is not fully done (Anna will know
> > more). We don't have Windows builds for testing yet. It also doesn't
> > make sense to me to release 7.6 in January and 7.8 in February.
>
> Personally I would have rather skipped 7.6 but of course that is not possible.
I fail to see why. Is there any major distro dropping 2.7 support now?
If not, then lets better iron out all issues arising from transition
to 3.

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

Re: [GRASS-dev] PO file error?

[Maris Nartiss]

Hello,
there was a bug in the original source code. It was fixed on Oct 10,
2018 by mmetz in r73517. PO files in SVN have not been updated for 2
months thus contain the old message. It should be just fine in
Transifex.

Māris.

otrd., 2018. g. 4. dec., plkst. 03:07 — lietotājs Huidae Cho
() rakstīja:
>
> Hi,
>
> I just found this weird issue in the PO files. This message is in 
> raster/r.spreadpath/main.c line 161. The file itself looks fine, but all PO 
> files miss the first character "R".
>
> G_verbose_message(_("Reading the input map -%s- and -%s- and creating some 
> temporary files..."), backrow_layer, backcol_layer);
>
>
> #: ../raster/r.spreadpath/main.c:161
> #, fuzzy, c-format
> msgid "eading the input map -%s- and -%s- and creating some temporary 
> files..."
>
> I have no idea what happened? A bug in any of our scripts?
>
> Best,
> Huidae
> --
> Huidae Cho, Ph.D., GISP, PE (MD), CFM, M.ASCE
> Open Source GIS Developer, GRASS GIS Development Team
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r73627 - grass/trunk/raster/r.stream.extract

[Maris Nartiss]

... and by doing so marking all translated strings as untranslated.
This exactly is a type of change that should NOT be backported – the
meaning of this string can be understood also when it is misspelled
and backporting would thus harm translations.

Māris.
trešd., 2018. g. 31. okt., plkst. 09:33 — lietotājs Martin Landa
() rakstīja:
>
> Hi,
>
> such commits would be good to backport to G76 (and probably also to
> G74) release branch. Thanks for taking care about backports in
> advance, Ma
>
> st 31. 10. 2018 v 2:54 odesílatel  napsal:
> >
> > Author: hcho
> > Date: 2018-10-30 18:54:09 -0700 (Tue, 30 Oct 2018)
> > New Revision: 73627
> >
> > Modified:
> >grass/trunk/raster/r.stream.extract/cseg.c
> > Log:
> > r.stream.extract: Typo
> >
> > Modified: grass/trunk/raster/r.stream.extract/cseg.c
> > ===
> > --- grass/trunk/raster/r.stream.extract/cseg.c  2018-10-30 21:00:49 UTC 
> > (rev 73626)
> > +++ grass/trunk/raster/r.stream.extract/cseg.c  2018-10-31 01:54:09 UTC 
> > (rev 73627)
> > @@ -83,7 +83,7 @@
> >  int cseg_get(CSEG *cseg, CELL *value, GW_LARGE_INT row, GW_LARGE_INT col)
> >  {
> >  if (Segment_get(&(cseg->seg), value, row, col) < 0) {
> > -   G_warning(_("Unabel to read segment file"));
> > +   G_warning(_("Unable to read segment file"));
> > return -1;
> >  }
> >  return 0;
> >
> > ___
> > grass-commit mailing list
> > grass-com...@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-commit
>
>
>
> --
> 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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.in.ogr and v.import do not import all features in gpkg file

[Maris Nartiss]

trešd., 2018. g. 10. okt., plkst. 16:04 — lietotājs Markus Metz
() rakstīja:
>
> >> I am not sure what to do about this. Disable this safety check again?
> >
> >
> > Maybe the bb safety check makes sense for features other than points, 
> > dunno. Others can for sure tell some use cases that I am not aware of. But 
> > I can say that it is pretty striking to see that some features are "eaten 
> > and lost" when importing into GRASS while ogr and others show everything.
> >
> > What about a flag? Import all by default and the safety check with a flag? 
> > Or at least a note in the manual page of v.in.ogr
>
> I would rather disable this safety check if it does more harm than good.

I would vote for:
1) adding a flag to activate safety check;
2) disable safety check by default;
3) add a check "point in bbox" during import and print a warning if
any point of any geometry is outside of bbox (aka safety check without
action).

>
> Markus M

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

Re: [GRASS-dev] SOLVED: Trunk fails at configure phase on Ubuntu 18.04

[Maris Nartiss]

2018-08-15 23:19 GMT+03:00 Markus Neteler :
> That's strange. I recently updated the Dockerfile in trunk to use
> 18.04 and it works smoothly:
>
> https://hub.docker.com/r/neteler/grassgis7/~/dockerfile/
>
> Perhaps compare to your install procedure?
>
> Markus

Thanks, Markus.
As Docker didn't contain anything suspicious, I almost gave up but
decided to give the last shot to LC_ALL=C. Seems that I must set
LC_COLLATE=C before running ./configure. My previous value was
lv_LV.UTF-8.

Apparently my locale and GRASS build system do not play along nicely.

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

[GRASS-dev] Trunk fails at configure phase on Ubuntu 18.04

[Maris Nartiss]

Hello folks,
I just updated my Ubuntu box from previous LTS to new LTS (18.04).
When I try to configure a fresh trunk checkout, it fails to pass
configure phase:

./configure --enable-debug --with-nls --with-cxx --with-bzlib
--with-liblas --with-freetype
--with-freetype-includes=/usr/include/freetype2 --with-X11
--with-wxwidgets --with-python --with-sqlite --with-geos --with-blas
--with-openmp --with-lapack --with-pdal --with-zstd
configure: error: freetype: invalid package name

Here's the last part of sh -x:
+ test -n
+ ac_optarg=
+ echo --with-freetype
+ sed -e s/-*with-// -e s/=.*//
+ ac_package=freetype
+ echo freetype
+ sed s/[-_a-zA-Z0-9]//g
+ test -n y
+ echo configure: error: freetype: invalid package name
configure: error: freetype: invalid package name
+ exit 1

Any hints how to work around this issue?

It is not a freetype issue, as removing freetype from configure call
then results in failure with Python, or "freetype-includes: invalid
package name". Thus it is something bad in the configure "magic".

Thanks,
Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Dependencies for wxGUI and wx monitors

[Maris Nartiss]

2018-07-11 19:42 GMT+03:00 Nikos Alexandris :
> What are more fundamental dependencies for Graphics? The standard Linux
> graphics stack? Is there any special dependency to X, to Mesa, Cairo, to
> GLX perhaps?

Nothing special, as far as I know.

> My laptop has a integrated Intel graphics card, nothing fancy with the
> hardware.

I do have two boxes with Nvidia cards (Quadro NVS 160m for Gentoo and
Quadro K620 for Ubuntu LTS) running Nouveau and Nvidia proprietary
drivers.

> Note, while the GRASS GIS GUI works, I do observe many glitches in my
> system.
> Like, zoom in or out, does not refresh properly the display. The "new"
> map is rendered on top of the old, resulting in a noisy image.

I can not confirm any issues with GRASS graphical stack. It seems that
your system is semi-broken. I would start with video drivers and then
work all way up (recompile, check and test various parameters). Have
you been trying to run bare bones X11 with some light WM (twm)?

> Thank you Maris.

Have fun with broken drivers ;)
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Dependencies for wxGUI and wx monitors

[Maris Nartiss]

2018-07-07 3:00 GMT+03:00 Nikos Alexandris :
> * Nikos Alexandris  [2018-07-07 01:20:52 +0200]:
>
>> Dears,
>>
>> I have trouble launching wx monitors via `wx0` under Funtoo-Linux. I
>> guess I have something messy in my system. See also
>> https://bugs.funtoo.org/browse/FL-5256.

> Anyone running Funtoo or Gentoo? Thank you for any hint.

Hello Nikos,
d.mon wx0 && d.rast map=mymap works just fine on my Gentoo box and
produces a ppm file in tmp directory. Anything fancy on your box
(Wayland)?

I have wxpython-3.0.2.0 with wxGTK-3.0.3

> Nikos

Māris.
___
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

[Maris Nartiss]

Makrus, there always will be some improvements. I still would prefer
releases with much shorter -RC times as this is not a 7.6.0. Single
-RC should be enough as I have some doubts how much those -RC's are
tested & it just delays getting already existing fixes to end users.

Māris.


2018-06-05 10:44 GMT+03:00 Markus Neteler :
> On Tue, Jun 5, 2018 at 8:49 AM, Martin Landa  wrote:
>> 2018-06-02 14:58 GMT+02:00 Vaclav Petras :
>>> Agreed, e.g.:
>>
>> OK, so please let's go for RC3 and final soon. We are behind schedule
>> a bit :-) Martin
>
> AFAIK some wxGUI related changes were done by Anna in trunk, is
> anything of that yet to be backported?
>
> Markus
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [Issue] String formatting issue

[Maris Nartiss]

Hi Sanjeet,
try like this:

msg = _("Bla bla {0} with {1}").format(zero, one)


Māris.


2018-06-04 3:08 GMT+03:00 Sanjeet :
> Hi everyone,
>
> I came across this type error while porting libs.
>
> msg = _("Module run %s %s ended with error") % (module, code)
> TypeError: %b requires a bytes-like object, or an object that
> implements __bytes__, not 'NoneType'
>
> This uses % format specifier which sometimes fails on Python 3 because
> of strings and bytes differences.
>
> I can resolve this by using fomat() like this:
> msg = _(("Module run {} {} ended with error").format(module,code))
>
> Do you think this is a good way to resolve this?
> Is "format()" going to work well with translations using the
> ''gettext()'' used as _() as shown in the above line?
>
> Thanks,
> Sanjeet
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r72650 - grass/trunk/scripts/i.spectral

[Maris Nartiss]

Hello Moritz,
if subgroups are removed, it will be necessary to update all i.
modules to follow some kind of new workflow. For the current state of
GRASS, subgroups are crucial.
I'm adding output of i.group on my system. As you can see, output of
i.spectral on the output of i.maxlik is nonsense and thus should be
avoided. Also I like to have one group for whole scene and switch
between RGB (visible) and RGBI (VNIR) bands as needed.
IMHO subgroups should be implemented in a way as in i.spectral – if no
subgroup is provided, all maps from the group are used. Thus subgroup
usage would be opt-in for those who understand how to use them.
I somehow fail to see what kind of problem will be solved by removing
subgroup functionality.

Māris.

> i.group -l Mai05
group  references the following raster maps
-



   
   
-

> i.group -ls Mai05
group  references the following subgroups
-
allrgb
-

> i.group -ls Mai05 subgroup=all
subgroup  of group  references the following raster maps
-


-

> i.group -ls Mai05 subgroup=rgb
subgroup  of group  references the following raster maps
-


-

2018-04-26 15:46 GMT+03:00 Moritz Lennert :
> Hi Maris,
>
> Could you explain your motivation behind this commit ? There have been
> discussions on and off (latest at the code sprint in Bonn) about the
> possibility to actually get rid of the notion of subgroups altogether. For
> that discussion, it would be interesting to know the actual patterns of use
> of subgroups.
>
> Moritz
>
>
>
> On 26/04/18 13:19, svn_gr...@osgeo.org wrote:
>>
>> Author: marisn
>> Date: 2018-04-26 04:19:33 -0700 (Thu, 26 Apr 2018)
>> New Revision: 72650
>>
>> Modified:
>> grass/trunk/scripts/i.spectral/i.spectral.py
>> Log:
>> i.spectral: Add subgroup option
>>
>>
>> Modified: grass/trunk/scripts/i.spectral/i.spectral.py
>> ===
>> --- grass/trunk/scripts/i.spectral/i.spectral.py2018-04-26
>> 10:20:18 UTC (rev 72649)
>> +++ grass/trunk/scripts/i.spectral/i.spectral.py2018-04-26
>> 11:19:33 UTC (rev 72650)
>> @@ -36,6 +36,10 @@
>>   #% required : no
>>   #% guisection: Input
>>   #%end
>> +#%option G_OPT_I_SUBGROUP
>> +#% required : no
>> +#% guisection: Input
>> +#%end
>>   #%option G_OPT_R_INPUTS
>>   #% key: raster
>>   #% required : no
>> @@ -198,6 +202,7 @@
>> def main():
>>   group = options['group']
>> +subgroup = options['subgroup']
>>   raster = options['raster']
>>   output = options['output']
>>   coords = options['coordinates']
>> @@ -226,7 +231,10 @@
>>   # get data from group listing and set the x-axis labels
>>   if group:
>>   # Parse the group list output
>> -s = gcore.read_command('i.group', flags='g', group=group,
>> quiet=True)
>> +if subgroup:
>> +s = gcore.read_command('i.group', flags='g', group=group,
>> subgroup=subgroup, quiet=True)
>> +else:
>> +s = gcore.read_command('i.group', flags='g', group=group,
>> quiet=True)
>>   rastermaps = s.splitlines()
>>   else:
>>   # get data from list of files and set the x-axis labels
>>
>> ___
>> grass-commit mailing list
>> grass-com...@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-commit
>>
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Makefile for mixed Python & C module

[Maris Nartiss]

Hi devs,
during my free time I have been working on a Python module, but its
performance with PyGRASS was miserable. I managed to improve
performance by moving some loops to C and calling them from Python
with ctypes. Only thing I can not figure out is the Makefile.

How should a Makefile for hybrid module look like? Code is organized
in a simple fashion with two files:
i.module.py
get_data.c

Will it be possible to ship such code as an addon?

Thanks,
Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] GRASS GIS 7.2.3

[Maris Nartiss]

RC then should be a real RC. If it compiles and installs on
Windows/one Linux, ship it! (mv grass-rc.tgz grass-release.tgz) No
"yet another RC in three weeks".

Māris.
2018-03-09 16:14 GMT+02:00 Markus Neteler :
> I am not convinced - a single RC would be good to avoid emergency re-release.
> Maybe no fully packaging needed but know if it compiles at all...
>
> Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] planning releases - spring 2018

[Maris Nartiss]

2018-03-04 20:59 GMT+02:00 Markus Neteler :
> For 7.2.3, I see only these relevant candidates left:
>
> * i18N: Install gettext to Python script modules to use translated
> strings extracted by r70817: r70818

It is useless to backport r70818 without r70817. And both are
questionable, as someone would have to merge translations from trunk
to 7.2 as there are no translations for newly extracted strings in 7.2
and Transifex points to (whatever but it is not 7.2).
I tend to say - no backport for this one.

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

Re: [GRASS-dev] Problems installing the r.pi suite using g.extension [was: Re: [GRASS-user] LSMetrics - addon development]

[Maris Nartiss]

2018-02-16 17:56 GMT+02:00 Markus Metz :
>
> the addons directory is supposed to hold executables and scripts, not
> libraries. At least I could not find a mechanism in the grass startup script
> where LD_LIBRARY_PATH is adjusted to also include some directory within the
> addons directory. I am not sure if it is worth the trouble to modify the
> addons mechanism to support addon libraries, particularly if only the r.pi
> suite is affected.

Then what is the solution? Moving all library code to each module?

> Markus M

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

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

[Maris Nartiss]

2018-01-16 22:31 GMT+02:00 Stefan Blumentrath :
> FYI:
> Seems Maris is not alone with his scepticism towards the benefits of 
> Transifex.
> Looks like several people in the QGIS project made not only good experience 
> with Transifex:
> See: http://lists.osgeo.org/pipermail/qgis-developer/2018-January/051452.html
Experience of Polish, Ukrainian and other teams starts a bit earlier
in that thread:
https://lists.osgeo.org/pipermail/qgis-developer/2018-January/051429.html

I am not against others using Tx as long as I (and other "teams") have
an opt-out.

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

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

[Maris Nartiss]

2018-01-07 23:24 GMT+02:00 Martin Landa :
> Hi all,
>
> 2018-01-07 22:03 GMT+01:00 Veronica Andreo :
>> Just out of curiosity: Why not use transifex also for Latvian? Is there any
>> particular reason for that?
>
> I agree, to exclude LV from trasifex is not systematic approach once
> we agreed that we will use transifex...
>
> Ma
I somehow, as a current translator of GRASS to Latvian, don't remember
agreeing for this.

I fail to see any benefit of using web-based translation tools. Yes, I
am familiar with Transifex and Launchpad, also with KBabel, Lokalize
and fixing raw po files. I have been working as a coordinator of KDE
Latvian "team" since 2005, translating QGIS and various smaller
projects. And still I fail to see why moving to web based tool would
be beneficial.

Translating with a web interface is just a joke. Slow and cumbersome.
Not convenient for fast review of large amount of strings. No
scripting abilities. No diff support. No possibility to reject
contributions. KDE project as whole rejected all translation work done
in Launchpad (due to extremely low quality) before Ubuntu guys dropped
KDE from Launchpad.
Transifex still is showing wrong labels for plural form strings for
Latvian language. I reported it in 2015 and their answer was "change
string order in the file". (Really?!?) Thus anyone using web interface
will provide wrong translations for Latvian language.
"Easier to contribute" argument is also not solved by moving to web
platform, as it still depends on people. I got access to translate one
project on Transifex only after it was removed from my company
production servers as being obsolete. Yes, I submitted my translated
po file, but the fact that we managed to translate, integrate, test,
deploy to production and replace with different component all before
my request to add language and assign me rights to translate was
fulfilled speaks on its own.

QGIS moved to Transifex some time a go. Number of new contributors to
Latvian language due to "it is easier to contribute": 0. Keep in mind
– contrary to GRASS GIS, QGIS is widely used in Latvia, including some
(millions € worth) governmental IT projects, thus one could expect
large number of contributors; Recently a new issue was identified (see
Qgis-tr Tue Jan 9 15:16:15 PST 2018) – it is hard to track
contributors and thus list them in credits; Following multiple
branches is still unsolved.

KDE SC (number of strings approaches 200k, comparing to GRASS shy 15k)
is still pure po+svn workflow (with teams being free to use anything
as they wish as long as final output is a po file commit to svn). So
far all proposals for global migration have died out (example:
https://marc.info/?l=kde-i18n-doc=135873075615507=2); The Summit
approach of KDE SC is worth of exploring – so far it is the best
solution for tracking multiple branches simultaneously. Still Summit
plays off only for really active teams.

Finally – I fail to see any problem for skipping *_lv.po files as long
as data exchange with Transifex is scripted (or I decide to move to
ArcGIS). I'm not blocking others of using Transifex workflow, if it
feels appealing for someone. Yes, that means that I'll have to do all
pot->po merge dance for Latvian language and I'm fine with it.

I hope I clarified a bit.
Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Please add your profile as GRASS GIS dev or user! - was: Fwd: [OSGeo-Discuss] Website 15th relaunch - members and local chapters

[Maris Nartiss]

I would wait for a few days till they fix database encoding.

https://trac.osgeo.org/osgeo/ticket/2081

With regards,
??š???ž??

2018-01-11 23:10 GMT+02:00 Markus Neteler :
> Hi devs, user, community,
>
> to gain visibility, please consider to populate your OSGeo page in the
> upcoming new Web site.
> Picking "GRASS GIS" will highlight that you are involved (yes, also
> translators, document writers etc are welcome!).
>
> For instructions, see below - it is really easy and the login you
> already have (the trac login = OSGeo-ID).
>
> Thanks!
> Markus
>
> -- Forwarded message --
> From: Jody Garnett 
> Date: Thu, Jan 11, 2018 at 3:55 AM
> Subject: [OSGeo-Discuss] Website 15th relaunch - members and local chapters
> To: OSGeo Discussions 
>
>
> Great news coming out of the system admin meeting - the OSGeo website
> is scheduled to go live Jan 15th!
>
> The "staging" website is located here: https://staging.www.osgeo.org
>
> 1. Login with your OSGeo id
>
> 2. Fill in your profile information, taking special care to provide a
> photo and add yourself to your local chapter, along with any projects
> or committees you take part in.
>
> [...]
>
> Thanks to everyone who worked so hard on this in 2017.
>
> ___
> Discuss mailing list
> disc...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/discuss
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Maris Nartiss]

Hello Markus,

2018-01-07 9:55 GMT+02:00 Markus Neteler :
> Hi Māris,
>
> Thanks but the last but one language edit you did in trunk (r71617,
> r70824, etc) which I merged into the relbranches yesterday.
> But yesterday you edited relbr74 (r72041)... does this need to go into
> trunk and relbr72 now?
No, I just merged trunk to 7.4 + manually checked for any fuzzy
strings to ensure LV readiness for release. No need to do anything
from your side.
As 7.4.0 will be out, I don't see any need for updating 7.2.x.

> It would be important to declare one as Latvian master.
> Or, ideally, you manage completeley the Latvian translations yourself :-)
Taking into account that I am the only translator and quite possibly
also the only user (except my students when I force them to do some
analysis in GRASS) of GRASS in Latvian, I'll manage translations in
future. Thus no need to take any action from your side any more. More
free time for you :-)

>> I compiled 7.4 and started GUI – looks fine for me :)
>
> Good!
>
> Markus

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

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

[Maris Nartiss]

Hello Markus,
I updated the grass-addons/tools/transifex_merge.sh script to skip lv
files. Thus no further action is needed from you in case if you merge
translations from Tx to release branch/trunk.

I compiled 7.4 and started GUI – looks fine for me :)

Māris.


2018-01-06 15:00 GMT+02:00 Markus Neteler :
> Hi,
>
> I have now
> - updated 7.5 (trunk) from Transifex except for Latvian and fixed some
> errors in the .po files, submitted;
> - updated 7.4 from Transifex except for Latvian; merged Latvian from
> trunk; fixed some errors in the .po files, submitted;
> - updated 7.2 from Transifex except for Latvian; merged Latvian from
> trunk; fixed some errors in the .po files, submitted;
>
> Procedure:
> For merging,
> - trunk: I used grass-addons/tools/transifex_merge.sh, then reverted
> the Latvian changes
> - rel branches: I used grass-addons/tools/transifex_merge.sh, then
> merged the Latvian changes from trunk using msgmerge -N
>
> Hope I got it right. Please test.
>
> Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Maris Nartiss]

2018-01-02 23:33 GMT+02:00 Markus Neteler :
> Hi,
>
> ... isn't that basically re rewrite of the script? At time is uses msgmerge.
> Maris, why must .po files be replaced rather than using msgmerge?
Hello,
I might not see whole picture of workflow clearly. My points:
* if whole translation is performed in Transifex, then (after initial
import to Tx) SVN PO file has 0 value as all changes should be
performed in Transifex;
* if msgmerge is used (although as it can be seen from the previous
point, it's useless), -N (no fuzzy matching) should be used to not
generate fuzzy matches as translation flow will be from Tx to SVN and
not backwards thus fuzzy PO file can not be fixed (in a normal
workflow).

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

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

[Maris Nartiss]

If I understood correctly, the proposed workflow is to switch
Transifex to 7.4 branch and keep it there till 7.6 branch is created.
Sounds OK.

Here is a quick list of TODOs:
* provide a script to run before each stable release that pulls
translated messages from Transifex and replaces(!) PO files in SVN. It
is important to replace existing PO files with Tx version to prevent
generation of fuzzy entries in the final PO file;
* update documentation:
** How to release;
** locale/README;
** Wiki & web page;
* document how switching between branches should be done.

As for any team willing to translate only in SVN (that's me) – only
the pulling script will have to be modified to exclude language while
pulling translations from Transifex. That's really easy and I'll do
that as soon as the script is in place.

Māris.


2017-12-20 22:13 GMT+02:00 Markus Neteler :
> On Wed, Dec 20, 2017 at 5:31 PM, Moritz Lennert
>  wrote:
> ...
>> I agree that we do not have to guarantee that the development version is
>> translated. IMHO, priority for translation should go to the stable,
>
> +1
>
>> or soon-to-be version which would mean that as soon as we create a release
>> branch, translations should be maintained for this release branch as long as
>> it is supported,
>
> +1
>
>> but any old release branch should be in strict bug-fix only
>> mode as soon as a new release is out, so message strings should not change
>> much.
>>
>> Does that sound feasible ?
>
> This is what I also think. Yet the workflow isn't fully implemented
> yet. And Maris will appreciate to not lose his translations (how to do
> that?)...
>
> Markus
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] All attempts to enable English language have failed. GRASS running with C locale. (trunk)

[Maris Nartiss]

2017-11-25 11:46 GMT+02:00 Helmut Kudrnovsky :
> here a win 10 with german locale; setting preferences in GRASS to en, then I
> get:
>
> --
> All attempts to enable English language have failed. GRASS running with C
> locale.
> If you observe UnicodeError in Python, install en_US.UTF-8 locale and
> restart GRASS.
> -
>
> what does this mean?
It means that you want to run GRASS in a language that is not
supported on your system. Attempts to switch GRASS + any related
programs that GRASS might be calling to English have failed. Your
GRASS session will run with C locale. It is not the same as en_US and
thus, although you might see messages in English (due to fact that
they are in English in the source code), it will not behave as it
should for a proper (US) English language (i.e. sorting will be "A B C
a b c" versus your expected "a A b B c C"). One more bad thing will be
defaulting to ASCII encoding thus most likely causing a failure at the
first encounter with "Österreich" (still "schadenfreude" will be
fine). To enjoy a proper English experience in GRASS, you should
install en_US.UTF-8 locale on your system. If you think – how QGIS
manages to deal with it –, here GRASS modularity bites us, besides
everything in QGIS-land is also not so fine with language switching.

Unfortunately I do not have access to recent Windows boxes (I have a
Vista VM), neither MacOS thus patches solving problems on those OSes
will have to be provided by GRASS Windows and Mac developers.

> -
> best regards
> Helmut
Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Maris Nartiss]

2017-11-20 15:03 GMT+02:00 Moritz Lennert :
> Thanks a lot, Maris !
>
> I think you can backport, so that it gets as much testing as possible
> in the 7.4 release branch before release.
Done in r71788

> Moritz
Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Maris Nartiss]

2017-11-12 19:50 GMT+02:00 Moritz Lennert :
> MarkusM is the one who really knows, but AFAIU, the GEOS implementation
> of buffering is the best we have (or the only one without errors in
> specific cases). There is not function for creating parallel lines in
> GEOS, so for that the functions in buffer2.c are the best we have, but
> they are pretty bad. Apparently, creating a parallel line is not as
> simple as it would sound, and we are still looking for a correct
> implementation, or rather to even see if such an implementation is
> possible.
I played around with native buffering (both versions) and they both
look similarly bad :(
Thus I made v.profile to hard depend on GEOS buffers (no native
option) till we manage to fix problems with native buffering.
Please test if trunk seems to be OK now (I added also a test case
based on your example).
r71769 will need a backport if there will be no objections.

> Moritz
Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Maris Nartiss]

2017-11-12 14:27 GMT+02:00 Moritz Lennert :
> Another, intermediate option would be to use the functions in
> buffer2.c, i.e. Vect_line_buffer2, which is what is used in v.buffer if
> GEOS is not available. It has a slightly different API, with some new
> outputs (holes), but shouldn't be too difficult to use in v.profile.
>
> Do you think you have the time to work on v.profile these days ?
I spent some hours trying to understand how buffering works. It
doesn't look good at the moment:
#3439 #3438 and r71704

What is the current road map for buffering? Making GEOS a hard option?
Fixing native version? Or should I try to mimic v.buffer and have both
for 7.4.0 release (#3438 and #3439 doesn't affect v.profle use case)?

> Moritz
Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] community sprint before Xmas? :)

[Maris Nartiss]

2017-11-12 18:06 GMT+02:00 Moritz Lennert :
> Ondrej is actually very much present and working for his Masters thesis
> on neural networks for GRASS ! :-)
If it is not a secret, is it possible to know more on this topic? Is
it connected with r.learn.ml? Any new modules on the way? If it's just
a thesis, then good luck ;-)

Full disclosure – I have several half baked or prototype modules
related to machine learning (TF, Theano), but no time to finish
dealing with code before winter holidays. Thus would like to know if
there aren't any competing implementations coming up soon to not waste
my time.

> Moritz

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

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

[Maris Nartiss]

2017-11-10 19:39 GMT+02:00 Moritz Lennert :
> Hi Maris,
>
> v.profile still uses the old buffering library methods which has quite
> a lot of issues.

The best question then is why we are still shipping library methods
that are *known* to be broken? If they are so broke, they must be
changed to fail all the time to prevent end-users from getting wrong
results.

> As an example, I attach the output map of the following example:
>
> v.profile input=geonames_NC@PERMANENT output=- separator=comma dp=3
> buffer=500 profile_map=roadsmajor@PERMANENT profile_where=cat=193
> map_output=test_profile
>
> I also attach the equivalent v.buffer output:
>
> v.buffer -c roadsmajor where=cat=193 dist=500 out=buff500
>
> Would it be possible for you, Maris, to change to the GEOS method used
> in v.buffer in order to get the same buffering output ?

I can take a look at v.buffer to see how GEOS is used. Still I don't
know how soon I'll have time for it :(

> This is not only formal as you can see when you use the following
> vector points as input:
>
> v.in.ascii in=- out=test_points << EOF
> 626382.68026139|228917.44816672|1
> 626643.91393428|228738.2879083|2
> 626907.14939778|228529.10079092|3
> EOF
>
> v.profile then misses out on point 2, even though it is within 500m:
>
> v.profile input=test_points output=- separator=comma dp=3 buffer=500
> profile_map=roadsmajor@PERMANENT profile_where=cat=193
> Number,Distance,cat,dbl_1,dbl_2,int_1
> 1,2102.114,3,626907.14939778,228529.10079092,3
> 2,2960.822,1,626382.68026139,228917.44816672,1

I see. I would +1 for setting current GRASS buffer functions to call
G_fatal_error till they get fixed or replaced by GEOS version. I also
would +1 to block 7.4.0 release till a final action is made (fatal
error or a fix). Quality (correctness) should be our priority.

> Moritz

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

Re: [GRASS-dev] [GRASS-SVN] r71617 - grass/trunk/locale/po

[Maris Nartiss]

According to documentation, no:
https://grass.osgeo.org/development/translations/
https://grasswiki.osgeo.org/wiki/GRASS_messages_translation#Continuing_an_existing_translation

If Transifex is the only option, then I'll research how to make lv
exempt of it (I assume modification of merge script will be enough).

Māris.

2017-10-31 20:48 GMT+02:00 Markus Neteler :
> Hi,
>
> shouldn't a translation update be done in transifex?
> And from there uploaded to svn?
>
> Markus
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Maris Nartiss]

2017-10-30 0:15 GMT+02:00 Moritz Lennert :
> Am 29. Oktober 2017 18:27:22 MEZ schrieb Markus Neteler :
>>Shall we remove it from Addons or put a "deprecated" file there for a
>>while?
>
> At least as long as 7.2 is still the official stable version it should remain 
> available in addons.
What will happen for users who have installed addon that later is
included into the core modules? I haven't been checking the code to
see if there will be any warnings printed for this case. I assume such
scenario of moving modules from addons to core will be more common if
we follow an approach of maturing code in addons at first.

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

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

[Maris Nartiss]

I added simple tests for v.profile. [1]
I also changed one of examples from documentation to use NC Basic dataset. [2]

If v.profile is moved to trunk, README file should be deleted.

As there seem to be a lot of +1's and the requirement of tests is
fulfilled, this addon should be moved to trunk to gain some exposure
before release (or wait till 7.4.1).


Māris.

1. https://trac.osgeo.org/grass/changeset/71605
2. https://trac.osgeo.org/grass/changeset/71604

2017-10-20 19:58 GMT+03:00 Helmut Kudrnovsky :
>>v.clip and v.profile are IMHO important functionality for 7.4.0.
>
> +1 for these 2 addons
>
>
>
> -
> 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 mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Fwd: [gdal-dev] git(hub) migration ?

[Maris Nartiss]

If there are talks about migration to git, I would strongly suggest to
evaluate also GitLab as an option. I haven't been migrating Trac to
GitLab thus can not comment how easy that would be, still google
search shows some options (i.e.
https://github.com/moimael/trac-to-gitlab).

Keep in mind - migrating to git is not so straight forward as CVS to
SVN. We will need to come up with git usage pattern that fits us the
best and some of them are not easy to understand at the first moment
;)

Māris.

2017-09-06 21:51 GMT+03:00 Markus Neteler :
> On Wed, Sep 6, 2017 at 8:25 PM, Martin Landa  wrote:
>> Hi,
>>
>> 2017-09-06 15:35 GMT+02:00 Luca Delucchi :
>>> Just to let us think again to git migration :-)
>>
>> yes, such experience (GDAL migration) will be highly valuable for us.
>> I feel it's topic for Bonn code sprint. Martin
>
> Yes, we need to discuss it thoroughly then because it is a complex topic.
>
> @all: please read Even's email:
> https://lists.osgeo.org/pipermail/gdal-dev/2017-September/047060.html
>
> Markus
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] move everything from /lib/init/grass.py to /lib/python/init

[Maris Nartiss]

2017-07-14 19:00 GMT+03:00 Vaclav Petras :
> Also I think one reason for having
> them there was that grass.py works without a he G Python lib found. Vaclav

This! Although having a module would be fine, we must take extra care
to put warnings in all files to not depend on any other GRASS GIS
functions that might not be available/useable before full
initialisation is done.

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

Re: [GRASS-dev] Python grass script error

[Maris Nartiss]

Works just fine here.
What is the output of os.getenv("GISBASE")? Are you trying to run this
code outside of GRASS GIS session (this could explain lack of GISBASE
environmental setting)?

Māris.


2017-06-29 18:00 GMT+03:00 Margherita Di Leo :
> Hi,
>
> I have GRASS 7.3.svn (r71212). In python , calling grass.script I get:
>
 import grass.script as grass
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/local/grass-7.3.svn/etc/python/grass/script/__init__.py", line
> 5, in 
> from .core   import *
>   File "/usr/local/grass-7.3.svn/etc/python/grass/script/core.py", line 35,
> in 
> gettext.install('grasslibs', os.path.join(os.getenv("GISBASE"),
> 'locale'))
>   File "/usr/lib64/python2.7/posixpath.py", line 70, in join
> elif path == '' or path.endswith('/'):
> AttributeError: 'NoneType' object has no attribute 'endswith'
>
> Anyone can reproduce this error?
>
> Thank you in advance
>
>
> --
> Margherita Di Leo
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] GRASS GIS 7.0.6

[Maris Nartiss]

Of course we can release 7.0.6., still I wouldn't expect any distro
already shipping 7.0 to "upgrade" GCC to 7 without upgrading the rest
of packages, as GCC 7 would break not only GRASS GIS.

At the end it is call for the release manager (Markus?) to decide if
he's into packaging et al.

Māris.

2017-06-27 12:49 GMT+03:00 Markus Neteler :
> On Mon, Jun 26, 2017 at 3:54 PM, Moritz Lennert
>  wrote:
>> On 26/06/17 15:42, Markus Neteler wrote:
>>> On Mon, Jun 26, 2017 at 2:49 PM, Markus Metz
 On Sun, Jun 25, 2017 at 11:39 PM, Markus Neteler 
>>> ...
 That means, some distros would update GRASS from 7.0.5 to 7.0.6 but not
 to 7.2.2? Weird.
>>>
>>> AFAIK their rationale is to introduce major updates only within a full
>>> distro release cycle.
>>> However, I am just guessing here, extrapolating from what I observed
>>> in Fedora and Debian.
>>
>> In Debian, it's mostly a question of timing between Debian freeze for a new
>> release and our releases. The new stable was released a week ago with
>> 7.2.0-2, and Debian testing has 7.2.1-1.
>
> FWIW, I got 7.2.1 into Fedora yesterday via maintainer Devrim Gündüz
> (my updated SPEC file + ctypes patch):
>
> https://koji.fedoraproject.org/koji/packageinfo?packageID=1972
> :-)
>
> Ok, back to the topic:
> If the majority of grass-devs thinks that a 7.0.6 release is not
> needed, I'm ok with that. Maintainers just need to understand that the
> final patch from #3331 is needed to compile with GCC 7.
>
> markusN
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [SoC] GSoC 2017 Weekly Report 2 - SOS tools in GRASS GIS

[Maris Nartiss]

2017-06-11 20:20 GMT+03:00 Ondřej Pešek :
> Hi everyone!
> * I had a problem with xml parser in OWSLib for SOS observations, because it
> works completely different way than we expected. After few conversations I
> have decided to work with raw output and write parser by myself.

I have no idea how much of XML parsing is needed, but implementing an
own XML parser never sounds a good idea unless it is a quick hack.
Working with XML in a correct way is PITA, unless your parser is
really good.
Just my 0.02, as I haven't seen teh codez.

> Regards,
> Ondrej

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

Re: [GRASS-dev] [GRASS-SVN] r70821 - grass/trunk/include/Make

[Maris Nartiss]

Hello Markus,
no idea, as it runs just fine on my system and I do not see any easy
to spot problem with test.c code. You should run it under valgrind /
gdb or just send me the core file.
Ah, yes, while at it, include also
/home/mundialis/software/grass72_svn/dist.x86_64-pc-linux-gnu/demolocation/.grassrc72

Setting all locale stuff to C should prevent failures when translated
strings are used or comma is the decimal separator thus it *should* be
harmless.

Māris.


2017-05-31 14:56 GMT+03:00 Markus Neteler <nete...@osgeo.org>:
> Hi,
>
> I guess I have to revert it:
>
> grass72_svn/lib/cdhc]$ make
> if [ "" != "" -a -f "".html ] ; then make html ; fi
> ==TEST=
> make test
> make[1]: Entering directory '/home/mundialis/software/grass72_svn/lib/cdhc'
> GISRC=/home/mundialis/software/grass72_svn/dist.x86_64-pc-linux-gnu/demolocation/.grassrc72
> GISBASE=/home/mundialis/software/grass72_svn/dist.x86_64-pc-linux-gnu
> PATH="/home/mundialis/software/grass72_svn/dist.x86_64-pc-linux-gnu/bin:/home/mundialis/software/grass72_svn/dist.x86_64-pc-linux-gnu/bin:/home/mundialis/software/grass72_svn/dist.x86_64-pc-linux-gnu/scripts:$PATH"
> PYTHONPATH="/home/mundialis/software/grass72_svn/dist.x86_64-pc-linux-gnu/etc/python:/home/mundialis/software/grass72_svn/dist.x86_64-pc-linux-gnu/gui/wxpython:$PYTHONPATH"
> LD_LIBRARY_PATH="/home/mundialis/software/grass72_svn/dist.x86_64-pc-linux-gnu/bin:/home/mundialis/software/grass72_svn/dist.x86_64-pc-linux-gnu/bin:/home/mundialis/software/grass72_svn/dist.x86_64-pc-linux-gnu/scripts:/home/mundialis/software/grass72_svn/dist.x86_64-pc-linux-gnu/lib:/home/mundialis/software/grass72_svn/dist.x86_64-pc-linux-gnu/lib:"
> LC_ALL=C LANG=C LANGUAGE=C OBJ.x86_64-pc-linux-gnu/test <
> test_numbers.csv
> TESTS:
> N:30
> /bin/sh: line 1: 28663 Illegal instruction (core dumped)
> GISRC=/home/mundialis/software/grass72_svn/dist.x86_64-pc-linux-gnu/demolocation/.grassrc72
> GISBASE=/home/mundialis/software/grass72_svn/dist.x86_64-pc-linux-gnu
> PATH="/home/mundialis/software/grass72_svn/dist.x86_64-pc-linux-gnu/bin:/home/mundialis/software/grass72_svn/dist.x86_64-pc-linux-gnu/bin:/home/mundialis/software/grass72_svn/dist.x86_64-pc-linux-gnu/scripts:$PATH"
> PYTHONPATH="/home/mundialis/software/grass72_svn/dist.x86_64-pc-linux-gnu/etc/python:/home/mundialis/software/grass72_svn/dist.x86_64-pc-linux-gnu/gui/wxpython:$PYTHONPATH"
> LD_LIBRARY_PATH="/home/mundialis/software/grass72_svn/dist.x86_64-pc-linux-gnu/bin:/home/mundialis/software/grass72_svn/dist.x86_64-pc-linux-gnu/bin:/home/mundialis/software/grass72_svn/dist.x86_64-pc-linux-gnu/scripts:/home/mundialis/software/grass72_svn/dist.x86_64-pc-linux-gnu/lib:/home/mundialis/software/grass72_svn/dist.x86_64-pc-linux-gnu/lib:"
> LC_ALL=C LANG=C LANGUAGE=C OBJ.x86_64-pc-linux-gnu/test <
> test_numbers.csv
> Makefile:19: recipe for target 'test' failed
> make[1]: *** [test] Error 132
> make[1]: Leaving directory '/home/mundialis/software/grass72_svn/lib/cdhc'
> Makefile:13: recipe for target 'default' failed
> make: *** [default] Error 2
>
> Any idea why this fails?
>
> Markus
>
>
> On Wed, May 31, 2017 at 8:47 AM, Maris Nartiss <maris@gmail.com> wrote:
>> Yes, this one looks safe too, although it affects only compilation
>> running on non English locales thus a minority of users.
>>
>> Māris.
>>
>> 2017-05-30 11:44 GMT+03:00 Markus Neteler <nete...@osgeo.org>:
>>> Hi Maris,
>>>
>>> and, shall I backport this one?
>>>
>>> Markus
>>>
>>> On Sat, Apr 1, 2017 at 2:35 PM,  <svn_gr...@osgeo.org> wrote:
>>>> Author: marisn
>>>> Date: 2017-04-01 05:35:46 -0700 (Sat, 01 Apr 2017)
>>>> New Revision: 70821
>>>>
>>>> Modified:
>>>>grass/trunk/include/Make/Rules.make
>>>> Log:
>>>> Enforce C language when running Python during compilation as LANGUAGE has 
>>>> a preference over LC_ALL.
>>>>
>>>>
>>>> Modified: grass/trunk/include/Make/Rules.make
>>>> ===
>>>> --- grass/trunk/include/Make/Rules.make 2017-04-01 11:48:43 UTC (rev 70820)
>>>> +++ grass/trunk/include/Make/Rules.make 2017-04-01 12:35:46 UTC (rev 70821)
>>>> @@ -38,7 +38,7 @@
>>>> 
>>>> PATH="$(ARCH_DISTDIR)/bin:$(GISBASE)/bin:$(GISBASE)/scripts:$$PATH" \
>>>> PYTHONPATH="$(GRASS_PYTHONPATH)" \
>>>> 
>>>> $(LD_LIBRARY_PATH_VAR)="$(BIN):$(GISBASE)

Re: [GRASS-dev] Managing the translations with Transifex

[Maris Nartiss]

The most easy solution is to just nuke (empty) offending translations
in any text editor as those errors make them unusable anyway.

Māris.


2017-05-30 12:05 GMT+03:00 Markus Neteler :
> Hi,
>
> I have merged back the translations fetched from transifex to SVN in r71148.
>
> Some issues to be fixed (how?):
>
> [neteler@oboe locale]$ make verify
> ...
> grasslibs_ja.po:6472: number of format specifications in
> 'msgid_plural' and 'msgstr[0]' does not match
> grasslibs_ja.po:6479: number of format specifications in
> 'msgid_plural' and 'msgstr[0]' does not match
> grasslibs_ja.po:6489: number of format specifications in
> 'msgid_plural' and 'msgstr[0]' does not match
> grasslibs_ja.po:6495: number of format specifications in
> 'msgid_plural' and 'msgstr[0]' does not match
> msgfmt: found 4 fatal errors
> ...
> grassmods_ar.po:29132: format specifications in 'msgid' and 'msgstr'
> for argument 1 are not the same
> msgfmt: found 1 fatal error
> - grassmods_cs.po:
> grassmods_cs.po:38116: number of format specifications in
> 'msgid_plural' and 'msgstr[2]' does not match
> msgfmt: found 1 fatal error
>
> Final question:
> Merge back to relbr72 using my good old msgmerge scripts or the
> transifex_merge.sh ?
>
> Markus
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r70821 - grass/trunk/include/Make

[Maris Nartiss]

Yes, this one looks safe too, although it affects only compilation
running on non English locales thus a minority of users.

Māris.

2017-05-30 11:44 GMT+03:00 Markus Neteler :
> Hi Maris,
>
> and, shall I backport this one?
>
> Markus
>
> On Sat, Apr 1, 2017 at 2:35 PM,   wrote:
>> Author: marisn
>> Date: 2017-04-01 05:35:46 -0700 (Sat, 01 Apr 2017)
>> New Revision: 70821
>>
>> Modified:
>>grass/trunk/include/Make/Rules.make
>> Log:
>> Enforce C language when running Python during compilation as LANGUAGE has a 
>> preference over LC_ALL.
>>
>>
>> Modified: grass/trunk/include/Make/Rules.make
>> ===
>> --- grass/trunk/include/Make/Rules.make 2017-04-01 11:48:43 UTC (rev 70820)
>> +++ grass/trunk/include/Make/Rules.make 2017-04-01 12:35:46 UTC (rev 70821)
>> @@ -38,7 +38,7 @@
>> PATH="$(ARCH_DISTDIR)/bin:$(GISBASE)/bin:$(GISBASE)/scripts:$$PATH" \
>> PYTHONPATH="$(GRASS_PYTHONPATH)" \
>> 
>> $(LD_LIBRARY_PATH_VAR)="$(BIN):$(GISBASE)/bin:$(GISBASE)/scripts:$(ARCH_LIBDIR):$(BASE_LIBDIR):$($(LD_LIBRARY_PATH_VAR))"
>>  \
>> -   LC_ALL=C \
>> +   LC_ALL=C LANG=C LANGUAGE=C \
>> $(1)
>>
>>  # default clean rules
>>
>> ___
>> grass-commit mailing list
>> grass-com...@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-commit
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Behavior of v.sort.points

[Maris Nartiss]

Please report both as new issues in trac to not loose them:
https://trac.osgeo.org/grass

Māris.


2017-05-27 6:33 GMT+03:00 Steven Pawley :
> Hello devs,
>
> I appear to be having some problems with the add on v.sort.points. Two
> issues, potentially bugs:
>
> (1) the module fails if the 'cat' column is not the first attribute in the
> table (i.e. if points have been generated from a database table), returning
> the error:
>
> 'Error in sqlite3_prepare(): duplicate column name: cat'
>
> (2) even if 'cat' is the first column, sorting by an integer column does not
> appear to be sorting point datasets in numeric order. Example from the
> nc_spm location:
>
> v.sort.points input=firestations@PERMANENT output=firestations_sorted
> column=ID
>
> The order of the points based on opening the attribute table, and the
> relationship between the 'ID' column and 'cat' appears to be the same as the
> original dataset, where 'ID' was not in ascending order.
>
> Either I'm doing something wrong or the add on requires some tweaks.
> Otherwise this would be a useful tool.
>
> Steve
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Implement a REST API for GRASS

[Maris Nartiss]

It is no about implementation but the concept itself. As soon as there
will be an easy way how to provide GRASS GIS processing as a service,
somebody will run it without understanding all security ramifications
of allowing any input into GRASS. Securing GRASS code would be nice,
but so far we are short on high level developers who could do it.
I'm not voting against anyone making easy to run GRASS via WPS or
REST, I just want to be sure that lack security against various remote
threats is kept in mind.

Māris.


2017-05-25 11:24 GMT+03:00 Blumentrath, Stefan <stefan.blumentr...@nina.no>:
> Seen this: https://bitbucket.org/huhabla/open-graas?
> Cheers
> Stefan
> 
> Von: grass-dev [grass-dev-boun...@lists.osgeo.org] im Auftrag von Maris 
> Nartiss [maris@gmail.com]
> Gesendet: Donnerstag, 25. Mai 2017 09:42
> An: Pietro
> Cc: GRASS developers list
> Betreff: Re: [GRASS-dev] Implement a REST API for GRASS
>
> I assume that both are equally dangerous. My opinion is that GRASS GIS
> should not be exposed to any non trustable users, as various smaller
> and larger bugs are too common. Unless, of course, it runs inside a
> throw-away VM.
>
> 2017-05-25 10:33 GMT+03:00 Pietro <peter.z...@gmail.com>:
>> Dear Māris,
>>
>> On Wed, May 24, 2017 at 8:52 PM, Maris Nartiss <maris@gmail.com> wrote:
>>>
>>> GRASS GIS code has never been developed with security in mind. I would
>>> not suggest to run it in a non-trustable environment.
>>
>>
>> Do you think that expose some GRASS modules through a REST API can be more
>> dangerous than exposing the same modules through a WPS service? Why?
>>
>> Pietro
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev