Profile Analysis Tool Problems

[stu]

The following bugs appear to exist in the Profile Analysis Tool when run in GRASS 6.4.3 on OS X 10.6.8 and 10.7.5:

1. Save Profile Data to csv file gives this error:

Traceback (most recent call last):

File "/Users/cmbarton/grass_dev/release_20121024_grass_6_4

_3RC1/dist.x86_64-apple- darwin12.2.0/etc/wxpython/wxplot/profile.py", line 343, in SaveProfileToFile

timings = self.timings TypeError : string indices must be integers

2. Plot display is incorrectly scaled. The sampled DEM is in EPSG 3401 (Ohio north SPC, US feet)

Profile start and end points are plotted the correct distance apart, but the horizontal scale of the actual profile is plotted in meters (i.e. the plot is compressed in the first ~1/3 of the frame).

[stu]

This appears to be an OS X problem as it was not replicated using the same data set on 6.4.1 running on Ubuntu 12.04 through Parallels.

[stu]

Replying to martinl: bad analysis on my part - I found an old 6.4.1 on my OS X side and the profile tool worked fine. So it must be some time after 6.4.1 that it broke - at least on OS X 10.6.8

[cmbarton]

The error message reported in #1 doesn't make sense. Line 343 of profile.py is:

pfile = path+'_'+str(rname)+'.csv'

I also don't understand how a path on my computer is showing up in the error message since "path" in line 343 is defined by:

path = dlg.GetPath()

This doesn't at all look like GRASS 6.4.3

[stu]

Replying to cmbarton:

The error message reported in #1 doesn't make sense. Line 343 of profile.py is:

pfile = path+'_'+str(rname)+'.csv'

I also don't understand how a path on my computer is showing up in the error message since "path" in line 343 is defined by:

path = dlg.GetPath()

This doesn't at all look like GRASS 6.4.3

Sorry to report that it is indeed 6.4.3

I downloaded and reinstalled the 6.4.3 binary and was able to replicate these errors.

The same function (Profile tool - save to csv) produces the following in GRASS 7.0 svn

Traceback (most recent call last):

File "/Users/Shared/grass_dev/grass70_dev/dist.x86_64

-apple-darwin12.2.0/etc/gui/wxpython/wxplot/profile.py", line 340, in SaveProfileToFile

ppt, pit, pet, pfn, pframe, pcur = rcur TypeError : string indices must be integers The plot itself has the same characteristics as reported in the bug report for 6.4.3

[martinl]

Replying to stu:

I downloaded and reinstalled the 6.4.3 binary and was able to replicate these errors.

RC1 or latest SVN? Recently I have fixed several bugs in profile tool - see r53696.

[dadudeman]

Used r.profile interactively in GRASS 7.1 SVN. Same problems described by stu. If I use horizontal and vertical units of meters, the plot is perfect. If I change to horizontal and vertical units of feet, the Y axis of elevations is displayed correctly, but the X axis is squished to stop at the unit value in meters rather than feet. Example: I had a 800 meter transect, but when reprojected to feet and profiled, the graph stops at 800 feet rather than the approximate 2600. The endpoint triangle, however, is placed around the 2600 distance. It's as if it thinks the units are meters horizontal.

I get a seemingly related issue when I use the measure tool, as the distances are reported as units meters, but the values are reported correctly as feet.

I also tested this with grass 6.4 binary.

[annakrat]

Replying to dadudeman:

I get a seemingly related issue when I use the measure tool, as the distances are reported as units meters, but the values are reported correctly as feet.

I actually fixed the measurement tool yesterday (r61132). The problem is I guess that the units are FootUSs which is not recognized as feet. So now the original units are displayed as footuss which is still kind of weird but not wrong at least.

[annakrat]

Replying to dadudeman:

Used r.profile interactively in GRASS 7.1 SVN. Same problems described by stu. If I use horizontal and vertical units of meters, the plot is perfect. If I change to horizontal and vertical units of feet, the Y axis of elevations is displayed correctly, but the X axis is squished to stop at the unit value in meters rather than feet. Example: I had a 800 meter transect, but when reprojected to feet and profiled, the graph stops at 800 feet rather than the approximate 2600. The endpoint triangle, however, is placed around the 2600 distance. It's as if it thinks the units are meters horizontal.

