<div>Hi there Vaclav, an assorted reaction to your remarks:<br></div><div><br></div><div>- Hexagonal rasters have to be integrated as new data type, there are too many differences to a squared raster to make it practical otherwise. Note however, that I do not know the code in GRASS, so you suggestions may still make sense.<br></div><div><br></div><div>- The abstraction of the raster data type is the key to integrate hexagons with the least work possible. In the modules themselves, this would mean transforming segments where cell neighbourhood or geometry may be hard-coded. E.g. a loop like:<br></div><div>for(i=0; i<8; i++)<br></div><div>must be transformed into something like:<br></div><div>for(i=0; i<NUM_NEIGHBOURS; i++)<br></div><div><br></div><div>- In theory, all raster modules can function in exactly the same way with both square and hexagons if all geometric and neighbourhood methods/properties/functions are abstracted correctly.<br></div><div><br></div><div>- The risk here is breaking the existing r. modules by implementing the raster abstraction. Perhaps some sort of transition may be devised to avoid it <br></div><div class="protonmail_signature_block "><div class="protonmail_signature_block-user "><div><br></div><div>- On my side, the next step is to dive into the code and study how practical these ideas may be. But please put forward your ideas in any case.<br></div><div><br></div><div>Cheers.<br></div><div><br></div><div>-- <br></div><div>Luís Moreira de Sousa<br></div><div>Im Grund 6<br></div><div>CH-8600 Dübendorf<br></div><div>Switzerland<br></div><div><br></div><div>Phone: +41 (0)79 812 62 65<br></div><div>Email: <a href="mailto:luis.de.sousa@protonmail.ch">luis.de.sousa@protonmail.ch</a><br></div><div>URL: <a href="https://sites.google.com/site/luismoreiradesousa">https://sites.google.com/site/luismoreiradesousa</a><br></div></div><div class="protonmail_signature_block-proton protonmail_signature_block-empty"><br></div></div><div><br></div><blockquote class="protonmail_quote" type="cite"><div>-------- Original Message --------<br></div><div>Subject: Re: [GRASS-dev] Adding hexagonal rasters to GRASS<br></div><div>Local Time: July 24, 2017 1:19 AM<br></div><div>UTC Time: July 23, 2017 11:19 PM<br></div><div>From: wenzeslaus@gmail.com<br></div><div>To: Luí­s Moreira de Sousa <luis.de.sousa@protonmail.ch><br></div><div>grass-dev@lists.osgeo.org <grass-dev@lists.osgeo.org><br></div><div><br></div><div dir="ltr"><div>Dear Luís,<br></div><div><div class="gmail_extra"><div><br></div><div class="gmail_quote"><div>On Sun, Jul 23, 2017 at 11:50 AM, Luí­s Moreira de Sousa <span dir="ltr"><<a rel="noreferrer nofollow noopener" href="mailto:luis.de.sousa@protonmail.ch">luis.de.sousa@protonmail.ch</a>></span> wrote:<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div><br></div><div><br></div><div>I presented hex-utils at the GISTAM conference in April, here is the video:<br></div><div><a rel="noreferrer nofollow noopener" href="https://www.youtube.com/watch?v=uLO4HDCVBp0">https://www.youtube.com/watch?<wbr>v=uLO4HDCVBp0</a><br></div><div><br></div></blockquote><div><div><br></div><div class="gmail_extra">thank you, this is very informative and exiting!<br></div><div> <br></div></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div><br></div><div><br></div><div>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.<br></div></blockquote><div><br></div><div>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.<br></div><div> <br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div><br></div><div><br></div><div>For a programmer, the main difference between hexagonal and squared rasters is the cell addressing system: with hexagons the axis are not orthogonal.<br></div></blockquote><div><br></div><div>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). <br></div><div> <br></div><div><br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div>However, it is possible to store an hexagonal raster in a bi-dimensional array like you would store a squared raster.<br></div></blockquote><div><br></div><div>That would help the implementation and hopefully also the integration and adoption, again see below.<br></div><div> <br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div>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.<br></div></blockquote><div><br></div><div>If you can share it, I would like to see it.<br></div><div> <br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div><br></div><div><br></div><div>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 ;)<br></div></blockquote><div><br></div><div>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.<br></div></div></div><div class="gmail_extra"><div>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).<br></div></div><div class="gmail_extra"><div>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).<br></div></div><div class="gmail_extra"><div>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.<br></div></div><div class="gmail_extra">If I may ask, what would you need to create a prototype and what do you envision as a final goal?<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Best,<br></div><div class="gmail_extra">Vaclav<br></div></div></div></blockquote><div><br></div>