frame_id in response from osm_server should be configurable

[miaoxw]

Recently I'm using osm_cartography package for visualization of OpenStreetMap data. This package works well when running alone, but I think something needs to be improved when this package is working with other packages, such as robot_localization.

Here is the scenario: I'm using GPS, IMU and wheeled odometery for localization of my robot. In robot_localization, it defines the following TF tree:

map->odom->base_link
 |
 ->utm(->local_map)          //local_map is my frame for easier observation

In this TF tree, map frame is not in UTM coordinate, but utm frame is. However, osm_server hard-coded frame_id in the response as /map. By the behavior of this package, markers are published on map frame, but that is far from the real UTM coordinate. I think it is better to let user configure this frame id at their wish.
By the way, tf2 doesn't support the forward-slashd frame id any more. According to the tf2/Migration Wiki:

Removal of support for tf_prefix

One feature which has never really worked was the tf_prefix parameter. tf_prefix was an attempt to parallel the namespacing capability of ROS but for tf frame_ids. However, without core support built in the tf_prefix languished and required a significant amount of work for all developers to implement it correctly. Only a small fraction of packages implemented tf_prefix correctly and for tf_prefix to work correctly it requires all packages interacting with the data to be fully implemented. Thus tf_prefix was only useful for very limited use cases.

tf2 does not support tf_prefix. To avoid confusion tf2 asserts that all frame_ids do not start with /. To make this work tf::resolve will still work to join a tf_prefix and a frame_id, but it will no longer support escaping a frame_id which starts with '/'. tf2 will treat all frame_ids as string literals. All pass throughs from tf to tf2 will strip the leading slash.

To support multiple homogeneous tf trees. As multiple master techniques develop for ROS it is expected that there will be tools developed which will expose subsets of tf data onto foreign masters.

Perhaps the default behavior of osm_server should be changed even if we don't turn frame_id customizable.

I have looked into the related code and I'm supposing some ways to fix that.

• Add a parameter for osm_server as the frame id (Acceptable)
  This might be the easiest way. But the problem that who should control the frame to locate those markers remains to be considered. Personally, being handled by osm_server is not a perfect idea, but still acceptable.
• Add a parameter for viz_osm and pass that value from service get_geographic_map (Not recommended)
  It is better for service's client to hold that frame id. In this way, different clients can visualize maps of different areas at the same time. But fixing in this way has to change the definition of geographic_msgs/GetGeographicMap, the package which is also used by many other packages. We had better not change that interface so significantly.
• Add a parameter for viz_osm and pass that value from another service offered by get_geographic_map (Favourable)
  That new service can be called set_frame_id or something else. With the use of dynamic reconfigure, once we want to publish markers on a different frame, server can be noticed in time.

I think I can fix the code in any of these ways by myself. I need some suggestions. If you think this fix is necessary, please feel free to let me know. After finishing the fix work, I'm going to put a PR forward.