Yes, it's meters because meters come from r.profile and the GUI profiling tool just takes the values as they are. I wonder if this should be changed in r.profile rather than in the GUI?

[annakrat]

Replying to annakrat:

Replying to dadudeman:

I get a seemingly related issue when I use the measure tool, as the distances are reported as units meters, but the values are reported correctly as feet.

I actually fixed the measurement tool yesterday (r61132). The problem is I guess that the units are FootUSs which is not recognized as feet. So now the original units are displayed as footuss which is still kind of weird but not wrong at least.

Backported in r61268.

[annakrat]

Replying to annakrat:

Replying to dadudeman:

Used r.profile interactively in GRASS 7.1 SVN. Same problems described by stu. If I use horizontal and vertical units of meters, the plot is perfect. If I change to horizontal and vertical units of feet, the Y axis of elevations is displayed correctly, but the X axis is squished to stop at the unit value in meters rather than feet. Example: I had a 800 meter transect, but when reprojected to feet and profiled, the graph stops at 800 feet rather than the approximate 2600. The endpoint triangle, however, is placed around the 2600 distance. It's as if it thinks the units are meters horizontal.

Yes, it's meters because meters come from r.profile and the GUI profiling tool just takes the values as they are. I wonder if this should be changed in r.profile rather than in the GUI?

I fixed this problem in GUI (r61269). Please test. Still it would be worth changing the behavior of r.profile (and then revert this commit).

[cmbarton]

Yes. The proper place to fix this is in r.profile rather than a patch in the GUI, no matter how welcome.

[mlennert]

Replying to annakrat:

Replying to annakrat:

Replying to dadudeman:

Used r.profile interactively in GRASS 7.1 SVN. Same problems described by stu. If I use horizontal and vertical units of meters, the plot is perfect. If I change to horizontal and vertical units of feet, the Y axis of elevations is displayed correctly, but the X axis is squished to stop at the unit value in meters rather than feet. Example: I had a 800 meter transect, but when reprojected to feet and profiled, the graph stops at 800 feet rather than the approximate 2600. The endpoint triangle, however, is placed around the 2600 distance. It's as if it thinks the units are meters horizontal.

Yes, it's meters because meters come from r.profile and the GUI profiling tool just takes the values as they are. I wonder if this should be changed in r.profile rather than in the GUI?

I fixed this problem in GUI (r61269). Please test. Still it would be worth changing the behavior of r.profile (and then revert this commit).

This immediately raises once again the question of whether such temporary workaround fixes are really a good idea, especially when we know that a fix is actually needed elsewhere. Now that this actually seems to work, the needed fix is in risk of oblivion.

I personally would plead for not applying such temporary fixes...

Moritz

[annakrat]

Replying to mlennert:

This immediately raises once again the question of whether such temporary workaround fixes are really a good idea, especially when we know that a fix is actually needed elsewhere. Now that this actually seems to work, the needed fix is in risk of oblivion.

Well, I tried to fix it in r.profile, but I failed. I couldn't find a correct way to get the meter-whateverfeet conversion. The problem is that in the US they apparently use FootUS instead of feet, so the standard grass mechanism for handling units fails to recognize it as feet. (Survey foot = 0.3048006096, international foot = 0.3048). g.proj, on the other hand, gives correct conversion.

[annakrat]

Replying to mlennert:

Replying to annakrat:

I fixed this problem in GUI (r61269). Please test. Still it would be worth changing the behavior of r.profile (and then revert this commit).

This immediately raises once again the question of whether such temporary workaround fixes are really a good idea, especially when we know that a fix is actually needed elsewhere. Now that this actually seems to work, the needed fix is in risk of oblivion.

I personally would plead for not applying such temporary fixes...

Any recommendation if I should backport r61269 for the upcoming beta3? I am not going to fix r.profile any time soon (I don't know how).

[wenzeslaus]

The foot/meter issue of profile (second originally reported problem) was reported also in #1273.

If the first originally reported problem was fixed and the GUI works now fine, this should be closed and new ticket should be opened against r.profile and r61269.

I'm closing #1273 as duplicate since most of the discussion is here. Reopen #1273 if scale in GUI is still not working.

Changing version to reported one.

[annakrat]

Backported fix for profiling tool in r61910. I created a new ticket #2417 for r.profile.

Reopen if needed.