ros / common_msgs

Commonly used messages in ROS. Includes messages for actions (actionlib_msgs), diagnostics (diagnostic_msgs), geometric primitives (geometry_msgs), robot navigation (nav_msgs), and common sensors (sensor_msgs), such as laser range finders, cameras, point clouds.
http://wiki.ros.org/common_msgs
181 stars 190 forks source link

Add polygon with 64bit precision #117

Closed jgassaway closed 6 years ago

jgassaway commented 6 years ago

There is no polygon with 64 bit precision, this adds a Polygon64 and Polygon64Stamped.

Ideally, the standard naming conventions should be maintained, where Polygon.msg has 64-bit, and Polygon32.msg has 32-bit precision, but that would change the message definition and is more likely to break dependent code.

tfoote commented 6 years ago

Could you explain a little bit more about the use case where you see this as necessary? In general I'd prefer not to have duplicates of every message with different precisions for then every component dealing with that datatype needs to have dual parallel interfaces and possibly implementations. It might make more sense to have specific messages (with extra information) for a use case or cases that need the higher precision.

jgassaway commented 6 years ago

For my part, I have a simple polygon drawing tool in mapviz. I am outputting a polygon in wgs84 (gps latitude and longitude) coordinates, where I actually need the precision to be low enough for centimeter accuracy or less.

tfoote commented 6 years ago

For that use case a generic polygon 32 or 64bit is not appropriate. Latitude and longitude do not fit into Points (the units of points are meters). As a first pass I'd suggest simply using a vector of sensor_msgs/NavSatFix datatypes, which natively represents latitude and longitude. There's clearly more information in there than you need. And a custom message could be created to be more specific.

What is the object that you're trying to represent? If you're defining a message it needs to capture the semantic meaning of the data so that it can be reused appropriately.

jgassaway commented 6 years ago

Alright, sounds like I need a better approach for representing this data. I'll either create a different msg type, or handle my polygon creation another way. Thanks!