When using r.profile interactively in a location using horizontal and vertical units of meters, the output profile is correct. My transect is about 800 meters long.
When using r.profile interactively in a location using horizontal and vertical units of feet, the Y axis (raster elevation values) displays values correctly. However, the X axis stops plotting at 800 feet but puts the endpoint ‘triangle’ of the profile at the correct distance on the X axis at around 2600 feet. Essentially, it squishes the plot to fit between 0 and 800 when it should be between 0 and around 2600.
I notice that when I measure distances, the display also outputs the units in meters, but the values are in feet. Seems like a related issue.
Where do I change this so that units are correct as feet? I’ve tried setting the EPSG code in Settings–>Preferences–>Projection Tab to 2882 with the proj.4 string inserted, but it still treats the horizontal units as if they were meters and not feet when measuring or profiling the surface.
Tried r.profile in GRASS 6.4 and 7.1 on Linux Mint with same results.
When using r.profile interactively in a location using horizontal and
vertical units of meters, the output profile is correct. My transect is
about 800 meters long.
When using r.profile interactively in a location using horizontal and
vertical units of feet, the Y axis (raster elevation values) displays
values correctly. However, the X axis stops plotting at 800 *feet* but
puts the endpoint 'triangle' of the profile at the correct distance on the
X axis at around 2600 feet. Essentially, it squishes the plot to fit
between 0 and 800 when it should be between 0 and around 2600.
I notice that when I measure distances, the display also outputs the units
in meters, but the values are in feet. Seems like a related issue.
Where do I change this so that units are correct as feet? I've tried
setting the EPSG code in Settings-->Preferences-->Projection Tab to 2882
with the proj.4 string inserted, but it still treats the horizontal units
as if they were meters and not feet when measuring or profiling the surface.
Tried r.profile in GRASS 6.4 and 7.1 on Linux Mint with same results.
Thanks,
Mark
This is a long standing problem (for me anyway) - see thread from 2012 https://www.mail-archive.com/grass-dev@lists.osgeo.org/msg26480.html
I still have the problem but have learned to adapt … I upgrade the csv output to the appropriate scales in GNU Octave and replot… bit of a pain but it works.
Interesting that you are experiencing this on a Linux system - others reported the problem not replicated on Linux back in 2012.
Thanks. I’ll have to come up with a creative solution. The best solution would have been for the US to adopt the metric system back in the 70s, but there’s some saying about spilt milk.
When using r.profile interactively in a location using horizontal and
vertical units of meters, the output profile is correct. My transect is
about 800 meters long.
When using r.profile interactively in a location using horizontal and
vertical units of feet, the Y axis (raster elevation values) displays
values correctly. However, the X axis stops plotting at 800 feet but
puts the endpoint ‘triangle’ of the profile at the correct distance on the
X axis at around 2600 feet. Essentially, it squishes the plot to fit
between 0 and 800 when it should be between 0 and around 2600.
I notice that when I measure distances, the display also outputs the units
in meters, but the values are in feet. Seems like a related issue.
Where do I change this so that units are correct as feet? I’ve tried
setting the EPSG code in Settings–>Preferences–>Projection Tab to 2882
with the proj.4 string inserted, but it still treats the horizontal units
as if they were meters and not feet when measuring or profiling the surface.
Tried r.profile in GRASS 6.4 and 7.1 on Linux Mint with same results.
Thanks,
Mark
This is a long standing problem (for me anyway) - see thread from 2012 https://www.mail-archive.com/grass-dev@lists.osgeo.org/msg26480.html
I still have the problem but have learned to adapt … I upgrade the csv output to the appropriate scales in GNU Octave and replot… bit of a pain but it works.
Interesting that you are experiencing this on a Linux system - others reported the problem not replicated on Linux back in 2012.
Also, if you found an email with the ticket (copy of ticket message was
sent to mailing list), you should find a link to the ticket at the bottom
of the message.
The ticket status is in parentheses after the ticket number.
If the ticket is older without activity, you may want to write there that
you are also affected and specify your system and other related details.
You need OSGeo ID to be able to login to the GRASS Trac and create and
modify tickets.
Also, if you found an email with the ticket (copy of ticket message was sent to mailing list), you should find a link to the ticket at the bottom of the message.
The ticket status is in parentheses after the ticket number.
If the ticket is older without activity, you may want to write there that you are also affected and specify your system and other related details.
You need OSGeo ID to be able to login to the GRASS Trac and create and modify tickets.