Opened 5 years ago

Closed 4 years ago

#2624 closed defect (fixed)

r.horizon problem in Windows (horizon_zud)

Reported by: rorschach Owned by: grass-dev@…
Priority: major Milestone: 7.0.1
Component: LibGIS Version: 7.0.0
Keywords: r.horizon, r.sun, wingrass, basename.c Cc: andrei
CPU: Unspecified Platform: Unspecified

Description

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.

Change History (8)

comment:1 Changed 5 years ago by rorschach

Keywords: wingrass added; grass windows removed

comment:2 Changed 5 years ago by wenzeslaus

Keywords: r.sun added; grass70 removed

comment:3 Changed 4 years ago by andrei

Cc: andrei added
Component: RasterLibGIS
Keywords: basename.c added
Platform: MSWindows 8Unspecified
Priority: normalmajor

this has its origin in 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.

Last edited 4 years ago by andrei (previous) (diff)

comment:4 Changed 4 years ago by annakrat

Hopefully fixed in r65614. Please test in trunk.

comment:5 in reply to:  4 Changed 4 years ago by annakrat

Replying to annakrat:

Hopefully fixed in r65614. Please test in trunk.

Backported in r65618. Still needs to be confirmed.

comment:6 Changed 4 years ago by neteler

Milestone: 7.0.17.0.2

Ticket retargeted after 7.0.1 milestone closed

comment:7 Changed 4 years ago by neteler

Milestone: 7.0.27.0.3

Ticket retargeted after milestone closed

comment:8 Changed 4 years ago by neteler

Milestone: 7.0.37.0.1
Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.