Re: [GRASS-dev] FIXED: Re: compiling GRASS-latest - configure fails with Unable to locate PostgreSQL includes
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
Re: [GRASS-dev] [release planning] GRASS GIS 8: create new release branch
On Fri, 14 May 2021 17:09:42 +0200
Markus Neteler wrote:
[...]
> 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?
#1237
#1421
#1569 (fixes #1420)
#1570 (fixes #1355)
These are all trivial bugfixes.
--
Denis Ovsienko
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] some perspective for r.geomorphon profile data
Hello list. As some might remember, last year I came to propose a few changes to r.geomorphon in order to support a student (CCed) PhD research. For me this project had lasted about 6 months, and for the student it was much longer. The research has been finally concluded and submitted, so it is a good time to follow up on the mailing list and to explain the role of these GRASS changes in the project and some ways of reusing this work in future. My contribution was to develop source code and some documentation in the following three layers: 1. r.geomorphon (C), extended to output profile data in a machine-readable format. The profile data feature is very generic and should not require major changes (if any) to accommodate similar data extraction tasks in future. The JSON/XML/YAML generation code is mostly independent from r.geomorphon, with a more sophisticated memory management it potentially could serve a better job in GRASS library supporting other plugins. 2. Geomorphon Profiler (shell, Python), developed from scratch to automate running of the above and several other GRASS plugins. This software was written to be generic and parametrizable, so it should not be difficult to adjust to other similar projects. That said, there are inevitable project-specific design choices (such as at most one extra POI in an image), but this should not block development if other sound use cases emerge. Examples of Geomorphon Profiler output can be seen in its README [a]. 3. Place-Name Props (shell, Python), developed from scratch to translate between the research space and Geomorphon Profiler space. In other words, Geomorphon Profiler can be given a short configuration file and a long list of POIs and left unattended to produce thousands of standalone geomorphon profiles and images. From that Place-Name Props produces combined files for the research study. Clearly, this only makes sense in this research, but you might be interested to look at a small example output PDF file at [b] to see how geomorphon profile data mixes with linguistic data. In the list above [1] took about 25% in terms of lines of code count and enabled the other 75% in [2] and [3], which in turn enabled subsequent phases of the research. I would like to thank GRASS developers that had the faith to review and to accept the changes to r.geomorphon, or otherwise to provide constructive feedback. When GRASS 8 comes out, this new research method should be easier to reproduce for other end users. Cheers. a: https://gitlab.com/geomorphon-hunters/GeomorphonProfiler/-/blob/master/README.md b: https://gitlab.com/geomorphon-hunters/place-name-props/-/raw/master/examples/export.pdf -- Denis Ovsienko ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS GIS single layout (GSoC 2021)
On Sun, 11 Apr 2021 11:51:32 +0200 (CEST) "L.Kladivova" wrote: > Idea: > > https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/SingleWindow I trust you mean well. Let me provide some input. My own GUI arrangement for GRASS work was on two monitors (same size, same DPI). The first monitor with the two smaller GRASS windows plus non-GRASS windows of the project was in in horizontal orientation. The second monitor with the GRASS map display was in vertical orientation to fit the region of interest. And I was running out of screen space all the time, so if this was a commercial project, there would be at least one more monitor to provide more space for the multiple independent windows. Clearly, for a single window UI it would not make as much sense. One other interesting arrangement is a more or less ordinary monitor to display some GUI in normal usable size plus another "high DPI" monitor to display some other GUI that needs to show as many physical pixels at once as possible. Of course, neither the physical size nor the pixel count match between the monitors, so when a window spans more than one monitor it becomes difficult to use. Finally, GIMP has been using multiple window UI for many years, and the users figure the GUI out just fine. So a multiple window GUI makes a sound use case and it would be nice to keep it reasonably accessible. -- Denis Ovsienko ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.geomorphon multiresolution mode
On Mon, 15 Feb 2021 22:23:09 + Michael Barton wrote: > Can anyone explain how multiresolution model works in r.geomorphon? > It does not seem to respond to any setting changes and seems to > always produce blank maps (testing with NC demo set). There is > nothing about multiresolution mode in the manual for 7.8 or 7.9 Hello Michael. I had applied a few rounds of cleanups and improvements to this plugin, one of which was directly related to multires (see commit 867ff057b). Other than that, I didn't study multires closely, but managed to notice earlier that start_distance and step_distance (which are derived from the command-line arguments) are never used in the main multires branch, which also overrides the value of num_of_steps with a hard-coded value of 5, but I had more pressing problems to solve in the non-multires branch of main() at the time. Having looked through the multires branch again just now, it does not look right that after the call to calc_pattern() the code does not have a call to determine_form(), the output of which ought to go into multiple_output[i].forms_buffer before Rast_put_row() stores it. That would explain why you have blank outputs. That said, I still do not understand the intended difference between the multiple output rasters. > Also, I think there is a typo in the manual and arguments. I think > that what is meant is the word "extent" (a noun for area) rather than > "extend" (a verb to make larger). I can make an issue for this typo > if helpful. If you take the 8 cardinal points of a geomorphon without the elevations, the plane figure will be an octagon (a degenerate one when more than two cardinal points end up in the centre). In any case, it will always be a so called simple polygon, let's call its area S1. If you take a fixed search radius, draw a circle and intersect it with the 8 cardinal directions (in other word, if you consider the regular convex case of the above figure), its maximum possible area (let's call it S2) will be a function of the search radius. So what is currently known as the "extend" output of r.geomorphon is S1/S2, hence its value belongs to the [0.0, 1.0] interval. I agree this might be not the right term, although I am not sure what would be the most appropriate geometric term in English. For what it is worth, the function that computes S1 is currently called "extends()", and both the G_parser props and the HTML document currently give an incorrect description of what the "extend" output produces, so that would be best made consistent in the same go. There are some other long-standing imperfections in both the C code and the HTML documentation of r.geomorphon, if you have time now to work on these, I could suggest a few points. That said, it would be nice not to re-jig r.geomorphon in substantial ways right now, because it is serving as a foundation for Geomorphon Profiler, and I am busy finishing another layer of software on top of these two, so a student can finally get their thesis done. -- Denis Ovsienko ___ 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
tten in three programming languages and there are so many dependencies that more than 3-4 years of backward compatibility would be an unreasonable level of commitment. So I'd say it helps to take "long-term support" with a grain of salt. Of course, if the vendor is willing to help you achieve the extra backward compatibility (see DIY above), that's a good trade-off for everyone, but usually it is not the case. Thus, as far as I can figure it out, if GRASS developers at some point establish that C17 gives GRASS particular significant technical advantages, it should be fine to declare C17 the house standard if (and only if) your currently active platforms reliably support C17. But if you resolve to stick with C89 or C99 for a few more years, that would be fine as well. -- Denis Ovsienko ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS Elections 2020] Announcement and voters registry
On Tue, 15 Dec 2020 16:29:59 +0100
"Chief Return Officer (CRO) - GRASS GIS election 2020"
wrote:
> - all people that have already posted a pull request to github
> (possibly only those PR that have been merged)
As far as I understand, that applies to me, and I would like to
nominate someone, so if there is a formal requirement for me to be on a
list of contributors, please add me there. Thank you.
--
Denis Ovsienko
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] OSGeo virtual code sprint
Hello all. I've been working on a geomorphon data processing project for a while and would like to have the code completed and published soon, would it make sense to do that as a part of the sprint? The work that still needs to be done is as follows: 1. Merge https://github.com/OSGeo/grass/pull/1052 2. Open and merge another GRASS pull request with a few more cleanups (ready as soon as you are). 3. Open and merge another GRASS pull request with a new feature for r.geomorphon (will be ready after a bugfix). 4. Finalize and publish a small stand-alone data processing tool based on the new r.geomorphon feature. It is a niche solution that I have developed as an independent contribution to a research project. I am not sure if it is useful enough to live under GRASS or OSGeo hood, but hopefully it is useful enough in similar research elsewhere. Let me know what you think and if you need additional information. -- Denis Ovsienko ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] a broken link on wiki
Hello list. Here: https://grasswiki.osgeo.org/wiki/Compile_and_Install#Download_GRASS_GIS_source_code the link "download the GRASS GIS source code" points to an invalid URL: https://grass.osgeo.org/download/sources/ It should probably be the same as "Source code" at https://grass.osgeo.org/contribute/development/ (which is https://github.com/OSGeo/grass/), or maybe something else. -- Denis Ovsienko ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
