I would call it a (undocumented) feature not a bug as it dates back to initial revision of v.mkgrid. Unfortunately I could not find the initial commit with a rationale behind magical number 27. Earliest change I found was from 2004, when Radim just commits v.mkgrid with message "upgrade". It is possible that this feature(?) dates back to original version "Written by GRASS, Fall of 88, Michael H." thus its original meaning seems to be lost.
I would suggest to go to trac and open a bug (with a patch, preferably). Question, of course, is - which behaviour is the correct one (count from bottom, count from top). https://trac.osgeo.org/grass/changeset/13320 Māris. 2015-11-28 0:14 GMT+02:00 Michel Wortmann <[email protected]>: > Hi Devs, > I have been using the v.mkgrid command extensively recently and noticed that > the tables of the output differ depending on the grid size. Apart from not > having the columns rown and coln, larger grids’ row column counts from > bottom to top rather than top to bottom as with smaller grids. I have dug in > the code and found the appropriate lines in the main.c: > > > > > 447 if (grid_info.num_rows < 27 && grid_info.num_cols < > 27) { > 448 sprintf(buf, "( %d, %d, %d, '%c', '%c' )", > 449 attCount + 1, grid_info.num_rows - i, > 450 j + 1, 'A' + grid_info.num_rows - i - 1, > 'A' + j); > 451 } > 452 else { > 453 sprintf(buf, "( %d, %d, %d )", > 454 attCount + 1, i + 1, j + 1); > > > > > > Has this a good reason or is this a bug? I guess inconsistent output is > undesirable here. > Best, > Michel > > _______________________________________________ > grass-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-dev _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
