[GRASS-dev] [SoC] Week 08 Report: GRASS GIS Locations from Public Data

[Zechariah Krautwurst]

WEEK 08: JULY 17 - JULY 21
GRASS GIS Locations from Public Data
Zechariah Krautwurst

ACCOMPLISHED
- UNAVAILABLE

NEXT WEEK
- Review and complete r.in.usgsned
- Begin converting r.in.usgsned into r.in.usgs
- Create hardcoded USGS data dictionaries
- Continue working on dynamic dictionaries
- Refine clean-up, cache, and zip detection code
- Finalize module with mentors

CHALLENGES
- None

Latest git commit:
https://github.com/zkwurst/GSoC2017-GRASS-GIS/commit/48e9d9d6480fb3f5b2554d0076618e43f0f743ed

Commit url missing from Week 07 report:
https://github.com/zkwurst/GSoC2017-GRASS-GIS/commit/cd6213a8faa968a6724a3d042d98ac01622d4895
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Week 08: Integration Of PDAL into GRASS GIS

[Paul Schrum]

1. What did you get done this week?
a. Completed the basic functionality of r.in.pdal. (Link to commit

)

2. What do you plan on doing next week?
a. In r.in.pdal, remove all remaining references to liblas while retaining
all functionailty already part of r.in.lidar.

b. Set up and pass unit tests for v.in.pdal and r.in.pdal.  (Carried over
from Week 6.)

c. Develop a class to build a pdal pipeline from GRASS options and inputs
of v.in.pdal and r.in.pdal.

3. Are you blocked on anything?
No.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Adding hexagonal rasters to GRASS

[Vaclav Petras]

Dear Luís,

On Sun, Jul 23, 2017 at 11:50 AM, Luí­s Moreira de Sousa <
luis.de.so...@protonmail.ch> wrote:

>
> I presented hex-utils at the GISTAM conference in April, here is the video:
> https://www.youtube.com/watch?v=uLO4HDCVBp0
>
>
thank you, this is very informative and exiting!


>
> But as Luca said during the Q/A, it is probably better to start outright
> within GRASS. This will require the abstraction of the raster concept,
> together with operations like neighbourhood, number of neighbours, distance
> to neighbours, etc. With that done most of the raster modules would
> function the same way for squared and hexagonal rasters. Still, this would
> require a complete revision of all the raster modules.
>

Sounds good. I think there is a way in GRASS GIS to make it revolutionary
and at the same time keeping everything in place. See below.


>
> For a programmer, the main difference between hexagonal and squared
> rasters is the cell addressing system: with hexagons the axis are not
> orthogonal.
>

If there would be a way, like the abstraction you mentioned, which would,
e.g. make the current rectangle-only code work with hexagonal data (e.g. by
presenting converting hexagons as rectangles on the fly), that would be
helpful, but on the other side, I don't think it is necessarily the first
step if there is an other way how to connect with rectangular rasters (even
if it involves converting back and forth or less precision).


> However, it is possible to store an hexagonal raster in a bi-dimensional
> array like you would store a squared raster.
>

That would help the implementation and hopefully also the integration and
adoption, again see below.


> I wrote an article last year with full details on the HexASCII file format
> and how to deal with hexagonal cell adressing, but it is still under
> review. I can not send it to the list, please send me a personal message if
> you wish to read it.
>

If you can share it, I would like to see it.


>
> It would be great if we can take this forward. I imagine it is a load of
> work, but it will make GRASS an even more awesome system ;)
>
>
Load of work and resulting code to maintain should be part of the
consideration. Using existing functionality (algorithms, formats) and
integrating with it will be crucial for both users and developers alike.

Can you implement it this as a layer on top of existing functionality in
GRASS GIS? There is several examples and concepts in GRASS GIS of this. For
example, the temporal (t.*) modules work with series of rasters and vectors
registered as spatio-temporal datasets and the image processing (i.*)
modules work with series of rasters registered as imagery groups and
subgroups ("multiband image"). In both cases standard storage of rasters
(or vectors) is used, so there is no new backend format in GRASS database
except for the additional data (metadata) needed for these tools. What is
important is that you can work with the existing tools on the data handled
by temporal or imagery modules, i.e. you can use the existing tools to
implement the new tools (e.g. average of spatio-temporal raster dataset can
be implemented through a tool for average of multiple rasters) and if the
imagery or temporal modules miss specific functionality you need, you can
fallback to the standard modules (e.g. loop over members of imagery group).

