<div>Hi Sören, good to have you in this discussion.<br></div><div><br></div><div>I do not know exactly what the compressed row approach is, but I am pretty positive on it being applicable to hexagonal rasters too. As I wrote initially, an hexagonal mesh can be stored in an array; from then on it is all a matter of cell indexation.<br></div><div class="protonmail_signature_block "><div class="protonmail_signature_block-user "><div><br></div><div>I added the angle rotation to the HexASCII specification since there are two ways to align an hexagon with the Cartesian axis: with two sides parallel to the x axis (North-South orientation) or with two sides parallel to y axis (East-West orientation). With an angle of 0º in HexASCII you get a North-South mesh, with 90º it is a East-West mesh. If other angles complicate matters, on a first approach only angles of 0º and 90º could be considered. <br></div><div><br></div><div>In any case, rotating a mesh by an angle is a relatively simple computation, you can see an example in this method of the hex-utils package:<br></div><div><a href="https://github.com/ldesousa/hex-utils/blob/develop/hex_utils/hasc.py#L235">https://github.com/ldesousa/hex-utils/blob/develop/hex_utils/hasc.py#L235</a><br></div><div><br></div><div>During my MSc thesis I developed a method to display hexagons in a squared monitor with bitmaps that may be still useful for the d. modules. But perhaps a vector approach is more interesting today.<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 type="cite" class="protonmail_quote"><div>-------- Original Message --------<br></div><div>Subject: Re: [GRASS-dev] Adding hexagonal rasters to GRASS<br></div><div>Local Time: July 24, 2017 9:24 PM<br></div><div>UTC Time: July 24, 2017 7:24 PM<br></div><div>From: soerengebbert@googlemail.com<br></div><div>To: Vaclav Petras <wenzeslaus@gmail.com><br></div><div>Luí­s Moreira de Sousa <luis.de.sousa@protonmail.ch>, grass-dev@lists.osgeo.org <grass-dev@lists.osgeo.org><br></div><div><br></div><div>Dear Luí­s,<br></div><div>this sounds very interesting, especially the improvement for surface<br></div><div>flow algorithms using hexagonal grids and other mass conservation<br></div><div>approaches like groundwater flow, heat flow, ... .<br></div><div><br></div><div>I agree with Vaclav on this topic. I think hexagonal grids can be<br></div><div>stored using the compressed row based approach of GRASS GIS. In<br></div><div>addition the rotation of the hexagonal grid may be stored in the<br></div><div>metadata. The question is, do we need rotated hexagonal grids at all<br></div><div>or do horizontal hexagonal grids do the job? In case of "horizontal"<br></div><div>hexagonal grids the compressed row approach would be very fast for<br></div><div>horizontal access. Indexing can be easily mapped to row/column access<br></div><div>using the "odd-r" horizontal layout. The existing on the fly nearest<br></div><div>neighbor resampling algorithms will have an offset of half a cell for<br></div><div>odd row indices when interacting with normal raster layers in existing<br></div><div>modules, so they must be adjusted.<br></div><div>Neighborhood operations must be implemented on top of the existing<br></div><div>row/col approach of GRASS. All algorithms that make cell neighbor<br></div><div>computations must be modified. The existing r.mapcalc neighbor<br></div><div>operators r[x][y] can be reused in case of odd-r horizontal layout.<br></div><div>Conversion between regular grids and hexagonal grids must be<br></div><div>implemented. Resampling algorithms must be modified. Rendering of<br></div><div>hexagonal grids must be implemented in the display library.  Plenty of<br></div><div>work do do. :)<br></div><div><br></div><div>Best regards<br></div><div>Sören<br></div><div><br></div><div>2017-07-24 1:19 GMT+02:00 Vaclav Petras <wenzeslaus@gmail.com>:<br></div><div>> Dear Luís,<br></div><div>><br></div><div>> On Sun, Jul 23, 2017 at 11:50 AM, Luí­s Moreira de Sousa<br></div><div>> <luis.de.sousa@protonmail.ch> wrote:<br></div><div>>><br></div><div>>><br></div><div>>> I presented hex-utils at the GISTAM conference in April, here is the<br></div><div>>> video:<br></div><div>>> https://www.youtube.com/watch?v=uLO4HDCVBp0<br></div><div>>><br></div><div>><br></div><div>> thank you, this is very informative and exiting!<br></div><div>><br></div><div>>><br></div><div>>><br></div><div>>> But as Luca said during the Q/A, it is probably better to start outright<br></div><div>>> within GRASS. This will require the abstraction of the raster concept,<br></div><div>>> together with operations like neighbourhood, number of neighbours, distance<br></div><div>>> to neighbours, etc. With that done most of the raster modules would function<br></div><div>>> the same way for squared and hexagonal rasters. Still, this would require a<br></div><div>>> complete revision of all the raster modules.<br></div><div>><br></div><div>><br></div><div>> Sounds good. I think there is a way in GRASS GIS to make it revolutionary<br></div><div>> and at the same time keeping everything in place. See below.<br></div><div>><br></div><div>>><br></div><div>>><br></div><div>>> For a programmer, the main difference between hexagonal and squared<br></div><div>>> rasters is the cell addressing system: with hexagons the axis are not<br></div><div>>> orthogonal.<br></div><div>><br></div><div>><br></div><div>> If there would be a way, like the abstraction you mentioned, which would,<br></div><div>> e.g. make the current rectangle-only code work with hexagonal data (e.g. by<br></div><div>> presenting converting hexagons as rectangles on the fly), that would be<br></div><div>> helpful, but on the other side, I don"t think it is necessarily the first<br></div><div>> step if there is an other way how to connect with rectangular rasters (even<br></div><div>> if it involves converting back and forth or less precision).<br></div><div>><br></div><div>>><br></div><div>>> However, it is possible to store an hexagonal raster in a bi-dimensional<br></div><div>>> array like you would store a squared raster.<br></div><div>><br></div><div>><br></div><div>> That would help the implementation and hopefully also the integration and<br></div><div>> adoption, again see below.<br></div><div>><br></div><div>>><br></div><div>>> I wrote an article last year with full details on the HexASCII file format<br></div><div>>> and how to deal with hexagonal cell adressing, but it is still under review.<br></div><div>>> I can not send it to the list, please send me a personal message if you wish<br></div><div>>> to read it.<br></div><div>><br></div><div>><br></div><div>> If you can share it, I would like to see it.<br></div><div>><br></div><div>>><br></div><div>>><br></div><div>>> It would be great if we can take this forward. I imagine it is a load of<br></div><div>>> work, but it will make GRASS an even more awesome system ;)<br></div><div>>><br></div><div>><br></div><div>> Load of work and resulting code to maintain should be part of the<br></div><div>> consideration. Using existing functionality (algorithms, formats) and<br></div><div>> integrating with it will be crucial for both users and developers alike.<br></div><div>><br></div><div>> Can you implement it this as a layer on top of existing functionality in<br></div><div>> GRASS GIS? There is several examples and concepts in GRASS GIS of this. For<br></div><div>> example, the temporal (t.*) modules work with series of rasters and vectors<br></div><div>> registered as spatio-temporal datasets and the image processing (i.*)<br></div><div>> modules work with series of rasters registered as imagery groups and<br></div><div>> subgroups ("multiband image"). In both cases standard storage of rasters (or<br></div><div>> vectors) is used, so there is no new backend format in GRASS database except<br></div><div>> for the additional data (metadata) needed for these tools. What is important<br></div><div>> is that you can work with the existing tools on the data handled by temporal<br></div><div>> or imagery modules, i.e. you can use the existing tools to implement the new<br></div><div>> tools (e.g. average of spatio-temporal raster dataset can be implemented<br></div><div>> through a tool for average of multiple rasters) and if the imagery or<br></div><div>> temporal modules miss specific functionality you need, you can fallback to<br></div><div>> the standard modules (e.g. loop over members of imagery group).<br></div><div>><br></div><div>> I was thinking that the hexagonal rasters can be implemented in GRASS GIS<br></div><div>> using two rasters which would be shifted against each other, but aligned<br></div><div>> with the hexagonal cells, i.e. two rectangular rasters making up one<br></div><div>> hexagonal raster/grid (but I didn"t test that or examined that more). After<br></div><div>> seeing your video with slightly rotated hexagonal grid, I"m thinking if it<br></div><div>> is possible to fit only one raster but with different resolution to the<br></div><div>> hexagons. The idea is that 1) you don"t need another storage format and 2)<br></div><div>> you can use the raw data without the hexagon-aware algorithms. Of course we<br></div><div>> can settle just with re-using the storage format (1).<br></div><div>><br></div><div>> Another approach is to threat hexagonal rasters/grids as another basic data<br></div><div>> type next to raster maps, vector maps, and 3D raster maps (in GRASS GIS<br></div><div>> there are also the aforementioned spatio-temporal datasets and imagery<br></div><div>> groups). They would be connected to the rest where it makes sense. For<br></div><div>> example, (2D) rasters and 3D rasters are independent, but there is also<br></div><div>> several connections: there are modules for conversion in between the two<br></div><div>> types, a lot of code for handling colors is the same, and computational<br></div><div>> region applies to both and is handled from the same module.<br></div><div>><br></div><div>> If I may ask, what would you need to create a prototype and what do you<br></div><div>> envision as a final goal?<br></div><div>><br></div><div>> Best,<br></div><div>> Vaclav<br></div><div>><br></div><div>> _______________________________________________<br></div><div>> grass-dev mailing list<br></div><div>> grass-dev@lists.osgeo.org<br></div><div>> https://lists.osgeo.org/mailman/listinfo/grass-dev<br></div></blockquote><div><br></div>