ros-geographic-info/geographic_info

ROS packages for geographic information

geographic_info's Issues

geodesy: add support for conversions to and from ECEF

This is needed to support the earth frame ID, as described in REP-0105, "Coordinate Frames for Mobile Platforms".

xref:

• https://en.wikipedia.org/wiki/ECEF
• http://www.ros.org/reps/rep-0105.html#earth

UTM and Euclidean geometry

Hey, great package. Just wanted to make a comment about something I read in the ROS package information

"Being a Mercator projection, these coordinates permit local navigation using Euclidean geometry"

Respectfully, I do not believe that this is strictly true, and the approximation to Cartesian diverges as you move away from the UTM zone center.

Jade release?

Geodesy is a dependency of novatel_span_driver.

geodesy: convert C++ interfaces to use the PROJ.4 Cartographic Projections library.

We are already using pyproj for the Python implementation. It makes sense for the C++ interface to use PROJ.4, too. That should also simplify maintainance.

• http://trac.osgeo.org/proj/

convert to catkin for Hydro

Needed so wet packages can depend on these interfaces.

ROS Hydro header file installation bug

The geodesy headers are installed to /opt/ros/hydro/include/geodesy/include/geodesy/*.h instead of /opt/ros/hydro/include/geodesy/*.h.

Thus the headers are not found if you try to build a dependent package.

[ROS2 Foxy] Cannot use conversion functions from `geodesy`

I am trying to convert some NavSatFix messages to WGS84 and UTM. I know in ROS1 the conversion tools we usable by

#include "geodesy/utm.h"
#include "geodesy/wgs84.h"

but this doesn't seem to work in ROS2 with the package installed by

sudo apt install ros-foxy-geodesy

I can't seem to find any example anywhere online of utilizing this package in ROS2, which would almost lead me to believe it hasn't yet been ported if not for the availability of ros-foxy-geodesy in apt. Any ideas what I'm doing wrong?

geodesy: add Universal Polar Stereographic bands to UTM coordinate implementation

This will allow "extended" UTM coordinates to map the entire globe.

The implementation is straightforward, once we know the equations for converting from WGS 84 to UPS and back.

Perhaps PROJ.4 will provide a straightforward solution, see issue #2.

Indigo release

I am currently working on migrating our software to ROS Indigo and found these packages missing. Will they be released for Indigo?

geodesy: remove deprecated geodesy.gen_uuid module

Take it out before release version 1.0.0.

devel job failing - compile error

http://jenkins.ros.org/view/Idev/job/devel-indigo-geographic_info/ARCH_PARAM=amd64,UBUNTU_PARAM=trusty,label=devel/3/console

undefined reference to `geodesy::toMsg(geodesy::UTMPose const&)'

Reproducible e.g. by adding this unit test to test_utm.cpp:

TEST(UTMPose, toMsg)
{
  double e = 1000.0;
  double n = 2400.0;
  double a = 200.0;
  uint8_t z = 14;
  char b = 'R';
  geodesy::UTMPoint pt(e, n, a, z, b);

  // identity quaternion
  geometry_msgs::Quaternion q;
  q.x = 1.0;
  q.y = 0.0;
  q.z = 0.0;
  q.w = 0.0;
  geodesy::UTMPose pose1(pt, q);
  EXPECT_TRUE(geodesy::isValid(pose1));

  geographic_msgs::GeoPose gp = geodesy::toMsg(pose1);
}

geodesy: remove unnecessary dependencies on roscpp and rospy

Only the catkin version needs to be fixed.

Azimuth message type?

Hi, I was doing research about ways of representing azimuth in ROS, and found out that there is no publicly available suitable message for it! How are people coping with that? I see robot_localization expects azimuth encoded in an IMU message, which is... a workaround? :)

Nevertheless, for our internal purposes, I've put together the following message definition. Would there be interest to send a PR and integrate this message into the more standardized geographic_msgs message library?

Azimuth.msg

Header header

# The represented azimuth angle (angular difference between a given direction and north/east)
float64 azimuth

# Variance of the measurement (i.e. standard deviation squared)
float64 variance

# Unit of measurement:
#  RAD: radians, default
#  DEG: degrees (not suggested by REP-103, but are more human-friendly)
uint8 UNIT_RAD=0
uint8 UNIT_DEG=1
uint8 unit

# Orientation type:
#  ENU: default, 0 degrees on east, increases CCW, follows to REP-103
#  NED: 0 degrees on north, increases CW (consistent with the touristic magnetic compasses)
uint8 ORIENTATION_ENU=0
uint8 ORIENTATION_NED=1
uint8 orientation

# Which north reference is used:
#  MAGNETIC: magnetic north, changes in time
#  GEOGRAPHIC: geographic north, stable in time, also called "true azimuth"
#  UTM: UTM grid azimuth, based on GEOGRAPHIC, but accounts for UTM grid convergence; valid only in specific UTM zone
uint8 REFERENCE_MAGNETIC=0
uint8 REFERENCE_GEOGRAPHIC=1
uint8 REFERENCE_UTM=2
uint8 reference

geographic_info: metapackage deprecation warning is misleading

The metapackage <description> says:

Geographic information metapackage. DEPRECATED for wet packages, use only to resolve dry stack dependencies.

Although intended only to describe the metapackage itself, this appears to deprecate the entire repository, which is confusing.

Fix for UTM Conversion to LatLon in southern hemisphere.

The python Geodey package does not correctly recreate lat lon from a utm in the southern hemisphere. It seems pyProj needs a specific hemisphere tag in the definition.

However another fix is provided in the cpp code for geodesy::UTM that I've replicated in the python code to ensure both are consisted with each other. (and as far as I can tell with google maps)

I've opened a PR #53

Bad UTM Transformation

Comparing the geodesy and pygeodesy modules:

from pygeodesy import utm as pyutm
from geodesy import utm
latlon=(-41.0,147.0)
pyutm.toUtm(latlon[0],latlon[1]) # [Z:55, H:S, E:500000, N:5461243]
utm.fromLatLong(latlon[0],latlon[1]).toPoint() # x: 500000.0 y: -4538757.06191 z: 0.0

Easting seems to be fine, Northing is the problem:

latlon=(-40.0,146.0)
pyutm.toUtm(latlon[0],latlon[1]) # [Z:55, H:S, E:414640, N:5571764]
utm.fromLatLong(latlon[0],latlon[1]).toPoint() # x: 414639.538157 y: -4428236.06463 z: 0.0

Confirmed that the pygeodesy module is giving correct UTMs according to geoplaner. Am I missing an important aspect of the geodesy.py namespace?

Release geographic_info to Noetic?

@SteveMacenski Here's a ticket to release to ROS Noetic. I had a quick look for any Python 3 related stuff that needs to be done; I don't see any Python 3 syntax errors using python3 -m flake8 --select=E999 .. For all stuff these wiki pages should be helpful

• http://wiki.ros.org/UsingPython3
• http://wiki.ros.org/noetic/Migration

• Bump CMake version to avoid CMP0048 warning (see ros/catkin#1052)
• Make geodesy use setuptools instead of distutils.core (see ros/catkin#1048)
• Create a rosdep key for python3-pyproj to replace python-pyproj used by geodesy. ros/rosdistro#24114
  • Debian: https://packages.debian.org/buster/python3-pyproj
  • Ubuntu: https://packages.ubuntu.com/focal/python3-pyproj
  • Fedora: https://koji.fedoraproject.org/koji/rpminfo?rpmID=20764115
  • Gentoo: https://packages.gentoo.org/packages/dev-python/pyproj
• Assuming ROS Melodic and Noetic will both be released from the master branch, use conditional dependencies on ROS_PYTHON_VERSION for python-pyproj/python3-pyproj and python-catkin-pkg-modules/python3-catkin-pkg-modules in geodesy.

(edit: continued from ros/rosdistro#21513 (comment))

geodesy: make Python code work with both Python 2.7 and Python 3.3