r.profile should report distance in location units

[annakrat]

r.profile reports the length in meters no matter which units the current location uses. It would be better if it could report it in the current units. This ticket is created based on #1787. Once this is changed, certain changes must be reverted in GUI profile tool (r61910, r61269).

[mlennert]

patch to enable location units

[mlennert]

Replying to annakrat:

r.profile reports the length in meters no matter which units the current location uses. It would be better if it could report it in the current units.

The attached patch is a very simple attempt to use location units. I don't have time right now to revert the GUI profile tool changes to check whether this solves the problem, but at least with this patch distances are in location units.

The question is whether this should be the default behaviour of r.profile, or whether this should be only activated when a flag is set.

Moritz

[annakrat]

New patch for r.profile

[annakrat]

Replying to mlennert:

Replying to annakrat:

r.profile reports the length in meters no matter which units the current location uses. It would be better if it could report it in the current units.

The attached patch is a very simple attempt to use location units. I don't have time right now to revert the GUI profile tool changes to check whether this solves the problem, but at least with this patch distances are in location units.

Thanks for looking into this. The patch seems to work. I got confused from the handling of units in the library which is completely weird, and I thought the conversion is not working properly but it's fortunately computed correctly. I improved the patch. The only problem is the name of the units which is in case of Foot_US not recognized and G_database_unit_name gives just unit. As a result, r.profile now prints something like this

Output Format:
[Along Track Dist. (units)] [Elevation]
Approx. transect length [205.092833] units
...

but this is a different problem.

The question is whether this should be the default behaviour of r.profile, or whether this should be only activated when a flag is set.

In my opinion, in most cases you want the current units. If you think the flag would be useful, it should switch to meters and by default (unset flag) use current units. Anyone has any opinion on adding this flag?

[mlennert]

Replying to annakrat:

The only problem is the name of the units which is in case of Foot_US not recognized and G_database_unit_name gives just unit. As a result, r.profile now prints something like this

Output Format:
[Along Track Dist. (units)] [Elevation]
Approx. transect length [205.092833] units
...

but this is a different problem.

It seems to me that it should be possible to get the correct units name from the PROJ_UNITS file, but I just can't find a library function to do just that. I'm sure it must exist...

Moritz

[annakrat]

I implemented the -m flag in r62035. In case of latlon, meters are used always. I reverted the changes in GUI.

[mlennert]

Replying to annakrat:

I implemented the -m flag in r62035. In case of latlon, meters are used always. I reverted the changes in GUI.

Great, thanks !

This still leaves the issue of how to get the unit names if they are outside the standard. As they are correct in PROJ_UNITS there should be a way to get them from there.

Moritz

[marisn]

Replying to annakrat:

I implemented the -m flag in r62035. In case of latlon, meters are used always. I reverted the changes in GUI.

If changing module parameters, wouldn't it be better to implement it as a choice option with appropriate parser standard option chooser? Default could be location units. Then the user could decide, if he wants to have metres, feet, etc. Just a question not a request.

[neteler]

At least in California (​http://maps.cityofdavis.org/library/, Street Centerline, ​http://epsg.io/102642) as well as some North Carolina .prj definitions with

• unit: Foot_US
• units: Foot_USs

still exist, hence should be supported as well.

I checked and found some older discussion:

Re: U_FEET versus US_USFEET, there has been discussion in the past:

• ​http://lists.osgeo.org/pipermail/grass-dev/2011-September/055991.html
  • ​http://lists.osgeo.org/pipermail/grass-dev/2011-September/055993.html
  • ​http://lists.osgeo.org/pipermail/grass-dev/2011-September/056011.html
• ​http://lists.osgeo.org/pipermail/grass-user/2012-June/065082.html
• ​http://lists.osgeo.org/pipermail/grass-user/2012-June/065086.html

I have created a patch (attached) which introduces US_USFEET as suggested years ago by Glynn. It contains one TODO where I don't know how to distinguish the special State Plane feet case. How to do that properly? with PROJECTION_SP_USF?

TODO: GS_geodistance() in ogsf/GS_util.c comes with hardcoded values! Instead G_meters_to_units_factor() should be used, stuff to be merged.

[neteler]

Support for US feet (incomplete)

[annakrat]

working patch for us feet

[annakrat]

Replying to neteler:

I have created a patch (attached) which introduces US_USFEET as suggested years ago by Glynn. It contains one TODO where I don't know how to distinguish the special State Plane feet case. How to do that properly? with PROJECTION_SP_USF?

It seems that the PROJECTION_SP is not recognized anyway ​see GPJ_osr_to_grass. I attached a fixed patch, r.profile seems to report units now correctly (tested with ​nc_spf location).

TODO: GS_geodistance() in ogsf/GS_util.c comes with hardcoded values! Instead G_meters_to_units_factor() should be used, stuff to be merged.

This function is not used (but it should be merged anyway).

If there are no objections, I will commit it.

[annakrat]

Replying to marisn:

Replying to annakrat:

I implemented the -m flag in r62035. In case of latlon, meters are used always. I reverted the changes in GUI.

If changing module parameters, wouldn't it be better to implement it as a choice option with appropriate parser standard option chooser? Default could be location units. Then the user could decide, if he wants to have metres, feet, etc. Just a question not a request.

Yes, it was not so difficult so I added this option in r62046 (and removed the flag).

[neteler]

Thanks for fixing my proposed patch. Since PROJECTION_SP is not recognized but treated as PROJECTION_OTHER, I suggest to remove the "case PROJECTION_SP" entirely in order to simplify the code.

Please commit then.

[annakrat]

Support for feet added in r62060 and PROJECTION_SP removed in r62061. Hopefully we can close this after backporting (will wait a couple of days).

[neteler]

While we are at it, I checked the entire source code for more "private" feet definitions, there are some to be fixed:

[neteler@pgis_north grass71]$ find . -type f | xargs grep 3048 | grep -v 'pristine'
./general/g.setproj/README:	feet:foot:0.3048
./general/g.setproj/main.c:		    G_set_key_value("meters", "0.30480060960121920243",
./general/g.setproj/main.c:		    G_set_key_value("meters", "0.3048", in_unit_keys);
./raster/r.ros/spot_dist.c:    h0 = 0.3048 * (1.055 * sqrt(E));
./raster/r.watershed/ram/Gwater.h:#define METER_TO_FOOT		(1 / 0.3048)
./raster/r.watershed/seg/Gwater.h:#define METER_TO_FOOT		(1 / 0.3048)
./raster/r.shaded.relief/main.c:	    /* 1 international foot = 0.3048 meters */
./raster/r.shaded.relief/main.c:	    scale = 1. / 0.3048;
./raster/r.buffer/distance.h:#define FEET_TO_METERS 0.3048
./ps/ps.map/distance.h:#define FEET_TO_METERS 0.3048
./scripts/r.buffer.lowmem/r.buffer.lowmem.py:    'feet': 0.3048,
./vector/v.split/main.c:#define FROM_FEET        0.3048

[annakrat]

Changes in library, r.profile and gui backported in r62177, r62178.

[martinl]

Milestone renamed

[martinl]

What is missing for closing the issue?

[neteler]

Ticket retargeted after milestone closed