Support of geographical co-ordinate projections other than UTM

asked 2022-03-10 20:22:53 -0500

Cadmus
25 ●3 ●6 ●11

updated 2022-03-13 21:13:59 -0500

Hi all. I would like to run an idea by other ROS users before I implement things. For reference we are using ROS 2 galactic.

We can currently convert geographical co-ordinates (e.g. GeoPoint from geographic_msgs) to projected co-ordinates (e.g. UTMPoint from geodesy) through the use of the geodesy package, however our team would like to use projections other than UTM.

It would be super convenient this kind of conversion can be done though TF2, e.g. converting from GeoPoint to a PointStamped message with a frame_id corresponding to the projection as REP 105 might be suggesting with earth and map. However I think it's not possible because of the non-linear transformation that may be necessary for some projections. (Unless non-linear transformations are possible in TF2???)

If that's not possible, then I should support the conversions with geodesy, which means I'd need to define a class similar to UTMPoint and then

implement fromMsg() and toMsg() functions for both points and poses

for each projection. I could even define an object with an extra field indicating the projection type in there so I can handle any projection conversion.

Does that sound right?

edit retag flag offensive close merge delete

add a comment

answered 2022-03-11 17:09:13 -0500

tfoote

58457 ●128 ●550 ●526 http://www.ros.org/

tf2 cannot support non-linear transforms. No coordinate frames are special for it, they're all expected to be euclidian space with SO3 rotation.

It is possible to transform to a non-euclidian space, and transform back. However when you do that you cannot rely on any of the existing transform methods as they would all have to have logic to operate in the non-euclidian space for all datatypes defined, and have knowlege of what projection they are operating in which is not available generically.

The toMsg()/fromMsg() constructs are for converting equivalent datatypes and require a bijective transformation. THis is for converting datatypes(like from a Point message to a bullet::Vector3, and not transforming the data.

Going to and from a non-euclidian space cannot be done without external references knowing things like the shape of the manifold etc.

The simplest way to do this conversion is to just have a function that converts your projection into an Earth Centered Earth Fixed (ECEF) coordinate frame and make sure to publish that transform into the tf system. If you want to go the other way you would have to converted to your ECEF frame and run the inverse transform function.

As an improvement for ease of use, you could add a transform listener/buffer inside a class which provides the above and possibly even lets you select other target frames for the output and apply the appropriate transform via a query to the buffer. Going the other way it could ingest any incoming point apply the transform automatically to take it to ECEF and then convert it to your preferred projection.

edit flag offensive delete link

Comments

Thanks for your suggestion. I think I understand what you've suggested at the end there but I would like to clarify what you mean.

Are you suggesting that we make a class that handles the conversion between a geographical co-ordinate and a projected co-ordinate, then define some transform between the projected co-ordinate with some other frame? How would you suggest how we should handle multiple projections (e.g. azimuthal projections with different reference points?)

OR are you suggesting we extend the capabilities of tf2 and publish the projection transform into the tf2 system? I would prefer this option, and we may be able to offer it as contribution back to the community if this was the case.

Cadmus ( 2022-03-13 22:07:03 -0500 )edit

The former. You should create a class that can convert between any projection and an ECEF frame earth frame. And then tf2 can handle it from there. I do not think that it is feasible to embed the knowlege and math of each and every projection into the greater distributed tf2 system. The use of specific projections for input and output makes sense. But we strive hard to keep things simple by always using metric and euclidian space. Different projections have different curvatures, potentially discontinuities and singularities etc. And the math for doing transforms and other operations becomes conditional on the representation thus making all the current algorithms will be inaccurate. Instead I strongly recommend that you use the standard representation of metric MKS and euclidian space for all your operations, and provide inputs and outputs to make them interact with other systems which are using various projections for specific application purposes.

tfoote ( 2022-03-13 23:52:54 -0500 )edit

Thanks. We will probably go ahead with that suggestion.

Cadmus ( 2022-03-15 02:09:26 -0500 )edit

add a comment

Support of geographical co-ordinate projections other than UTM

1 Answer

Comments

Question Tools

Stats

Related questions

Support of geographical co-ordinate projections other than UTM edit

1 Answer

Comments

Question Tools

Stats

Related questions

Support of geographical co-ordinate projections other than UTM