I was thinking that the hexagonal rasters can be implemented in GRASS GIS
using two rasters which would be shifted against each other, but aligned
with the hexagonal cells, i.e. two rectangular rasters making up one
hexagonal raster/grid (but I didn't test that or examined that more). After
seeing your video with slightly rotated hexagonal grid, I'm thinking if it
is possible to fit only one raster but with different resolution to the
hexagons. The idea is that 1) you don't need another storage format and 2)
you can use the raw data without the hexagon-aware algorithms. Of course we
can settle just with re-using the storage format (1).

Another approach is to threat hexagonal rasters/grids as another basic data
type next to raster maps, vector maps, and 3D raster maps (in GRASS GIS
there are also the aforementioned spatio-temporal datasets and imagery
groups). They would be connected to the rest where it makes sense. For
example, (2D) rasters and 3D rasters are independent, but there is also
several connections: there are modules for conversion in between the two
types, a lot of code for handling colors is the same, and computational
region applies to both and is handled from the same module.

If I may ask, what would you need to create a prototype and what do you
envision as a final goal?

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

[GRASS-dev] [SoC] GSoC 2017 Weekly Report 8 - SOS tools in GRASS GIS

[Ondřej Pešek]

Hi everyone!

Here is the eighth report of my GSoC project - SOS tools in GRASS GIS. You
can see my project at wiki at [1]

What did you get done this week?

* t.vect.in.sos creates new vector for each offering and observed property
   main commits: [2], [3], [4]
* implemented shell script style output into modules
   main commits: [5]
* first shuck of r.in.sos
   main commits: [6]
* get exhausted at FOSS4G-E

What do you plan on doing next week?

* I hope that me and Luca will solve somehow a problem with temporalization
in t.vect.in.sos, because I would like to finish this module
* If possible, I would like to finish also r.in.sos (or at least approach
the end)

Are you blocked on anything?

* In t.vect.in.sos, I'm stuck on the temporalization of a vector map with
layers (based on timestamps). I have opened an issue for that [7] and me
and Luca are working on the solution.


Regards,
Ondrej

[1] https://trac.osgeo.org/grass/wiki/GSoC/2017/SOSInGRASS
[2]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/b9d81443ec20d92737a50b78c4f7e0f042a5b90a
[3]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/4b5728973d9a3417ec641e9a27d6788f6abbe7a5
[4]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/090cc580603bbefca27176df7127a8ca353f1dfb
[5]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/11dcefd601a061f786ddcaf4cb1a11ee0c06a10b
[6]
https://github.com/pesekon2/GRASS-GIS-SOS-tools/commit/e513796000da6ed2ee5d9028be492221956c8cb3
[7] https://github.com/pesekon2/GRASS-GIS-SOS-tools/issues/18
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2940: Compiling Grass-7.0.3 under FreeBSD: tplot directory (with log)

[GRASS GIS]

#2940: Compiling Grass-7.0.3 under FreeBSD: tplot directory (with log)
--+-
  Reporter:  pieside  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.2
 Component:  Default  |Version:  7.2.0
Resolution:   |   Keywords:  FreeBSD
   CPU:  x86-64   |   Platform:  Other Unix
--+-

