alog" 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. :-)
>
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 c
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
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
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
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
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 th
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 fiddli
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
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 reformat
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.
--
Th
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? Class
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
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 classificatio
.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
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 modu
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
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) o
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://gith
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
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
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
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 ar
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 includ
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
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
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 signatu
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
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
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-a
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, class
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
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 onlin
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 aw
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
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
() rak
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
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,
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 instructi
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 compi
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 f
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=UnVOa0
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 funct
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
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
> Luc
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 wo
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://git
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 di
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 process
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
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
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
>
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 Uni
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
supp
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
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 learn
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.o
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 yo
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
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:
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īj
... 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
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 n
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 con
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/freety
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, no
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
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:4
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 o
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
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 hybri
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
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 wo
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 no
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-Ja
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 tha
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
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 no
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
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 perfo
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
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
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@
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 bu
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 diffi
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 th
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 fai
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 wi
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
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
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 - mig
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
funct
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 , ca
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.
2
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
86_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
> mak
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 fixe
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
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' col
s: 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 devel
1 - 100 of 371 matches
Mail list logo
