r.horizon problem in Windows (horizon_zud)

[rorschach]

I think that r.horizon does not create multiple raster maps when used in raster mode in Windows.

*Note: I am using a dual-booted PC (Ubuntu 14.04 and Windows 8.1)

I ran r.horizon on Windows 8.1 using GRASS 7.0.0. During runtime, it kept on showing angle: X raster: <horizon_zud> instead of the usual angle: X raster: horizon_X when being run on Ubuntu.

When looking at the mapset, only 1 map named horizon_zud was added when running r.horizon on Windows compared to the multiple horizon_X maps when the command is ran on Ubuntu.

Also, when using r.horizon as an input for r.sun, the results I got on Windows and Ubuntu where different. This should not have been the case considering I used the same dataset and input parameters for r.sun and r.horizon.

Lastly, when I ran r.sun on Ubuntu using the location and mapset (including the r.horizon results) I created using GRASS 7.0.0 on Windows, it tells me that the horizon maps are not found.

These things lead me to believe that r.horizon does not create multiple raster maps on Windows.

[andrei]

this has its origin in grass/trunk/lib/gis/basename.c on lines:

91	        sprintf(intfmt, "%%0%zud", ndigits);
96	        sprintf(decfmt, "_%%0%zud", ndecimals);

My C skills are very rusty and I would not like to make things worse, but I think that these two lines have to be changed to:

91	        sprintf(intfmt, "%%0%u", ndigits);
96	        sprintf(decfmt, "_%%0%u", ndecimals);

and the problem would be solved. I'm not that good with old-school format specifiers, but I have internet and there's no %z format specifier.

This problem appeared after this discussion ​2136 that decided that all basename functionality should be moved to this file.

This makes every module that outputs multiple files with file names like basename_001, basename_002, etc (and uses basename.c), unusable, since all output files will be named basename_zud and each will overwrite the previous result. In the end these modules will only leave the last result as final output.

In my opinion this is at least a major bug, if not critical since it can cause loss of data if the overwrite option is used.

[annakrat]

Hopefully fixed in r65614. Please test in trunk.

[annakrat]

Replying to annakrat:

Hopefully fixed in r65614. Please test in trunk.

Backported in r65618. Still needs to be confirmed.

[neteler]

Ticket retargeted after 7.0.1 milestone closed

[neteler]

Ticket retargeted after milestone closed

[neteler]

This was fixed for 7.0.1, no more complaints since then. Closing.