Comment (by mmetz):

 Replying to [comment:3 glynn]:
 > Replying to [comment:2 pieside]:
 > > The problems seems to be an old friend:
 > >
 > {{{
 > /home/pierre/tmp/grass7/grass-7.0.3/dist.x86_64-unknown-
 freebsd10.2/lib/libgrass_gis.7.0.3.so: undefined reference to `libiconv'
 > }}}
 >
 > This usually means that it's including  from libiconv but
 linking against the system iconv (which may be part of libc).

 Both the configure tests and the compilation use the same CPPFLAGS
 "-I/usr/local/include", i.e. the libiconv version of iconv.h should be
 found first for both configure and compilation. The problem is that
 configure tests for iconv() include /usr/include/iconv.h from libc despite
 CPPFLAGS while the actual compilation includes /usr/local/include/iconv.h
 from libiconv which requires linking against libiconv.

 >
 > One way to solve issues with multiple library versions is to create
 "include" and "lib" directories, populate them with symlinks to the
 desired versions of the headers and libraries, and use --with-includes=
 and --with-libs= to put those directories at the front of the search path.

 Or ensure that configure tests and compilation use the same order of
 include dirs.

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #3368: warnings and errors in compilation log

[GRASS GIS]

#3368: warnings and errors in compilation log
--+-
  Reporter:  hellik   |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.4.0
 Component:  Compiling|Version:  svn-trunk
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  All
--+-

Comment (by mmetz):

 Replying to [ticket:3368 hellik]:
 > looking into the
 [https://wingrass.fsv.cvut.cz/grass73/x86_64/logs/log-r71243-290/
 package.log] regarding warnings and errors during compilations in windows
 (zipped log file attached), there are some warnings and error (AFAIR I've
 seen them also in my debian 9):

 There will be many more compiler warnings with different compiler flags,
 e.g. -Wall -Wextra -Wpedantic -Wshadow

 As of trunk r71288, some of the warnings have been removed.

 The errors in ctypes parsing C headers seem to be harmless, ctypes is
 apparently working anyway. Getting rid of these error messages would be a
 nice to have.

 About the remaining compiler warnings:

 There are various warnings like

 {{{
 warning: assignment discards 'const' qualifier from pointer target type
 }}}

 These are mostly harmless, it would be nice to get rid of them.

 About iconv

 MS Windows

 {{{
 parser_interface.c: In function 'print_escaped_for_xml':
 parser_interface.c:67:20: warning: passing argument 2 of 'libiconv' from
 incompatible pointer type [-Wincompatible-pointer-types]
   ret = iconv(conv, (char **), , , );
 ^
 In file included from parser_interface.c:32:0:
 C:/OSGeo4W64/include/iconv.h:87:15: note: expected 'const char **' but
 argument is of type 'char **'
  #define iconv libiconv
^
 C:/OSGeo4W64/include/iconv.h:89:37: note: in expansion of macro 'iconv'
  extern LIBICONV_DLL_EXPORTED size_t iconv (iconv_t cd,
 const char **inbuf, size_t
 *inbytesleft,
 char **outbuf, size_t
 *outbytesleft);
 }}}

 Linux

 {{{
size_t iconv(iconv_t cd,
 char **inbuf, size_t *inbytesleft,
 char **outbuf, size_t *outbytesleft);
 }}}

 We could add `#ifdef __MINGW32__` clauses to avoid these warnings, but the
 both the standard C and the GNU libiconv version expect `char **inbuf`,
 not `const char **inbuf`, therefore I would leave it as it is.

 {{{
 put_row.c: In function 'write_null_bits_compressed':
 put_row.c:509:29: warning: passing argument 1 of 'G_lz4_compress' discards
 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
  nwrite = G_lz4_compress(flags, size, compressed_buf, size);
  ^
 In file included from
 
C:/msys64/usr/src/grass_trunk/dist.x86_64-w64-mingw32/include/grass/gis.h:670:0,
  from
 C:/msys64/usr/src/grass_trunk/dist.x86_64-w64-mingw32/include/grass/raster.h:4,
  from put_row.c:27:
 
C:/msys64/usr/src/grass_trunk/dist.x86_64-w64-mingw32/include/grass/defs/gis.h:208:1:
 note: expected 'unsigned char *' but argument is of type 'const unsigned
 char *'
  G_lz4_compress(unsigned char *src, int src_sz, unsigned char *dst,
  ^
 }}}

 G_compress() and all G_*_compress() functions would need to be changed to
 use const unsingned char *src, same for G_expand() and G_*_expand(). That
 would make sense but is a (probably harmless) API change. Considering that
 GRASS 7.2 is the first release to feature new compression methods, GRASS
 7.2 could be regarded as a tech preview and minor changes in the API
 related to the new feature might be ok.

 `lib/driver/text3.c` same iconv issue as for parser_interface.c

 `lib/cairodriver/text.c` same iconv issue as for parser_interface.c

 {{{
 [...]/include/grass/iostream/empq_adaptive.h: In constructor
 'EMPQueueAdaptive::EMPQueueAdaptive(long int)':
 [...]/include/grass/iostream/empq_adaptive.h:69:47: warning: delegating
 constructors only available with -std=c++11 or -std=gnu++11
EMPQueueAdaptive(long N) : EMPQueueAdaptive() {};
^
 }}}

 I guess the c++11 standard should not be a requirement. Any suggestions on
 how to avoid that?

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] git repo for new Web site created

[Nikos Alexandris]

À Dimanche 23 juillet 2017, Markus Neteler a écrit :
> On Jul 23, 2017 8:02 PM, "Nikos Alexandris"  wrote:
> >
> > * Helmut Kudrnovsky  [2017-07-23 01:24:36 -0700]:
> >
> >
> >> Markus Neteler wrote
> >>>
> >>> Hi,
> >>>
> >>> during the FOSS4G-Europe 2017 code sprint we decided to create a git
> >>> repo the upcoming GRASS GIS web site (there is the long standing plan
> >>> to get a new beautiful web site :-)
> >>>
> >>> To join, please register here - by using your OSGeo-ID:
> >>>
> >>> https://git.osgeo.org/gogs/grass_gis
> >>>
> >>> Then we can enable you for the repo.
> >>
> >>
> >> please add me, my account is:hellik
> >> https://git.osgeo.org/gogs/hellik
> >>
> 
> All requests so far approved.
> 
> > I hope I get the chance to join in this too.
> 
> Yes, please.
> As written earlier, register there and communicate your ID name for being
> added.

nikosa

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

Re: [GRASS-dev] git repo for new Web site created

[Markus Neteler]

On Jul 23, 2017 8:02 PM, "Nikos Alexandris"  wrote:
>
> * Helmut Kudrnovsky  [2017-07-23 01:24:36 -0700]:
>
>
>> Markus Neteler wrote
>>>
>>> Hi,
>>>
>>> during the FOSS4G-Europe 2017 code sprint we decided to create a git
>>> repo the upcoming GRASS GIS web site (there is the long standing plan
>>> to get a new beautiful web site :-)
>>>
>>> To join, please register here - by using your OSGeo-ID:
>>>
>>> https://git.osgeo.org/gogs/grass_gis
>>>
>>> Then we can enable you for the repo.
>>
>>
>> please add me, my account is:hellik
>> https://git.osgeo.org/gogs/hellik
>>

All requests so far approved.

> I hope I get the chance to join in this too.

Yes, please.
As written earlier, register there and communicate your ID name for being
added.

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

Re: [GRASS-dev] git repo for new Web site created

[Nikos Alexandris]

* Helmut Kudrnovsky  [2017-07-23 01:24:36 -0700]:


Markus Neteler wrote

Hi,

during the FOSS4G-Europe 2017 code sprint we decided to create a git
repo the upcoming GRASS GIS web site (there is the long standing plan
to get a new beautiful web site :-)

To join, please register here - by using your OSGeo-ID:

https://git.osgeo.org/gogs/grass_gis

Then we can enable you for the repo.


please add me, my account is:hellik
https://git.osgeo.org/gogs/hellik



I hope I get the chance to join in this too.

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

[GRASS-dev] Adding hexagonal rasters to GRASS

[Luí­s Moreira de Sousa]

Dear friends,
I presented hex-utils at the GISTAM conference in April, here is the video:
https://www.youtube.com/watch?v=uLO4HDCVBp0
This was before the QGis plug-in was completed, but for the rest it is pretty 
much the same story.
Before the FOSS4G-E, in my mind the next phase of the project would be to code 
the abstraction functionalities in C++ (or C), to make it fully portable and 
easier to use with other languages, particularly Java. After that would then 
come a map algebra and spatial analysis.
But as Luca said during the Q/A, it is probably better to start outright within 
GRASS. This will require the abstraction of the raster concept, together with 
operations like neighbourhood, number of neighbours, distance to neighbours, 
etc. With that done most of the raster modules would function the same way for 
squared and hexagonal rasters. Still, this would require a complete revision of 
all the raster modules.
For a programmer, the main difference between hexagonal and squared rasters is 
the cell addressing system: with hexagons the axis are not orthogonal. However, 
it is possible to store an hexagonal raster in a bi-dimensional array like you 
would store a squared raster. I wrote an article last year with full details on 
the HexASCII file format and how to deal with hexagonal cell adressing, but it 
is still under review. I can not send it to the list, please send me a personal 
message if you wish to read it.
It would be great if we can take this forward. I imagine it is a load of work, 
but it will make GRASS an even more awesome system ;)
All the best.

--
Luís Moreira de Sousa
Im Grund 6
CH-8600 Dübendorf
Switzerland
Phone: +41 (0)79 812 62 65
Email: luis.de.so...@protonmail.ch
URL: https://sites.google.com/site/luismoreiradesousa___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2940: Compiling Grass-7.0.3 under FreeBSD: tplot directory (with log)

[GRASS GIS]

#2940: Compiling Grass-7.0.3 under FreeBSD: tplot directory (with log)
--+-
  Reporter:  pieside  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.2.2
 Component:  Default  |Version:  7.2.0
Resolution:   |   Keywords:  FreeBSD
   CPU:  x86-64   |   Platform:  Other Unix
--+-

Comment (by mmetz):

 Replying to [comment:11 lbartoletti]:
 > Normally, Python is already present.

 ... but not the link python -> python2

 You need to `pkg install python`

 this creates that link (at least on FreeBSD 12).

 > It does not matter, I'll start from scratch.

 No need to start from scratch, just run gmake again.

 I get GRASS trunk (7.3) compiled on FreeBSD 12 without errors. GRASS is
 running, but there is no GUI because there is a problem with numpy:

 {{{
 ImportError: /lib/libgcc_s.so.1: version GCC_4.6.0 required by
 /usr/local/lib/gcc5/libgfortran.so.3 not found
 }}}

 That seems to be an error in the numpy/gcc ports because a gcc5 lib
 requires a gcc4 lib which seems odd.

 > Here's what I get by compiling directly
 [https://raw.githubusercontent.com/lbartoletti/grass7/master/build_log
 log].
 >
 > That's how I configured it:
 >
 > {{{
 > ./configure --with-includes=/usr/local/include --with-
 libs=/usr/local/lib --with-freetype-includes=/usr/local/include/freetype2
 --with-cairo --with-nls --with-cxx --with-readline --with-proj-
 share=/usr/local/share/proj
 > }}}
 > and the
 [https://raw.githubusercontent.com/lbartoletti/grass7/master/config_log
 log for it]
 >

--
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] git repo for new Web site created

[Moritz Lennert]

On 22/07/17 20:10, Vaclav Petras wrote:



On Sat, Jul 22, 2017 at 2:04 PM, Markus Neteler > wrote:



Then we can enable you for the repo.


Please add me. My account is wenzeslaus

https://git.osgeo.org/gogs/wenzeslaus


Me too:

https://git.osgeo.org/gogs/mlennert

:-)

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

Re: [GRASS-dev] git repo for new Web site created

[Helmut Kudrnovsky]

Markus Neteler wrote
> Hi,
> 
> during the FOSS4G-Europe 2017 code sprint we decided to create a git
> repo the upcoming GRASS GIS web site (there is the long standing plan
> to get a new beautiful web site :-)
> 
> To join, please register here - by using your OSGeo-ID:
> 
> https://git.osgeo.org/gogs/grass_gis
> 
> Then we can enable you for the repo.

please add me, my account is:hellik
https://git.osgeo.org/gogs/hellik



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/git-repo-for-new-Web-site-created-tp5328792p5328815.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev