fix #419 by calculating transformed x/y in image-based maps

[codebot]

In image-based maps (which almost everyone is currently using), there was some ambiguity about what the x(m) and y(m) properties panel meant when a vertex was selected. Due to long-ago historical reasons, it was simply dividing the pixel coordinate by the calculated scale of the floorplan image. This works fine for single-level worlds, but it caused problems in multi-level worlds, because the x(m) and y(m) coordinates were in meters relative to the corner of that level's floorplan image. Typically, multi-floor maps require some translation (guided by fiducials) to align the floorplan images, and this translation was not incorporated into the vertex properties panel.

This PR fixes this, so that the x(m) and y(m) coordinates are now in the metric frame of the reference level. This should coincide with what appears in the generated navigation graph and simulation model.

For reasons I haven't fully chased down at the moment, they seem to be a few centimeters difference in some of the large test maps I've tried. I need to more closely compare the C++ implementation of level-alignment (as used in the Traffic Editor GUI) and the Python implementation that is used during navigation-graph and simulation-model generation. But this fix as-is should be close enough to unblock some current work.

It should also be noted that the gradual migration to global coordinates (latitude/longitude) in traffic-editor maps will eliminate problems like this 😄

Signed-off-by: Morgan Quigley [email protected]

[codebot]

This PR should fix #419 and #391

[codebot]

Tested and fixes the issue in this multi-level world. Also tested against the maps in rmf_demos_maps and it seems to work as expected: no changes to behavior in the single-level worlds, and seems to behave reasonably in the multi-world demo maps.

[Yadunund]

The changes look good! Just had a comment for my curiosity.

[Yadunund]

Thanks for addressing that!